3.2 关系
如果我们只定义数据模式中的表，数据建模工具就不那么重要了。各个表之间的关系、依赖情况往往很复杂，有一个管理和显示这些关系的工具将带来很大的帮助。对于一个给定的关系，必须收集的重要信息包括：
父表和子表。 两个表之间的强制关系。例如，父表可能有一个子表，但子表必须有一个父表。 关系基数（Cardinality）。即，一个父表可以有零个或者多个子表，但一个子表有且只能有一个父表。 关于关系的注释、意见和角色说明。大多数建模工具通过在两个或者更多表之间画出连线的方式定义关系。默认情况下，关系往往被定义成为一对多关系，而且它对于关系中的任何一方都是可选的。要修改关系，你必须打开关系的属性窗口，更新实体关系的特征信息。图4a和图4b显示了两个不同的工具允许为关系定义的部分属性：
图4a：PowerDesigner的关系属性设置界面
图4b：Visio的关系属性设置界面
该图显示了一个一对多关系——一个典型的父-子关联关系。部门（Branch）和雇员（Emplyee）的关系是强制的。它意味着一个部门必须至少有一个雇员（1-N强制关系）；另一方面，它意味着一个雇员必须属于且只能属于一个部门（1-1强制关系）。图5a和图5b反映了修改后的关系。
图5a：PowerDesigner中两个表之间的关系
图5b：Visio中两个表之间的关系
这个图显示了如何把信息转换成符号。强制的关系由一条实心垂直线（而不是椭圆）表示。某些工具用虚线表示可选的关系。关系中属于“多”的这一边用一个类似鸟爪的图形表示，关系的基数在靠近它所描述的那一端显示。
你可能已经注意到，Employee表没有定义外键列。这个图仍旧处于“概念设计”阶段——此后，从概念图到物理数据模型之间的转换是必不可少的。大多数工具区分概念和物理数据模型——概念数据模型描述信息的需求，但不关注细节问题，例如索引和强制性的引用完整性。
有些时候，你可能要定义自我引用的表。自我引用的表一般用来描述层次型关系。如下面的图形所示，大多数数据建模工具能够处理这类关系。注意在这个例子中，雇员可以有零个或者一个上级——它使你能够处理一些特殊的情况，比如总统没有直接的上级。
图6a：PowerDesigner中自我引用的表
图6b：Visio中自我引用的表
四、图的规划
定义表和关系只是挑战的一部分，图的清楚明白同样很重要。虽然一些工具提供自动布局能力，我还没有看到过一个完善的实现。相反，你的目标应该是遵从“孔雀东南飞”这一规则（这里的“孔雀”是关系中代表“多”这一方的符号，它是连接到表的三条分叉线，象个鸟爪）。换句话说，子表应该位于父表的右方和下方。这种安排使得从逻辑上组织和理解数据模型更加方便。最重要、最高级别的表应该出现在左上角，让级别较低的表出现在页面的右下角。为了清楚起见，减少图中交叉线的数量也是很重要的。正如Eberhardt Rechtin在The Art of Systems Architecting中强调的，“一个好的设计往往看起来很舒服”。如果无论怎样安排，你的数据模型看起来都很混乱，那么，它可能正在告诉你数据模型本身有一些值得注意的问题。
文章来源于领测软件测试网 https://www.ltesting.net/
