数据建模和分析

5.5　数据建模和分析

数据建模，它不仅作为一种为数据库定义业务需求的技术，而且它在系统开发中扮演着一个重要的角色。有时数据建模被称为数据库建模，主要是因为数据模型最终要实现成数据库。

5.5.1　数据建模的概念

用于数据建模的符号方法有多种。一般经常使用的一种为实体关系图（Entity Relationship Diagram，ERD）因为它是按照实体和关系来刻画数据。ERD的符号也有好多种，大多数的都以发明者命名。在本书中我们采用的Martin（信息工程）符号记法，主要使用的工具为Power Designer因为它应用比较广泛。

1．实体（Entity）

所有系统都包括数据，通常还包括大量的数据。如在学校系统中，学校系统包括了描述各种事物的数据，如“学生”“教师”“课程”和“教室”等。在数据建模时我们需要一个概念来抽象地表示一组类似的事物的所有实例称为实体。实体可以是具体的对象，如一个学生、一个客户等；也可以是抽象的事件，如一次订单、一次发货等。实体分两个层次：个体和实体。

要注意的是区分实体及其实例很重要，实体实例指的是实体的具体值。

2．属性（Attributes）

如果一个实体是要存储数据的某样东西，那就需要确定我们想存储关于一个给定实体的每个实例的什么数据。一般称这些数据为属性。如图5-13中的TitleISBN、TitleText、TitleType、TitlePrice、TitleNotes和TitlePublicationDate等都是实体的属性。

图5-13　Entity图形

3．关系（Relationship）

从现实意义上讲，实体和属性都不是独立存在的。它们各自代表的事物互相交互，并且影响彼此，共同支持业务。关系是存在于一个或多个实体之间的自然业务联系。关系可以表示链接实体的一个事件，或是存在于实体之间的逻辑关系。如图5-14就表示了实体之间的关系。

图5-14　实体之间的关系

（1）基数

基数定义了一个实体相对于另一个关联实体的某个具体的最小和最大值数量。因为所有的关系都是双向的，所以对于每个关系在两个方向上都必须定义基数值。表5-1不同基数及其对应的图形显示。

表5-1　不同基数及其对应的图形显示

（2）度数

度数是来描述数据关系复杂性的。关系的度数就是参与某个关系实体数量。目前我们讨论的所有关系都是二维的。也就说有两个不同的实体参与这个关系（度数=2）。

其实关系也可以存在于同一个实体的不同实例之间，一般称这样的关系为递归关系（度数=1）。例如，在公司管理系统中，管理者（Manager）本身也是员工（Employee），如图5-15所示。

图5-15　递归关系图

（3）外键

在ERD中关系隐含了一个实体实例关联于另一个实体实例。在做数据分析时我们应该能够为任何给定的实体确定这些实例。在确定相关实体实例将涉及外键的创建。关于外键其实是一个实体的主键，它被贡献给另一个实体来确定一个关系实例。子实体中的外键总是和父实体中的主键相匹配的。在实体之间的关系存在两种，即确定性关系和非确定性关系。确定性关系的定义是父实体贡献其主键成为子实体的主键的一部分的关系。任何确定性关系中的子实体经常被称为弱实体。因为它的存在依赖于父实体的存在。非确定性关系的定义是每一个参与关系的实体都有各自独立主键的关系。也就是说不共享主键的属性。

（4）泛化

泛化是一种技术，其中几类实体公共的属性被组合成了实体。例如，在一个典型的学校系统中，一个学校登记学生（Student）并雇用雇员（Employee）。对这两个实体来说，有几个属性是公共的，如：Name、Gender和Race等。我们可以提取这些公共性的属性到一个为Person的实体超类中。实体超类是一个实体，其实例存储了一个或多个实体子类的公共属性。实体超类将拥有一个或多个到实体子类的一对一关系属性。扩展这一个概念，一个实体可以是个超类，同时也可以是一个子类。值得注意的是，所有子类都是弱实体。

通过继承，数据库中的泛化概念使我们可以通过共享公共属性减少属性数量和减少数据的冗余。子类不仅继承了属性，而且还继承了那些属性的数据类型、域和默认值等。通过这种方法可以提高应用于许多不同实体的属性的一致性。

5.5.2　构造数据模型

获取实体是建模中的第一项目工作，也是相对比较容易的一项任务，需要获取在系统中的基本实体，这些基本实体由数据来进行描述，也有可能不是由数据来描述。在获取实体中要注意的是不要把对实体的考虑仅仅限制在最终用户所知的范围内。

1．上下文数据模型

在获取实体后下一个任务是构造上下文数据模型。上下文数据模型主要包括基本业务实体以及它们之间的关系。在关系中，关系的命名应该使用动词词组和实体名称组合而成。形成一个简单的业务语句。在有些CASE工具中允许在两个方向上命名关系。否则一般从父实体向子实体的方向命名关系。上下文模型示例如图5-16所示。

2．确定数据模型的键

接下来的任务就是确定每个实体中的键。要遵循如下原则：在每个实体实例的开发生命周期中，一个键的值不应该改变；键的值不能为空；必须进行控制以保证键的有效性。

在业务编码时有效的业务编码可以给组织带来价值，因为人们可以在没有计算机辅助下快速地处理数据。编码有几种类型，序列码、块状编码、字母编码、显著位置编码和层次编码。不同的编码有不同的优点和缺点。

图5-16　上下文数据模型示例

3．建立数据模型

看上去确定其他的数据属性是一个琐碎的任务，但不熟悉数据建模技术的分析员经常会遇到麻烦。为完成这项任务，系统分析员必须全面地理解系统的数据属性，这些事实可以是使用自顶向下的方法或自底向上的方法收集。存在一个企业数据模型，一些属性就可能已经被确定并记录和存储在资料库中。

5.5.3　数据模型

虽然通过模型能够有效地沟通数据库需求，但它并不一定就代表了一个优良数据库设计，其中的某些数据结构特征可能会降低数据库的灵活性和扩展性，或者产生不必要的数据冗余。下面讲述如何为数据库设计和实现准备好具有完整属性的数据模型。一个高质量的数据模型的特征包括：数据模型是简单的、数据模型基本上是无冗余的、数据模型是灵活的而且对未来的需求具有可适应性。如果我们在设计数据库没有考虑这条准则，我们往往会设计出只能实现目前业务需求的数据库，然后，当一个新的需求产生时，若不重写许多或所有的使用那个数据库的程序，就无法方便地修改数据。因此我们要做到使数据模型做到尽最大可能性地与应用无关，以鼓励采用不影响现在程序扩展的数据库结构。

数据分析是在为数据设计做准备的过程，同时，也是一项数据模型的技术。数据分析的目标是实现简单的、无冗余的、灵活的和可扩展的数据库。这项专门的技术称为规范化。规范化是一种数据分析技术，下面将详细叙述规范化。

1．范式的概念

满足一定条件的关系模式，称为（Normal Form），满足不同程度要求的为不同的程度要求的为不同的范式。满足最低要求的为第一范式，简称1NF。在第一范式里满足进一步要求的为第二范式，其余以此类推。一个低级范式的关系模式，通过分解方法可以转换成多个高一级范式的关系模式的集合，这种过程称为规范化。

2．第一范式（1NF）

如果一个关系模式R的所有属性都是不可再分的基本数据项，则R属于1NF。在任何一个关系数据库系统中，第一范式是对关系模式的一个最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。

（1）关系中每个数据项必须是一个不可分的数据项，即此项所表达的实体属性必是原子属性，且要求数据项没有重复组；

（2）列是同质的，即每一列中所有数据项类型相同。各列指定一个相异的名字，列的次序任意；

（3）各行相异，不允许有重复的行，行的次序任意。

3．第二范式（2NF）

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。这个唯一属性列被称为主关键字或主键、主码。

第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。

例：选课关系 SCI（SNO，CNO，GRADE，CREDIT）其中SNO为学号，CNO为课程号，GRADEGE为成绩，CREDIT 为学分。 由以上条件，关键字为组合关键字（SNO，CNO）在应用中使用以上关系模式有以下问题：

（1）数据冗余：假设同一门课由40个学生选修，学分就重复40次。

（2）更新异常：若调整了某课程的学分，相应的元组CREDIT值都要更新，有可能会出现同一门课学分不同。

（3）插入异常：如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程和学分存入。

（4）删除异常：若学生已经结业，从当前数据库删除选修记录。某些门课程新生尚未选修，则此门课程及学分记录无法保存。

其原因在于，非关键字属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。 解决方法是分成两个关系模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC1中的外关键字CNO相联系，需要时再进行自然连接，恢复了原来的关系。

4．第三范式（3NF）

第三范式和第二范式不同的地方在于，在第三范式里，所有的非键属性都必须和每个候选键有直接相关。如果再对第三范式做进一步加强就成了BC范式，它所强调的重点就在于“数据间的关系是奠基在键上、以整个键考虑，而且除了键之外不考虑其他因素”。

表5-2　未规范化的订单表

在表5-2中，非主键字段完全依赖于主键订单编号，也就是说唯一的订单编号能导出唯一非主键字段值，符合第二范式。第三范式要求非主键字段之间不能有依赖关系，显然本例中“小计”依赖于非主键字段“单价”和“数量”，不符合第三范式。“小计”不应该放在这个数据表里面，只要把“单价”乘上“数量”就可以得到“小计”了；如果想要符合第三范式的话，就把“小计”拿掉（不过在做查询的时候，本来用“SELECT Orders.Total FROM Order”就要改成用“SELECT UnitPrice * Quantity FROM Order”了）。规范化后的订单表如表5-3所示。

表5-3　规范化后的订单表