数据库考试重点

1、中国计量学院信息工程学院China Jiliang University2014 清华大学出版社数据库设计与应用开发实践数据库设计与应用开发实践(第一版） 陆慧娟 主编 陆慧娟 高波涌 刘丽娟 翁文勇 关伟 编著数 据 库 设 计 与 应 用 开 发 实 践2.1 E-R2.1 E-R模型设计模型设计数据库的设计分为三个阶段：从E-R模型开始的概念设计（即组织建立抽象的概念数据模型）；数据库的逻辑结构设计（即把概念设计阶段设计好的全局概念模式转换成与选用的具体机器上的DBMS所支持的数据模型相符合的逻辑结构）；优化数据存储和访问的物理设计（即对给定的基本数据模型设计一个适应环境的物理结构的过程

2、，包括文件类型、索引结构和数据的存放次序等）。2.1 E-R2.1 E-R模型设计模型设计本章主要介绍数据库设计的第一和第二阶段，以图书管理系统为例，从小型系统的E-R模型设计开始切入，进一步扩展到大型系统的E-R模型设计，最后介绍了数据库建模工具PowerDesigner。通过系统的讲解，有助于读者更为清晰地理解数据库的概念设计和逻辑结构设计，为后续章节展开优化图书管理系统的设计奠定基础。2.1 E-R2.1 E-R模型设计模型设计数据建模指的是对现实世界各类数据的分析、抽象、并从中找出内在联系，确定数据库需管辖的范围、数据的组织形式等进而确定数据库的结构。概念数据建模连接了两端，一端是需求

3、分析，其能辅助捕获需求中的实体及之间的关系，便于人们的交流。另一端是关系型数据库，模型可以很容易的转化为范式化或接近范式化的SQL表。2.1.1 2.1.1 数据建模的基本内容和方法数据建模的基本内容和方法2.1 E-R2.1 E-R模型设计模型设计基本内容： 确定数据及其相关过程（如读者搜索馆藏图书时，需要 获取图书相关信息及藏书位置等）。 定义数据（如数据类型、范围和默认值）。 确保数据的完整性（使用业务规则和验证检查）。 定义操作过程（如安全检查和数据备份）。 选择数据存储技术（如关系、分层或索引存储技术）。2.1.1 2.1.1 数据建模的基本内容和方法数据建模的基本内容和方法2.1

4、E-R2.1 E-R模型设计模型设计方法：逻辑数据库设计有多种实现方式，包括：自顶向下，自底向上以及混合方式。 传统数据库设计是一个自底向上的过程，从分析需求中的单个数据元素开始，把相关多个数据元素组合在一起转化为数据库中的表。这种方式较难应对复杂的大型数据库设计，这就需要结合自顶向下的设计方式。 目前使用E-R模型进行概念数据建模是一种高效的自顶向下的设计方法。一个数据库中的实体数量比数据元素少很多，因为大部分数据元素表示的是属性，辨别实体并关注实体之间的关系能大大减少需要分析的对象数量，且使用E-R模型还方便了项目团队内部及与最终用户之间的交流与沟通。2.1 E-R2.1 E-R模型设计模

5、型设计2.1.2 E-R模型的基本元素 E-R模型，是P.P.S. Chen于1976年提出的。E-R模型是用E-R图来描述概念模型的一种常用的表示方法。E-R模型的基本语义单位是实体与联系，它可以形象地用图形表示实体-联系及其关系。E-R图是直观表示概念模型的有力工具，该方法简单实用。E-R图有三要素：2.1 E-R2.1 E-R模型设计模型设计2.1.2 E-R模型的基本元素 实体用矩形框表示，框内标注实体名称。实体是首要的数据对象，常用于表示一个人、地方、某样事物或某个事件。 联系用菱形框表示，框内标注联系名称，并用连线将菱形框分别与有关实体相连。联系依赖于实体，一般没有物理概念上的存在

6、。联系最常用来表示实体之间一对一、一对多、多对多的对应关系。 属性用椭圆形表示，并用连线与实体或联系连接起来。属性为实体提供详细的描述信息。2.1 E-R2.1 E-R模型设计模型设计2.1.2 E-R模型的基本元素 使用ER模型可帮助项目成员专注在讨论实体之间的重要关系上，而不受其他细节的干扰。 ER模型把大量复杂的语言描述转化为精简的、易理解的图形化描述。 对原始ER模型的扩展，如可选和强制存在性关系，泛化关系等加强了ER模型对现实语义的描述能力。从ER模型转化为SQL表有完整的规则，且易于使用。在关系数据库设计中应用ER模型会带来如下益处：2.1 E-R2.1 E-R模型设计模型设计2.

7、1.3 实体识别 数据库实体就是数据库管理系统中的不同管理对象。数据库管理系统中的各种用于数据管理方面而设定的各种数据管理对象，如：数据库表、视图、存储过程等都是数据库实体。广义上讲，这些对象中所存储的数据也是数据库实体。因为它们也是确切存在着的实体。2.1 E-R2.1 E-R模型设计模型设计2.1.3 实体识别 实体（Entity）是一个数据对象，指应用中可以区别的客观存在的事物。 实体集（Entity Set）是指同一类实体构成的集合。 实体类型（Entity Type）是对实体集中的实体的定义。实体识别的内容就是区分实体和属性，实体和属性的概念都比较容易理解，但是在需求中区分二者有时并

8、不简单。实体、实体集、实体类型的定义如下：2.1 E-R2.1 E-R模型设计模型设计2.1.3 实体识别 1. 实体应包含描述性信息如果一个数据元素有描述型信息，该数据元素应被识别为实体。如果一个数据元素只有一个标识名，则其应被识别为属性。例如“读者”有姓名、年龄、性别等描述时，“读者”应当被认为一个实体。而像“作者”这样假如没有其他描述，则应当被作为“图书”实体的属性。辨别实体与属性可参考如下准则：2.1 E-R2.1 E-R模型设计模型设计2.1.3 实体识别2. 多值属性应作为实体来处理 如果一个实例的某个描述符包含多个对应值，则即使该描述符没有自己的描述信息也应作为实体进行建模。例如

9、“读者”的其中一个描述“读者类型”，同时会有普通借阅、参考借阅、阅览等多个属性值，则“读者类型”应当被识别为实体。2.1 E-R2.1 E-R模型设计模型设计2.1.3 实体识别 3. 属性应附着在其直接描述的实体上例如“借阅数量”属性依附于“读者类型”比依附于“读者”更合适。实体识别的难点在于定义的实体常常带有主观性，但是遵循一定的规律后就会变得容易，定义实体应当首选用户感兴趣的主要对象，实体的名字对用户来说意义直观，如果条件允许，实体识别可以直接从用户的需求说明提取相应的名词或者名词短语作为实体。识别实体与属性，并把属性附加到实体中是一个循环迭代的过程，这些准则能引导开发人员得到符合范式的

10、关系数据库设计。2.1 E-R2.1 E-R模型设计模型设计2.1.4 联系的设计l联系、联系集、联系类型的定义如下：l联系（Relationship）表示一个或多个实体之间的关联关系。l联系集（Relationship Set）是指同一类联系构成的集合。l联系类型（Relationship Type）是对联系集中联系的定义。2.1 E-R2.1 E-R模型设计模型设计2.1.4 联系的设计联系的元数定义 一个联系涉及到的实体集个数，称为该联系的元数或度数（Degree）。例如二元联系与三元联系的度分别为2和3，因此可以类推至n元联系的度数为n。二元联系是最常见的联系，当二元联系无法准确描述关

11、联的语义时，就需要使用三元联系。2.1 E-R2.1 E-R模型设计模型设计2.1.4 联系的设计如下面这个例子，图2-1表示的是一个三元联系，它能清楚的描述出某本图书是通过某个管理员借阅到某个读者手上。再看图2-2，这是一个二元联系，只能看出读者通过借阅获取图书，管理员参与了图书借阅，但无法描述出借阅图书的过程中，管理员和读者的联系。2.1 E-R2.1 E-R模型设计模型设计2.1.4 联系的设计 所以，一个实体可以参与到任意多个联系中，同时每个联系也可以联系任意多个实体，而且两个实体之间也能有任意多个二元联系，要选择怎样的联系，需根据系统的具体功能而定。2.1 E-R2.1 E-R模型设

12、计模型设计2.1.4 联系的设计联系类型的约束（1）基数约束二元联系的映射基数（Mapping Cardinalities）定义 实体集E1和E2之间有二元联系，则参与一个联系中的实体数目称为映射基数。（2）参与约束定义 如果实体集E中的每个实体都参与联系集R的至少一个联系中，称实体集E“完全参与”实体集R。如果实体集E中只有部分实体参与联系R的联系中，称实体集E“部分参与”联系集R。在E-R图中表示时，完全参与用双边线表示，部分参与用单边线表示。2.1 E-R2.1 E-R模型设计模型设计2.1.4 联系的设计实体间的联系有两种方式：一种是同一实体集的实体间的联系，另一种是不同实体集的实体间

13、的联系。主要研究第二种。实体间的联系虽然复杂，但可分解到最基本的两个实体间的联系。实体间的联系根据数量映射关系可归纳为三种类型： 一对一联系（1:1）如果实体集A和B中的每一个实体至多和另一个实体集中的一个实体有联系，那么实体集A和B的联系称为一对一联系，记作1:1。例如，飞机的乘客和座位之间、学校与校长之间等都是1:1的联系，要注意的是1:1联系不一定是一一对应。如图2-3(a)所示。2.1 E-R2.1 E-R模型设计模型设计2.1.4 联系的设计 一对多联系（1:n）若实体集A中每个实体与实体集B中任意多个实体(n0)有联系，而实体集B中每个实体至多与实体集A中一个实体有联系，那么称从A

14、到B是“一对多联系”，记为1:n。例如，部门与职工之间、班级与学生之间、车间和工人之间、系与学生之间，都是一对多联系。1:1联系是1:n联系的一个特例，即n=1时的1:n。如图2-3(b)所示。2.1 E-R2.1 E-R模型设计模型设计2.1.4 联系的设计 多对多联系（m:n）若实体集A和实体集B中允许每个实体都和另一个实体集中任意多个实体有联系，那么称A和B为多对多联系，记为m:n。例如，图书与读者之间、学生与课程之间、电影院和观众之间、商店和顾客之间都是多对多的联系。如图2-3(c)所示。2.1 E-R2.1 E-R模型设计模型设计2.1.4 联系的设计2.1 E-R2.1 E-R模型

15、设计模型设计2.1.4 联系的设计2.1 E-R2.1 E-R模型设计模型设计2.1.4 联系的设计实际上，一对一联系是一对多联系的特例，而一对多联系又是多对多联系的特例，如图2-3(d)示。联系中实体的存在性可以是强制的或可选的。当联系中的某一边实体（无论是“一”或“多”端）必须总是存在，则该实体为强制的。反之，该实体为可选的。 在实体与联系之间的连接线上标识“o”来表示可选存在性。含义是最小连通数为0。强制存在性表示最小连通数为1。在存在性不确定或不可知的情况下，默认最小连通数为1。如图2-4的例子，表示一个读者可能借了n本书，但是也可能一本都没借。2.1 E-R2.1 E-R模型设计模型

16、设计2.1.4 联系的设计3. 确定联系的映射数量以一张表来帮助记录确定的联系映射数量，如表2-1所示。2.1 E-R2.1 E-R模型设计模型设计2.1.4 联系的设计表中给出了5个实体名称，假设这只是一个完整的数据库中的一部分，以此为例，那说明联系映射数量的确定。考察一对实体的联系时，往往需要参考实体中的属性之间的联系，这种联系是以客观世界为依据的。下面先以读者实体为例，考察其与其他实体的联系。l一个读者可以借阅多本图书。l一个读者对应一种读者类别。l一个读者对应一个读者单位。2.1 E-R2.1 E-R模型设计模型设计2.1.4 联系的设计由此，确定了读者实体与其他实体之间的联系，如表2

17、-2所示。2.1 E-R2.1 E-R模型设计模型设计2.1.4 联系的设计 因为读者实体与管理员实体没有直接的联系，所以它们之间对应的框留空。现在，对其余的实体重复这一过程，就能得到一个完整的映射数量表，如表2-3所示。2.1 E-R2.1 E-R模型设计模型设计2.1.4 联系的设计从表2-3中可以看出，从一个角度确定的映射数量不一定与其相反的角度相同，例如从“读者”到“读者类别”的映射是1，从“读者类别”到“读者”的映射是n，此时将根据下面的公式来计算得到实体之间相互的映射数量：2.1 E-R2.1 E-R模型设计模型设计2.1.4 联系的设计l1 + 1 = 1:1 表示一对实体之间有

18、一对一的联系。如“读者”与“读者单位”是一对一的联系。ln + 1 = 1:n 表示一对实体之间有一对多的联系。如“读者类别”与“读者”是一对多的联系，即一个“读者类别”能关联多个“读者”，而一个“读者”只能关联一个“读者类别”。ln + n = m:n 表示一对实体之间有多对多的联系。如“读者”与“图书”是多对多联系。接下来只要根据表2-3以及上面的公式，就能确定所有的实体与实体之间的映射数量。2.1 E-R2.1 E-R模型设计模型设计2.1.5 属性设计属性的定义：定义：实体的某一特性称为属性（Attribute）。在一个实体中，能够唯一标识实体的属性或属性集称为“实体标识符”。属性的分

19、类：1、简单属性和复合属性简单属性（Simple Attribute）是不可再分割的属性。复合属性（Composite Attribute）是可再分解为其他属性的属性（即属性可嵌套）。2.1 E-R2.1 E-R模型设计模型设计2.1.5 属性设计2、单值属性和多值属性单值属性（Single -Value Attribute）指的是同一实体的属性只能取一个值。多值属性（Multi-Value Attribute）指的是同一实体的某些属性可能取多个值。多值属性进行变换的方法：（1）将原来的多值属性用几个新的单值属性来表示。（2）将原来的多值属性用一个新的实体类型表示。2.1 E-R2.1 E-R

20、模型设计模型设计2.1.5 属性设计3、存储属性和派生属性可从其他属性值推导出值的属性，称为派生属性（Derived Attribute）。派生属性的值不必存储在数据库内，而其他需要存储值的属性称为存储属性（Stored Attribute）。4、允许为空值的属性当实体在某个属性上没有值时应使用空值（Null Value）。当然，联系也可以有属性。例如上面的图2-1所表示的联系中，读者借阅图书时，可以有“借阅时间”这一属性，而归还时有“归还时间”这一属性，显然，将这些属性放在联系“借阅”上，才有实际意义。2.1 E-R2.1 E-R模型设计模型设计2.1.5 属性设计在联系的设计中需要注意一点

21、，联系的属性一般出现在多对多的二元或三元联系上。而在一对一或一对多联系上放置属性时，一般会引起歧义，所以这种情况下的做法通常是将这些属性移至一端的实体中。2.2 大型系统的E-R模型设计利用E-R方法进行数据库的概念设计，可分成三步进行：首先设计局部E-R模式，然后把各局部E-R模式综合成一个全局模式，最后对全局E-R模式进行优化、增强得到最终的E-R模型。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.1 局部E-R模式在系统需求分析阶段，最后得到了多层数据流图、数据字典和系统分析报告。建立局部E-R模型，就是根据系统的具体情况，在多层的数据流图中选择一个适当层次的数

22、据流图，作为设计E-R图的出发点，让这些图中每一部分对应一个局部应用。由于高层的数据流图只能反映系统的概貌，而中层的数据流图能较好地反映系统中各局部应用的子系统组成，因此人们往往以中层数据流图作为设计局部E-R图的依据。在选择好局部应用之后，就要对每个局部应用逐一设计局部E-R图。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.1 局部E-R模式在前面选好的某一层次的数据流图中，每个局部应用都对应了一组数据流图，局部应用涉及的数据都已经收集在数据字典中了，现在就是要将这些数据从数据字典中抽取出来，参照数据流图，标定局部应用中的实体、实体的属性、表示实体的码、确定实体之间

23、的联系及其类型。 设计局部E-R模型的关键就是正确划分实体和属性。实体和属性之间在形式上并无可以明显区分的界限，通常是按照现实世界中事物的自然划分来定义实体和属性，将现实世界中事物进行数据抽象，得到实体和属性。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.1 局部E-R模式一般说来，在给定的应用环境中，区别属性与实体要遵循原则请参照2.1.3。此外，要根据实际情况来决定，同一数据项，可能由于环境和要求不同，有时作为属性，有时则作为实体。一般情况下，凡能作为属性对待的，应尽量作为属性，以简化E-R图的处理。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计

24、2.2.1 局部E-R模式局部E-R模式的设计步骤如图2-5所示。l确定局部范围范围的划分要自然，这样易于管理，范围太小会造成局部过多，设计繁琐，范围太大会造成结构复杂，不便分析。另外范围之间的界面要清晰，相互影响要小。l定义实体一般采用人们的习惯来定义实体，在一个局部结构中，对一个对象只取一种抽象形式，不要重复避免冗余。 l定义联系l分配属性2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.1 局部E-R模式实体与属性之间的联系只能是一对多的，并且不同实体类型的属性之间应无直接联系。而当多个实体类型用到同一属性时，一般把属性分配给那些使用频率最高的实体类型，或分配给实体

25、值少的实体类型。注意：某些属性不适宜分配到实体上，如图书管理系统中的“借阅时间”属性，它表明了实体之间的联系的特性，此时应当分配到联系上。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.1 局部E-R模式2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.2 全局E-R模式各个局部视图即局部E-R图建立好后，还需要对它们进行合并，集成为一个整体的数据概念结构，形成全局E-R图，即视图的集成。视图集成的方法有两种： 多元集成法，一次性将多个E-R图合并为一个全局E-R图，如图2-6（a）所示。 二元集成法，首先集成两个重要的局部视图，以后每次将一个新的

26、局部视图集成进来。当然，如果局部视图比较简单，也可以采用多元集成法。一般情况下采用二元集成法，即每次只考虑两个视图，这样可降低难度，如图2-6（b）。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.2 全局E-R模式2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.2 全局E-R模式无论使用哪一种方法，视图集成均分成两个步骤，如图2-7所示。 (1) 合并消除局部E-R图之间的冲突，生成初步E-R图。 (2) 修改与重构消除不必要的冗余，生成基本E-R图。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.2 全局E-R模式 1

27、. 合并各个局部应用所面向的问题不同，且通常是由不同的设计人员进行局部视图设计，这就导致各个局部E-R图之间必定会存在许多不一致的地方，因此合并局部E-R图时并不能简单地将各个局部E-R图画到一起，而是必须着力消除各个局部E-R图中的不一致，以形成一个能为全系统中所有用户共同理解和接受的统一的概念模型。合理消除各局部E-R图的冲突是合并局部E-R图的主要工作与关键所在。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.2 全局E-R模式2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.2 全局E-R模式(1) 属性冲突属性冲突又分为属性值域冲突和属性

28、取值单位冲突。 属性值域冲突，即属性值的类型、取值范围或取值集合不同。例如，由于图书编号是数字，因此某些部门(即局部应用)将产品号定义为整数形式，而由于产品号不用参与运算，因此另一些部门(即局部应用)将产品号定义为字符型形式。 属性取值单位冲突。例如，图书的滞纳金，有的以元做单位，有的以角为单位。属性冲突通常用讨论、协商等手段加以解决。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.2 全局E-R模式(2) 命名冲突命名不一致可能发生在实体名、属性名或联系名之间，其中属性的命名冲突更为常见。一般表现为值同名异义和异名同义。 同名异义，即不同意义的对象在不同的局部应用中具

29、有相同的名字。例如，某局部应用A中将图书编号称为序号，局部应用B中将借书证号也称为序号。 异名同义(一义多名)，即同一意义的对象在不同的局部应用中具有不同的名字。例如，有的局部应用把图书的编号称为图书编号，有的局部应用则把它称为图书序号。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.2 全局E-R模式命名冲突可能发生在实体、联系一级上，也可能发生在属性一级上。其中属性的命名冲突更为常见。处理命名冲突通常也像处理属性冲突一样，通过讨论、协商等手段加以解决。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.2 全局E-R模式 (3) 结构冲突 同一对

30、象在不同应用中具有不同的抽象，可能为属性，也可能为实体。例如，出版社在某一局部应用中被当作属性，而在另一局部应用中则被当作实体。解决方法通常是把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。但变换时仍要遵循下节2.3.1所提到的两条原则。 同一实体在不同局部视图中所包含的属性不完全相同，或者属性的排列次序不完全相同。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.2 全局E-R模式2. 修改与重构 局部E-R图经过合并生成的是初步E-R图。之所以称其为初步E-R图，是因为其中可能存在冗余的数据和冗余的实体间联系。所谓冗余的数据是指可由基本数据导出的数据，冗

31、余的联系是指可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难，因此得到初步E-R图后，还应当进一步检查E-R图中是否存在冗余，如果存在则一般应设法予以消除。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.2 全局E-R模式但并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高某些应用的效率，不得不以冗余信息作为代价。因此在设计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。消除不必要的冗余后的初步E-R图称为基本E-R图。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设

32、计2.2.2 全局E-R模式(1) 分析方法修改、重构初步E-R图以消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。 如果是为了提高效率，人为地保留了一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.2 全局E-R模式(2) 规范化理论 除分析方法外，还可以用规范化理论来消除冗余。视图集成后形成一个整体的数据库概念结构，对该整体概念结构还必须进一步验证，确保它能够满足下列条件： 整体概念结构内部必须具有一致性，即不能存在互相矛盾的表达。 整体概念结

33、构能准确地反映原来的每个视图结构，包括属性、实体及实体间的联系。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.2 全局E-R模式 整体概念结构能满足需求分析阶段所确定的所有要求。整体概念结构最终还应该提交给用户，征求用户和有关人员的意见，进行评审、修改和优化，然后把它确定下来，作为数据库的概念结构，作为进一步设计数据库的依据。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.3 增强E-R模型E-R模型是对现实世界的一种抽象。它的主要成分是实体、联系和属性。使用这3种成分，已可以建立许多应用环境的E-R模型，但是还有一些特殊的语义，单用上述概念尚

34、无法表达清楚。为了更准确地模拟现实世界，需要扩展基本E-R模型的概念，从而导致了增强的E-R模型(Enhanced-E-R模型，EE-R模型)。增强E-R模型引入了以下几个概念。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.3 增强E-R模型 1. 特殊化（specialization）和普遍化（generalization） 如前所述，一个实体集是具有某些共性的实体的集合。这些实体一方面具有共性，另一方面还具有各自的特殊性。一个实体集可以按照某一特征区分为几个子实体集。例如学生这个实体集可以分为研究生、本科生、大专生等子集。如果需要的话，还可以把研究生这个实体集再分

35、为博士生、硕士生等子集。这是一个从普遍到特殊的过程，这个过程叫做特殊化。与特殊化相反的过程叫普遍化，即把几个具有某些共性的实体集概括成一个更普遍的实体集。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.3 增强E-R模型 例如，把研究生、本科生、大专生三个实体集概括为学生实体集，还可以把学生、教师、职工这些实体集概括为“人”这个实体集。从一般到特殊，从特殊到一般，本来就是人们认识世界实用的方法，因而在E-R数据模型中引入特殊化和普遍化这两个概念，对模拟现实世界是有用的。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.3 增强E-R模型设有实体集E

36、，如果F是E的某些真子集的集合，即F= Si | Si E，i=1,n，则称F是E的一个特殊化，E是S1、S2、Sn的超实体集，S1、S2、Sn称为E的子实体集。 如果，则称F是E的全（total）特殊化；否则，F是E的部分（partial）特殊化。如果SiSj = ，ij，则F是不相交（disjoint）的特殊化；否则，F是重叠（overlapping）的特殊化。全部分特殊化和不相交重叠特殊化是特殊化的两种重要的语义约束。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.3 增强E-R模型 普遍化是特殊化的逆过程，上述的讨论虽对特殊化而言，对普遍化也基本适用，但有一点不

37、同，设S1、S2、Sn被普遍化为超实体集G，则G一定等于，即在普遍化时，不会出现上述的部分特殊化的情况。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.3 增强E-R模型 子实体集中的实体也是超实体集的实体，但在部分特殊化时，超实体集的实体不一定都是子实体集的实体。子实体集继承（inherit）超实体集的所有属性和联系。除此以外，子实体集还可以有自己的特殊的属性和联系。例如，研究生除了继承学生的所有属性和联系外，还要增加“导师”、“学位类别”等属性以及与科研项目的联系（见图2-8）。因此、在数据模型中，引入子实体集，可以很方便地描述实体集中部分实体的特殊属性和联系。2.

38、2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.3 增强E-R模型特殊化和普遍化可用扩充的E-R图表示，图2-8是一个例子。图中，有符号的线表示特殊化，圆圈中的d表示不相交特殊化，圆圈中的o表示重叠特殊化。超实体集与圆圈的连线若是双线，则表示全特殊化；若是单线，则表示部分特殊化。在图2-8中，在职进修生既是教职工，又是学生，所以有两个超实体集，继承了两者的属性。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.3 增强E-R模型2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.3 增强E-R模型在基本E-R数据模型中，只有实体才能

39、参与联系，不允许联系参与联系。在E-R数据模型中，可以把联系看成由参与联系的实体组合而成的新的实体，其属性为参与联系的实体的属性和联系的属性的并。这种新的实体标为参与联系的实体的聚集。有了聚集这个抽象概念，联系也可以参与联系。图2-9是应用聚集的例子。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.3 增强E-R模型2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.3 增强E-R模型 3. 范畴（category） 在模拟现实世界时，有时要用到由不同类型的实体组成的实体集，例如车主这个实体集的成员可能是单位，也可能是个人。这种由不同类型实体组成的实

40、体集不同于前面所定义的实体集，为了区分起见，特别命名称之为范畴。设E1、E2、En是n个不同类型的实体集，则范畴T可定义为:T (E1E2En)。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.3 增强E-R模型 E1、E2、En也称为T的超实体集。图2-10是应用范畴的一个例子，其中账户是个范畴，可以是单位，也可以是个人。圆圈中的表示并操作。范畴也继承其超实体集的属性，但与子实体集的继承规则不一样。子实体集继承所有超实体集的属性，例如图2-8的在职进修生继承教职工和学生的所有用性。而范畴的继承是有选择性的，例如在图2-10中，如果帐户是单位，则继承单位的属性；如果帐户

41、是个人，则继承人的属性。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.3 增强E-R模型 这叫选择性继承（selective inheritance）。范畴与具有多超实体集的子实体集在形式上有些相似，但意义完全不同。范畴是超实体集并的子集，而子实体集是超实体集交的子集。例如，图2-8中在职进修生既是教职工的成员，又是学生的成员，而在图2-10中，帐户只是一个单位或个人。2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.3 增强E-R模型2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.4 图书馆管理系统的E-R模型设计以图书

42、馆管理系统为例可按以下步骤构建E-R模型：1. 设计局部E-R模式 图书馆管理系统主要包括以下几个实体：l 读者（借书证号，姓名，年龄，电话，地址，密码，E-mail，读者类别，注册日期，状态，借阅数量）l 读者类别（读者类别ID，读者类型名称，最大借阅数量，续借期限，借阅期限，权限）2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.4 图书馆管理系统的E-R模型设计l图书（图书ID，书名，作者，ISBN，中国分类号，出版日期，定价，简介）l图书管理员（管理员ID，员工号，密码，性别，年龄，职位，电话，地址，E-mail，状态）l出版社（出版社ID，出版社名，所在地，地址

43、，电话，E-mail）l读者单位（单位名称，性质，地址，电话，备注）2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.4 图书馆管理系统的E-R模型设计根据实体之间的联系，可得如下几个局部E-R模式图：2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.4 图书馆管理系统的E-R模型设计2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.4 图书馆管理系统的E-R模型设计2.2 2.2 大型系统的大型系统的E-RE-R模型设计模型设计2.2.4 图书馆管理系统的E-R模型设计2.2 2.2 大型系统的大型系统的E-RE-R模型设计模

44、型设计2.2.4 图书馆管理系统的E-R模型设计2. 设计全局E-R模式图 2-16 全局E-R模式图2.3 2.3 数据库逻辑结构设计数据库逻辑结构设计逻辑结构设计阶段的任务是把概念设计阶段设计的全局概念模式转换成与选用的具体机器上的DBMS所支持的数据模型相符合的逻辑结构（包括数据库模式和外模式），并对其进行优化。逻辑结构设计一般分为三步进行： 1. E-R模型向关系模型转换 主要是将概念模型转换成一般的关系模式，也就是将E-R图中的实体、联系及属性转化为关系模式。在转化过程中会遇到如下问题：2.3 2.3 数据库逻辑结构设计数据库逻辑结构设计l 命名问题。可以使用原名，也可以重命名，但是

45、要避免重名。 l 非原子属性问题。非原子属性问题可将其进行纵向和横行展开。l 联系转换问题。联系可用关系表示。2.3 2.3 数据库逻辑结构设计数据库逻辑结构设计 2. 关系数据模型的优化 数据库逻辑设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还应该适当修改数据模型的结构，提高查询的速度。 3. 关系视图设计 关系视图的设计又称为外模式的设计，也叫用户模式设计，是用户可直接访问的数据模式。同一系统中，不同用户可有不同的关系视图。关系视图来自逻辑模式，但在结构和形式上可能不同于逻辑模式，所以它不是逻辑模式的简单子集。2.3 2.3 数据库逻辑结构设计数据库逻辑结构设计2.3.1 E

46、-R模型向关系模型转换 关系模型的逻辑结构是一组关系模式的集合。而E-R图则是由实体、实体的属性和实体之间的联系三个要素组成的。所以将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式，这种转换一般遵循如下原则：2.3 2.3 数据库逻辑结构设计数据库逻辑结构设计2.3.1 E-R模型向关系模型转换(1) 一个实体转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。(2) 一个联系转换为一个关系模式。与该联系相连的各实体的码以及联系的属性均转换为该关系的属性。该关系的码有三种情况： 如果联系为1:1，则每个实体的键都是关系的候选键。 如果联系为1

47、:n，则n端实体的键是关系的键。 如果联系为n:m，则各实体键的组合是关系的码或关系码的一部分。2.3 2.3 数据库逻辑结构设计数据库逻辑结构设计2.3.1 E-R模型向关系模型转换(3) 三个或三个以上实体间的一个多元联系在转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。2.3.2 关系数据模型的优化关系数据模型的优化通常以规范化理论为指导，方法如下：1. 确定范式级别 考查关系模式的函数依赖关系，确定范式等级，逐一分析各关系模式，考查是否存在部分函数依赖，传递函数依赖等，确定它们分别属于第几范式。2.3 2.3 数据库逻辑

48、结构设计数据库逻辑结构设计2.3.2 关系数据模型的优化2. 实施规范化处理 确定范式级别后，利用规范化理论，逐一考察各个关系模式，根据应用要求，判断它们是否满足规范要求，可用已经介绍过的规范化方法和理论将关系模式规范化。 综合以上数据库的设计过程，规范化理论在数据库设计中有如下几方面的应用： （1）在需求分析阶段，用数据依赖概念分析和表示各个数据项之间的联系。 （2）在概念结构设计阶段，以规范化理论为指导，确定关系码，消除初步E-R图中冗余的联系。 （3）在逻辑结构设计阶段，从E-R图向数据模型转换过程中，用模式合并与分解方法达到规范化级别。2.3 2.3 数据库逻辑结构设计数据库逻辑结构设

49、计2.3.2 关系数据模型的优化 3. 模式评价与改进(1)模式评价关系模式的规范化不是目的而是手段，数据库设计的目的是最终满足应用需求。因此，为了进一步提高数据库应用系统的性能，还应该对规范化后产生的关系模式进行评价、改进，经过反复多次的尝试和比较，最后得到优化的关系模式。模式评价的目的是检查所设计的数据库模式是否满足用户的功能要求、效率，确定加以改进的部分。模式评价包括功能评价和性能评价。2.3 2.3 数据库逻辑结构设计数据库逻辑结构设计2.3.2 关系数据模型的优化 功能评价 功能评价指对照需求分析的结果，检查规范化后的关系模式集合是否支持用户所有的应用要求。关系模式必须包括用户可能访

50、问的所有属性。在涉及多个关系模式的应用中，应确保联接后不丢失信息。如果发现有的应用不被支持，或不完全被支持，则应该改进关系模式。发生这种问题的原因可能是在逻辑结构设计阶段，也可能是在系统需求分析或概念结构设计阶段。是哪个阶段的问题就返回到哪个阶段去，因此有可能对前两个阶段再进行评审，解决存在的问题。2.3 2.3 数据库逻辑结构设计数据库逻辑结构设计2.3.2 关系数据模型的优化 在功能评价的过程中，可能会发现冗余的关系模式或属性，这时应对它们加以区分，搞清楚它们是为未来发展预留的，还是某种错误造成的，比如名字混淆。如果属于错误处置，进行改正即可，而如果这种冗余来源于前两个设计阶段，则也要返回

51、重新进行评审。2.3 2.3 数据库逻辑结构设计数据库逻辑结构设计2.3.2 关系数据模型的优化 性能评价 对于目前得到的数据库模式，由于缺乏物理设计所提供的数量测量标准和相应的评价手段，所以性能评价是比较困难的，只能对实际性能进行估计，包括逻辑记录的存取数、传送量以及物理设计算法的模型等。美国密执安大学的TTeorey和JFry于1980年提出的逻辑记录访问(Logical Record Access，LRA)方法是一种常用的模式性能评价方法。LRA方法对网状模型和层次模型较为实用，对于关系模型的查询也能起一定的估算作用。 有关LRA方法读者可以参考有关书籍。2.3 2.3 数据库逻辑结构设

52、计数据库逻辑结构设计2.3.2 关系数据模型的优化(2)模式改进根据模式评价的结果，对已生成的模式进行改进。如果因为系统需求分析、概念结构设计的疏漏导致某些应用不能得到支持，则应该增加新的关系模式或属性。如果因为性能考虑而要求改进，则可采用合并或分解的方法。 合并 如果有若干个关系模式具有相同的主键，并且对这些关系模式的处理主要是查询操作，而且经常是多关系的查询，那么可对这些关系模式按照组合使用频率进行合并。这样便可以减少联接操作而提高查询效率。2.3 2.3 数据库逻辑结构设计数据库逻辑结构设计2.3.2 关系数据模型的优化 分解 为了提高数据操作的效率和存储空间的利用率，最常用和最重要的模

53、式优化方法就是分解，根据应用的不同要求，可以对关系模式进行垂直分解和水平分解。 水平分解是把关系的元组分为若干子集合，定义每个子集合为一个子关系。对于经常进行大量数据的分类条件查询的关系，可进行水平分解，这样可以减少应用系统每次查询需要访问的记录数，从而提高了查询性能。2.3 2.3 数据库逻辑结构设计数据库逻辑结构设计2.3.2 关系数据模型的优化 垂直分解是把关系模式的属性分解为若干子集合，形成若干子关系模式。垂直分解的原则是把经常一起使用的属性分解出来，形成一个子关系模式。这样，便减少了查询的数据传递量，提高了查询速度。 垂直分解可以提高某些事务的效率，但也有可能使另一些事务不得不执行连

54、接操作，从而降低了效率。因此是否要进行垂直分解要看分解后的所有事务的总效率是否得到了提高。垂直分解要保证分解后的关系具有无损连接性和函数依赖保持性。2.3 2.3 数据库逻辑结构设计数据库逻辑结构设计2.3.2 关系数据模型的优化 经过多次的模式评价和模式改进之后，最终的数据库模式得以确定。逻辑设计阶段的结果是全局逻辑数据库结构。对于关系数据库系统来说，就是一组符合一定规范的关系模式组成的关系数据库模型。 数据库系统的数据物理独立性特点消除了由于物理存储改变而引起的对应程序的修改。标准的DBMS例行程序应适用于所有的访问，查询和更新事务的优化应当在系统软件一级上实现。这样，逻辑数据库确定之后，

55、就可以开始进行应用程序设计了。2.3 2.3 数据库逻辑结构设计数据库逻辑结构设计2.3.3 图书管理系统的基本表设计由图书管理系统的E-R图（见图2-16），可以转换为以下的几个关系模式：l 读者（借书证号、用户名、密码、注册日期、姓名、年龄、电话、地址、E-mail、读者类别、借阅数量、状态）l 图书管理员（管理员ID、员工号、密码、性别、年龄、职位、电话、地址、E-mail、状态）l 图书（图书ID、书名、作者、ISBN、中图分类号、出版社、出版日期、定价、上架时间、简介）2.3 2.3 数据库逻辑结构设计数据库逻辑结构设计2.3.3 图书管理系统的基本表设计l 借阅（借阅ID、借出日期

56、、归还日期、续借次数、续借日期、超期时间、超期费用）l 读者类型（读者类型ID、读者类别名称、借阅数量、借阅期限、续借期限、权限）l 读者单位（单位名称、职位、地址、电话、备注）l 出版社（出版社ID、出版社名、所在地、地址、电话、E-mail）2.3 2.3 数据库逻辑结构设计数据库逻辑结构设计2.3.3 图书管理系统的基本表设计根据图书管理系统的关系模式，可得数据库的七个表如下：2.4 2.4 使用使用PowerDesignerPowerDesigner进行概念模型设计进行概念模型设计PowerDesigner是Sybase公司推出的一个集成了企业架构分析，UML(统一建模语言)，和数据建

57、模的CASE(计算机辅助软件工程)工具。利用PowerDesigner可以制作数据流程图、概念数据模型、物理数据模型，可以生成多种客户端开发工具的应用程序，而且可以满足管理，系统设计，开发等相关人员的使用。下面简单介绍PowerDesigner在数据库设计方面的应用。2.4 2.4 使用使用PowerDesignerPowerDesigner进行概念模型设计进行概念模型设计2.4.1 PowerDesigner 简介 1. 数据库设计常用模型 很多时候，数据库设计中概念模型和逻辑模型区别比较模糊，比如在数据库设计工具ERWIN中只提供了逻辑模型和物理模型，而在PowerDesigner早期版本

58、中也只提供了概念模型和物理模型两种模型，只是在PowerDesigner15版本中提供了三种模型：概念模型、逻辑模型、物理模型。逻辑模型主要是使得整个概念模型更易于理解，同时又不依赖于具体的数据库实现，使用逻辑模型可以生成针对具体数据库管理系统的物理模型。2.4 2.4 使用使用PowerDesignerPowerDesigner进行概念模型设计进行概念模型设计2.4.1 PowerDesigner 简介但是逻辑模型并不是在整个步骤中必须的，最终的目的是得到数据库的物理模型，所以一般在使用PowerDesigner进行数据库建模时，最常用的就是概念模型和物理模型，可以直接通过概念模型来生成物理

59、模型。图2-24是PowerDesigner 15中新建模型的窗口，可见其支持的模型相当丰富。2.4 2.4 使用使用PowerDesignerPowerDesigner进行概念模型设计进行概念模型设计2.4.1 PowerDesigner 简介2.4 2.4 使用使用PowerDesignerPowerDesigner进行概念模型设计进行概念模型设计2.4.1 PowerDesigner 简介PowerDesigner 除了进行数据库建模以外，还可以建业务模型、UML 模型等，比起其它专业建模工具，PowerDesigner 在这些模型的建立上并没有看出有什么明显的优势，而它的强项就是数据库

60、建模。 另外PowerDesigner还支持数据流图、数据迁移模型和 UML 类图等，由于篇幅原因，本书并不打算一一详解 PowerDesigner 的所有功能，只重点介绍概念模型和物理模型。2.4 2.4 使用使用PowerDesignerPowerDesigner进行概念模型设计进行概念模型设计2.4.1 PowerDesigner 简介 2. 数据库设计一般过程 (1) 进行概念模型设计 数据库建模最先是要建立概念模型，概念模型是一个抽象的宏观层次的业务模型，最常用的是“实体-联系”图。所以在概念模型中最重要的对象是实体（Entity）和联系（Relationship）。2.4 2.4