Table of Contents

第七章数据库设计和E-R模型

E-R数据模型提供了一个找出在数据库中表示的实体以及实体之间如何关联的方法。最终，数据库设计将会表示为一个关系数据库设计和一个与之关联的约束集合。

7.1 设计过程概览

7.1.1 设计阶段

数据库设计的最初阶段需要完整的刻画出未来数据库用户的数据需求 ===> 用户需求规格说明书
- 用户需求规格说明书（specification of function requirement）中，用户描述将在数据上进行的各类操作，包括：增删改查
概念设计（conceptual-design）阶段：设计者选择数据模型，并采用所选数据模型的概念将这些需求转换为数据库的概念模式。概念设计阶段所产生的模式提供了一个对企业的详细综述。======> E-R 图
- 通常使用E-R模型来表示概念设计。
- 概念模式定义了数据库中表示的实体，属性，实体之间的联系，以及实体和联系上的约束
- 完善的概念模式还指明企业的功能需求。在这个阶段要确保所有数据需求都被满足，还要检查和去除设计的冗余。
从抽象数据模型到数据库实现的转换过程在最后两个设计阶段中进行
- 逻辑设计阶段（logical-design phase）: 设计者将高层概念模式映射到将使用的数据库系统的实现数据模型上。实现数据模型通常是关系数据模型，该阶段通常包括将实体-联系模型定义的概念模式映射到关系模式
- 物理设计阶段（physical-design phase）：该阶段指明数据库的物理特征，这些特征包括：文件组织格式和索引结构的选择。

7.1.2 设计选择

数据库设计的主要部分是：决定如何在设计中表示各种类型的“事物”。

实体Entity：指示所有可明确识别的个体，如：教师、学生、系、课程和开课记录

联系Relationship：表示实体之间的关联

设计数据库模式时要避免的两个主要缺陷：

冗余：包含重复信息
- 冗余导致维护困难，信息容易变得不一致
- 如：开课记录关系中不仅包括课程id，还包括课程的名称；课程关系中也包括了课程id和名称。
不完整：不好的设计可能会使得某些信息无法建模
- 例如：只用开课记录来维护课程信息，而不单独创建课程关系，会导致无法展示未开课的课程。

另外，数据库设计过程中还需要在很多好的设计中选择一个。

7.2 实体-联系模型

实体-联系（Entity-Relationship) 数据模型的提出旨在方便数据库设计，它是通过允许定义代表数据库全局逻辑结构的企业模式实现的。

E-R模型采用了三个基本概念：

实体集
联系集
属性

7.2.1 实体集

实体（Entity）：是现实世界中可区别于所有其他对象的一个“事物”或“对象”。例如：大学中的每个人都是一个实体。

实体集（Entity Set）：相同类型即具有相同性质（或属性）的一个实体集合。例如：大学中所有的老师可以定义为实体集instructor

外延（extension）：实体集的外延指属于实体集的实体的实际集合。例如：大学中实际老师的集合构成了实体集instructor的外延

属性（attribute）：实体通过一组属性来表示。属性是实体集中每个成员所拥有的的描述性性质。例如：instructor实体集可能具有属性ID，name等

值（Value）：每个实体的每个属性都有一个值

数据库包含一组实体集，每个实体集包括任意数量的相同类型的实体。

7.2.2 联系集

联系（relationship）：指多个实体之间的相互关联。例如：可以定义关联教师Katz和学生Shankar的联系advisor，这一联系指明Katz是Shankar的导师。

联系集（relationship set）: 相同类型的联系的集合。

参与（participate）：实体集之间的关联称为参与，例如：实体集E1，E2, ..., En参与了联系集R。

E-R模式中的一个联系实例（relationship instance）表示在所建模的现实世界企业中命名实体间的一个关联。

实体在联系中扮演的功能称为实体的角色（role）。

同样的实体集以不同的角色参与一个联系集多于一次，这类联系集被称作自环的（recursive）联系集。这类联系集需要现实指明实体的角色，即：他们是如何参与到联系中的。

例如：联机集：课程的先修课程-显示的指明每个实体扮演的角色，是课程，还是先修课程

联系集也可以具有描述性属性（descriptive attribute）。

例如：实体集instructor合student之间的联系集advisor，可以具备date属性，描述教师称为学生的导师的起始时间。

二元（binary）联系集：即联系集有两个参与的实体集组成

度（degree）：参与联系集的实体集的数目称为联系集的度。二元联系集的度是2，三元联系集的度是3。

7.2.3 属性

域（domain）/值集（value set）：每个属性都有一个可取值的集合，称为该属性的域，或者值集。

正规的说，实体集的属性是将实体集映射到域的函数。一个实体集可以具有多个属性。

E-R模型中的属性可以按照如下的属性类型来进行划分：

简单（simple）和复合（composite）属性：
- 简单属性不能进行进一步划分为更小的属性
- 复合属性可以划分为更小的属性，如：地址可以划分为国家，省，市等。
  - 复合属性是可以具有层次的，因为其子属性也可以进一步划分。
单值（single-valued）和多值（multivalued）属性
- 单值属性要求实体集中的每个特定实体都只有一个单独的值。如：一个学生只能由一个student_ID
- 一个实体的某个属性可能具有多个值，这种属性是多值属性。如：一个教师可能有多个电话号码phone-number，那么phone_number就是一个多值属性。
  - 我们用{phone_number}表示多值属性
  - 我们可以对多值属性设置数目的上、下界，如：要求单个老师的电话号码限制在2个以内。
派生属性（derived）：这类属性的值可以从别的相关属性或实体派生出来。
- 例如，instructor中的年龄属性age，可以从date_of_birth中推算出来。则date_of_birth是基属性，age是派生属性。

空值null：可以表示属性的值未知或者不存在。

7.3 约束

7.3.1 映射基数

映射基数（mapping cardinality）或基数比率：表示一个实体通过一个联系集能关联的实体的个数。

对于实体集A和B之间的二元联系集R来说，映射基数必然是以下情况之一：

一对一（one-to-one）: A中一个实体至多与B中一个实体相关联，反之亦然。
一对多（one-to-many）：A中的一个实体可以与B中任意数目的实体关联，而B中的实体至多与A中的一个实体关联
多对一（many-to-one）：A中的一个实体至多与B中的一个实体相关联，而B中的实体可以与A中的任意数目的实体相关联。
多对多（many-to-many）: A中的实体可以与B中任意数目的实体关联，B中的实体也可以与A中任意数目的实体相关联

7.3.2 参与约束

如果实体集E中的每个实体都参与到联系集R的至少一个联系中，实体集E在联系集R中的参与称为全部的（total）。例如：图7-5 a中的B

如果实体集E中只有部分实体参与到联系集R的至少一个联系中，实体集E在联系集R中的参与称为部分的（partial）。例如：图7-5a中的A

7.3.3 码

码可以用来唯一的标识实体，同样可用于唯一的标识联系。

一个实体的属性的值必须可以唯一表示该实体，即：一个实体集没有两个实体在所有属性上的取值都相同。2.3节介绍的关系的超码、候选码和主码的概念同样适用于实体集。

超码（superkey）：是一个或多个属性的集合，这些属性的组合可以唯一标识一个元组。超码的任意超集也是超码。

候选码（candidate key）：如果该超码的任意真子集都不能成为超码，那么该集合就是候选码。

主码（primary key）：代表被数据库设计者选中的，主要用来在一个关系中区分不同元组的候选码。

主码应该选择那些值从不或者很少发生变化的属性。

联系集的码：

设R是一个涉及实体集E1，E2，..., En的联系集。设primary-key(Ei)代表构成时提及Ei的主码的属性。假设所有主码的属性名是不同的。联系集R 的主码的构成依赖于同联系集R相关联的属性集合。

如果联系集R没有属性与之关联，那么属性集合

primary-key(E1)∪primary-key(E2)∪...∪primary-key(En)

构成了集合R中的一个联系

如果联系集R中有属性a1,a2,...,am与之关联，那么属性集合

primary-key(E1)∪primary-key(E2)∪...∪primary-key(En)∪{a1,a2,...,am}

构成了集合R中的一个联系

以上两种情况，属性集合primary-key(E1)∪primary-key(E2)∪...∪primary-key(En)组成了联系集的一个超码

如果实体集间主码的属性名称有重复，那么需要重命名以作区分。

联系集的主码依赖于联系集的映射基数。

若由A和B组成的联系集是多对多的：则primary-key(A)∪primary-key(B)组成联系集的主码
若由A和B组成的联系集是一对多的：则primary-key(B)组成联系集的主码
若由A和B组成的联系集是一对一的：则primary-key(A)或primary-key(B)都可以作为联系集的主码

7.4 从实体集中删除冗余属性

联系集可能会导致不同实体集中的属性冗余，此时需要将冗余属性从原始实体集中删除。

例如：

instructor(ID, name, dept_name, salary)
department(dept_name, building, budget)

如果构建联系集inst_dept(ID, dept_name)，那么dept_name在instructor中就是冗余的，我们需要将其删除。

这是因为一个instructor可以属于多个系，所以我们需要构建联系集；如果一个教师只能属于一个系，我们不需要构建联系集，继续保持原有的结构即可。

7.5 实体-联系图

7.5.1 基本结构

分成两部分的矩形：代表实体集；本书中有阴影的部分包含实体集的名字；第二部分包含实体集中所有属性的名字。
菱形：代表联系集
未分割的矩形：代表联系集的属性。构成主码的属性以下划线标注
线段：将实体集连接到联系集
虚线：将联系集属性连接到联系集
双线：显示实体在联系集中的参与度
双菱形：代表连接到弱实体集的标志性联系集

7.5.2 映射基数

用不同箭头可以表示一对一，一对多，多对一，和多对多

更复杂的表示方法表示映射基数

l..h表示：l是最小映射基数，h是最大映射基数。最小值1表示这个实体集在该联系集中全部参与。

例如：下图表示了一个学生必须要有且仅有一个导师。student的映射基数为1，instructor的映射基数为0...*表示advisor表示教师可以拥有0或多个学生。

7.5.3 复杂的属性

下图说明了如何表达复杂属性。

其中name，adress，street均为复合属性；

phone_number为多值属性；

age为派生属性

7.5.4 角色

我们通过在菱形和矩形之间的连线上进行标注来表示角色。

7.5.5 非二元的联系集

7.5.6 弱实体集

弱实体集（weak entity set）：没有足够的属性以形成主码的实体集称为弱实体集

强实体集（strong entity set）：有主码的实体称为强实体集。

例如：

course(course_id, title, credits)
section(sec_id, semester, year, course_id)

在这种情况下，section中(sec_id, semester, year, course_id)作为主码，若没有course_id, 则剩余属性不足以作为主码，但是course_id又关联于course实体集。所以section是弱实体集，而course是强实体集。

弱实体集必须与另一个称作标识（identifying）或属主属性（owner entity set）的实体集关联才能有意义。每个弱实体必须与一个标识实体关联，即：弱实体集存在依赖（existence dependent）于标识实体集。

我们称标识实体集拥有（own）它所标识的弱实体集。将弱实体集与标识实体集相联的联系称为标识性联系（identifying relationship）。

标识性联系是从弱实体集到标识实体集多对一的，并且弱实体集在联系中的参与是全部的。标识性联系集不应该有任何描述性属性，因为这种属性中的任意一个都可以与弱实体集相关联。

分辨符（discriminator）+ 标识实体集的主码==>弱实体集的主码

例如：section的主码由分辨符（sec_id, semester, year）和course_id组成。

注意:虽然我们可以让sec_id是不重复的，但是section在概念上仍然依赖于section，通过使之成为弱实体可以明确这种依赖关系。

当弱实体集属性不多时，我们可以将一个弱实体集表示为属主实体集的一个多值复合属性；当弱实体集属性较多是，建模时将其表示为弱实体集更恰当。

7.5.7 大学的E-R图

7.6 转换为关系模式

可以将E-R数据库模式转换为一个关系模式的集合。关系集合名即为相应的实体集或联系集的名称。

7.6.1 具有简单属性的强实体集的表示

设E是只具有简单描述属性a1,a2,..., an的强实体集，则可以用具有n个不同属性的模式E来表示这个实体。该模式的关系中的每个元组同实体集E的一个实体对应。

强实体集的主码==> 生成的模式的主码

例如：图7-15中

classroom(building, room_number, capacity)

department(dept_name, building, budget)

course(course_id, title, credits)

instructor(ID, name, salary)

student(ID, name, tot_ cred)

7.6.2 具有复杂属性的强实体集的表示

当一个强实体集具有复合属性时，我们并不为复合属性自身创建一个单独的属性。

例如： instructor的name，由first_name, middle_name, last_name组成； instructor的address由 street, city, state和zip

_code组成，street又由street_number, street_name, apt_number组成。

instructor就可以设计为：instructor(ID, first_name, middle_name, last_name, street_number, street_name, apt_number, city, state, zip_code, date_of_birth);

对于一个多值属性M，构建关系模式R，该模式包含一个对应于M的属性A，已经对应于M所在的实体集或联系集的主码的属性。

例如：instructor中每个实体可以具有多个phone_number，那么可以构建instructor_phone(ID, phone_number)存储多值属性

如果一个实体集只有两个属性的情况下——一个主码B和一个多值属性M——那么该实体机的关系模式中只包含一个属性，即：主码B。此时，可以删掉这个关系，同时保留具有属性B和对应M的属性A的关系模式。

例如：time_slot关系中time_slot_id是主码，且它只有一个多值属性。那么，可以设计为：time_slot(time_slot_id, day, start_time, end_time)

7.6.3 弱实体集的表示

设A是具有属性a1, a2,..., am的弱实体集，设B是A所依赖的强实体集，设B的主码包括属性b1, b2,..., bn。

我们用名为A的关系模式表示弱实体集A，该模式的每个属性对应一下集合中的一个成员：{a1, a2,..., am}∪{b1,b2,...,bn}

关系模式A的主码为：弱实体集的分辨码+A所依赖的参照关系B的主码

例如：弱实体集section(sec_id, semester, year) ，sec_id, semester和year是其分辨码；它参照course中的course_id，

那么可以用下面的关系模式进行表示section（sec_id, semester, year, course_id）

7.6.4 联系集的表示

设R是联系集，a1, a2,..., am表示所有参与R的实体集的主码的并集构成的属性集合。设R的描述性属性（如有）为b1,b2,..,bn。

==> 可以用名为R的关系模式来表示该联系集，{a1,a2,...,am}∪{b1, b2,...,bn}

如何为二元联系集选择主码？

多对多：参与关系的所有实体集的主码属性的并集作为主码
一对一：任何一个实体集的主码都可以作为主码
一对多/多对一：联系集中“多”的一方的主码作为联系集的主码

如何为n元联系集选择主码？

对于边上没有箭头的n元联系集，所有参与实体集的主码属性的并集作为主码
对于边上有一个箭头的n元联系集，不在“箭头”侧的实体集的主码属性为模式的主码。（注意：一个联系集外只允许有一个箭头）

我们还在关系模式R上建立外码约束，R中来自Ei的主码属性的那些属性参照表示关系模式Ei的主码。

例如：advisor为例，它参照instructor和student；

由于该联系集没有属性，它只具有s_id和i_id，分别是student和instructor的主码。
由于student和instructor是多对一的，所以advisor的主码为s_id
另外，需要为s_id和i_id建立外码约束

7.6.4.1 模式的冗余

连接弱实体集和相应强实体集的联系集比较特殊：这样的联系集是多对一的，且没有描述性属性，并且弱实体集的主码包括强实体集的主码。

==》一般情况下，这类联系集的模式是冗余的，在基于E-R图的关系数据库设计时不必给出。

例如：section弱实体集，course强实体集，以及联系它们的sec_course联系集。==> sec_course模式是冗余的。

7.6.4.2 模式的合并

考虑从实体集A到实体集B的一个多对一的联系集AB。用前面的关系-模式构建算法===》得到三个模式A，B，AB。

进一步假设A在该联系集中的参与是全部的，即：A中的每个实体a都必须参与到联系集AB中。

那么==》可以将A和AB模式合并成单个包含两个模式所有属性的并集的模式。其主码是其模式中融入了联系集模式的那个实体集的主码。

例如：图7-15

inst_dept: inst_dept可以和instructor合并==> instructor(ID, name, dept_name, salary)
stud_dept：stud_dept可以和student合并===> student(ID, name, dept_name, cred)
course_dept: course_dept可以和course合并===> course(course_id, title, dept_name, credits)
sec_class: sec_class可以和section合并===> section(course_id, sec_id, semester, year, building, room_number)
sec_time_slot: sec_time_slot可以和上一步产生的section合并===> section(course_id, sec_id, semester, year, building, room_number, time_slot_id)

在一对一联系的情况下，联系集的关系模式可以跟参与联系的任何一个实体集的模式合并。

7.7 实体-联系设计问题

7.7.1 用实体集还是用属性

例如：instructor的phone_number，我们既可以通过属性表示phone_number，也可以通过实体集表示phone_number

这两种定义的差别是什么呢？

将其作为属性时，表示一个教师只能由一个电话号码
将其看成一个实体时，允许每个教师有多个电话号码，还允许描述电话的额外信息，如：location等。

至于如何选择，则取决于具体的应用设计。

但是，与之相对的是，将name视作一个实体是不合适的，从概念上讲不具有说服力。

具体是作为属性还是作为实体，需要具体问题具体分析，和应用场景有很大的关系。

常见的错误：

将一个实体集的主码作为另一个实体集的属性。例如: 将student_id作为instructor的属性，是不合适的。用advisor维护关系则更直观容易理解。
将相关实体集的主码属性作为联系集的属性。例如：student_id和instructor_id作为advisor的属性，这是不合适的，因为联系集中已经隐含的包含了这两个主码属性。

7.7.2 用实体集还是用联系集

将一个对象表现为实体集还是联系集有时并不那么显而易见。

例如：

可以用takes 联系集可以被用来表示学生选择课程（的某一次开课）建模。
也可以用registration的实体集表示课程-注册记录，再用两个联系集section_reg和student_reg分别表示registration与course和student的关联。

但是具体哪种方式合适，应该取决于实际应用。如果注册办公室通过课程-注册记录与其他信息相关联，那么最好让其成为一个实体。否则，takes会更紧凑，

在决定用实体集还是联系集时可以用的一个准则是：

当描述发生在实体间的行为时采用联系集。

7.7.3 二元还是n元联系集

数据库中的联系通常是二元的，非二元的关系实际上也可以通过多个二元关系来很好的表示。

例如：可以创建一个三元关系parent，来表示一个孩子的父母；也可以使用两个二元关系mother和father表示孩子的父母。

事实上，一个非二元的（n，n>2）联系集总可以用一组不同的二元联系集来替代。

例如：一个抽象的三元联系集R，它将实体集A，B，C联系起来。用实体集E替代联系集R，并创建三个联系集RA，RB，RC，如下图：

在概念可以限制E-R模型只包含二元联系集，但是这种限制是有缺点的：

对于未表示联系集而创建的实体集，我们可能不得不为其创建一个标识属性。该标识属性和额外所需的那些联系集增加了设计的复杂程度以及对总的存储空间的需求。
n元联系集可以更清晰的表示几个实体集参与单个联系集
有可能无法将三元联系集的约束变为二元联系集上的约束。例如：一个约束表明R是从A，B到C多对一的；即：来自A和B上的每一对实体最多与一个实体C相关联。这种约束就不能用联系集RA，RB和RC的基数约束表示

7.7.4 联系属性的布局

一个联系的映射基数比率会影响联系属性的布局。因此，一对一或一对多联系集的属性可以放到一个参与该联系的实体集中，而不是放到联系集中。

7.8 扩展的E-R特性

扩展的E-R特性：特化、概化、高层和低层实体集、属性继承和聚集

7.8.1 特化

实体集可能包含一些子集，子集中的实体在某些方面区别于实体集中的其它实体。例如：person可分为employee和student两类；学生student可分为undergraduate和graduate。

特化（specialization）：在实体集内部进行分组的过程称为特化。

一个实体集可以根据多个可区分的特征进行特化。

特化可分为：

重叠特化（overlapping specialization）：一个实体可以属于多个特化实体集，使用不相交的空心箭头表示。例如：一个 person可以既是employee也是student
不相交特化（disjoint specialization）：一个实体只能至多属于一个特化实体集，使用相交的一个空心箭头表示。例如：一个student只能是graduate或者是undergraduate中的一种。

7.8.2 概化

特化 - 自顶向下的(top-down)

概化(generalization) - 自底向上的(bottom-up)，是一个高层实体集与一个或多个低层实体集间的包含关系。

高层和低层的实体集可称作超类（superclass）和子类（subclass）。

概化和特化的区别主要在于它们的出发点和总体目标：

特化是从单一的实体集出发，通过创建不同的低层实体集来强调同一实体集中不同实体之间的差异。低层实体集可以有不适用于高层实体集中所有实体的属性，也可以参与到不适用于高层实体集中所有实体的联系中。设计者采用特化的原因正是为了表达这些与众不同的特征
概化则是基于这样的一种认识：一定数量的实体集共享一些共同的特征。概化是在这些共性的基础上将它们综合成一个高层实体集。概化用于强调低层实体集之间的相似性并隐藏它们的差异。

7.8.3 属性继承

属性继承（attribute inheritance）：由特化和概化所产生的高层和低层实体的一个重要特征是属性继承。高层实体集的属性被低层实体集继承。

例如：employee继承了person的所有属性

低层实体集同时还继承地参与其高层实体/超类所参与的联系集。

例如：person和department有person_dept联系集。那么person的子类实体集student，employee，instructor和secretary都与department隐式的参与到person_dept联系中。

===》规则：

高层实体集所关联的属性和联系适用于它的所有低层实体集
低层实体集特有的性质仅适用于特定的低层实体集

图7-21是实体集的层次结构（hierarchy）。在层次结构中，给定的实体集作为低层实体集只参与到一个ISA联系中，即：具有单继承（single inheritance）。

如果一个实体集作为低层实体集参与到多个ISA联系中，则该实体具有多继承（multiple inheritance），且产生的结构成为格(lattice)。

7.8.4 概化上的约束

数据库设计者需要在特定概化上设置某些约束，包括：

判定哪些实体能够成为给定低层实体集的成员:
- 条件定义的（condition-defined）：在条件定义的低层实体集中，成员资格的确定基于实体是否满足一个显示的条件/谓词
  - 例如：满足student_type="研究生"，则属于graduate；student_type=“本科生”，则属于undergraduate
- 用户定义的（user-defined）：用户定义的低层实体集不是由成员资格条件定义的，而是由数据库用户将实体指派给某个实体类。
  - 例如：大学雇员3个月试用期通过后被认为分派到到4个小组中的一个。
一个实体是否可以属于多个低层实体集
- 不相交的（disjoint）：不相交约束要求一个实体至多属于一个低层实体集。
  - 例如：student实体在student-type上只能满足一个条件，要么是本科生要么是研究生
- 重叠（overlapping）：同一个实体可以属于同一个概化中的多个低层实体集
  - 例如：一个employee员工可以被分配到多个工作组中
概化的完全性约束（completeness constraint）：定义高层实体集中的一个实体是否必须至少属于该概化/特化的一个低层实体集。
- 全部概化（total generalization）/ 全部特化（total specialization）：每个高层实体必须属于一个低层实体集
- 部分概化（partial generalization）/部分特化（partial specialization）：允许一些高层实体不属于任何低层实体集。

部分概化是默认的。但是可以在E-R图中表示全部概化：

在图中加上关键词total，并画一条从关键词到相应的空心箭头（表示不相交概化）的虚线；

或者画一条到空心箭头集合（表示重叠概化）的虚线

7.8.5 聚集

如图7-22：

eval_for：表示对student， project，instructor和evaluation之间的关系。
proj_guide：表示student，project和instructor之间的联系。

按照这种方法是有冗余信息存在的，因为在eval_for中的每个student，project和instructor肯定也在proj_guide中。

如果evaluation是一个值而不是一个实体，我们可以将其作为proj_guide一个多值属性；

然而，如果evaluation和其他实体关联时，则不能采用这样方法。

解决上述问题===>聚集（aggregation）

聚集：是一种抽象，通过这种抽象，联系作为高层实体。

例如：我们将proj_guide联系集看成一个名为proj_guide的高级实体集，即：一个聚集。如下图所示，我们就可以在proj_guide和evaluation之间构建一个二元关系，来对这种情况进行表达。

7.8.6 转化为关系模式

7.8.6.1 概化的表示

为高层实体集创建一个模式，为低层实体集创建一个模式。例如：

person(ID, name, street, city)

employee(ID, salary)

student(ID, tot_cred)

此时，高层实体集的主码也是低层实体集的主码属性。低层实体集的主码也具有外码约束，参照高层实体集的关系的主码。

如果概化是不相交且完全的——如果不存在同时属于两个同级的低层实体集的实体，且如果高层实体集的任何实体也都是某个低层实体集的成员，则可以采用另一种方式：
- 不为高层实体集创建任何模式，只为低层实体集创建一个模式。例如：

employee(ID, name, street, city, salary)

student(ID, name, street, city, tot_cred)

缺点：
- 定义外码约束
  - 例如: 如果person有一个联系集R，那么在这种情况下R需要参照两个关系，即：employee和student都有外码约束。但是如果是使用第一种方法，则可以只与person做外码约束。
- 如果这种方法用于重叠概化，某些值就会被存储多次。
- 如果概化是不相交的但不是全部的，那么就需要一个额外的模式person去存储那些既不属于employee也不属于student的实体，这样就是第一种方法一样。

7.8.6.2 聚集的表示

聚集的表示是很直接的。例如7-23中，eval_for的模式包含：对应实体集evaluation的主码+联系集proj_guide主码+描述性属性。

聚集的主码是定义该聚集的联系集的主码。不需要使用单独的关系来表示聚集；而使用从定义该聚集的联系创建出来的关系就可以了。

7.9 数据建模的其它表示法

E-R图和UML图均可应用于对数据建模进行图形化表示。

E-R图还没有一个统一的规范。

7.9.1 E-R图的其它表示法

7-24列出来本书中E-R图用过的符号。7-25列出来一部分广泛可用的E-R图符号

7.9.2 统一建模语言UML

统一建模语言（Unified Modeling Language, UML），是由对象管理组织(Object management group, OMG)支持开发的一个标准，它是为了建立软件系统不同部分的规范定义而提出的。UML的组成部分：

类图class diagram: 类图和E-R图类似。
用例图use case diagram：说明了用户和系统之间的交互，特别是用户所执行的任务中的每一步操作。
活动图Activity diagram：说明了系统不同部分之间的任务流
实现图implementation diagram：在软件结构图和硬件构建层说明了系统的各组成部分以及它们之间的联系

本节主要介绍类图。

+，-，#分别表示共有、私有和受保护的访问。
UML中，联系集称为关联（association）

下图列出来UML类图和E-R图表示法的对比和等价表示。

值得注意的是基数约束那个子图，表示的是E2到E1是多对一的！！！

E1边上的约束0..*表示，每个E1实体可以参与多个关系；即：一个E1可以对应多个E2。

E2边上的约束0..1表示，每个E2实体至多可以参与一个关系，即：一个E2可以对应一个E1。

7.10 数据库设计的其他方面

7.10.1 数据约束和关系数据库设计

SQL可以表达多种数据约束，包括：主码约束、外码约束、check约束、断言和触发器。约束的最重要的一个目的是为了自动保持数据的一致性。

数据约束在确定数据的物理结构时也同样有用：可以将彼此紧密关联的数据存储在磁盘上邻近的区域，以便在磁盘访问时提高效率。当索引建立在主码上时，索引结构工作的很好。

每次数据库更新时，执行约束会在性能上带来潜在的高代价。

7.10.2 使用需求：查询、性能

数据库系统的性能非常重要，性能不仅和计算能力的有效利用以及所使用的存储硬件有关，而且受到与系统交互的人的效率、以及依赖数据库数据的处理效率的影响。

度量效率的两个方法：

吞吐量（throughput）——每单位时间能够处理的查询或更新（通常指事务）的平均数量
响应时间（response time）——单个事务从开始到结束所需的平均时间或者最长时间。

以批量的方式处理大量事务的系统更关注高吞吐量。

与人交互或者时间苛责的系统则更关注响应时间。

查询和性能会影响数据库的设计。例如：索引能够加快查询，但同时也会影响更新的速度。

7.10.3 授权需求

授权索引同样会影响数据库的设计。不同用户对不同视图具有不同的访问权限，如何进行数据划分和存储非常重要。

7.10.4 数据流、工作流

工作流：表示一个流程中的数据和任务的组合。

数据库不仅可以存储工作流操作的数据，还可以存储工作流自身的数据，包括：工作流的任务以及它们在用户之间移动的路径。

在数据库设计时，不仅需要理解数据的语义，还要理解业务流程。

7.10.5 数据库设计的其它问题

一个好的数据库设计能够考虑到将来的需求和变化，尽量避免或最小化由预计或有可能发生的改变而导致的改动。

区分预期持久的基本约束和预期要改变的约束非常重要。

如何协调多个数据库之间的交互也需要考虑。

总结

数据库设计主要涉及到数据库模式的设计。E-R数据模型是一个广泛用于数据库设计的数据模型。它提供了一个方便的图形化表示方法以查看数据、联系和约束
E-R模型主要用于数据库设计过程。它的发展是为了帮助数据库设计，这是通过允许定义企业模式（Enterprise schema）实现的。这种企业模式代表数据库的全局逻辑结构，该逻辑结构可以用E-R图表示。
实体（entity）是在现实世界中存在并区别于其他对象的对象。我们通过把每个实体同描述该实体的一组属性相关联来表示区别。
联系（relationship）是多个实体的关联。
相同类型的联系的集合称为联系集（relationship set）；相同类型的实体的集合称为实体集（entity set）。
属于超码（superkey），候选码（candidate key）和主码（primary key）不仅适用于关系模式，也适用于实体和联系集。在确定一个联系集的主码时要小心，因为它由来自一个或多个相关的实体集的主码组成
映射的基数（mapping cardinality）：表示通过联系集可以和另一个实体相关联的实体的个数。
不具有足够属性构成主码的实体称为弱实体集（weak entity set）。具有主码的实体集称为强实体集（strong entity set）。
E-R图的各种性质为数据库设计者提供了大量的选择，使得设计人员可以最好的表示被建模的企业。在某些情况中，概念和对象可以用实体、联系和属性来表示。企业总体结构的某方面可以用弱实体集、概化、特化或聚集很好的描述。设计者通常需要在简单的，紧凑的模型与更精确但也更复杂的模型之间进行权衡。
用E-R图定义的数据库设计可以用关系模式的集合来表示。数据库的每个实体集合联系集都有唯一的关系模式与之对应，其名称即为相应的实体集或联系集的名称。这是从E-R图转换为关系数据库设计的基础。
特化（specialization）和概化（generalization）定义了一个高层实体集合一个或多个低层实体集之间的包含关系。特化是取出高层实体集的一个子集来形成一个低层实体集；概化是用两个或多个不相交的低层实体集的并集形成一个高层实体集。高层实体集的属性被低层实体集继承。
聚集（aggregation）是一种抽象，其中联系集被看做高层实体集，并且可以参与联系
UML是一种常用的建模语言，UML类图广泛的用于对类建模以及一般的数据建模

《数据库系统概念》学习笔记——第七章 数据库设计和E-R模型

第七章 数据库设计和E-R模型