数据库建模

目录

PowerDesigner简介

数据库建模：

一对多关系案例：

多对多关系案例：

逆向工程

 数据库表的三种关系：

一对多：

多对多：

一对一：

三大范式：

第一范式

第二范式

范式总结：

---

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：学生班级表 

学号(主键)	学生姓名	班级编号	班级名称	班级信息
023145	张三	987654	3班	特招班
023146	李四	987654	3班	特招班
023147	王五	987655	4班	普通班
023258	赵六	987654	3班	特招班

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

范式总结：

• 范式是指导数据设计的规范化理论，可以保证数据库设计质量
• 第一范式：字段不能再分
• 第二范式：不存在局部依赖
• 第三范式：不含传递依赖（间接依赖）
• 优点：结构合理、冗余较小、尽量避免插入删除修改异常
• 缺点：多表查询比单表查询速度慢，性能降低

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

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

编号(主键)	图书id	图书名称	价格	数量
023145	1	精通Java	60	1
023146	2	Oracle宝典	65	1
023147	3	JSP	87	3
023258	1	精通Java	60	2