4.1 数据库设计概述

4.1.1 数据库设计方案

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

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

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

4.1.2 数据库结构模型

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

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

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

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

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

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

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

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

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

4.2 E-R模型方法

4.2.1 E-R模型概念

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

4.2.2 E-R模型的基本元素

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

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

• 标识符：标识符是指标识不同实体实例的属性。标识符可以是1个或多个属性（是一个逻辑上的键）。

• 联系(Relationship)是指实体之间的联系，如“学生”与“成绩”的联系、“孩子”与“父亲”、“母亲”的联系等（需要注意这里是联系不是关系）。

4.2.3 实体联系类型

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



上述实体之间的联系反映了一个给定实体有多少实例与另一实体实例存在的数量对应关系。通常采用术语基数（Cardinality）来表示。



在实体之间除了需要反映了数量对应关系，有时还需要反映实体参与关系的必要性，即可选（optional）或强制（mandatory）。（必要性也用方形表示）

• 鸟足版本的实体-联系符号表示

• 可选为圆圈，强制为横线

• 基数直接写在横线上/鸟足表示

4.2.4 实体继承联系

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

• 继承联系的类型
• 互斥性继承联系：子类不相交
• 非互斥性继承联系：子类相交
• 完整继承：子类取并集得到父类
• 非完整继承：子类取并得不到父类

4.2.5 强弱实体联系

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

• 强实体：被弱实体依赖的实体称为强实体
关于强弱实体的区分，这个应该是比较主观并且跟具体的业务逻辑有关系。需要判断的时候就正常使用定义来判断就好了——强实体不存在的话，弱实体就没有存在的必要。
一、无论强实体还是弱实体，只是在后期向物理模型（关系模型）转换时处理上有不同。 二、强弱是相对于其它实体而言的，某个实体（A实体）可能对于B实体而言是强实体，对于C实体而言是弱实体，在一个关系中非强即弱。

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

• 弱实体的分类
• 标识符（ID）依赖弱实体：如果弱实体的标识符中含有所依赖实体的标识符，则该弱实体称为标识符（ID）依赖弱实体（用一个不太正确的说法来解释这个定义——也就是弱实体的主键中含有强实体的主键，或者说需要额外再根据强实体的标识符才能区分弱实体）。
• 三角形。



• 非标识符（非ID）依赖弱实体：拥有自己的标识符的弱实体即为非标识符（ID）依赖弱实体（也就是有自己的主键了。这个时候就几乎跟强实体没有什么区别，只不过在逻辑上这个实体仍然是依赖于一个强实体存在的）

4.3 数据库建模设计

4.3.1 概念数据模型设计

• 概念数据模型设计步骤（这玩意应该不用背吧）
• 业务数据分析，抽取数据实体
• 定义实体属性及其标识



• 建立实体联系，构建局部E-R模型图





注意：联系要写在横线上
• 分类、聚集和概括各个部分E-R模型图
• 完善全局E-R模型图，建立系统业务数据组成结构



需要注意的就是将局部ER图合成全局ER图的时候需要有一些额外要注意的。下面进行简要的介绍

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

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表了）：
• 第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上都没有提到
• 关系规范化程度利弊
• 利：关系的规范化程度越高，关系数据库存储的冗余数据就越少，可消除的数据访问异常就越多。
• 弊：关系的规范化程度越高，分解出来的关系表就越多，但实现数据查询访问时，需关联多表，其效率降低。

设计题

2.范式判断

• 第一步：求候选键

• 第二步：非键属性是否部分依赖候选键
• 否→至少是2NF
• 是→1NF

• 第三步：非键属性是否有传递依赖于候选键
• 否→至少3NF
• 是→2NF

• 第四步：判断所有依赖项左边是否全为候选键
• Y→BCNF
• N→3NF

规范化设计过程及修改后的PDM（满足4NF）

原始PDM存在的问题

1. 多值依赖：
• 一个运动项目（SportName）可能关联多个运动员（player）和多个裁判（referee）。
• 原始表中将这些多值属性直接存储，导致数据冗余和更新异常。

2. 函数依赖：
• SportName → colleaguename, dtime, location
• player → colleaguename（假设运动员姓名唯一）
• referee未明确依赖关系。

规范化步骤

1. 第一范式（1NF）

• 拆分多值属性：
• 运动员和裁判信息分别存储到独立表中，并通过关联表建立关系。

• Sport（运动项目表）：
• SportName (PK)
• colleaguename
• dtime
• location

• Player（运动员表）：
• PlayerID (PK)
• PlayerName

• Referee（裁判表）：
• RefereeID (PK)
• RefereeName

• Sport_Player（项目-运动员关联表）：
• SportName (FK)
• PlayerID (FK)
• 复合主键：(SportName, PlayerID)

• Sport_Referee（项目-裁判关联表）：
• SportName (FK)
• RefereeID (FK)
• 复合主键：(SportName, RefereeID)

2. 第二范式（2NF）

• 原始表分析：
• Sport表的主键为SportName，所有非主属性（colleaguename, dtime, location）完全依赖于主键，已满足2NF。
• 关联表（Sport_Player, Sport_Referee）的复合主键无部分依赖问题。

3. 第三范式（3NF）

• Player表的传递依赖：
• 原始Player表中存在PlayerID → PlayerName → colleaguename的传递依赖。
• 拆分为：
• Player表：
• PlayerID (PK)
• PlayerName
• Player_College表：
• PlayerName (FK)
• colleaguename

• Referee表（假设裁判无其他属性，直接保留）。

4. 第四范式（4NF）

• 原始问题：
• SportName →→ player 和 SportName →→ referee 是多值依赖。

• 解决方案：
• 已通过关联表（Sport_Player, Sport_Referee）拆分多值属性，每个关联表仅包含两个属性的组合，满足4NF。

修改后的PDM（4NF）

1. Sport（运动项目表）

字段名	类型	约束
SportName	character(64)	PK
colleaguename	character(64)	ㅤ
dtime	date&time	ㅤ
location	character(64)	ㅤ

2. Player（运动员表）

字段名	类型	约束
PlayerID	integer	PK
PlayerName	character(64)	ㅤ

3. Player_College（运动员-学院表）

字段名	类型	约束
PlayerName	character(64)	FK
colleaguename	character(64)	ㅤ

4. Referee（裁判表）

字段名	类型	约束
RefereeID	integer	PK
RefereeName	character(64)	ㅤ

5. Sport_Player（项目-运动员关联表）

字段名	类型	约束
SportName	character(64)	FK
PlayerID	integer	FK
复合主键：(SportName, PlayerID)	ㅤ	ㅤ

6. Sport_Referee（项目-裁判关联表）

字段名	类型	约束
SportName	character(64)	FK
RefereeID	integer	FK
复合主键：(SportName, RefereeID)	ㅤ	ㅤ

总结

• 规范化结果：
• 通过拆分多值属性和消除传递依赖，所有表均满足4NF。
• 数据冗余减少，更新异常（如插入、删除、修改异常）被消除。

• 验证4NF：
• 所有表中不存在非平凡多值依赖，每个关联表仅表示两个属性间的多对多关系。

• 优化点：
• 如果colleaguename与运动项目直接相关（而非运动员），需调整Sport表的依赖关系。
• 使用唯一标识符（如PlayerID、RefereeID）避免重名问题。

• 关系视图：
• 表之间的外键关系以箭头连接。