关系数据库设计
一、基本概念
1关系模型
表：和数学上的关系这个概念密切相关，关系数据库是表的集合。表中的一行代 表了一系列值之间的联系。
属性：表的列首被称为属性。
域：属性所允许的值。
数学上的描述
关系：可以代替“表”这个概念的数学名词。关系是元组的集合。
元组：可以代替“行”这个概念的数学名词。
元组变量:代表元组的变量，以所有元组集为域的变量。
原子的域：域的元素被看做是不可再分的单元。
超码：一个或多个属性的集合。这些属性的组合可以在一个关系中唯一标识一个元组。
候选码：最小的超码，它的任意真子集都不能构成超码。
主码：被数据库设计者选中的，用来在同一个关系中区分不同元组的候选码。
外码：一个关系模式r1的某个属性是另一个关系模式r2的主码,这个属性被称为外码。
参照关系：称r1为外码依赖的参照关系。
被参照关系：称r2为外码的被参照关系。
数据库模式：数据库的逻辑设计。
数据库实例：给定时刻数据库中数据的一个快照。
与程序设计语言类比
关系模式：相当于程序设计语言中类型定义的概念。其与关系的区别在于，关系相当于程序设计语言中变量的概念。
关系实例：对应于程序设计语言中变量的值得概念
2 实体-联系模型（E-R模型）
实体-联系模型（E-R数据模型）：基于对现实世界的这样一种认识，世界由一组称为实体的基本对象及这些对象间的联系组成。E-R模型的三个基本概念：实体集，联系集，属性。
实体：现实世界中可区别于其他对象的“事件”或“物体”。
实体集：具有相同类型及共享相同性质的实体集合。
实体集有可能相交。
数据库包括一组实体集，每个实体集中包括一些相同类型的实体。
实体集可能有多个属性。
实体集中的实体可以用一个（属性，数据值）对的集合来表示。
实体集的外延：组成实体集的各实体。
属性：实体集中每个成员具有的描述性性质。。
属性的域（属性的值集）：属性都有一个值，属性的可取值的集合为属性的域。
简单属性：不能划分为更小的部分的属性。
复合属性：可再划分为更小的部分的属性。
单值属性：对特定实体都只有单独的一个值的属性。
多值属性：可能对应一组值的属性。
派生属性：可以从其他的相关属性或实体派生出来的属性。派生的属性不存储，可在需要时计算出来。
基属性（存储的属性）：被派生的属性。
联系：多个实体间的相互关联。
联系集：同类型联系的集合。
参与：实体集之间的关联称为参与。
联系实例：表示所模拟的现实世界的命名实体间的一个关联。
实体的角色：实体在联系中的作用。
联系集的度：参与联系集的实体集的数目。
映射基数(基数比例)：通过一个联系集能同时与另一个实体相联系的实体数目。
对实体集A与B之间的二元联系集，其映射基数为：
一对一：A中的一个实体至多同B中的一个实体相联系，B中的一个实体也至多同A中的一个实体相联系。
一对多：A中的一个实体可以同B中的任意数目的实体相联系，而B中的一个实体至多同A中的一个实体相联系。
多对一：A中的一个实体至多同B中的一个实体相联系，而B中的一个实体可以和A中的任意数目的实体相联系。
多对多：A中的一个实体可以同B中的任意数目的实体相联系，B中的一个实体也可以同A中的任意数目的实体相联系。
实体集E全部参与联系集R：实体集E中的每个实体都参与到联系集R的至少一个联系中。
实体集E部分参与联系集R：实体集E中只有部分实体参与到联系集R中。
码：用以区别实体和联系，并惟一地标识联系。
超码：一个或多个属性的集合，这些属性的组合可以使我们在一个实体集中惟一地标识一个实体。
候选码：最小的超码，其任意真子集都不能成为超码。
主码：用来在同一实体集中区分不同实体的候选码。
应该选择那些从不或极少变化的属性作为主码。
联系的主码结构依赖于联系集映射基数。一对一的联系中，可使用两个主码中的任何一个作为联系的主码。多对多的联系中，联系的主码由两个主码共同构成。一对多的联系中，联系的主码由其中之一决定。
弱实体集：属性不足以形成主码的实体集被称为弱实体集。
强实体集：有主码的实体集。
标识实体集（属主实体集）：弱实体集所依赖的强实体集。
标识性联系：将弱实体集与其标识实体集相联系的联系集。标识性联系是从若实体集到标识实体集的多对一联系，且弱实体集全部参与联系。
分辨符：能够区分若弱实体的属性集合。
特殊化：在实体内部分组的过程。
一般化：高层实体集与一个或多个低层实体集间的包含关系。
超类：即高层实体集。
子类：即低层实体集。
属性继承：由特殊化和一般化所产生的高层实体和低层实体的一个重要特性，高层实体集会被低层实体集继承。
二、规范化原则
第一范式
如果一个关系模式R的所有属性域都是原子的，称关系模式R属于第一范式。更一般地表达方式为，所有属性都是简单属性，这样的实体集符合第一范式。
第二范式
如果实体集符合第一范式，并且非主码完全依赖于主码，这样的实体集符合第二范式。
第三范式
如果实体集符合第二范式，并且其非主码均不依赖于其他任何非主码，这样的实体集符合第三范式。
三、设计过程（非关系型数据库可用）
第一阶段，需求分析。和领域专家、数据库用户广泛交流，获得较详细的规格说明，最终提交的产品为用户需求规格说明。
第二阶段，概念设计。选择数据模型，将需求转换为数据库的概念模式。
若为关系型数据库设计，那么必定选择关系模型，最终提交的产品为实体-联系图和功能需求规格说明。本阶段的具体工作就是：定义数据库中表示实体，实体属性，实体之间的联系和实体上的限制；描述在数据上进行的各类操作（增删改查）或事物。
获得E-R模型后使用上面介绍的范式进行检验和优化。
第三阶段，逻辑设计。将概念模式映射为将被使用的数据库系统的实现数据模型。
若为关系数据库设计，要实现数据模型就是关系数据模型，通常将E-R模型定义的概念模式映射为关系模式，所以最终提交的产品为关系模式。
获得关系模式后，使用上面介绍的范式对模式检验和优化。
第四阶段，物理设计。定义数据库的物理特征，完成设计。
四、设计过程详解
1概念设计要点
1）应该选择实体还是属性？
实体和属性的概念并不是非常精确的，其区别取决于被建模的现实中的事物的特征或结构。
一般的原则是，根据被建模的现实事物的特征，要使用属性前先要判断此属性是否可以再次分割，即此属性是否有包含了其他一些“属性”，这些属性能够更精确地描述它，这个时候应该使用实体而不是属性。
2）一个实体集的主码可以作为另一个实体集的属性吗？
一般来讲，在建模的过程中，将一个实体集属性作为另一个实体集的属性是不合适的，最明显的缺点就是造成数据的重复存储，况且将一个实体集的主码作为另一个实体集的属性更不恰当，因为，如果在建模的过程中，发现两个实体似乎有着共同的属性，那么这两个实体之间必然存在联系，这时应抽象出两个实体集的联系，将他们的关系用联系明确的表达出来，而不是将关系隐藏起来。
3）可以将相关实体集的主码属性作为联系集的属性吗？
由于联系集中隐含了相关实体集的主码属性，所以不要将相关实体集的主码属性作为联系集的属性。这样做常常是由于概念不清导致的。
4）是否可以将两个实体集的联系集也设计为实体集？
具体情况具体分析。
若相关实体集与联系集都是一对一的关系，那么用联系集比较好。此外，描述实体间的行为时用联系比较好。
若不上述假设不成立，那么应考虑将两个实体集的联系集设计为实体集。
5）避免使用四元或高于四元的联系集
一些看起来非二元联系集通常可以转换为多个二元联系集，但将有些高元联系生硬地转换成多个二元也是不恰当的。
6）尽可能将两个实体集间的多对多的联系转换为一对一或一对多的联系
7）联系属性的布局
将描述性属性放到联系集还是实体集取决于业务特点。
一对一的联系集，联系的属性可以放到任一参与联系的实体中。
一对多的联系集，联系的属性仅能放到参与联系的“多”的那边的实体集中。
多对多的联系集，联系的属性一般放在联系集中
8）应该选择那些从不或极少变化的属性作为主码
9）弱实体集与多值属性
如果弱实体集只参与标识性联系，并且属性不多，可以将弱实体集表示为属主实体集的一个复合属性。
10）特殊化还是一般化
采用的特化是为了表达实体集所包含的子集之间的差异，突出强调子集的特征，以满足业务的需要。
采用一般化的原因是凸显实体集间的相似性隐藏他们之间的差异，以满足业务的需要。
11）使用聚集
E-R模型无法表达联系间的联系。聚集表达了更复杂的关系。当需要表达联系间的联系或联系与实体间的联系时使用聚集。
2逻辑设计要点
逻辑设计就是要将ER模型转换为关系模式
1）由强实体集导出的关系模式
强实体集的主码就是生成的关系模式的主码。强实体集的描述属性就是关系模式的属性。
2）由弱实体集导出的关系模式
有弱实体集A和强实体集B，A依赖于B。
由弱实体集A导出的关系模式的主码由B的主码和A的分辨符组合而成。
在关系A上指明外码约束，
3）由联系集导出的关系模式
有联系集R，参与R的所有实体集的主码的并集为C，由并集构成的属性集合P={p1,p2,p3,......}
R的描述性属性为D ={d1,d2,d3,......}
联系集导出的关系模式的属性对应于P与D的并集中的各个属性。
关系的主码的确定规则为：
一对一的二元联系集，关系模式的主码是是参与联系的实体集中任意一个的主码。
多对一的二元联系集，关系模式的主码是联系集中“多”的一方的实体集的主码。
多对多的二元联系集，关系模式的主码是参与联系的实体集的主码的并集。
4）模式冗余
一般地，参与联系的实体中，包含了弱实体集及其依赖的强实体集，那么由此联系集导出的关系模式极可能是冗余的。
5）关系模式的合并
一对一的联系，联系集的关系模式可以和参与联系的任一实体集的关系模式合并。
部分参与到联系中的情形，可以通过使用空值进行模式合并。
合并之后的模式的外码约束要做相应的调整。
6）复合属性与多值属性
复合属性的处理方式：为每个子属性创建单独的属性。
多值属性的处理方式：为多值属性M创建关系模式R。
R具有的属性包括：对应M的属性A,以及M所在的实体集的主码。
R的主码由模式中所有属性构成。
7）一般化
为高层实体集创建一个模式，为此高层实体集的每个低层实体集创建一个模式，模式中的属性包括对应于低层实体集的每个属性和对应于高层实体集的主码的每个属性。高层实体集的主码属性也是低层实体集的主码属性。
也可以不为高层实体集创建模式，只为每个低层实体集创建模式，这样低层实体集的属性为对应的低层实体集的属性以及对应的高层实体集的属性。
8）由聚集导出的关系模式
表示聚集不需要单独导出关系模式，聚集关系模式是定义该聚集的联系集的关系模式。
9）聚集与实体集间的联系导出的关系模式
这种联系导出的关系模式，属性包括对应实体集的主码中的每个属性、联系集主码中的每个属性、联系集（聚集与实体集间的联系集）的描述性属性。
五、设计实例
下面仅对部分关键建模问题加以分析。
应用背景描述：
提供在线文献阅读和下载的网站，有普通的用户和网站的管理员，如果平台对外开放API服务，那么还有开发者，即授权调用API的用户。
文献按种类可分为：期刊，会议，报纸，博士硕士论文，图书等。
若将文献按行业分类为：建筑建材，水利水电，石油化工，信息产业等。
若将每个行业细分，比如：电讯、电话、印刷、出版、新闻、广播等。
为方便用户阅读，所以还要提供导航，导航类似于将每个行业细分的结果。
系统将用户的行为呈现给用户，例如下载量，阅读量，浏览历史。
可以订阅喜欢的刊物，实时跟踪最新文章动态。
用户可以自定义主题，按照自定义主题检索相关文献。系统也会提供默认的主题。
用户可以收藏喜欢的文章，还可以下载文献。
根据上述描述获得实体：
普通用户（读者），用户所属的机构，网站管理员，API开发者，文献，行业，导航，主题，统计信息。
E-R建模分析与导出关系模式：
可以将用户的账号作为主码，但在实际使用过程中，却常使用自增的Id作为主码,称为UserId，虽然自增的Id不是构成实体所必须的，原因是自增Id是整型而账号一般为字符串，且一般关系数据库默认建立索引，整型上的索引有一定的优势。
统计信息只与普通用户有联系，可以将统计信息和普通用户合并为一个实体，即统计信息成为复合属性，但这是不好的设计。虽然这样可以减少实体数量，但是普通用户的基本信息，例如账号，密码，邮箱等是不经常变化的。而统计信息是随着用户的行为经常变化的。所以这里用实体而不用属性。这里没有将弱实体集转换为强实体集的复合属性。
统计信息构成弱实体集，它依赖强实体集，即由所有普通用户构成的实体集。弱实体集分辨符取自增Id，称为StaticId。导出关系模式的主码是分辨符即StaticId与用户UserId
收藏是用户的一种行为，一个用户可以收藏多篇文章，一篇文章也可被多个用户收藏，他们是多对多的关系。通过收藏这种行为用户和文献建立起了关系。
收藏时间是关系的描述性属性，由于是多对多的关系，所以收藏时间应该放在联系集中。导出的关系模式的主码为用户实体集与文章实体集的主码的并集。
导航和用户之间的关系也是多对多的。客户端页面的导航要有一个显示顺序，而且是可以调整的。那么导航顺序这个属性也应该放在联系集中。
平台的用户包括普通的用户和API使用者，他们都是用户，有共性又有差别。根据API接口的访问权限可以对使用API的用户细分，例如：超级用户可以调用涉及修改操作的API接口，而一般用户只能调用涉及查询操作的API接口，但这种细分不构成一般化与特殊化的概念。这里并未采用为高层实体创建模式的方式实现一般化的过程。而是为每个低层实体创建一个模式。
参考书目：
数据库系统概念 （原书第5版）
作者:（美）Abraham Silberschatz/（美）Henry F.Korth/（美）S.Sudarshan
