4.1 数据库设计概述

4.1.1 数据库设计方案

• 数据库应用架构设计：在不同应用需求场景中，数据库的应用架构方式是不同的。数据库应用架构可分为单用户结构、集中式结构、客户／服务器结构和分布式结构（这个跟第一章总论中介绍的是一样的）

• 数据库结构模型设计：数据库结构模型设计一般分为概念层、逻辑层、物理层设计，它们的设计模型分别为概念数据模型、逻辑数据模型和物理数据模型（想想作业三）。

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

4.1.2 数据库结构模型

• 概念数据模型概念：概念数据模型（Concept Data Model，CDM）是一种面向用户的系统数据模型，它用来描述现实世界的系统概念化数据结构。使数据库设计人员在系统设计的初始阶段，摆脱计算机系统及DBMS的具体技术问题，集中精力分析业务数据以及数据之间的联系等，描述系统的数据对象及其组成关系。

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

• 物理数据模型概念：物理数据模型（Physical Data Model，PDM）是在逻辑数据模型基础上，针对具体DBMS所设计的数据模型。它用于描述系统数据模型在具体DBMS中的数据对象组织、存储方式、索引方式、访问路径等实现信息。
各个数据模型之间的关系如下：



image-20240517152412164
可以发现概念数据模型和逻辑数据模型都是与具体的DBMS无关的

4.1.3 数据库开发过程及设计策略

• 数据库开发过程
如下图：



image-20240517150956630
实际上还是软工那一套，只不过这里说的是开发，所以将数据库维护去掉了。并且将数据库设计讲得更细了
下面就是开始逐一介绍各个阶段要干的事情（在第一章中也提到了，要背的话也只需要去背第一章的），感觉瞎编就行了（这里的真没必要背吧）
• 数据需求分析阶段
• 从现实业务获取数据表单、报表、查询、业务规则、数据更新的说明
• 分析系统的数据特征、数据类型、数据取值约束
• 描述系统的数据关系、数据处理要求
• 建立系统的数据字典
• 数据库设计阶段
• 数据库模型结构设计（概念数据模型、逻辑数据模型、物理数据模型）
• 数据库索引、视图、查询设计
• 数据库表约束设计
• 数据库触发器、存储过程设计
• 数据库实现阶段
• 数据库创建
• 数据模型物理实现
• 数据库测试阶段
• 数据库数据上线
• 数据库系统测试

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

4.1.4 主流数据库建模工具Power Designer

• Power Designer的数据建模工具特点：
• 功能强大的软件开发生命周期建模工具
• 支持目前主流的数据库管理系统（如Oracle、SYBASE、 SQL Server、DB2、MySQL、PostgreSQL等）
• 支持目前多种客户端开发工具（如PB、VB、VC、Delphi等）
• 满足大、中、小型数据库建模设计

4.2 E-R模型方法

4.2.1 E-R模型概念

• E-R模型概念：E-R模型是“实体-联系模型”（Entity-Relationship Model）的简称。它是一种描述现实世界概念数据模型、逻辑数据模型的有效方法（ER模型不描述物理数据模型）

4.2.2 E-R模型的基本元素

• 实体：实体(Entity)是指问题域中存在的人、事、物、地点等客观事物在逻辑层面的数据抽象。它用于描述事物的数据对象，如客户、交易、产品、订单等。

• 属性：属性是指描述实体特征的数据项。每个实体都具有1个或多个属性（跟关系中的属性应该是一样的）。

• 标识符：标识符是指标识不同实体实例的属性。标识符可以是1个或多个属性（是一个逻辑上的键）
在后面也说道了：标识符与主键的区别是标识符是一个逻辑概念，主键是物理概念。

• 联系(Relationship)是指实体之间的联系，如“学生”与“成绩”的联系、“孩子”与“父亲”、“母亲”的联系等（需要注意这里是联系不是关系）。
• 联系度数：联系中关联的实体数目称为联系度数（实际上就是几元联系）。如下：



image-20240517153849009
二元联系的联系度数就是2（因为关联两个实体）。。。

4.2.3 实体联系类型

• 实体联系的类型
• 1对1（1:1）
• 1对多（1:N）
• 多对多（M:N）
在一般的版本中数量关系的体现就是直接在关系线上写上基数。

• 基数：实体联系的类型中的数量就是基数（基数用于描述实体之间的数量关系）
• 最小基数：描述了一个实体在关系中至少可以有多少个实例。例如，如果一个学生至少要选修一门课程，那么学生和课程之间的关系的最小基数就是1。
• 最大基数：描述了一个实体在关系中最多可以有多少个实例。例如，如果一个学生最多可以选修五门课程，那么学生和课程之间的关系的最大基数就是5

• 强制与可选（就是能不能为空的概念，或者说这个实体的实例数量在关系中能不能是0）
强制与可选在ER模型上的符号表示方式：



image-20240517154727665
强制就是一道杠，而可选就是一个小圆圈（这个都没用过，要特别记一下）
这样通过强制和可选以及基数，就能实现任意数量的实体关系：



image-20240517155213037
需要注意的是最小基数和最大基数都是对同一实体而言的

• 鸟足版本的ER符号表示
如下图：



image-20240517154833287
可以发现这里跟一般版本的区别只有两个：一是基数直接使用鸟足表示（多个就岔开，单个就不岔开），二是关系的名称是直接写在关系线上了，而不是在一个菱形中

4.2.4 实体继承联系

• 继承联系：在实体继承联系中，一端是具有公共属性的实体，称为父实体；另一端是与父实体具有相似属性，同时也具有特殊性的一个或多个实体，称为子实体（就是正常的继承）。
继承联系表示如下：



image-20240517155740061
这里有一个小半圆，并且指向的是父实体（这个应该是一般版本的图）

• 继承联系的类型
• 互斥性继承：子类不相交
如下图：



image-20240517160005112
这里的个人账户和公司账户就是不相交的。需要注意的是互斥性继承需要在小半圆中打一个叉，但是非互斥性继承就不需要（所以可以发现正常的继承应该是非完整非互斥的）
• 非互斥性继承：子类相交
如下图：



image-20240517160044924
这里教师可能也是干部，所以子类是相交的
• 完整继承：子类取并集得到父类
如下图：



image-20240517160149422
男人和女人合起来就构成了人，所以是一个完整继承
需要注意的是完整继承需要在小半圆下面加上一个小矩形，但是非完整继承不需要
• 非完整继承：子类取并得不到父类
如下图：



image-20240517160404832
因为学生还有小学生啥的

4.2.5 强弱实体联系

• 弱实体：弱实体是指那些对于另外实体有依赖关系的实体，即一个实体的存在必须以另一实体的存在为前提。

• 强实体：被弱实体依赖的实体称为强实体
关于强弱实体的区分，这个应该是比较主观并且跟具体的业务逻辑有关系。需要判断的时候就正常使用定义来判断就好了——强实体不存在的话，弱实体就没有存在的必要

• 弱实体的特点
• 弱实体没有足够的属性标识自己
• 弱实体的标识符通常是由部分标识符（弱实体自己的标识符）和强实体标识符组合而成（隐含的意思就是弱实体只有加上了主实体的标识符才能进行区别）
• 弱实体的生命周期与强实体相关联

• 弱实体的分类
• 标识符（ID）依赖弱实体：如果弱实体的标识符中含有所依赖实体的标识符，则该弱实体称为标识符（ID）依赖弱实体（用一个不太正确的说法来解释这个定义——也就是弱实体的主键中含有强实体的主键，或者说需要额外再根据强实体的标识符才能区分弱实体）。
• 非标识符（非ID）依赖弱实体：拥有自己的标识符的弱实体即为非标识符（ID）依赖弱实体（也就是有自己的主键了。这个时候就几乎跟强实体没有什么区别，只不过在逻辑上这个实体仍然是依赖于一个强实体存在的）
但是讲道理在cal的ppt中没有提到标识符依赖弱实体和非标识符依赖弱实体。cal的ppt中认为弱实体就一定是这里说的标识符依赖弱实体。这样其实也是合理的，因为非标识符依赖弱实体确实就跟强实体没有什么区别了。但是无论如何，标识符依赖弱实体一定是一个弱实体。
在cal的ppt中还提到了两个概念：
• 识别实体型与识别联系：假如联系R关联弱实体A和强实体B，A的弱实体可以通过与实体B相结合来加以区别，则B称为弱实体A的识别实体（在cal的ppt中实际上就是强实体是弱实体的识别实体），R称为弱 实体A的识别联系（依赖关系就一定是识别关系）
下面给出一个关于判断强弱实体的题：



image-20240517192420260
这里是标识符弱实体而不是非标识符弱实体是因为单单根据商品编号是没有办法将这个弱实体和其他的弱实体区分开的，这个时候就需要让弱实体的标识符包含强实体的标识符，才能区分这个弱实体。所以这个是一个标识符依赖弱实体。（需要注意一下这里不是鸟足了，而是三根短线）



image-20240517192621477
这里是一个非标识符依赖弱实体是因为这里只需要根据一个处方编号就能区分这个弱实体了，所以这个弱实体是一个非标识符依赖弱实体。（同样需要注意这里就是正常的鸟足表示。所以可以发现实际上所有的依赖关系默认应该都是一个非标识符依赖，所以非标识符依赖弱实体确实跟强实体几乎没有区别，只是语义上或者业务上他是依赖于强实体的。所以弱实体的判断就只能根据题目来主观判断了）
我感觉这里有一句话说的很好：

强弱是相对于其它实体而言的，某个实体（A实体）可能对于B实体而言是强实体，对于C实体而言是弱实体，在一个关系中非强即弱。

所以强弱实体的判断确实是相对的，比较主观的

4.3 数据库建模设计

4.3.1 概念数据模型设计

• 概念数据模型设计概念：概念数据模型设计是通过对现实世界中数据实体进行抽取、分类、聚集和概括等处理，建立反映系统业务数据组成结构的过程。（也就是建立概念数据模型的过程了。一般是采用ER模型设计）

• 概念数据模型设计步骤（这玩意应该不用背吧）
• 业务数据分析，抽取数据实体
• 定义实体属性及其标识
• 建立实体联系，构建局部E-R模型图
• 分类、聚集和概括各个部分E-R模型图
• 完善全局E-R模型图，建立系统业务数据组成结构
需要注意的就是将局部ER图合成全局ER图的时候需要有一些额外要注意的。下面进行简要的介绍

• 局部ER图合并
合并的一般步骤如下：
• 消除冲突
常见的冲突如下：
• 命名冲突: 包括同名异义或异名同义等。
• 属性冲突: 包括属性的数据类型、取值范围等。
• 结构冲突：如一个字段在可能在一个局部ER图中是一个实体，在另一个ER图中又是一个属性，这个时候就需要进行统一的处理
• 确定公共实体（这个是合并局部ER图的关键）
• 消除冗余
• 实体和联系尽量减少 1 : 1 联系的或具有相同键的两个实体集根据实际情况可以合并。如 职工和工资。
• 属性尽量减少：去除冗余的属性（也就是去除函数依赖的属性）

4.4 数据库规范化设计

4.4.1 规范化数据库设计的必要性

• 减少数据库中的冗余数据，尽量使同一数据在数据库中仅保存一份，有效降低维护数据一致性的工作量

• 避免数据丢失
关于数据冗余冲突以及丢失，给出一些例子：



image-20240517202607558
出现了数据冲突（因为产品部的地点不一致）和数据冗余（部门地址是冗余信息）



image-20240517202653470
出现了数据丢失
• 出现冗余数据、数据冲突和数据丢失主要是因为出现了数据依赖（指通过关系模式某些属性的取值能够决定另一些属性的取值。这种决定关系是由现实决定的），数据依赖的类型如下（后面都会介绍的）：
• 函数依赖
• 多值依赖
• 连接依赖

• 设计合理的表间依赖关系和约束关系，便于实现数据完整性和一致性（实际上如果出现了数据的冗余就很难再保证数据的一致性了，进而就很难保证数据不出现冲突）。

• 设计合理的数据库结构，便于系统对数据高效访问处理

4.4.2 函数依赖

• 函数依赖的概念：函数依赖（Functional Dependency)是数据依赖的一种，它反映属性或属性组之间相互依存、互相制约的关系，即反映现实世界的数据约束关系（就是一个属性在现实中就是能决定另一个属性）

• 函数依赖的定义：设有一关系模式R（U），X和Y为其属性U的子集，设t，s是关系R中的任意两个元组，如果t [X] = s[X]，则t [Y] = s[Y]。那么称Y函数依赖于X，或X函数决定Y。也可称 在关系模式R（U）上成立。
这里再给出另一种定义：定义：设X、Y是关系表R的属性（组），如果对于R的所有元组都有：X的每一具体值都只有一个Y的值与之对应，则称X函数决定Y，或Y函数依赖于X，记作X->Y。
疑问候选键是不是函数依赖于主键？copilot说不是函数依赖，但是我觉得是函数依赖
说明白一点就是通过一组属性可以导出另一组属性，如人的名字就是函数依赖于人的身份证号的，这个是语义上的一种依赖，并不是只对当前关系表中已有数据成立的。所以在建模的时候如果出现了一对一或者一对多的关系，就一定存在函数依赖
• 决定因子与依赖因子：Y函数依赖于X时，就将X称为决定因子，Y称为依赖因子

• 函数依赖的类型
• 平凡函数依赖和非平凡函数依赖定义：设X、Y是关系表R的属性（组），且X-> Y， 若Y包含于X，则称为平凡依赖，否则称为非平凡依赖
如（学号，姓名）->姓名，而姓名包含于（学号，姓名），这就是一个平凡依赖
• 完全函数依赖和部分函数依赖定义：设X、Y是关系表R的属性（组），且X->Y，若X存在某个子集 X1，使X1->Y成立，则称Y部分依赖于X，否则称Y完全依赖于X。
如 （学号，姓名）->班号，而学号->班号，因此，班号部分依赖于（学号，姓名）。
• 传递函数依赖和非传递函数依赖定义：设X、Y、Z是关系表R的属性（组），若X->Y，Y->Z，且Y不决定X，Y不属于X，则称X传递决定Z，或Z传递依赖于X，否则称Z非传递依赖于X 。
如学号->班号，班号->学院，因此，学院传递依赖于学号，或学号传递决定学院
传递依赖在第三范式的判定中还需要使用到，这里Y不决定X实际上就限定了Y不能是候选键，必须是一个普通的属性组。并且如果没有要求Y不决定X实际上传递依赖就退化为了函数依赖

• Armstrong公理系统：为从已知的函数依赖推导出其他的函数依赖，Armstrong提出了一 套推理规则，称为Armstrong公理
Armstrong公理如下图（这个只要看看就好了，稍微有点影响就好，说不定啥时候判断函数依赖的时候有奇用）：



image-20240517210801855

4.4.3 多值依赖

• 多值依赖的定义：设 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（跟函数依赖的不同点就是并不是一个取值x确定一个取值y，而是确定一组取值Y。并且多值依赖也是一种语义上的依赖关系）

• 多值依赖的性质
如下图：



image-20240517212003511

• 函数依赖和多值依赖的区别
• 函数依赖出现在一对一、多对一的关系上，而多值依赖出现在一对多、多对多的关系上
• 函数依赖与关系模式中剩余的属性组无关，而多值依赖需要判断依赖因子是否与剩余的属性组有关（最简单的判断方法就是尝试给剩余的属性组添加一条可能的属性，然后想想是否会影响依赖因子的取值。比如之前的教材教师的例子，显然增加一本教材并不会影响教师的取值）

4.4.4 连接依赖

• 连接依赖的定义：设U是关系模式R的属性集，X1、…、Xn是U的子集，并且U= X1∪X2∪…∪Xn， 对于R的任一关系r，都有r为其在各Xi(1=1,…,n)上的投影的自然连接； 即r=πX1(r)⨝πX2 (r)⨝…⨝πXn (r) ，则称R满足连接依赖（Join Dependency， JD），记为⨝(X1 ,…,Xn )。
通俗地讲，如果将关系模式R按照某种方式，分解为n个属性集为X1、…、Xn的 子模式，R的任意关系r分别在这n个子模式属性上投影生成n个关系集合，然后可以通过对n个投影结果进行自然连接后还原生成同样的r，则称R满足连接依赖。
连接依赖的判定比较麻烦也比较难懂，这里给一个示例（这玩意怕是考不了一点）：



image-20240518095319816

4.4.5 关系规范化范式

• 关系规范化的概念：关系规范化是把一个有访问异常的关系分解成结构良好的关系的过程，使得这些关系有最小的冗余或没有冗余。

• 规范化范式的概念：规范化范式（Normal Form，NF）是指关系表符合特定规范化程度的模式。

• 第1范式（1NF）：如果关系表中的属性不可再细分，该关系满足第1范式。反之，该表就不是关系表（也就是一个单元格中只有一条数据，这个是关系的一个特点）

• 第2范式（2NF）：如果关系表R满足1NF，且所有非主属性都完全依赖于任一候选键，或者说R中不存在非主属性对键的部分函数依赖（就相当于是对键做了最小化处理了），则称R满足第二范式，记作R∈2NF（非主属性是指不是候选键部分的属性。可以看出如果是第2范式就一定是第1范式。并且可以看出第二范式是对键的要求，所以这个时候还允许非主属性之间的的完全函数依赖，这也正是第三范式要消除的）
如果出现部分函数依赖的话就需要去额外建表了，比如说一个键有1、2两个属性组，那么非主属性完全函数依赖于1的就归到以1为主键的一张表上，完全函数依赖于2的就归到以2为主键的那一张表上，完全函数依赖于1、2的就归到以1、2为主键的那一张表上，并且通过外键将这几张表连接起来

• 第3范式（3NF）：如果关系表R满足2NF（疑问calppt上为什么说是满足第一范式？他实际操作的时候也是先将第一范式转化为第二范式），且所有非主属性都非传递依赖于R的任一候选键，则称R满足第三范式，记作R∈3NF（即关系中不存在非主属性对键的函数依赖了。再换句话说，这个时候就不能有非主属性之间的函数依赖了）。
• 推论：若R不存在非主属性，则一定满足3NF（都没有非主属性怎么可能有非主属性之间的函数依赖）。
将第2范式转化为第3范式时就是根据中间属性将一张表分解为两张表，如那个学号、班号、学院的例子。这里就是要根据中间属性班号将这一张表格分解为学号、班号关系以及班号学院关系（如果需要的话甚至可以加上中间属性的编号，比如这里的班号）

• 巴斯-科德范式（BCNF）：在关系中，所有函数依赖的决定因子都是候选键，该关系满足BCNF范式（即R中不存在主属性对键的传递函数依赖或部分依赖。也就是有可能一个候选键的部分属性就能决定另一个候选键。相当于是将第2范式和第3范式的原则不仅仅应用在非主属性上，还用在了主属性上）。
关于BCNF的构建：首先先要将关系修改为第3范式，然后如果满足3NF，则将部分依赖的主属性和它所依赖的主属性构成新表；然后将左端的候选键构成新表。其实思路跟修改成第二范式的时候是差不多的，也是将部分依赖的部分构建成一张新表，只不过这里另一张表就是候选键表（也就是函数依赖中的决定因子属性组构成的关系）
后面的范式应该就稍微了解就好了

• 第4范式（4NF）：如果关系表R满足第一范式，且R的任一非平凡的多值依赖X->-> Y（X不包含Y），X含有候选键，则称R满足第四范式，记作R∈4NF。
关于4NF的构建：这也是比较自然的，因为多值依赖就是有一组属性跟另一组属性完全无关，这个时候只需要不让这两组属性在同一个关系表中出现就好了。如下图（因为ZY无关所以就没有ZY表了）：



image-20240518094925195

• 第5范式（5NF）：若对于R的每一JD: ⨝(X1 ,…,Xn )，要么是平凡连接依赖，要么每个Xi包含R的候选 键，则称R∈5NF，或称投影连接范式（Project-Join NF，PJNF）（JD是连接依赖的意思）。上面的讲连接依赖的那个例子就不是一个第五范式，因为存在一个连接依赖SPJ = SP⨝PJ⨝JS但他不是平凡连接依赖，并且SP、PJ、JS都不包含候选键SPJ
第五范式一定是一个第四范式是因为第五范式甚至已经要求了所有的非平凡连接依赖中的投影属性组都必须含有候选键，就几乎是要求所有的子模式一定包含候选键（就先这样简单理解吧），而第四范式要求的是所有非平凡多值依赖的决定因子中含有候选键，而决定因子又一定是一个子模式，所以按照第5范式的要求，决定因子中一定存在候选键，所以第五范式一定是一个第四范式
如何在构建一个第5范式就一定是没有要求了，calppt上都没有提到

• 关系规范化程度利弊
• 利：关系的规范化程度越高，关系数据库存储的冗余数据就越少，可消除的数据访问异常就越多。
• 弊：关系的规范化程度越高，分解出来的关系表就越多，但实现数据查询访问时，需关联多表，其效率降低。