一、数据库设计方案

数据库设计是数据库应用系统开发的重要内容。在实现数据库之前，必须有明确的设计方案。

1. 数据库应用架构设计：单用户、集中、CS、分布

在不同应用需求场景中，数据库的应用架构方式是不同的。

数据库应用架构可分为单用户结构、集中式结构、客户／服务器结构和分布式结构。

2. 数据库结构设计：概念、逻辑、物理

数据库结构设计一般分为概念层、逻辑程、物理层设计，设计模型分别为概念数据模型、逻辑数据模型和物理数据模型。

3. 数据库应用访问方式设计：访问方式

数据库应用对数据库访问可以有多种方式，如直接本地接口连接访问、基于标准接口连接访问、基于数据访问层框架连接访问。

数据库结构设计模型

概念数据模型：概念，不考虑实时细节

（Concept Data Model，CDM）是一种面向用户的系统数据模型，它用来描述现实世界的系统概念化数据结构。

使数据库设计人员在系统设计的初始阶段，摆脱计算机系统及DBMS的具体技术问题，集中精力分析业务数据以及数据之间

的联系等，描述系统的数据对象及其组成关系。

逻辑数据模型 ：逻辑表示

(Logic Data Model，LDM)是在概念数据模型基础上，从系统设计角度描述系统的数据对象组成及其关联结构，并考虑这些数据对象符合数据库对象的逻辑表示。

物理数据模型：具体实现

（Physical Data Model，PDM）是在逻辑数据模型基础上，针对具体DBMS所设计的数据模型。

它用于描述系统数据模型在具体DBMS中的数据对象组织、存储方式、索引方式、访问路径等实现信息。

数据库建模设计过程

1）数据需求分析阶段

• 从现实业务获取数据表单、报表、查询、业务规则、数据
• 更新的说明
• 分析系统的数据特征、数据类型、数据取值约束
• 描述系统的数据关系、数据处理要求
• 建立系统的数据字典

2）数据库设计阶段

• 数据库模型结构设计（概念数据模型、逻辑数据模型、物理数据模型）
• 数据库索引、视图、查询设计
• 数据库表约束设计
• 数据库触发器、存储过程设计

3）数据库实现阶段

• 数据库创建
• 数据模型物理实现

4）数据库测试阶段

• 数据库数据上线
• 数据库系统测试

2.设计策略

• 自底向上设计
• 自顶向下设计
• 自内向外设计
• 混合策略设计

自顶向下分析需求与自底向上设计概念结构：需求分析是自顶向下，概念结构是自底向上

概念模型（CDM）：数据结构、数据操作和完整性约束

CDM是一组严格定义的模型元素的集合，

这些模型元素精确地描述了系统的静态特性、动态特性以及完整性约束条件等，

其中包括了数据结构、数据操作和完整性约束三部分。

① 数据结构表达为实体和属性;

② 数据操作表达为实体中的记录的插入、删除、修改、查询等操作;

③ 完整性约束表达为数据的自身完整性约束（如数据类型、检查、规则等）和数据间的完整性约束（如外键、联系、继承联系等）;

实体联系模型（ERM）：甲方用户要求

概念模型的用途

① 概念模型用于信息世界的建模

② 是现实世界到机器世界的一个中间层次

③ 是数据库设计的有力工具

④ 数据库设计人员和用户之间进行交流的语言

对概念模型的基本要求

① 较强的语义表达能力

② 能够方便、直接地表达应用中的各种语义知识

③ 简单、清晰、易于用户理解

ER模型及基本概念：现实对象

实体(Entity)

概念：一个现实世界中有别于其它对象的对象。

注意：可以是具体的、也可以是抽象的。

示例：某某学生、某某老师、某门课程

属性（Attribute）

概念：实体的特征或性质，即实体用若干属性来描述。

示例： 学生的学号、姓名、生日、年龄、性别、住址等；

课程的课程号、课程名、学时、学分、开课学院等。

分类(按结构)：简单属性(不可再分)复合属性和子属性。

示例：复合—姓名(现用名、曾用名、英文名)；住址(省、

市、区、街道、门牌号、邮政编码)。

域(Domain)：取值范围

概念：属性的取值范围。

按域的取值分：单值、多值、导出和空值(NULL)等属性。

示例：

① 单值属性—性别（每个实体只有唯一确定的值）

② 多值属性—学位值(学士、硕士、博士)；

③ 导出属性—年龄（是出生日期计算出年龄）。
 

键：唯一标识属性

用于唯一标识集合中的每个实体的一组属性。

示例：学生的学号；课程的课程号；选课的学号及课程号

键的分类(按属性个数)：简单键、复合键。

① 由单个属性构成的键，称为简单键

② 由两个或两个以上属性构成的键，称为复合键

候选键(Candidate Key)：有多种选择作为键的属性或属性集，且属性集的任何属性都不可缺少，如缺少任意属性，就不能成为键。

主键(Primary Key)：当存在多个候选键时，需选定一个作为实体的主键。是描述实体的唯一标识。示例：学生的身份证号、学号等。

实体型（Entity Type）：实体名+属性

概念：用实体名及其属性名集合来抽象和刻画同类实体称为实体型

示例：学生（学号、姓名、生日、年龄、性别、住址）

实体集（Entity Set）：实体集合

概念：同一类型实体的集合称为实体集

示例：一个学校所有学生构成的集合，称为学生实体集

注意：在不影响理解的情况下，可以将实体、实体型、实体集都简称为实体

实体、属性及标识符的表达：唯一标识

实体类型中的每个实体包含唯一标识它的一个或一组属性，

这些属性称为实体类型的标识符（Identifier），

有些实体类型可以有几组属性充当标识符，选定其中一组属性作为实体类型的主标识符，其他的作为次标识符。

主流数据库建模工具Power Designer

Power Designer是一种面向软件开发生命周期的建模工具，它提供软件需求模型、业务流程模型、数据库模型、面向对象模型、自定义模型的开发支持。

Power Designer的数据建模工具特点：

• 功能强大的软件开发生命周期建模工具

• 支 持 目 前 主 流 的 数 据 库 管 理 系 统 （ 如 Oracle 、 SYBASE 、SQL Server、DB2、MySQL、PostgreSQL等）

• 支持目前多种客户端开发工具

• 满足大、中、小型数据库建模设计

Power Designer可建立的数据模型

Power Designer各个数据模型之间的关系

 使用PowerDesigner工具进行数据库建模

(1) 创建工程

(2) 创建数据库模型

(3) 创建实体（或实体型）

(3) 给实体命名

(3) 给实体添加属性

(3) 属性添加完成

PowerDesigner创建实体

ER模型及基本概念

联系（Relationship）

概念：反映为实体内部的联系和实体之间的某种关系。

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

联系的属性：联系也可有描述属性，记录联系的信息而非实体的信息。

联系的识别：联系由参与的实体唯一确定。

两个实体之间可能有多个不同的联系；

一个联系所关联的是同一个实体集中的两个实体

实体间联系的类型

1.一对一联系（one-to-one，1:1）

定义:设联系R关联实体A和B。如果对应A中的每个实体，B中有且仅有一个实体与之关联,则称R是一对 一联系 ，

简记作1 :1联系。

2. 一对多联系（one-to-many，1:N）

定义:如果对应A中的每个实体，B中有n个实体(n≥0)与之关联，则称R是一对多联系型，简记作1 :N联系

3. 多对多联系（many-to-many，M:N）

定义:如果对应A中的每个实体，B中有n个实体(n≥0)与之关联，如果对应B中的每个实体，A中有m个实体(m≥0)与之关联，则称R是多对多联系，简记作M:N联系

(4) 添加联系

(4) 修改联系类型

弱实体(Weak Entities):没有键的实体

前面所讲的实体总存在键。但实际情况中，并不总是如此。

概念：不存在键的实体，称为弱实体。

不同弱实体的属性值可能完全相同，因此，难以区别。

为此，弱实体型需要与一般的实体相关联。

识别实体型与识别联系：弱实体通过关系结合实体识别

假如联系R关联弱实体A和一般实体B，

A的弱实体可以通过与实体B相结合来加以区别，

则B称为弱实体A的识别实体，R称为弱实体A的识别联系。

ER模型描述概念分层

在某些应用中，需要将实体集划分为若干子类，分类后形成层次关系，最上层为超类（Super class），下层即为子类。

示例：研究生和本科生都是学生的子类。

表示：研究生ISA（is a）学生、本科生ISA学生。ISA为这种类层次的联系。

子类属性：除可继承超类属性外还可有自己独特的属性。

注意：有时还可按其他标准分类，可根据管理的需要来定。

示例：员工分资深员工（Senior Employee）与非资深（Junior）员工。 

注意：调整布局的逻辑清晰美观

三、E-R 模型的设计实例

设计一个企业职工管理数据库，主要功能有：

人事管理（人事部门）

工资管理（财务部门）

项目管理（科研部门）

第1步 设计局部 E-R 模型

（1）确定局部范围

可以按部门划分。

（2）确定实体集

人事部门：职工、部门、职务

财务部门：职工、工资

科研部门：职工、项目

（3）确定实体集的属性

人事部门：职工（职工号、姓名、性别、出生日期、工资）

部门（部门号、部门名称、部门电话、负责人）

职务（职务编码、职务名称、职务津贴）

财务部门：职工（职工号、姓名、性别、出生日期、职务）

工资（工资号、基本工资、津贴、保险、实发工资）

科研部门：职工（职工号、姓名、性别、出生日期、职务）

项目（项目号、名称、起始日期、鉴定日期）

（4）确定联系集

人事部门：职工与部门的联系（分工）

职工与职务的联系（担任）

财务部门：职工与工资的联系（领取）

科研部门：职工与项目的联系（参与）

（5）确定联系集的属性

人事部门： 职工与职务的联系有一个属性（任职时间）。

（6）画出各局部的 E-R 模型

人事管理的局部 E-R 模型

人事部门：职工（职工编号、姓名、性别、出生日期、工资）

部门（部门号、部门名称、部门电话、负责人）

职务（职务编码、职务名称、职务津贴）

工资管理的局部 E-R 模型

财务部门：职工（职工号、姓名、性别、出生日期、职务）

工资（工资号、基本工资、津贴、保险、实发工资） 

项目管理的局部 E-R 模型

科研部门：职工（职工号、姓名、性别、出生日期、职务）

项目（项目号、名称、起始日期、鉴定日期）

2、组合局部 E-R 模型为全局 E-R 模型

消除各局部E-R模型之间的冲突

① 命名冲突: 包括同名异义或异名同义等。

② 属性冲突: 包括属性的数据类型、取值范围等。

③ 结构冲突

确定公共实体

有两个重复的属性，

该去掉哪一个？

局部 E-R模型以公共实体为中心，两两合并。

 3、消除冗余，优化全局 E-R 模型

（1）实体和联系尽量减少

1 : 1 联系的或具有相同键的两个实体集根据实际情况可以合并。如 职工和工资。

（2）属性尽量减少

去除冗余的属性。

如 工资和职务两个实体都有津贴属性；

工资实体的实发工资属性可以由其他属性计算出来；

（3）实体间的联系没有冗余

改进后 E-R 模型 

通过PowerDesigner将概念模型转化为逻辑模型

检查模型的正确性

通过PowerDesigner转化的逻辑模型 

通过PowerDesigner转化物理模型 

由物理模型生成SQL语句如下，可以copy到文本编辑器

为什么要对关系模式进行优化？

如何对关系模式进行优化？

一、实例-假设有如下表

教师学生关系模式

假设数据语义: （1）教师可以在不同学期上同一门课程；

（2） 一个教师可为多位学生上课，而一个学生可选多门课程；

（3）同一门课，一个学生在某学期只能选一个教师。

根据上述语义（Tid,Course,Sid,Semester）作为该模式的主键

假设教师、学生、课程信息没有在其它表中存储

上述教师学生模式可能存在的问题

(1) 插入异常(Insert Anomaly)

如果教师新来工作，由于还没排课，学生为空，由于主键属性不能为null，导致而不能插入教师信息

(2) 删除异常(Delete Anomaly)

① 删除时删掉了其他信息；

② 删除一个元组却删除了多个元组。

(3) 冗余(Redundancy)

表现： ① 某种信息在关系中存储多次；

(4) 更新异常(Update Anomaly)

表现：① 更新一条记录却要求更新多个记录。

解决方案：

除了1:1联系的实体可以包含在一个表中，其它实体应或联系单独建立关系表中。

将上表中的两个实体及联系分解，形成三张关系表

分析为何存在这些问题

数据语义在关系模式中的体现

具体表现：在关系模式的属性间的依赖关系，此即数据依赖。

数据依赖（Data Dependency）：指通过关系模式某些属性的取值能够决定另一些属性的取值。

数据依赖分类：函数依赖、多值依赖和连接依赖

数据依赖决定因素：由现实系统中属性间相互联系的语义决定。

异常现象产生的根源：关系模式中属性间存在的这些依赖关系。

根源的体现及解决：一般来讲，关系必须含有主键和候选键。

主键值决定其他属性值，候选键的值不能重复。如果将各种数据集中于一个模式中，一般都会造成异常。

解决异常的方法，是利用规范化理论，对关系模式进行相应的分解，以消除这些异常。

规范化就是对所有的属性进行重新组合，使关系的结构更简洁、更规范。

规范化的目的是：

优化关系模式，提高数据管理的效率。

三、规范化的几个概念

1、属性的几个概念

（1）简单属性和复合属性:可不可以再分

关系模型只支持简单属性。

 （2）单值属性和多值属性

关系模型只支持单值属性。

（3）基本属性和导出属性

如出生日期和年龄；

基本工资、津贴、保险和实发工资，等等。

（4）属性之间的联系

① 1:1

② 1:n

③ m:n

2、键的几个概念

① 单键:由一个属性组成的键称为单键。

② 多键:由关系表中的多个属性组成的键称为多键。

③ 全键:由关系表中的全部属性组成的键称为全键。

3、函数依赖：就是函数的映射关系

函数依赖是属性之间的约束关系。

定义：设X、Y是关系表R的属性（组），

如果对于R的所有元组都有：X的每一具体值都只有一个Y的值与之对应，则称X函数决定Y，或Y函数依赖于X，记作XY。

换句话说，如果知道了X的值，就可以在表中确定与之对应的Y的值（只有一个）。

函数依赖等价定义

假设R是一关系模式，U是R的属性集合，X、Y⊆U，r是R的一个关系实例，元组t∈R。则用t[X]表示元组t在属性集合X上的值。XY表示X和Y的并集。

函数依赖定义：

设R是一个关系模式，U是R的属性集合，X和Y是U的子集。对于R的任意实例r，r中任意两个元组t1和t2，如果t1[X]=t2[X] 则t1[Y]=t2[Y]，那么称X函数地确定Y，或Y函数地依赖于X，记作：X→Y，X称为决定子(Determinant)。

函数依赖关心的问题：

是一个或一组属性的值决定其他属性的值。

如果X、Y是 1 : 1 的联系，则X<->Y

如 学号 联系电话，即知道了学号，就可以在表中确定其联系电话；

同样地，知道了联系电话，也可以在表中确定其学号。

如果X、Y是 n : 1 的联系，则X->Y。

如 学号 班号，即知道了学号，就可以在表中确定其班号；

相反地，如果知道了班号，却无法确定学号。

如果X、Y是 m : n 的联系，则X和Y不存在函数依赖关系。

如 学号和课程号没有函数依赖关系。即知道了学号，无法在表中确定课程号；

同样地，如果知道了课程号，也无法确定学号

（1）平凡函数依赖和非平凡函数依赖：X->Y，Y是X子集，平凡依赖

定义：设X、Y是关系表R的属性（组），且X->Y，

若Y⊆X，则称为平凡依赖，否则称为非平凡依赖。

（2）完全函数依赖和部分函数依赖：X->Y，X子集->Y，Y部分依赖

定义：设X、Y是关系表R的属性（组），且X->Y，

若X存在某个子集X1，使X1->Y成立，则称Y部分依赖于X，

否则称Y完全依赖于X。

（3）传递函数依赖和非传递函数依赖：X->Y，Y->Z，Y-x->X，X传递决定Z

定义：设X、Y、Z是关系表R的属性（组），若X->Y，Y->Z，且Y不属于X，

则称X传递决定Z，或Z传递依赖于X，否则称Z非传递依赖于X 。

Armstrong公理系统：函数映射系统

问题提出：在关系模式的规范化处理过程中，不仅要知道一个给定的函数依赖集合，还要知道由给定的函数依赖集合所蕴涵（或推导出）的所有函数依赖的集合。为此，需要有效而完备的公理系统，Armstrong公理系统即是这样的系统。

Armstrong公理：为从已知的函数依赖推导出其他的函数依赖，Armstrong提出了一套推理规则，称为Armstrong公理(Armstrong’sAxioms)。

Armstrong公理包含如下三条推理规则：

• (1) 自反律(Reflexivity) ：若Y⊆X⊆U，则X→Y。
• (2) 增广律(Augmentation) ：若X→Y，Z⊆U，则XZ→YZ。
• (3) 传递律(Transitivity) ：若X→Y和Y→Z，则X→Z。

引理 1：Armstrong公理是正确的，即由已知函数依赖，根据Armstrong公理所推导的函数依赖总是成立的。

引理 2：如下三条推理规则是正确的：

• (1) 合并规则(Union)：如果X→Y，X→Z，则X→YZ。
• (2) 伪传递规则(Pseudo Transitivity)：如果X→Y，YW→Z，则XW→Z。
• (3) 分解规则(Decomposition)：如果X→Y，Z⊆Y，则X→Z。或：如X→YZ，则X→Y，X→Z。

多值依赖：X可以决定一组Y的值

（MultiValued Dependency，缩写为MVD）

设R(U)是属性集U上的关系模式，X、Y、Z是U的子集，且Z=U−X−Y，

多值依赖X→→Y成立当且仅当对R(U)的任一关系r，

任给的一对（x，z）值有一组Y的值，这组值仅仅取决于x值而与z值无关。

称X多值决定Y或Y多值依赖于X

例如，在关系模式TEACH中有C→→T

直观上看，若X→→Y，则X的一个值唯一决定一组Y值，且这组值与X、Y之外的属性值无关

多值依赖的另一等价定义：

多值依赖X→→Y成立当且仅当对R(U)的任一关系r，

若存在元组s、t使得s[X]=t[X]，则必存在元组w、v∈r（w、v可以与s、t相同），

使得w[X]=v[X]=t[X]，而w[Y]=t[Y]，w[Z]=s[Z]，v[Y]=s[Y]，v[Z]=t[Z]。

交换s、t的Y值所得新元组仍在r中

图直观显示，x决定一组y值，这组值与z无关

由前面例子，可看出X、Y、Z之间有下述关系： 

多值依赖的性质：

（1）对称性：若 X→→Y， Z=U−X−Y，则 X→→Z。

（2）函数依赖可看成是多值依赖的特例：若 X→Y，则 X→→Y

（3）若U=XY（表示X ∪ Y），则 X→→Y显然成立。

（这种多值依赖无任何实际意义，故称为 平凡的多值依赖 ）

多值依赖与函数依赖的区别

（1）函数依赖X→Y的有效性仅取决于X、Y，与X、Y之外的属性无关：

X→Y在πXY（R）上成立    <->   X→Y在π W（R）上成立

其中W满足 XY ⊆ W ⊆ U（U是关系模式R的属性集）。

 多值依赖X→→Y的有效性与X、Y之外的属性范围有关：

若X→→Y在U上成立，则在W（ XY ⊆ W ⊆ U）上也成立，但反之不然。

可缩小范围但不一定能扩大范围

三、关系模式规范化理论

1、第一范式（1NF）：关系表R不存在复合属性及多值属性

定义：如果关系表R不存在复合属性及多值属性，

即：属性是不可再分，则称R满足第一范式，记作R∈1NF。

对于不满足1NF的表，其解决办法：

① 将复合属性用各子属性代替，称为简单属性

② 将含有多值属性的表分解成两张表，一张表由主键和简单属性构成，另外一张表由多值属性和主键。

2、第二范式（2NF）：所有非主属性都完全依赖于任一候选键，候选键->非主属性，候选键子集-x->非主属性

定义：如果关系表R满足1NF，且所有非主属性都完全依赖于任一候选键，

则称R满足第二范式，记作R∈2NF。

即R中不存在非主属性对键的部分函数依赖。

INF转化为2NF

① 将部分依赖的非主属性和它所依赖的属性构成新的模式

② 将完全依赖的非主属性与候选键构成新模式

将上述的表分解为如下三张表

可以写成如下关系模式：

（1）学生表（学号,姓名,班号,学院）

（2）课程表（课程号,课程名）

（3）选课表（学号,课程号,成绩）

3、第三范式（3NF）

定义：如果关系表R满足1NF，且所有非主属性都非传递依赖于R的任一候选键，

则称R满足第三范式，记作R∈3NF。

即R中不存在非主属性对键的传递函数依赖。

推论：若R不存在非主属性，则一定满足3NF。

如何将1NF转化3NF

如果不满足2NF，则先按照前面方法转化2NF，然后继续下一步；

如果满足2NF，则将传递依赖的属性及其中间属性移出构成新表；

将不存在传递依赖的属性及候选键构成新表。

4、改进的3NF（BCNF）

定义：如果关系表R满足1NF，且R的任一函数依赖关系的左部都是R的一个候选键，

则称R满足BCNF，记作R∈BCNF。

即R中不存在主属性对键的传递函数依赖或部分依赖。

推论1：R中所有非主属性对所有键都是完全依赖。

推论2：R中所有主属性对不包含它们的键都是完全依赖。

推论3：R中没有哪个属性完全依赖于非键属性。

定理： 若R满足BCNF，则一定满足3NF，但满足3NF并不一定就满足BCNF。

BCNF范式示例

BCNF范式的规范化

①如果不满足3NF，则先转化为3NF，然后继续下一步；

②如果满足3NF，则将部分依赖的主属性和它所依赖的主属性构成新表；然后将左端的候选键构成新表。

5、第四范式（4NF）

定义：如果关系表R满足第一范式，且R的任一非平凡的多值依赖X->->Y（X不包含Y），

X含有键，则称R满足第四范式，记作R∈4NF。

若R∈ 4NF，则必有R∈BCNF。

若R∈ BCNF，则不一定有R∈4NF。

若R中没有非平凡多值依赖，则必有R∈4NF。

4NF范式的规范化

对于U=X+Y+Z，如果有X→→Y，则将U分解XY和XZ两张表

四、规范化程度

规范化的过程

对关系模式分解，把一个低一级关系模式分解成若干个高一级的关系模式。

规范化与操作效率

片面追求高级的模式，会使数据库操作效率降低

通常情况，满足3NF就达到基本规范要求。

规范化过程：

1NF    去除复合属性和多值属性；

2NF    去除非主属性对键的部分函数依赖；

3NF    去除非主属性对键的传递函数依赖；

BCNF    去除主属性对键的传递函数依赖；

4NF    去除非平凡多值依赖。

三、反规范化处理

规范化减少了数据冗余，易于保证数据的完整性，但规范化也会导致数据库性能降低，因此，在利用规范化设计数据库时要平衡两者的关系。

规范化带来结构的完整和精确性，但同时也可能带来负面的效果。

也正是基于此，人们提出了反规范化设计的基本思想。

所谓的反规范化，就是适当降低甚至抛弃范式约束，不再要求一个表只表述其表自身，而是适当冗余性添加带有某种依赖关系的数据。

反规范化处理的主要手段有如下2种：

（1）增加冗余列或派生列

如果应用系统的常用操作需要关联其他表中的数据，则在进行表设计时，

应直接将该列融入当前表中，使其冗余存在，称为冗余列。

（2） 表的合并和分割

执行反规范化设计，表的数量往往也就会减少，而这也就降低了表连接运算的压力，

可以有力提升性能。

但反规范化的使用也会带来以下问题：

（1）数据冗余的存在

（2）降低了数据库的完整性

反规范化是把双刃剑，并不具有普遍意义，需要就事论事，用不好会伤及自身