在前面的步骤中，我们创建了数据库的ER模型，ER模型属于概念级别的模型，需要映射为表才能被计算机存储。本章节的目标就是从ER模型中创建表，并检查这些表的结构。这组表应该代表逻辑数据库模型中的实体，关系，属性和约束。然后检查每个表的结构，确保建表过程中没有产生错误。如果表中有错误，则表明在建表的过程中或在ER模型中仍有发现的错误。将ER模型映射为表的过程如下所述的步骤：
1． 创建表。创建表的目标是从从ER模型映射表集合，在这步中，为ER模型创建表来表达实体，关系，属性和约束，每个标的结构来源于ER所描述的信息，这些信息包括ER图，数据字典和任何其他相关的文档。我们使用关系数据库定义语言DBDL来描述每个表的组成，首先确定表的名字，在后面跟着该表的简单属性的名字，并将这些属性的名字括在括号中，然后标示该表的主键以及任何备用键和外键，对于每个外键，还要给出包含被引用主键的表。在创建的过程中，需要注意以下的事项：
a)
如何表达实体，对于模型中的每个实体，创建一个包含实体的所有简单属性的表。例如对于复合属性
Address
，应该包含它的简单属性
Street,state,zipcode,
如果有可能，标示每个表中的主键的列。
如何表达关系，一个实体与另一个实体间的关系由主键
/
外键机制表达，为了决定将外键属性放在哪里，首先必须标示关系中包含父实体和子实体。不同类型的关系和多值属性主要有：
i.
一对多的二元关系，对每个一对多的二元关系，关系一端的实体被设计为父实体，多端的实体被设计为字实体。为了描述这种关系，父实体主键的拷贝被放在字实体的表中。在一对多关系中有一个或者多个属性的情况下，这些属性也随着主键加到子表中。
ii.
一对多递归关系
,
一对多递归关系和一对多的二元关系很相似，只不过父实体和子实体都是同一个表。
iii.
一对一二元关系。一对一的二元关系的表稍微有些复杂。因为不能使用元组的数目来表示一个关系中的父实体和子实体。而是需要使用参与过程来决定把实体结合为一个表来表示关系。考虑如下的参与约束。
1. 1
：
1
关系的两边都是强制参与，在这种情况下，应该将两个实体合为一个表。并选择初始实体中的一个主键作为新表的主键。其他的键作为备用键。
2.1:1
关系的一边是强制参与，在这种情况下可以使用参与约束来标示
1
：
1
关系的父实体和子实体，关系中强制参与的实体被设计为子实体，可选参与的实体被设计为父实体。
3. 1
：
1
关系的两边均为可选参与。这种情况下父实体和子实体之间的设计是任意的。除非你可以得到关于关系的更多信息来帮助你判断使用那个设计。
b)
一对一递归关系。对于一对一递归关系，应该遵循上面所描述的对
1
：
1
关系的参与规则。但是在这种情况下，父实体和子实体是相同的，对于两边有强制参与的
1:1
递归关系，应该用主键的两个拷贝，来把这个递归关系，描述为一个表，同前面一样，主键的一个拷贝代表外键，并且应该将他重命名来表示他代表的关系。
c)
多对多的二元关系，对于每个多对多的二元关系，创建一个表达关系的表，这个表包含关系的任何属性，我们将参与关系的实体的主键属性拷贝到新表中，使之为外键，一个外键或全部外键将组成新表的主键，可能结合此关系的一些属性。
d)
复杂关系类型，有多于两个参与实体的关系是复杂关系，为每个复杂关系创建一个表达关系的表，将参与复杂关系的这些实体的主键复制到新表中，并作为外键，此表还包含与关系相关的全部属性，一个或多个外键将组成新表的主键，还可以加上关系中的一些其他属性。
e)
多值属性，对于每个与实体有关的多值属性，应该遵守上述
1:*
关系中所描述的规则，在一端的实体被指定为父实体，在多端的多值属性被指定为子实体，创建一个新的表包含这些多值属性，并将父实体的主键拷贝过来作为外键，除非多值属性自己本身是父实体的备用键，否则，新表的主键由多值属性和父实体的原始主键组成。
2．
用规范化的方法检查表的结构。这个步骤地目标是检查和使用规范化标准，使每个表的结构正确。用规范化的方法检查表可以避免不必要的数据重复。应该确保前面所建立的表至少是第三范式的，如果所标示的表不是第三范式的，可能表明
ER
模型的某部分是错误的。或者由模型创建表的时候产生了错误。
3．
检查表是否支持用户事务。这个步骤的目标是取保所产生的表支持用户所需要的事务。检查表是否支持事务的一种方法是检查是否支持事务的数据需求。以确保数据在一个或多个表中存在。同时，如果事务所需要的数据在多个表中，则应该检查这些表是否能够通过主键外键连接起来。
4．
检查业务规则。目标是检查逻辑数据库设计中表达的业务规则。业务规则适用于防止数据不完整，不准确或者不一致的约束，尽管
DBMS
在完整性方面的控制可能存在也可能不存在，但这不是问题所在，在这个阶段，你只关心高级设计，即确定需要什么样的数据完整性约束，而不管怎么样去实现，标示完整性约束之后，就可以得到一个完整而准确的描述视图的局部逻辑数据模型。如果必要的话，可以从逻辑数据模型产生物理数据库设计，在为用户构建系统的原形时，需要考虑如下的一个常见的完整性约束：
i.
需要的数据，即某些列的数据是必须要填写的。
ii.
列的值域约束，每个列都有一个值域，
iii.
实体完整性，实体的主键不能为空。
iv.
多样性，多样性表达了数据库中数据间的关系的约束。比如班级必须有学生，而且必须有班主任，
v.
参照完整性。外键包含的与父表象匹配的主键值。关于主键需要注意以下两点：
1
。主键允许为空吗？
2.
如何保证参照的完整性，当向字表中插入数据，删除数据，更新子表记录外键，向父表中插入数据，从父表删除数据时，应该进行哪些约束，如
No Action,Cascade,set Null,set Defaule,No Check
5．
与用户讨论逻辑数据库设计。目标是为了确保局部逻辑数据模型与描述模型的文档确实表达了用户视图。此视图的逻辑数据库设计应该已经设计完全，并且全部存档，但在完成这个步骤之前，应该与用户一起研究这个设计。
本文转自凌辉博客51CTO博客，原文链接http://blog.51cto.com/tianli/58491如需转载请自行联系原作者
lili00okok
