数据库建模
数据库建模
·
目录
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 |
更多推荐
已为社区贡献1条内容
所有评论(0)