两类数据模型

数据模型应满足三方面要求：

• 一是能比较真实地模拟现实世界；
• 二是容易为人所理解；
• 三是便于在计算机上实现。

一种数据模型要很好地、全面地满足这三方面的要求在目前尚很困难。
因此，在数据库系统中针对不同的使用对象和应用目的，采用不同的数据模型。
如同在建筑设计和施工的不同阶段需要不同的图纸一样，在开发实施数据库应用系统中也需要使用不同的数据模型：概念模型、逻辑模型和物理模型。
根据模型应用的不同目的，可以将这些模型划分为两大类，它们分别属于两个不同的层次。

• 第一类是：概念模型；
• 第二类是：逻辑模型和物理模型。

第一类概念模型（conceptual model）也称信息模型，按用户的观点来对数据和信息建模，主要用于数据库设计。
第二类中的逻辑模型：主要包括层次模型（hierarchical model）、网状模型（network model）、关系模型（relational model）、面向对象数据模型(（object oriented data model）和对象关系数据模型（object relational data model）、半结构化数据模型（semistructured data model）等。它是按计算机系统的观点对数据建模，主要用于数据库管理系统的实现。
第二类中的物理模型：是对数据最底层的抽象，它描述数据在系统内部的表示方式和存取方法，或在磁盘或磁带上的存储方式和存取方法，是面向计算机系统的。物理模型的具体实现是数据库管理系统的任务，数据库设计人员要了解和选择物理模型，最终用户则不必考虑物理级的细节。

数据模型是数据库系统的核心和基础。
各种机器上实现的数据库管理系统软件都是基于某种数据模型或者说是支持某种数据模型的。
为了把现实世界中的具体事物抽象、组织为某一数据库管理系统支持的数据模型，人们常常首先将现实世界抽象为信息世界，然后将信息世界转换为机器世界。
也就是说，首先把现实世界中的客观对象抽象为某一种信息结构，这种信息结构并不依赖于具体的计算机系统，不是某一个数据库管理系统支持的数据模型，而是概念级的模型；然后再把概念模型转换为计算机上某一数据库管理系统支持的数据模型，这一过程如下图所示。

从现实世界到概念模型的转换是由数据库设计人员完成的；
从概念模型到逻辑模型的转换可以由数据库设计人员完成，也可以用数据库设计工具协助设计人员完成；
从逻辑模型到物理模型的转换主要是由数据库管理系统完成的。

下面首先介绍概念模型，数据模型的组成要素，然后介绍三个常用的数据模型。

概念模型

概念模型的一种表示方法：实体 - 联系模型（E-R模型）

E-R图
概念模型实际上是现实世界到机器世界的一个中间层次。
概念模型用于信息世界的建模，是现实世界到信息世界的第一层抽象，是数据库设计人员进行数据库设计的有力工具，也是数据库设计人员和用户之间进行交流的语言，因此概念模型一方面应该具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识，另一方面它还应该简单、清晰、易于用户理解。

信息世界中的基本概念

信息世界主要涉及以下一些概念。

实体（entity）
客观存在并可相互区别的事物称为实体。实体可以是具体的人、事、物，也可以是抽象的概念或联系，例如，一个职工、一个学生、一个部门、一门课、学生的一次选课、部门的一次订货、教师与院系的工作关系（即某位教师在某院系工作）等都是实体。

属性（attribute）
实体所具有的某一特性称为属性。一个实体可以由若干个属性来刻画。

例如，学生实体可以由学号、姓名、性别、出生年月、所在院系、入学时间等属性组成，属性组合（201315121,张山，男，199505，计算机系，2013）即表征了一个学生。

码（key）
唯一标识实体的属性集称为码。例如学号是学生实体的码。

实体型（entity type）
具有相同属性的实体必然具有共同的特征和性质。
用实体名及其属性名集合来抽象和刻画同类实体，称为实体型。

例如，学生（学号，姓名，性别，出生年月，所在院系，入学时间）就是一个实体型。

实体集（entity set）
同一类型实体的集合称为实体集。例如，全体学生就是一个实体集。

联系（relationship）
在现实世界中，事物内部以及事物之间是有联系的，这些联系在信息世界中反映为实体（型）内部的联系和实体（型）之间的联系。

• 实体内部的联系通常是指：组成实体的各属性之间的联系；
• 实体之间的联系通常是指：不同实体集之间的联系。

实体之间的联系有一对一、一对多和多对多等多种类型。 联系的多种类型如果对于实体集 A 中的每一个实体，实体集 B 中至多有一个（也可以没有）实体与之联系，反之亦然，则称实体集 A 与实体集 B 具有一对一联系。

如果对于实体集 A 中的每一个实体，实体集 B 中有 n 个实体（n ≥ 0）与之联系，反之，对于实体集 B 中的每一个实体，实体集 A 中至多只有一个实体与之联系，则称实体集 A 与实体集 B 有一对多联系。

如果对于实体集 A 中的每一个实体，实体集 B 中有 n 个实体（n ≥ 0）与之联系，反之，对于实体集 B 中的每一个实体，实体集 A 中也有 m 个实体（m ≥ 0）与之联系，则称实体集 A 与实体集 B 具有多对多联系。

例如一门课程可以同时有若干名学生选修，而一个学生可以同时选修多门课程，则课程实体与学生实体具有多对多联系。

数据模型的组成要素

一般地讲，数据模型是严格定义的一组概念的集合。
这些概念精确地描述了系统的静态特性、动态特性和完整性约束条件（integrity constraints）。
因此数据模型通常由数据结构、数据操作和数据的完整性约束条件三部分组成。

1. 数据结构

数据结构描述数据库的组成对象以及对象之间的联系。
也就是说，数据结构描述的内容有两类：

• 一类是与对象的类型、内容、性质有关的，如网状模型中的数据项、记录，关系模型中的域、属性、关系等；
• 一类是与数据之间联系有关的对象，如网状模型中的系型（set type）。

数据结构是刻画一个数据模型性质最重要的方面。因此在数据库系统中，人们通常按照其数据结构的类型来命名数据模型。例如层次结构、网状结构和关系结构的数据模型分别命名为层次模型、网状模型和关系模型。
总之，数据结构是所描述的对象类型的集合，是对系统静态特性的描述。

2. 数据操作

数据操作是指对数据库中各种对象（型）的实例（值）允许执行的操作的集合，包括操作及有关的操作规则。
数据库主要有查询和更新（包括插入、删除、修改）两大类操作。
数据模型必须定义这些操作的确切含义、操作符号、操作规则（如优先级）以及实现操作的语言。
数据操作是对系统动态特性的描述。

3. 数据的完整性约束条件

数据的完整性约束条件是一组完整性规则。
完整性规则是给定的数据模型中数据及其联系所具有的制约和依存规则，用以限定符合数据模型的数据库状态以及状态的变化，以保证数据的正确、有效和相容。
数据模型应该反映和规定其必须遵守的基本的和通用的完整性约束条件。

例如，在关系模型中，任何关系必须满足实体完整性和参照完整性两个条件

此外，数据模型还应该提供定义完整性约束条件的机制，以反映具体应用所涉及的数据必须遵守的特定的语义约束条件。

例如，在某大学的数据库中规定学生成绩如果有 6 门以上不及格将不能授予学士学位，教授的退休年龄是 65 周岁，男职工的退休年龄是 60 周岁，女职工的退休年龄是 55 周岁等。

逻辑数据模型

数据库领域中主要的逻辑数据模型有：

• 层次模型（hierarchical model）
• 网状模型（network model）
• 关系模型（relational model）
• 面向对象数据模型（object oriented data model）
• 对象关系数据模型（object relational data model）
• 半结构化数据模型（semistructure data model）

其中层次模型和网状模型统称为格式化模型。
随着 Internet 的迅速发展，Web 上各种半结构化、非结构化数据源已经成为重要的信息来源，产生了以 XML 为代表的半结构化数据模型和非结构化数据模型。

关系模型

关系模型是逻辑数据模型的一种。

关系模型是最重要的一种数据模型。关系数据库系统采用关系模型作为数据的组织。

关系模型的数据结构

关系模型与以往的模型不同，它是建立在严格的数学概念的基础上的。
从用户观点看，关系模型由一组关系组成。每个关系的数据结构是一张规范化的二维表。

下面以学生登记表为例，介绍关系模型中的一些术语。

• 关系（relation）：一个关系对应通常说的一张表，例如这张学生登记表。
• 元组（tuple）：表中的一行即为一个元组。

• 属性（attribute）：表中的一列即为一个属性，给每一个属性起一个名称即属性名。

  如这张学生登记表有 6 列，对应 6 个属性（学号，姓名，年龄，性别，系名和年级）。

• 码（key）：也称为码键。表中的某个属性组，码可以唯一确定一个元组。

  如这张学生登记表中的学号可以唯一确定一个学生，也就成为本关系的码。

• 域（domain）：域是一组具有相同数据类型的值的集合。属性的取值范围来自某个域。

  如人的年龄一般在 1~120 岁之间，大学生年龄属性的域是（ 15~45 岁），性别的域是（男，女），系名的域是一个学校所有系名的集合。

• 分量：元组中的一个属性值。

• 关系模式：对关系的描述，一般表示为关系名（属性1，属性2，…，属性n）

例如，上面的关系可描述为学生（学号，姓名，年龄，性别，系名，年级）

关系模型要求关系必须是规范化的，即要求关系必须满足一定的规范条件，这些规范条件中最基本的一条就是，关系的每一个分量必须是一个不可分的数据项，也就是说，不允许表中还有表。

例如，下表中工资和扣除是可分的数据项，工资又分为基本工资、岗位津贴和业绩津贴，扣除又分为三险和个人所得税。因此，下表就不符合关系模型要求。

一个工资表（表中有表）实例

可以把关系和现实生活中的表格所使用的术语做一个粗略的对比，如下表所示。

关系模型的数据操作与完整性约束

关系模型的数据操纵主要包括查询、插入、删除和更新数据。
这些操作必须满足关系的完整性约束条件。
关系的完整性约束条件包括三大类：实体完整性、参照完整性和用户定义的完整性。

关系模型中的数据操作是集合操作，操作对象和操作结果都是关系，即若干元组的集合，而不像格式化模型中那样是单记录的操作方式。
另一方面，关系模型把存取路径向用户隐蔽起来，用户只要指出“干什么”或“找什么”，不必详细说明“怎么干”或“怎么找”，从而大大地提高了数据的独立性，提高了用户生产率。

关系模型的优缺点

关系模型具有下列优点：

• 关系模型与格式化模型不同，关系模型是建立在严格的数学概念的基础上的。
• 关系模型的概念单一。无论实体还是实体之间的联系都用关系来表示。对数据的检索和更新结果也是关系（即表）。所以其数据结构简单、清晰，用户易懂易用。
• 关系模型的存取路径对用户透明，从而具有更高的数据独立性、更好的安全保密性，也简化了程序员的工作和数据库开发建立的工作。

所以关系模型诞生以后发展迅速，深受用户的喜爱。
当然，关系模型也有缺点，例如，由于存取路径对用户是隐蔽的，查询效率往往不如格式化数据模型。为了提高性能，数据库管理系统必须对用户的查询请求进行优化，因此增加了开发数据库管理系统的难度。不过用户不必考虑这些系统内部的优化技术细节。

E-R图向关系模型的转换

E-R图向关系模型的转换要解决的问题是，如何将实体型和实体间的联系转换为关系模式，如何确定这些关系模式的属性和码。
关系模型的逻辑结构是一组关系模式的集合。E-R图则是由实体型、实体的属性和实体型之间的联系三个要素组成的，所以将E-R图转换为关系模型实际上就是要将实体型、实体的属性和实体型之间的联系转换为关系模式。
转换的一般原则：一个实体型转换为一个关系模式，关系的属性就是实体的属性，关系的码就是实体的码。
对于实体型间的联系有以下不同的情况：

一个 1:1 联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。

• 如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。
• 如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。

一个 1:n 联系可以转换为一个独立的关系模式，也可以与 n 端对应的关系模式合并。

• 如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为 n 端实体的码。

一个 m:n 联系转换为一个关系模式，与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。

三个或三个以上实体间的一个多元联系可以转换为一个关系模式。
与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。

具有相同码的关系模式可合并。

常用中间件的数据模型

数据模型有哪几种

• 结构化
• 半结构化
• 非结构化

MySQL
Redis
MongoDB
Zookeeper
ES