数据库建模

目录

PowerDesigner简介

• 数据库建模
  • 由已存在的数据库或者SQL语句反向生成PDM，CDM
  • 根据PDM产生为SQL 语句并可以文件形式存储。
  • 根据CDM 产生基于特定数据库的“物理数据模型”-PDM。（正向）
  • 利用实体-关系图创建“概念数据模型”－CDM。（反向）
  • 面向对象设计（ UML 建模）

    • 用例图

      类图

      对象图

    • 时序图 状态图 协作图

    • 状态图      组件图 部署图

  • 业务流程图 (BPM)

数据库建模：

一对多关系案例：

例1：部门 dept 和员工 emp ，一对多关系

• 完成步骤
  • 创建概念数据模型CDM（抽象的，和具体的数据库没有关系）
  • 产生物理数据模型PDM（具体的，和具体的数据库有关系）
  • 产生数据库脚本（由PDM生成可执行的数据库脚本）
  • 实际开发中也可能直接从PDM开始，PDM可以向上转换成CDM，可以向下转换成数据库脚本

先画出CDM（实体-联系图），然后根据CDM生成PDM物理模型，可以是Mysql或Oracle等：

可以根据PDM直接生成SQL语句

一对一关系是特殊的一对多关系，一对多关系可以把一中的主键字段放到多的表中作为外键（fk）

多对多关系案例：

例2：学生和课程，多对多关系

实际开发中也可能直接从PDM开始，PDM可以向上转换成CDM，可以向下转换成数据库脚本。此示例直接从PDM开始建模。

PDM：

逆向工程

逆向工程的作用：当需要把SQL表转化为Qracle表时可以利用逆向工程实现。

• 需求

  1

  ：如何生成MySQL中sakila用户的数据库表关系图，清晰了解表和表之间的关系

• 需求 2 ：如何将 MySQL 中 r 用户的数据库表移植到Oracle数据库中

• 解决方案：使用

  PowerDesigner

  的反向工程完成

• 含义：根据

  SQL

  脚本或者数据库表生成

  PDM

  图

• 操作：

  File—–Reverse Engineering

数据库表的三种关系：

一对多：

多对多：

增加一个中间表，将多对多转换为两个一对多。两个表的主键作为中间表的外键，中间表用两个表的外键作为联合主键

多对多：增加一个中间表，将一个多对多转换为两个一对多。中间表中有外键

一对一：

有外键关联和主键关联两种方式，本质上都是外键关联

三大范式：

• 什么是范式（NF= NormalForm）

  • 范式是符合某一种设计要求的总结。
  • 要想设计一个结构合理的关系型数据库，必须满足一定的范式。

• 如何是合理数据库

  • 结构合理
  • 冗余较小
  • 尽量避免插入删除修改异常

• 范式分类

• 第一范式

• 第二范式

• 第三范式

  • Boyce Codd范式=BCNF
  • 由Boyce和Codd提出的,
  • 比3NF又进了一步
  • 通常认为是修正的第三范式.

• 第四范式

• 第五范式

• 各个范式是依次嵌套包含的

• 范式越高，设计质量越高，在现实设计中也越难实现

• 一般数据库设计，只要达到第三范式，即可避免异常的出现

• 

第一范式

• 要求
  • 最基本的范式
  • 数据库表每一列都是不可分割基本数据项，同一列中不能有多个值
  • 简单说就是要 确保每列保持的原子性
  • 第一范式的合理遵循需要根据系统的实际需求来定
• 示例
  • 用户表（用户名，家庭地址）
  • 用户表（用户名，省，城市，详细地址）
  • 系（系名称，系主任，系高级职称人数）
  • 系（系名称，系主任，系教授人数，系副教授人数）

第二范式

• 要求
  • 第二范式需要确保数据库表中的 每一列都和主键相关，而不能只与主键的某一部分相关（即不能使用联合主键，主键只能是一列不能是多列联合）
  • 即在一个数据库表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中
• 示例
  • 学号和课程编号作为联合主键
  • 课程名称只依赖于课程编号，而和学号没有关系

• 解决
  • 提取出学生表
  • 提取成课程表
  • 提取选课表，存放选课记录

第三范式

• 要求

  • 确保数据表中的 每一列数据都和主键直接相关，而不能间接相关
  • 属性不依赖于其他非主属性。

• 示例1：学生班级表

班级名称和信息与班级编号直接相关，而和主键间接相关，不符合第三范式。

范式总结：

• 范式是指导数据设计的规范化理论，可以保证数据库设计质量

• 第一范式：字段不能再分

• 第二范式：不存在局部依赖

• 第三范式：不含传递依赖（间接依赖）

• 优点 ：结构合理、冗余较小、尽量避免插入删除修改异常

• 缺点 ：多表查询比单表查询速度慢，性能降低

• 特定表的的设计可以违反第三范式，增加冗余提高性能

• 数据库的设计应该根据当前情况和需求做出灵活的处理。

  • 在实际设计中，要整体遵循范式理论。
  • 如果在某些特定的情况下还死死遵循范式也是不可取的，因为可能降低数据库的效率，此时可以 适当增加冗余而提高性能 。
    • 示例：
      • 比如经常购物车条目的中除了条目编号，商品编号，商品数量外，可以增加经常使用的商品名称，商品价格等

订单表中增加冗余列图书名称、价格，以空间换时间。