【从零开始学习计算机科学】数据库系统（三）关系数据库设计

关系数据库设计

数据模型

数据模型是对现实世界数据特征的模拟和抽象，用来描述数据是如何组织、存储和操作的。数据模型对应不同的应用层次分成三种类型：分别是概念模型，逻辑模型和物理模型。

数据模型是严格定义的一组概念的集合，精确地描述了系统的静态特性、动态特性和完整性约束条件。

数据模型由三部分组成：

数据结构。描述系统的静态特性。数据结构的类型来命名数据模型。

数据操作。描述系统的动态特性，其是对数据库中各种对象的实例允许执行的操作的集合

完整性约束。其是一组完整性规则的集合。完整性规则表述为给定的数据模型中数据及其联系所具有的制约和依存规则，其用以限定符合数据模型的数据库状态以及状态的变化，以保证数据的正确、有效和相容。数据模型对完整性约束条件的定义为反映和规定必须遵守的基本的通用的完整性约束条件。提供定义完整性约束条件的机制，以反映具体应用所涉及的数据必须遵守的特定的语义约束条件。因此，我们可以总结出，完整性约束使用一些规则，规范数据的操作，来保证数据的正确、有效和相容。

概念模型（用户观点对数据和信息建模）

信息世界的基本概念：

实体（Entity）。客观存在并可相互区别的事物称为实体。可以是具体的人、事、物或抽象的概念。

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

码（Key）。唯一标识实体的属性集称为码。

实体型（Entity Type）。用实体名及其属性名集合来抽象和刻画同类实体称为实体型。

实体集（Entity Set）。同一类型实体的集合称为实体集。

联系（Relationship）。联系包含以下两个方面：实体内部的联系：组成实体的各属性之间的联系。实体之间的联系：通常是指不同实体集之间的联系。实体之间的联系有一对一（1:1）、一对多（1:n）和多对多（m:n）等多种类型

逻辑模型（计算机系统的观点对数据和信息的建模）}

逻辑模型有以下形式：

层次模型。

有向树结构。实体之间用指针表示关系。

网状结构。DBTG实体一个多对多的联系,必须通过转换两个一对多的联系。

关系模型。数据结构用二维表，实体以及实体之间的联系都用二维表表示。

关系模型

关系模型（应用数学方法处理数据）（包含数据结构，数据操作，完整约束条件）其使用关系数据结构进行建模，并采纳以下定义：每一个元素构成的$D_1(d_1,d_2)$元组；每个值$d_1$成为分量；每个关系表示一张二维表。每一行表示原则，每一列表示一个域。

数据库设计概述

数据库设计就是根据业务系统的具体需求，结合我们所选用的数据库，建立好表结构及表与表之间的管理关系，为这个业务系统构造出最优秀的数据存储模型的过程。使之能有效的对应用的数据进行存储，并高效的对已经存储的数据进行访问。

数据库设计是数据库系统中的重要组成部分。一个良好的数据库可以给系统带来清晰的数据统计与数据的详细分析，给系统带来方便直观的数据。不良的数据库设计，必然会造成很多问题，轻则增减字段，重则系统无法运行。

为什么要强调先设计再创建数据库和表？原因很简单，我们将数据库比作建筑物，如果盖一间茅屋或一间简易平房，毫无疑问没有人会花钱请人设计房屋图样。但是，如果是房地产开发商要开发一个新楼盘，修建多幢楼的居住小区，施工前，他肯定会先请人设计施工图样。

同样的道理，在实际项目开发中，如果系统的数据存储量较大，设计的表较多，表与表之间的关系比较复杂，就必须先规范的设计数据库，然后再创建数据库、表等工作。

无论是创建动态网站，还是创建桌面窗口应用程序，数据库设计的重要性都不言而喻。只有优良的数据库设计，才能提高系统的性能，提供更好的服务。糟糕的数据库设计会出现很多问题，影响我们的工作效率，服务效率和用户的使用效率。

糟糕的数据库设计表现在以下几个方面：访问数据效率低下、存在大量的数据冗余，浪费存储空间、更新和检索数据时会出现许多问题。

良好的数据库设计表现在以下几方面：访问效率高、减少数据冗余，节省存储空间，便于进一步扩展、可以使应用程序的开发变得更容易。

数据库中的表设计也是决定数据库系统效率的重要因素。表设计就是对数据库中的数据实体及数据实体之间的关系，进行规划和结构化的过程。

按照规范设计的方法，考虑数据库及其应用系统开发全过程，将数据库设计分为以下 6 个阶段：

1，需求分析。

需求分析是数据库设计的第一步，是最困难、最耗费时间的一步，也是整个设计过程的基础。

本阶段的主要任务是对现实世界中要处理的对象（公司、部门及企业，也可以理解成客户）进行详细调查，然后通过分析，逐步明确客户/用户对系统的需求，包括数据需求和业务处理需求。
需求分析是否做的充分和准确，直接决定了在其上构建数据库大厦的速度与质量。需求分析做的不好，会导致整个数据库设计返工重做。

2，概要设计（概念设计阶段）。

概要设计是数据库设计的关键，通过综合、归纳与抽象用户需求，形成一个具体 DBMS 的概念模型，也就是绘制数据库的 E-R 图。

E-R 图主要用于在项目团队内部，设计人员和客户之间进行沟通，确认需求信息的正确性和完整性。

3. 逻辑结构设计。

将 E-R 图转换为多张表，进行逻辑设计，确认各表的主外键，并应用数据库设计的三大范式进行审核，对其优化。

在这阶段，E-R 图非常重要。大家要学会根据各个实体定义的属性来画出总体的 E-R 图。

4. 物理设计阶段。

经项目组开会讨论确定 E-R 图后，根据项目的技术实现，团队开发能力及项目的成本预算，选择具体的数据库（如 MySQL 或 Oracle 等）进行物理实现。

5. 数据库实施阶段。

运用 DBMS 提供的数据语言（例如 SQL）、工具及宿主语言（例如 Java），根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。

6. 数据库运行和维护阶段。

数据库应用系统经过试运行后即可投入正式运行。在运行过程中必须不断地对其进行评价、调整与修改。

总之设计一个完善的数据库应用系统是不可能一蹴而就的，它往往是上述 6 个阶段的不断反复。

需求分析

需求分析是数据库设计的第一步，也是最困难、最耗时间的一步。需求分析的任务是准确了解并分析用户对系统的需要和要求，弄清系统要达到的目标和实现的功能。需求分析是否做得充分与准确，决定着在其上构建数据库大厦的速度与质量。如果需求分析做不好，会影响整个系统的性能，甚至会导致整个数据库设计返工。

数据库应用系统的需求分析包括数据需求分析、功能需求分析(数据处理需求分析、业务规则需求分析)、性能需求分析(数据操作响应时间或数据访问响应时间、系统吞吐量、允许并发访问的最大用户数、每秒TPS代价值)、其他需求分析(存储需求分析、安全性需求分析、备份和恢复需求分析)。

数据处理需求分析：从对数据组织与存储的设计角度，辨识应用领域所管理的各类数据项和数据结构，与数据处理需求分析结果一 起，组成数据字典，形成数据规范说明书”。

功能需求分析：功能需求分析主要针对DBAS应具有的功能进行分析，是DBAS需求分析的核心环节，总体上可分为数据处理需求分析与业务规则需求分析。数据处理需求分析从数据访问和处理的角度,明确对各数据项所需要进行的数据访问操作。在系统规划与分析阶段，DBAS开发者已经明确了各类用户视图。因此数据处理需求分析阶段可以从这些视图出发，

性能需求分析：性能需求则描述了系统应当做到什么程度，分析DBAS应具有的性能指标。

其他需求分析包括：存储需求、安全性需求等。

存储需求分析：存储需求分析是指估计DBAS系统需要的数据存储量，如DB所存储的数据总量。

安全需求分析：主要用于数据库安全设计，避免被非法使用和攻击。

基本步骤主要为设计者的中心工作是弄清并综合各个用户的应用需求。

主要任务是详细调查现实世界要处理的对象（组织、部门、企业等）；充分了解原系统（手工系统或计算机系统）的概况和发展前景；明确用户的各种需求；收集支持系统目标的基础数据及其处理方法；确定新系统的功能和边界。

常用的数据建模方法

DFD方法

数据流图(Data Flow Diagram,简称DFD)是便于用户理解系统数据流程的图形表示。DFD建模方法的核心是数据流，它能精确地在逻辑上描述系统的功能、输入、输出和数据存储等，从而摆脱了其物理内容。数据流图是系统逻辑模型的重要组成部分。

DFD的主要组成包括外部实体(外部项)、处理过程、数据存储和数据流。外部实体指系统之外又和系统有联系的人或者事物，说明了数据的外部来源和去处。处理指对数据逻辑处理，也就是数据变换，它用来改变数据值。数据流是指处理功能的输入输出数据存储表示数据保存的地方，它用来存储数据。

在DFD建模方法中，数据流用箭头表示，处理用矩形框表示，数据存储用圆角矩形框表示，外部项用圆角框或
者平行四边形框表示。

数据流程图表达了数据和处理过程之间的关系。在结构化分析方法中，处理过程的处理逻辑常常用判定表或判定树来描述。

DFD特性有

抽象性：在DFD中具体的组织机构、工作场所、物质流等都已经去掉，只剩下信息和数据存储、流动、使用以及加工的情
况。所以描述的是抽象出来的数据。

概括性：它把系统对各种业务的处理过程联系起来考虑，形成一个总体，可反映出数据流之间的概括情况。

IDEF方法

IDEF方法是70年代提出的结构化分析方法基础上发展起来的。其中，IDEF方法又分为以下几种：

IDEF0：描述系统的功能活动及其联系。

IDEF1：描述系统信息及其联系，建立信息模型作为数据库设计的依据。

IDEF2：用于系统模拟，建立动态模型。

UML方法

UML-Unified Modeling Language 统一建模语言，又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言。UML的定义包括UML语义和UML表示法两个元素。

UML是在开发阶段，说明、可视化、构建和书写一个面向对象软件密集系统的制品的开放方法。最佳的应用是工程实践，对大规模，复杂系统进行建模方面，特别是在软件架构层次，已经被验证有效。统一建模语言（UML）是一种模型化语言。模型大多以图表的方式表现出来。一份典型的建模图表通常包含几个块或框，连接线和作为模型附加信息之用的文本。这些虽简单却非常重要，在UML规则中相互联系和扩展。

数据字典

数据字典是各类数据描述的集合，它是进行详细的数据收集和数据分析后所获得的主要成果。数据字典在数据库设计中占有很重要的地位。数据字典通常包括以下5个部分。

数据项

数据项是不可再分的数据单位。它的描述为：数据项 = {数据项名，含义说明，别名，类型，长度，取值范围，与其他数据项的逻辑关系}。其中，“取值范围”和“与其他数据项的逻辑关系”两项定义了数据的完整性约束条件，它们是设计数据完整性检验功能的依据。

数据结构

数据结构的描述为：数据结构 = {数据结构名，含义说明，组成，{数据项或数据结构}}。
数据结构反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干数据项和数据结构混合组成。

数据流

数据流是数据结构在系统内传输的路径。数据流的描述通常为：
数据流 = {数据流名，说明，流出过程，流入过程，组成：{数据结构}，平均流量，高峰期流量}。
其中，“流出过程”说明该数据流来自哪个过程；“流入过程”说明该数据流将到哪个过程去；“平均流量”是指在单位时间（每天、每周、每月等）里传输的次数；“高峰期流量”则是指在高峰时期的数据流量。

数据存储

数据存储是数据及其结构停留或保存的地方，也是数据流的来源和去向之一。数据存储可以是手工文档、手工凭单或计算机文档。数据存储的描述通常为：数据存储 = {数据存储名，说明，编号，输入的数据流，输出的数据流，组成：{数据结构}，数据量，存取频度，存取方式}。
其中：“数据量”说明每次存取多少数据；“存取频度”指每小时或每天或每周存取几次、每次存取多少数据等信息；“存取方式”指是批处理还是联机处理，是检索还是更新，是顺序检索还是随机检索等；“输入的数据流”要指出其数据的来源处；“输出的数据流”要指出其数据去向处。

处理过程

处理过程的具体处理逻辑一般用判定表或判定树来描述。数据字典中只需要描述处理过程的说明性信息，通常包括以下内容：
处理过程 = {处理过程名，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}}。
其中，“简要说明”中主要说明该处理过程用来做什么（不是怎么做）及处理频度要求，如单位时间里处理多少事务、多少数据量、响应时间要求等。

数据字典是关于数据库中数据的描述，即对元数据的描述。数据字典是在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善的。
需求和分析阶段收集到的基础数据用数据字典和一组数据流程图（Data Flow Diagram , 简称DFD）表达，它们是下一步进行概念设计的基础。数据字典能够对系统数据的各个层次和各个方面进行精确和详尽的描述，并且把数据和处理有机地结合起来，可以使概念结构的设计变得相对容易。

数据库概念结构的设计

概念结构设计是整个数据库设计的关键。在概念结构的设计过程中，设计者要对用户需求进行综合、归纳和抽象，形成一个独立于具体计算机和DBMS的概念模型。

基本步骤为设计者要将应用需求转换为与计算机硬件无关的、与各个数据库管理系统产品无关的概念模型（即E-R图）；

概念结构独立于数据库逻辑结构和支持数据库的DBMS，其主要特点如下。

概念模型是现实世界的一个真实模型：概念模型应能真实、充分地反映现实世界，能满足用户对数据的处理要求。

概念模型应当易于理解：概念模型只有被用户理解后，才可以与设计者交换意见，参与数据库的设计。

概念模型应当易于更改：由于现实世界（应用环境和应用要求）会发生变化，这就需要改变概念模型，易于更改的概念模型有利于修改和扩充。

概念模型应易于向数据模型转换：概念模型最终要转换为数据模型。设计概念模型时应当注意，使其有利于向特定的数据模型转换。

概念结构的设计可分为两步，第一步是抽象数据，并设计局部视图；第二步是集成局部视图，得到全局的概念结构。

数据抽象与局部视图设计

概念结构是对现实世界的一种抽象。所谓抽象是对实际的人、物、事和概念进行人为处理，抽取所关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述，这些概念组成了某种模型。

三种数据抽象方法

1，分类 (Classification)。定义某一类概念作为现实世界中一组对象的类型，这些对象具有某些共同的特性和行为。分类抽象了对象值和型之间的“成员”的语义。在E-R模型中，实体集就是这种抽象。

2，聚集 (Aggregation)。定义某一类型的组成部分，它抽象了对象内部类型和对象内部“组成部分”的语义。若干属性的聚集组成了实体型。

3，概括 (Generalization)。定义了类型之间的一种子集联系，它抽象了类型之间的“所属”的语义。例如，学生是一个实体型，本科生、研究生也是实体型。本科生、研究生均是学生的子集。把学生超类( Superclass )，本科生、研究生称为学生的子类( Subclass)。概括的一个重要性质是继承性。继承性指子类继承超类中定义的所有抽象。

E-R图

概念结构设计是利用抽象机制对需求分析阶段收集到的数据进行分类、组织（聚集），形成实体集、属性和码，确定实体集之间的联系类型（一对一、一对多或多对多的联系），进而设计分E-R图。

ER图分为实体、属性、关系三个核心部分。实体是长方形体现，而属性则是椭圆形，关系为菱形。

ER图的实体（entity）即数据模型中的数据对象，例如人、学生、音乐都可以作为一个数据对象，用长方体来表示，每个实体都有自己的实体成员（entity member）或者说实体对象（entity instance），例如学生实体里包括张三、李四等，实体成员（entity member）/实体实例（entity instance） 不需要出现在ER图中。

ER图的属性（attribute）即数据对象所具有的属性，例如学生具有姓名、学号、年级等属性，用椭圆形表示，属性分为唯一属性（ unique attribute）和非唯一属性，唯一属性指的是唯一可用来标识该实体实例或者成员的属性，用下划线表示，一般来讲实体都至少有一个唯一属性。

ER图的关系（relationship）用来表现数据对象与数据对象之间的联系，例如学生的实体和成绩表的实体之间有一定的联系，每个学生都有自己的成绩表，这就是一种关系，关系用菱形来表示。

ER图中关联关系有三种：

1对1（1:1）：1对1关系是指对于实体集A与实体集B，A中的每一个实体至多与B中一个实体有关系；反之，在实体集B中的每个实体至多与实体集A中一个实体有关系。

1对多（1:N）：1对多关系是指实体集A与实体集B中至少有N(N>0)个实体有关系；并且实体集B中每一个实体至多与实体集A中一个实体有关系。

多对多（M:N）：多对多关系是指实体集A中的每一个实体与实体集B中至少有M(M>0)个实体有关系，并且实体集B中的每一个实体与实体集A中的至少N（N>0）个实体有关系。

ER的实体还会细分为弱实体和复合实体：

弱实体：一个实体必须依赖于另一个实体存在，那么前者是弱实体，后者是强实体，弱实体必须依赖强实体存在，例如上图的学生实体和成绩单实体，成绩单依赖于学生实体而存在，因此学生是强实体，而成绩单是弱实体。

弱实体和强实体的联系必然只有1：N或者1：1，这是由于弱实体完全依赖于强实体，强实体不存在，那么弱实体就不存在，所以弱实体是完全参与联系的，因此弱实体与联系之间的联系也是用的双线菱形。

复合实体：复合实体也称联合实体或桥接实体，常常用于实现两个或多个实体间的M：N联系，它由每个关联实体的主玛组成，用长方体内加一个菱形来表示。

下图就是一个典型的复合实体，因为只是举例，相对粗糙，用户和商品两个实体是M：N的关系，中间又订单这个实体联系，因此订单这个实体是一个复合实体，同时如果用户 实体不存在，就没有订单实体的存在，因此对于用户实体来讲订单是弱实体，同理商品实体如果不存在，同样不存在订单实体，因此对商品实体而言订单是弱实体，具体如图：

er图的属性还细分为复合属性、多值属性和派生属性、可选属性，同时还有用来表示联系的属性，称为联系属性。

复合属性(composite attribute)：复合属性是指具有多个属性的组合，例如名字属性，它可以包含姓氏属性和名字属性，如下图：

复合属性也有唯一属性，例如学生的所在班级属性，由于多个年级都有班级，所以单单班级属性是不唯一的，但是和年级组成的复合属性后则可以匹配成唯一属性。

多值属性（multivalued attribute）：一个实体的某个属性可以有多个不同的取值，例如一本书的分类属性，这本书有多个分类，例如科学、医学等，这个分类就是多值属性， 用双线椭圆表示。

派生属性(derivers attribute)：是非永久性存于数据库的属性。派生属性的值可以从别的属性值或其他数据（如当前日期）派生出来，用虚线椭圆表示，如下图。

其中的小组人数就是典型的派生属性，随着学生实例的参加的兴趣小组变化，小组人数属性也会变化，一般来讲派生属性不存在于数据库中，而是通过相应的公式进行计算得到，如果要放到数据库中，那么隔一段时间就要进行更新，否则会出现数据错误。

可选属性(optional attribute)：并不是所有的属性都必须有值，有些属性的可以没有值，这就是可选属性，在椭圆的文字后用（O）来表示，如下图的地址就是一个可选属性。

联系属性：联系属于用户表示多个实体之间联系所具有的属性，一般来讲M:N的两个实体的联系具有联系属性，在1:1和1：M的实体联系中联系属性并不必要。

设计分E-R图的具体做法

1，选择局部应用。选择局部应用是根据系统的具体情况，在多层的数据流程图中选择一个适当层次的数据流程图，作为设计分E-R图的出发点，并让数据流程图中的每一部分都对应一个局部应用。选择好局部应用之后，就可以对每个局部应用逐一设计分E-R图了。

2，设计分E-R图。在设计分E-R图前，局部应用的数据流程图应已经设计好，局部应用所涉及的数据应当也已经收集在相应的数据字典中了。在设计分E-R图时，要根据局部应用的数据流程图中标定的实体集、属性和码，并结合数据字典中的相关描述内容，确定E-R图中的实体、实体之间的联系。

视图

各子系统的局部E-R图设计好以后，下一步就是要将所有的局部E-R图综合成一个系统的总E-R图。一般说来，视图集成可以有两种方式：多个局部E-R图一次集成；逐步集成，即用累加的方式一次集成两个局部E-R图。第一种方法比较复杂，做起来难度较大。第二种方法每次只集成两个局部E-R图，可以降低复杂度。

每次集成局部E-R图时都需要分两步走：

1，合并。解决各局部E-R图之间的冲突，将各局部E-R图合并起来生成初步E-R图。

2，修改和重构。消除不必要的冗余，生成基本E-R图。

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

局部E-R图的冲突

属性冲突

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

属性取值单位冲突。例如，零件的重量有的以公斤为单位，有的以斤为单位，有的以克为单位。

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

命名冲突

同名异义，即不同意义的对象在不同的局部应用中具有相同的名字。

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

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

结构冲突

同一对象在不同应用中具有不同的抽象。例如，职工在某一局部应用中被当作实体，而在另一局部应用中则被当作属性。

解决方法通常是把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。同一实体在不同局部E-R图中所包含的属性个数和属性排列次序不完全相同。解决方法是根据应用的语义对实体联系的类型进行综合或调整。

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

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

消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。

但并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。因此在设计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。如果人为地保留了一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件。

数据库逻辑结构的设计

数据逻辑结构设计的主要任务是将概念结构转换为某个DBMS所支持的数据模型，并将其性能进行优化。

要完成数据库的逻辑模式和外模式的设计工作，即系统设计者要先将E-R图转换成具体的数据库产品支持的数据模型，形成数据库逻辑模式，然后根据用户处理的要求、安全性的考虑建立必要的数据视图，形成数据的外模式；将概念结构转换为一般的关系、网状、层次模型；
将转换来的关系、网状、层次模型向指定数据库管理系统支持的数据模型转换；对数据模型进行优化。

范式

相关概念

函数依赖

设R(U)是属性集合U = { A 1 , A 2 , … , A n } \{A_1,A_2,\ldots,A_n\} { A1​,A2​,…,A