目录

一、概念

二、初始关系模式设计（E-R图转换关系模式）

1、实体集向关系模式的转换

2、两个实体型之间的联系集向关系模式的转换

3、同一实体型之间的联系集向关系模式的转换

4、多实体型之间的联系向关系模式的转换

5、弱实体集向关系模式的转换

 三、关系模式规范化

1、概念

2、范式

四、模式的评价与改进

---

一、概念

        逻辑结构设计是将概念结构设计阶段完成的概念模型，转换成能被选定的数据库管理系统(DBMS)支持的数据模型。这里主要将E-R模型转换为关系模式。需要具体说明把原始数据进行分解、合并后重新组织起来的数据库全局逻辑结构，包括所确定的关键字和属性、重新确定的记录结构和文件结构、所建立的各个文件之间的相互关系，形成本数据库的数据库管理员视图。一般的逻辑设计分为以下3步：初始关系模式设计、关系模式规范化、模式的评价与改进。

二、初始关系模式设计（E-R图转换关系模式）

1、实体集向关系模式的转换

        实体集的转换规则：一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就的码。

例：学生实体可以转换为如下关系模式：

学生（学号，姓名，性别，出生日期，所在系，年级）

2、两个实体型之间的联系集向关系模式的转换

（1）1：1联系的转换

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

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

（2）1:n联系的转换

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

        若转换为一个独立的关系模式，则与该联系相连的各实体的主码以及联系本身的属性均转换为关系的属性，而关系的主码为n端实体的主码。若与n端关系模式合并，则在n端实体集中增加新属性，新属性由联系对应的1端实体集的主码和联系自身的属性构成，而关系模式的主码不变。

 

(3)m:n联系的转换

        与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。 

3、同一实体型之间的联系集向关系模式的转换

        同一实体型的实体间的联系即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。

 （1)1：1联系的转换

（2）1:n联系的转换

（3）m:n联系的转换

​

4、多实体型之间的联系向关系模式的转换

        两个以上的实体型间也存在着1:1、1:n和m:n三种情况。

（1）1：n的多元联系

        修改1端实体集对应的关系，即将与联系相关的其他实体集的码和联系自身的属性作为新属性加入到1端实体集中。

（2）m:n的多元联系

        新建一个独立的关系，多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。

5、弱实体集向关系模式的转换

        强实体集和弱实体集的概念与存在依赖密切相关，强实体集的成员必然是支配实体，而弱实体集的成员是从属实体。由于弱实体不能独立存在，它必须依附于一个所有者实体，因此将弱实体集转换成关系模式时，弱实体所对应的关系中必须包含所有者实体的主码。

 三、关系模式规范化

1、概念

        数据库逻辑设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还应该根据应用需要适当修改、调整数据模型的结构，这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导，将关系模式规范化，使之达到较高的范式是设计好关系模式的唯一途径，否则，设计的关系数据库会产生一系列的问题。

        一个“好”的关系模式应当不会发生插入和删除异常，冗余度要尽可能少。对于存在问题的关系模式，可以通过模式分解的方法使之规范化。“分解”是解决冗余的主要方法，也是规范化的一条原则，“关系模式有冗余问题，就分解它”。

        函数依赖基本概念
        规范化是指用形式更为简洁、结构更加规范的关系模式取代原有关系模式的过程。

        关系模式必须满足一定的完整性约束条件以达到现实世界对数据的要求。完整性约束条件主要包括以下两个方面：

        对属性取值范围的限定

        属性值间的相互联系(主要体现在值的相等与否)，这种联系称为数据依赖。

        客观世界的事物间存在着错综复杂的联系，实体间的联系有两类：一类是实体与实体之间的联系；另一类是实体内部各属性间的联系。而属性间的联系可分为3类：

        一对一联系(1:1)。设X和Y是关系R的两个属性(集)。如果对于X中的任一具体值，Y中至多有一值与之对应；反之亦然，则称X、Y两属性间是一对一联系。

        一对多联系(1:n)。设X和Y是关系R的两个属性(集)。如果对于X中的任意具体值，Y中至多有一个值与之对应，而Y中的一个值却可以在X中的n个值(n≥0)相对应，则称Y对X是一对多联系。

        多对多联系(m:n)。设X和Y是关系R的两个属性(集)。如果对于X中的任意具体值，Y中有m个值(m≥0)与之对应，而Y中的一个值也可以和X中的n个值(n≥0)相对应，则称Y对X是多对多联系。

        数据依赖是指通过一个关系中属性间值的相等与否体现出来的数据间的相互关系，是现实世界属性间相互联系的抽象，是数据内在的性质。数据依赖共有3种：

        函数依赖(Functional Dependency, FD)

        多值依赖(Multivalued Dependency, MVD)

        连接依赖(Join Dependency, JD)

        其中最重要的是函数依赖和多值依赖。

        在数据依赖中，函数依赖是最基本、最重要的一种依赖，它是属性之间的一种联系，假设给定一个属性的值，就可以唯一确定(查找到)另一个属性的值。这种唯一性并非指只有一个记录，而是指任何记录。

        设有关系模式R(U)，X和Y均为U={A1, A2, …, An}的子集，r是R的任一具体关系，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等(也就是说，如果对于r中的任意两个元组t和s，只要有t[X]=s[X]，就有t[Y]=s[Y])，则称X函数决定Y，或称Y函数依赖于X，记作X→Y，其中X叫作决定因素(Determinant)，Y叫作依赖因素(Dependent)。

        属性间联系决定函数依赖。

        1:1联系。如果两属性集X、Y之间是1:1联系，则存在函数依赖X←→Y。

        1:n联系。如果两属性集X、Y之间是n:1联系，则存在函数依赖X→Y。

        m:n联系。如果两属性集X、Y之间是m:n联系，则不存在函数依赖。

        识别函数依赖是理解数据语义的一个组成部分，依赖是关于现实世界的断言，它不能被证明，决定关系模式中函数依赖的唯一方法是仔细考察属性的含义。

2、范式

        利用规范化理论，使关系模式的函数依赖集满足特定的要求，满足特定要求的关系模式称为范式(Normal Form)。关系按其规范化程度从低到高可分为5级范式，分别称为1NF、2NF、3NF(BCNF)、4NF、5NF。规范化程度较高者必是较低者的子集。一个低一级范式的关系模式，通过模式分解可以转换成若干个高一级范式的关系模式的集合，这个过程称为规范化。

（1）第一范式(1NF)
        如果关系模式R中不包含多值属性(每个属性必须是不可分的数据项)，则R满足第一范式(First Normal Form)，记作R∈1NF 。1NF是规范化的最低要求，是关系模式要遵循的最基本的范式，不满足1NF的关系是非规范化的关系。关系模式如果仅仅满足1NF是不够的，只有对关系模式继续规范化，使之满足更高的范式，才能得到高性能的关系模式。

（2）第二范式(2NF)
        如果关系模式R(U, F)∈1NF，且R中的每个非主属性完全函数依赖于R的某个候选码，则R满足第二范式(Second Normal Form)，记作R∈2NF。不满足2NF的关系模式，会产生以下几个问题：插入异常、删除异常、更新异常。解决的办法是用投影分解把关系模式分解为多个关系模式。投影分解是把非主属性及决定因素分解出来构成新的关系，决定因素在原关系中保持，函数依赖关系相应分开转化(将关系模式中部分依赖的属性去掉，将部分依赖的属性单组组成一个新的模式)。

（3）第三范式(3NF)
        如果关系模式R(U, F)∈2NF，且每个非主属性都不传递函数依赖于任何候选码，则R满足第三范式(Third Normal Form)，记作R∈3NF。解决的办法同样是投影分解。3NF是一个可用的关系模式应满足的最低范式，也就是说，一个关系模式如果不满足3NF，则实际上它是不能使用的。

四、模式的评价与改进

        关系模式的规范化不是目的而是手段，数据库设计的目的是最终满足应用需求。因此，为了进一步提高数据库应用系统的性能，还应该对规范化后产生的关系模式进行评价、改进，经过反复多次的尝试和比较，最后得到优化的关系模式。

---

0.思维导图

1.数据库系统结构

（1）两种角度

• 从数据库管理系统角度看，数据库系统通常采用三级模式结构，是数据库系统内部的系统结构

• 从数据库最终用户角度看（数据库系统外部的体系结构） ，数据库系统的结构分为:
  单用户结构
  主从式结构
  分布式结构
  客户／服务器
  浏览器／应用服务器／数据库服务器多层结构等

（2）数据库系统模式的概念

来自张教授的解疑：模式是数据库结构的描述、关系模式是表的结构的描述;

“型” 和“值” 的概念

• 型(Type)
  对某一类数据的结构和属性的说明
• 值(Value)
  是型的一个具体赋值

例如
学生记录型：
（学号，姓名，性别，系别，年龄，籍贯）
一个记录值：
（900201，李明，男，计算机，22，江苏）

模式（Schema）

• 数据库逻辑结构和特征的描述
• 是型的描述
• 反映的是数据的结构及其联系
• 模式是相对稳定的

实例（Instance）

• 模式的一个具体值
• 反映数据库某一时刻的状态
• 同一个模式可以有很多实例
• 实例随数据库中的数据的更新而变动

一个数据库只有一个模式，可以把模式看成唯一的数据库，实例就是数据库里面的多个表

例如：在学生选课数据库模式中，包含学生记录、课程记录和学生选课记录

• 2003年的一个学生数据库实例，包含：
  2003年学校中所有学生的记录
  学校开设的所有课程的记录
  所有学生选课的记录
• 2002年度学生数据库模式对应的实例与2003年度学生数据库模式对应的实例是不同的

（3）数据库系统的三级模式结构

① 模式（Schema）

模式（也称逻辑模式）

• 数据库中全体数据的逻辑结构和特征的描述
• 所有用户的公共数据视图，综合了所有用户的需求

一个数据库只有一个模式，可以把模式看成唯一的数据库，实例就是数据库里面的多个表

模式的地位：是数据库系统模式结构的中间层

• 与数据的物理存储细节和硬件环境无关
• 与具体的应用程序、开发工具及高级程序设计语言无关

模式的定义:

• 数据的逻辑结构（数据项的名字、类型、取值范围等）
• 数据之间的联系
• 数据有关的安全性、完整性要求

② 外模式（External Schema）

外模式（也称子模式或用户模式）

• 数据库用户（包括应用程序员和最终用户）使用的局部数据的逻辑结构和特征的描述
• 数据库用户的数据视图，是与某一应用有关的数据的逻辑表示，可以看成把数据库的部分数据，运用在不同的应用程序上，在UI界面上显示

一个数据库只有一个模式，可以把模式看成唯一的数据库，实例就是数据库里面的多个表
外模式的地位：介于模式与应用之间

• 模式与外模式的关系：一对多
  外模式通常是模式的子集;
  一个数据库可以有多个外模式。反映了不同的用户的应用需求、看待数据的方式、对数据保密的要求;
  对模式中同一数据，在外模式中的结构、类型、长度、保密级别等都可以不同;
• 外模式与应用的关系：一对多
  同一外模式也可以为某一用户的多个应用系统所使用;
  但一个应用程序只能使用一个外模式;可以看成把数据库的部分数据，运用在不同的应用程序上，在UI界面上显示

外模式的用途

• 保证数据库安全性的一个有力措施；
• 每个用户只能看见和访问所对应的外模式中的数据；

③ 内模式（Internal Schema）

内模式（也称存储模式）

• 是数据物理结构和存储方式的描述
• 是数据在数据库内部的表示方式:
  • 记录的存储方式（顺序存储，按照B树结构存储，
    按hash方法存储）
  • 索引的组织方式
  • 数据是否压缩存储
  • 数据是否加密
  • 数据存储记录结构的规定
• 一个数据库只有一个内模式

·例如学生记录，如果按堆存储，则插入一条新记录总是放在学生记录存储的最后.

• 如果按·学号升序存储，则插入一条记录就要找到它应在的位置插入，如图1.29（b）所示
• 如果按照学生年龄聚簇存放，假如新插入的S3是16岁，则应插入的位置如图1.29（c）所示
  

④ 数据库模式、外模式、内模式总结

数据库模式

• 即全局逻辑结构是数据库的中心与关键
• 独立于数据库的其他层次
• 设计数据库模式结构时应首先确定数据库的逻辑模式

数据库的外模式

• 面向具体的应用程序
• 定义在逻辑模式之上
• 独立于存储模式和存储设备
• 当应用需求发生较大变化，相应外模式不能满足其视图要求时，该外模式就得做相应改动
• 设计外模式时应充分考虑到应用的扩充性

数据库的内模式

• 依赖于它的全局逻辑结构
• 独立于具体的存储设备
• 将全局逻辑结构中所定义的数据结构及其联系按照一定的物理存储策略进行组织，以达到较好的时间与空间效率

（4）数据库的二级映像功能与数据独立性

• ·三级模式是对数据的三个抽象级别

• 二级映象在DBMS内部实现这三个抽象层次的联系和转换

  • 外模式／模式映像
  • 模式／内模式映像
    

① 外模式／模式映象

• 模式：描述的是数据的全局逻辑结构
• 外模式：描述的是数据的局部逻辑结构
• 同一个模式可以有任意多个外模式
• 每一个外模式，数据库系统都有一个外模式／模式映象，定义外模式与模式之间的对应关系,看成数据库的数据与API调用的部分数据之间的关系(I think)
• 映象定义通常包含在各自外模式的描述中

保证数据的逻辑独立性

• 当模式改变时，数据库管理员修改有关的外模式／模式映象，使外模式保持不变
• 应用程序是依据数据的外模式编写的，从而应用程序不必修改，保证了数据与程序的逻辑独立性，简称数据的逻辑独立性。

② 模式／内模式映象

模式／内模式映象定义了数据全局逻辑结构与存储结构之间的对应关系。

  例如，说明逻辑记录和字段在内部是如何表示的

• 数据库中模式／内模式映象是唯一的
• 该映象定义通常包含在模式描述中

保证数据的物理独立性

• 当数据库的存储结构改变了（例如选用了另一种存储结构），数据库管理员修改模式／内模式映象，使模式保持不变.
• 应用程序不受影响。保证了数据与程序的物理独立性，简称数据的物理独立性。

特定的应用程序

• 在外模式描述的数据结构上编制的
• 依赖于特定的外模式
• 与数据库的模式和存储结构独立
  不同的应用程序有时可以共用同一个外模式

数据库的二级映像

• 保证了数据库外模式的稳定性
• 从底层保证了应用程序的稳定性，除非应用需求本身发生变化，否则应用程序一般不需要修改

数据与程序之间的独立性，使得数据的定义和描述可以从应用程序中分离出去

数据的存取由DBMS管理

• 用户不必考虑存取路径等细节
• 简化了应用程序的编制
• 大大减少了应用程序的维护和修改

2.数据库的组成

• 数据库
• 数据库管理系统（及其开发工具）
• 应用系统
• 数据库管理员
• 硬件平台及数据库
• 软件
• 人员

（1）硬件平台及数据库

数据库系统对硬件资源的要求

• (1) 足够大的内存

  • 操作系统
  • DBMS的核心模块
  • 数据缓冲区
  • 应用程序

• (2) 足够大的外存

  • 磁盘或磁盘阵列
  • 数据库
  • 光盘、磁带
  • 数据备份

• (3) 较高的通道能力，提高数据传送率

（2） 软件

• DBMS
• 支持DBMS运行的操作系统
• 与数据库接口的高级语言及其编译系统
• 以DBMS为核心的应用开发工具
• 为特定应用环境开发的数据库应用系统

（3）人 员

• 数据库管理员
• 系统分析员和数据库设计人员
• 应用程序员
• 用户

不同的人员涉及不同的数据抽象级别，具有不同的数据视图，如下图所示

① 数据库管理员(DBA)

具体职责：
1.决定数据库中的信息内容和结构
2.决定数据库的存储结构和存取策略
3.定义数据的安全性要求和完整性约束条件
4.监控数据库的使用和运行

• 周期性转储数据库
• 数据文件
• 日志文件
• 系统故障恢复
• 介质故障恢复
• 监视审计文件

5.数据库的改进和重组

• 性能监控和调优
• 定期对数据库进行重组织，以提高系统的性能
• 需求增加和改变时，数据库须需要重构造

② 系统分析员

具体职责：

• 负责应用系统的需求分析和规范说明
• 与用户及DBA协商，确定系统的硬软件配置
• 参与数据库系统的概要设计

③ 数据库设计人员

具体职责：

• 参加用户需求调查和系统分析
• 确定数据库中的数据
• 设计数据库各级模式

④ 应用程序员

具体职责：

• 设计和编写应用系统的程序模块
• 进行调试和安装

⑤ 用户

用户是指最终用户（End User）。
最终用户通过应用系统的用户接口使用数据库。
1.偶然用户

• 不经常访问数据库，但每次访问数据库时往往需要不同的数据库信息
• 企业或组织机构的高中级管理人员

2.简单用户

• 主要工作是查询和更新数据库
• 银行的职员、机票预定人员、旅馆总台服务员

3.复杂用户

• 工程师、科学家、经济学家、科技工作者等
• 直接使用数据库语言访问数据库，甚至能够基于数据库管理系统的API编制自己的应用程序