*【零基础自学笔记】第二章：实体联系数据模型

一、数据模型

 

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模型图

说明：如果某个实体型的属性太多，可以将实体型的属性分离出来单独表示；当实体型比较多，而联系又特别复杂时，可以分解成几个子图来表示。