1、实体 
 客观存在并可相互区别的事物称为实体。实体可以是具体的人、事、物，也可以是抽象的概念或联系。 
 2、属性 
 实体所具有的某一特性称为属性。一个实体可以由若干个属性来刻画。 
 3、联系 
 实体内部的联系通常指组成实体的各属性之间的联系，实体之间的联系通常指不同实体集之间的联系。 
 实体之间的联系有一对一、一对多和多对多等多种类型。 
 4、概念模型 
 E-R图（Entity-Relation diagram），包括实体、属性、实体之间的联系等。
 
 
 
实体型用矩形表示，矩形框内写明实体名。 
 属性用椭圆形表示，并用无向边将其与相应的实体型连接起来。 
 联系用菱形表示。
 
 
5、逻辑结构设计 
 一般都为关系数据模型，将E-R图向关系模型转换，需要将实体型、实体的属性和实体型之间的联系转换为关系模式。注意数据依赖的适度优化（范式）

在PowerDesigner的概念模型中，实体之间的关系是非常重要的，也决定了从概念模型转化到物理模型时的表现形式，所以有必须深究其中的相关设置。做数据库重要的就是表与表之间的关系，而这个关系是连接所有数据库系统的纽带，所以即使我们不用PD，也应该重视表与表之间的关系。这也是关系型数据库的由来。
 
PD中的表与表之间的关系有四种，分别是one-one(一对一)，one-many(一对多)，many-one（多对一），many-many（多对多）。在实际中使用得最多的只有前面两种，而多对一和一对多其实没有什么区别，只是二者关系的反向描述，所以其可以看成是一种类型。而多对多在实际的数据库设计中也是时有出现的，这种情况下，我们一般不直接处理多对多的关系，而是通过一种技巧，将多对多转化为多对一，和一对多的关系，这样可以简化数据库关系的复杂性。将多对多转化为多对一，再一对多意思是通过提供一个关联关系表，来使多对多的关系表与该关联关系表发生关系，而不让其直接发生多对多的关系，这样就可以简化这样的关系。前面文章中已经说明如何创建这种关联表了。这里也就不再说多对多的关系。后面只重点说明一对一，一对多的关系。
 
在CDM中，实体之间的关系更符合现实情况一些，以一对多的关系来说，如果一个实体对应多个实体，通常含有“包含，拥有”等这样的意思在里面。比如一个部门拥有多个员工，一个企业拥有多个部门等。而如果多个实体对应一个实体，则通常含有“属于，包含于”等这样的意思。比如多个员工属于一个部门，多个部门包含于一个企业等。在PDM中就很具体了，且与实际的有些区别了，这主要是由于在软件的实现角度上的体现，比如一对多的关系，比如T1与T2的关系为T1一对多个T2，在PDM中，通常表现在T2中有一个外键，用来存储T1的主键，这样就叫一对多，而这样的表现与实际上具有一定的差别。当然这是没有什么问题的，因为PDM才是我们真正在软件实现时所采用的方式。我只是想说的是CDM中这种关系的描述，可能更和实际情况接近一些，也就更加容易明白一点。
 
好了，下面分别说明一下一对多和一对一的关系详细说明：
 
1.对于一对多的说明
 
当两个实体需要进行一对多的关联时（比如T1与T2的关系为T1一对多个T2，T1和T2为两个实体），我们通过Relationship，从T1拉至T2时，二者关系就建立起来了。默认情况下就是个一对多的关系，即T1为1，T2为多。
 
双击拉的关系线，则弹出二者关系描述的对话框，我们就可以在这个弹出的属性对话框里进行我们所需要的设置了。在弹出来的默认属性为General属性选项。我们可以在这个属性页里面修改关系名称以及对这个关系的描述等。点击Cardinalities属性页，在上面默认显示的就是一对多的关系，我们现在是描述一对多的关系，所以不修改它。在关系下面有个Dominant role，这个右边有个下拉框，不过是被置灰了，不可操作，这里先不管，后面在说一对一时再说说这里。
 
在T1 to T2的内容里面，有个Role name，在其右边有个输入框，可以输入T1表的角色名字，这里就可以用前面提到的比如“拥有，包含”等这样的内容，可以用来说明T1表的职能。在Role name下面的Dependent默认是置成灰色，意即不可操作，这里我们就不管了。然后是Mandatory，这个是什么意思呢？这个是否选择决定了某个东西是否为空。是什么东西呢？指的是和本实体发生关系的对方实体的主键在本实体的外键字段是否为空。比如现在有种情况是T1中某个字段，如par1，该字段为外键，它将存储T2中的主键，则如果Mandatory被选中，则par1不为空，意即它必须存储某一个T2的值，而如果不选上，则表示该字段值可以为空。在现在的情况下T1与T2是一对多的关系，我们知道在PDM中，出现的情况是T2中会生成一个外键，用来存储T1表的主键，而T1表不会有任何字段来存储T2的主键 ，所以这个Mandatory是否被选择上，不会对关系造成任何影响，所以这里我们就不用管它了。当然，我们从实际的描述中，可以这样来说明这个值的选取相关的情况，比如现在T1指的是部门，而T2指的是员工，当你选择了该值，则在后面的Cardinality中会变成1,n，即如果选择这个值，则表示一个部门至少有一个员工，而如果不选，则表示一个部门至少有0至n个员工，就这个区别，因为为一对多，T1表中不会存储T2表中的主键，即使你选择了Cardinality，用于说明是部门至少含有1个员工，但是，T2表此时仍为空，没有任何员工，也不会出现问题的（这是因为一对多这个关系，导致T1表中不会有T2的任何相关信息造成的，当然在一对一的关系中，则不一样的，后面会说到）。
 
现在再说说T2到T1的内容里面的东西，其中的role name仍可以加入你所描述的T2的角色职责，比如“属于，包含于”等。在其下面，我们发现Dependent没有置灰了，是可以勾选的。我们先不管它，先趁热把Mandatory再说清楚点，此时由于我们已经知道T2表中会含有T1的主键的了，因为一对多的关系，则在生成的T2表时，会生成一个外键，用来单独存储T1的主键的，现在有个问题出现了，就是T2的存在是否依赖于T1，即说白一点就是一个员工是否一定要属于某一个部门？如果你的数据库系统中要求一定属于，那么你就把Mandatory选择上。反之，如果你认为新来的员工还没有分配好部门，可以暂时不让其属于某一个部门，到后面在人为的选择某一个部门，那么你就可以不用选择上Mandatory了。Cardinality会根据你是否选择Mandatory来决定其值是0,1还是1,1，意思很明确，就是是否T2一定属于T1，即一个员工是否一定属于一个部门。为这进一步确认Mandatory是否选中对PDM的实际表现造成的影响，可以通过CDM转化为PDM，查看其中的外键字段是否允许为空就可以明确了，如果你选择了Mandatory，则在PDM中T2生成的外键中将不允许为空，即必须含有T1的某一主键，而如果不选择Mandatory，则在PDM中T2生成的外键是可以允许为空的。
 
好了，现在来说说Dependent的意思，如果其不选，则没有什么变化，如果其被选择中了，则会在PDM中对T2中生成的用于存储T1主键的那个外键（FK）将会成为T2的另外一个主键，这就是这个值的意思，如果你不需要T2中的外键同时成为主键，则不用选择该值。通常情况下，都不需要选择这个。
 
2.一对一的关系说明
 
在两个实体表中的关系中，如果一个表和另一个表是一对一的关系，这种一对一的关系有两种形式，以T1表和T2表为例。一种是T1中有个字段（外键）是T2表的主键，T2中有一个字段（外键）是T1表的主键，另一种情况是只有其中的一个表含有另一个表的主键，而另一个表不含有前一个表的主键。前面说的第一种情形是指两个实体互相感知，互相拥有对方的信息，另一种情况是指二者含有一定的依赖关系。某一个实体的存在依赖于另一个实体的存在。
 
相对来说，在软件领域中，第二种情形更常见一些，完全平等的两个实体在现实中存在的意义不大，毕竟社会是一个充满着各种联系的实体，实体之间存在的着一定的依赖关系，就象孩子依赖于父母，员工依赖于企业，当然存在着两个互相感知的实体，这样带来的一个好处是在查询时非常迅速。下面说一下一对一关系的某些属性的改变带来的变化。
 
当T1和T2实体建立好了关系之后，正如前面所言，默认情况下是个一对多的关系，我们这次就要改变这种关系了。在关系线的属性中，在Cardinalities属性页，我们将one-many修改为one-one，当我们选中one-one后，下面的Dominant role由原来的置灰不可操作状态变为可操作状态了。Dominant role的意思是占支配地位的角色，在其右边的下拉框中默认值为none，这里要求我们选择的是两个实体，谁占支配地位，谁占被支配地位。即谁支配谁。默认值中的none表示二者双方都不占支配地位，意即二者地位平等，则就是前面所述的第一种情况，即二者互相感知。这种情况下，在PDM中会发现T1表和T2表中都会生成一个外键，用于存储对方的主键。而下面的Dependent和Mandatory和前面描述一对多的关系时表现是一样的。这里就不再赘述了，只是需要注意的一点是如果你的关系是二者互相平等的话，在选择Mandatory中，不要将T1和T2都同时选择上，不然就会出现互斥现象，永远不成立。
 
现在我重点说一下关于第二种情形，现在假设我们需要T2中的外键来存储T1的主键，那么这种情况下谁是支配地位的角色呢？在Dominant role中是选择T1->T2还是T2->T1呢？在->前面的是支配地位，后面的是被支配地位。想一下，为什么T2需要用一个外键来存储T1的主键呢？是因为T2需要T1的信息，需要T1来支持T2的存在，即T2依赖于T1，则说明T1应该是支配地位角色，那么在Dominant role项中，我们就需要选择T1->T2。明白了这个，就明白了为什么在一对多的关系里，这个Dominant role是置灰的呢？原因很简单，不需要我们指定这种支配角色，因为一对多的关系中，为一的那个必定是支配地位的角色，不需要我们改变。
 
好了，关于实体之间的关系就结束了。如果你不是很确定关系的选项对后来的PDM造成的影响，你可以通过试验，通过简单的两个实体表，从CDM转化为PDM，实际看一下二者关系的表现，就明确了，这是我在实际的使用过程中，所用的方法。

实体-联系（Entity-Relationship， E-R）模型(以下简称E-R模型)的提出旨在方便数据库的设计，它是通过允许定义代表数据全局逻辑结构的企业模式实现的。
 E-R模型采用三个基本概念：实体集、联系集和属性。
 
实体集
 
实体（entity）是现实世界中可区别于所有其他对象的一个“事物”或“对象”。（与面向对象的类含义类似）实体集是相同类型即具有相同性质（或属性）的一个实体集合。在建模汇中，我们通常抽象地使用术语“实体集”，而不是指某个个别实体的特别集合。
 实体集不必互不相交。如可以定义大学里所有人的实体集（person）。一个person实体可以是teacher实体，也可以是student实体，可以既是teacher实体又是student实体，也可以都不是。
 实体通过一组属性（attribute）来表示。属性是实体集中每个成员所拥有的描述性性质。且每个属性都有一个值。
 
弱实体集
 
没有足够的属性以形成主码的实体集称为弱实体集（weak entity set）。有主码的实体集称作强实体集（strong entity set）。弱实体集必须与另一个称作标识（identitying）或属主实体集的实体集关联才能有意义。也就是说，弱实体集的存在依赖于标识实体集。将弱实体集与其标识实体集相连的联系称为标识性联系。
 标识性联系是从弱实体集到标识实体集多对一的，并且弱实体集在联系中的参与是全部的。
 虽然弱实体集没有主码，但仍需要区分依赖于特定强实体集的弱实体集中实体的方法。弱实体集的分辨符是使得我们进行这种区分的属性集合。弱实体集的分辨符也称为该实体集的部分码。
 弱实体的主码由标志实体集的主码加上该弱实体集的分辨符构成。
 
联系集
 
联系（relationship）是指多个实体间的相互关联。联系集是相同类型联系的集合。
 联系集也可以具有描述性属性（descriptive attribute）。如果teacher实体集与student实体集的联系集advisor。可以将属性date与该联系集联系起来，以表示教师成为学生的老师的日期。
 数据库中的大部分联系集都是二元的。然而，有时联系集会涉及多于两个实体集。参与联系集的实体集的数目称为联系集的度（degree）。二元联系集的度为2，三元联系集的度为3，以此类推。
 
非二元的联系集
 
对于非二元联系集，为了避免混淆，只允许在一个联系集外有一个箭头。（如果有多个箭头，则无法表明对应的哪个实体）。而函数依赖可以以一种不会混淆的方式描述实体间的联系。
 
属性
 
每个属性都有一个可取值的集合，称为该属性的域（domain），或者值集（value set）。 严格来说，实体集的属性是将实体集映射到域的函数。由于一个实体集可能有多个属性，因此每个实体可以用一组（属性，数据值）对来表示，实体集的每个属性对应一个这样的对。
 E-R模型中的属性可以按照如下的属性类型来划分：
 
简单（simple）和复合（composite）属性。简单属性不能划分为更小的部分。复合属性可以再划分为更小的部分。 复合属性帮助我们把相关属性聚集起来，使模型更清晰。注意，复合属性可以是有层次的。如address可以包含street、city、state等，而street可以进一步分解为street_number、street_name、apartment_number。
单值（single-valued）和多值（multi-valued）属性。一般情况下，一个属性对应一个值，这样的属性称为单值属性。如stuent_ID属性只对应于一个学生ID。而在某些情况下对某个特定实体而言，一个属性可能对应于一组值。以phone_number为例，每个教师可以有零个、一个或多个电话号码。这样的属性称为多值属性。为了表示一个多值属性，用花括号将属性名包住；如{phone_number}。
派生（derived属性）。派生属性的值可以从别的相关属性或实体派生（计算）出来。如age属性表示年龄，如果还具有属性date_of_birth，就可以从当前的日期和date_of_birth计算出age。派生属性的值不存储，而是在需要时计算出来。
 当实体在某个属性上没有值时，使用空（null）值。空值可以表示“不适用”，即该实体的这个属性不存在值。空还可以用来表示属性值未知。未知的值可能是缺失的（值不存在），或不知道的（不知道该值是否确实存在）。
 
删除冗余属性
 
一个好的实体-联系设计不包含冗余的属性。但是在实际开发中，实现这一点需要极大的代价。
 
约束
 
可以定义一些数据库中的数据必须要满足的约束。
 
映射基数(Mapping Cardinality)
 
映射基数表示一个实体通过一个联系集能关联的实体的个数。对于实体集A和B之间的二元联系集R来说，映射基数必然是以下情况之一：
 一对一（one-to-one）：A中的一个实体至多与B中的一个实体相关联，并且B中的一个实体也至多与A中的一个实体相关联。
 一对多（one-to-many）：A中的一个实体可以与B中的任意数目（零个或多个）实体相关联，而B中的一个实体至多与A中的一个实体相关联。
 多对一（many-to-one）：A中的一个实体至多与B中的一个实体相关联，而B中的一个实体可以与A中的任意数目（零个或多个）的实体相关联。
 多对多（many-to-many)：A中的一个实体可以与B中的任意数目（零个或多个）实体相关联，，并且B中的一个实体也可以与A中的任意数目（零个或多个）的实体相关联。
 注意，考虑映射关系时，一定要同时考虑A->B和B->A两个方面，而不能只考虑其中一方面而忽略另一方面，从而导致错误的设计。
 
参与约束
 
如果实体集E中的每个实体都参与到联系集R的至少一个联系中，那么实体集E在联系集R中的参与称为全部的。如果实体集E中只有部分参与到联系集R中，那么实体集E在联系集R中的参与称为部分的。如我们期望每个student实体通过advisor联系同至少一名教师相联系，因此student在联系集advisor中的参与是全部的。相反地，一个teacher不是必须要指导一个学生。因此，很可能只有一部分teacher实体通过advisor联系同student相关联，于是teacher在advisor中的参与是部分的。
 
码
 
我们必须有一个区分给定实体集中实体的方法。从概念上来说，各个实体是互异的；但从数据库的观点来看，它们的区别必须通过其属性表明。实体的码是一个足以区分每个实体属性集。关系模式中的超码、候选码、主码的概念同样适用于实体集。
 码同样可以唯一标识联系，并从而将联系相互区分开来。联系集的主码结构依赖于联系集的映射基数。如果联系集是多对多的，那么联系集的主码由两个实体集的主码的并集构成。如果联系是多对一的，那么多的实体的主码就是联系集的主码。如果联系集是一对一的，那么两个实体的任一主码就是联系集的主码。
 
E-R数据模式转换为关系模式
 
E-R模型和关系数据库模型都是现实世界企业抽象的逻辑表示。由于两种模型采用类似的设计原则，因此可将E-R设计转换为关系设计。
 
具有简单属性的强实体集的表示
 
设E是只具有简单描述性属性a1，a2，…，an的强实体集。我们用具有n个不同属性的模式E来表示这个实体集。对于从强实体集转换而来的模式，强实体集的主码就是生成的模式的主码。
 
具有复杂属性的强实体集的表示
 
当一个强实体集具有非简单属性时，可以通过为每个子属性创建一个单独的属性来处理复合属性，而不为复合属性自身创建一个单独的属性。
 多值属性的处理不同于其他属性。对于一个多值属性M，构建关系模式R，该模式包含一个对应于M的属性A，以及对应于M所在的实体集或联系集的主码的属性。另外，在多值属性构建的关系模式上建立外码约束，由实体集的主码所生成的属性去参照实体集所生成的关系。
 派生属性并不在关系数据模型中显式地表达出来。
 
弱实体集的表示
 
设A是具有属性a1，a2，…，an的弱实体集，设B是A所依赖的强实体集，设B的主码包括b1，b2，…，bn。
 对于从弱实体集转换而来的模式，该模式的主码由其所依赖的强实体集的主码与弱实体集的分辨符组合而成。除了创建主码之外，还要在关系A上建立外码约束，该约束指明属性b1，b2，…，bn参照关系B的主码。外码约束保证表示弱实体的每个元组都有一个表示相应强实体的元组与之对应。
 
联系集的表示
 
设R是联系集，设a1，a2，…，an表示所有参与R的实体集的主码的并集构成的属性集合，设R的描述性属性（如果有）为b1，b2，…，bn。映射基数不同，主码的选择方式不同：
 
对于多对多的二元联系集，参与实体集的主码属性的并集成为主码。
对于一对多的二元联系集，任何一个实体集的主码都可以选作主码。这个选择是任意的。
对于多对一或一对多的二元联系集，联系集中多的那一方的实体集的主码构成主码。
对于边上没有箭头的n元联系集，所有参与实体集的主码属性的并集构成主码。
对于边上有一个箭头的n元联系集，不在"箭头"侧的实体集的主码属性为模式的主码。
 此外，还需在关系模式R上建立外键约束。
 
模式的冗余
 
连接弱实体集和相应强实体集的联系集比较特殊。弱实体集的主码包含强实体集的主码。连接弱实体集与其所依赖强实体集的联系集的模式是冗余的，而且在基于E-R图的关系数据库设计不必给出。
 
模式的合并
 
在一对一的联系的情况下，联系集的关系模式可以跟参与联系的任何一个实体集的模式进行合并。即使参与是部分的，也可以通过空值来进行模式的合并。
 最后，还需考虑表示联系集的模式上本应有的外码约束。参照每一个参与联系集的实体集的外码约束本应存在。我们舍弃了参照联系集模式所合并入的实体集模式的约束，然后将另一个外码约束加到合并的模式中。
 
实体-联系设计问题
 
在实体-联系数据库模式中涉及到一些基本问题。
 
用实体集还是用属性
 
什么构成属性？什么构成实体集？对这两个问题并不能简单地回答。区分它们主要依赖于被建模的现实世界的企业结构，以及被讨论的属性的相关语义。
 一个常见的错误是用一个实体集的主码作为另一个实体集的属性，而不是用联系。例如，即使每名教师指指导一名学生，将student的ID作为teacher的属性也是不正确的。用advisor联系代表学生和教师之间的关联才是正确的方法，因为这样可以明确表示出两者之间的关系而不是将这种关系隐含在属性中。
 另一个常见的错误是将相关实体集主码属性为联系集的属性。这种做法是不对的，因为在联系集中已隐含这些主码属性。（这些属性默认已经在联系集中，不应再明确表示出来）
 
用实体集还是联系集
 
一个对象最好被表述为实体集还是联系集并不总是显而易见。在决定用实体集还是联系集可采用一个原则是，当描述发生在实体间的行为时采用联系集。这一方法在决定是否将某些属性表示为联系可能更适合时也很有用。
 
二元还是n元联系集
 
数据库中的联系通常都是二元的。一些看来非二元的联系实际上可以用多个二元联系更好地表示。事实上，一个非二元的（n元，n>2）联系集总可以用一组不同的二元联系集来替代。可以将这一过程直接推广到n元联系集的情况。因此在概念上可以限制E-R模型只包含二元联系集。然而，这种限制并不总是令人满意的。
 
对于为表示联系集而创建的实体集，可能不得不为其创建一个标识属性。该标识属性和额外所需的那些联系集增加了设计的复杂度以及对总的存储空间的需求。
n元联系集可以更清晰地表示几个实体集参与单个联系集。
有可能无法将三元联系上的约束转变为二元联系上的约束。例如，考虑一个约束，表明R是从A、B到C多对一的；也就是，来自A和B的每一对实体最多与一个C实体关联。这种约束就不能用联系集Ra、Rb和Rc上的基数约束表示。
 
联系集中属性的布局
 
一个联系的映射基数比率会影响联系集中属性的布局。因此，一对一或一对多联系集的属性可以放到一个参与该联系的实体集中，而不是放到联系集中。一对多联系集的属性仅可以重置到参与联系的“多”方的实体集中。而对于一对一的联系集，联系的属性可以放到任意一个参与联系的实体中。
 设计时将描述性属性作为联系集的属性还是实体集的属性这一决定反映出被建模企业的特点。
 属性位置的选择在多对多的联系集中体现得更清楚。同名的属性，放在实体集中还是联系集中其作用不同。
 
扩展的E-R特性
 
虽然基本的E-R概念足以对大多数数据库特征建模，但数据库的某些方面可以通过基本E-R模型作某些扩展来更恰当地表达。
 
特化(Specialization)
 
在实体集内部进行分组的过程称为特化。一个实体集可以根据多个可区分的特征进行特化。在E-R图中，特化用从特化实体指向另一个实体的空心箭头来表示。所以，这种关系也称为ISA关系。特化关系还可能形成超类-子类(superclass-subclass)联系。
 
概化(Generalization)
 
实体的共性可以通过概化来表达，概化是高层实体集与一个或多个低层实体集间的包含关系。对于所有实际应用来说，概化只不过是特化的逆过程。为企业设计E-R模型时，将配合使用这两个过程。
 
聚集(Aggregation)
 
聚集是一种抽象，通过这种抽象，联系被视为高层实体。
 当把聚集像其他实体集一样看待时，之前用于在联系集上创建主码和外码约束的规则，也同样可以应用于与聚集相关联的联系集。聚集的主码是定义该聚集的联系集的主码。不需要单独的关系来表示聚集；而使用从定义该聚集的联系创建出来的关系即可。
 
数据库设计的其他方面
 
数据约束和关系数据库设计
 
使用SQL可以表达多种数据约束，包括主码约束、外码约束、check约束、断言和触发器。约束有多种目的。最明显的一个目的是自动的一致性保持。通过在SQL数据定义语言中表达约束，设计者能够确保数据库系统自己执行这些约束（显式声明约束）。
 显式声明约束的另一个优点是一些约束在数据库模式的设计中特别有用。
 数据约束在确定数据的物理结构时同样有用，可以将彼此紧密相关的数据存储在磁盘上邻近的区域，以便在磁盘访问时提高效率。如将索引建立在主码上，索引结构工作得更好。
 每次数据库更新时，执行约束会在性能上带来潜在的高代价。对于每次更新，系统都必须检查所有的约束，然后要么拒绝与约束冲突的更新，要么运行相应的触发器。性能损失的严重性，不仅仅取决于更新的频率，而且依赖于数据库的设计方式。
 
使用需求：查询、性能
 
数据库系统的性能时绝大多数企业信息系统的一个关键因素。性能不仅与计算能力的有效利用以及所使用的存储硬件有关，而且受到与系统交互的人的效率以及依赖数据库数据的处理的效率的影响。以下是效率的两个主要度量方法：
 
吞吐量（throughput）————每单位时间里能够处理的查询或更新（通常指事务）的平均数量。
响应时间(response time)————单个事务从开始到结束所需的平均时间或最长时间。
 
授权需求
 
授权约束同样会影响数据库的设计，因为SQL允许在数据库逻辑设计组件的基础上将访问权限授予用户。（现有主流数据库系统均已合理实现授权（基于角色分配））
 
数据流、工作流
 
术语工作流表示一个流程中的数据和任务的组合。当工作流在用户间移动以及用户执行他们在工作流中的任务时，工作流会与数据库系统交互。
 
数据库设计的其他问题
 
数据库设计通常不是一个一蹴而就的工作。一个组织的需求不断发展，它所需要存储的数据也会相应地发展。但是，对于一个已明确的需求，还是可以给出稳定的设计的。
 一个好的设计应该不止考虑当前的规定，还应该避免或者最小化由预计或有可能发生的改变而带来的改动。（需要做向上兼容的思考）
 最后，数据库设计在两个意义上是面向人的工作：系统的最终用户是人（使用该程序的用户）；数据库设计者需与应用领域的专家进行广泛交互以理解应用的数据需求。所有涉及数据的人都有需要和偏好，为了数据库设计和部署在企业中获得成功，这些都是需要考虑的。
 
参考
 
数据库系统概念(第六版) A. Silberschatz H. F. Korth S. Sudarshan著 杨冬青 等译 第七章

前言
 

 为了重新回顾我写的消息系统架构，我需要重新读一下数据库系统概念的前三章，这里简单的做一个笔记，方便自己回顾
 

 
 
 

 
 
 
基本概念
 

 实体-联系（E-R）数据模型基于对现实世界的这样一种认识：世界由一组称为实体的基本对象及这些对象间的联系组成。E-R数据模型所采用的三个主要概念是：实体集、联系集和属性
 
 
 

 
 
 
实体集
 

 实体是现实世界中可区别于其他对象的“事件”或“物体”
 

 
 
 

 实体集是具有相同类型及共享相同性质（或属性）的实体集合
 

 
 
 

 实体通过一组
 属性来表示。属性是实体集中每个成员具有的描述性质。将一个属性赋予某实体集表明数据库为实体集中每个实体存储相似的信息，但每个实体在自己的每个属性上都有各自的值。属性类型划分：
 
 
 
简单属性和符合属性
单值属性和多值属性
派生属性
 
 

  
 
 
 
 
联系集
 
 

  联系是多个实体间的相互关联
 
 
 

  
 
 
 
 

  联系集是同类型联系的集合。规范的说，联系集是n(n >= 2)个实体集上的数学关系，这些实体集不必互异。如果E1, E2, ..., En为n个实体集，那么联系集R是{(e1,e2,e3,..,en)|e1 (- E1, e2 (-E2, ..., en (- En}的一个子集，其中（e1, e2, e3,...,en）是一个联系
 
 
 

  
 
 
 
 

  
 
 
 
 
约束
 
 

  有了实体集合，有了联系集合，自然而然的就产生出来约束，约束描述的是实体集和实体集之间的关系，而这种关系具现为一个联系集。我们要讨论的是
  映射基数和
  参与约束
 
 
 

  
 
 
 
 
映射基数
 
 

  映射基数，或基数比例，指明通过一个联系集能同时与另一个实体相联系的实体数目
 
 
 

  
 
 
 
 

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

   
 
  
 
 
 
 
参与约束
 
 

  如果实体集E中的每一个实体都参与到联系集R的至少一个联系中，我们称实体集E全部参与联系集R
 
 
 

  
 
 
 
 

  如果实体集E中只有部分实体参与到联系集R的联系中，我们称实体集E部分参与联系集R
 
 
 

  
 
 
 
 
码
 
 

  我们必须有一个能区分一个实体集中的所有实体的方法。概念上来说，各个实体是互异的;但从数据库的观点来看，它们的区别必须用其属性来表明
 
 
 

  
 
 
 
 

  码概念使得我们可以区别实体，码同样可以唯一地标识联系，并将联系互相区分开来
 
 
 

  
 
 
 
 
 
  
超码：一个或多个属性的集合，这些属性的组合可以使我们在一个实体集中唯一地标识一个实体
候选码：任意真子集都不能称为超码的超码，也就是最小的超码
主码：数据库设计者选定的候选码
 
  

   
 
  
 
 
 
 
设计问题
 
 

  实体集和联系集的概念并不精确，而且定义一组实体及它们的相互联系可以有多种不同的方式
 
 
 

  
 
 
 
 
用实体集还是属性
 
 

  书里的电话号码和姓名的例子很清楚，哪个为属性哪个为实体集，
  注意两点常见的错误：
 
 
 
 
  
一个常见的错误是用实体集的主码作为另一个实体集的属性，而不是用联系
另一个常见的错误是将有关系的实体集的主码属性作为联系集的属性
 
  

   
 
  
 
 
 
 
用实体集还是联系集
 
 

  用联系集可能产生的两个问题：
 
 
 
 
  
数据多次存储，浪费存储空间
更新可能使数据处于不一致的状态，即两个联系中应该具有相同值的属性具有了不同的值
 
  

   
 
  
 
 
 
 
二元联系集与n元联系集
 
 

  n元关系可以分解成为二元关系，但是会出现关系描述不准确的情况
 
 
 

  
 
 
 
 

  
 
 
 
 
实体-联系图
 
 

  E-R图包括如下几个主要组件：
 
 
 
 
  
矩形：实体集
椭圆：属性
菱形：联系集
线段：将属性连接到实体集或将实体集连接到属性集
双椭圆：多值属性
虚椭圆：派生属性
双矩形：弱实体集
 
  

   
 
  
 
  

   举个书上的例子：
  
 
 
 
 

  
 
 
 
 

  
  
 
 
 
 

  
 
 
 
 

  
 
 
 
 

  
 
 
 
 

  
 
 
 
 

  
 
 
 
 
数据库规范化
 
 

  数据库规范化，又称数据库或资料库的正规化、标准化，是数据库设计中的一系列原理和技术，以减少数据库中数据冗余，增进数据的一致性。关系模型的发明者埃德加.科德最早提出这一概念，并于1970年代初定义了第一范式、第二范式和第三范式的概念，还与Raymond f. Boyce于1974年共同定义了第三范式的改进范式-BC范式
 
 
 

  
 
 
 
 
第一范式
 
 

  第一范式（1NF）是数据库规范化中所使用的一种正规形式。第一范式是为了要排除重复组的出现，所采用的方法是要求数据库的每个字段都只能存放单一值，而且每笔记录都要能利用一个唯一的主键来加以识别
 
 
 

  
 
 
 
 

  重复组举例：
 
 
 

  
 
 
 
 

  
  
 
 
 
 

  
 
 
 
 

  符合第一范式，就需要取消重复组，将数量中的每个数量单独作为一条记录，因为顾客可能会有多次购买记录，因此，需要有主键标识这张表
 
 
 

  
 
 
 
 

  
  
 
 
 
 

  
 
 
 
 

  
 
 
 
 
第二范式
 
 

  第二范式(2NF)是数据库规范化中使用的一种正规形式。它的规则是要求数据库表里的所有数据都要和该数据表的主键有完全依赖关系;如果有哪些数据只和主键的一部分有关的话，就得把它们独立出来变成另一个数据表。如果一个数据表的主键只有一个单一字段的话，它就一定符合第二范式
 
 
 

  
 
 
 
 

  示例：
 
 
 

  
 
 
 
 

  有一个数据表记录了设备组件的信息，如下图所示：
 
 
 

  
 
 
 
 

  
  
 
 
 
 

  
 
 
 
 

  
 
 
 
 

  这个数据表的每个字段都是单一值，所以它符合第一范式。因为同一个组件有可能由不能的供应商提供，所以得把组件id和供应商id合在一起组成一个主键
 
 
 

  
 
 
 
 

  主键和价格之间的关系很正确：同一组件在不同供应商有可能会有不同的报价，所以价格确实和主键完全相关（完全依赖）
 
 
 

  
 
 
 
 

  另一方面，供应商名称和住址就只和供应商ID有关（部分依赖），这不符合第二范式的原则。最好把供应商名称和地址独立出来变成另一个数据表
 
 
 

  
 
 
 
 

  
  
 
 
 
 

  
 
 
 
 

  
 
 
 
 

  检查数据表里的每个字段，确认它们是不是都和主键完全相关，这样才能知道这个数据表是不是符合第二范式。如果不是的话，就把那些不完全相关的字段移动到独立的数据表里。接下来的步骤是要确保所有不是键的字段和彼此没有相依关系，这就叫做第三范式
 
 
 

  
 
 
 
 

  
 
 
 
 
第三范式
 
 

  第三范式是数据库规范化中所使用的一种正规形式，用来检验是否所有非键属性都只和候选键有相关性，也就是说所有非键属性互相之间应该是无关的
 
 
 

  
 
 
 
 

  满足第三范式（3NF）必须先满足第二范式（2NF）。第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息
 
 
 

  
 
 
 
 

  所谓传递函数依赖，指的是如果存在“A -> B -> C”的决定关系，则C传递函数依赖于A
 
 
 

  
 
 
 
 

  因此，满足第三范式的数据库应该不存在如下依赖关系：
 
 
 

  
 
 
 
 

  关键字段 -> 非关键字段x -> 非关键字段y
 
 
 

  
 
 
 
 

  假设学生关系表为Student(学号，姓名，年龄，所在学院，学院地点，学院电话)，关键字为单一关键字“学号”，因为存在如下决定关系：
 
 
 

  
 
 
 
 

  （学号） -> （姓名，年龄，所在学院，学院地点，学院电话）
 
 
 

  
 
 
 
 

  这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系：
 
 
 

  
 
 
 
 

  （学号） -> （所在学院） -> （学院地点，学院电话）
 
 
 

  
 
 
 
 

  
 
 
 
 

  即存在非关键字字段“学院地点”、“学院电话”对关键字字段“学号”的传递函数依赖
 
 
 

  
 
 
 
 

  把学生关系表分为如下两个表：
 
 
 

  
 
 
 
 

  学生： （学号，姓名，年龄，所在学院）
 
 
 

  
 
 
 
 

  学院： （学院，地点，电话）
 
 
 

  
 
 
 
 

  这样的数据库是符合第三范式的，消除了数据冗余，更新异常，插入异常和删除异常
 
 
 

  
 
 
 
 

  
 
 
 
 
BCNF
 
 

  BCNF是在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合BCNF范式
 
 
 

  
 
 
 
 

  假设仓库管理关系表为StorehouseManage(仓库ID，存储物品ID，管理员ID，数量)，且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：
 
 
 

  
 
 
 
 

  （仓库ID，存储物品ID） ——>  （管理员ID，数量）
 
 
 

  
 
 
 
 

  （管理员ID，存储物品ID）——> （仓库ID，数量）
 
 
 

  
 
 
 
 

  所以，（仓库ID，存储物品ID）和（管理员ID，存储物品ID）都是StorehouseManage的候选关键字，表中唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：
 
 
 

  
 
 
 
 

  （仓库ID）——> （管理员ID）
 
 
 

  （管理员ID）——> （仓库ID）
 
 
 

  
 
 
 
 

  即存在关键字段决定关键字段的情况，所以其符合BCNF范式。它会出现如下异常情况：
 
 
 

  
 
 
 
 
四种范式之间存在如下关系：
 
 

  
 
 
 
 

  
  
 
 
 
 

  
 
 
 
 

  
 
 
 
 

  
 
 
 
 
主键和索引的区别
 
 

  所谓主键，就是能够唯一标识表中某一行的属性或属性组，一个表只能有一个主键，但可以有多个候选索引。因为主键可以唯一标识某一行记录，所以可以确保执行数据更新、删除的时候不会出现张冠李戴的错误。主键除了上述作用外，常常与外键构成参照完整性约束，防止出现数据不一致的情况
 
 
 

  
 
 
 
 
 
  
主键是唯一性索引，唯一性索引不一定是主键
一个表中可以右多个唯一性索引，但只能有一个主键
主键列不允许有空值，而唯一性索引列允许有空值
 
  

   
 
  
 
 
 
 

  
 
 
 
 

  
 
 
 
 
后记
 
 

 纯粹为了回顾E-R模型和E-R图的画法，比较水，高手可以直接跳过了！