《数据库系统概念》学习笔记——数据库设计和 E-R模型
数据库系统概念——数据库设计和 E-R模型
- 数据库设计和 E-R模型
-
- 设计过程概览
-
- 设计阶段
- 设计选择
- 实体 - 联系 模型
-
- 实体集
- 联系集
- 属性
- 约束
-
- 映射基数
- 参与约束
- 码
- 从实体集中删除冗余属性
- 实体 - 联系图
-
- 基本结构
- 映射基数
- 复杂的属性
- 角色
- 非二元的联系集
- 弱实体集
- 大学的E-R图
- 转换为关系模式
-
- 具有简单属性的强实体集的表示
- 具有复杂属性的强实体集的表示
- 弱实体集的表示
- 联系集的表示
- 实体-联系设计问题
-
- 用实体集还是用属性
- 用实体集还是用联系集
- 二元还是n元联系集
- 联系属性的布局
- 扩展的E-R特性
-
- 特化
- 概化
- 属性继承
- 概化上的约束
- 聚集
- 转换为关系模式
- 数据建模的其他表示法
-
- E-R图的其他表示法
- 统一建模语言UML
- 数据库设计的其他方面
-
- 数据约束和关系数据库设计
- 使用需求：查询、性能
- 授权需求
- 数据流、工作流
- 数据库设计的其他问题
数据库设计和 E-R模型
实体 - 联系（E-R）数据模型，提供了一个找出数据库中表示的实体以及实体间如何关联的方法。
最终，数据库设计将会表示为一个关系数据库设计和一个与之关联的约束集合。
设计过程概览
构建一个数据库应用是一个复杂的任务，包括设计数据库模式，设计访问和更新数据的程序，以及设计控制数据访问的安全模式。
用户的需求在设计过程中扮演一个中心角色。
设计阶段
一个高层数据模型为数据库设计者提供了一个概念框架，在该框架中以系统方式定义了数据库用户的数据需求，及满足这些需求的数据结构。
- 完整刻画未来数据库用户的数据需求
用户需求规格。 - 选择数据模型，采用所选数据模型的概念将这些需求转化为数据库的概念模式
在此概念设计阶段所产生的模式提供了一个对企业的详细综述。
概念模式定义了数据库中表示的实体，实体的属性，实体间的联系，实体和联系上的约束。
概念设计阶段会导致实体－联系图的构建，它提供了对模式的图形化描述。 - 功能需求
功能需求规格说明中，用户描述在数据上各类操作。
从抽象数据模型到数据库实现的转换过程在最后两个设计阶段中进行。
- 逻辑设计阶段
将概念模式转化为具体数据库的实现数据模型。 - 物理设计阶段
文件组织格式和索引结构选择。
设计选择
用实体（entity）指示所有可明确识别的个体。
各种各样的实体以多种方式互相关联，而所有这些方式都需要在数据库设计中反映出来。
在设计一个数据库模式的时候，必须确保避免两个主要的缺陷。
- 冗余
一个不好的设计可能会重复信息。
冗余也可能出现在关系模式中。
信息的这种冗余表达的最大问题是当对一条信息进行更新但没有将这条信息的所有拷贝都更新时，这条信息的拷贝会变得不一致。 - 不完整
一个不好的设计可能会使得企事业机构的某些方面难于甚至无法建模。
从多个可选设计选出一个好的，合适的。
实体 - 联系 模型
实体-联系（entity-relationship, E-R）数据模型的提出旨在方便数据库的设计，它是通过允许定义代表数据库全局逻辑结构的企业模式实现的。
E-R数据模型采用了三个基本概念：实体集、联系集、属性。
还有一个相关的图形表示：E-R图
实体集
实体是现实世界可区别于所有其他对象的一个事物或对象。
每个实体有一组性质，其中一些性质的值可以唯一地标识一个实体。
实体集是相同类型即具有相同性质（或属性）的一个实体集合。
实体集的外延指属于实体集的实体的实际集合。
实体集不必互不相交。
实体通过一组属性来表示。
属性是实体集中每个成员所拥有的描述性质。
每个实体的每个属性都有一个值（value）。
数据库包括一组实体集，每个实体集包括任意数量的相同类型的实体。
联系集
联系（relationship）是指多个实体间的相互关联。
联系集是相同类型联系的集合。
正规地说，联系集是n>=2个（可能相同的）实体集上的数学关系。
如果 E1, E2, . . . , En 为实体集，则联系集R是
{ ( e 1 , e 2 , . . . , e n ) ∣ e 1 ∈ E 1 , e 2 ∈ E 2 , . . . , e n ∈ E n } \{(e1, e2, . . ., en) | e1 ∈ E1, e2 ∈ E2, . . . , en ∈ En\} {(e1,e2,...,en)∣e1∈E1,e2∈E2,...,en∈En}
的一个子集，而(e1, e2, . . ., en)是一个联系。
实体集之间的关联称为参与；
实体集 E1, E2, . . . , En 参与 联系集R。
E-R模式中的一个联系实例（relationship instance）表示在所建模的现实世界企业中命名实体间的一个关联。
实体在联系中扮演的功能称为实体的角色（role）。
联系也可以具有描述性属性（descriptive attribute）。
给定的联系集中的一个联系实例必须是由其参与实体唯一标识的，而不必使用描述属性。
相同的实体集可能会参与到多于一个联系集中。
数据库系统中的大部分联系集都是二元的。然而，有时联系集会涉及多于两个实体集。
参与联系集的实体集的数目称为联系集的度（degree）。
二元联系集的度为2；三元联系集的度为3。
属性
每个属性有一个可取值的集合，称为该属性的域（domain）或值集（value set）。
实体集的属性是将实体集映射到域的函数。
由于一个实体集可能有多个属性，因此每个实体可以用一组（属性，数据值）对来表示，实体集的每个属性对应一个这样的对。
E-R模型中的属性可按如下属性类型进行划分：
- 简单（simple）和复合（composite）属性
简单属性，不能划分为更小的部分。
复合属性，可以再划分为更小的部分（即其他属性）。
复合属性可以是有层次的。
-
单值（single-valued）和多值（multivalued）属性
为表示一个属性是多值的，用花括号将属性名括住.
-
派生（derived）属性
这类属性的值可以从别的相关属性或实体派生出来。
派生属性的值不存储，而是在需要时计算出来。
当实体在某属性上没有值时使用空（null）值。
空值可以表示“不适用”，即该实体的这个属性不存在值。
空还可以用来表示属性值未知。
未知的值可能是缺失的（值存在，但我们没有该信息），或不知道的（我们并不知道该值是否确实存在）。
约束
映射基数
映射基数（mapping cardinality），或基数比率，表示一个实体通过一个联系集能关联的实体的个数。
对于实体集A和B之间的二元联系集R来说，映射基数必是以下情况之一：
-
一对一（one-to-one）。
Ａ中一个实体至多与B中一个实体相关联，并且B中一个实体也至多与A中一个实体相关联。 -
一对多（one-to-many）。
A中的一个实体可与B中的任意数目（零或多个）实体相关联，而B中的一个实体至多与A中的一个实体相关联。 -
多对一（many-to-one）。
Ａ中的一个实体至多与B中的一个实体相关联，B中一个实体可与A中任意数目（零或多个）实体相关联。 -
多对多（many-to-many）。
Ａ中的一个实体可与B中任意数目（零或多个）实体相关联，Ｂ中一个实体也可与A中任意数目（零或多个）实体相关联。
参与约束
如实体集E中的每个实体都参与到联系集R的至少一个联系中，实体集E在联系集R中的参与称为全部（total）的。
如果E中只有部分实体参与到R的联系中，实体集E到联系集R的参与称为部分（partial）的。
码
从概念上来说，各个实体是互异的；但从数据库的观点来看，它们的区别必须通过其属性来表明。
一个实体的属性的值必须可以唯一标识该实体。
一个实体集中不允许两个实体对所有属性都具有完全相同的值。
实体的码是一个足以区分每个实体的属性集。
关系模式的超码、候选码、主码概念同样适用于实体集。
码同样用于唯一地标识联系，并从而将联系互相区分开来。
实体集的主码使我们可区分实体集中不同的实体。
设R是一个涉及实体集 E1, E2, . . . , En 的联系集。
主码（Ei）代表构成实体集Ei的主码的属性集合。
假设所有主码属性名是互不相同的。
联系集主码构成依赖于同联系集相关联的属性集合。
如联系集R没有属性与之关联，
则属性集合
p r i m a r y − k e y ( E 1 ) ∪ p r i m a r y − k e y ( E 2 ) ∪ ⋅ ⋅ ⋅ ∪ p r i m a r y − k e y ( E n ) primary-key(E1) ∪ primary-key(E2) ∪ ··· ∪ primary-key(En) primary−key(E1)∪primary−key(E2)∪⋅⋅⋅∪primary−key(En)
描述了集合R的一个联系。
如联系集R有属性 a1, a2, . . ., am与之相关联，那么属性集合：
p r i m a r y − k e y ( E 1 ) ∪ p r i m a r y − k e y ( E 2 ) ∪ ⋅ ⋅ ⋅ ∪ p r i m a r y − k e y ( E n ) ∪ { a 1 , a 2 , . . . , a m } primary-key(E1) ∪ primary-key(E2) ∪ ··· ∪ primary-key(En) ∪ \{a1, a2, . . . , am\} primary−key(E1)∪primary−key(E2)∪⋅⋅⋅∪primary−key(En)∪{a1,a2,...,am}
描述了集合R中的一个联系。
以上两种情况下，属性集合：
p r i m a r y − k e y ( E 1 ) ∪ p r i m a r y − k e y ( E 2 ) ∪ ⋅ ⋅ ⋅ ∪ p r i m a r y − k e y ( E n ) primary-key(E1) ∪ primary-key(E2) ∪ ··· ∪ primary-key(En) primary−key(E1)∪primary−key(E2)∪⋅⋅⋅∪primary−key(En)
构成了联系集的一个超码。
如实体集间主码属性名称不是互不相同，重命名来区分；
实体集的名字加上属性名可构成唯一名称。
一个实体集多次参与某个联系集，则使用角色名代替实体集名构成唯一的属性名。
联系集的主码结构依赖于联系集的映射基数。
二元联系Ａ，Ｂ：
若Ａ到Ｂ为一对多，Ｂ的主码可作联系集主码；
若Ａ到Ｂ为多对一，Ａ的主码可作联系集主码；
若Ａ到Ｂ为一对一，Ａ／Ｂ的主码可作联系集主码；
若Ａ到Ｂ为多对多，Ａ＋Ｂ的主码可作联系集主码。
从实体集中删除冗余属性
使用E-R模型设计数据库时，通常从确定那些应当包含的实体集开始。
考虑实体集instructor和department：
- 实体集 instructor 包含属性 ID, name, dept_name, salary，其中ID为主码。
- 实体集 department 包含属性 dept_name, building, budget，其中dept_name构成主码。
用关联instructor和department的联系集inst_dept对每个教师都有一个关联的系的情况建模。
dept_name在两个实体集都出现了，且是其中一个实体集的主码，因此它在实体集 instructor 中是冗余的。需要将其移除。
一个好的实体－联系设计不包含冗余的属性。
对于大学的例子，列出实体集以及他们的属性。主码以下划线标明。
- classroom：含属性（building , room_number, capacity）
- department：含属性（dept_name, building, budget）
- course：含属性（course_id, title, credits）
- instructor：含属性（ID, name, salary）
- section：含属性（course_id, sec_id, semester, year）
- student：含属性（ID, name, tot_cred）
- time_slot：含属性（time_slot_id, {(day, start_time, end_time)}）
设计的联系集如下。
- inst_dept：关联教师和系
- stud_dept：关联学生和系
- teaches：关联教师和开课
- takes：关联学生和开课，含描述属性grade
- course_dept：关联课程和系
- sec_course：关联开课和课程
- sec_class：关联开课和教室
- sec_time_slot：关联开课和时段
- advisor：关联学生和教师
- prereq：关联课程和先修课程
实体 - 联系图
E-R 图（E-R diagram）可以图形化表示数据库的全局逻辑结构。
E-R 图既简单又清晰，这些是致使E-R模型广泛使用的重要性质。
基本结构
E-R图包括如下几个主要构件：
- 分成两部分的矩形代表实体集。
- 菱形代表联系集。
- 未分隔的矩形代表联系集所关联的属性。
- 线段将实体集连接到联系集。
- 虚线将联系集属性连接到联系集。
- 双线显示实体在联系集中的参与度。
- 双菱形代表连接到弱实体集的标志性联系集。
如果一个联系集有关联的属性，那么我们将这些属性放入一个矩形中，并且用虚线将该矩形与代表联系集的菱形连接起来。
映射基数
- 一对一
从联系集 advisor 向实体集 instructor 和 student 各画一个箭头。 - 一对多
从联系集 advisor 画一个箭头到实体集 instructor， 以及一条线段到实体集 student 。 - 多对一
从联系集 advisor 画一条线段到实体集 instructor， 以及一个箭头到实体集 student 。 - 多对多
从联系集 advisor 向实体集 instructor 和 student 各画一条线段。
E-R图还提供了一种描述每个实体参与联系集中联系的次数的更复杂的约束的方法
实体集和二元联系集之间的一条边，可有一个关联的最大和最小映射基数，用l…h形式表示，其中l表示最小的映射基数，而h表示最大的映射基数。
最小值为１表示这个实体集在该联系集中全部参与。即为每个实体至少在联系集中一个联系中出现。
最大值为１，表示实体至多参与一个联系，而最大值为*代表没有限制。
复杂的属性
角色
在E-R图中，
通过在菱形和矩形之间的连线上进行标注来表示角色。
非二元的联系集
非二元的联系集也可以在E-R图中简单地表示。
在一个联系集外至多允许一个箭头，因为在一个非二元联系集外包含两个或更多箭头的E-R图，可用两种方法解释。
假设实体集A1,A2,…,An之间有联系集R，并且只有指向实体集Ai+1,…,An的边是箭头。
则，两种可能的解释为：
- 来自A1,A2,…,Ai的实体的一个特定组合可以和至多一个来自Ai+1,…,An的实体组合相关联。
因而联系R的主码可用A1,…,Ai的主码的并集来构造。 - 对每个实体集Ak, i
弱实体集
没有足够的属性以形成主码的实体集称作弱实体集。
有主码的实体集称作强实体集。
弱实体集必须与另一个称作标识或属主实体集的实体集关联才有意义。
标识实体拥有它所标识的弱实体集。
将弱实体集与其标识实体集相联的联系称为标识性联系。
标识性联系是从弱实体集到标识实体集多对一的，并且弱实体集在联系中的参与是全部的。
标识性联系集不应该有任何描述性属性，因为这种属性中的任意一个都可以与弱实体集相关联。
例子中，section的标识实体集是course，将section实体和它们对应的course实体关联在一起的sec_course是标识性联系。
虽然弱实体集没有主码，但仍需区分依赖于特定强实体集的弱实体集中实体的方法。
弱实体集的分辨符是使得我们进行这种区分的属性集合。
例如，弱实体集section的分辨符由属性sec_id,year,semester组成。
弱实体集的分辨符也称为该实体集的部分码。
弱实体集的主码由标识实体集的主码加上该弱实体集的分辨符构成。
在E-R图中，弱实体集和强实体集类似，以矩形表示，有两点主要的区别：
- 弱实体集的分辨符以虚下划线标明，而不是实线。
- 关联弱实体集和标识性强实体集的联系集用双菱形表示。
使用双线表示全部参与；
没有箭头表示多。有箭头表示１
弱实体集可以参与标识性联系以外的其他联系。
弱实体集可以作为属主与另一个弱实体集参与一个标识性联系。
一个弱实体集也可能不止与一个标识实体集关联。
这样，一个特定的弱实体将被一个实体组合标识，其中每个标识实体集有一个实体在该组合中。
弱实体集的主码可由标识实体集的主码的并集加上弱实体集的分辨符组成。
某些情况下，
将弱实体集表示为属主实体集的一个多值复合属性。
大学的E-R图
下图展示了大学的E-R图。
增加了若干约束，以及section为弱实体。
该E-R图与大学E-R模型的文字性描述等价。
转换为关系模式
可以将一个符合E-R数据库模式的数据库表示为一些关系模式的集合。
对每个实体集及每个联系集，都有唯一的关系模式与之对应，关系模式名即为相应的实体集或联系集的名称。
用关系模式来表示E-R模式，将E-R设计中提出的约束映射到关系模式上的约束。
具有简单属性的强实体集的表示
设E是只具有简单描述性属性a1,a2,…,an的强实体集。
用具有n个不同属性的模式E来表示这个实体集。
对于从强实体集转换而来的模式，强实体集的主码就是生成的模式的主码。
具有复杂属性的强实体集的表示
我们通过为每个子属性创建一个单独的属性来处理复合属性；并不为复合属性自身创建一个单独的属性。
多值属性的处理不同于其他属性。
对于多值属性，创建新的关系模式。
派生的属性不在关系数据模型中显式地表示出来。
它们可在例如对象－关系数据模型的其他数据模型中表示为“方法”。
对于一个多值属性M，构建关系模式R，该模式包含一个对应于M的属性A，以及对应于M所在的实体集或联系集的主码的属性。
创建关系模式的主码，它由模式中的所有属性组成。
在多值属性构建的关系模式上建立外码约束，由实体集主码所生成的属性去参照实体集所生成的关系。
在一个实体集只有两个属性下——一个主码B及一个多值属性M——该实体集的关系模式只包含一个属性，即主码属性B。
可删除这个关系，同时保留具有属性B和对应M的属性A的关系模式。
弱实体集的表示
设A是有属性 a 1 , . . . , a m a_{1},...,a_{m} a1,...,am的弱实体集，设B是A所依赖的强实体集，设B的主码包括属性 b 1 , . . . , b n b_{1},...,b_{n} b1,...,bn。
用名为A的关系模式表示实体集A，该模式的每个属性对应以下集合中的一个成员：
{ a 1 , . . . , a m } U { b 1 , . . . , b n } \{a_1,...,a_m\} U \{b_1,...,b_n\} {a1,...,am}U{b1,...,bn}
对从弱实体集转换而来的模式，该模式的主码由其所依赖的强实体集的主码与弱实体集的分辨符组合而成。
除创建主码外，还要在关系A上建立外码约束，该约束指明属性 b 1 , . . . , b n b_{1},...,b_{n} b1,...,bn参照关系B的主码。
外码约束保证表示弱实体集的每个元组都一个表示相应强实体的元组与之对应。
外码约束，意思是每个元组中外码部分取值只能在外码作主码关系中，其主码值集合范围内取值。
级联删除：外码作主码的关系中删除了一个元组，用此元组主码在具有此主码作外码约束的关系中，依次删除此关系的元组外码部分和其匹配的元组。
联系集的表示
设R是联系集，设 a 1 , . . . , a m a_{1},...,a_{m} a1,...,am表示所有参与R的实体集的主码的并集构成的属性集合，设R的描述属性为 b 1 , . . . , b n b_{1},...,b_{n} b1,...,bn。
用名为R的关系模式来表示该联系集，下面集合中的每一项表示为模式的一个属性：
{ a 1 , . . . , a m } U { b 1 , . . . , b n } \{a_{1},...,a_{m}\} U \{b_{1},...,b_{n}\} {a1,...,am}U{b1,...,bn}
从所有相关实体集中取所有主码属性能够用来标识一个指定元组，但是对于一对一，多对一和一对多联系集，这会得到一个比我们所需要的主码大的属性集合。
因而如下选择主码：
- 对于多对多二元联系，参与实体集的主码属性的并集成为主码
- 对于一对一的二元联系，任何一个实体集的主码都可选作主码。
- 对于多对一或一对多的二元联系，联系集中多的那一方的实体集的主码构成主码。
- 对与边上没有箭头的n元联系集，所有参与实体集的主码属性的并集成为主码。
- 对于边上有一个箭头的n元联系集，不在“箭头”侧的实体集的主码属性为模式的主码。
在关系模式R上建立外码约束，如下：
对每个与联系集R相关的实体集 E i E_{i} Ei，建立一个关系模式R上的外码约束，R中来自 E i E_{i} Ei主码属性的那些属性参照表示关系模式 E i E_{i} Ei的主码。
模式的冗余
连接弱实体集和强实体集的联系集比较特殊。
这样的联系集是多对一的，且没有描述属性。
弱实体集的主码包含强实体集的主码。
一般情况下，连接弱实体集与其所依赖的强实体集的联系集的模式是冗余的，而且在基于E-R图的关系数据库设计中不必给出。
模式的合并
考虑从实体集A到实体集B的一个多对一的联系集AB。
用前面的关系—模式构建算法，得到三个模式：A、B、AB。
可将A和AB模式合并成单个包含两个模式所有属性的并集的模式。
合并后模式的主码是其模式中融入了联系集模式的那个实体集的主码。
在一对一的联系的情况下，联系集的关系模式可以跟参与联系的任和一个实体集的模式进行合并。
实体-联系设计问题
用实体集还是用属性
主要的差别，
一个人可能希望保存关于电话的额外信息。位置，类型等或共享该电话的所有的人时，将电话看作一个实体是一种更好的建模方式。
因此，把电话视为一个实体比把它视为一个属性的方式更具有通用性；而且当通用性可能有用的时候，这种定义方式就更为适合了。
一个常见的错误是用一个实体集的主码作为另一个实体集的属性，而不是用联系。
另一个错误是将相关实体集的主码属性作为联系集的属性。
用实体集还是用联系集
当用实体集还是联系集时，可采用的一个原则是，当描述发生在实体间的行为时采用联系集。
二元还是n元联系集
一些非二元的联系实际上可用多个二元联系更好地表示。
事实上，一个非二元的（ｎ元，n>2）联系集总可以用一组不同的二元联系集来替代。
考虑一个抽象的三元（n=3）联系集R，它将实体集A、B和C联系起来。
用实体集E替代联系集R，创建三个联系集：
R A R_{A} RA，关联E和A。
R B R_{B} RB，关联E和B。
R C R_{C} RC，关联E和C。
三元联系与三个二元联系：
如果联系集R有属性，那么将这些属性赋给实体集E；为E创建一个特殊的标识属性。
针对联系集R中的每个联系 ( a i , b i , c i ) (a_{i}, b_{i}, c_{i}) (ai,bi,ci)
在实体集E中创建一个新的实体 e i e_{i} ei
然后，在三个新联系集中，分别插入新联系如下：
- 在 R A R_{A} RA插入 ( e i , a i ) (e_{i}, a_{i}) (ei,ai)
- 在 R B R_{B} RB插入 ( e i , b i ) (e_{i}, b_{i}) (ei,bi)
- 在 R C R_{C} RC插入 ( e i , c i ) (e_{i}, c_{i}) (ei,ci)
可将这一过程直接推广到n元联系集的情况。
- 对于为表示联系集而创建的实体集，需要为其创建一个标识属性。
标识属性和额外所需的那些联系集增加了设计的复杂程度及对总的存储空间的需求。 - n元联系集可更清晰表达几个实体参与单个联系集。
- 有可能无法将三元联系上的约束变为二元联系上的约束。
例如，考虑一个约束，表明R从A、B到C多对一的；也就是来自A和B的每一对实体最多与一个C实体关联。
联系属性的布局
一个联系的映射基数比率会影响联系属性的布局。
因此，一对一或一对多联系集的属性可放到一个参与该联系的实体集中，而非放到联系集中。
一对多联系集的属性仅可以重置到参与联系的“多”方的实体集中。而对于一对一的联系集，联系的属性可以放到任意一个参与联系的实体中。
设计时将描述性属性作为联系集的属性还是实体集的属性这一决定应该反映出被建模企业的特点。
属性位置的选择在多对多联系集中体现得更清楚。
当一个属性是由参与的实体集联合确定而不是由单独的某个实体集确定时，该属性就必须放到多对多联系集中。
扩展的E-R特性
扩展E-R特性：特化、概化、高层和底层实体集、属性继承和聚集。
特化
实体集可能含一些子集，子集中的实体在某些方面区别于实体集中的其他实体。
例如，实体集中的某个实体子集可能具有不被该实体集中所有实体所共享的一些属性。
E-R模型提供了表示这种与众不同的实体组（子集）的方法。
在实体集内部进行分组的过程称为特化。
一个实体集可根据多个可区分的特征进行特化。
当一个实体集上形成了多于一种特化时，某个特定实体可能同时属于多个特化实体集。
在E-R图中，特化用从特化实体指向另一方实体的空心箭头来表示。
称这种关系为ISA关系。
它代表“is a”，表示“是一个”。
重叠特化： 一个实体集是否可能属于多个特化实体集。
不相交特化： 一个实体集是否必须属于至多一个特化实体集。
概化
从初始实体集到一系列不同层次的实体子集的细化，代表了一个自顶向下的设计过程。
设计过程也可以自底向上进行，多个实体集根据共同具有特征综合为一个较高层实体集。
实体集间包含共同属性，称为共性。
这种共性可通过概化来表达，概化是高层实体集与一个或多个低层实体集间的包含关系。
高层与低层实体集也可分别称作超类和子类。
对于所有实际应用来说，概化只不过是特化的逆过程。
特化从单一的实体集出发，通过创建不同的低层实体集来强调同一实体集中不同实体间的差异。
概化基于这样认识：一定数量的实体集共享一些共同的特征（用相同属性，参与相同联系集）。
概化是在这些实体集的共享的基础上将它们综合成一个高层实体集。
概化用于强调低层实体集间的相似性并隐藏它们的差异；由于共享属性的不重复出现，它还使得表达简洁。
属性继承
由特化和概化所产生的高层和低层实体的一个重要特性是属性继承。
高层实体集的属性被低层实体集继承。
低层实体集（或子类）同时还继承地参与其高层实体（或超类）所参与的联系集。
对E-R图的一个给定部分说，不管是通过特化还是概化得到，结果都是一样的：
- 高层实体集所关联的所有属性和联系适用于它的所有低层实体集。
- 低层实体集特有的性质仅适用于特定的低层实体集。
在层次结构中，给定的实体集作为低层实体集只参与到一个ISA联系中，即在这个图中实体集具有单继承。
如果一个实体集作为低层实体集参与到多个ISA联系中则称实体集具有多继承，且产生的结构称为格。
概化上的约束
一类约束包含判定哪些实体能成为给定低层实体集的成员。
成员资格可是下列中一种：
-
条件定义的
在条件定义的低层实体集中，成员资格的确定基于实体是否满足一个显式的条件或谓词。例如：假设高层实体集student有属性student_type。 只有满足student_type为"研究生"的实体，才允许属于graduate_student低层实体集。 由于所有实体基于同一属性评估，这种类型的概化称作是属性定义的。 -
用户定义的
用户定义的低层实体集不是通过成员资格条件来限制，而是由数据库用户将实体指派给某个实体集。例如：设大学雇员在３个月到期后，被分配到４个工作组的一个。 因此，用高层实体集employee的４个低层实体集来表示工作组。 一个给定员工，由负责决策用于根据个人观点进行工作组的分配。 该分派通过将一个实体加入某个实体集的操作而实现。
另一类约束涉及在一个概化中一个实体是否可属于多个低层实体集。
低层实体集可能是下述情况之一：
- 不相交
不相交约束要求一个实体至多属于一个低层实体集。 - 重叠
在重叠概化中，同一个实体可以同时属于同一个概化中的多个低层实体集。
假定一个人既可为雇员，又可为学生，但一个人不可雇员不可同时为教师和助理。
最后一类约束是对概化的完全性约束，定义高层实体集中的一个实体是否必须至少属于该概化/特化的一个低层实体集。
这种约束可为下述之一：
- 全部概化或特化。每个高层实体必须属于一个底层实体集。
- 部分概化或特化。允许一些高层实体不属于任何底层实体集。
在E-R，加入关键字“total”表示全部概化。
对不相交概化，画一条从关键词到相应的空心箭头的虚线。
对重叠概化，画一条到空闲箭头集合的虚线。
完全性约束和不相交约束彼此并没有依赖关系。
约束模式也可是部分-不相交或全部-重叠的。
对给定概化或特化使用约束带来某些插入和删除需求。
聚集
E-R模型的一个局限性在于它不能表达联系间的联系。
假设，每位在项目上指导学生的教师需要记录月评估报告
将评估报告建模为一个主码为evaluation_id的实体evaluation。
记录一个evalution对应的(student, project, instructor)组合的另一个方法是在instructor，student，project，evaluation间建立一个四元联系集eval_for。
一些instructor,student,project的组合是可能没有关联的evaluation 。
上述图存在冗余信息，因为在eval_for中的每个instructor，student，project组合肯定也在proj_guide中。
如果evaluation是一个值而不是一个实体，可以将evaluation作为联系集proj_guide的一个多值属性。
然而，当某个evaluation和其他实体相关联时，这方法不可行。
对类似上述情况建模的最好办法是使用聚集。
聚集是一种抽象，通过这种抽象，联系被视为高层实体。
对我们例子，将联系集proj_guide（关联实体集instructor, student, project）看成一个名为proj_guide的高层实体集。
这种实体集可像对任何其他实体集一样来处理。
这样，可在proj_guide和evaluation间创建一个二元联系eval_for来表示evaluation对于哪个(student, projec, instructor)组合。
转换为关系模式
概化的表示
为包含概化的E-R图进行关系模式设计有两种不同方法。
为了简化讨论，谈到的内容实际只包括第一层的低层实体集-employee和student。
假定ID是person的主码。
-
为高层实体集创建一个模式。
为每个低层实体集创建一个模式，模式中的属性包括对应于低层实体集的每个属性，以及对应于高层实体集主码的每个属性。高层实体集的主码属性变成既是高层实体集的主码属性也是所有低层实体集的主码属性。
另外，在低层实体集上建立外码约束，其主码属性参照创建自高层实体集的关系的主码。
上面例子中，employee的属性ID会参照person的主码，对student类似。 -
如果概化是不相交且完全的——如果不存在同时属于两个同级的低层实体集的实体，且如果高层实体集的任何实体也都是某个低层实体集的成员——那么可以采用另一种表示方法。
这时，不需要为高层实体集创建任何模式，只需为每个低层实体集创建一个模式，模式中的属性包括对应于低层实体集的每个属性，以及对应于高层实体集的每个属性。
第二种方法的一个缺点在于定义外码约束。
聚集的表示
为包含聚集的E-R图进行模式设计是很直接的。
如上图，表示聚集proj_guide和evaluation间联系的联系集eval_for的模式包含对应实体集evaluation主码中的每个属性以及联系集proj_guide主码中的每个属性。
还包含对应于联系集eval_for的任意描述属性。
聚集的主码是定义该聚集的联系集的主码。
不需要单独的关系来表示聚集；而使用从定义该聚集的联系创建出来的关系就可以了。
数据建模的其他表示法
下图总结了此前在E-R图表示法中用到的符号集。
E-R图的其他表示法
下图，列出一部分广泛使用的可选择的E-R表示法。
表示实体的属性的一种可选的方法是将它们放入与代表实体的方框所连接的椭圆形中。
主码属性以下划线表明。
统一建模语言UML
实体-联系图有助于对软件系统的数据表示部分建模。
数据表示只构成整个系统设计的一部分。其他部分包括系统用户界面的建模、系统公民模块的规范定义以及他们之间的交互等。
统一建模语言（Unified Modeling Language, UML）是由对象管理组织主持开发的一个标准，它是为了建立软件系统不同部分的规范定义而提出的。
UML的一些组成部分为：
- 类图
- 用况图
- 活动图
- 实现图
UML类图还提供了表示面向对象语言的特征的表示法，例如接口。
数据库设计的其他方面
数据约束和关系数据库设计
使用SQL可表达多种数据约束、包括主码约束、外码约束、check约束、断言和触发器。
约束用于多个目的。最明显一个是自动的一致性保持。
通过在SQL数据定义语言中表达约束，设计者能确保数据库系统自己执行这些约束。
显式声明约束的另一个优点是一些约束在关系数据库模式的设计中特别有用。
关系数据库设计的规范化方法使我们能在给定的设计是好的设计时用准确的方式进行表述，并且能把不好的设计转变为较好的设计。
从实体－联系设计开始并根据该设计规则地生成关系模式的过程给整个设计过程提供一个好的开始。
数据约束在确定数据的物理结构时同样有用，可以将彼此紧密相关的数据存储在磁盘上邻近的区域，以便在磁盘访问时提高效率。
当索引建立在主码上时，索引结构工作得更好。
每次数据库更新时，执行约束会在性能上带来潜在的高代价。
使用需求：查询、性能
性能不仅与计算能力的有效利用以及所使用的存储硬件有关，而且受到与系统交互的人的效率以及依赖数据库数据的处理的效率的影响。
效率的两个主要度量方法
- 吞吐量——每单位时间里能处理的查询或更新［通常指事务］的平均数量
- 响应时间——单个事务从开始到结束所需的平均时间或最长时间
授权需求
SQL允许在数据库逻辑设计组件的基础上将访问权限授予用户。
一个关系模式可能需分解为两个或多个模式，以便在SQL中授予访问权限。
数据流、工作流
工作流表示一个流程中的数据和任务的组合。
当工作流在用户间移动及用户执行他们在工作流中的任务时，工作流会与数据库系统交互。
除了工作流操作的数据之外，数据库还可以存储工作流自身的数据，包括构成工作流的任务以及他们在用户之间移动的路径。
因此工作流可以列出一系列对数据库的查询和更新，而这些可能会作为数据库设计过程的一个部分考虑进来。
企业建模不仅要理解数据的语义，还要理解使用这些数据的业务流程。
数据库设计的其他问题
一个组织的需求不断发展，它所需要存储的数据也会相应地发展。
模式上的改变会影响数据库应用的方方面面。
一个好的数据库设计会预先估计一个组织将来的需要，设计出的模式在需求发展时只需要做最少的改动即可满足要求。
区分预期持久的基本约束和预期要改变的约束非常重要。
数据库所服务的企业很可能会与其他企业交互，因此，多个数据库可能需要进行交互。
数据库设计在两个意义上是面向人的工作：
- 系统的最终用户是人（即使有应用教程位于数据库和最终用户之间）；
- 数据库设计者需要与应用领域的专家进行广泛交互以理解应用的数据需求。
学习参考资料：
《数据库系统概念》第6版