下载文档原格式
实验三数据流图与数据字典数据流图与数据字典是软件工程中常用的工具，用于描述系统的功能和数据流动。
本文将详细介绍数据流图和数据字典的定义、结构和使用方法。
一、数据流图数据流图（Data Flow Diagram，简称DFD）是一种图形化的工具，用于描述系统内部的数据流动和处理过程。
它由四个基本元素组成：数据流、处理器、数据存储和外部实体。
下面分别对这些元素进行详细介绍。
1. 数据流（Data Flow）数据流是系统中不同部分之间传输的数据。
它用箭头表示，箭头的方向表示数据的流向。
数据流可以分为输入数据流和输出数据流。
输入数据流表示从外部实体进入系统的数据，输出数据流表示从系统流出到外部实体的数据。
2. 处理器（Process）处理器表示对数据进行处理的功能模块或子系统。
它可以是一个人、一个机器或一个软件模块。
处理器接收输入数据流，经过处理后产生输出数据流。
3. 数据存储（Data Store）数据存储表示系统中用于存储数据的位置，如数据库、文件等。
数据存储是持久化的，可以在系统的不同执行过程中保存数据。
4. 外部实体（External Entity）外部实体表示系统外部的实体，可以是用户、其他系统或设备等。
外部实体与系统之间通过数据流进行数据交换。
在数据流图中，以上四个元素通过连线连接起来，形成一个完整的系统模型。
数据流图可以分为多个层次，从整体到细节逐步展开，以便更好地理解系统的功能和数据流动。
二、数据字典数据字典（Data Dictionary）是对系统中使用的数据元素进行定义和描述的文档。
它包含了系统中使用的数据元素的名称、定义、属性和关系等信息。
数据字典的主要作用是提供对系统中数据元素的统一定义和描述，以便于系统开发和维护。
数据字典的内容包括以下几个方面：1. 数据元素名称（Data Element Name）数据元素名称是对数据元素进行命名的标识符。
它应该具有描述性，能够清晰地表达数据元素的含义。
中级数据库系统工程师2013上半年下午试题试题一阅读以下说明和图，根据要求回答下列问题。
[说明]某慈善机构欲开发一个募捐系统，以跟踪记录为事业或项目向目标群体进行募捐而组织的集体性活动。
该系统的主要功能如下所示。
1管理志愿者。
根据募捐任务给志愿者发送加入邀请、邀请跟进、工作任务；管理志愿者提供的邀请响应、志愿者信息、工作时长、工作结果等。
2确定募捐需求和收集所募捐赠(资金及物品)。
根据需求提出募捐任务、活动请求和捐赠请求，获取所募集的资金和物品。
3组织募捐活动。
根据活动请求，确定活动时间范围。
根据活动时间，搜索场馆，即：向场馆发送场馆可用性请求，获得场馆可用性。
然后根据活动时间和地点推广募捐活动，根据相应的活动信息举办活动，从募捐机构获取资金并向其发放赠品。
获取和处理捐赠，根据捐赠请求，提供所募集的捐赠；处理与捐赠人之间的交互，即：录入捐赠人信息，处理后存入捐赠人信息表；从捐赠人信息表中查询捐赠人信息，向捐赠人发送募捐请求，并将已联系的捐赠人存入已联系的捐赠人表。
根据捐赠请求进行募集，募得捐赠后，将捐赠记录存入捐赠表；对捐赠记录进行处理后，存入已处理捐赠表，向捐赠人发送致谢函。
根据已联系的捐赠人和捐赠记录进行跟进，将捐赠跟进情况发送给捐赠人。
现采用结构化方法对募捐系统进行分析与设计，获得如图所示的分层数据流图。
1、使用说明中的词语，给出图1中的实体E1～E4的名称。
2、在建模DFD时，需要对有些复杂加工(处理)进行进一步精化，图2为图1中处理3的进一步细化的1层数据流图，图3为图2中3.1进一步细化的2层数据流图。
补全图2中加工P1、P2和P3的名称和图2与图3中缺少的数据流。
3、使用说明中的词语，给出图3中的数据存储D1～D4的名称。
试题二阅读以下说明，根据要求回答下列问题。
[说明]某航空公司要开发一个订票信息处理系统，该系统的部分关系模式如下：航班(航班编号，航空公司，起飞地，起飞时间，目的地，到达时间，票价)折扣(航班编号，开始日期，结束日期，折扣)旅客(身份证号，姓名，性别，出生日期，电话，VIP折扣)购票(购票单号，身份证号，航班编号，搭乘日期，购票金额)有关关系模式的属性及相关说明如下：4航班表中的起飞时间和到达时间不包含日期，同一航班不会在一天出现两次及两次以上；5各航空公司会根据旅客出行淡旺季适时调整机票的折扣，旅客购买机票的购票金额计算公式为：票价×折扣×VIP折扣，其中旅客的VIP折扣与该旅客已购买过的机票的购票金额总和相关，在旅客每次购票后被修改。
数据库系统工程师考点精讲之数据流图基本概念考点精讲数据流图的考查中需要考生掌握数据流图的基本概念，另外还会涉及数据字典、数据库、面向对象方法、转换图、状态迁移图等概念，考生对这些概念都要非常清晰。
对于基本概念的考查一般都结合在题目中，有时也会针对这些基本概念出题，比如有的题目要求说明逻辑数据流图和物理数据流图之间的主要区别。
数据流图的基本概念数据流贯穿于企业组织的每一个活动中，可以说没有数据流就没有企业的活动。
通过对数据流程的分析，一方面可以更准确地了解企业管理活动的全过程，分析出各种管理活动的实质和相互间的关系；另一方面，数据是信息的载体，是正在开发的企业信息系统的主要对象，因此必须对系统调查中所收集的数据和数据处理过程进行分析整理，为以后的新系统逻辑模型、数据库结构和功能模块设计打下基础。
数据流程分析就是把数据在现行系统内部的流动情况抽象出来，舍去了具体组织机构、信息载体、处理工作等物理组成，单纯从数据流动过程来考查实际业务的数据处理模式。
数据流程分析主要包括对信息流动、传递、处理、存储等的分析，其目的就是确定合理的数据项，确定合适的数据流向，确认合适的数据处理过程，并发现和解决数据流通中存在的问题。
1.数据流一个系统的基本组件包括输入流、输出流以及处理过程。
企业作为一个系统也存在输入流、输出流以及处理过程，企业输入流、输出流的表现形式多种多样，在处理过程中经常要涉及各式各样的输入流、输出流。
要想很好地了解一个企业的活动，需具体分析其中所包含的各种流。
（1）物资流工厂输入原材料与零配件，经过加工制造过程，输出成品；商店进货，经过销售过程，把货卖给顾客。
这些输入与输出物品的流动都属物资流。
（2）事务流事务是指系统与其外部环境或子系统之间发生的交往活动而引起的一系列信息处理活动。
例如，工商企业接到订货单，便有开发货单、发票、记账等信息处理活动，它们统称为订单处理，这就是一项事务。
再如政府经济行政管理部门接到下级的请示报告，经过调查研究和有关主管人员分析、开会讨论，协调不同意见，做出统一决定，作为对下级的指示，这也是一种事务，可称之为请示报告的处理。
学生选课系统数据流图数据流图是一种图形化的工具，用于描述系统中数据的流动和处理过程。
学生选课系统是一个常见的教育管理系统，用于管理学生的选课信息和课程安排。
下面是一个标准格式的学生选课系统数据流图的详细描述。
1. 上下文图：上下文图是数据流图的最高级别，用于描述系统与外部实体之间的交互。
在学生选课系统中，外部实体可以包括学生、教师、管理员等。
上下文图显示了系统与这些外部实体之间的数据流和处理过程。
2. 系统概述：学生选课系统是一个在线的教育管理系统，旨在匡助学生方便地选择课程并管理他们的选课信息。
系统的主要功能包括学生注册、课程查询、选课、退课和成绩查询等。
3. 数据流：在学生选课系统中，存在以下数据流：- 学生信息流：用于传输学生的个人信息，如学生姓名、学号、专业等。
- 课程信息流：用于传输课程的相关信息，如课程名称、课程编号、学分等。
- 选课请求流：用于传输学生的选课请求，包括学生选课的课程编号。
- 退课请求流：用于传输学生的退课请求，包括学生退课的课程编号。
- 成绩信息流：用于传输学生的成绩信息，包括学生的课程成绩和绩点。
4. 处理过程：学生选课系统中的主要处理过程包括以下几个步骤：- 学生注册：学生在系统中注册账号，提供个人信息，并生成学号。
- 课程查询：学生可以根据自己的需求查询系统中提供的课程信息，包括课程名称、授课教师、上课时间等。
- 选课：学生根据课程查询结果，选择自己感兴趣的课程，并提交选课请求。
- 退课：学生可以在选课期间选择退课，提交退课请求。
- 成绩查询：学生可以查询自己的课程成绩和绩点。
5. 数据存储：学生选课系统中的数据存储包括以下几个部份：- 学生信息库：存储学生的个人信息，如学生姓名、学号、专业等。
- 课程信息库：存储课程的相关信息，如课程名称、课程编号、学分等。
- 选课记录库：存储学生的选课记录，包括学生选课的课程编号和选课时间。
- 成绩记录库：存储学生的成绩信息，包括学生的课程成绩和绩点。
数据流图分析1)数据流图制造企业供应管理主要包括领料计划、采购计划、出入库管理和合同管理等四方面的工作。
领料计划负责接收领料员（领料部门）的领料申请，根据现有可用库存等情况审批领料申请单、制订物料发放计划；采购计划负责接收采购申请等物料需求，根据经验等制订采购计划；出入库管理负责接收领料单、入库申请单，进行出库、入库登记等工作；合同管理负责接收、保存合同文档和合同执行、统计分析等工作。
这几项工作之间的数据处理关系如图8.1所示。
图8.1 供应管理问题第一层数据流图在图8.1所示的第一层数据流图的基础上，可用利用分层数据流图对供应管理的各项工作具体进行细化。
图8.2~8.5分别是关于领料计划、采购计划、出入库管理和合同管理的数据流图。
图8.2 供应管理问题第二层数据流图－领料计划图8.3 供应管理问题第二层数据流图－采购计划图8.4 供应管理问题第二层数据流图－出入库管理图8.5 供应管理问题第二层数据流图－合同管理2)实体联系图用实体联系图描述的图8.1~8.5的中的各个数据存贮之间的关系如图8.6所示。
其中各个实体的属性如图8.7~8.20所示。
图8.6 供应管理问题实体联系图图8.7 领料计划单－实体属性图8.8 物料主文件－实体属性图8.9 采购计划单－实体属性图8.10 入库单－实体属性图8.11 出库单－实体属性图8.12 采购申请单－实体属性图8.13 采购合同－实体属性图8.14 采购员档案－实体属性图8.15 领料员档案－实体属性图8.16 物料代用目录－实体属性图8.17 分供方档案－实体属性图8.18 采购费用单－实体属性3)数据流说明(D01) 领料申请单＝领料员＋密码＋物料代码＋需求日期＋数量(d01.01) 领料员＝编号(d01.01.01) 编号＝"00".."99"(d01.02) 物料代码＝1{"英文字母数字"}20(d01.03) 需求日期＝日期(d01.03.01) 日期＝"1900".."9999"＋"01".."12"＋"01".."31"(d01.04) 数量＝"000000.00".."999999.99"(D02) 领料审批单＝领料员＋物料代码＋申领日期＋审批结果＋(批准数量)＋(代用物料代码＋代用依据)＋领料计划员＋签发日期(d02.04) 审批结果＝ ["同意"|"不同意"](d02.07) 代用依据＝审批人＋审批日期(d02.07.01) 审批人＝领料员(d02.08) 领料计划员＝编号(D03) 领料单＝领料计划(d03.01) 领料计划＝领料员＋申领物料代码＋申领日期＋签发日期(D04) 缺货单＝领料单＋"缺货"(D05) 入库申请单＝采购员＋物料代码＋采购计划员＋计划日期＋数量＋(单价＋运杂费)＋分供方(d05.01) 采购员＝编号(d05.03) 采购计划员＝编号(d05.06) 单价＝金额(d05.06.01) 金额＝"000000.00".."999999.99"(d05.07) 运杂费＝金额(d05.08) 分供方＝分供方编号(d05.08.01) 分供方编号＝"000000".."999999"(D06) 退货单＝采购员＋物料代码＋采购计划员＋计划日期＋["分供方不合格"|"物料不合格"](D07) 采购命令单＝采购员＋物料代码＋采购计划员＋计划日期＋需求日期＋需求数量＋验收标准(d07.07) 验收标准＝1{"汉字"}15(D08) 合同文档＝采购员＋分供方＋签订日期＋{合同记录}(d08.04) 合同记录＝物料代码＋数量＋单价＋交货日期＋验收标准＋运输方式＋特殊要求＋执行情况(d08.06) 运输方式＝1{"汉字"}15(d08.07) 特殊要求＝1{"汉字"}15(d08.08) 执行情况＝1{"汉字"}15(D09) 合同执行情况＝合同编号＋物料代码＋交货日期＋执行情况(D10) 无效申请单＝采购员＋物料代码＋采购计划员＋计划日期＋"无采购计划"(D11) 无效领料单＝领料单＋"无领料计划"(D12) 有效领料申请单＝领料申请单＋"有效"(D13) 可用库存＝数量(D14) 代用报告＝物料代码＋代用物料代码＋数量(D15) 代用审批单＝代用报告＋批准人＋批准日期(D16) 物料出库流量＝物料代码＋起始日期＋终止日期＋数量(D17) 物料入库流量＝物料代码＋起始日期＋终止日期＋数量(D18) 物料ABC类型＝物料代码＋["A"|"B"|"C"](D19) 报警物料＝{物料代码}(D20) 有效领料单＝领料单＋"有效"(D21) 采购费用申请＝采购员＋物料代码＋采购计划员＋计划日期＋数量＋单价＋运杂费(D22) 物料入库申请＝采购员＋物料代码＋采购计划员＋计划日期＋数量＋分供方(D23) 物料检验单＝采购员＋物料代码＋采购计划员＋计划日期＋数量＋分供方＋检验意见＋检验员＋检验日期(d23.07) 检验意见＝["合格"|"分供方不合格"|"物料不合格"](d23.08) 检验员＝1{"汉字"}4(D24) 采购合同＝合同编号＋合同文档(d24.01) 合同编号＝1{"数字"}10(D25) 合同统计报表＝[合同执行情况统计|合同资源统计|应付帐统计](d25.01) 合同执行情况统计＝{合同编号＋物料代码＋数量＋交货日期＋执行情况}(d25.02) 合同资源统计＝{物料代码＋数量＋交货日期}(d25.03) 应付帐统计＝{合同编号＋物料代码＋数量＋单价＋交货日期＋分供方}4)加工说明加工编号：1.1加工名称：领料申请单验收加工逻辑：根据领料员档案审查领料申请单的有效性。
数据流图（示例）
系统流图虽然在一定程度上表达了信息的流动和存储情况，但要想描述出信息流和数据从输入移动到输出的过程中所经受的变换，必须把信息的流动、加工、存储等过程流抽象出来，得出组织中信息流的综合情况，描述这种情况的就是数据流图。
数据流图是组织中信息运动的抽象，是管理信息系统逻辑模型的主要形式。
数据流图（DFD）是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。
在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程，具有直观、形象、易理解的优点。
数据流图有以下四种基本元素组成，它们的图形符号说明如下：
变换数据的处理数据的源点/终点
数据存储数据流
图1 数据流图的图形符号
1 系统顶层数据流图
图2 顶层数据流图
2系统0层数据流图
图3系统0层数据流图对图3中的数据流描述如下：
F1：用户信息
F2：课程相关数据
F3：测试题
F4：网络课件数据
F5：课程信息
F6：测试过程数据
F7：学生答案
F8：学生的学习及测试情况
F9：学习进度
F10：测试成绩
3 系统1层数据流图
图4系统1层数据流图（用户管理）对图4中的数据流描述如下：
F1：用户名，密码
F2：用户基本信息
F3：课程用户信息
F4：课程学生信息
F5：课程教师信息
图5系统1层数据流图（课程管理）
图6系统1层数据流图（在线测试过程控制）
图7系统1层数据流图（信息反馈）。
实验三数据流图与数据字典数据流图与数据字典是系统分析与设计过程中常用的工具，用于描述系统中的数据流动和数据存储。
本文将详细介绍数据流图和数据字典的概念、用途、标准格式以及编写方法。
一、数据流图数据流图（Data Flow Diagram，简称DFD）是一种图形化的工具，用于表示系统中数据的流动过程。
它由一系列的过程、数据流、数据存储和外部实体组成。
1. 概念- 过程（Process）：代表系统中的一个功能模块或者子系统，用圆角矩形表示，通常用动词短语命名。
- 数据流（Data Flow）：表示系统中数据的流动，用箭头表示，箭头指向数据流的方向，通常用名词短语命名。
- 数据存储（Data Store）：表示系统中数据的存储位置，用平行四边形表示，通常用名词短语命名。
- 外部实体（External Entity）：表示系统外部与系统进行数据交互的实体，用矩形表示，通常用名词短语命名。
2. 用途数据流图主要用于以下方面：- 描述系统的功能和数据流动过程，匡助分析人员理解系统的整体结构。
- 识别系统中的数据流、数据存储和过程，有助于发现系统中的问题和改进空间。
- 作为与用户和开辟人员沟通的工具，匡助他们共同理解系统需求和设计。
3. 标准格式数据流图的标准格式包括四个层次，分别是：0层数据流图、1层数据流图、2层数据流图和3层数据流图。
- 0层数据流图：也称为上下文图，用于表示系统与外部实体之间的交互关系。
它只包含一个过程，一个外部实体和相应的数据流，用于描述系统的整体概貌。
- 1层数据流图：用于进一步分解0层数据流图中的过程，将系统功能拆分成更小的模块。
它包含多个过程、外部实体和数据流，用于描述系统的主要功能。
- 2层数据流图：用于进一步分解1层数据流图中的过程，将系统功能进一步细化。
它包含多个更小的过程、外部实体和数据流，用于描述系统的详细功能。
- 3层数据流图：用于进一步分解2层数据流图中的过程，将系统功能拆分成最小的功能模块。
实验三数据流图与数据字典数据流图是一种图形化的工具，用于描述系统中的数据流动和处理过程。
它可以帮助我们理解系统内部的数据流动方式，并且可以用来分析和设计系统。
数据字典是一种文档，用于记录系统中使用的所有数据项的定义和属性。
在本次实验中，我们将学习如何绘制数据流图，并创建相应的数据字典。
我们将以一个图书馆管理系统为例，来说明数据流图和数据字典的应用。
首先，我们需要定义系统中的各个角色和功能。
在这个例子中，我们有图书管理员、读者和图书馆系统这三个角色。
图书管理员负责管理图书的借还过程，读者可以借阅图书，而图书馆系统则负责管理图书的信息和借还记录。
接下来，我们可以开始绘制数据流图。
数据流图由一系列的方框和箭头组成，方框代表各个处理过程，箭头代表数据的流动。
在我们的图书馆管理系统中，我们可以绘制以下几个方框来表示各个功能模块：1. 图书借阅：这个方框表示读者借阅图书的过程。
数据流进入这个方框，表示读者提交借书请求，然后系统会检查图书是否可借，并更新图书的借阅记录。
最后，系统会生成借书通知单，通知读者可以去借阅图书。
2. 图书归还：这个方框表示读者归还图书的过程。
数据流进入这个方框，表示读者提交还书请求，然后系统会检查图书的借阅记录，并更新图书的状态。
最后，系统会生成还书通知单，通知读者图书已成功归还。
3. 图书管理：这个方框表示图书管理员管理图书的过程。
数据流进入这个方框，表示管理员需要查询或更新图书的信息。
管理员可以添加新书、删除旧书、修改图书信息等。
4. 读者管理：这个方框表示图书管理员管理读者信息的过程。
数据流进入这个方框，表示管理员需要查询或更新读者的信息。
管理员可以添加新读者、删除旧读者、修改读者信息等。
5. 借阅记录管理：这个方框表示图书管理员管理借阅记录的过程。
数据流进入这个方框，表示管理员需要查询或更新借阅记录的信息。
管理员可以查看借阅记录、生成统计报表等。
以上是我们根据图书馆管理系统的功能，绘制的数据流图。
软件工程之数据流图(DFD) 数据库分析与设计主讲：邓少勋一．软件工程之数据流图和数据字典 (1)1.1数据流图的基本成分 (1)1.2数据流图的基本原则 (1)1.3 DD(Data Dictionary)数据字典 (2)1.3.1 数据字典的内容以及格式 (2)1.3.2 数据字典条目 (2)二．数据库分析与设计 (3)2.1 某公司销售信息管理系统需求描述 (3)2.2 系统数据库概念模型设计 (4)2.2.1 提炼需求描述得到实体型 (4)2.2.2 三个实体型之间的实体联系图(E-R图) (4)2.3 系统数据库逻辑模型设计 (4)2.3.1 E-R图向关系数据库转换思想 (4)2.3.2 销售信息管理系统逻辑模型设计 (8)一．软件工程之数据流图和数据字典1.1数据流图的基本成分数据流图主要由4种成分(加工、数据流，数据存储文件、数据源点或汇点)组成，如表1.1所示：表1.1数据流图基本成分1.2数据流图的基本原则1.在单张DFD中，必须满足以下原则：●一个加工的输出数据流不能与输入数据流同名，即使它们的组成成分相同(流进和流出存储文件的数据流除外);●数据流必然有一头是加工,数据流不能存在于外部实体与外部实体之间，也不能存在于外部实体和数据存储文件之间;●保持数据守恒。
一个加工所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者是通过该加工能产生的数据；●每个加工必须既有输入数据流，又有输出数据流；●所有的数据流都必须以一个加工开始，或以一个加工结束（数据流存在于加工与加工之间，加工与数据存储文件之间，加工与外部实体之间）。
●流向/流出数据存储文件的数据流名可以省略不写。
2.在父图与子图之间，必须满足以下原则●保持父图与子图的平衡。
也就是说，父图中某加工的输入(输出)数据流中的数据必须与它的子图的输入(输出)数据流中的数据在数量和名字上相同;●加工细节隐藏。
根据抽象原则，在画父图时，只需画出加工和加工之间的关系，而不必画出各个加工内部的细节;●均匀分解。
应该使一个数据流图中的各个加工分解层次大致相同。
3.其它应该注意的原则●简化加工间关系。
在数据流图中，加工间的数据流越少，各加工就越相对独立，所以应尽量减少加工间输入输出数据流的数目；●适当地为数据流、加工、文件、源/宿命名，名字应反映该成分的实际意义，避免空洞的名字;●忽略枝节。
应集中精力于主要的数据流，而暂不考虑一些例外情况、出错处理等枝节性问题;●表现的是数据流而不是控制流;●在整套数据流图中，每个文件必须既有读文件的数据流又有写文件的数据流，但在某一张子图中可能只有读没有写或者只有写没有读。
例：根据数据流图的设计原则(子图)，阅读下图所示的数据流图，找出其中的错误之处。
答案：错误1：外部实体A和B之间不能存在数据流；错误2：外部实体A和数据存储H之间不能存在数据流；错误3：加工2的输入/输出数据流名字相同；错误4：加工4只有输入，没有输出；错误5：加工5只有输出，没有输入。
图1.1带错误的部分数据流图注意：一个加工只有输入数据流，没有输出数据流，称为“黑洞”现象，而只有输出流没有输入数据流则称为“奇迹”，无法从输入数据流经过加工得到输出数据流称为“灰洞”。
1.3 DD(Data Dictionary)数据字典数据字典(Data Dictionary,简称DD)就是用来定义数据流图中的各个成分的具体含义的，它以一种准确的、无二义性的说明方式为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述。
它和数据流图共同构成了系统的逻辑模型，是需求规格说明书的主要组成部分。
1.3.1 数据字典的内容以及格式在定义数据流或数据存储组成时，使用的符号如表1.2：图1.2数据字典中的符号举例：定义数据流组成和数据项。
机票=姓名+日期+航班号+起点+终点+费用姓名={字母}航班号=“Y7100”..“Y8100”终点=[上海|北京|西安]1.3.2 数据字典条目数据字典有以下四类条目：数据流、数据项、数据存储、基本加工。
二．数据库分析与设计在数据库分析与设计中，主要涉及到概念模型、逻辑模型和物理模型的分析与设计。
概念模型在考题中主要集中体现为对实体联系图(E-R图)的考查，而逻辑模型则主要考查关系型数据库，物理模型是数据库在计算机中的实际物理存储形式，无须人为干预！2.1 某公司销售信息管理系统需求描述甲公司的经营销售业务目前是手工处理的，随着业务量的增长，准备采用关系数据库对销售信息进行管理。
经销业务的手工处理主要涉及三种表：订单、客户表和产品表。
在日常工作中，三表样式如下：图2.1实际工作中的工作表为了用计算机管理销售信息，甲公司提出应达到以下要求：产品的单价发生变化时，应及时修改产品表中的单价数据。
客户购货计价采用订货时的单价。
订货后，即使单价发生变化，计算用的单价也不变。
2.2 系统数据库概念模型设计2.2.1 提炼需求描述得到实体型分析图2.1中客户表，很容易得出其对应的实体型为：客户(客户代码，客户名，地址，电话) ，其中“客户代码”为主码。
分析图2.1中产品表，很容易得出其对应的实体型为：产品(产品代码，产品名称，单价) ，其中“产品代码”为主码。
分析图2.1中订单表发现，此表比客户表和产品表都复杂得多，而初学者往往拿到这种表束手无策！实际上此表可一分为二，可以分为如下两部分：A部分和B部分，分别对应此表上数据量为1和为多的两部分图2.2订单表可分为两部分在图2.2中，把A部分（数量为1部分）单独提取出来，成为订单实体型：订单(订单号，订货日期，总金额)，其中“订单号”为主码。
注意：A部分中的“客户代码”和“客户名”不属于订单实体的属性，而应是客户实体型的属性！故在订单实体型中没有“客户代码”和“客户名”两个属性。
对于B部分，“产品代码”、“产品名称”，“单价”都属于产品实体型属性，至于“订货序号”、“数量”和“小计”则是订单上订购产品的相关订购细节，即不能单属于订单，也不能单属于产品，而应该归属于订单和产品之间的订购明细关系(但是此订单明细不属于实体型的范围，故其不对应具体实体型)。
三张表分别对应的三个实体型图为：图2.3订单实体型图2.4客户实体型图2.5产品实体型2.2.2 三个实体型之间的实体联系图(E-R图)从2.1节中“订单”表可以看出“订单”和“产品”两实体型之间的关系是多对多的关系，而“客户”和“订单”两实体型之间是1对多的关系。
图2.6三实体型E-R图思考：在图2.1中，“产品代码”、“产品名称”等是属于订单明细的，但为什么在如图2.6所示图中，“订单明细”没有“产品代码”、“产品名称”等属性？2.3 系统数据库逻辑模型设计在数据库的分析与设计工作中，概念模型是从用户的角度出发而对信息世界进行数据建模，此设计阶段主要是产出完好的实体联系图，即E-R图。
而逻辑模型设计阶段主要工作是把实体联系图转换为对应的关系数据库模型。
但要注意，逻辑模型除了关系数据库模型外，还有其他的种类，如网状数据库模型，层次数据库模型等，而关系数据库模型是当今主流使用的数据库模型。
2.3.1 E-R图向关系数据库转换思想根据E-R图中实体型之间的关系，E-R图向关系数据库的转换遵循以下原则：1.一个实体型转换为一个关系模型，实体的属性就是关系的属性，实体的键就是关系的键。
如图2.7是一个实体型图（假设属性1为主属性，即为码），则将其转换为关系模式如下：图2.7实体型A对应的关系模式为：实体A（属性1，属性2，属性3）2.一个联系是否要转换为一个关系模式，这取决于与该联系相关的实体之间的对应关系，不同的对应关系，遵循不同的转换原则：（1）两个实体型之间的关系为1：1关系这种情况下，可把相关的实体型合并成一个实体型，然后再转换为对应的关系模式，实体型之间的联系不用转换为关系模式。
即是1：1的对应关系至少需要一张关系表就够了。
图2.81对1联系图在图2.8中，实体型A和实体型B之间的对应关系为1：1，这种情况下中间的联系名不用转换为关系模式，而直接把实体型A和实体型B合并且转换为一个关系模式，这个关系模式名可为实体型A，也可以为实体型B，还可起名为其他同等意义的名字。
当然也可以把两个实体型单独转换为对应的关系模式，这种情况下有两个关系模式，但是由于这个两个关系模式的主键是一样的，所以可以合并为一个关系模式。
故图2.8对应的关系模式为（假设此E-R图中属性1为主属性）：实体A（属性1，属性2，属性3，属性4，属性5）总之，把实体型之间对应关系为1：1的E-R图转换为对应的关系模式的时候，至少需要一个关系模式，即至少需要一张二维关系表，联系不必转换为关系模式。
（2）两个实体型之间的关系为1：m关系如图2.9所示，实体型A与实体型B的关系为1：m的关系，假设“属性1”为实体型A的码，“属性4”为实体型B的码。
图2.91对多联系图这种情况下，实体型A和实体型B分别单独转换为两个关系模式。
除此，由于要体现两个关系模式之间的“1：m”的参照关系，所以还要把“1：m”联系中“1”端的主键复制到“m”一端的关系模式里面去并作为外键，而对于这个参照关系来说，实体型A转换的关系模式称为主键表，而实体型B转换的关系表称为外键表。
至于两个实体型之间的联系则无需转为为关系模式。
所以在两个实体型之间的对应关系为1对多的情况下，把E-R转换为关系模式至少需要2张关系二维表。
如图2.9对应的关系模式为：实体A（属性1，属性2，属性3）实体B（属性4，属性5，属性6，属性1）在以上的关系模式“实体型B”中，“属性4”是主键，“属性1”是外键（参照到主键表“实体型A”表的主键“属性1”）。
（3）两个实体型之间的关系为m：n关系如图2.10，实体型A与实体型B的关系为m：n的关系，假设“属性1”为实体型A的码，“属性4”为实体型B的码。
联系自己也有一个属性“属性7”。
图2.10多对多联系图由第（1）、（2）可知，1对1、1对多的E-R图可轻松地转换为对应的关系模式。
在关系数据库中，目前也只能实现二维表之间关系为1对1和一对多这两种情况，不能直接实现多对多的关系。
故m：n的实体关系图不能直接转换为关系模式，而必须先把一个“m：n”关系先转换为对应的两个“1：m”关系，然后再把这两个“1：m”关系按照第（2）的原则转换为对应的关系模式。
这里首先把图2.10个多对多的关系转换为两个一对多的关系，如图2.11示：图2.11一个多对多对应的两个一对多联系图从图2.11以看出来，图2.10多对多的“联系名”已经被转换为一个实体型（在图2.10中是棱形表示，而在图2.11中则为矩形表示），而新加入了两个新联系“新联系1”和“新联系2”，需要注意的是实体型A和实体型B分别位于“1”的一段，而新实体型“联系名”位于“多”的一端。
