前言
数据建模就是通过减低数据库设计的复杂度得到各个方面都能理解的数据抽象，包括定义实以及它们之间的关系。接下来学习数据建模的基本概念以及数据模型的发展过程。
正题
在开始编写文章前，有几个问题需要思考一下：
- 什么数据模型
- 生成数据模型的业务规则
- 数据模型构成
- 数据模型的类别
- 数据模型的抽象层次
1. 什么是数据模型
数据模型（data model）是对复杂现实世界数据结构的一种简单表达，如采用图形方式。广而言之，模型是对复杂现实世界对象或事件的抽象，它能帮助我们理解现实世界的复杂性。而在数据库环境中，数据模型则是表示数据结构及其特征、关系、约束、变换以及为特定问题域提供支持的其他组成。
2. 生成数据模型的业务规则
当数据库设计人员决定使用实体、属性和联系建立数据模型时，他们首先应对企业的数据进行全面了解和分析，如企业有哪些数据种类、如何使用及何时使用这些数据等。但是，这些数据和信息本身不会对企业整个业务的了解。从数据库角度看，数据只有在其能正确反映所定义的业务规则时才有意义。业务规则（Business Rule）是对特定组织的策略、规程和准则的简要、清晰和无歧义描述。从某种意义上讲，业务规则是一个误称，实际上也可应用于存储和利用数据产生信息的任意规模组织，如企业、政府机构、宗教团体或研究所等。
业务规则来自对企业操作的详细描述，可帮助企业创建和实施具体活动，因此必须明确制定并及时更新，以正确反映企业操作环境的变化。
正确的业务规则可用于定义实体、属性、联系和约束。任何时候，当我们看到“一个代理人可以为多个客户服务，而每个客户只能由一个代理人服务”的联系描述时，那就是业务规则在发生作用。
为了提高效率，业务规则应简单易懂且广泛宣传，以确保组织中的所有人都能正确理解。业务规则是用简单语言描述从公司视觉所看到数据的特征。例如：
- 一个客户可以产生多张发票。
- 一张发票只能由一个客户产生。
- 少于 10 名雇员或超过 30 名雇员都不能安排培训会议。
这些业务规则可建立实体、联系和约束。
2.1 发现业务规则
业务规则的主要来源是公司经理、策略制定者、部门经理以及书面文档（如公司的规程、标准或操作手册）。一个更加快速直接获得业务规则的方法是直接同用户对话。但不幸的是，由于各个人的理解不同，当需要制定特定的业务规则时，用户显得不太靠谱。例如，维护部门的技工可能认为任何一个技工都可以启动一个维护程序，然而，事实上只有授权检查的人才能完成此项任务。这种区别看起来似乎很平常，但是可能产生重大的法律后果。虽然用户是制定业务规则的决定性因素，但是用户的理解仍需做进一步验证。如果与许多从事相同工作的人进行交流，常常会对该项工作产生不同的理解，这很可能被认为是管理上的问题。因此，这种泛泛的调查分析不能帮助数据库设计人员，他们的职责就是要协调这些差异并对产生的结果进行验证，以确保得到合适且准确的业务规则。
识别和确定业务规则对数据库设计至关重要，因为它能够：
- 帮助企业进行数据标准化。
- 为用户和设计人员提供交流工具。
- 帮助设计人员理解数据的本质、作用和范围。
- 帮助设计人员理解业务流程。
- 帮助设计人员开发出合适的联系参与规则和约束，并建立正确的数据模型。
当然，并不是所有的业务规则都可以被建模。
2.2 将业务规则转化成数据模型组件
业务规则为正确识别实体、属性、联系和约束提供了基础。在现实世界中，通常用名称来标识对象。如果业务环境需要保持对象的状态，那么应对其产生专门的业务规则。一般来说，业务规则中的名词可转化成数据模型中的实体，而与名词相连的动词（主动或被动）则可转化成实体之间的联系。例如，业务规则“一位客户可产生多张发票”包含两个名词（客户和发票）和一个动词（产生），我们可从中推出：
- 客户和发票是系统感兴趣的对象，应表示为实体。
- 客户和发票间存在“产生”联系。
为正确判定联系的类型，应考虑联系的双向特性。如果在上面规则的基础上在增加一条规则“一张发票只能由一位客户所产生”，那么该联系就是一对多（1:M）联系，其中客户是“一”，发票是“多”。
作为一般准则，可通过下列两个问题判定联系的类型：
- 有多少 B 的实例与一个 A 的实例关联？
- 有多少 A 的实例与一个 B 的实例关联？
3. 数据模型构成
数据模型的基本组成包括实体、属性、联系和约束。
- 实体（Entity）：可以是任何事物，如一个人，一个地点、一个物件或一个事件等，其数据将被收集和存储。一个实体表示现实世界中一类特定类型对象。实体是“可区分的”，即每个实体是独特且唯一的。
- 属性（Attribute）：用于描述实体的特征。属性等同于文件系统中的字段。
- 联系（Relationship）：用于描述实体之间的关联。联系有 3 种类型：一对多、多对多、一对一，可分别用符号 1：M（或 1..*）、M：N（或 *..*）和 1：1（或 1..1）表示。
4. 数据模型的类别
4.1 层次模型
层次模型诞生于 20 世纪 60 年代，主要用于复杂制造项目的大量数据管理。它的基本逻辑结构可以用一棵倒置的树表示。层次结构包含层次和段。一个段（Segment）等同于文件系统中的记录类型。在层次结构中，顶层（树根）是其直接分支段的双亲。
层次模型具有许多文件系统并不具备的优势。事实上，层次数据模型的许多特征是现代数据模型的基础，并以不同的形式应用在现在的数据库中。
4.2 网状模型
网状模型不仅比层次模型能更有效地表示复杂的数据联系。而且还能提升数据库性能和有利于推行数据库标准。为了帮助建立数据库标准，数据系统语言会议（Conference on Data Systems Languages，CODSL）在 20 世纪 60 年代末建立了一个数据库工作组（Database Task Group，DBTG），专门负责为数据库创建和数据操作定义标准规范。最终的 DBTG 报告包含了 3 个非常重要的数据库组件规范。
- 模式：从数据库管理员角度来看，模式是整个数据库的概念结构，它负责定义数据库名称、记录类型和由记录构成的组件。
- 子模式：负责定义访问数据库数据的应用程序所“看到”的数据库。子模式的存在使得应用程序只需调用子模式就能访问数据库文件。
- 数据管理语言（Data Management Language）：DML 负责定义管理数据的环境。
DBTG 指定了 3 个不同的 DML 组件：
- 模式的数据定义语言（Data Definition Language，DDL）：帮助数据库管理员定义模式组件。
- 子模式 DDL：帮助应用程序定义应用需要使用的数据库组件。
- 数据操纵语言：用于访问数据库中的数据。
在网状模型中，用户将网状数据库看做是一个由一对多联系记录组成的集合。然而，与层次模型不同，网状模型允许一条记录拥有多个双亲。在网状数据库中，一个联系称为一个集合。每个集合至少由两个记录类型构成：一个主记录和一个成员记录。一个集合代表主记录和成员记录之间的一个一对多联系。
随着信息量不断增长，人们越来越需要具有功能强大的数据库和应用程序，而网状模型越来越不能适应这种需求。而且，虽然网状数据库具有一定的数据独立性，但是数据库结构的改变仍然可能需修改相应的数据库应用程序。正是由于层次模型和网状模型存在这些不足，在 20 世纪 80 年代它们已被关系数据模型广泛替代。
4.3 关系模型
关系模型的基础是数学中的“关系”概念。简单地说，关系（Relation）有时也称为表（table），它是由交叉的行与列构成的矩阵，其中每行称为一个元组（Tuple），每列代表一个属性。同时，关系模型也描述了一组基于高级数学概念的关系数据操作集合。
关系模型通过非常复杂的关系数据库管理系统（Relation Database Management System，RDBMS）实现。RDBMS 负责完成层次和网状数据库管理系统所提供的基本功能。此外，RDBMS 还集成了其他一些功能，使得关系数据库模型更容易理解和实现。RDBMS 的最大优势在于它对用户隐藏了关系模型的复杂性。RDBMS 负责管理所有的物理细节，而用户只看到由一系列存储数据的表构成的关系数据库，它们可用直观和逻辑的方式操纵和查询数据。
关系数据库中的表与表之间是通过共享共同属性（列中的值）实现相互关联。虽然表与表是相互独立的，但是仍然可以很容易地将多个表中的数据联系起来。关系模型提供了最低水平的可控冗余，消除了文件系统中存在的大多数冗余。联系的类型（1:1，1:M 或 M:N）在关系模式中经常出现。
一个关系表是一个由相关实体组成的集合。从这个意义上讲，表就像一个文件。但是表与文件的本质区别是表所产生的数据具有结构独立性，因为它是纯粹的逻辑结构。用户和设计人员不需要关心表中的数据如何存储在数据库中。
关系数据模型取得优势的另一个原因是它提供了强大且灵活的查询语言。对大多数关系数据库软件来说，查询语言是结构化查询语言（Structured Query Language，SQL），它允许用户只说明需要做什么而不必说明如何去做。RDBMS 利用 SQL 将用户查询转化成数据检索命令。SQL 使得查询数据的代价比任何其他类型数据库或文件更小。
对用户而言，任何基于 SQL 的关系数据库应用程序都包括 3 个部分：用户接口、数据库表集合以及 SQL 引擎，具体为：
- 用户接口：接口主要是方便用户通过自动生成的 SQL 代码访问数据。每种接口都是数据库软件厂商提供的数据访问产品。有的数据库软件提供了应用程序生成器，以帮助用户设计个性化接口。
- 数据表集合：在关系数据库中，所有数据都存放在表中，以一种简单易懂的方式展现给用户。表与表之间是相互独立的，但不同表可通过公共属性的公共值互相关联。
- SQL 引擎：SQL 引擎负责执行所有查询或数据请求，它是 DBMS 软件的一部分。用户可使用 SQL 创建结构、存取数据以及维护表。SQL 引擎负责处理所有的用户请求，而这大部分是在幕后进行而用户并不知情。因此，SQL 是一种声明性语言，即只需说明要做什么而不必说明如何去做。（软件中的引擎：实现了核心业务逻辑的代码）
4.4 实体联系模型
关系数据库的概念简洁性使得 RDBMS 得到了广泛使用，而且交易和信息需求的快速增长要求创建更为复杂的数据库结构。这些都要求提供更为高效的数据库设计工具。
复杂的设计活动要求使用简单的概念得到正确地结果。虽然在概念上关系模型确实比层次和网状模型有了很大程度的提高，但是它仍然不是高效的数据库设计工具。由于图形比文本更容易验证结构的正确性，因此数据库设计人员更倾向于使用图形化工具描述实体以及实体间的联系。于是，实体联系模型（Entity Relational Model，ERM）成为广泛接受的数据建模标准。
它是一种图形化表示方法，能够反映数据库结构中实体以及实体之间的联系。由于 ER 数据模型很好地弥补了关系模型概念描述的不足，因此很快就得到普及。关系模型和 ERM 一起共同奠定了结构化数据库设计的基础。
ER 模型用实体联系图（Entity Relation Diagram，ERD）表示，即运用图形对数据库组件进行建模。ER 模型主要有一下组件：
- 实体：如前所述，实体可以是其数据将被收集和存储的任何事物。在 ERD 图中，用矩形（也称实体盒）表示实体。实体的名称通常是名词，写在矩形中央，一般用字母书写且是单数形式。通常，当将 ERD 应用到关系模型时，一个实体对应一个关系表。关系表的每一行称为 ER 模型中的一个实体实例（Entity Instance）或实体发生（Entity Occurence）。每个实体都用一组属性描述其详细特征。
- 联系：联系用于描述数据之间的关联，大部分联系用于描述两个实体之间的关联。有三种类型联系：一对多（1:M），多对多（M:N）和一对一（1:1）。
4.5 面向对象模型
随着现实世界问题复杂性的不断增加，人们越来越需要能更准确描述现实世界的数据模型。面向对象数据模型（Object-oriented Data Model，OODM）是面向对象数据库管理系统（Object-oriented Database Management System，OODBMS）的基础，其数据和联系都包含在称为对象（Object）的结构中。
OODM 采用不同方式定义和使用实体。与关系模型中的实体相似，对象由其自身所包含的内容所描述。但与实体的区别是：对象不仅包含了它与其他对象之间的联系信息。因此，对象所包含的实体被赋予了更多的含义，正是由于语义可指明含义，因此 OODM 也被称作为语义数据模型。
随着 OODM 的发展，面向对象数据模型允许对象包含对它所进行的所有操作，如修改、查询以及打印数据值等。由于对象包含了数据、不同类型的联系以及操作，因此对象是自包含的，已称为自治结构的基本构件。
面向对象数据模型包含以下组件：
- 对象是现实世界实体的抽象。概括的说，一个对象等同于 ER 模型中的一个实体。更准确地说，一个对象只表示一个实体实例。对象的语义是由对象列表中的条目定义。
- 属性用于描述对象的特征。
- 拥有相似特征的对象组成类。类（Class）是具有共同结构（属性）和行为（方法）的一组相似对象所组成的集合。一般地，类与 ER 模型中的实体集相似。但类与实体集的不同之处在于，类包含了一组称为方法的程序。方法（Method）代表了现实世界中的行为。简言之，方法等同于传统编程语言中的过程。在面向对象的术语中，方法用于定义对象的行为。
- 类可组织成一个类层次结构。类层次结构像一颗倒置的树，其中每个类只有一个双亲。
- 继承是指类层次结构中的对象可继承其上层类的属性和方法的能力。
面向对象数据模型通常使用统一建模语言（Unified Modeling Language，UML）描述类图。UML 是基于面向对象概念的一种语言，它通过一组图像和符号对系统进行图形化建模。在较大的 UML 面向对象系统建模语言中，主要使用 UML 类图表示数据和数据之间的联系。
在数据模型发展过程中可以发现，作为一种数据模型，它必须具有下列共同特性才被人们广泛接受：
- 数据模型必须在不被破坏数据库语义完整性的前提下，具有一定程度上的概念简洁性。一个比现实世界还要复杂的数据模型是没有任何意义的。
- 数据模型必须尽可能真实的表达现实世界的特征。该目标可以通过对数据表示增加语义信息实现。语义主要关注数据的动态行为，而数据表示则组成现实世界的静态特征。
- 现实世界转换（行为）的表示必须符合数据模型的一致性和完整性要求。
每个新的数据模型都在克服之前模型缺点的基础上向上发展的。网状模型替代层次模型，是因为网状模型能更容易表示复杂的多对多联系。与层次和网状模型相比，关系模型具有更多的优势，如数据表示简单、更好的数据独立性以及易于使用的查询语言等，它已成为商业应用的主要数据模型。虽然 OO 和 ERDM 拥有足够坚实的根基，但是它们还不能关系模型。在将来，一个成功的数据模型必须能够管理非结构化数据，并支持通过 XML 进行数据交换。
特别需要指出的是，并非所有数据模型都是为相同目的而创建的。相反，不同数据模型具有不同的使用范围。例如，概念模型适用于高层次数据建模，而实现模型则适用于物理实现层的数据存储管理。实体联系模型是一种概念模型，而层次模型和网状模型则是实现模型。有些模型既是概念模型又是实现模型，如关系模型和 OODM。
5. 数据抽象程度
设计一个可用的数据库需要同样的抽象过程，即数据库设计人员设计出全局数据的抽象视图，然后在设计过程中逐渐添加具体细节内容，最终接近具体实现。使用不同层次的抽象对整合整个组织内不同层次的数据视图也很有帮助。美国国家标准协会（American National Standards Institute，ANSI）的标准计划和需求委员会（SPARC）定义了基于数据抽象程度的数据建模框架，它将数据抽象分为 3 个层次：外部、概念和内部。
5.1 外模型
外模型是用户数据视图。此处的用户是指通过应用程序操纵数据并产生信息的人，他们一般是在特定部分的应用环境中工作。通常，公司可分为许多部门，如销售、财务和市场等。这些部门都有各自的约束和需求，且都使用公司全局数据的子集。因此，每个部门的用户都认为他们的数据子集与公司的其他部门是分离的或者是外部的。
使用外部视图表示数据库的子集具有以下优点：
- 易于识别每个部门所需的特定数据；
- 有助于简化设计者的工作。设计者可通过外部视图检查数据模型，以确保它能支持外部模型所定义的所有处理、操作需求和约束；
- 有助于保证数据库安全、当每个部门只允许访问自己的数据子集时，数据库的安全不易受到破坏；
- 易于开发应用程序；
5.2 概念模型
确定了外部视图后，可运用 ER 图表示概念模型，概念模型用于标识整个组织的数据库全局视图，即负责将所有外部视图（实体、联系、约束和处理）整合成包含企业所有数据的单一全局视图。概念模型也称为概念模式，它是对数据对象进行识别和高层次描述的基础。
ER 模型是应用最广泛的概念模型，它利用 ER 图对数据进行图形化描述。事实上，ER 图是数据库的基本“设计蓝图”，可用于表示概念模型。
概念模型具有以下优点：
- 提供了一个易于理解的数据总体视图（宏观层面）。
- 概念模型独立于软件和硬件。软件独立性和硬件独立性意味着模型不依赖于实现该模型的 DBMS 软件和硬件，这样，无论是硬件或 DBMS 软件的改变都不会影响到概念层次数据库设计。
5.3 内模型
一旦选定了 DBMS，内模型负责将概念模型映射到 DBMS 上，内模型是指 DBMS 所“看到”的数据库结构。换言之，内模型要求设计者将概念模型的特征和约束映射到所选择的实现模型上去。内模型是用所选择的数据库结构来表示内模型。
由于内模型依赖特定的数据库软件，因此内模型是软件相关的，即当 DBMS 软件发生改变时，内模型也要随之改变，以适应数据库模型的特性和需求。然而，内模型仍然是硬件无关的，它不会受软件所安装的计算机影响。因此，存储设备的改变甚至是操作系统的变化不会影响内模型。
5.4 物理模型
物理模型位于抽象的最底层，主要用于描述数据在磁盘、磁带等物理存储介质上的保存方式。物理模型需要定义存储设备以及在这些设备上获得数据的（物理）存取方法，因此物理模型既软件相关又硬件相关。物理模型所使用的存储结构依赖于软件（DBMS 和操作系统）和计算机能处理的存储设备类型。物理模型定义的准确性要求该层次设计人员对硬件和数据库设计软件都非常熟悉。
早期的数据模型迫使数据库设计人员不得不考虑物理模型中的数据存储细节。而现在的关系模型更注重逻辑层次上的设计而不是物理层次，因此，关系模型不要求设计物理层次细节。
虽然关系模型不要求设计人员关注数据的物理存储特性，但是为了提高系统性能，关系模型可能需要在物理层次进行调优。特别是大型机环境下的海量数据库，性能调优显得尤其重要。即便如此，物理层次上的性能调优也不需清楚物理数据的存储特性。
物理模型主要依赖于 DBMS、存取文件的方法以及操作系统所支持的硬件存储设备。物理模型发生改变但不影响内模型，称之为物理独立性。因此，存储设备或方法甚至是操作系统的改变都不会影响到内模型。
