1、数据库应用示例,现有一个公司希望为其客户订购行为建立一个数据库。如果一个客户可以有一份或多份订单，每份订单可以订购一种或多种商品。每份订单有一个发票，可以通过多种方式来支付，例如支票，信用卡或者现金。处理这个客户订购登记的职工的名字要被记录下来。部门工作人员负责整理订单并根据库存情况处理订单。如果订单上的产品在库存中有，就可以直接发货，发货方式也有多种；如果订单上的产品在库存中没有，就不需要登记或者订购其它产品。请根据上述要求进行数据库的概念设计和逻辑设计。,客户订购登记,一、需求分析,1客户订购登记,客户订购登记数据流图,客户订购登记过程涉及到的主要数据有：订单数据客户数据职工数据发票数据发
2、货数据产品数据,1客户订购登记,1客户订购登记,二、概念设计,1、局部视图设计 （1）确定局部视图的设计范围 （2）确定实体及实体的主键 根据所提供的信息，客户订购登记管理涉及到的实体有：产品，主键：产品编号；订单，主键：订单编号；发票，主键：发票编号；职工，主键：职工编号；发货，主键：发货编号；客户，主键：客户编号。,1客户订购登记,由于发票实体中的付款方式是多值的，即可以为支票/信用卡/现金。所以将付款方式单独作为一个实体考虑，主键是付款方式编号。发货实体中发货方式也是多值的，也应该将发货方式单独作为一个实体考虑，主键是发货方式编号。另外，每份订单可以订购多个产品。为了避免数据冗余，我们将
3、订单中的产品订购信息单独作为一个订单细节实体考虑，主键是订单编号产品编号；而订单中的其他数据作为一个订单实体，主键仍为订单编号。,其他问题的考虑：,1客户订购登记,（3）定义实体间的联系客户实体和订单实体通过提交订单发生联系。每个客户可以提交多份订单，而每份订单只对应一个客户。因此，客户实体和订单实体之间是一对多联系，如图所示。,产品实体和订单细节实体通过订购产品发生联系。每个订单细节可以订购一种产品，而每种产品可以被不同的订单订购。因此，产品实体和订单细节实体之间是一对多联系，如图所示。,1客户订购登记,1客户订购登记,订单细节实体是订单实体的组成部分，故必存在联系。一份订单可以订购多种产品
4、，也就是可以有多个订单细节，而每个订单细节只对应一份订单。因此，订单实体和订单细节实体之间是一对多联系，如图所示。,1客户订购登记,职工实体通过处理订单和订单实体发生联系。每个职工可以处理多份订单，而每份订单只能由一个职工处理。因此，职工实体和订单实体之间是一对多联系，如图所示。,1客户订购登记,付款方式是发票的组成部分，故必存在联系。每张发票对应一种付款方式，而每种付款方式可以用于不同的发票中。因此，付款方式实体和发票实体之间是一对多联系，如图所示。,1客户订购登记,发货实体与订单细节实体通过发货打包发生联系。每个订单细节对应多次发货，而每次发货只对应一个订单细节。因此，发货实体和订单细节实
5、体之间是一对多联系，如图所示。,1客户订购登记,发货方式是发货的组成部分，故必存在联系。每个发货对应一种发货方式，而每种发货方式可以用于不同的发货中。因此，发货方式实体和发货实体之间是一对多联系，如图所示。,1客户订购登记,订单实体和发票实体通过开具发票发生联系。每份订单开具一张发票，而每张发票也只对应一份订单。因此，订单实体和发票实体之间是一对一联系，如图所示。,1客户订购登记,（4）给实体及联系加上描述属性,客户实体的描述属性有： 客户编号，客户名，邮编，电话号，传真号，银行帐号。产品实体的描述属性有： 产品编号，产品名，型号，规格，单价，重量。订单实体的描述属性有： 订单编号，客户编号，
6、订货日期，交货日期，发货方式编号，职工编号，执行状态。,1客户订购登记,订单细节实体的描述属性有： 订单编号，产品编号，订货数量。发票实体的描述属性有： 发票编号，开票日期，付款日期，订单编号，客户编号，付款方式编号。发货实体的描述属性有： 发货编号，订单编号，产品编号，数量，发货日期，发货方式编号，完成状态，职工编号。,1客户订购登记,职工实体的描述属性有： 职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，EMAIL，职务，职称。付款方式实体的描述属性有： 付款方式编号，付款方式。 发货方式实体的描述属性有： 发货方式编号，发货方式。,1客户订购登记,3视图集成 集成策略：采用两两
7、集成策略，即每次只集成两个局部视图。该例中，假设不存在冲突问题。,1客户订购登记,1客户订购登记,1客户订购登记,二、逻辑设计,客户（客户编号，客户名，邮编，电话号，传真号，银行帐号） 主键：客户编号。 候补键：电话号，传真号，银行帐号。 函数依赖集F： 客户编号客户名，邮编，电话号，传真号，银行帐号， 电话号客户编号，邮编，传真号，银行帐号，,1客户订购登记,传真号客户编号，客户名，邮编，电话号，银行帐号， 银行帐号客户编号，客户名，邮编，电话号，传真号 虽然，客户编号电话号，电话号传真号，但由于电话号客户编号也成立，所以，客户编号传真号不是传递函数依赖。客户关系中不存在非主属性与候选键之间
8、的部分与传递函数依赖，所以客户关系满足第3范式。,1客户订购登记,产品（产品编号，产品名，型号，规格，单价，重量） 主键：产品编号。 函数依赖集F： 产品编号产品名，型号，规格，单价，重量。产品关系不存在非主属性与候选键之间的部分与传递函数依赖，所以产品关系满足第3范式。,1客户订购登记,订单（订单编号，客户编号，订货日期，交货日期，发货方式编号，职工编号，执行状态） 主键：订单编号。 外键：客户编号，引用了客户关系中的客户编号；发货方式编号，引用了发货方式关系中的发货方式编号；职工编号，引用了职工关系中的职工编号。 函数依赖集F： 订单编号客户编号，订货日期，交货日期，发货方式编号，职工编号
9、，执行状态。订单关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以订单关系满足第3范式。,1客户订购登记,订单细节（订单编号，产品编号，订货数量） 主键：订单编号产品编号。 函数依赖集F： 订单编号，产品编号订货数量。订单细节关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以订单细节关系满足第3范式。,1客户订购登记,发票（发票编号，开票日期，付款日期，订单编号， 客户编号，付款方式编号） 主键：发票编号。 候选键：订单编号。 外键：订单编号，引用了订单关系中的订单编号；客户编号，引用了客户关系中的客户编号；付款方式编号，引用了付款方式关系中的付款方式编号。 函数依赖集F： 发
10、票编号开票日期，付款日期，订单编号，客户编号，付款方式编号， 订单编号发票编号，开票日期，付款日期，客户编号，付款方式编号。发票关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以发票关系满足第3范式。,由于发票与订单之间是1：1联系，且都是强制性的，所以也可与订单文件合并,1客户订购登记,发货（发货编号，数量，发货日期，订单编号， 产品编号，发货方式编号，完成状态，职工编号） 主键：发货编号。 外键：订单编号，引用了订单关系中的订单编号；产品编号，引用了产品关系中的产品编号；发货方式编号，引用了发货方式关系中的发货方式编号。 函数依赖集F： 发货编号数量，发货日期，订单编号，产品编号，
11、发货方式编号，完成状态，职工编号。发货关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以发货关系满足第3范式。,1客户订购登记,职工（职工编号，姓名，性别，出生年月，地址， 办公电话，住宅电话，EMAIL，职务，职称） 主键：职工编号。 候选键：EMAIL。 函数依赖集F： 职工编号姓名，性别，出生年月，地址，办公电话，住宅电话，EMAIL，职务，职称， EMAIL职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，职务，职称。职工关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以职工关系满足第3范式。,1客户订购登记,付款方式（付款方式编号，付款方式） 主键：付款方式编
12、号。 函数依赖集F： 付款方式编号付款方式。付款方式关系满足第3范式。,1客户订购登记,发货方式（发货方式编号，发货方式） 主键：发货方式编号。 函数依赖集F： 发货方式编号发货方式。发货方式关系满足第3范式。所有关系都满足较高的范式要求，故客户订购登记管理的数据库设计是合理的。,2 学生住宿管理,一个大学的后勤部门希望建立一个数据库来管理学生宿舍的分配。凡是需要住宿的学生都要填写一个申请表，表中有学生的信息情况和要申请的宿舍类型以及租用时间。学生可以租用一个厅室的一个房间或者是学生公寓。厅室只能提供单独的房间，房间有房间号、住宿号以及月租金。住宿编号唯一地决定了后勤部门控制的厅室中的每个房间
13、，以便租给学生使用。每个厅室由后勤部门的一个职工管理。后勤部门也提供公寓给学生租用，每个房间有一个唯一的公寓编号。这些公寓房间是已经装修好的而且提供单个房间给3个、4个或者是5个学生一起住。公寓中的每个床位都有月租金、房间编号和住宿编号。住宿编号唯一地确定了所有学生公寓中的可用房间，在房间租给学生时使用。每个公寓由后勤部门的几个职工共同管理。在每个新的学年开始，签订新的租用合同，最少的租用时间为一个学期，最多的是一年。学生要交一个学年的住宿费用，然后每个学期都有一个发票。如果学生在一个规定的日期之前没有交费，则会收到两封提示交费的信。请针对学生住宿问题，进行数据库的概念设计和逻辑设计。,2 学
14、生住宿管理,需求分析,学生住宿管理的部分数据流图,2 学生住宿管理,学生住宿管理过程中涉及到的数据有： 租用合同 公寓 厅室 发票 学生 职工 欠款提示,2 学生住宿管理,客户订购登记的处理需求有： 查询每种产品的订购情况 查询订单上产品的发货情况 查询开出去的发票情况 查询每份订单的执行情况 ,2 学生住宿管理,概念设计一、局部视图设计 （1）确定局部视图的设计范围在该应用中，设计的范围主要涉及到提供给学生的租房信息、学生租用信息、学生租房的交费信息等。 （2）确定实体及实体的主键,2 学生住宿管理,学生住宿管理涉及到的实体有： 租用合同，存放所有租房学生的租用合同。主键：租用合同编号 公寓
15、，存放所有可租用的公寓信息。主键：公寓编号 厅室，存放所有可租用的厅室信息。主键：厅室编号 房间，存放公寓或厅室所提供的房间信息。主键：住宿编号 发票，存放学生需交租金而开出的发票。主键：发票编号 学生，存放所有学生的基本信息。主键：学号 职工，存放管理公寓或厅室的管理员信息。主键：职工编号 欠款提示，存放欠费学生的提示信。主键：提示编号 付款方式，存放不同的付款方式。主键：付款方式编号 由于发票实体中的付款方式是多值的，所以将付款方式单独作为一个实体考虑，主键是付款方式编号。,2 学生住宿管理,（3）定义实体间的联系学生租房必须签订租用合同。由于每个学期都要签订一次租用合同，故一个学生可能多
16、次签订合同；而每份合同只对应一个学生。因此，学生实体与租用合同实体之间是一对多联系。,2 学生住宿管理,凡是租用房子的都要付租金。因为学生要交一个学年的住宿费用，每个学期都有一张发票。而每张发票都对应一份租用合同。因此，租用合同实体与发票实体之间是一对多联系。,2 学生住宿管理,每张发票只有一种支付方式，而每种支付方式可以在不同的发票中使用。因此，支付方式实体和发票实体之间是一对多联系。,2 学生住宿管理,如果学生在一个规定的日期之前没有交费，则会收到两封提示交费的信。因此，每张发票最多对应两封提示信。而每封提示信一定对应一张发票。所以，发票实体和提示信实体之间是一对多联系。,2 学生住宿管理
17、,每个厅室可提供多个房间租用，而每个厅室房间只能属于一个厅室。因此，厅室实体和房间实体之间是一对多联系。,2 学生住宿管理,一个职工管理一个厅室，而每个厅室只能由一个职工管理。因此，厅室与职工之间是一对一联系。,2 学生住宿管理,每个公寓提供多个房间。因此，公寓与房间之间也存在一对多联系。,2 学生住宿管理,每个职工管理一个公寓，而一个公寓可由多个职工管理。因此，公寓与职工之间是一对多联系。,2 学生住宿管理,每份租用合同对应一个房间，而每个房间可多次租用，即，有多份合同。因此，房间和租用合同之间是一对多联系。,2 学生住宿管理,租用合同实体的描述属性有： 租用合同编号，租期，开始日期，终止日
18、期，学号，住宿编号。 公寓实体的描述属性有： 公寓编号，公寓地址，公寓房间数量。 厅室实体的描述属性有： 厅室编号，厅室地址，厅室电话，厅室传真号，厅室房间数量，管理员编号。,给实体及联系加上描述属性：,2 学生住宿管理,房间实体的描述属性有： 住宿编号，房间编号，每学期租金，厅室编号，公寓编号，床位数、租满否。 发票实体的描述属性有： 发票编号，学期，应付款日期，实际付款日期，租用合同编号，支付方式编号。 提示信息实体的描述属性有： 发票编号，提示日期1，提示日期2，备注 。,2 学生住宿管理,职工实体的描述属性有： 职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，EMAIL，职务
19、，职称，部门。 付款方式实体的描述属性有： 付款方式编号，付款方式。 学生实体的描述属性有： 学号，姓名，性别，家庭住址，联系电话，邮政编码，系编号。,2 学生住宿管理,视图集成集成时仍采用两两集成策略。集成后的E-R图。,2 学生住宿管理,2 学生住宿管理,学生住宿管理的集成E-R图,2 学生住宿管理,逻辑设计,租用合同（合同编号，租期，开始日期，终止日期，学号，住宿编号） 主键：合同编号。 候补键：住宿编号开始日期，学号开始日期。 外键：学号，引用了学生关系中的学号；住宿编号，引用了房间关系中的住宿编号。 函数依赖集F： 合同编号租期，开始日期，终止日期，学号，住宿编号， 住宿编号，开始日
20、期合同编号，租期，终止日期，学号， 学号，开始日期合同编号，租期，终止日期，学号。租用合同关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以租用合同关系满足第3范式。,2 学生住宿管理,公寓（公寓编号，公寓地址，公寓房间数量） 主键：公寓编号。 函数依赖F： 公寓编号公寓地址，房间数量公寓关系中不存在非主属性与候选键之间的传递函数依赖，所以公寓关系满足第3范式。,2 学生住宿管理,厅室（厅室编号，厅室名，厅室地址，厅室电话，厅室传真号，厅室房间数量，管理员编号） 主键：厅室编号。 候补键：厅室电话；厅室传真号。 外键：管理员编号，引用了职工关系中的职工编号。 函数依赖集F： 厅室编号厅
21、室名，厅室地址，厅室电话，厅室传真号，厅室房间数量，管理员编号， 厅室电话厅室编号，厅室地址，厅室传真号，厅室房间数量，管理员编号， 厅室传真号厅室编号，厅室地址，厅室传真号，厅室房间数量，管理员编号，关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以厅室关系满足第3范式。,2 学生住宿管理,房间（住宿编号，房间编号，每学期租金，厅室编号，公寓编号，床位数，租满否） 主键：住宿编号。 候补键：厅室编号+房间编号；公寓编号+房间编号。 外键：厅室编号，引用了厅室关系中的厅室编号；公寓编号，引用了公寓关系中的公寓编号。 函数依赖集F： 住宿编号房间编号，每学期租金，厅室编号，公寓编号，床位
22、数，租满否， 厅室编号，房间编号住宿编号，每学期租金，床位数，租满否， 公寓编号，房间编号住宿编号，每学期租金，床位数，租满否。 不 关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以房间关系满足第3范式。,2 学生住宿管理,发票（发票编号，学期，应付款日期，实际付款日期，租用合同编号，付款方式编号） 主键：发票编号。 外键：租用合同编号，引用了租用合同关系中的租用合同编号；付款方式编号，引用了付款方式关系中的付款方式编号。 函数依赖集F： 发票编号学期，应付款日期，实际付款日期，租用合同编号，付款方式编号。关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以发票关系满足第3范式
23、。,2 学生住宿管理,付款方式（付款方式编号，付款方式） 主键：付款方式编号。 函数依赖集F： 付款方式编号付款方式。该关系满足第3范式。,2 学生住宿管理,职工（职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，EMAIL，职务，职称，部门，公寓编号） 主键：职工编号。 候补键：EMAIL。 外键：公寓编号。 函数依赖集F： 职工编号姓名，性别，出生年月，地址，办公电话，住宅电话，EMAIL，职务，职称，部门， EMAIL职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，职务，职称，部门。关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以职工关系满足第3范式。,2 学
24、生住宿管理,学生（学号，姓名，性别，家庭住址，联系电话，邮政编码，系编号） 主键：学号。 候补键：联系电话。 学号姓名，性别，家庭住址，联系电话，邮政编码，系编号， 联系电话学号，姓名，性别，家庭住址，邮政编码，系编号。关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以学生关系满足第3范式。,2 学生住宿管理,提示信（发票编号，提示日期1，提示日期2，备注 ） 主键：发票编号。 外键：发票编号，来自于发票关系中的发票编号。 函数依赖集F： 发票编号提示日期1，提示日期2，备注 。关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以职工关系满足第3范式。至此，设计的所有关系都满足较
25、高范式，故学生住宿管理的数据库设计是合理的。,2 学生住宿管理,验证处理需求的满足情况： （1）要查询租用的公寓或厅室情况，只需查询公寓关系或厅室关系。 （2）要查询房间的租用情况，只需查询房间关系。 （3）要查询租房学生的租用情况，只需查询租用合同关系。 （4）要查询哪个租房学生有欠款情况，只需对提示信关系、发票关系以及租用合同关系进行连接操作即可。上述数据库的设计能够满足用户的数据需求和处理需求。,3 工资管理,工资管理部门希望建立一个数据库来管理职工的工资。要计算职工的工资，就需要考虑不在休假日期以内的假期、工作期间的病假时间、奖金和扣除的部分。系统必须指明给每个职工发薪水的方式，随着时
26、间的推移，发薪水的方式可能会有些改变。大多数的职工是通过银行卡来结算工资的，但是也有一部分人使用现金或支票。如果是通过银行卡，就需要知道账号和卡的类型。付款方式只可能是一种方式。另外，还有几种原因需要扣除工资：例如，个人所得税、养老保险、公积金等。请根据工资管理的要求，进行数据库的概念设计和逻辑设计。,需求分析工资管理主要是根据每个职工每个月的考勤情况来计算工资的发放。,3 工资管理,工资管理系统的部分数据流图,3工资管理,工资管理过程中涉及到的数据有： 职工数据 奖金数据 假期数据 病假数据 扣除数据 工资历史数据 工资细节数据,3 工资管理,概念设计,一、局部视图设计 （1）确定局部视图的
27、设计范围 （2）确定实体及实体的主键每个职工都会有多次的假期、病假、奖金以及其他扣除。其中，“其他扣除”包括了个人所得税、国家税、医疗保险、退休保险或者预付款等几种扣除类型；工资的支付方式分银行卡、现金或支票几种支付类型；奖金也分为不同类型。,3 工资管理,工资管理中涉及到的实体有： 职工，主键：职工编号 奖金，主键：职工编号日期 假期，主键：职工编号假期起始日期 病假，主键：职工编号病假起始日期 扣除，主键：职工编号扣除日期 工资历史，主键：职工编号日期 工资细节，主键：职工编号日期 奖金类型，主键：奖金类型编号 支付类型，主键：支付类型编号 扣除类型，主键，扣除类型编号,3 工资管理,（3
28、）定义实体间的联系如果每个职工可以有多次请假，而每次请假都对应某个职工。因此，职工实体和假期实体之间是一对多联系。,职工与假期之间的一对多联系,3 工资管理,如果每个职工可以有多次病假，而每次病假都对应某个职工。因此，职工实体和病假实体之间是一对多联系。,职工和病假之间的一对多联系,3 工资管理,如果每个职工可以有不同的扣除部分，而每次扣除都对应某个职工。因此，职工实体和扣除实体之间是一对多联系。,职工和扣除之间的一对多联系,3 工资管理,职工根据工作情况每个月份可以获得不同类型的奖金，但不是任何职工都能获得奖金。因此，职工实体和奖金实体之间是一对多联系。,职工和奖金之间的一对多联系,3 工资
29、管理,职工和工资历史、工资细节之间的一对多联系,每一个职工不同的月份都有一份工资。如果工资发放使用银行卡的话，则还应该保存工资的细节和支付方式变化情况。为了避免数据冗余，因此，职工实体和工资历史实体之间是一对多联系；而职工实体和工资细节实体之间也是一对多联系。,3 工资管理,职工获得的每份奖金对应一种奖金类型。每种奖金类型可以被不同的职工获得。因此，奖金实体和奖金类型实体之间是一对多联系。,奖金和奖金类型之间的一对多联系,3 工资管理,工资的每一次扣除对应一种扣除类型，而每一种扣除类型可对应多次扣除。因此，扣除类型实体和扣除实体之间是一对多联系。,扣除类型和扣除之间的一对多联系,3 工资管理,
30、（4）给实体及联系加上描述属性 职工实体的描述属性有： 职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，EMAIL，职务，职称，部门。 奖金实体的描述属性有： 职工编号，日期，奖金数，奖金类型。 假期实体的描述属性有： 职工编号，假期起始时间，假期结束时间，原因。,3 工资管理,病假实体的描述属性有： 职工编号，病假起始时间，病假结束时间，原因。 扣除实体的描述属性有： 职工编号，扣除日期，扣除类型编号，扣除数量。 工资历史实体的描述属性有： 职工编号，日期，工资数。 工资细节实体的描述属性有： 职工编号，日期，帐号，支付方式编号，银行名称，银行地址。,3 工资管理,支付方式实体的描
31、述属性有：支付方式编号，支付方式。 奖金类型实体的描述属性有：奖金类型编号，奖金类型。 扣除类型实体的描述属性有：扣除类型编号，扣除类型,3 工资管理,视图集成,3 工资管理,3 工资管理,逻辑设计,职工（职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，EMAIL，职务，职称，部门） 主键：职工编号。 候补键：EMAIL。 函数依赖集F： 职工编号姓名，性别，出生年月，地址，办公电话，住宅电话，EMAIL，职务，职称，部门， EMAIL职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，职务，职称，部门。关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以职工关系满足第3
32、范式。,3 工资管理,奖金（职工编号，日期，奖金数，奖金类型编号) 主键：职工编号，日期。 外键：职工编号，来自于职工实体中的职工编号； 奖金类型编号，来自于奖金类型实体中奖金类型编号。 函数依赖集F： 职工编号日期，奖金数，奖金类型编号。关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以奖金关系满足第3范式。,3 工资管理,假期（职工编号，假期起始时间，假期结束时间，原因） 主键：职工编号假期起始时间。 函数依赖集F： 职工编号，假期起始时间假期结束时间，原因。关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以假期关系满足第3范式。,3 工资管理,病假（职工编号，病假起始时间
33、，病假结束时间，原因） 主键：职工编号病假起始时间。 函数依赖集F： 职工编号，病假起始时间病假结束时间，原因。关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以病假关系满足第3范式。,3 工资管理,扣除（职工编号，扣除日期，扣除数量，扣除类型编号） 主键：职工编号扣除日期。 函数依赖集F： 职工编号，扣除日期扣除数量，扣除类型编号。关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以扣除关系满足第3范式。,3 工资管理,工资历史（职工编号，日期，工资数） 主键：职工编号日期。 外键：职工编号，引用了职工关系中职工编号。 函数依赖集F： 职工编号，日期 工资数关系中不存在非主属性
34、与候选键之间的部分与传递函数依赖，所以扣除关系满足第3范式。,3 工资管理,工资细节（职工编号，日期，帐号，支付方式编号，银行名称，银行地址） 主键：职工编号日期。 外键：职工编号，来自于职工实体中的职工编号； 支付方式编号，来自于支付方式实体中的支付方式编号。 函数依赖集F： 职工编号，日期帐号，支付方式编号，银行名称，银行地址。关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以工资关系满足第3范式。,3 工资管理,支付方式（支付方式编号，支付方式） 主键：支付方式编号。 函数依赖集F： 支付方式编号支付方式。关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以工资关系满足第3
35、范式。,3 工资管理,奖金类型（奖金类型编号，奖金类型） 主键：奖金类型编号。 函数依赖集F： 奖金类型编号奖金类型。关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以工资关系满足第3范式。,3 工资管理,扣除类型（扣除类型编号，扣除类型） 主键：扣除类型编号。 函数依赖集F： 扣除类型编号扣除类型。关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以工资关系满足第3范式。至此，设计的所有关系都满足较高范式，故工资管理的数据库设计是合理的。,3 工资管理,个人所得税 养老保险 公积金,银行卡 现金 支票,3 工资管理,职工（职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话
36、，EMAIL，职务，职称，部门） 奖金（职工编号，日期，奖金数，奖金类型编号) 假期（职工编号，假期起始时间，假期结束时间，原因） 病假（职工编号，病假起始时间，病假结束时间，原因） 扣除（职工编号，扣除日期，扣除数量，扣除类型编号） 支付细节（职工编号，开始日期，帐号，支付方式编号，银行名称，银行地址） 支付历史（职工编号，支付日期，工资数） 支付方式（支付方式编号，支付方式） 奖金类型（奖金类型编号，奖金类型） 扣除类型（扣除类型编号，扣除类型）,3 工资管理,4 发票处理,在公司的订单处理中，凡是订购商品的客户，如果库存能够满足客户需求，财务部门就可以开出发票。同时将商品和发票寄给客户，
37、并要求客户付款。公司要求建立一个数据库，对客户的发票进行处理。该数据库应能够提供对发票到款情况的查询，如实际到款数、欠款数等。如果发票到期而客户没有按时付款，系统应该提供欠款的客户名单并发出催款通知。请给出数据库的概念设计和逻辑设计。,4 发票处理,需求分析,4 发票处理,概念设计,一、局部视图设计 （1）确定局部视图的设计范围 （2）确定实体及实体的主键 发票处理的实体有： 发票，存放开出的每一张发票。主键：发票编号 实际到款，存放每张发票的实际到款数。主键：发票编号到款日期 付款方式，存放付款方式。主键：付款方式编号，付款方式 催款通知，存放发票到期但未付完款的客户催款通知。,4 发票处理
38、,（3）定义实体间的联系如果一张发票对应多次到款，而每笔到款只对应一张发票。则发票实体与到款实体之间是一对多联系。,4 发票处理,一张发票只对应一种付款方式，而每种付款方式可对应多张发票。则付款方式实体和发票实体之间是一对多联系。,4 发票处理,一张发票可能对应多次催款通知，而每个催款通知对应一张发票。因此，发票实体和催款通知实体之间是一对多联系。,4 发票处理,（4）给实体及联系加上描述属性 发票实体的描述属性有： 发票编号，开票日期，付款日期，订单编号，客户编号，金额，付款方式编号。 实际到款实体的描述属性有： 发票编号，客户编号，到款日期，到款金额。 付款方式实体的描述属性有： 付款方式
39、编号，付款方式。,4 发票处理,二、视图集成,4 发票处理,逻辑设计,发票（发票编号，开票日期，付款日期，订单编号，客户编号，金额，付款方式编号） 主键：发票编号。 外键：订单编号，引用了订单关系中的订单编号（本例不讨论订单处理部分）；客户编号，引用了客户关系中的客户编号（本例不讨论订单处理中的客户关系部分）；付款方式编号，引用了付款方式关系中的付款方式编号。 函数依赖集F: 发票编号开票日期，付款日期，订单编号，客户编号，金额，付款方式编号， 订单编号发票编号，开票日期，付款日期，客户编号，金额，付款方式编号。发票关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以发票关系满足第3范式
40、。,4 发票处理,实际到款（发票编号，客户编号，到款日期，到款金额） 主键：发票编号到款日期。 外键：客户编号，引用了客户关系中的客户编号。 函数依赖集F： 发票编号，到款日期客户编号，到款金额。发票关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以实际到款关系满足第3范式。,4 发票处理,付款方式（付款方式编号，付款方式） 主键：付款方式编号。 函数依赖集F： 付款方式编号付款方式。付款方式关系满足第3范式。,4 发票处理,要查询是否有欠款情况，只要对已到付款日期的发票进行检查，对实际到款关系进行统计，然后再与发票关系中的金额进行比较。如果某张发票的实际到款总数等于发票实体中对应发票
41、上开出的金额数，则不欠款；如果某张发票的实际到款总数小于发票实体中对应发票上开出的金额数，则欠款。将其记录在催款通知关系中，以便打印。至此，设计的所有关系都满足较高范式，也满足应用需求。故发票处理的数据库设计是合理的。,5保险业务管理,某保险公司雇佣多名业务员开展保险业务。一名业务员可以为多名客户服务；一个客户也可以通过多个业务员购买多种保险；每个客户在每次购买保险时通过一个业务员与保险公司签订合同。图中显示一张经过简化的该保险公司的个人保险投保合同书，请根据这张合同书所提供的信息设计一个数据库，对保险业务数据进行管理。,5保险业务管理,5保险业务管理,需求分析,5保险业务管理,保险业务管理的
42、主要查询需求有： 查询所有已签的个人保险投保合同情况 查询能够保险的所有项目 查询所有投保人情况 查询所有被保险人情况,保险业务管理的处理需求有： 查询所有已签的个人保险投保合同情况 查询能够保险的所有项目 查询所有投保人情况 查询所有被保险人情况 查询业务员情况 ,5保险业务管理,一、局部视图设计 （1）确定局部视图的设计范围 略。 （2）确定实体及实体的主键该保险业务涉及到的实体有： 个人保险投保合同书，存放保险公司与投保人签订的所有个人保险投保合同。主键：保险合同号 投保人，存放所有投保人的信息。主键：投保人号 被保险人，存放所有被保险人的信息。主键：被保险人号 业务员，存放所有业务员的
43、基本信息。主键：业务员工号 保险，存放所有能够提供的保险内容。主键：保险号,概念设计,5保险业务管理,（3）定义实体间的联系如果一份合同只能购买一种保险，而每种保险可以被不同的合同购买。则保险实体和合同实体之间是一对多联系。,5保险业务管理,每个客户只和一名业务员签订保险合同，而一名业务员可以为多名客户服务，也就是可以签订多份保险合同；则业务员实体和合同实体之间是一对多联系。,5保险业务管理,每份合同只有一个投保人，而每个投保人可以购买多种保险，即可签订多份保险合同。则投保人实体和合同实体之间是一对多联系。,5保险业务管理,被投保人是依赖于投保人的，因此，被保险人是一个弱实体。如果投保人可以为
44、多个被保险人购买保险，而每个被保险人只能有一个投保人。则投保人实体和被投保人之间是一对多联系。,（4）给实体及联系加上描述属性根据个人保险投保合同书的内容，我们可以确定每个实体的描述属性。如果需要，可以在实体中增加一定的描述属性。 合同实体的描述属性有： 保险合同号，投保人号，被保险人号，业务员工号，保险号，日期，收款收据号。 保险实体的描述属性有： 保险号，保险名称，保险金额，保险期限，交费期限，交费方式，标准保险费。,5 保险业务管理,5保险业务管理,业务员的描述属性有： 业务员工号，业务员姓名，电话号码。 投保人实体的描述属性有： 投保人号，姓名，性别，出生日期，证件名称，证件号码，通信
45、地址，联系电话，地址，邮编，Email。 被投保人实体的描述属性有： 投保人号，被保险人号，姓名，性别，出生日期，证件名称，证件号码，通信地址，联系电话，地址，邮编，Email。,5保险业务管理,二、视图集成,5保险业务管理,逻辑设计,1 投保人（投保人号，姓名，性别，出生日期，证件名称，证件号码，通信地址，联系电话，地址，邮编，Email） 主键：投保人号。 候补键：Email； 函数依赖集F： 投保人号姓名，性别，出生日期，证件名称，证件号码，通信地址，联系电话，地址，邮编，Email, Email投保人号，姓名，性别，出生日期，证件名称，证件号码，通信地址，联系电话，地址，邮编。关系中不
46、存在非主属性与候选键之间的部分与传递函数依赖，所以投保人关系满足第3范式。,5保险业务管理,3 被保险人依赖于投保人，是个弱实体。 被保险人（投保人号，被保险人号，姓名，性别，出生日期，证件名称，证件号码，通信地址，联系电话，地址，邮编，Email） 主键：投保人号被保险人号。 候补键：Email。 外键：投保人号，引用了投保人关系中的投保人号。 函数依赖集F： 投保人号，被保险人号姓名，性别，出生日期，证件名称，证件号码，通信地址，联系电话，地址，邮编，Email， Email投保人号，被保险人号，姓名，性别，出生日期，证件名称，证件号码，通信地址，联系电话，地址，邮编。 另：被保险人号姓名
47、，性别，出生日期，证件名称，证件号码，通信地址，联系电话，地址，邮编，Email也成立。关系中存在非主属性与候选键之间的部分函数依赖，所以被保险人关系是第1范式。,5保险业务管理,2 业务员（业务员工号，业务员姓名，电话号码） 主键：业务员工号。 函数依赖集F： 业务员工号业务员姓名，电话号码。关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以业务员关系满足第3范式。,5保险业务管理,3保险（保险号，保险名称，保险金额，保险期限，交费期限，交费方式，标准保险费） 主键：保险号 函数依赖集F： 保险号保险名称，保险金额，保险期限，交费期限，交费方式，标准保险费。关系中不存在非主属性与候选
48、键之间的部分与传递函数依赖，所以保险关系满足第3范式。,5保险业务管理,5.合同（保险合同号，投保人号，被保险人号，业务员工号，保险号，日期，收款收据号） 主键：保险合同号。 外键：投保人号，引用了投保人关系中的投保人号； 被保险人号，引用了被保险人关系中的被保险人号； 业务员号，引用了业务员关系中的业务员号； 保险号，引用了保险关系中的保险号。 函数依赖集F： 保险合同号投保人号，被保险人号，业务员工号，保险号，日期，收款收据号。关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以合同关系满足第3范式。,5保险业务管理,验证查询需求的满足情况： （1）要查询所有已签的个人保险投保合同情
49、况，只需对合同关系进行查询； （2）要查询能够保险的所有项目，只需对保险关系进行查询； （3）要查询所有投保人情况，只需对投保人关系进行查询； （4）要查询所有被保险人情况，只需对被保险人关系进行查询；,6 车辆租赁管理,一个租赁公司希望建立一个数据库来管理对用户的车辆租赁。公司有不同的部门，每个部门都有一定的职工，其中包括一个经理和几个高级技师，高级技师负责把工作分配给下面的一组普通技工。每个部门都有库存的车辆，以便租给用户。用户租赁时间一般为最少4小时到最多6个月。每个用户和公司之间的租赁合同都有一个惟一的租赁号。用户必须拿出在租用期间的保险金。每次租用过后要对车辆进行检查，以验证它的损坏程度。 请根据上述要求设计数据库。,6 车辆租赁管理,需求分析,6 车辆租赁管理,车辆租赁管理涉及到的数据有： 租赁合同数据 部门数据 职工数据 用户数据 车辆数据 车辆故障数据,
