日期:2009-08-24  浏览次数:20661 次

用实体关系图进行数据库建模
(阿良@仙人掌工作室 2001年08月14日 15:37)
一、概述
很可能你现在正在规划一个数据库驱动的网站;而且几乎可以肯定的是,你一定已经浏览过数据库驱动的网站。过去,一些网站依赖CGI脚本和文本文件存储实现数据持久化,但现在我们能够访问大量不同的关系型、对象-关系型、面向对象型数据库。

对于Web应用来说,关系数据库是一种强大的支持工具,这得感谢它们的高可用性、性能,而且相对来说,关系数据库比较容易使用。要找出一个功能完善、源代码开放、能够在多种平台上运行的数据库系统并不困难。你可以用Perl、Java、PHP以及其他服务器端脚本语言把关系数据库和Web网站连结到一起。
随着网站规模的发展,它对数据库——通常是关系数据库——的依赖程度也日益增加。大量页面和服务需要向数据库表写入信息,或者从数据库提取信息。对于大多数网站,数据库表很快成为网站体系结构中的关键部分,成为网站运作的生命中枢。为了方便和轻松地管理大容量数据,用户帐户、新闻动态、内容、统计数据都可以保存到关系数据库管理系统(Relational Database Management System,RDBMS)。
用图(Diagram)管理数据模型具有高效、方便的优点。对于RDBMS,描述数据模型的图通常称为实体关系图(Entity Relationship Diagram,ERD)。用ERD描述数据模型能够帮助你预先精确定义数据需求,使你能够对以后的改动作出有效的规划,能够随着网站的发展方便地改进规划。
本文将介绍ERD建模工具和概念。文章提供了一些图的实例,但它们的目的不是提供精确的或者是全面的数据设计范例。它们的目的是以两个建模工具为例,介绍数据建模符号。在不同的工具之间,图的符号有着重大的差别,但它们的基本概念一样。本文的图例从PowerDesigner和Visio 2000 Professional的试用版得到,你可以从本文末尾找到这些工具和其他类似产品的链接。
二、是否使用建模工具?
许多规模较小的网站用ASCII形式的SQL(Structured Query Language)脚本文件进行数据建模。当开发小组人员较少,或者最理想的情况下仅由一个人构成时,这种方法最有效。然而,数据模型将很快发展成为一个复杂的结构——在这种情况下,CASE(Computer Aided Software Engineering,计算机辅助软件设计)工具、有关所有数据信息的图、集中式知识库能够极大地帮助你管理Web网站的数据层。
2.1 何时使用SQL?
即使当你准备用SQL直接管理数据模式(物理数据库)时,图也能有效地帮助你理解和改进系统。然而,如果你的预算或者时间非常有限,采用复杂的新式建模工具可能得不偿失。相反,在这种情况下,你应该使用一个简单的图形工具把数据模式的基本情况记录下来,然后逐步转换到复杂的数据建模工具。
如果你正在设计的数据库类型不常见(或者是非标准的),避免使用某些复杂CASE工具可能是明智的,因为这些工具的“反向工程”能力和某些自动功能可能无法在你的环境下发挥作用。这里所谓的自动功能,是指建模工具根据输入模型的图形和属性信息,自动为目标数据库生成合适SQL命令的能力。反向工程是这样一种能力,建模工具根据已经部署的物理数据模式,从现有的表提取出实体和关系信息。
2.2 转入建模工具
从简单绘图工具转换到数据建模工具并不是一个很复杂的过程。大多数数据建模工具的工作方式就象是一个标准的绘图工具,参见图1a和图1b,这是两个数据建模工具的界面实例。你可以在这里创建和排列表,定义关系,以及指定其它信息(列的类型、长度,键等)。

图1a:PowerDesigner的界面(点击放大) 

图1b:Visio的界面(点击放大)
转向数据建模工具的主要挑战在于:
学习使用建模符号。在不丢失任何关键信息的前提下,用数据建模工具描述现有数据模型。寻找一个对你的数据库提供全面支持的工具,例如在生成SQL、从现有数据模式通过反向工程建立数据模型时。  一些入门级数据建模工具(参见本文后面的参考资源)只有少量的高级特性。这有好处,但也有弊端——它们很容易学习使用,但当你积累了更多的经验时,它们可能不再满足你日益增长的需要。然而,升级工具或更换工具一般不存在大的问题,特别是当新的工具能够对现有数据模式进行精确、完整的反向工程时,升级或更换工具的过程尤其简单。
三、ERD建模符号
本文使用Martin的Information Engineering符号。PowerDesigner采用的就是这种符号,Oracle的Designer产品所使用的符号也和它很相似。你可以在AIS Modeling Summary查看各种ERD符号的说明。基本的ERD绘图规范很直观易懂。你可以定义实体(表),描述各个实体之间的关系。在填写表和关系的细节信息时,每一种工具的做法都有所不同;但就我所遇到的工具来看,基本概念在大多数软件包之间是相通的。接下来的内容将介绍你必须了解的主要图形元素和设置方法。
3.1 表
所有构造合理的数据建模工具都允许为表指定丰富的关联信息。这些信息包括(但不局限于):
表的描述、注解,以及实体(表)的标题。列,列的类型、长度、默认值和强制条件。主键,索引,唯一性约束。  要指定这些信息,一般你需要进入表的属性窗口,如图2a和图2b所示。

2a:PowerDesigner中表的属性窗口

图2b:Visio中表的属性窗口
一旦输入了新表的属性信息,图将被更新,显示出你所提供的新的或更改后的表信息。下面的图形显示了一个表的实例,这个表的属性信息见图2a和图2b。在图2a和图2b中,许多列被定义成了(m)andatory(强制的)、(p)rimary(主键)和(d)isplayed(被显示的)列。下面的图显示了为该表输入的部分属性信息。

图3a:PowerDesigner的表

图3b:Visio的表
在图3a中可以看到一些非标准的数据类型,如PHONENUMBER和PK。许多数据建模工具允许定义域或定制数据类型,它们可供一个以上的列使用。域不仅代表着数据类型——通常,它们还包含检查约束、默认值、值列表等信息。如果你想要更新一个域(例如定义一种新的电话号码格式),所有该模型中引用该域的列都将自动更新。
3.2 关系
如果我们只定义数据模式中的表,数据建模工具就不那么重要了。各个表之间的关系、依赖情况往往很复杂,有一个管理和显示这些关系的工具将带来很大的帮助。对于一个给定的关系,必须收集的重要信息包括:
父表和子表。两个表之间的强制关系。例如,父表可能有一个子表,但子表必须有一个父表。关系基数(Cardinality)。即,一个父表可以有零个或者多个子表,但一个子表有且只能有一个父表。关于关系的注释、意见和角色说明。  大多数建模工具通过在两个或者更多表之间画出连线的方式定义关系。默认情况下,关系往往被定义成为一对多关系,而且它对于关系中的任何一方都是可选的。要修改关系,你必须打开关系的属性窗口,更新实体关系的特征信息。图4a和图4b显示了两个不同的工具允许为关系定义的部分属性:

图4a:PowerDesigner的关系属性设置界面

图4b:Visio的关系属性设置界面
该图显示了一个一对多关系——一个典型的父-子关联关系。部门(Branch)和雇员(Emplyee)的关系是强制的。它意味着一个部门必须至少有一个雇员(1-N强制关系);另一方面,它意味着一个雇员必须属于且只能属于一个部门(1-1强制关系)。图5a和图5b反映了修改后的关系。

图5a:PowerDesigner中两个表之间的关系

图5b:Visio中两个表之间的关系
这个图显示了如何把信息转换成符号。强制的关系由一条实心垂直线(而不是椭圆)表示。某些工具用虚线表示可选的关系。关系中属于“多”的这一边用一个类似鸟爪的图形表示,关系的基数在靠近它所描述的那一端显示。
你可能已经注意到,Employee表没有定义外键列。这个图仍旧处于“概念设计”阶段——此后,从概念图到物理数据模型之间的转换是必不可少的。大多数工具区分概念和物理数据模型——概念数据模型描述信息的需求,但不关注细节问题,例如索引和强制性的引用完整性。
有些时候,你可能要定义自我引用的表。自我引用的表一般用来描述层次型关系。如下面的图形所示,大多数数据建模工具能够处理这类关系。注意在这个例子中,雇员可以有零个或者一个上级——它使你能够处理一些特殊的情况,比如总统没有直接的上