Structure:
步骤2：建立逻辑数据模型
步骤2.1：从逻辑数据模型中导出关系
步骤2.2：使用规范化方法验证关系
步骤2.3：针对用户事务验证关系
步骤2.4：检查完整性约束
步骤2.5：与用户一起复查逻辑数据模型
步骤2.6：将逻辑数据模型合并为全局模型
步骤2.7：检查模型对于未来可扩展性的支持
Summary：
步骤2：将概念数据模型转换为逻辑数据模型，并对该模型的结构正确性以及是否能够支持企事业单位需要处理的事务进行验证。
从概念数据模型中导出一组关系（关系模式）。关系模式的结构需要用规范化的方法进行验证，然后还要验证这些关系是否能够满足客户的需求。接下来，需要检查完整性约束，以及和客户一起复查，直到用户确认该模型能够真实反映组织的数据需求。
步骤2.1：从逻辑数据库模型中导出关系，用来表示已确认的实体，联系和属性。
使用DBDL表示关系时，首先指定关系的名字以及被括号括起来的简单属性列表；然后指定关系的主关键字，可替换关键字，或外部关键字；在外部关键字后面要列出所引用的主关键字的关系；也要列出所有导出属性及其计算方式。
主关键字/外部关键字机制表现了实体间的联系。先确认实体间的父实体和子实体关系，父实体的主关键字被放入表示子实体的关系中，作为该关系的外部关键字。
为下列不同结构导出与之对应的关系：
1. 强实体类型
对于数据类型中的强实体，创建一个包含这个实体所有简单属性的关系；对于组合属性，仅将主要的简单属性包含进关系。
2. 弱实体类型
对于数据模型中的每个弱实体，创建一个包含该实体所有简单属性的关系。弱实体的部分主关键字甚至全部都是从所有者实体中获取的，因为弱实体关键字的确认要等与所有者实体相关的联系全部都转换完毕后才能进行。
3. 一对多（1：*）二元联系类型
联系“一方“的实体被标记为父实体，联系”多方“的实体被标记为子实体。为了表示这样的关系，需要将父实体的主关键字放到子实体的关系中作为外部关键字。
4. 一对一（1：1）二元联系类型
需要在参与约束的帮助下决定谁是父实体，谁是子实体，并决定是将两种关系合为一种还是创建两种关系。
a. 双方都强制参与的的1：1关系，合并。
b. 一方强制参与的1：1关系，可选参与的作为父实体，强制参与的作为子实体
c. 双方可选参与的1：1关系，任意指定父子实体或者强制性较弱的一方作为父实体。
5. 一对一（1：*）递归联系类型
与前面的1：1关系一样
6. 超类/子类联系类型
7. 多对多（*：*）二元联系类型
为*:*二元联系创建关系，关系中包含*:*二元联系的所有属性以及参与这个联系的实体的主关键字副本，主关键字的副本作为外关键字。这些外关键字可能组合在一起构成新的主关键字，也可能与其他一些联系的属性合并在一起构成主关键字。（如果联系自身的一个属性有唯一性，说明我们漏掉了一个实体）
8. 复杂联系类型
为每一个复杂联系创建一个关系，关系包含了属于这个联系的所有属性，并将参与该联系的的实体的主关键字也复制到这个关系中，作为关系的外部关键字。表示联系的”多”方的外部关键字通常也会成为这个新创建的关系的主关键字，也与联系中的其他属性一起组成主关键字。
9. 多值属性
对于每一个多值属性，都创建一个新的关系来表示这个多值属性，并将实体的主关键字复制到新建立的关系中；除非多值属性本身是实体的可替换关键字否则多值属性本身与实体的主关键字一起组成新关系的主关键字。
在2.1的最后，将导出的关系记录在文档中。每一个关系已经包含了应该包含的属性，接下来确认这些关系的主关键字和可替换关键字。这一步对于弱实体来说尤其重要，因为弱实体的主关键字是依赖于父实体的，即将父实体的主关键字复制过来作为自己的主关键字。
步骤2.2：使用规范化的方法验证逻辑数据模型的关系
使用规范化的规则对于每个关系中的属性集合进行验证。规范化的方法是为了确保这些关系在拥有最小属性集合的同时又能满足组织的数据需求。而且，这些关系还应该拥有最小的数据冗余，除非有些冗余是关系之间建立联系所必须的。
规范化的方法确定了一系列步骤对关系进行检验，以确认其属性是否遵循某个给定的范式，如第一范式，第二范式，第三范式。从正确的概念数据模型中正确的导出的关系已经是符合3NF的。如果发现某个关系不是3NF，则概念数据模型或者导出关系的过程中出现了错误。
如有必要，需要重建。
步骤2.3：针对用户事务验证关系
针对用户事务验证关系，确保逻辑数据模型中的关系支持所需要的事务。
利用关系，关系的主关键字/外部关键字，ER图和数据字典，我们可以尝试以手工的方式来执行组织的所有事务，如果这样的方式能支持所有的事务，则说明逻辑数据模型能够支持所有事务。
步骤2.4：检查完整性约束
完整性约束是为了避免数据库不完全，不准确，不一致的而增加的约束；包含所有重要的完整性约束的逻辑数据模型才是组织数据需求的真实写照。
完整性约束包括：
1. 必须有值的数据约束
属性域约束
2. 多重性约束：定义在联系上的约束，比如一个部门可以有很多员工，而一个员工只能在一个部门工作的情况。
3. 实体完整性约束：实体的主关键字不能为空。
4. 引用完整性约束：子关系中的每个元组都通过外部关键字链接到父关系中拥有相同键值的元组，如果外部关键字包含一个值，这个值就必须指向父关系中存在的一个元组。
对于外部关键字，有两个问题需要思考：
1. 外部关键字是否可以为空？
2. 如何保证引用的完整性？
解决方案是：
1. 如果是强制参与的，则不允许为空；如果不是强制参与的，则不允许为空；
2. 指定“存在约束“，存在约束定义了一个候选关键字或者外部关键字可以插入，更新或者删除的条件。
5. 一般性约束
这些约束来自“现实世界“的管控，比如，每个员工最多管理100处房产。
2.4的最后一步，在数据字典中记录下所有的完整性约束。
步骤2.5：与用户一起复查逻辑数据模型
用户判断的标准是模型是否能正确反应组织的现状，满足组织的需求。
逻辑数据模型和数据流图的关系：
定义：逻辑数据模型反映了组织需要存储的数据的结构；数据流图（DFD）显示了数据在组织的流动情况和存储情况。
如果组织拥有某种属性，则该属性就必须出现在某个实体类型中，并且可能以数据流的形式在组织的事务中流动。当我们使用这两种技术根据客户的需求规格说明书建模时，可以用其中一个来检验另外一个的一致性和完整性。
两种技术之间的关联规则是：
1. 数据存储结构应该描述所有的实体类型；
2. 数据流中出现的属性应该属于某个实体类型