数据库原理及应用

(5)局部视图9.5与图9.13中的“订单”实体为同一个实体，集成后如图9.14所示。
（6）局部视图9.9与图9.14中“订单”实体为同一个实体，集成后如图9.15所示。
（7）局部视图9.6与图9.15中“发票”实体为同一实体，集成后如图9.16所示
9.1.3逻辑设计
逻辑设计是将概念设计得到的E-R模型映射为DBMS的逻辑模型。对于关系型数据库设计来说，符合E-R图的数据可以用表的集合来表示。根据前面概念设计得到的集成视图9.16，并利用实体到关系模式以及联系到关系模式的映射规则，可以得到以下一组关系模式集，然后利用关系规范化理论判断关系属于第几范式，如果需要，则可再对关系模式进行优化处理。
“职工”实体：
职工编号、姓名、性别、出生年月、地址、办公电话、住宅电话、E-mail、职务：发货方式编号、发货方式
2．视图集成
集成策略为：采用两两集成策略，即每次只集成两个局部视图。
（1）局部视图9.3和图9.4中的“订单细节”实体是同一个实体。在集成时只需保留一个。另外，“产品”实体和“订单”实体是完全不同的两个实体，不存在域的相关性，集成视图中全部保留，集成后如图9.10所示。
试根据工资管理的要求，进行数据库的概念设计和逻辑设计。
9.3.1需求分析
工资管理主要根据每个职工每个月的考勤情况来计算工资发放。工资管理系统的部分数据流图如图9.28所示。
图9.28工资管理系统的顶层数据流图
工资管理过程中涉及到的数据有如下几种：
职工数据
奖金数据
假期数据
病假数据
扣除数据
工资历史数据
工资细节数据
图9.9
（4）给实体及联系加上描述属性，实体和联系的属性应该根据具体应用进行识别。同一个实体，在不同的应用场合可能拥有属性不同。凡是应用中需要用到的属性都必须考虑，而应用中不会用到的属性则不必考虑。
“客户”实体：
客户编号、客户名称、邮编、电话号、传真号、银行账号、Email
“产品”实体：
产品编号、产品名、型号、规格、单价、重量、现有库存量
订单数据
客户数据
职工数据
发票数据
发货数据
产品数据
本例的处理需求有以下几种：
查询每种产品的订购情况
查询订单上产品的发货情况
查询开出去的发票情况
查询每份订单的执行情况
概念设计
1．局部视图设计
（1）确定局部视图的设计范
（2）确定实体及实体的主键（主标识符）。
产品：存放所有可以订购的产品信息。主键为“产品编号”。
图9.10局部视图9.3和图9.4的集成
（2）局部视图9.7和图9.10中的“订单细节”实体是同一个实体，集成后如图9.11所示。
（3）局部视图9.8和图9.11中的“发货”实体是同一个实体，集成后如图9.12所示。
（4）局部视图9.2和图局部视图9.12中的“订单”实体为同一个实体，集成后如图9.13所示。
二、例举现实生活中的几个数据库应用实例：
1、客户订购登记管理
现有一个公司希望为其客户订购行为建立一个数据库。如果一个客户可以有一份或多份订单，每份订单可以订购一种或多种商品。每份订单有一张发票，发票可以通过多种方式来支付购买款，如支票、信用卡或者现金。处理这个客户订购等级的职工的名字要被记录下来。
部门工作人员负责整理订单并根据库存情况处理订单。如果库存中有订单上的产品，就可以直接发货，发货方式也有多种；如果库存中没有订单上的产品，就不需要登记或者订购其他产品。
主键：订单编号+产品编号
函数依赖集F：
{订单编号+产品编号}→{单价，订货数量}
“订单细节”关系满足第三范式。
5．发票（发票编号，开票日期，付款日期，订单编号，客户编号，金额，付款方式编号）
主键：发票编号
候选键：订单编号
外键：订单编号、客户编号、付款方式编号
函数依赖集F：（略）
“发票”关系满足第三范式。
意义：数据库管理系统是一个复杂、较大的程式，它好比是一个图书管理系统，不仅可以储存和取得数据，并且可以定义数据格式。
数据库则是一群经过整合的数据，以一种共同的格式储存，以达到数
据共享、减少数据重复的目的。数据库包含了多个表以及表中各种属性的特性，是一种工作环境能减少数据的冗余并提高数据的完整性。
发展趋势：数据库信息量的使用频度已经成为衡量一个国家信息化程度的重要标志。在我国70年代——数据库技术引入我国，80年代——数据库技术广泛普及，90年代——我国数据库建设飞速发展。当前数据库发展还有两股重大的势头：1、数据库用户急剧增多；2、数据库无论是逻辑级、物理级还是整个结构级，其技术发展都很快。市场对数据库的需要量猛增，促进了数据库科研工作的发展，并不断研究出来越来越好的数据库技术。主要发展趋势为：1、信息特性和来源的变化；2、应用领域的变化；3、相关技术的发展；4、当前若干研究热点，包括文本、数据、代码、数据流的集成。
发货方式编号，引用了“发货方式”关系中的发货方式编号；
职工编号，引用了“职工”关系中的职工编号。
函数依赖集F：
订单编号→{客户编号，订货日期，交货日期，发货方式编号，职工编号，执行状态}
“订单”关系满足第三范式。
注意：订单中的“执行状态”用来表示订单是否已执行完毕，即产品全部发出且钱也已全部到款。
4．订单细节（订单编号，产品编号，单价，订货数量）
图9.6
⑥“发货”实体与“订单细节”实体通过发货打包发生联系。每个订单细节可能对应多次发货，而每次发货只对应一个订单细节。因此，“发货”实体和“订单细节”实体之间是一对多联系。
图9.7
⑦发货方式是发货的组成部分，故必存在联系。
图9.8
⑧“订单”实体和“发票”实体通过开发票发生联系。，每份订单开一张发票，而每张发票只对应一份订单。因此，“订单”实体和“发票”实体之间是一对一联系。
工资管理的处理需求主要有以下几种情况。
查询每个职工的所有工资情况。
查询职工的支付方式或银行编号
查询职工的奖金、假期、病假以及扣除情况。
订单：存放所有与客户签订的订单，主键为“订单编号”。
发票：存放所有开出的发票，主键为“发票编号”。
职工：存放职工基本信息，主键为“职工编号”。
发货：存放订购产品的发货情况，主键为“发货编号”。
客户：存放客户基本信息，主键为“客户编号”。
发票：实体中的付款方式是多值的，主键是“付款方式编号”。
发货：实体中发货方式也是多值的，主键是“发货方式编号”。
主键：发货编号
外键：订单编号、产品编号、发货方式编号
函数依赖集（略）
“发货”关系满足第三范式。
7．职工（职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，E-mail，职务，职称）
主键：职工编号
候选键：E-mail
函数依赖集F（略）
“职工”满足第三范式。
8．付款方式（付款方式编号，付款方式）
2/工资管理部门希望建立一个数据库来管理职工的工资。要计算职工的工资，就需要考虑不在休假日期以内的假期、工作期间的病假时间、奖金和扣除的部分。系统必须指明给每个职工发薪水的方式，随着时间的推移，发薪水的方式可能会发生改变。
大多数的职工是通过银行卡来结算工资的，但是也有一部分人使用现金或支票。如果是通过银行卡，就需要知道账号和银行地址。付款方式只可能是一种方式。另外，还有几种原因需要扣除工资。例如，个人所得税、养老保险、医疗保险、公积金等。
订单：主键为“订单编号”。
（3）定义实体间的联系，所涉及到的联系一般有以下几种。
①“客户”和“订单”通过提交发生联系。
图9.2
②“产品”实体和“订单细节”实体通过订购产品发生联系。
图9.3
③“订单细节”是“订单”实体的组成部分，故必存在联系。一份订单可以订购多种产品，也就是可以有多个订单细节，而每个订单细节只对应一份订单。因此，二者是“一对多”联系。
需求分析
根据数据库设计步骤，在进行数据库设计之前应该先进行用户需求分析，主要是搞清楚用户的数据需求和处理需求。如图9.1所示是客户订购登记数据流图。
产品发货台账发票
客户信息订单
图9.1客户订购登记数据流图
经过分析，了解到公司主要是对客户的订购行为进行管理，客户订购登记过程涉及到的数据有以下几种（数据需求）：
2．产品（产品编号，产品名，型号，规格，单价，重量，现有库存量）
主键：产品编号
函数依赖集F：
产品编号→{产品名，型号，规格，单价，重量，现有库存量}。
显然，“产品”关系满足第三范式。
3.订单（订单编号，客户编号，订货日期，交货日期，发货方式编号，职工编号，执行状态）
主键：订单编号
外键：客户编号，引用了“客户关系”中的客户编号；
图9.4
④“职工”实体通过处理订单和“订单”实体发生联系。每个职工可以处理多份订单，而每份订单只能由一个职工处理。因此，二者存在“一对多联系。
图9.5
⑤付款方式是发票的组成部分，故必存在联系。每张发票对应一种付款方式，而每种付款方式可以用于不同的发票中。因此，“付款方式”实体和“发票”实体之间是一对多联系。
1.客户（客户编号，客户名称，邮编，电话号，传真号，银行账号，E-mail）
主键：客户编号
候选键：电话号、传真号、银行账号、E-mail
函数依赖集F：
客户编号→{客户名称，邮编，电话号，传真号，银行账号，E-mail}，
电话号→{客户编号，客户名称，邮编，传真号，银行账号，E-mail}，
传真号→{客户编号，客户名称，邮编，电话号，银行账号，E-mail}，
主键：付款方式编号
函数依赖集F（略）
满足第三范式
9.发货方式（发货方式编号，发货方式）
主键：发货方式编号
函数依赖集F（略）
满足第三范式
至此，所有关系都满足较高的范式要求，故客户订购登记管理的数据库设计是合理的。