一、数据模型
1、为什么需要数据模型
(1)DBMS的实现:“数据结构”与“数据文件”从应用程序中剥离出来,交由DBMS来定义和管理。因此DBMS需要采用某种“数据结构”来定义、存储所要管理的数据,这个“数据结构”就是DBMS的数据模型。
(2)数据库的设计:现实系统要向计算机化的管理转变,因此在数据库设计时,也必须用某种方式将其所关心、管理的数据抽取出来并组织起来,数据模型正是起到这种作用。
2、数据模型含有哪些内容?
(1)数据的静态结构,包括:数据本身、数据间的联系。
(2)数据的动态操作,即增刪改查询。
(3)数据的完整性约束。
3、如何评价数据模型
(1)真实地描述现实系统
(2)易为业务用户所理解
(3)易于用计算机实现
如果个数据模型能同时满足这 3项要求,则可认为其达到优秀级。事实上,这3个要求是由数据模型所处的地位、担负的角色所决定的。
4、数据模型为什么有层次性
(1)从与数据抽象的关系看:数据模型是数据库设计时数据抽象的工具,由于抽象层次的存在,相应的数据模型也会有层次性。
(2)从评价指标第二、三项的互斥性看:因第二、三项的互斥性,无法在数据库应用系统开发时,从设计到实现只使用一个数据模型,因此需要再构造一种高级数据模型(如ERM,是用的最广泛且最成熟的高级语义数据模型),用于数据库设计,然后在实现时再将其转换为所用DBMS支持的数据模型,从而形成了层次性。
5、数据模型努力的方向
(1)设计与实现只用一个数据模型:目前已有这样的数据模型,对象数据模型(ODM),只是OODBMS的产品商业化程度及水平还不高。
(2)层次共存、自动转换:实现一种高级数据模型向DBMS支持的数据模型的自动转换CASE工具。在设计时用一种高级数据模型,然后利用该转换工具,将高级数据模型描述的数据模式转换为DBMS可支持的数据模式,减轻开发工作量,实现快速应用开发。目前已有Power Designer、ERwin等工具,可实现ERM向关系模型转换、关系模型向ERM转换,还有Rose工具实现对象模型向关系模型的转换。
二、数据库设计概述
(一)一大堆概念(略)
1、实体(可以是具体也可以是抽象的)、实体型、属性(按结构分:简单属性、子属性、复合属性;按域的取值分:单值属性、多值属性、导出属性、空值属性)、域、键(分为简单键、复合键、主键、候选键)
2、联系、联系型、联系型的阶(阶为n的联系型,成为n元联系型)
3、联系型存在的情况
(1)二元联系
(2)三元联系
(3)两个实体型之间可能有多个不同的联系,不要以为只有一种联系
(4)有时一个联系型所关联的是同一实体型的两个实体
想象不出来...
4、联系性分类
(1)一对一
(2)一对多
(3)多对多
由于这些联系都是对联系中实体与实体数量上的约束(或限制),因此有时也分别称它们为一对一约束、一对多约束和多对多约束,同时作为ERM中的一般性约束。
5、键约束或键限制
键约束是在一般性约束的基础上更细致的约束。只有一对多、一对一约束才存在键约束。
6、参与约束
(1)完全参与约束
如:员工与工作。只要是企业在职员工,企业都会为其安排工作。
(2)部分参与约束
如:员工与管理。只有作为领导的部分员工才参与部分的管理。
7、联系型属性的移动处理
在一对一和一对多联系的情况下,可以将联系型的属性移动到所关联的某个实体型中,作为其属性。方法如下:
(1)一个联系型R是关联实体型A和B的1:1联系型,则R的描述属性,既可以移动到A,也可以移动到B。
(2)一个联系型R是关联实体型A和B的1:n联系型,则最好移动R的属性到与n对应的实体型B。
8、弱实体
如:企业给员工办理各种保险,必然涉及保险的受益人,如员工的子女、亲属等。那么子女和亲属不会企业管理的主体,保险受益人这类实体型就是弱实体。
(二)扩展实体联系模型
1、类层次
(1)子类:将员工分为合同工和小时工,小时工和合同工就是员工的子类。
(2)超类:员工(最上层的)就是超类。
(3)类层次:员工和小时工、合同工之间这种特殊的层次联系,就是类层次,用ISA表示。
2、演绎和归纳
演绎和归纳是类层次的两种处理方法。
(1)演绎:先定义超类,再由超类来定义子类,然后加入子类的特定属性。即一般到特殊的方法。如,员工可以分为管理人员、技术人员、销售人员等。
演绎的原则:重叠约束和包容约束。
①重叠约束:要求演绎出来的子类不能有重叠或交叉,又名正交约束。
②包容约束:要求超类中的每个实体必须属于某一子类,又名完全性约束。
(2)归纳:先定义子类,再定义超类。即由特殊到一般的方法。如:本科生、研究生、博士生最后归纳为学生。
3、聚集
某部门“资助”某项目后,该部门会指定某个员工去“监督”该“资助”不被挪作他用。“部门”实体与“项目”实体间的联系为“资助”,“员工”与“资助”之间的联系为“监督”,而“资助”本身是联系。于是出现联系概念的不一致。
通过引入“聚焦”概念后,可将“部门”、“项目”以及他们之间的联系“资助”组合起来,形成一个“聚集”,将此聚集当作一个“虚实体”,然后再与“员工”实体构成“监督”联系。
(三)利用ER模型的概念数据库设计
1、设计方法
(1)自顶向下:先了解全局,再考虑各部门、用户的需求。企业越来越大,全局需求很难掌握。
(2)自底向上:先给部门生成各自的一个概念模式,再进行集成。大多数情况下采用此方法。
2、应用实例
(1)系统调研
①该公司有多个原材料库房,每个库房分布在不同的地方,每个库房有不同的编号,公司对这些库房进行统一管理。
②每个库房可以存放多种不同的原材料,为了便于管理,各种原材料分类存放,同种原材料集中存放在同一个库房里。
③每一个库房可安排一名或多名员工管理库房 ,在这些库房,每一个管理员有且仅有一名员工是他的直接领导。
④同一种原材料可以供应多个不同的工程项目,同一个工程项目要使用多种不同的原材料。
⑤同一种原材料可由多个不同的厂家生产,同一个生产厂家可生产多种不同的原原材料。
(2)概念DB设计
对调研结果分析后,可以归纳出相应的实体型、联系型及其属性。
1)实体型及属性
①库房实体型,具有库房号、地点、库房面积、库房类型等属性。
②员工实体型,具有员工号、姓名、性别、出生年月、职称等属性。
③原材料实体型,具有材料号、名称、规格、单价、说明等属性。
④工程项目实体型,具有项目号、预算资金、开工日期、竣工日期等属性。
⑤生产厂家实体型,具有厂家号、厂家名称、通信地址、联系电话等属性。
2)联系型及属性
①工作联系型是1 : n联系。
②领导联系型是1: n联系,且是一种递归联系型。
③存放联系型是m: n联系,且具有“库存量”属性。
④供应联系型是一个三元联系型,且具有“供应量”属性。
(3)生成ER模型图
说明:如果某个实体型的属性太多,可以将实体型的属性分离出来单独表示;当实体型比较多,而联系又特别复杂时,可以分解成几个子图来表示。