关系型数据库设计浅谈

概要

概念数据模型（Conceptual Data Model）

简称概念模型，是面向数据库用户的现实世界的模型，主要用来描述世界的概念化结构，它使数据库的设计人员在设计的初始阶段，摆脱计算机系统及DBMS的具体技术问题，集中精力分析数据以及数据之间的联系等，与具体的数据库管理系统（Database Management System，简称DBMS）无关. 最常用的是实体联系模型（Entity Relationship Model).

物理数据模型（Physical Data Model，PDM）

提供了系统初始设计所需要的基础元素，以及相关元素之间的关系。即用于存储结构和访问机制的更高层描述，描述数据是如何在计算机中存储的，如何表达记录结构、记录顺序和访问路径等信息. 即使用具体的DBMS来创建相关的对象.

一般的OLTP系统数据库设计流程

分析客户的业务需求->CDM->PDM.

详细介绍CDM->PDM

将Entity转为Table

一般分两种Table

Entity Table ：如学生表, 商品表，保单表等, 一般以名词命名

Association Table ：如选课表, 购物表，投保表等，一般已动词+名词命名

将Attribute转为Table Column

Column，基本就是要符合数据库设计的三大范式

1NF(normal format)：确保标识的字段的原子性

如学生表(学生号, 姓名, 性别, 家庭住址), 家庭住址里面包括省市街道, 如果系统经常需要访问和统计在校各省的学生. 那么家庭住址这个字段设计就不满足1NF. 应该将省份独立出来.

2NF(normal format)：确保非主键字段不是完全依赖于主字段

数据库表中的每一条记录被唯一地区分, 这种能唯一标识记录的字段被称为主关键字或主键、主码. 当主键有多个字段时, 如果非主键字段不是完全依赖于主字段, 这样就会造成该表存储的数据冗余.

比如一个选课表(学生号, 课程号, 姓名, 性别, 课程名, 课程描述), 这张表的主键明显应该是学生号和课程号, 但一些非主键字段课程名和课程描述不是完全依赖于学生号和课程号, 只是部分依赖于课程号. 这种情况下, 如果某个课程需要修改描述信息, 并且这个课程被上百个同学选修, 那么就要更改上百条记录. 这种数据冗余不仅消耗存储资源, 同时也影响操作效率. 符合2nd的设计应该是学生表(学生号, 姓名, 性别)， 课程表(课程号, 课程名, 课程描述)，选课表(学生号, 课程号).

3NF(normal format)：确保不存在非主键字段对任一主键字段存在传递依赖

如学生表(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话), 很明显学号是主键, 所在学院依赖于学号, 学院电话依赖于所在学院, 我们就说学院电话传递依赖学号. 这种设计同样会出现数据冗余. 正确的设计应该是学生表(学号, 姓名, 年龄, 所在学院), 学院表(所在学院, 学院地点, 学院电话)

Relation转化为Column或者Association Table

表与表之间的关系根据需求来划分，一般包括一对一，一对多，多对一，多对多

一对一关系实现：在2个Entity Table中任选一个主键添加另一个表即可

一对多和多对一的关系实现: 通常将一方的主键添加到多方中, 如学生表和班级表, 班级和学生是一对多的关系, 那么学生表(学号, 姓名, 性别, 班级号), 班级表(班级号, 班级位置)这样的设计就能体现一对多的关系.

多对多的关系, 通常用一中间表(Association Table)来实现, 如以上举过的例子, 学生表(学生号, 姓名, 性别)， 课程表(课程号, 课程名, 课程描述)，选课表(学生号, 课程号). 一个学生可以选多个课, 一个课同样可以被多个学生选, 学生表与选课表是一对多的关系, 同样课程表与选课表也是一对多的关系, 这两种关系合并起来就实现了多对多.