建立数据库系统的目的，是为了实现对现实世界中各种信息的计算机处理。换言之，要实现计算机对现实世界中各种信息的自动化、高效化的处理，首先必须建立能够存储和管理现实世界中的信息的数据库系统。数据模型是数据库系统的核心和基础。任何一种数据库系统，都必须建立在一定的数据模型之上。由于现实世界的复杂性，不可能直接从现实世界中建立数据模型。
现实世界 →（抽象）→ 信息世界 →（转化）→ 数据世界
（建立概念模型） （建立数据模型）
（而首先要把现实世界抽象为信息世界，并建立信息世界中的数据模型，然后再进一步把信息世界中的数据模型转化为可以在计算机中实现的、最终支持数据库系统的数据模型）。信息世界中的数据模型又称为概念模型，概念模型必须具有：
（1）抽象的真实性：是对现实世界本质的、确实存在的内容的抽象。而忽略了现实世界中非本质的和与研究主题无关的内容。
（2）完整、精确的语义表达力，能够模拟现实世界中本质的、与研究主题有关的各种情况
（3）易于理解和修改
（4）易于向DBMS所持的数据模型转换，现实世界抽象成信息世界的目的，是为了用计算机处理现实世界中的信息。
概念模型，作为从现实世界到其数据世界转换的中间模型，它不考虑数据的操作，而只是用比较有效的、自然的方式来描述现实世界的数据及其联系。
最著名、最实用的概念模型设计方法是P.P.S.Chen于1976年提出的“实体－联系模型”（Entity－Relationship Approach），简称E－R模型。
5.1 建立实体联系模型
1、E－R模型的基本构构成：
三个主要概念：实体集、联系集和属性，分别用矩形框、菱形框和椭圆表示。
联系集的类型：一对一（1：1）、 一对多（1：n）、多对多（m：n）及表示
主码的表示：用带下划线的属性表示
2、多元联系
在E－R中，可以表示两个以上实体集之间的联系，称为多元联系。
3、联系的属性
联系集和实体集一样，也可以有自己的属性，来表现联系的特点。
4、自身联系
在一个联系中，一个实体可以出现两次或多次，扮演多个不同角色，此种情况称为实体集的自身联系。
例如，同一部门中，职工与职工之间可以有领导和被领导的关系。
5、子类和 is-a 层次联系
信息世界中常常有这样的实体集B，它属于另一个实体集A，B中实体的都有特殊的属性需要描述，并且这些特殊属性对实体集A的其它实体无意义。在E－R模型中，称B是A的子类，或A是B的父类。两类实体集之间存在着一种层次联系——is-a 联系。
例如，一个企业中的职工实体集和经理实体集，经理集中的每一位经理，又是职工集中的一位职工，他具有职工的所有属性，但他自己的属性“任职时间”对职工集的其他职工却没意义。此时，我们可以说，经理集与职工集存在着 is-a 联系。（P85图5-8所示）
5.2 E－R模型的设计方法
在设计E－R模型时，首先应根据需求分析，确认实体集、联系集和属性这三种E－R模型的基本要素。
需要强调的三条设计原则是：
（1）相对原则：
建模的过程实际上是对对象抽象的过程。实体、联系、属性，是对同一个对象抽象过程的不同解释和理解。在同一情况下不同的人，或同一人在不同的情况下，对事物抽象的结果可能是不同的。
在E－R模型的整个设计过程中，实体、联系和属性不是一成不变的，而可能会被不断的调整和优化。
（2）一致原则：
同一对象在不同的业务系统中抽象的结果要求保持一致。因为业务系统是建立系统的各子系统。
（3）简单原则：
为简化E－R模型，现实世界中的事物，能作属性对待时，应尽量作为属性处理。
属性与实体和联系之间，并无一定界限。当属性满足如下两个条件时，就不能作实体或联系对待：
①它不再具有需要进一步描述的性质，因为属性在含义上是不可再分的数据项
②属性不能再与其它实体集具有联系，即E－R模型中的联系只能是实体集之间的联系。
设计一个大型的企业或单位的E－R模型，一般按照先局部、后整体，最后优化的方法进行。
下面以一个企业的职工信息管理系统为例，说明E－R模型的设计过程：
该管理系统涉及到三个部门的业务：
Ø 人事处管理职工的基本信息、职务信息和所在部门信息
Ø 财务处管理职工的工资情况
Ø 科研处管理科研项目和职工参加项目的情况
第一步：确定局部应用范围，设计局部E－R模型
1、确定局部应用范围
本例中初步决定按照不同的职能部门划分不同的应用范围，即分为三个子模块：人事管理、工资管理和项目管理。
下面以人事管理为例，说明设计局部E－R模型的一般过程。
2、确认实体集
在人事管理中，需要对职工、部门、职称职务进行管理，所以需要确定相应的三个实体集
3、确认实体集间的联系集
需要判断所有二二实体集之间是否存在或存在着怎样联系：
Ø 职工与部门：n:1；
Ø 职工与职称职务：m:n
Ø 部门与职称职务之间没有联系
4、确认实体集及联系集的属性
Ø 职工：职工号、姓名、性别、年龄
Ø 部门：部门号、名称、电话
Ø 职称职务：代号、名称、津贴，住房面积
Ø 职工和职称职务的联系：任职时间；
Ø 职工和部门的联系，没有单独的属性；
5、画出局部E－R模型
（P88图5-12、13、14分别人事管理、工资管理、项目管理的局部E－R模型）
第二步：集成局部E－R模型，形成全局初步的E－R模型
由于各局部E－R模型设计时所考虑问题的角度不同和各自业务需要的不同，合并各局部E－R模型时可能会存在许多不一致的地方，称为冲突。而这些冲突，必须在合并局部E－R模型时进行合理的消除。
冲突主要有如下三类：
1、命名冲突：
包括实体集名、联系集名和属性名之间的同名异义和异名同义等冲突。
同名异义：同样的名称，在不同的局部E－R模型中表示不同含义的对象
异名同义：相同意义的对象在不同局部E－R模型中具有不同的名称
命名冲突通过不同部门间协商解决
2、属性冲突：
包括属性值类型、取值范围、数量单位的冲突
3、结构冲突：
包括两种情况：
Ø 一是同一对象在不同应用中具有的抽象不同。如职工工资，在人事部门的业务中可能作为属性对待，而在财务部门的业务中会作为一个实体集处理。另外，实体集间的联系在不同的业务应用中也可能有不同的联系集。
Ø 二是同一实体在各局部应用中包含的属性个数和属性排列次序不完全相同。
处理冲突，要根据具体需求分析，在各方兼顾的情况下，对发生冲突的属性、实体集、联系集进行合理的调整和综合。形成一个全系统用户共同理解和认可的统一的E－R模型，是合并各局部E－R模型的主要工作和关键所在。
在集成全局E－R模型时，一般采用两两集成的方法进行。将两个具有相同实体集的E－R模型，以该相同实体集为基准进行集成。
第三步：消除冗余，优化全局E－R模型
一个“好”的全局E－R模型，除了能够满足用户的功能需求外，还必须符合下列三个条件：
Ø 实体集个数应尽可能少；
Ø 实体集所含属性尽可能少；
Ø 实体集间的联系无冗余。
对于具有1：1的联系的，且有相同码的两个实体集可以合并，以减少实体集的个数；
另外，有些实体集中的属性，可能是冗余数据，需要进行适当的取舍。
所谓冗余数据，是指在不同实体集中重复存在的，或在同一实体集中可以由其它属性值计算得到的数据。
冗余数据一方面加大了工作量，浪费了存储空间，另一方面，又有可能造成数据的不一致性，破坏数据的完整性。
但并不是所有的数据冗余都必须被消除，所有能合并的实体集都要被合并，有时，为了工作的方便或工效的提高，要保持适当的数据冗余，和合理的实体集分解。
5.3 E－R模型向关系模型的转化
E－R模型是概念模型的表示。它是对现实世界客观事务及其联系的抽象，是用户对系统的应用需求的概念化表示，计算机不能直接处理它。
要使计算机能够处理E－R模型中的信息。首先必须将它转化为具体的DBMS能处理的数据模型。
E－R模型可以向现有的各种数据模型转换。而目前市场上DBMS大部分是基于关系数据模型的，所以我们只学习E－R模型向关系数据模型的转换方法。
从E－R图中可以看出，E－R模型实际上是实体型及实体间联系所组成的有机整体，而前面我们也学过，关系模型的逻辑结构是一系列关系模式的集合。所以将E－R模型转化为关系模型，实质上就是将实体型和联系转化为关系模式。也就是如何用关系模式来表达实体型以及实体集之间的联系的问题。下面学习这种转化的步骤：
第一步：将每一个实体型转换为一个关系模式
将实体集的属性转换成关系的属性，实体集的码对应关系的码。实体集的名对应关系的名。例如职工管理系统全局E－R模型中的五个实体集可以表示如下：
Ø 职工（职工号，姓名，性别，年龄）＊
Ø 部门（部门号，名称，电话，负责人）
Ø 职称职务（代号，名称，津贴，住房面积）
Ø 工资（工资号，补贴，保险，基本工资，实发工资）
Ø 项目（项目号，名称，起始日期，鉴定日期）
第二步：将每个联系转换为关系模式
用关系表示联系，实质上是用关系的属性描述联系，那么该关系的属性从何而来呢？我们说，对于给定的联系R，由它所转换的关系具有以下属性：
Ø 联系R单独的属性都转换为该关系的属性；
Ø 联系R涉及到的每个实体集的码属性（集）转换为该关系的属性。
如职工管理系统中的联系可以表示如下：
Ø 分工（职工号，部门号）＊ n:1联系
Ø 任职（职工号，代号，任职日期） n:m 联系
Ø 拥有（职工号，工资号）＊ 1:1联系，职工号和工资号都可以作为主码
Ø 参加（职工号，项目号，角色） n:m联系
根据联系的类型不同，联系转换为关系后，关系的码的确定也相应有不同的规则：
Ø 若联系R为1:1联系，则每个相关实体的码均可作为关系的候选码；
Ø 若联系R为1:n联系，则关系的码为n端实体的码；
Ø 若联系R为n:m联系，则关系的码为相关实体的码的集合；
第三步：根据具体情况，把具有相同码的多个关系模式合并成一个关系模式
具有相同码的不同关系模式，从本质上说，它们描述的是同一实体的不同侧面（即属性），因此，它们可以合并。合并的过程也就是将对事物不同侧面的描述转化为对事物的全方位的描述。
合并后关系包括两关系的所有属性，这样做可以简化系统，节省存储空间。上列关系中的职工关系、分工关系和拥有关系就可以合并为一：
职工（职工号，姓名，性别，年龄，部门，工资号）
现在我们不难看，当将联系R转换为关系模式时，只有当R为m:n联系时，才有必要建立新的关系模式；当R为1:1、1:n及is-a联系时，只需对与该联系有关的关系作相应的修改即可。
5.4 历史上有影响的数据模型
在关系数据模型产生之前,数据库管理系统普遍使用的数据模型是层次和网状数据模型,它们又被称为非关系数据模型.它们的数据结构和图的结构是相互对应的.
在非关系模型中，概念模型中的实体型反映为记录型, 实体型的属性反映为记录的字段。因此，图的结点表示为记录型，结点之间的连线表示为记录型之间的联系。
在非关系数据模型中，将两个记录型之间的一对一、一对多和多对多的联系，归结为一个只有1:n联系的基本层次联系，（因为1:1可以看作是1:n的特例，m:n可以分解为两个1:n的联系）。
|
双亲结点
|
|
子女结点
|
|
1：n的联系名
|
|
Ri
|
|
Rj
|
|
Lij
|
|
双亲结点
|
|
子女结点
|
层次数据模型，满足下列两个基本条件：
Ø 有且仅有一个结点无双亲，这个结点称为根结点；
Ø 其它结点有且仅有一个双亲。（如P22图1.17）
在层次模型中，同一双亲的子女结点称为“兄弟结点”，没有子女的结点称为“叶结点”。
从P92图5-18可以看出，层次模型象一棵倒立的树，所以层次模型也称为树状模型。
层次模型中的每一个结点表示一个记录型。结点之间的有向线表示记录型之间的联系，这种联系是父与子之间的一对多的联系。
在层次模型的中，任何一个给定的记录值只有按其路径查看时，才能显出它的全部意义，没有一个子女记录值能够脱离双亲记录值而独立存在。
层次模型对具有一对多的层次联系的部门描述得非常自然、直观，易于理解。
历史上最典型层次模型，是1968年由IBM公司推出的数据库管理系统是IMS(Information Management System)。
3、网状模型：
采用层次模型组织数据，使数据的查询变得很简便，无需设计特别的算法，因为查询路径是唯一的。它的这种简单性，一方面给数据的查询带来了好处。另一方面，又使它在描述具有复杂联系的客观事物时，显得力不从心。这使得它不得不重新考虑放宽对其结构中结点的两个限制条件。从而使它让位于网状数据模型，即网状数据模型符合下列两个条件：
Ø 允许有一个以上的结点无双亲；
Ø 允许一个结点可以有多于一个的双亲。
从上述定义看出，层次模型中子女结点与双亲结点的联系是唯一的，而在网状模型中这种联系可以不唯一。因此，在网状模型中，要为每个联系命名，并指出与该联系有关的双亲记录和子女记录。（P93图5-20）
网状数据模型中记录的概念，类似于关系数据模型中关系的概念。如：
记录型→（对应）→关系模式，记录→（对应）→关系的元组，记录字段→（对应）→关系的属性
网状数据库采用网状模型作为数据的组织方式。网状数据库的典型代表是CODASYL系统，这是20世纪70年代数据系统语言研究会CODASYL(Conference On Data Systems Language)下属的数据库任务组（DataBase Task Group, DBTG）提出的一个系统方案，所以又称为DBTG报告。
DBTG报告虽然不是一个具体的数据库管理系统，但是它提出的基本概念、方法和技术具有普遍意义，后来很网状数据库管理系统都是采用DBTG报告所提出的模型设计的。
网状模型取消了对层次模型结点的两个限制，从而构成了比层次结构更复杂的网状结构。尽管网状模型也不支持多对多联系，但由于一个多对多联系可以转化为两个一对多联系，所以网状模型可以间接地描述多对多联系。
例如学生（S）与课程（C）是多对多的联系，一个学生可以选修多门课程，一门课程也可以供多个学生选读，这种联系用层次模型是很难描述的，如果在学生与课程之间建立一个中间实体：“学生－课程(SC)”,这就可以把原来的多对多联系转化为S与SC、C与SC这两个一对多联系,而这种情况正是典型的网状结构,（如P93图5-20）。
网状数据模型的优点：
ü 能够更为直接地描述现实世界，如一个结点可以有多个双亲。
ü 具有良好的性能，存取效率较高。
网状数据模型的缺点：
² 结构比较复杂，且随着应用环境的扩大，数据库的结构变得越来越复杂，不利于最终用户的掌握。
² 其DDL,DML语言复杂，用户不易使用
² 由于记录之间的联系是通过存取路径实现的，应用程序在访问数据时必须选择适当的存取路径，因此，用户必须了解系统结构的细节，加重了编写应用程序的负担。
层次数据库是数据库应用的先驱，而网状数据库则对数据库的概念、方法、技术进行了较全面的发展。所以对这两种数据模型的了解有助于今后对数据库技术的进一步学习和研究。
5.5 数据模型与数据库系统的发展
数据模型是数据库系统的核心和基础。按照计算机所支持的数据模型的发展历史，数据库系统的发展过程可分为以下三个阶段：
一、第一代数据库系统
层次数据库系统和网状数据库系统，统称为第一代数据库系统。支持它们的数据模型的数据结构可以用图来表示。层次模型对应于一棵有根的定向树，网状模型对应于平面有向图。它们被统称为格式化的数据模型
层次和网状数据库系统有许多共同特征，如它们：
1. 都支持数据库的三级模式结构；
2. 都用存取路径来表示数据之间的联系；
3. 用户对数据的存取，必须按照定义了的存取路径进行；
4. 必须清楚地了解数据在数据库中的位置；
5. 对数据的操作是一次一个记录地、导航式地进行；
6. 程序和数据都具有较高的物理独立性，但逻辑独立性较低。
以上六点特征，关键一点是用户和应用程序必须知道所操作的数据在数据库中的位置。而且必须用存取路径来指引系统完成你的指令。既要告诉系统你要干什么？还要指出怎么干？即要使用所谓的导航式的数据操纵语言。
导航式的数据操纵语言的优点是对数据的存取效率高。缺点是要求用户或程序员必须掌握数据库的逻辑结构和物理结构。所以第一代数据库又被称为专家数据库，不利于数据库应用的推广和普及。
二、第二代数据库系统
关系模型数据库系统被称为第二代数据库系统。其特点是：
1. 关系数据模型概念清晰、简单、易于用户理解和使用，而且具有关系代数这个严格理论做基础；
2. 关系模型中，实体和实体间联系均用关系表示，数据结构单一，数据操作简化，克服了非关系模型中由于信息表示方式多样性带来的操作复杂性；
3. 支持非过程化数据操作语言（如SQL），将用户从对数据库的导航式编程语言中解脱出来，大大降低了编程的难度。用户只要指出做什么，而无需指出怎么，因此无需了解数据库的存取路径，这不但减轻了用户的负担，也提高了数据的独立性。
4. 非关系模型采用的是面向记录的操作方式，而关系模型采用的是面向关系即集合的操作，操作的对象和结果都是元组的集合。
自从E.F.Codd于1970年首次提出了关系模型以后，关系数据库系统很快就在数据库领域中占据了相当重要的地位。微机型RDBMS的使用，已使数据库技术广泛应用于企业管理、情报检索、科学研究、管理信息系统等各个领域。
三、第三代数据库系统
随着数据库技术的发展，人们正试图将数据库技术应用到更深更广的领域，如计算机辅助设计／管理／集成制造（CAD/CAM/CIMS）、联机分析处理（OLAP）、办公自动化系统（OAS）、地理信息系统（GIS）／知识库系统、图像处理、模式识别、实时仿真等。变些应用有着与传统应用不同的行为特性和数据特性。关系数据模型在这些应用中开始显露出许多缺陷，如：
1. 不能存储和处理复杂对象。
2. 支持的数据类型有限，不能存储和检索复杂的数据类型。
3. 关系数据库语言（SQL）与程序设计语言之间差距较大，不能进行无缝连接。
4. 关系模型对应用环境适应性差，缺乏灵活丰富的建模能力。
为此，人们已开始提出并发展了许多新的数据模型。目前，关于数据模型的研究，主要沿着下列三个方向进行：
1. 对传统的关系数据模型进行扩充，引入构造器，使之能表达复杂的数据类型，增强其建模能力。
2. 抛弃关系数据模型，发展全新的语义数据模型。语义数据模型可表达复杂的结构和丰富的语义，具有全新的数据构造器和数据处理原语。代表模型有：语义数据模型（SDM）、E－R模型、函数数据模型（FDM）
3. 结合语义数据模型和面向对象程序设计方法，提出了面向对象数据模型（OODM）。它是一种可扩充的数据模型，以对象为基础，支持面向对象的分析、设计和编程。（第九章详介）
人们把支持新的数据模型的数据库系统，统称为第三代数据库系统。究竟谁能最终成为第三代数据库系统的基本模型，目前还处于诸侯纷起，群雄争霸的时期，但无论是基于哪一种数据模型，体系结构如何，应用在何种领域，第三代数据库系统都应具有以下三个基本特点：
1. 必须保持或继承第二代数据库系统的技术
2. 应支持数据管理、对象管理和知识管理
3. 应该对其他系统开放
本章我们主要学习了实体－联系模型（E－R模型）的建立、设计方法和步骤；并学习了E－R模型向关系模型的转化过程；还了解了历史上有影响的层次和网状数据模型的特点，最后介绍了数据模型和数据库系统发展的历史和前景。其中最关键的内容是E－R模型的设计和E－R模型向关系数据模型的转换，要求一定要掌握。