设计过程概览
1. 设计阶段
·最初阶段：刻画未来数据库用户的数据需求，产品为用户需求规格说明；
·概念设计阶段（conceptual-design phase）：（关注描述抽象数据及其联系，通常使用实体-联系模型）
概念模式：定义数据库中表示的实体、实体的属性、实体之间的联系以及实体和联系上的约束。
概念设计阶段需要完成
1. 选择数据模型，并采用所选数据模型的概念将需求转化为数据库的概念模式
2. 指明企业的功能需求，完善概念模式：在功能需求规格说明（specification of functional requirement）中描述在数据上进行的各类操作/事务。
设计者检查概念模式确保功能需求满足、所有数据需求都满足且互相不冲突；
·逻辑设计阶段（logical-design phase）：将（通常以实体-联系模型定义）高层概念模式映射到数据库系统的（通常为关系数据模型的）实现数据模型上。
·物理设计阶段（physical-design phase）：指明数据库的物理特征（包括文件组织格式和索引结构的选择）。
2. 设计选择
设计数据库模式时必须避免两个主要缺陷：
·冗余：重复存储信息；
·不完整
实体-联系模型
数据库的设计主要涉及数据库模式的设计。E-R数据模型是一个广泛用于数据库设计的数据模型，提供了一个方便的图形化表示方法以查看数据、联系和约束。
实体-联系（entity-relationship, E-R）模型采用三个基本概念：实体集、联系集、属性。
1. 实体集
数据库包括一组实体集，每个实体集包括任意数量的相同类型的实体。
实体是在现实世界中存在并且区别于其他对象的对象。我们通过把每个实体痛描述该实体的一组属性相关联来表示区别。相同类型的实体的集合为实体集。
实体（entity）：现实世界中可区别于所有其他对象的一个”事物“或”对象“。每个实体有一组性质，其中一些性质的值可以唯一地标识一个实体。实体可以是实在或抽象的。
实体集（entity set）：相同类型（具有相同性质/属性）的一个实体集合。(e.g. 一所给定大学的所有教师的集合定义为实体集instructor)
实体集不必互不相交。(e.g. 一个person实体可以是instructor实体、或student实体、或既是instructor实体又是student实体、或都不是。)
外延（extension）：实体集的外延指术语实体集的实体的实际集合。(e.g. 大学中实际教师的集合构成了实体集instructor的外延)
属性（attribute）：实体集中每个成员所拥有的描述性性质。
实体通过一组属性来表示；
为某实体集指定一个属性表明数据库为该实体集中每个实体存储相似的信息，但每个实体在每个属性上都有各自的值（value）。
2. 联系集
联系是多个实体间的关联。相同类型的联系的集合为联系集。
联系（relationship）：多个实体间的相互关联。
联系集（relationship set）：相同类型联系的集合。
联系集是n≥2个（可能相同的）实体集上的数学关系。联系集R是
{ (e1, e2, …, en) | e1∈E1, e2∈E2, …, en∈En } 的一个子集，其中E1, E2, …, En为实体集，(e1, e2, …, en)为一个联系。
参与：实体集之间的关联。(e.g. 实体集E1, E2, …, En参与（participate）联系集R。)
相同的实体集可能会参与到多于一个联系集中。
二元（binary）联系集：设计两个实体集的联系集。数据库系统中的大部分联系集都是二元的，有时联系集会涉及多于两个实体集。
度（degree）：参与联系集的实体集的数目称为联系集的度。(e.g. 二元联系集的度为2，3元联系集的度为3。)
角色（role）：实体在联系中扮演的功能称为实体的角色。（隐含，一般并不指定。）
在自环（recursive，i.e. 同样的实体集以不同角色参与一个联系集多于一次）联系集中，有必要使用显式的角色名指明实体是如何参与联系实例的。
联系也可具有描述性属性（descriptive attribute）。(e.g. 实体集instructor和student之间的联系集advisor，可将属性date作为描述性属性与该联系关联。)
联系实例（relationship instance）：E-R模式中的一个联系实例表示所在建模的现实世界企业中命名实体的一个关联。(e.g. 一个教师ID为45565的instructor实体Katz和一个学生ID为12345的student实体Shankar参与到advisor的一个联系实例中)
给定的联系集中的一个联系实例必须是由其参与实体唯一标识的（不必使用描述属性）。
3. 属性
域（domain）/值集（value set）：每个属性都有的一个可取值的集合。
实体集的属性是将实体集映射到域的函数，每个实体可以用一组（属性，数据值）对来表示。
E-R模型中的属性可进行如下划分：
·简单（simple）属性/复合（composite）属性：
简单属性不能划分为更小的部分；
复合属性可以划分为更小的部分（其他属性）。(e.g. 属性name可设计为一个包括first_name、middle_initial和last_name的复合属性) 复合属性可以有层次，子属性可进一步划分。
·单值（single-alued）属性/多值（mutivalued）属性：
单值属性对一个特定的实体都只有单独的一个值；
多值属性对一个特定的实体有对应的一组值。用花括号表示属性是多值的。(e.g. instructor实体集可有{ phone_number }属性，每个教师可以有0到多个电话号码。) 可对多只属性的取值数目设置上、下界。
·派生（derived）属性：可从别的相关属性或实体派生出来。(e.g. instructor实体集可有属性student_advised表示一个教师指导了多少个学生，可通过统计与一个教师相关联的所有student实体的数目来得到该属性的值) 派生属性的值不进行存储，而是在需要时计算出来。
基属性：存储的属性
约束
1. 映射基数
映射基数（mapping cardinality）/基数比率：表示一个实体通过一个联系集能关联的实体的个数。（可用于描述二元联系集和涉及多于两个实体集的联系集）
对于实体A和B之间的二元联系集R，映射基数必然是以下情况之一：
·一对一（one-to-one）：A中的一个实体至多与B中的一个实体相关联，B中的一个实体也至多与A中的一个实体相关联；
·一对多（one-to-many）：A中的一个实体可与B中任意数目（0到多个）实体相关联，B中的一个实体至多与A中的一个实体相关联；
·多对一（many-to-one）：A中的一个实体至多与B中的一个实体相关联，B中的一个实体可与A中任意数目实体相关联；
·多对多（many-to-many）：A中的一个实体可与B中任意数目实体相关联，B中的一个实体可与A中任意数目实体相关联。
2. 参与约束
如果实体集E中的每个实体都参与到联系集R的至少一个联系中，实体集E在联系集R中的参与称为全部的（total）；
如果实体集E中只有部分实体参与到联系集R的联系中，实体集E到联系集R的参与称为部分的（partial）。
3. 码
一个实体的属性值必须可以唯一标识该实体。（在一个实体集中不允许两个实体对于所有属性都具有完全相同的值）
码：实体的码是一个足以区分每个实体的属性集。（关系模式汇总的超码、候选码、主码同样适用于实体集）
术语超码（superkey）、候选码（candidate key）以及主码（primary key）同适用于关系模式一样适用于实体集合联系集。
码也可用于唯一地标识联系。
设一个涉及实体集E1, E2, …, En的联系集R，primary-key(Ei)代表构成实体集Ei的主码的属性集合（假设实体集中所有主码属性名互不相同）。
a. 如果R没有属性与之相关联，则属性集合
primary-key(E1)∪primary-key(E1)∪…∪primary-key(En)
描述了集合R中的一个联系；
b. 如果R有属性a1, a2, …, am与之相关联，则属性集合
primary-key(E1)∪primary-key(E1)∪…∪primary-key(En)∪{ a1, a2, …, am }
描述了集合R中的一个联系。
在以上两种情况中，属性集合
primary-key(E1)∪primary-key(E1)∪…∪primary-key(En)
构成了联系集的一个超码。(如果实体集中主码属性名有重名情况可重命名构成唯一名称以区分。)
联系集的主码结构依赖于联系集的映射基数。
e.g. 考虑实体集instrutor、student和具有属性date的联系集advisor。
a. 假设联系集是多对多的，则advisor的主码由instructor和student的主码的并集组成；
b. 如果联系是从student到instructor多对一的，则student的主码就是advisor的主码；
c. 如果联系是从instructor到student多对一的，则instructor的主码就是advisor的主码；
d. 如果联系集是一对一的，则两个候选码中的任意一个可用作主码。
4. 从实体集中删除冗余属性
建立实体间的联系集，可能会导致不同实体集中的属性冗余，则需要将冗余的属性从原始实体集中删除，用E-R设计中的联系代替冗余的属性。
e.g.
关系模式设计：
实体集instructor (ID, name, dept_name, salary);
实体集department (dept_name, building, budget);
分析：
属性dept_name在实体集instructor中冗余，移除。
实体-联系设计：
实体集instructor (ID, name, salary);
实体集department (dept_name, building, budget);
联系集inst_dept关联instructor和department。
类似，实体集student中不需要dept_name属性，联系集student_dept关联student和department。
e.g.
关系模式设计：
实体集section (course_id, sec_id, semester, year, building, room_number, time_slot_id);
实体集time_slot (time_slot_id, { (day, start_time, end_time) } );
实体集classroom (building, room_number, capacity);
分析：
属性time_slot_id在实体集section中冗余，移除。
属性{ building, room_number}在实体集section中冗余，移除。
实体-联系设计：
实体集section (course_id, sec_id, semester, year);
实体集time_slot (time_slot_id, { (day, start_time, end_time) } );
实体集classroom (building, room_number, capacity);
联系集sec_time_slot关联section和time_slot；
联系集sec_class关联section和class。
实体-联系图
E-R模型主要用于数据库设计过程，它的发展是为了帮助数据库设计，这是通过允许定义企业模式（enterprise schema）实现的。这种企业模式代表数据库的全局逻辑结构，该全局结构可用E-R图（E-R diagram）图形化地表示。
E-R图（E-Rdiagram）可图形化表示数据库的全局逻辑结构。
1. 基本结构
E-R图的主要构件：
·分割为两部分的矩形：代表实体集。第一部分（有阴影）包含实体集的名字，第二部分包含实体集中所有属性的名字；
·菱形：代表联系集；
·未分割的矩形：代表联系集的属性。构成主码的属性以下划线标明；
·线段：将实体集连接到联系集；
·虚线：将联系集属性连接到联系集；
·双线：显示实体在联系集中的参与度；
·双菱形：代表连接到弱实体集的标志性联系集。
e.g.
2. 映射基数
二元联系集可以是一对一、一对多、多对一或多对多的，联系集和实体集之间画箭头或线段以区分这些类型。
·一对一：当实体集A中的一个实体最多只能与实体集B中的一个实体关联，并且实体集B中的一个实体也最多只能与实体集A中的一个实体关联时，从联系集向实体集A和B各画一条箭头；
·一对多：当实体集A中的一个实体可与实体集B中任意数目的实体关联，但实体集B中的一个实体最多只能与实体集A中的一个实体关联时，从联系集向实体集A画一条箭头，向实体集B画一条线段；
·多对一：当实体集A中的一个实体最多只能与实体集B中的一个实体关联，但实体集B中的一个实体可与实体集A中任意数目的实体关联时，从联系集向实体集A画一条线段，向实体集B画一条箭头；
·多对多：当实体集A中的一个实体可与实体集B中任意数目的实体关联，实体集B中的一个实体也可与实体集A中任意数目的实体关联时，从联系集向实体集A和B各画一条线段。
e.g.
（一对多：一名教师可以指导多名学生，但一名学生可以至多有一位导师。）
E-R图提供描述“每个实体参与联系集中联系的次数约束”的方法：
实体集和二元联系集之间的一条边可以有一个关联的最大和最小的映射基数，用l..h表示。其中l为最小映射基数，h为最大映射基数。
l=1时表示这个实体集在该联系集中全部参与（每个实体在联系集中的至少一个联系中出现）；
h=1时表示这个实体参与至多一个联系；
最大值为*，表示没有限制。
e.g. 约束每个学生必须有且仅有一个导师，教师可以有零个或多个学生。
（从instructor到student的一对多联系，student在advisor联系中的参与是全部的。）
另一种画法：在基数约束的位置画一条从student到advisor的双线，以及一条从advisor到instructor的箭头。
3. 复合属性、多值属性、派生属性的表示
e.g.
实体集instructor包含：
复合属性name，由子属性first_name、middle_initial和lastname组成；
复合属性address，由子属性street、city、state和zipcode组成，其中street也是符合属性，其子属性为street_number、street_name和apartment_number；
多值属性phone_number，由{ phone_number }表示；
简单属性date_of_birth；
派生属性age，由{ aget( ) }表示。
4. 角色
通过在菱形和矩形之间的连线上进行标注来表示角色。
e.g. course实体集合prereq联系集之间的角色标识course_id和prereq_id
5. 非二元联系集
e.g. 三个实体集instructor、student和project通过联系集proj_guide相关联。
在非二元联系集中可表示某些类型的多对一联系。(e.g. 假设一个student在每个项目上最多只能有一位导师，可用从project_guide的边指向instructor的箭头表示。)
在一个非二元联系集外包含两个或更多箭头的E-R图可有两种解释：
（假设实体集A1, A2, …, An之间有联系集R，并且只有指向实体集Ai+1, Ai+2, …, An的边是箭头。）
a. 来自A1, A2, …, Ai的实体的一个特定组合可以与至多一个来自Ai+1, Ai+2, …, An的实体组合相关联。因此联系R的主码可用A1, A2, …, Ai的主码的并集来构造。
b. 对于每个实体集AK, i<k≤n, 来自其他实体集的实体的每个组合可以和来自AK的至多一个实体相关联。因此对于i<k≤n，每个集合{ A1, A2, …, Ak-1, Ak+1, …, An }构成一个候选码。
因为以上两种解释在不同的书/系统中使用，为避免混淆，我们规定在一个非二元联系集外只允许有至多一个箭头。
6. 弱实体集
弱实体集（weak entity set）：不具有足够的属性构成主码的实体集。
有主码的实体集则称作强实体集（strong entity set）。
e.g.
情况：
实体集section由course_id, semester, year, sec_id唯一标识；
实体集course 由course_id唯一标识；
（i.e. 不同course的section可能会有相同的sec_id、year和semester。）
联系集sec_course关联section和course。
分析：
因为section已有属性course_id，sec_course中信息冗余。
如果删除联系sec_course会使section和course的联系隐含于一个属性中，不合适。
如果删除section中的属性course_id，则剩下的属性不足以唯一标识一个指定的section实体；
处理方法：
删除section中的属性course_id，标志性联系sec_course关联弱实体集section与其标识实体集course，
给唯一标志的section实体提供额外信息course_id。
标识实体集（identifying entity set）/属主实体集（owner entity set）：一个弱实体集必须与一个标识实体集关联才有意义。每个弱实体集必须和一个标识实体关联。
弱实体集存在依赖（existence dependent）于标识实体集，标识实体集拥有（own）它所标识的弱实体集。
标志性联系（identifying relationship）：将弱实体集与其标识实体集相联的联系。
标志性联系是从弱实体集到标识实体集多对一的，弱实体集在联系中参与是全部的。
标志性实体集不应该有任何描述性属性。
分辨符（discriminator）：弱实体集的分辨符，也成为弱实体集的部分码，是用于区分依赖于特定强实体集的弱实体集中的实体的属性集合。
e.g. 弱实体集section的分辨符{ sec_id, year, semester }，对每个course来说，该属性集唯一标识了该course对应的一个section。（用于区分同一course的不同section实体）
弱实体集的主码由标识实体集的主码加该弱实体集的分辨符构成。
e.g. 弱实体集section的主码{ course_id, sec_id, year, semester }由标识实体集course的主码course_id加其分辨符{ course_id, sec_id, year, semester }构成。
E-R图中，弱实体集以矩形表示（类似强实体集），其分辨符以虚下划线标明，关联弱实体集和标识性强实体集的联系集以双菱形表示。双线表示参与是全部的。
e.g. 弱实体集section通过联系集sec_course依赖于强实体集course，弱实体集section在联系sec_course中的参与是全部的，每次section与单门course相关联。
弱实体集可以参与标识性联系以外的其他联系；
弱实体集可以作为属主与另一个弱实体集参与一个标识性联系；
一个弱实体集可能与不止一个标识实体集关联（i.e. 一个特定的弱实体将被一个实体的组合标识，其中每个标识实体集有一个实体在该组合中，弱实体集的主码则由标识实体集的主码的并集加弱实体集的分辨符组成）。
如果弱实体集只参与标识性联系，并且属性不多，则建模时适合将其表示为属主实体集的一个多值复合属性；
如果若实体集参与到标识性联系以外的联系中，或属性较多，则建模时适合将其表示为弱实体集。
E-R图转换为关系模式
对于每个实体集/联系集，都有唯一的关系模式与之对应，关系模式名为相应的实体集或联系集的名称。所以，一个符合E-R数据库模式的数据库可表示为一些关系模式的集合。
1. 具有简单属性的强实体集的表示
设E为只具有n个简单描述性属性的强实体集，则用具有n个不同属性的关系模式E表示。
关系中的每个元组都对应于实体集中的一个特定实体。
如果实体集为强实体集，则其转换得到的关系模式的主码就是强实体集的主码。
2. 具有复杂属性的强实体集的表示
如果强实体集具有复合属性，关系模式中不为复合属性自身创建一个单独的属性，而为复合属性的每个子属性创建一个单独的属性。
e.g.
对于复合属性name，模式包括first_name, middle_initial, lastname，没有单独的属性表示name;
对于复合属性address，模式包括street, city, state, zip_code，因为street是一个复合属性，将其替换为子属性street_number, street_name, apt_number。
多值属性不能直接映射到相应关系模式的属性上，需要为多值属性创建新的关系模式。
对于实体集的一个多值属性M，构建关系模式R，该模式包含一个对应于M的属性A以及对应于M所在的实体集或联系集的主码的属性。
R的主码由其所有属性组成。
R上外码约束：由M所在实体集的主码所生成的属性参照M所在实体集所生成关系。
e.g. 实体集Instructor主码为ID，包含多值属性phone_number。为phone_number构建关系模式：
instructor_phone(ID, phone_number)。Instructor_phone关系上有外码约束：属性ID参照instructor关系。
特殊情况：实体集只有两个属性，一个主码B和一个多值属性M。则该实体集的关系模式只包含一个属性（主码属性B）。也可删掉该关系，保留具有属性B和对应M的属性A的关系模式。）
e.g. 实体集time_slot含主码time_slot_id和多值复合属性{day, start_time, end_time}，可生成关系模式time_slo t(time_slot_id, day, start_time, end_time)。
派生属性不在关系模式中显示表示，可在类似对象-关系数据模型的其他数据模型中表示为方法。
3. 弱实体集的表示
设A为具有属性a1, a2, …, am的弱实体集，B为A所依赖的强实体集，B的主码包括属性b1, b2, …, bn。则：关系模式A的每个属性对应集合{ a1, a2, …, am }∪{ b1, b2, …, bn }的一个成员；
该模式的主码由B的主码与A的分辨符组成；
关系A上建立外码约束：属性b1, b2, …, bn参照关系B的主码。（保证弱实体的每隔元组都有一个表示相应强实体的元组与之对应）。
可添加外码约束上的级联删除规范，如果弱实体集A依赖的强实体集B中的一个实体被删除，那么所有与它关联的A实体也被删除。
4. 联系集的表示
设R为联系集，a1, a2, …, am为所有参与R的实体集的主码的并集构成的属性集合，b1, b2, …, bn为R的描述性属性。则关系模式R的每个属性对应集合{ a1, a2, …, am }∪{ b1, b2, …, bn }的一个成员。
二元联系集关系模式主码的选择：
·多对多：参与实体集的主码属性的并集；
·一对一：任意一个实体集的主码；
·多对一或一对多：联系集中“多”的那一方实体集的主码。
n元联系集关系模式主码的选择（联系集外至多允许一个箭头）：
·边上没有箭头：所有参与实体集的主码属性的并集；
·边上有一个箭头：不在“箭头”侧的实体集的主码属性；
对于每个与联系集R相关的实体集Ei，建立一个关系模式模式R上的外码约束：R中来自Ei主码属性的那些属性参照关系模式Ei的主码。
模式的冗余
连接弱实体集与其所依赖的强实体集的联系集比较特殊，一般情况下其关系模式冗余，在基于E-R图的关系数据库设计中不必给出。
模式的合并
设从实体集A到实体集B的一个多对一联系集AB，构建三个关系模式A、B、AB。如果A在该联系中的参与是全部的（i.e. 实体集A中的每个实体都参与到联系AB中），则可将模式A和模式AB合并为单个包含两个模式所有属性并集的模式。合并后模式的主码为被合并的那个实体集的主码。
e.g.
从instructor到department的联系集inst_dept。
instructor { ID, name, salary };
department { dept_name, building, budget };
inst_dept {ID, dept_name };
模式instructor可与模式Inst_dept合并，得到模式instructor{ ID, name, dept_name, salary }。
即使实体集A在联系中的参与是部分的，也可使用控制来进行模式的合并。(e.g. 例中如果instructor在inst_dept部分参与，可为没有相关联的department的instructor在属性dept_name中存放空值。)
合并后，舍弃联系集上参照实体集A的外码约束，将参照实体集B的外码约束加到合并后的关系模式中。(e.g. 例中将原inst_dept上dept_name属性参照department的外码约束加到合并后的insructor关系中。)
如果联系是一对一的，联系集的关系模式可以跟参与联系的任何一个实体集的关系模式合并。
实体-联系设计问题
1. 用实体集还是用属性
e.g. 给instructor增加phone的两种方法
如果希望保存电话的额外信息（位置、类型、共享改电话的所有的人等），将电话看做实体的建模方式根据有通用性。
常见错误1：用一个实体集的主码作为另一个实体集的属性，而不是用联系。×
应当明确表示出实体集之间的关系，而不是将关系隐含在属性中。
e.g.
将student的ID作为instructor的属性（即使一对一）×
将advisor联系代表student和instructor之间的关联。√
常见错误2： 将相关实体集的主码属性作为联系集的属性。×
因为在联系集中已经隐含了这些主码属性。
注意：当从E-R模式创建关系模式时，这些属性可能会出现在联系集的关系模式中，但不应该出现在E-R模式的联系集中。
e.g.
将student的ID和instructor的ID作为advisor联系的属性。 ×
2. 用实体集还是联系集
原则：当描述发生在实体间的行为时采用联系集。
e.g. 用实体集registration代表课程-注册记录，替代student和section之间的联系集takes。
一般使用联系集takes更紧凑可取。如果课程-注册记录与其他信息相关联则适合作为实体集。
3. 二元还是n元联系集
一个n元(n>2)的联系集总能用一组不同的二元联系集替代。
E.g. 用实体集E和联系集RA、RB、RC替代三元联系集R。【可推广到n元联系集】
如果联系集R有属性，则将这些属性赋给实体集E，并为E创建一个特殊的标识属性（用于区分E中的各个实体）。
针对联系集R中的每个联系(ai, bi, ci)在实体集E中创建一个新的实体ei。
在三个联系集中插入联系：在RA中插入(ei, ai)；在RB中插入(ei, bi)；在RC中插入(ei, ci)。
在概念上可以限制E-R模型只包含二元联系集，但这种做法也存在一些劣势：
·对为表示联系集而创建的实体集，必须创建一个标志属性，增加了设计的复杂程度和对存储空间的需求；
·n元联系集可以更清晰地表示几个实体集参与单个联系集；
·有些三元联系集上的约束不能转变为二元联系上的约束。
4. 联系属性的布局
一个联系的映射基数的比率会影响联系属性的布局：
·一对多的联系集的属性可以从联系集中移除，放到参与联系的“多”方的实体集中；
·一对一的联系集的属性可以从联系集中移除，放到任意一个参与联系的实体集中。
e.g. 设从实体集instructor到实体集student一对多的联系集advisor，其属性date可放在student实体集中（与原先放在advisor中具有相同含义）。
设计时将描述性属性作为联系集的属性还是实体集的属性，取决于被建模企业的特点。(e.g. 例中也可选择保留date作为advisor的属性以显式表明指导关系的日期。)
（多对多）当一个属性是由参与的实体集联合确定，而不是由单独某个实体集确定时，该属性就必须放在多对多联系集中。
扩展的E-R特性
特化和概化定义了一个高层实体集和一个或多个低层实体集之间的包含关系。特化是取出高层实体集的一个子集来形成一个低层实体集。概化是用两个或多个不想交的（低层）实体集的并集形成一个高层实体集。高层实体集的属性被低层实体集继承。
1. 特化
特化（specialization）：在实体集内部进行分组的过程。
e.g. 实体集person可进一步特化为employee类和student类，特化实体集用一个包括实体集person的所有属性和可能的附加属性的属性集来描述。(employee实体可进一步用属性salary描述；student实体可进一步用属性tot_cred描述。)
一个实体集可以根据多个可区分的特征进行特化。当一个实体集形成了多于一种特化时，某个特定实体集可能同时属于多个特化实体集。
e.g. 实体集employee可根据从事工作特化，也可根于工作任期特化，因此一个特定的employee可以既是temporary_employee又是secretary_employee。
E-R图中用从特化实体指向另一方实体的空心箭头表示特化，称为ISA关系，代表”is a”。(e.g. instructor “ is a” employee.)
重叠特化（overlapping specialization）：一个实体集可能属于多个特化实体集。对于一个重叠特化(e.g. student和employee作为person的特化)，分开使用两个箭头。
不相交特化（disjoint specialization）：一个实体集必须属于至多一个特化实体集，对于一个不相交特化(e.g. instructor和secretary作为employee的特化)，使用一个箭头。
特化关系可能形成超类-子类（superclass-subclass）联系。
高层和低层实体集按普通实体集表示（包含实体集名称的矩形）。
2. 概化
概化（generalization）：高层实体集与一个或多个低层实体集间的包含关系。低层实体集间存在共性（包含相同的属性），这些属性被赋予相同的名字并由高层实体集表示。
高层与低层实体集也分别称作超类（superclass）和子类（subclass）。
概化不是特化的逆过程。特化和概化的区别在于出发点和总体目标：
特化：从单一实体集出发，通过创建不同的低层实体集来强调同一实体集中不同实体间的差异。低层实体集可以有不适用于高层实体集中所有实体的属性，也可以参与到不适用于高层实体集中所有实体集的联系中。
概化：基于“一定数量的实体集共享一些共同特征（用相同的属性描述，且参与到相同的联系集中）”。在这些实体集共性的基础上将它们总和成一个高层实体集，用于强调低层实体集间的相似性并隐藏差异。
(概化使共享属性不重复出现，表达简洁。)
3. 属性继承
属性继承（attribute inheritance）：由特化和概化所产生的高层实体和低层实体的一个重要特性，高层实体集的属性被低层实体集继承（inherit）。
属性继承适用于所有低层实体集。
e.g.
实体集person用属性ID、name和address描述；
实体集student继承person的属性，用属性ID、name和adress，以及附加属性tot_cred描述；
实体集employee继承person的属性，用属性ID、name和address，以及附加属性salary描述；
employee的子类instructor和secretary从person继承属性ID、name和address，又从employee继承属性salary。
参与继承：低层实体集（子类）也同时继承地参与其高层实体集（超类）所参与的联系集。参与继承也适用于所有低层实体集。
e.g.
实体集person和department参与person_dept联系集；
person的子类student、employee、instructor和secretary也都和department隐式地参与到person_dept联系中。
对于E-R图的一个给定部分（无论是通过特化还是概化得到的），都具有以下性质：
·高层实体集所关联的所有属性和联系适用于它所有的低层实体集；
·低层实体集特有的性质仅适用于特定的低层实体集。
在实体集的层次结构中：
如果一个实体集作为低层实体集只参与到一个ISA联系中，则称这个实体集只具有单继承（single inheritance）；
如果一个实体集作为低层实体集参与到多个ISA联系中，则称这个实体集具有多继承（multiple inheritance），且产生的结构称为格（lattice）。
4. 概化上的约束
可在特定概化上设置三类约束。
a. 涉及”判定哪些实体能成为给定低层实体集的成员”的约束。成员资格可以是下列其中一种：
·条件定义的（condition-defined）：在条件定义的低层实体集中，成员资格的确定基于实体是否满足一个显式的条件或谓词。
e.g.
设高层实体集student具有属性student_type，所有student实体都根据student_type属性进行评估；
满足条件student_type=”graduate”的实体属于graduate低层实体集；
满足条件student_type=”undergraduate”的实体属于undergraduate低层实体集。
·用户定义的（user-defined）：在用户定义的低层实体集中，由数据库用户将实体指派给某个实体集。
（负责决策的用户根据个人观点进行分配，执行将一个实体加入某个实体集的操作。）
b. 涉及”在一个概化中一个实体是否可以属于多个实体集“的约束。低层实体集可以是下列其中一种：
·不相交（disjoint）：要求一个实体至多属于一个低层实体集。
·重叠（overlapping）：同一实体可以同时属于同一概化中的多个实体集。
使用分开的箭头表示重叠概化，单个箭头表示不相交概化。
e.g.
一个person可以既是employee又是student，使用分开的箭头表示重叠概化。一个箭头从employee指向person，一个箭头从student指向person；
一个employee不能既是instructor又是secretary，使用单个箭头表示不相交概化，从instructor和secretary指向employee。
c. 对概化的完全性约束（completeness constraint）。定义高层实体集中的一个实体是否必须至少属于该概化/特化的一个低层实体集。此类约束可以是下列其中之一：
·全部概化（total generalization）或特化（specialization）：每个高层实体必须属于一个低层实体集。
·部分概化（partial generalization）或特化（specialization）：允许一些高层实体不属于任何低层实体集。
默认情况下为部分概化。如果需要表示全部概化，可在E-R图中加入关键词total，并画一条从关键词到相应空心箭头（表示不相交概化）的虚线，或画一条到空心箭头集合（表示重叠概化）的虚线。
完全性约束和不相交约束彼此没有依赖关系。
对给定概化或特化使用约束带来某些插入和删除需求。
5. 聚集
聚集是一种抽象。其中联系集（和跟它们相关的实体集一起）被看作高层实体集，并且可以参与联系。
聚集（aggregation）：将联系视为高层实体的一种抽象。高层实体集可像对任何其他实体集一样处理。
e.g.
三元联系集proj_guide关联实体集Instrucotor、student和project。四元联系集eval_for关联实体集evaluation和instructor、student、project和evaluation。
分析：
联系集proj_guide和eval_for不能合并，因为一些(instructor, student, project)组合可能没有相关联的evaluation；
存在冗余信息，eval_for中的每个(instructor, student, project)组合一定也在proj_guide中，但E-R模型存在局限，不能表达联系间的联系；
可将evaluation可作为proj_guide的一个多值属性，但如果evaluation需要和其他实体关联时不可行。
处理方法：
使用聚集，将联系集proj_guide（关联实体集instructor、student和project）看做一个名为proj_guide的高层实体集；
在高层实体集proj_guide和evaluation创建二元联系eval_for，表示某个evaluation对应哪个(student, project, instructor)组合。
6. 将扩展E-R特性转换为关系模式
1）概化
方法一 一般采用：
为高层实体集创建关系模式，属性对应高层实体集的属性；为低层实体集创建关系模式，属性对应高层实体集主码属性和低层实体集的属性。
高层实体集的主码属性既是高层实体集的主码属性，也是所有低层实体集的主码属性。
在低层实体集上建立外码约束，其主码属性参照创建自高层实体集的关系的主码。
e.g.
person (ID, name, address);
employee (ID, salary);
student (ID, tot_cred);
方法二 如果概化不相交且完全（不存在同时属于两个同级低层实体集的实体，且高层实体集的任何实体也都是某个低层实体集的成员），则采用：
不需要为高层实体集创建任何模式；只为每个低层实体集创建一个模式，模式中的属性包括高层实体集的属性和低层实体集的属性；
高层实体集的主码属性作为低层实体集的主码属性。
缺点：定义外码属性时可能存在问题，如果有与高层实体集相关的联系集，当从该联系集创建关系模式时需要建立参照高层实体集的外码约束，无法参照单一的一个关系。
e.g.
employee (ID, name, address, salary);
student (ID, name, address, tot_cred);
2）聚集
将聚集A看做整个实体集，将关联聚集与另一对应实体集B的联系集C转换为关系模式。关系模式C包含：实体集B的主码属性、定义该聚集的联系集A‘的主码属性、联系集C的任意描述性属性（如果存在）。
根据已有规则，将聚集A中的实体集和联系集A’转换为关系模式；
将聚集A看做整个实体集，根据已有规则，在于聚集A关联的联系集C上创建主码和外码约束；
只需从定义该聚集的联系集A’创建的关系模式，不需要单独的关系表示聚集A。
数据建模的其他表示法
1. E-R图的其他表示法
实体属性可放入与表示实体的方框所连接的椭圆中，主码属性以下划线标明；
联系属性可放入与表示联系的菱形所连接的椭圆中；
联系上的基数约束可用在联系外面标记*和1表示；
联系集可用实体集之间的连线表示（只能表示二元联系）。“鸦爪形”表示基数约束，连线两侧是否使用鸦爪决定联系为一对一/一对多/多对一/多对多，对侧为竖线表示全部参与，对侧为圆圈表示部分参与；
概化可用三角形代替空心箭头表示；
2. 统一建模语言UML
UML是一种常用的建模语言。UML类图广泛用于对类建模以及一般的数据建模。
统一建模语言（Unified Modeling Language, UML）：为建立软件系统的不同部分的规范定义而提出的一个标准。组成部分包括
·类图（class diagram）：类似ER图；
·用况图（use case diagram）：说明用户和系统之间的交互，特别是用户所执行任务中的每一步操作；
·活动图（activity diagram）：说明系统不同部分之间的任务流；
·实现图（implementation diagram）：在软件构件层和硬件构件层说明系统的各组成部分以及它们之间的联系。
对象：UML类图为对象建模，对象类似实体，包含属性和方法。类图可以说明对象的属性和方法。
方法：UML类图中另外提供的一组函数，可在对象属性的基础上调用以计算值，或更新对象本身。
UML类图不支持复合或多值属性，派生属性与不带参数的函数等价；
UML类图支持封装，允许函数和属性带有前缀”+”、”-“或”#”，分别表示公共、私有以及受保护的访问。私有属性只能在类的方法中使用，受保护的属性只能在类和它的子类的方法中使用。
关联（association）：在UML类图中联系集称为关联。通过画一条线段连接实体集表示二元联系集，联系集的名称写在线段附近。可用以下两种方式说明联系集：
a. 可将角色名称写在靠近实体集的线段上，说明联系集中一个实体集的角色；
b. 可将联系集的名字和属性一起写在方框里，用虚线将该方框连接到表示联系集的连线上。该方框可看作一个实体集，可与其他实体一起参与联系。
从UML1.3开始，UML支持菱形表示法表示非二元联系。即使对于二元联系，UML也允许使用菱形表示法，但大部分设计者使用线段表示法。
UML中使用l..h形式表示基数约束，i表示参与联系的实体的最小个数，h表示最大个数。但约束位置与E-R图中正好相反。
e.g.
E2边上的约束0..*和E1边上的0..1表示每个E2实体可以参与至多一个联系，而每个E1实体可以参与任意多的联系，即该联系是从E2到E1多对一的。
可将单个值（如1或*）卸载边上，单个值1等价1..1，单个值*等价0..*。
UML类图支持概化，与E-R图基本相同，包括不想交概化和重叠概化的表示方式。
UML类图还包含一些与E-R表示法并不对应的表示法。
e.g. 连接两个实体的一条线的一端有一个小菱形，表示菱形这一端的实体集包含另一个实体集(e.g. 一个车辆实体可能包含一个发动机实体)。（包含关系在UML中称为”聚合“，注意不应与E-R图中的聚合的含义混淆。）
UML类图还提供表示面向对象语言的特征的表示法（e.g. 接口）。
数据库设计的其他方面
除模式设计外，数据库设计还包含其他组成部分。
1. 数据约束和关系数据库设计
2. 使用需求：查询、性能
数据库处理效率的两个主要度量方法：（两个度量并不等价）
·吞吐量（throughput）：每单位时间里能够处理的查询或更新（通常指事务）的平均数量。
以批量方式处理大量事务的系统(e.g. 大多数商用数据库系统)通常关注于达到高吞吐量。高吞吐量的目的在于获得系统部件的高利用率，但可能会导致某些事务延迟。
·响应时间（response time）：单个事务从开始到结束所需的平均时间或最长时间。
与人交互或时间苛刻的系统（e.g. 基于Web的应用和电信信息系统的用用）通常关注与响应时间。
涉及连接的查询比不涉及连接的查询需要更多的资源用以计算，可选择创建索引以加快连接的计算；
对于查询（不论是否涉及连接），可创建索引以加速频繁出现在查询中的选择谓词（where子句）的计算；
因为更新会为维护索引的准确性而强制带来额外工作，当一个索引加速查询的同事也可能减缓更新的速度。
3. 授权需求
4. 数据流、工作流
工作流：表示一个流程中的数据和任务的组合。
当工作流在用户间移动以及用户执行他们在工作流中的任务时，工作流会与数据库系统交互。
数据库可以存储工作流操作的数据和工作流自身的数据（构成工作流的任务、在用户之间移动的路径）。
5. 数据库设计的其他问题
注意区分预期持久的基本约束和预期要改变的约束，尽量避免或最小化由预计或可能发生的改变带来的改动。
