数据库第四章：数据库设计与实现-CSDN博客

本文链接：https://blog.csdn.net/hlxchamp/article/details/115407161

4.1 数据库设计概述

4.1.1 数据库设计方案

在数据库设计中，我们需要创建不同层次的数据模型来抽象表示系统中的数据对象组成及其关系，即建立系统数据架构。
系统数据架构可由概念数据模型、逻辑数据模型和物理数据模型组成。
在这里插入图片描述
一、概念数据模型（CDM）
是一种面向用户的系统数据模型，它用来描述现实世界的系统概念化数据结构。使数据库设计人员在系统设计的初始阶段，摆脱计算机系统及DBMS的具体技术问题，集中精力分析业务数据以及数据之间的联系等，描述系统的数据对象及其组成关系。
二、逻辑数据模型（LDM）
是在概念数据模型基础上，从系统设计角度描述系统的数据对象组成及其关联结构，并考虑这些数据对象符合数据库对象的逻辑表示。
三、物理数据模型（PDM）
是在逻辑数据模型基础上，针对具体DBMS所设计的数据模型。它用于描述系统数据模型在具体DBMS中的数据对象组织、存储方式、索引方式、访问路径等实现信息。
在这里插入图片描述
数据库设计模型的3个基本原则：
① 真实地模拟现实世界的数据关系；
② 数据模型形式容易被用户理解；
③ 数据模型便于在计算机上实现。

4.1.2 数据库设计过程与策略

一、数据库设计过程
在这里插入图片描述
二、数据库设计策略
（1）自底向上策略
先具体分析各业务数据需求，并抽象各业务的数据实体及其关系，然后设计各个业务的数据模型。
（2）自顶向下策略
先从组织机构全局角度，规划设计顶层数据模型，然后分别对所涉及的业务数据进行实体联系建模。
（3）由内至外策略
先确定组织机构的核心业务，进行建模设计，然后扩展到外围业务的数据模型设计。
（4）混合设计策略
同时应用多种设计策略进行系统数据建模，可避免单一设计策略导致的数据库建模设计局限。

4.2 E-R模型

E-R模型是**“实体-联系模型”**的简称。

4.2.1 模型基本元素

一、实体
实体是对现实世界中描述事物数据对象的抽象概念。
凡是包含数据特征的对象均可被定义为实体（人/物品/机构单位等）。
在E-R模型图中，实体符号通常使用两层矩形方框表示，并在顶层方框内注明实体的名称。
建议实体名在概念模型设计阶段使用中文表示，而在物理模型设计阶段转换成英文名形式。
在这里插入图片描述
二、属性
每个实体都有自己的一组数据特征，这些描述实体的数据特征被称为实体的属性。
不同实体的属性是不同的。
两栏矩形框中，上栏区域显示实体名称，下栏区域显示实体属性。

在实体中，能够唯一标识不同实体实例的属性或属性集被称为标识符。
标识符对应着主键。
作为标识符的属性需加上下画线。

三、实体间的联系
可以使用联系表示一个或多个实体之间的关联关系（一般用动词表示）。
实体之间关联的数目被称为元。

实体自己与自己之间的联系被称为一元联系，也被称为递归联系
两个实体之间的联系被称为二元联系
3个实体之间的联系被称为三元联系
二元联系是最常见的实体联系

4.2.2 实体联系类型

一、多重性分类
（1）一对一联系
如果实体A中的每一个实例在实体B中至多有一个实例与之联系，反之亦然，则称实体A与实体B具有一对一联系，记为1:1。
（2）一对多联系
如果实体A中的每一个实例在实体B中有N（N≥1）个实例与之联系，而实体B中的每一个实例在实体A中至多有一个实例与之联系，则称实体A与实体B具有一对多联系，记为1:N。
（3）多对多联系
如果实体A中的每一个实例在实体B中有N（N≥1）个实体与之联系，而实体B中的每一个实例在实体A中有M（M≥1）个实体与之联系，则称实体A与实体B具有多对多联系，记为 M:N。
在这里插入图片描述
二、参与性分类
二元实体联系除了有“一对一”等联系类型外，每种联系实体还可根据参与性再分成两种类型，即可选的联系和强制的联系。
还需要具体指定各实体参与联系的基数。

基数有最小基数与最大基数。
如果最小基数为0，则表示联系中的实体参与是可选的。
如果最小基数为1，则表示联系中的实体参与是强制性的。
在实体两端分别标记联系的最小基数和最大基数。

三、继承性分类
继承联系用于表示实体之间的相似性关系。
一端是具有公共属性的实体，被称为父实体；另一端是一个或多个实体，被称为子实体。
① 互斥继承联系与非互斥继承联系

② 完整继承和非完整继承

对应的模型符号：

4.2.3 强弱实体

一个实体的存在必须以另一个实体的存在为前提，前者就被称为弱实体，而被依赖的实体
被称为强实体。
例如，在“学生”“学校”实体联系中，“学生”实体必须依赖于“学校”实体而存在。因此，在该
实体联系中，“学生”为弱实体，“学校”为强实体。
在这里插入图片描述
当给出一个弱实体时，必须也给出它所依赖的强实体。
在一些情况下，一个实体既可能是弱实体，又可能是强实体，这取决于该实体与其他实体之间的关系。

4.2.4 标识符依赖实体

弱实体又分为标识符（ID）依赖弱实体和非标识符（ID）依赖弱实体两类。
一、标识符（ID）依赖弱实体
如果弱实体的标识符含有所依赖实体的标识符，则该弱实体被称为标识符（ID）依赖弱实体。
在这里插入图片描述
“成绩表”实体的标识符分别取决于“学生”“课程”实体的标识符，因此，“成绩表”实体是标识符（ID）依赖弱实体。
二、非标识符（ID）依赖弱实体
在有依赖关系的弱实体中，并非所有弱实体都是标识符（ID）依赖弱实体，它们可以有自己的标识符，这样的弱实体即为非标识符（ID）依赖弱实体。
例如，在图4-15所示的“客户”“订单”“商品”实体联系中，“订单”实体在语义上依赖于“客户”“商品”实体而存在。但在“订单”实体中，不需要将“客户”“商品”实体的标识符作为“订单”实体的标识符组成部分。因此，“订单”实体为非标识符依赖弱实体。
在这里插入图片描述
在以上示例给出的标识符依赖弱实体和非标识符依赖弱实体均为一对多联系。除此之外，标识符依赖弱实体和非标识符依赖弱实体在其他示例中也可为一对一联系或多对多联系。

在E-R模型中，对标识符（ID）依赖弱实体的联系连线图形符号，在弱实体一侧有一个三角形的符号，如图4-14所示。
对非标识符（ID）依赖弱实体的联系连线图形符号，在弱实体一侧仅为基本鸟足符号，如图4-15所示。

4.2.5 E-R模型图

在这里插入图片描述
补：
一、无论强实体还是弱实体，只是在后期向物理模型（关系模型）转换时处理上有不同。
二、强弱是相对于其它实体而言的

4.3 数据库建模设计

4.3.1 概念数据模型

一、什么是概念数据模型设计
概念数据模型设计一般是采用E-R模型方法进行建模设计。

4.3.2 CDM/LDM/PDM模型转换设计

一、不同层次数据模型转换方案
在这里插入图片描述
二、CDM/LDM到PDM转换原理
CDM/LDM到PDM的转换其实就是E-R模型到关系模型的转换。

E-R模型到关系模型转换原理：

将每一个实体转换成一个关系表，实体属性转换为关系表的列，实体标识符转换为关系表的主键或外键。
将实体之间的联系转化为关系表之间的参照完整性约束。

例：概念数据模型中“学生”实体，转换为物理数据模型中“学生”表
在这里插入图片描述
三、弱实体转换关系表
非ID依赖：在弱实体转换的关系表中加入强实体标识符作为外键列。

ID依赖：在弱实体转换的关系表中加入强实体标识符作为外键列与主键列。

四、实体联系转换参照完整性约束
1.“1:1实体联系”转换表示
两种转换方案：

将学生表的主键“学号”放入助研金账号表中做外键；
将助研金账号表的主键“账号”放入学生表中做外键。
这两种方案均是可行的，由设计者根据应用需求自主做出选择。

2.“1:N实体联系”转换表示
转换方案：两个实体分别转换为关系表，然后将父实体关系表的主键****放入子实体关系表中做外键，便可将1:N实体联系转换为关系表参照完整性约束。

3.“M:N实体联系”转换表示
转换方案：M:N实体联系不能直接转换。需要创建一个新的关联表，该关联表分别参照原有实体对应的关系表。

在这里插入图片描述
将两个表的主键都放在新的表中做主键与外键。

五、实体继承联系转换参照完整性约束
在处理实体继承联系转换时，将父表中的主键放置到子表中，既做主键又做外键。
在这里插入图片描述
六、实体递归联系转换参照完整性约束
1.“1:N实体递归联系”的转换
转换方案：首先将递归实体转换为表，其属性转换为列，标识符转换为主键，同时还将标识符转换为外键，实现自己对自己的参照。
在这里插入图片描述
2.“M:N实体递归联系”的转换
转换方案：增加一个关联表，该表分别参照原实体对应的关系表，并对原关系表建立两个参照完整性约束。

七、系统数据库建模设计实例
1、图书借阅管理系统CDM
在这里插入图片描述
2、图书借阅管理系统LDM

3、图书借阅管理系统PDM

4.4 数据库规范化设计

一、为什么需要规范化数据库设计？

减少数据库中的冗余数据，尽量使同一数据在数据库中仅保存一份，有效降低维护数据一致性的工作量。
设计合理的表间依赖关系和约束关系，便于实现数据完整性和一致性。
设计合理的数据库结构，便于系统对数据高效访问处理。

二、非规范化关系表的数据操作问题
1、“雇员”关系表数据访问操作存在的异常

插入数据异常
删除数据异常
修改数据异常
2、不规范的关系表可能存在数据冗余，引出数据访问操作异常现象，难以使数据库保持数据的一致性。

4.4.1 函数依赖

一、函数依赖理论
函数依赖是数据依赖的一种，它反映属性或属性组之间相互依存、互相制约的关系，即反映现实世界的数据约束关系。

定义下列符号：R表示一个关系的模式，**U = {A1,A2,…,An}**是R的所有属性的集合，F 是R 中函数依赖的集合，r是R 所取的值，**t[X]**表示元组 t 在属性X上的取值。
（元组就是行）

二、函数依赖的定义
定义：设有一关系模式R（U），X和Y为其属性U的子集，设 t，s 是关系R中的任意两个元组，如果t [X] = s[X]，则t [Y] = s[Y]。那么称Y函数依赖于X，或X函数决定Y。也可称在关系模式R（U）上成立。

一个函数依赖要能成立，要求关系的任一可能值都能满足函数依赖条件。
在这里插入图片描述
三、部分函数依赖

四、属性传递依赖

XY一一对应意味着实际上是等价的，那么X决定Z，必有Y决定Z，所以不是传递。

五、多值依赖
在这里插入图片描述

4.4.2 关系规范化范式

一、关系规范化范式
关系规范化是把一个有访问异常的关系分解成结构良好的关系的过程，使得这些关系有最小的冗余或没有冗余。
规范化范式（NF）是指关系表符合特定规范化程度的模式。

1、第1范式（1NF）
如果关系表中的属性不可再细分，该关系满足第1范式。反之，该表就不是关系表。

2、第2范式（2NF）
如果关系满足第1范式，并消除了关系中的属性部分函数依赖，该关系满足第2范式。
例：有一个关系（A,B,N,O,P）,其复合主键为（A,B）,那么N,O,P这三个非键属性都不存在只依赖A或只依赖B情况，则该关系满足第2范式，反之，不满足第2范式。

3、第3范式（3NF）
如果关系满足第2范式，并切断了关系中的属性传递函数依赖，该关系满足第3范式。
例：若有一个关系（A,N,O,P）,主键为（A）,那么非键属性N,O或P都不能由单个的N,O或P或它们的组合所确定。该关系满足第3范式。

4、巴斯-科德范式（BCNF）
在关系中，所有函数依赖的决定因子都是候选键，该关系满足BCNF范式。

5、第4范式（4NF）
如果关系满足BCNF范式，并消除了多值函数依赖，该关系满足第4范式。

例：设学校中某一门课程由多个教师讲授，每个教师可有自己的参考书。用关系模式Teaching（Course，Teacher，Book）来表示课程、教师和参考书之间的关系。

该关系Teaching（Course，Teacher，Book），属于BCNF范式；但是存在多值函数依赖，即不满足4NF。

将原表进行分解处理，可分解为Teaching（TeachingID，CourseID，TeacherID，BookID）、Course（CourseID，CourseName）、 Teacher（TeacherID，TeacherName）、Book（BookID，BookName）后，即可消除多值依赖，便可满足4NF范式。

6、关系规范化程度利弊

关系的规范化程度依次提升： 1NF→ 2NF → 3NF→ BNCF → 4NF
关系的规范化程度越高，关系数据库存储的冗余数据就越少，可消除的数据访问异常就越多。
不过关系的规范化程度越高，分解出来的关系表就越多，但实现数据查询访问时，需关联多表，其效率降低。

二、关系规范化设计实例
在这里插入图片描述
1、本关系不满足1范式，因为“联系方式”属性可以再细分“电话”、“电子邮件”等。

在这里插入图片描述
2、

分析：
主键（学号，课程号）：
（学号）→系名，
（学号）→住址，
（学号）→电话，
（学号）→电子邮件，存在部分依赖，不满足第2范式。
处理办法：对学生关系进行分解，按“学生信息”、“课程成绩”主题撤分为两个关系表。

在这里插入图片描述
3、分析：在学生关系表中，
（学号） →系名，
（系名） →住址，
故（学号） →住址。存在传递函数依赖，不满足第3范式。
处理办法：对学生关系再次分解为“学生”、“系信息”关系。

4、“学生”、“系信息”、“课程成绩”关系均满足BCNF范式

5、
分析：一个系的学生住址可能有多处，办公电话也有多个，故“系信息”关系存在多值依赖，不满足第4范式。
处理办法：
对“系信息”关系进一步分解为“系编码”、“学生住址”、“电话目录”关系。
在这里插入图片描述
三、逆规范化处理
所谓逆规范化，就是适当降低规范化范式约束，不再要求一个关系表必须达到很高的规范化程度，而是允许适当的数据冗余性，以获取数据访问性能。