1.2 数据模型

1.2.1 数据模型概述

模型是对现实世界的抽象。在数据库技术中，用模型的概念描述数据库的结构与语义，对现实世界进行抽象。表示实体类型及实体间联系的模型称为“数据模型”（Data Model）。

1.数据模型的种类

目前广泛使用的数据模型可分为两种类型。

（1）独立于计算机系统的模型，完全不涉及信息在系统中的表示，只是用来描述某个特定组织所关心的信息结构，这类模型称为“概念数据模型”。

（2）直接面向数据库的逻辑结构，它是现实世界的第二层抽象。这类模型涉及计算机系统和数据库管理系统，又称为“结构数据模型”，如层次、网状、关系、面向对象等模型。

2.结构数据模型的三个组成部分

结构数据模型有严格的形式化定义，以便于在计算机系统中实现。结构数据模型应包含数据结构、数据操作和数据完整性约束三个部分。

数据结构是对实体类型和实体间联系的表达和实现。

数据操作是指对数据的检索和更新两类操作的实现。

数据完整性约束给出数据及其联系应具有的制约和依赖规则。

1.2.2 常用数据模型

常用的数据模型主要有实体联系模型、结构数据模型和面向对象模型三种。

1.实体联系模型

客观存在且能相互区别的事物称为实体。实体可以是具体的对象，如一个男学生、一辆汽车，也可以是抽象的事件，如一次购物、一次体育竞赛等。

实体联系模型（Entity Relationship Model,ER模型）是P·P·Chen于1976年提出的。ER模型是直接从现实世界中抽象出实体类型及实体间联系，然后用ER图表示的数据模型。设计ER图的方法称为ER方法。

2.结构数据模型

这里介绍层次、网状、关系三种模型。

（1）层次模型

用树形结构表示实体类型及实体间联系的数据模型称为层次模型（Hierarchical Model）。树的节点是记录类型，每个非根节点有且只有一个父节点。上一层记录类型和下一层记录类型间的联系是1:N联系。

（2）网状模型

通常情况下会用有向图结构表示实体类型及实体间联系的数据模型称为网状模型（Network Model）。有向图中的节点是记录类型，有向边表示从箭尾一端的记录类型到箭头一端的记录类型间的联系，也是1:N联系。

（3）关系模型

关系模型（Relational Model）的主要特征是用二维表格结构表达实体集，用外键表示实体间联系。与前两种模型相比，关系模型概念简单，容易为初学者理解。关系模型是由若干关系模式组成的集合。关系模式相当于前面提到的记录类型，它是实例化的关系，每个关系实际上是一张二维表格。

3.面向对象模型（Object-Oriented Model）

面向对象模型是一种新兴的数据模型，它采用面向对象的方法来设计数据库。面向对象是以对象为单位，每个对象包含对象的属性和方法，具有类和继承等特点。

目前关系数据库的使用已相当普遍。但是现实世界中仍然存在许多含有复杂数据结构的应用领域，如CAD数据、图形数据等，而关系模型在这方面的处理能力就显得力不从心。因此需要更高级的数据库技术来表达这类信息。面向对象的概念最早出现在程序设计语言中，随后迅速渗透到计算机领域的每一个分支。面向对象数据库是面向对象概念与数据库技术相结合的产物。

面向对象模型中最基本的概念是对象和类。

（1）对象

对象（Object）是现实世界中实体的模型化，与记录的概念相仿，但远比记录复杂。每个对象有一个唯一的标识符，把状态和行为封装在一起。其中，对象的状态是该对象属性值的集合，对象的行为是在对象状态上操作的方法集。

（2）类

将属性集和方法集相同的所有对象组合在一起，可以构成一个类（Class）。类的属性值域可以是基本数据类型（整型、实型、字符串型），也可以是记录型或集合型。也就是说，类可以有嵌套结构。系统中的所有类组成一个有根的有向无环图，叫类层次。

一个类可以从类层次中直接或间接祖先那里继承所有的属性和方法。用这个方法实现了软件的可重用性。

1.2.3 ER模型

微课：实体与关系联系模型

ER模型是通过ER图表示的数据模型，下面通过设计ER图的过程来了解基本的ER方法。ER图是直观表示概念模型的工具。在ER图中有4个基本成分。

矩形框，表示实体类型（考虑问题的对象）。

菱形框，表示联系类型（实体间的联系）。

椭圆形框，表示实体类型和联系类型的属性。

相应的命名均记入各种框中。对于关键码的属性，在属性名下画一条横线。

直线，联系类型与其涉及的实体类型之间以直线连接，并在直线端部标上联系的种类（1:1, 1:N,M:N）。

【例1-1】为仓库管理设计一个ER模型。该仓库主要管理零件的入库、出库和采购等事项。仓库根据需要向各供应商订购零件，而许多工程项目需要仓库供应零件。建立ER图的过程如下。

（1）确定实体类型。本问题共有3个实体类型：项目（Project）、零件（Part）和供应商（Supplier）。

（2）确定联系类型。Project与Part之间是M:N联系，Part和Supplier之间也是M:N联系，分别定义为联系类型P_P和P_S。

（3）把实体类型和联系类型组合成ER图。

（4）确定实体类型和联系类型的属性。

实体类型 Project 有属性项目编号 J#、项目名称 ProjectName、开工日期 Date 等。实体类型Part有属性零件编号P#、零件名称PName、颜色Color等。实体类型Supplier有属性供应商编号S#、供应商名称SName、地址SAddress等。

联系类型 P_P 的属性是项目需要的零售数量 Total。联系类型 P_S 的属性是供应的数量Quantity。

（5）确定实体类型的键，在属于键的属性名称下画一条横线。

完成后的ER图如图1-1所示。

联系类型也可以发生在多于两个实体类型之间。例如，例1-1中，如果规定某个工程项目指定需要某个供应商的零件，那么ER图如图1-2（图中未画出属性）所示。

同一个实体类型的实体之间也有可能发生联系。例如，零件之间的组合关系可以用图1-3表示。

ER模型有两个明显的优点：一个是接近于人的思维，容易理解；另一个是与计算机无关，用户容易接受。因此，ER模型已成为软件工程的一个重要设计方法。

但是ER模型只能说明实体间的语义的联系，还不能进一步说明详细的数据结构。一般到实际问题，总是先设计一个ER模型，然后再把ER模型转换成计算机能实现的数据模型（如二维表形式）。

1.2.4 关系数据库规范化

数据库设计的最基本问题是怎样建立一个合理的数据库模式，使数据库系统无论是在数据存储方面，还是在数据操作方面都具有较好的性能。什么样的模型是合理的模型，什么样的模型是不合理的模型，应该通过什么标准去鉴别和采取什么方法来改进，这些问题是在进行数据库设计之前必须明确的。

为使数据库设计合理可靠、简单实用，长期以来，形成了关系数据库设计理论，即规范化理论。它是根据现实世界存在的数据依赖而进行的关系模式的规范化处理，从而得到合理的数据库设计效果。

1.关系规范化的作用

为了说明方便，先看如表1-1所示的教学管理关系表。

表1-1存在以下问题。

（1）数据冗余（Data Redundancy）

每一个系名对该系的学生人数乘以每个学生选修的课程门数重复存储。

每一个课程名均对选修该门课程的学生重复存储。

每一位教师都对其所教的学生重复存储。

（2）更新异常（Update Anomalies）

由于存在数据冗余，所以有可能导致数据更新异常，这主要表现在以下几个方面。`

插入异常（Insert Anomalies）：由于主键中元素的属性值不能取空值，如果新分配来一位教师或新成立一个系，则这位教师及新系名就无法插入；如果一位教师所开设的课程无人选修或一门课程列入计划但目前不开课，也无法插入。

修改异常（Modification Anomalies）：如果更改一门课程的任课教师，则需要修改多个元组。如果仅部分修改，部分不修改，就会造成数据不一致。同样的情形，如果一个学生转系，则对应此学生的所有元组都必须修改，否则，也会出现数据不一致。

删除异常（Deletion Anomalies）：如果某系的所有学生全部毕业，又没有在读生及新生，当从表中删除毕业学生的选课信息时，则连同此系的信息将全部丢失。同样地，如果所有学生都退选一门课程，则该课程的相关信息也同样丢失了。

由此可知，上述的教学管理关系尽管看起来能满足一定的需求，但存在的问题太多，因此它并不是一个合理的关系模式。

2.解决的方法

不合理的关系模式最突出的问题是数据冗余，而数据冗余的产生有着较为复杂的原因。虽然关系模式充分考虑到文件之间的相互关联而有效处理了多个文件间的联系产生的冗余问题，但关系本身内部数据之间的联系还没有得到充分解决，同一关系模式中的各个属性之间存在某种联系，如学生与系、课程与教师之间存在依赖关系的事实，才使得数据出现大量冗余，引发各种操作异常。这种依赖关系称为数据依赖（Data Independence）。

关系系统中数据冗余产生的重要原因就在于对数据依赖的处理，从而影响到关系模式本身的结构设计。解决数据间的依赖关系常常采用对关系的分解来消除不合理的部分，以减少数据冗余。

在表1-1教学管理关系表中，将教学关系分解为3个关系模式来表达。

学生基本信息（Sno,Sname,Ssex,Dname）

课程信息（Cno,Cname,Tname）

学生成绩（Sno,Cno,Grade），其中Cno为学生选修的课程编号

3.关系模式的规范化

关系数据库中的关系必须满足一定的规范化要求，对于不同的规范化程度可用范式来衡量。范式是符合某一种级别的关系模式的集合，是衡量关系模式规范化程度的标准，达到标准的关系才是规范化的。

范式的概念最早是由 E·F·Codd 提出的。1971到1972年期间，他先后提出了1NF、2NF、3NF的概念，1974年他又和Boyee共同提出了BCNF的概念，1976年Fagin提出了4NF的概念，后来又有人提出了5NF的概念。在这些范式中，最重要的是3NF和BCNF，它们是进行规范化的主要目标。一个低一级范式的关系模式，通过模式分解可以转换为若干高一级范式的关系模式的集合，这个过程称为规范化。实际上，关系模式的规范化主要解决的问题是关系中数据冗余及由此产生的操作异常。而从函数依赖的观点来看，即是消除关系模式中产生数据冗余的函数依赖。

目前主要有6种范式：第一范式、第二范式、第三范式、BC范式、第四范式和第五范式。

满足最低要求的叫第一范式，简称1NF。在第一范式基础上进一步满足一些要求的为第二范式，简称2NF。其余以此类推。显然各种范式之间存在联系，即1NF⊃2NF⊃3NF⊃BCNF⊃4NF⊃5NF，通常把某一关系模式R为第n范式简记为R∈nNF。

（1）第一范式（1NF）

如果关系模式R中每个属性值都是一个不可分解的数据项，则称该关系模式满足第一范式（First Normal Form,1NF），记为R∈1NF。第一范式规定了一个关系中的属性值必须是“原子”的，它排斥了属性值为元组、数组或某种复合数据的可能性，使得关系数据库中所有关系的属性值都是“最简形式”，这样要求的意义在于可以做到起始结构简单，便于以后讨论复杂情形。一般而言，每一个关系模式都必须满足第一范式，1NF是对关系模式的起码要求。

（2）第二范式（2NF）

如果一个关系模式 R∈1NF，且它的所有非主属性都完全函数依赖于 R 的任一候选键，则 R∈2NF。

（3）第三范式（3NF）

如果一个关系模式R∈2NF，且所有非主属性都不传递函数依赖于任何候选键，则R∈3NF。

（4）BC范式（BCNF）

如果关系模式 R∈1NF，对任何非平凡的函数依赖 X→Y,X 均包含码，则 R∈BCNF。BCNF是从1NF直接定义而成的，可以证明，如果R∈BCNF，则R∈3NF。

由BCNF的定义可以看到，每个BCNF的关系模式都具有如下3个性质。

所有非主属性都完全函数依赖于每个候选键。

所有主属性都完全函数依赖于每个不包含它的候选键。

没有任何属性完全函数依赖于非码的任何一组属性。

规范化的基本思想是逐步消除数据依赖中不适合的部分，使各关系模式达到某种程度的“分离”，即“一事一地”的模式设计原则。尽量让一个关系描述一个概念、一个实体或一种联系。若有多于一个概念的，就把它“分解”出去。因此，规范化实质上是概念的单一化。

（5）第四范式（4NF）

如果一个关系模式R∈BCNF，且不存在多值依赖，则R∈4NF。

（6）第五范式（5NF）

如果关系模式R中的每一个连接依赖均由R的候选键所含，则R∈5NF。

1.2.5 关系数据库设计原则

1.组件设计原则

不应该针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件处理的业务设计组件单元数据库；不同组件间对应的数据库表之间的关联应尽可能减少，即使不同组件间的表需要外键关联，也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。

2.自顶向下原则

采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封装的特性，确保与职责相关的数据项被定义在一个对象之内，这些数据项能够完整描述该职责，不会出现职责描述缺失，并且一个对象有且只有一项职责，如果一个对象要负责两个或两个以上的职责，就进行分拆。

3.尽量满足高范式标准原则

根据建立的领域模型映射数据库表，此时应参考数据库设计第二范式，即一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性，也可以是多个属性的集合，不论哪种方式，都应确保关键字的唯一性。在确定关键字时，应保证关键字不会参与业务且不会出现更新异常，这时，最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。

由于领域模型中的每一个对象只有一项职责，对象中的数据项不存在传递依赖，所以，这种思路的数据库表结构设计从一开始就满足第三范式，即一个表应满足第二范式，且属性间不存在传递依赖。

对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系，那么在领域模型中的对象就存在主对象和从对象之分，通常从对象及对象关系映射为的表及表关联关系不存在删除和插入异常。

在映射后得出的数据库表结构中，应再根据第四范式进一步修改，确保不存在多值依赖。这时，应根据反向工程的思路反馈给领域模型。如果表结构中存在多值依赖，则证明领域模型中的对象具有至少两个以上的职责，应根据第一条进行设计修正。

在经过分析后确认所有的表都满足第二、第三、第四范式的情况下，表和表之间的关联尽量采用弱关联，以便于调整和重构表字段和表结构。并且，数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的，只是一个存储介质，所以，表和表之间也不应用强关联来表述业务（数据间的一致性），这一职责应由系统的逻辑层来保证，这种方式也确保了系统对于不正确数据（脏数据）的兼容性。当然，从整个系统的角度来说还是要尽最大努力确保系统不会产生脏数据，单从另一个角度来说，脏数据的产生在一定程度上也是不可避免的，但也要保证系统对这种情况的容错性，这是一个折中的方案。

4.适当建立索引

应针对所有表的主键和外键建立索引，有针对性地建立组合属性的索引，提高检索效率。虽然建立索引会消耗部分系统资源，但比起在检索时搜索整张表中的数据，尤其是表中的数据量较大时所带来的性能影响，以及无索引时的排序操作带来的性能影响，这种方式仍然是值得提倡的。

5.尽量少采用存储过程，避免使用触发器

尽量少采用存储过程，目前已经有很多技术可以替代存储过程、触发器等功能，将数据一致性的保证放在数据库中，对版本控制、开发和部署，以及数据库的迁移都会带来很大的影响。但不可否认，存储过程具有性能上的优势，所以，当系统可使用的硬件不会得到提升，而性能又是非常重要的质量属性时，可经过平衡考虑选用存储过程。

由于触发器与存储过程一样可移植性差，同时触发器会占用较多的服务器资源，对服务器造成压力，另外触发器排错困难，容易造成数据不一致，后期的维护不方便，因此，在实际项目中应避免使用触发器，如果要做联带操作，建议使用事务等机制。