ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

数据库设计之概念结构设计

2021-12-31 11:58:50  阅读:206  来源: 互联网

标签:职工 联系 数据库 实体 概念 冗余 之间 结构设计 属性


概念模型

将需求分析得到的用户需求抽象为信息结构(即概念模型)的过程就是概念结构设计

概念模型的特点

(1)能真实、充分地反映现实世界,是现实世界的一个真实模型。
(2)易于理解,从而可以用它和不熟悉计算机的用户交换意见。
(3)易于更改,当应用环境和应用要求改变时,容易对概念模型修改和扩充。
(4)易于向关系、网状、层次等各种数据模型转换

描述概念模型的工具

E-R模型

E-R模型

1. 实体之间的联系

(1)两个实体型之间的联系:
①一对一联系(1∶1)
②一对多联系(1∶n)
③多对多联系(m∶n)
①一对一联系(1∶1)
如果对于实体集A中的每一个实体,实体集B中至多有一个(也可以没有)实体与之联系,反之亦然,则称实体集A与实体集B具有一对一联系,记为1∶1。
例如,学校里一个班级只有一个正班长,而一个班长只在一个班中任职,则班级与班长之间具有一对一联系。
②一对多联系(1∶n)
如果对于实体集A中的每一个实体,实体集B中有n个实体(n≥0)与之联系,反之,对于实体集B中的每一个实体,实体集A中至多只有一个实体与之联系,则称实体集A与实体集B有一对多联系,记为1∶n。
例如,一个班级中有若干名学生,而每个学生只在一个班级中学习,则班级与学生之间具有一对多联系。
③多对多联系(m∶n)
如果对于实体集A中的每一个实体,实体集B中有n个实体(n≥0)与之联系,反之,对于实体集B中的每一个实体,实体集A中也有m个实体(m≥0)与之联系,则称实体集A与实体集B具有多对多联系,记为m∶n。
例如,一门课程同时有若干个学生选修,而一个学生可以同时选修多门课程,则课程与学生之间具有多对多联系。
在这里插入图片描述

(2)两个以上的实体型之间的联系
一般地,两个以上的实体型之间也存在着一对一、一对多、多对多联系。
对于课程、教师与参考书3个实体型,如果一门课程可以有若干个教师讲授,使用若干本参考书,而每一个教师只讲授一门课程,每一本参考书只供一门课程使用,则课程与教师、参考书之间的联系是一对多的,如图(a)所示。
在这里插入图片描述

(3)单个实体型内的联系
同一个实体集内的各实体之间也可以存在一对一、一对多、多对多的联系。
例如,职工实体型内部具有领导与被领导的联系,即某一职工(干部)“领导”若干名职工,而一个职工仅被另外一个职工直接领导,因此这是一对多的联系,如图7.8所示。
在这里插入图片描述

联系的度:参与联系的实体型的数目
2个实体型之间的联系度为2,也称为二元联系;
3个实体型之间的联系度为3,称为三元联系;
N个实体型之间的联系度为N,也称为N元联系

2. E-R图

E-R图提供了表示实体型、属性和联系的方法:
实体型:用矩形表示,矩形框内写明实体名。
属性:用椭圆形表示,并用无向边将其与相应的实体型连接起来。
例如,学生实体具有学号、姓名、性别、出生年份、系、入学时间等属性,用E-R图表示如图所示
在这里插入图片描述

联系:用菱形表示,菱形框内写明联系名,并用无向边分别与有关实体型连接起来,同时在无向边旁标上联系的类型(1∶1,1∶n或m∶n)。
联系可以具有属性
在这里插入图片描述

3. 一个实例

某个工厂物资管理的概念模型。物资管理涉及的实体有:
仓库:属性有仓库号、面积、电话号码
零件:属性有零件号、名称、规格、单价、描述
供应商:属性有供应商号、姓名、地址、电话号码、账号
项目:属性有项目号、预算、开工日期
职工:属性有职工号、姓名、年龄、职称
这些实体之间的联系如下:
(1) 一个仓库可以存放多种零件,一种零件可以存放在多个 仓库中,因此仓库和零件具有多对多的联系。用库存量来表示某种零件在某个仓库中的数量。
(2) 一个仓库有多个职工当仓库保管员,一个职工只能在一个仓库工作,因此仓库和职工之间是一对多的联系。
(3) 职工之间具有领导与被领导关系。即仓库主任领导若干保管员,因此职工实体型中具有一对多的联系。
(4) 供应商、项目和零件三者之间具有多对多的联系。即一个供应商可以供给若干项目多种零件,每个项目可以使用不同供应商供应的零件,每种零件可由不同供应商供给。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

概念结构设计

1. 实体与属性的划分原则

为了简化E-R图的处置,现实世界的事物能作为属性对待的,尽量作为属性对待。
两条准则:
(1)作为属性,不能再具有需要描述的性质。属性必须是不可分的数据项,不能包含其他属性。
(2)属性不能与其他实体具有联系,即E-R图中所表示的联系是实体之间的联系。
[例1] 职工是一个实体,职工号、姓名、年龄是职工的属性。
职称如果没有与工资、福利挂钩,根据准则(1)可以作为职工实体的属性
如果不同的职称有不同的工资、住房标准和不同的附加福利,则职称作为一个实体更恰当
在这里插入图片描述

[例2] 在医院中,一个病人只能住在一个病房,病房号可以作为病人实体的一个属性;
如果病房还要与医生实体发生联系,即一个医生负责几个病房的病人的医疗工作,则根据准则(2) 病房应作为一个实体。
在这里插入图片描述

[例3] 如果一种货物只存放在一个仓库,那么就可以把存放货物的仓库的仓库号作为描述货物存放地点的属性。
如果一种货物可以存放在多个仓库中,或者仓库本身又用面积作为属性,或者仓库与职工发生管理上的联系,那么就应把仓库作为一个实体。
在这里插入图片描述

[例7.1] 销售管理子系统E-R图的设计。
该子系统的主要功能是:
处理顾客和销售员送来的订单
工厂是根据订货安排生产的
交出货物同时开出发票
收到顾客付款后,根据发票存根和信贷情况进行应收款处理
参照需求分析和数据字典中的详尽描述,遵循前面给出的两个准则,进行了如下调整:
(1)每张订单由订单号、若干头信息和订单细节组成。订单细节又有订货的零件号、数量等来描述。按照准则(2),订单细节就不能作订单的属性处理而应该上升为实体。一张订单可以订若干产品,所以订单与订单细节两个实体之间是1∶n的联系。
在这里插入图片描述

(2)原订单和产品的联系实际上是订单细节和产品的联系。每条订货细节对应一个产品描述,订单处理时从中获得当前单价、产品重量等信息。
(3)工厂对大宗订货给予优惠。每种产品都规定了不同订货数量的折扣,应增加一个“折扣规则”实体存放这些信息,而不应把它们放在产品实体中。
最后得到销售管理子系统E-R图如图所示。
在这里插入图片描述

对每个实体定义的属性如下:
顾客:{顾客号,顾客名,地址,电话,信贷状况,账目余额}
订单:{订单号,顾客号,订货项数,订货日期,交货日期,工种号,生产地点}
订单细则:{订单号,细则号,零件号,订货数,金额}
应收账款:{顾客号,订单号,发票号,应收金额,支付日期,支付金额,当前余额,货款限额}
产品:{产品号,产品名,单价,重量}
折扣规则:{产品号,订货量,折扣}

2. E-R图的集成

E-R图的集成一般需要分两步
合并。解决各分E-R图之间的冲突,将分E-R图合并起来生成初步E-R图。
修改和重构。消除不必要的冗余,生成基本E-R图。
在这里插入图片描述

(1)合并E-R图,生成初步E-R图
各个局部应用所面向的问题不同,各个子系统的E-R图之间必定会存在许多不一致的地方,称之为冲突。
子系统E-R图之间的冲突主要有三类:
①属性冲突
②命名冲突
③结构冲突
①属性冲突
属性域冲突,即属性值的类型、取值范围或取值集合不同。
例如零件号,有的部门把它定义为整数,有的部门把它定义为字符型。
年龄,某些部门以出生日期形式表示职工的年龄,而另一些部门用整数表示职工的年龄。
属性取值单位冲突。
例如,零件的重量有的以公斤为单位,有的以斤为单位,有的以克为单位。
②命名冲突
同名异义,即不同意义的对象在不同的局部应用中具有相同的名字。
异名同义(一义多名),即同一意义的对象在不同的局部应用中具有不同的名字。
如对科研项目,财务科称为项目,科研处称为课题,生产管理处称为工程。
命名冲突
可能发生在实体、联系一级上
也可能发生在属性一级上
通过讨论、协商等行政手段加以解决
③结构冲突
同一对象在不同应用中具有不同的抽象。
例如,职工在某一局部应用中被当作实体,而在另一局部应用中则被当作属性。
解决方法:把属性变换为实体或把实体变换为属性,使同一对象具有相同的抽象。
同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不完全相同。
解决方法:使该实体的属性取各子系统的E-R图中属性的并集,再适当调整属性的次序。
实体间的联系在不同的E-R图中为不同的类型。
实体E1与E2在一个E-R图中是多对多联系,在另一个E-R图中是一对多联系
解决方法是根据应用的语义对实体联系的类型进行综合或调整。
图中零件与产品之间存在多对多的联系“构成”
在这里插入图片描述

图中产品、零件与供应商三者之间还存在多对多的联系“供应”
在这里插入图片描述

合并两个E-R图,如图
在这里插入图片描述

(2)消除不必要的冗余,设计基本E-R图
所谓冗余的数据是指可由基本数据导出的数据,冗余的联系是指可由其他联系导出的联系。
消除冗余主要采用分析方法,即以数据字典和数据流图为依据,根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。
如图7.26中,Q3=Q1×Q2,Q4=∑Q5。所以Q3和Q4是冗余数据,可以消去。并且由于Q3消去,产品与材料间m:n的冗余联系也应消去。
在这里插入图片描述

并不是所有的冗余数据与冗余联系都必须加以消除,有时为了提高效率,不得不以冗余信息作为代价。
用规范化理论来消除冗余
①确定分E-R图实体之间的数据依赖。
实体之间一对一、一对多、多对多的联系可以用实体码之间的函数依赖来表示。于是有函数依赖集FL。
如图7.27中:
部门和职工之间一对多的联系可表示为职工号→部门号 职工和产品之间多对多的联系可表示为(职工号,产品号)→工作天数等。
在这里插入图片描述

②求FL的最小覆盖GL,差集为 D=FL-GL。
逐一考察D中的函数依赖,确定是否是冗余的联系,若是,就把它去掉。
由于规范化理论受到泛关系假设的限制,应注意下面两个问题:
冗余的联系一定在D中,而D中的联系不一定是冗余的;
当实体之间存在多种联系时,要将实体之间的联系在形式上加以区分。
[例7.2] 某工厂管理信息系统的视图集成。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
异名同义,项目和产品含义相同。某个项目实质上是指某个产品的生产。统一用产品作实体名。
库存管理中职工与仓库的工作关系已包含在劳动人事管理的部门与职工之间的联系之中,所以可以取消。职工之间领导与被领导关系可由部门与职工(经理)之间的领导关系、部门与职工之间的从属关系两者导出,所以也可以取消。
欢迎大家加我微信交流讨论(请备注csdn上添加)
在这里插入图片描述

标签:职工,联系,数据库,实体,概念,冗余,之间,结构设计,属性
来源: https://blog.csdn.net/weixin_45962068/article/details/122253294

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有