一、逻辑结构设计
1、数据库设计过程
在之前的博客中 讲解了 数据库设计过程 , 以及 概念设计 ( 概念结构设计 ) , 逻辑设计 ( 逻辑结构设计 ) ;
参考 【系统架构设计师】数据库系统 ③ ( 数据库设计过程 | 概念结构设计 | ER 图 简介 | 概念设计阶段 工作拆分 ) 博客 , 概念设计 阶段 绘制 ER 图 , 逻辑设计 阶段 , 将 ER 图 转为 关系模式 ;
关系模式 参考 【系统架构设计师】数据库系统 ④ ( 关系模型 | 数据模型 三要素 | 数据模型 种类 | 关系模型 的 表示形式 | 关系模型相关概念 | 完整性约束 | 触发器 ) 博客 , 关系模式 本质就是一张 二维表 , 也就是 数据库表 ;
2、逻辑结构设计 简介
逻辑结构设计 的 目标是将 概念结构设计 的 最终结果 - 概念模型 ( ER 图 ) 转化为 数据库 可实现的 逻辑模型 , 逻辑模型 是 关系模型 , 在进一步说就是 二维表 / 数据库表 ;
逻辑结构设计 阶段的输出结果 是 关系模型 , 涉及到的过程步骤如下图所示 :
逻辑结构设计 过程 :
- ① 数据模型转换 : ER 图 转为 关系模式 , 根据 规范化 理论 生成 关系模式 , 将 ER 图 中的实体、属性 和 联系 转化为 二维表结构 ;
- 实体转为关系 : 每个实体独立成表 , 主键保留 ;
- 联系转为关系 : 根据 联系类型 ( 1:1 , 1:n , m:n ) 生成新表 或 合并字段 ;
- ② 关系规范化 : 规范化 关系模式 , 通过 范式理论 优化表结构 , 消除冗余和异常 ;
- 1NF : 确保属性原子性 ;
- 2NF : 消除部分函数依赖 ;
- 3NF : 消除传递函数依赖
- ③ 模式优化 : 确定 完整性约束 , 为数据添加规则 , 确保一致性 , 对 关系模式 加上 完整性约束 , 确保数据的正确性 ;
- 实体完整性 : 主键非空且唯一 , 如 : 学号 是 学生实体 主键 ;
- 参照完整性 : 外键约束 , 如 : 选课.学号 必须存在于 学生.学号 ;
- 用户自定义完整性 : 用户 根据 业务需求 制定的规则 , 通常通过 检查约束 实现 , 确保数据符合实际业务逻辑 ;
- ④ 设计用户子模式 : 确定 用户视图 , 通过视图 控制 数据访问权限 和 简化操作 , 提高数据的 安全性 和 独立性 ;
- 基于数据流图 : 根据 数据流图 确定 处理过程 使用的 视图 ;
- 基于用户类别 : 根据 用户类别 确定 不同用户 使用的 视图 ;
- 应用程序设计 ( 不属于逻辑结构设计阶段 ) : 逻辑结构设计完毕后 , 数据库表创建完毕 , 此时可以 根据 逻辑结构 设计 应用程序 中的 交互界面 和 功能模块 ;
二、ER 图 转为 关系模式
1、ER 图 转为 关系模式 概述
将 ER 图 中的 实体、属性 和 联系 转化为 二维表结构 , 二维表结构 就是 关系模式 , 也就是 数据库表 ;
- 实体 转 关系模式 : 每个 实体模型 必须 直接 转为一个 独立的 关系模式 ( 数据库表 ) , 实体 的 属性 转换为表的列 ;
- 联系 转 关系模式 : 将 " 1:1、1:N、M:N " 三种联系 转为 不同的 关系模式 ;
- 1:1 或 1:N ➔ 合并到实体表中 ;
- M:N ➔ 新建独立表 ;
2、实体 转 关系模式
实体 转 关系模式 : 每个实体模型 必须 直接 转为一个 独立的 关系模式 ( 数据库表 ) ;
- 属性处理 : 实体 的 属性 转换为表的列 ;
- 主键设置 : 数据库表 ( 关系模式 ) 的 主键 需明确标识 , 通常选择唯一标识实体的属性 , 如 : 学号、身份证号 ;
以 " 学生 " 实体为例 , 学生实体 有如下 4 个属性 : " 学号、姓名、年龄、专业 " ;
将 上述 学生 实体 转为 数据库表 ( 关系模式 ) 后的结构为 :
学生表 ( 学号 , 姓名 , 年龄 , 专业 )
- 1
- 主键 为 " 学号 " ;
三、联系 转 关系模式
联系 转 关系模式 : 将 " 1:1、1:N、M:N " 三种联系 转为 不同的 关系模式 , 有以下 2 种转换方法 :
- 并入实体 ( 归并关系模式 ) : 1:1 或 1:N ➔ 合并到实体表中 ;
- 独立关系 ( 独立关系模式 ) : M:N ➔ 新建独立表 ;
1、并入实体
并入实体 就是 并入实体表 , 将联系的信息直接合并到实体表中 ,
避免冗余表结构 , 提高查询效率 ,
适用于 1:1 ( 一对一 ) 或 1:N ( 一对多 ) 联系 转为 关系模式 的 场景 ;
1:1 ( 一对一 ) 联系 转为关系模式
1:1 ( 一对一 ) 联系 转为关系模式 :
- 两个 一对一 的 实体 , 任意一个实体 可 合并到 另一方实体表 中 , 通常选择 查询频率更高 的一方 ;
- 需添加 对方实体 的 主键 作为外键 , 并包含 联系 本身的 属性 ( 可选 ) ;
示例说明 :
- 给出两个实体 : 员工表（工号、姓名）与 工位表（工位号、位置） ;
- 员工表 与 工位表 是 1:1 ( 一对一 ) 联系 , 联系 本身属性 是 工位分配日期 ;
- 将 工位实体 并入 员工表 , 工位表保持不变 , 得到如下数据库表 , 其中 工号 是 员工表 主键 , 工位号 是 引用的 工位表 的 外键 ;
员工表 ( 工号 , 姓名 , 工位号 , 工位分配日期 )
工位表（工位号、位置）
- 1
- 2
- 将 员工实体 并入 工位表 , 员工表保持不变 , 得到如下数据库表 , 其中 工位号 是 工位表 主键 , 工号 是 引用的 员工表 的 外键 ;
员工表（工号、姓名）
工位表 ( 工位号 , 位置 , 工号 , 工位分配日期 )
- 1
- 2
1:N ( 一对多 ) 联系 转为关系模式
1:N ( 一对多 ) 联系 转为关系模式 :
- " 1 方 对应的 实体 “ 必须 合并到 ” 多方 对应的 实体 " 表 中 ;
- " 多方 对应的 实体 “ 表 中 需添加 ” 1 方 对应的 实体 " 的 主键 作为外键 , 并包含 联系 本身的 属性 ( 可选 ) ;
示例说明 :
- 给出两个实体 : 班级表 ( 班级号 , 班级名称 ) 与 学生表（ 学号 , 姓名） ;
- 班级表 与 学生表 是 1:N ( 一对多 ) 联系 , 联系 本身属性 是 学生分班日期 ;
- 转换方式 : 将 " 班级 " 实体 并入 学生表 , 班级 是 " 1 方 对应的 实体 " , 学生 是 " 多方 对应的 实体 " ;
学生表（ 学号 , 姓名 , 班级号 , 分班日期 ）
班级表 ( 班级号 , 班级名称 )
- 1
- 2
2、独立关系
独立关系 就是 独立关系模式 , 也就是 新建独立表 , 通过 独立建表 记录多方关联关系 , 确保数据完整性和查询灵活性 ;
- 必须新建独立表 ;
- 双方实体的主键作为联合主键 ;
- 包含 联系 本身的 属性 ( 如果有 ) ;
M:N ( 多对多 ) 联系 转为关系模式
示例说明 :
- 给出两个实体 : 学生表（ 学号 , 姓名） 和 课程表 ( 课程号 , 课程名 ) ;
- 联系分析 : 学生表 与 课程表 是 M:N ( 多对多 ) 联系 , 一个学生选修多个课程 , 一个课程被多个学生选修 , 联系 本身属性 是 选课日期 ;
- 转换方式 : 新建独立表 选课表 , 使用 学号 和 课程号 作为 联合主键 , 此处有 联系本身的属性 选课日期 , 也添加到 新建表 中 ; 学生表 和 课程表不变 ;
学生表（ 学号 , 姓名）
课程表 ( 课程号 , 课程名 )
选课表 ( 学号 , 课程号 , 选课日期 )
- 1
- 2
- 3
特别注意 - 独立关系模式 ( 新建独立表 ) 适用于所有联系转换
独立关系 ( 独立关系模式 / 新建独立表 ) 的 方式 , 也可以用于 1:1 ( 一对一 ) 联系 转为关系模式 和 1:N ( 一对多 ) 联系 转为关系模式 , 但是 会产生数据冗余 , 不推荐这样使用 ;
四、软考考点
1、关系模式个数计算 - 三元多对多联系
下面是 概念结构设计 中的 A、B、C 三个实体的 ER 图 , 三个实体之间的 存在 互相的 m:n:p 的 多对多 联系 ;
首先 , 将 实体 转换为 独立关系模式 , 每个 实体 直接映射为一个 关系模式 ( 数据库表 ) , 表中包含 实体 所有属性 , 主键保持不变 ; 实体 转换的 3 个 独立关系模式 如下所示 :
A ( A_id , 属性1 , 属性2 , … )
B ( B_id , 属性1 , 属性2 , … )
C ( C_id , 属性1 , 属性2 , … )
- 1
- 2
- 3
然后 , 处理 三元多对多联系 , 将 三个实体 之间的 m:n:p 联系 转换为 独立的关系模式 ,
R_ABC ( A_id , B_id , C_id , 属性1 , 属性2 , … )
- 1
- 上述 关系模式 的 主键 是
( A_id , B_id , C_id )联合主键 ;
最终 , 得到 4 个关系模式 :
A ( A_id , 属性1 , 属性2 , … )
B ( B_id , 属性1 , 属性2 , … )
C ( C_id , 属性1 , 属性2 , … )
R_ABC ( A_id , B_id , C_id , 属性1 , 属性2 , … )
- 1
- 2
- 3
- 4
2、数据库表分析
项目管理 数据库 关系模式 :
供应商 ( 供应商号 , 名称 , 地址 , 电话 , 账号 )
项目 ( 项目号 , 负责人 , 开工日期 )
零件 ( 零件号 , 名称 , 规格 , 单价 )
供应 ( 项目号 , 零件号 , 供应商号 , 供应量 )
员工 ( 员工号 , 姓名 , 性别 , 出生日期 , 职位 , 联系方式 )
- 1
- 2
- 3
- 4
- 5
① 三元多对多关系分析 :
分析 " 供应 " 关系 对应的 数据库表 , 按照常理进行分析 ;
- 一个项目 对应 多个零件 , 多个 供应商 ;
- 一个项目 要使用 多个零件 ;
- 一个项目 要从多个供应商采购 零件 ;
- 一个零件 对应 多个项目 , 多个 供应商 ;
- 一个零件 可能在 多个项目中使用 , 如 : 水泥 , 钢筋 ;
- 一个零件 需要从多个 供应商 采购 , 防止出现 断供 涨价 等 风险 ;
- 一个供应商 对应 多个项目 , 多个 零件 ;
- 一个供应商 可以 向多个项目 出售零件 ;
- 一个供应商 可以 出售多种零件 ;
因此 , 供应关系 是 3 个实体之间的 m:n:p 多对多关系 , 这是一个 三元多对多关系 ;
② 分析 员工 和 项目 之间的关系 :
一个项目 可以有 多个员工 参加 , 一个员工 同一时间 可参加多个项目 ;
此时 员工 与 项目 是 m:n 多对多联系 ;
③ m:n 多对多联系 转换 关系模式
员工 和 项目 之间的关系 是 m:n 多对多联系 , 如果将该 联系 转为 关系模式 , 必须采用 独立关系模式 , 也就是 新建独立表 ;
使用 员工号 和 项目号 作为 联合主键 ;
评论记录：
回复评论：