本文属于「数据库系统」系列文章之一，这一系列着重于「数据库系统知识的学习与实践」。由于文章内容随时可能发生更新变动，欢迎关注和收藏数据库系统系列文章汇总目录一文以作备忘。需要特别说明的是，为了透彻理解和全面掌握数据库系统，本系列文章中参考了诸多博客、教程、文档、书籍等资料，限于时间精力有限，这里无法一一列出。部分重要资料的不完全参考目录如下所示，在后续学习整理中还会逐渐补充：

• 数据库系统概念 第六版 Database System Concepts, Sixth Edition ，作者是 Abraham Silberschatz, Henry F. Korth, S. Sudarshan ，机械工业出版社
• 数据库系统概论 第五版，王珊 萨师煊编著，高等教育出版社

将需求分析得到的用户需求、抽象为信息结构（即概念模型）的过程，就是概念结构设计。它是整个数据库设计的关键。本节讲解概念模型的特点，以及用E-R模型来表示概念模型的方法。

7.3.1 概念模型

在需求分析阶段所得到的应用需求，应该首先抽象为信息世界的结构，然后才能更好、更准确地用某一数据库管理系统实现这些需求。

概念模型的主要特点是：
（1）能真实、充分地反映现实世界，包括事物和事物之间的联系，能满足用户对数据的处理要求，是现实世界的一个真实模型。
（2）易于理解，可用它和不熟悉计算机的用户交换意见。用户的积极参与，是数据库设计成功的关键。
（3）易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。
（4）易于向关系、网状、层次等各种数据模型转换。

概念模型是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。描述概念模型的有力工具，就是E-R模型。

7.3.2 E-R模型

P.P.S.Chen提出的E-R模型，是用E-R图来描述现实世界的概念模型。第1章1.2.2小节简单介绍了E-R模型涉及的主要概念，包括实体、属性、实体之间的联系等，指出了实体应该区分实体集和实体型，初步讲解了实体之间的联系。下面首先对实体之间的联系做进一步介绍，然后讲解E-R图。

1. 实体之间的联系

在现实世界中，事物内部以及事物之间是有联系的。实体内部的联系通常是指组成实体的各属性之间的联系，实体之间的联系通常是指不同实体型的实体集之间的联系。

(1) 两个实体型之间的联系

两个实体型之间的联系可分为以下三种。

• 一对一联系（$1:1$）：如果对于实体集 $A$ 中的每个实体，实体集 $B$ 中至多有一个（也可以没有）实体与之联系，反之亦然，则称实体集 $A$ 与实体集 $B$ 具有一对一联系，记为 $1:1$ 。
  例如，学校里一个班级只有一个正班长，而一个班长只在一个班中任职，则班级与班长之间具有一对一联系。
• 一对多联系（$1:n$）：如果对于实体集 $A$ 中的每个实体，实体集 $B$ 中有 $n$ 个实体（$n\ge 0$）与之联系，反之，对于实体集 $B$ 中的每个实体，实体集 $A$ 中至多只有一个实体与之联系，则称实体集 $A$ 与实体集 $B$ 有一对多联系，记为 $1:n$ 。
  例如，一个班级中有若干名学生，而每个学生只在一个班级中学习，则班级与学生之间具有一对多联系。
• 多对多联系（$m:n$）：如果对于实体集 $A$ 中的每个实体，实体集 $B$ 中有 $n$ 个实体（$n\ge 0$）与之联系，反之，对于实体集 $B$ 中的每个实体，实体集 $A$ 中也有 $m$ 个实体（$m\ge 0$）与之联系，则称实体集 $A$ 与实体集 $B$ 具有多对多联系，记为 $m:n$ 。
  例如，一门课程同时有若干名学生选修，而一名学生可同时选修多门课程，则课程与学生之间具有多对多联系。

可用图形来表示两个实体型之间的这三类联系，如图所示：

(2) 两个以上的实体型之间的联系

一般地，两个以上的实体型之间，也存在着一对一、一对多、多对多联系。

• 例如，对于课程、教师与参考书三个实体型，如果一门课程可以有若干名教师讲授，使用若干本参考书，而每一门教师只讲授一门课程，每一本参考书只供一门课程使用。则课程与教师、参考书之间的联系是一对多的，如图7.7(a)所示。
• 又如，有三个实体型：供应商、项目、零件，一个供应商可以供给多个项目以多种零件，每个项目可以使用多个供应商供应的零件，每种零件可由不同供应商供给。则供应商、项目、零件三者之间是多对多的联系，如图7.7(b)所示。
  

(3) 单个实体型内的联系

同一个实体集内的各实体之间，也可以存在一对一、一对多、多对多的联系。例如，职工实体型内部具有领导与被领导的联系，即某一职工（干部）“领导”若干名职工，而一个职工仅被另外一个职工直接“领导”，因此这是一对多的联系，如图7.8所示。

一般地，把参与联系的实体型的数目称为联系的度。两个实体型之间的联系度为 $2$ ，也称为二元联系；三个实体型之间的联系度为 $3$ ，称为三元联系；$N$ 个实体型之间的联系度为 $N$ ，称为 $N$ 元联系。

2. E-R图

E-R图提供了表示实体型、属性和联系的方法——实体型用矩形表示，矩形框内写明实体名；属性用椭圆形表示，并用无向边将其与相应的实体型连接起来；联系用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时要在无向边旁标上联系的类型（$1:1,1:n,m:n$）。需要注意的是，如果一个联系具有属性，则这些属性也要用无向边，将其与该联系连接起来。

例如，学生实体具有学号、姓名、性别、出生年份、系、入学时间等属性，用E-R途表示如图7.9所示。

例如图7.7(b)中，如果用“供应量”来描述联系“供应”的属性，表示某供应商供应了多少数量的零件给某个项目，那么这三个实体及其之间联系的E-R图表示，可如图7.10所示。

3. 一个实例（某工厂物资管理的概念模型）

下面用E-R图，表示某个工厂物资管理的概念模型。物资管理涉及以下几个实体：

• 仓库：属性有仓库号、面积、电话号码；
• 零件：属性有零件号、名称、规格、单价、描述；
• 供应商：属性有供应商号、姓名、地址、电话号码、账号；
• 项目：属性有项目号、预算、开工日期；
• 职工：属性有职工号、姓名、年龄、职称
  

这些实体之间的联系如下：
（1）一个仓库可以存放多种零件，一种零件可以存放在多个仓库中，因此仓库和零件具有多对多的联系。用库存量来表示某种零件在某个仓库中的数量；
（2）一个仓库有多个职工当仓库保管员，一个职工只能在一个仓库工作，因此仓库和职工之间是一对多的联系。
（3）职工之间具有领导与被领导的联系，即仓库主任领导若干保管员，因此职工实体型中具有一对多的联系。
（4）供应商、项目、零件三者之间具有多对多的联系，即一个供应商可以供给若干项目多种零件，每个项目可以使用不同供应商供应的零件，每种零件可由不同供应商供给。

下面给出此工厂的物资管理E-R图，如图7.11所示。其中，图7.11(a)为实体属性图，图7.11(b)为实体联系图，图7.11 c)为完整的E-R图。这里把实体的属性单独画出来，只是为了更清晰地表示实体及实体之间的联系。

注意：由于E-R图的图形元素并没有标准化，不同的教材、不同的构建E-R图的工具软件都会有一些差异！

7.3.3 扩展的E-R模型*

E-R方法是抽象和描述现实世界的有力工具。用E-R图表示的概念模型，独立于具体的数据库管理系统所支持的数据模型，是各种数据模型的共同基础，因而比数据模型更一般更抽象、更接近现实世界。E-R模型得到了广泛的应用，人们在基本E-R模型的基础上，进行了某些方面的扩展，使其表达能力更强。

1. ISA联系（继承）

用E-R方法构建一个项目的模型时，经常会遇到某些实体型是某个实体型的子类型。例如，研究生和本科生都是学生的子类型，学生是父类型。这种父类-子类联系称为ISA联系（表示 is a 的语义）。图7.12中研究生 is a 学生、本科生 is a 学生。ISA联系用三角形来表示。

ISA联系一个重要的性质是子类继承了父类的所有属性，当然子类也可以有自己的属性。例如，本科生和研究生是学生实体的子类型，他们具有学生实体的全部属性，研究生子实体型还有“导师姓名”和“研究方向”两个自己的属性。

ISA联系描述了「对一个实体型中实体的一种分类方法」，下面对分类方法做进一步说明。

• 分类属性：根据分类属性的值，把父实体型中的实体，分派到子实体型中。例如图7.12中，在ISA联系符号三角形的右边，加了一个分类属性“学生类别”，它说明了：一个学生是研究生还是本科生、由“学生类别”这个分类属性的值来决定。
  
• 不相交约束与可重叠约束：不相交约束描述「父类中的一个实体不能同时属于多个子类中的实体集」，即一个父类中的实体最多属于一个子类实体集，用ISA联系的三角形符号内加一个叉号 X 来表示。例如，图7.13表明，一个学生不能既是本科生又是研究生。如果父类中的一个实体能同时属于多个子类中的实体集，则称为可重叠约束，子类符号中没有叉号就表示是可重叠的。
  
• 完备性约束：完备性约束描述「父类中的一个实体，是否必须是某一个子类中的实体」，如果是，则叫做完全特化 total specialization ，否则叫做部分特化 partial specialization 。完全特化用父类到子类的双线连接来表示，单线连接则表示部分特化。假设学生只有两类，要么是本科生、要么是研究生，二者必居其一，这就是完全特化的例子，如图7.13所示。

2. 基数约束

基数约束是对实体之间一对一、一对多、多对多联系的细化。参与联系的每个实体型用基数约束来说明，实体型中的任何一个实体，可以在联系中出现的最少次数和最多次数。

约束用一个数对 $\min ..\max$ 表示，$0\le \min \le \max$ 。例如，$0..1$ 、$1..3$ 、$1..\ast$（$\ast$ 表示无穷大）。$\min =1$ 的约束叫做强制参与约束，即被施加基数约束的实体型中的每个实体都要参与联系；$\min =0$ 的约束叫做非强制参与约束，被施加基数约束的实体型中的实体，可以出现在联系中，也可以不出现在联系中。

本节中，二元联系的基数约束标注在「远离施加约束的实体型」且「靠近参与联系的另外一个实体型」的位置。采用这种方式，一是可以方便地读出约束的类型（一对一、一对多、多对多），如班级和学生是一对多的联系；二是一些E-R辅助绘图工具也是采用这样的表现形式。例如：

• 图7.14(a)学生和学生证的联系中，一个学生必须拥有一本学生证，一本学生证只能属于一个学生，因此都是 $1..1$ 。
• 在图7.14(b)中学生和课程是多对多的联系。假设学生实体型的基数约束是 $20..30$ ，表示每个学生必须选修 $20\sim 30$ 门课程；课程的一个合理的基数约束是 $0..\ast$ ，即一门课程一般会被很多学生选修，但是有的课程可能还没有任何一位学生选修，比如新开的课程。
• 在图7.14 c)班级和学生的联系中，一个学生必须参加一个班级，并只能参加一个班级，因此是 $1..1$ ，标在参与联系的班级实体一边。一个班最少 $30$ 个学生，最多 $40$ 个学生，因此是 $30..40$ ，标在参与联系的学生实体一边。
  

3. Part-of联系（组成/合成、聚合）

Part-of 联系即部分联系，它表明某个实体型是另外一个实体型的一部分。例如汽车和轮子两个实体型，轮子实体是汽车实体的一部分，即 Part-of 汽车实体。Part-of 联系可以分为两种情况：

• 一种是整体实体如果被破坏，部分实体仍然可以独立存在，称为非独占的 Part-of 联系。例如，汽车实体型和轮子实体型之间的联系，一辆汽车车体被损坏了，但是轮子还存在，可以拆下来独立存在，也可以再安装到其他汽车上。
  非独占的 Part-of 联系可以通过基数约束来表达。在图7.15中，汽车的基数约束是 $4..4$ ，即一辆汽车要有 $4$ 个轮子，轮子的基数约束是 $0..1$ ，这样的约束表示非强制参与联系。例如，一个轮子可以安装到一辆汽车上，也可以没有被安装到任何车辆上、独立存在，即一个轮子可以参与一个联系，也可以不参与。因此，在E-R图中用非强制参与联系表示非独占 Part-of 联系。
  
• 还有一种 Part-of 联系是独占联系。即整体实体如果被破坏，部分实体就不能存在。在E-R图中用弱实体类型和识别联系来表示独占联系。如果一个实体型的存在依赖于其他实体型的存在，则这个实体型叫做弱实体型，否则叫做强实体型。一般来说，如果不能从一个实体型的属性中，找出可以作为键的属性，则这个实体型是弱实体型。在E-R图中用双矩形表示弱实体型，用双菱形表示识别联系。
  例如，图7.16所示为某用户从银行贷了一笔款用于购房，这笔款项一次贷出，分期归还。还款就是一个弱实体，它只有还款序号（第一笔还款的序号为 $1$ ，以此类推）、日期和金额三个属性，这些属性的任何组合都不能作为还款的键。还款的存在必须依赖于贷款实体，没有贷款自然就没有还款。
  
  再比如，房间和楼房的联系。如图7.17所示，每座楼都有唯一的编号或者名称，每个房间都有一个编号，如果房间号不包含楼号，则房间号不能作为键，因为不同的楼房中可能有编号相同的房间，所以房间是一个弱实体。例如，信息楼 $500$ 号房间及明德楼 $500$ 号房间，房间号都没有包含楼号，所以该房间号不能作为键。
  

7.3.4 UML

表示E-R图的方法有若干种，使用统一建模语言UML是其中之一。UML是对象管理组织 Object Management Group, OMG 的一个标准，它不是专门针对数据建模的，而是为软件开发的所有阶段，提供模型化和可视化支持的规范语言。从需求规格描述，到系统完成后的测试和维护，都可以用到UML。UML也可用于数据建模、业务建模、对象建模、组件建模等，它提供了多种类型的模型描述图 diagram ，借助这些图，可以使计算机应用系统开发中的应用程序更易理解。

关于UML的概念、内容和使用方法等，可以专门开设一门课程来讲解，这里仅简单介绍如何用UML中的类图来建立概念模型（即E-R图）。

UML中的类 class 大致对应E-R图中的实体。由于UML中的类具有面向对象的特征，它不仅描述对象的属性，还包括对象的方法 method ——方法是面向对象技术中的重要概念，在对象关系数据库中支持方法，但E-R模型和关系模型都不提供方法，因此本节在用UML表示E-R图时，省略了对象方法的说明。

• 实体型：用类表示，矩形框中实体名放在上部，下面列出属性名。
• 实体的键：在类图中，在属性后面加 PK (primary key) 来表示键属性。
• 联系：用类图之间的关联来表示。早期的UML只能表示二元关联，关联的两个类用无向边连接，在连线上面写关联的名称。例如，学生、课程、它们之间的联系以及基数约束的E-R图，用UML表示如图7.18所示。现在UML也扩展了非二元关联，并用菱形框表示关联，框内写联系名，用无向边分别与关联的类连接起来。
  
• 基数约束：UML中关联类之间基数约束的概念、表示和E-R图中的基数约束类似。用一个数对 $\min ..\max$ 表示类中的任何一个对象、可在关联中出现的最少次数和最多次数。例如，$0..1$ 、$1..3$ 、$1..\ast$ 。基数约束的标注方法和7.3.3中一样，在图7.18中学生和课程的基数约束标注，表示每个学生必须选修 $20\sim 30$ 门课程；一门课程一般会被很多同学选修，也可能没有同学选修，因此为 $0..\ast$ 。
• UML中的子类：面向对象技术支持超类-子类概念，子类可以继承超类的属性，也可以有自己的属性。这些概念和E-R图的父类-子类联系，或ISA联系是一致的。因此很容易用UML表示E-R图的父类-子类联系。

注意，如果计算机应用系统的设计和开发的全过程，都是使用UML规范，开发人员自然可以采用UML对数据建模。如果计算机应用系统的设计和开发不是使用UML，则建议数据库设计采用E-R模型来表示概念模型。

7.3.5 概念结构设计

前面讲解了E-R图的基本概念，本节介绍在设计E-R图的过程中，如何确定实体与属性、在集成E-R图时如何解决冲突等关键技术。

概念结构设计的第一步，就是对需求分析阶段收集到的数据进行分类、组织，确定实体、实体的属性、实体之间的联系类型，形成E-R图。首先，「如何确定实体和属性」这个看似简单的问题，常常会困扰设计人员，因为实体与属性之间并没有形式上可以截然划分的界限。

1. 实体与属性的划分原则

事实上，在现实世界中，具体的应用环境常常对实体和属性，已经做了自然的大体划分。在数据字典中，数据结构、数据流和数据存储都是若干属性有意义的聚合，这就已经体现了这种划分。可以先从这些内容出发定义E-R图，然后再进行必要的调整。

在调整中遵循的一条原则是：为了简化E-R图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待。那么，符合什么条件的事物可以作为属性对待呢？给出两条准则，凡满足如下两条准则的事务，一般均可作为属性对待：
（1）作为属性，不能再具有需要描述的性质，即属性必须是不可分的数据项，不能包含其他属性。
（2）属性不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。

例如，职工是一个实体，职工号、姓名、年龄是职工的属性，职称如果没有与工资、岗位津贴、福利挂钩，换句话说，没有需要进一步描述的性质，则可根据准则(1)作为职工实体的属性；但如果不同的职称有不同的工资、岗位津贴和不同的附加福利，则职称作为一个实体看待就更恰当，如图7.19所示：

又如，在医院中一个病人只能住一间病房，病房号可作为病人实体的一个属性；但如果病房还要与医生实体发生联系，即一个医生负责几个病房的病人的医疗工作，则根据准则(2)，病房应作为一个实体，如图7.20所示：

再如，如果一种货物只存放在一个仓库中，那么就可以把存放货物的仓库的仓库号，作为描述货物存放地点的属性。但如果一种货物可以存放在多个仓库中，或者仓库本身又用面积做属性（具有需要描述的性质），或者仓库与职工发生管理上的联系（与其他实体具有联系），那么就应把仓库作为一个实体，如图7.21所示。

【例7.1】销售管理子系统E-R图的设计。
某工厂开发管理信息系统，经过可行性分析，详细调查确定了该系统由物资管理、销售管理、劳动人事管理等子系统组成。为每个子系统组成了开发小组。

销售管理子系统开发小组的成员，经过调查研究、信息流程分析和数据收集，明确了该子系统的主要功能是：处理顾客和销售员送来的订单；工厂是根据订货安排生产的；交出货物的同时开出发票；收到顾客付款后，根据发票存根和信贷情况进行应收款处理。

通过需求分析，知道整个系统功能围绕“订单”和“应收款项”的处理来实现。数据结构中订单、顾客、顾客应收账目用得最多，是许多子功能、数据流共享的数据。因此，先设计该E-R图的草图（如图7.22所示）。

然后参照需求分析和数据字典中的详尽描述，遵循前面给出的两个准则，进行了如下的一些调整：
（1）每张订单由订单号、若干头信息和订单细节组成。订单细节又有订货的零件号、数量等来描述。按照第二条准则，订单细节就不能作为订单的属性处理，而应上升为实体。一张订单可以订做若干产品，所以订单与订单细节两个实体之间是 $1:n$ 的联系。
（2）原订单与产品的联系，实际上是订单细节与产品的联系。每条订货细节对应一个产品描述，订单处理时从中获得当前单价、产品重量等信息。
（3）工厂对大宗订货给予优惠。每种产品都规定了不同订货数量的折扣，应增加一个“折扣规则”实体存放这些信息，而不应把它们都放在产品实体中。

对每个实体定义的属性如下。最后得到销售管理子系统的E-R图，如图7.23所示，为了节省篇幅，这里省略了实体属性图：

• 顾客：（顾客号，顾客名，地址，电话，信贷状况，账目余额）
• 订单：（订单号，顾客号，订货项数，订货日期，交货日期，工种号，生产地点）
• 订单细则：（订单号，细则号，零件号，订货数，金额）
• 应收账款：（顾客号，订单号，发票号，应收金额，支付日期，支付金额，当前余额，货款限额）
• 产品：（产品号，产品名，单价，重量）
• 折扣规则：（产品号，订货量，折扣）
  

2. E-R图的集成

在开发一个大型信息系统时，最经常采用的策略是自顶向下地进行需求分析，然后再自底向上地设计概念结构，即首先设计各子系统的分E-R图，然后将它们集成起来，得到全局E-R图。E-R图的集成一般需要分两步走，如图7.24所示。

• 合并。解决各分E-R图之间的冲突，将分E-R图合并起来，生成初步E-R图。
• 修改和重构。消除不必要的冗余，生成基本E-R图。
  

(1) 合并E-R图，生成初步E-R图

各个局部应用所面向的问题不同，且通常是由不同的设计人员进行局部视图设计，这就导致了各个子系统的E-R图之间，必定会存在许多不一致的地方，称之为冲突。因此，合并这些E-R图时，并不能简单地将各个E-R图画到一起，而是必须着力消除各个E-R图中的不一致，以形成一个能为全系统中、所有用户共同理解和接受的、统一的概念模型。合理消除各E-R图的冲突，是合并E-R图的主要工作与关键所在。

各子系统的E-R图之间的冲突主要有三类：属性冲突、命名冲突和结构冲突。
① 属性冲突。属性冲突主要包括以下两类冲突：

• 属性域冲突，即属性值的类型、取值范围或取值集合不同。例如零件号，有的部门把它定义为整数，有的部门把它定义为字符型，不同部门对零件号的编码也不同。又如年龄，某些部门以出生日期形式表示职工的年龄，而另一些部门用整数表示职工的年龄。
• 属性取值单位冲突。例如，零件的重量有的以公斤为单位，有的以斤为单位，有的以克为单位。

属性冲突理论上好解决，但实际上需要各部门讨论协商，解决起来并非易事。

② 命名冲突。命名冲突主要包括以下两类冲突：

• 同名异义，即不同意义的对象，在不同的局部应用中，具有相同的名字。
• 异名同义（一义多名），即同一意义的对象，在不同的局部应用中，具有不同的名字。如对科研项目，财务科称为项目，科研处称为课题，生成管理处称为工程。

命名冲突可能发生在实体、联系一级上，也可能发生在属性一级上。其中属性的命名冲突更为常见。处理命名冲突通常也像处理属性冲突一样，通过讨论、协商等行政手段，加以解决。

③ 结构冲突。结构冲突主要包括以下三类冲突：

• 同一对象在不同应用中，具有不同的抽象。例如，职工在某一局部应用中被当作实体，而在另一局部应用中则被当作属性。解决方法通常是，把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。但变换时，仍要遵循7.3.5小节中讲述的两个准则。
• 同一实体在不同子系统的E-R图中，所包含的属性个数和属性排列次序不完全相同。这是很常见的一类冲突，原因是不同的局部应用，关心的是该实体的不同侧面。解决方法是，使该实体的属性取各子系统的E-R图中属性的并集，再适当调整属性的次序。
• 实体间的联系在不同子系统的E-R图中，为不同的类型。如实体 $E1$ 与 $E2$ 在一个E-R图中是多对多联系，在另一个E-R图中是一对多联系；又如在一个E-R图中 $E1$ 与 $E_2$ 发生联系，而在另一个E-R图中 $E1,E2,E3$ 三者之间有联系。解决方法是，根据应用的语义，对实体联系的类型进行综合或调整。
  例如，图7.25(a)中零件与产品之间存在多对多的联系“构成”，图7.25(b)中产品、零件、供应商三者之间还存在多对多的联系“供应”，这两个联系互相不能包含，则在合并两个E-R图时，就应把它们综合起来，见图7.25的c图：
  

(2) 消除不必要的冗余，设计基本E-R图

在初步E-R图中可能存在一些冗余的数据和实体间冗余的联系。所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难，应当予以消除。消除了冗余后的初步E-R图称为基本E-R图。

消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中「关于数据项之间逻辑关系的说明」来消除冗余。如图7.26中 $Q_3=Q_1\times Q_2,Q_4=\sum Q_5$ ，所以 $Q_3$ 和 $Q_4$ 是冗余数据，可以消去；并且由于 $Q_3$ 消去，产品与材料间冗余的 $m:n$ 联系“使用”也应消去。

但并不是所有的冗余联系与冗余数据，都必须加以消除。有时为了提高效率，不得不以冗余信息为代价。因此，在设计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。如果人为地保留了一些冗余数据，则应把数据字典中「数据关联的说明」作为完整性约束条件。例如，若物种部门经常要查询各种材料的库存量，如果每次都要查询每个仓库中此种材料的库存，再对它们求和，查询效率就太低了。所以应保留 $Q_4$ ，同时把 $Q_4=\sum Q_5$ 定义为 $Q_4$ 的完整性约束条件，每当 $Q_5$ 修改后，就触发该完整性检查，对 $Q_4$ 作相应的修改。

除分析方法外，还可用规范化理论来消除冗余。在规范化理论中，函数依赖的概念提供了消除冗余联系的形式化工具，具体方法如下：

1. 确定分E-R图实体之间的数据依赖。实体之间一对一、一对多、多对多的联系，可用实体键之间的函数依赖来表示，于是有函数依赖集 $F_L$ 。如图7.27中：部门和职工之间一对多的联系可表示为职工号 $\to$ 部门号；职工和产品之间多对多的联系，可表示为(职工号，产品号) $\to$ 工作天数等。
   
2. 求 $F_L$ 的最小覆盖 $G_L$ ，差集为 $D=F_L-G_L$ 。再逐一考察 $D$ 中的函数依赖，确定是否是冗余的联系，若是就把它去掉。由于规范化理论受到泛关系假设的限制，应注意下面两个问题：
   • 冗余的联系一定在 $D$ 中，而 $D$ 中的联系不一定是冗余的。
   • 当实体之间存在多种联系时，要将实体之间的联系，在形式上就加以区分。如图7.28中部门和职工之间，另一个一对一的联系就要表示为：负责人.职工号 $\to$ 部门号，部门号 $\to$ 负责人.职工号。

【例7.2】某工厂管理信息系统的视图集成。图7.11、图7.23、图7.27分别为该厂物资、销售、劳动人事管理的分E-R图。图7.28为该系统的基本E-R图，这里基本E-R图中各实体的属性，因篇幅有限从略。集成过程中，解决了以下问题：

• 异名同义，项目和产品含义相同。某个项目实质上是指某个产品的生产，因此统一用产品作实体名。
• 库存管理中，职工与仓库的工作关系，已包含在劳动人事管理部门与职工之间的联系中，所以可以取消。职工之间领导与被领导的关系，可由部门与职工（经理）之间的领导关系、部门与部门之间的从属关系两者导出，所以也可以取消。
  

最后

以上就是乐观胡萝卜为你收集整理的【数据库系统】第二部分 设计与应用开发(7) 数据库设计(3) 概念结构设计7.3.1 概念模型7.3.2 E-R模型7.3.3 扩展的E-R模型*7.3.4 UML7.3.5 概念结构设计的全部内容，希望文章能够帮你解决【数据库系统】第二部分 设计与应用开发(7) 数据库设计(3) 概念结构设计7.3.1 概念模型7.3.2 E-R模型7.3.3 扩展的E-R模型*7.3.4 UML7.3.5 概念结构设计所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。