【系统架构设计师】数据库系统 ③ ( 数据库设计过程 | 概念结构设计 | ER 图 简介 | 概念设计阶段 工作拆分 )





一、数据库设计过程 概述



数据库设计过程 :

  • 需求分析阶段 : 明确 用户需求 ;
    • 输入 :
      • 用户业务需求 : 任务书 和 设计方案 , 当前和未来应用数据要求 , 数据处理要求 ;
      • 现有系统文档 ;
    • 输出 :
      • 数据流图 : 用 图形化 方式展示系统中 数据流动、存储、处理 的逻辑关系 , 包含 进程、数据流、数据存储、外部实体四要素 ;
      • 数据字典 : 结构化文档 , 详细定义 数据项名称、类型、长度、约束条件、来源及去向 ;
      • 需求说明书 : 汇总 用户功能性 与 非功能性 需求 的 正式文档 ;
  • 概念设计阶段 : 使用 ER 模型 描述数据关系 , 将 现实世界的需求 抽象出 概念模型 , 即 实体-关系图 ( ER 图 ) ;
    • 输入 :
      • 需求分析产物 : 包括 数据流图、数据字典、需求说明书 ;
      • 用户业务需求 ;
    • 输出 : ER 图 ( 实体-关系图 ) , 将需求 抽象为 可视化模型 , 实体 由 实体 ( 矩形 ) 、属性 ( 椭圆 ) 、联系 ( 菱形 ) 表现出来 , 实体之间的关系有 1:1、 1:N、 M:N ;
  • 逻辑设计阶段 : 将 ER 图 转换为 关系模式 ;
    • 输入 :
      • 概念设计阶段产物 : ER 图 ;
      • 规范化理论 : 通过 范式 消除数据冗余与更新异常 , 范式有 1NF、2NF、3NF ;
      • 关系模型 : 以表 ( 关系 ) 为核心的数据模型 , 支持关系代数操作 ( 如 : 选择、投影、连接 ) , 数据库 都是 基于 关系模型 实现 ;
    • 输出 :
      • 关系模式 : 就是 数据库表结构 , ER 图 转为 关系模式 ( 表结构 ) ;
      • 视图 : 虚拟表 , 简化复杂查询 、 隐藏敏感数据 、 提供逻辑数据抽象 ;
      • 完整性约束 : 主键 / 外键 / 检查约束 ;
  • 物理设计阶段 : 确定 存储结构 与 索引 , 考虑具体的 物理存储、物理分布、物理访问 的细节 ;
    • 输入 :
      • 逻辑设计阶段输出 : 视图、完整性约束
      • DBMS 特性 : 如 存储引擎 / 索引类型 等 ;
      • 硬件 和 操作系统特性 : 软硬件配置 ;
      • 数据处理要求 ;
    • 输出 :
      • 物理存储结构 : 决定数据基础存取效率 , 是 文件 的 组织方式 , 数据在 磁盘 上的 物理存储形式 ( 堆文件、顺序文件、索引文件、散列文件 ) , 直接影响读写效率 ;
      • 索引方式 : 平衡查询性能与存储成本 , 索引可以 加速数据检索 , 牺牲存储空间换取查询效率 , 常见的索引方式有 哈希索引、位图索引、B+树索引 ;
      • 分区策略 : 解决海量数据分布与扩展性问题 , 将大数据集划分为 逻辑 / 物理 独立单元 , 提升可管理性与性能 , 常见的分区策略有 水平分区 、 垂直分区 、 范围分区 、 列表分区 等 ;
      • 缓存优化方案 : 通过 空间 换 时间 突破 I/O 瓶颈 , 利用 高速存储介质 ( 如内存 ) 缓存热点数据 , 减少磁盘访问 , 常见的策略有 LRU 最近最少使用 、 LFU 最不经常使用 、 TTL 过期时间 等 ;

在这里插入图片描述





二、ER 图 简介




1、ER 图 概念


ER 图 ( Entity-Relationship Diagram , 实体-关系 图 ) : 是 用于 描述 现实世界概念模型 的工具 , 通过 图形化方式 展示如下元素 :

  • 实体 ( Entity ) : 现实中的独立对象 , 可区分的 物体或概念 , 用 实体用矩形表示 , 矩形框内写明实体名 ;
  • 属性 ( Attribute ) : 实体 或 关系 的某个特征 , 属性用椭圆形表示 , 并用 无向边 将 属性 与 相应的 实体或关系 连接起来 ;
  • 关系 ( Relationship ) : 实体间的关联 , 关系 用菱形表示 , 菱形框内写明 关系名 , 并用无向边分别与有关实体连接起来 , 同时在无向边旁标上联系的类型 ( 如 : 1:1、1:n、m:n ) ;

2、ER 图 示例


下图是一个 学生 选课 的 ER 图 :
在这里插入图片描述

  • 实体 : 学生 和 课程 是 实体 , 使用 矩形 表示 ;
  • 属性 : 学生的属性有 学号、姓名、性别、年龄 等属性 , 课程的属性有 课程号、课程名、任课教师 等属性 , 使用椭圆表示 , 使用无向边连接 矩形 ( 实体 ) 与 椭圆 ( 属性 ) ;
  • 关系 : 选课 是 学生 和 课程 两个实体之间的 关系 , 使用 菱形 表示 ;

3、ER 图 关系类型


ER 图 中的 关系类型 :

  • 一对一 ( 1:1 ) : 一个实体的实例 与 另一个实体的唯一实例 相关联 ; 如 : 一个班级 设有 一个班长 ;
  • 一对多 ( 1:n ) : 一个实体的实例 与 多个实例的另一个实体 相关联 ; 如 : 一个班级 拥有 多个学生 ;
  • 多对多 ( m:n ) : 多个实体的实例 与 多个实例的另一个实体 相关联 ; 如 : 多个学生 选修 多个课程

① 一对一 ( 1:1 ) 关系


一对一 ( 1:1 ) 关系 : 一个实体的实例 与 另一个实体的唯一实例 相关联 ; 如 : 一个班级 设有 一个班长 , 班级 与 班长 的 ER 图如下所示 :
在这里插入图片描述

  • 核心转换 : 班级 与 班长 之间 , 可以选择某一端作为核心 ;
    • 以 班级 为核心 , 班级 与 班长 是 1:1 的关系 ;
    • 以 班长 为核心 , 班长 与 班级 是 1:1 的关系 ;
  • 班级集合 与 班长集合 是 一对一 的 匹配关系 , 如下图所示 :
    在这里插入图片描述

② 一对多 ( 1:n ) 关系


一对多 ( 1:n ) : 一个实体的实例 与 多个实例的另一个实体 相关联 ; 如 : 一个班级 拥有 多个学生 ; 班级 与 学生 的 ER 图如下所示 :
在这里插入图片描述

  • 核心转换 : 班级 与 学生 之间 , 可以选择某一端作为核心 ;

    • 以 班级 为核心 , 班级 与 学生 是 1:n 的关系 ;
    • 以 学生 为核心 , 学生 与 班级 是 n:1 的关系 ;
  • 班级集合 与 学生集合 是 一对多 的 匹配关系 , 如下图所示 :
    在这里插入图片描述

  • 学生集合 与 班级集合 是 多对一 的 匹配关系 , 如下图所示 :
    在这里插入图片描述


③ 多对多 ( n:n ) 关系


多对多 ( m:n ) : 多个实体的实例 与 多个实例的另一个实体 相关联 ; 如 : 多个学生 选修 多个课程 ; 学生 与 课程 的 ER 图如下所示 :
在这里插入图片描述

  • 核心转换 : 课程 与 学生 之间 , 可以选择某一端作为核心 ;
    • 以 课程 为核心 , 课程 与 学生 是 n:n 的关系 ;
    • 以 学生 为核心 , 学生 与 课程 是 n:n 的关系 ;
  • 课程集合 与 学生集合 是 多对多 的 匹配关系 , 如下图所示 :
    在这里插入图片描述




三、概念设计阶段 工作拆分



概念结构设计 阶段 通过 逐步 抽象、建模、合并与优化 , 将 碎片化需求 转化为统一的全局数据模型 ,

其核心在于 平衡用户需求与技术实现 , 确保模型具备 完整性、一致性与高效性 , 为后续数据库逻辑设计奠定基础 ;


如果 信息系统 规模比较大时 , 单靠一个人是无法完成 概念结构设计的 , ER 图 由 不同的 人员 分开完成的 , 每个人 完成一部分 局部 ER 图 ;


此处需要将 概念结构设计阶段 的工作 进行如下图所示的 拆分 : 抽象数据 ->设计局部 ER 模型 -> 合并局部 ER 模型并消除冲突 -> 重构优化并消除冗余 ;

  • 抽象数据 : 从 需求分析 中提炼 核心数据元素 及其 关联关系 , 方法如下 :
    • 分类 : 将 同类对象 抽象为实体 ;
    • 聚集 : 组合相关属性形成实体 , 如 : 学生 有 姓名 年龄 等属性 ;
    • 概括 : 建立 继承关系 , 如 : 学生 与 高中生 ;
  • 设计局部 ER 模型 :不同 子系统 或 用户视图 构建 独立的 ER 模型 , 重点是 识别局部范围内的实体、属性及联系 , 标注主键、外键及多重性 ;
  • 合并局部 ER 模型 : 整合局部模型为全局 ER 模型 , 主要的 集成方法如下 :
    • 一次性集成 : 将 所有的 ER 模型 , 一次性集成为 完整的 系统 ER 图 ;
    • 逐步集成 : 使用 累加的方式 集成 ER 图 , 每次只集成 两个 ER 图 ;
  • 消除冲突 : 解决 ER 模型 之间 不一致问题 , 常见的冲突如下 :
    • 属性冲突 : 属性域 或 属性值 冲突 ;
    • 命名冲突 : 同名异义 或 异名同义 , 统一命名规范 , 协商实体定义 ;
    • 结构冲突 : 同一对象 在 不同应用中 抽象实体不同 , 同一个实体 在 不同的 局部 ER 图 中 包含的 属性个数 和 属性排列次序不同 ;
    • 关系冲突 : 同一个关系 在 不同的 局部 ER 模型中 表现不同 ;
  • 重构优化并消除冗余 : 提高模型效率 , 减少数据冗余 ;
    • 合并相似实体 : 通过 属性 区分类型 ;
    • 消除冗余属性 : 若属性可通过其他数据推导 , 则删除冗余 ;
    • 简化复杂联系 : 检查 多对多联系 是否需要 拆解为中间实体 ;
数据表结构说明 4 1、基础字典 4 1.1设备分类字典sb_zd_class 4 1.2折旧方法字典sb_zd_depreciation(暂时没用到) 4 1.3折旧率字典sb_zd_depreciation_rate 4 1.4折旧类型字典sb_zd_depreciation_type 5 1.5设备名称字典sb_zd_equipname 5 1.6设备入出库类型字典sb_zd_in_out_type 5 1.7 设备库帐号字典sb_zd_kzh 6 1.8设备维修单位字典sb_zd_maintenance_unit 6 1.9设备制造厂商字典sb_zd_manufacture 6 1.10设备计量单位类型字典 sb_zd_measure_type 7 1.11设备计量单位字典 sb_zd_measurer 7 1.12设备调配原因字典sb_zd_move_cause 8 1.13设备状态字典sb_zd_state 8 1.14设备供应商字典 sb_zd_supplyer 8 1.15设备单位字典sb_zd_unit 9 1.16设备用途字典sb_zd_usage 9 1.17设备维修类型sb_zd_maintenance_kind 9 1.18设备内部帐号字典sb_zd_inner_acct_no 9 2、业务数据表 10 2.1设备现有附件表sb_appendix 10 2.2设备附件使用表sb_appendix_use 11 2.3设备成本效益信息表sb_cost_benefit 11 2.4设备折旧变更记录表sb_depreciation_alter_record 12 2.5设备折旧记录表sb_depreciation_record 12 2.6设备进口说明表sb_import_comment 12 2.7设备贷款记录表sb_in_credit(暂时没用到) 13 2.8设备购进明细表sb_in_detl 13 2.9主设备表sb_main_equipment 14 2.10设备维修计划单sb_maintenance_plan(暂时没用到) 15 2.11设备维修记录sb_maintenance_record 15 2.12设备计量记录sb_measure_record 16 2.13设备调配明细sb_move_detl 16 2.14设备付款明细sb_pay_detl 17 2.15设备服务计划sb_service_plan(暂时没用到) 17 2.16设备服务记录sb_service_record(暂时没用到) 18 2.17设备增值表sb_value_increment 18 2.18设备销减表sb_waste 19 2.19设备月结信息sb_report 19 2.20设备配置表sb_config 20
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值