MySQL数据库4——数据库设计

一.数据库设计

1.数据库设计过程

数据库设计（DBD）：构造最优的数据模型，建立数据库及其应用系统的过程。

数据库系统生存期：把数据库应用系统从开始规划、设计、实现、维护到最后被新的系统取代而停止使用的整个期间。

这个生存期一般可以划分为7个阶段：规划、需求分析、概念设计、逻辑设计、物理设计、实现、运行维护。

数据库系统在《操作系统》中我们知道其划分在软件里面，结合《软件工程》的知识，我们在数据库的课程中重点是概念设计、逻辑设计两个步骤，而软件设计的全过程更多在《软件工程》里学习。

概念设计：

概念设计的目标是产生反映用户单位信息需求的数据库概念结构，即概念模型。

一般有三步：1.进行数据抽象，设计局部概念模型；2.把局部抽象概念模型综合为全局概念模型；3.评审。

最著名的方法就是ER模型。

逻辑设计：

• 概念设计得到的是一个与DBMS无关的概念模型
• 逻辑设计的目的是把概念模型转化为DBMS能处理的逻辑模型
• 步骤：1.该概念模型转化为逻辑模型；2.设计外模型；3.设计应用程序与数据库的接口；4.评价模型；5.修正模型

物理设计主要是选取一个最适合应用环境的物理结构，主要是数据库体系结构中的内模式。

2.ER模型做概念设计

• 实体===》矩形
• 联系===》菱形
• 属性===》椭圆

属性补充：

• 属性的取值有可能是单值，有可能是多值，多值属性用双椭圆来表示。

  比如某货品的销售价格就是一个多值属性，有零售价格、批发价格、经销价格等待，如果存储这样的多值属性会存在问题，解决有两个办法：

  • 将原来的多值属性用几个新的单值属性来表示
  • 将原来的多值属性用一个新的实体类型来表示，这个实体叫弱实体

3.ER模型到关系模型的转化

采用ER模型的逻辑设计步骤：

• 1.导出初始关系模式集
• 2.规范化处理
• 3.模式评价
• 4.模式修正
• 5.设计子模式

4.UML模型做概念设计

UML是后来基于面向对象编程兴起的新方法，二者都是完成概念设计部分，现在常用UML进行设计。

UML全称统一建模语言，用于面向对象建模，也由于数据库建模。

结合面向对象编程，其实不难理解，下面补充几个知识点：

1.用类图表示类联系：

我们知道类和实体集对应，一个对象就是一个实体，实体之间的关系在类图中任然由直线连接，但是联系类需要知道标明，类图在直线连接两个类的端点处标上关联类型：

• m……*表示没有上限
• 0……n表示没有下限
• 0……*表示没有限制

一般把其看作区间的形式，左边是最小值，右边是最大值，如果连接的是C1类和C2类，写在C1端口表示的就是1个C2类对象最少对应左区间值，最多对应右区间值的C1类对象，同理如果写在C2端口，表示的就是1个C1类对应的C2类对象最少为左区间个，最多为右区间个。

在类图中必须标明关联类型，可以简写：

• *是0……*的简写
• 1是1……1的简写
• 如果不写，默认值是1……1

2.关联类

如果两个实体集（两个类）之间的关联也有属性，那么需要用关联类的方式把它表现出来。

UML类都可以包含下级子类，子类用连线连接父类，与父类连接处以空心三角形指向父类。主键来自父类，子类继承父类的属性，子类可以有子类自己的属性，以及与其它类的关联。

聚集：一种特殊的关联类型，其也用连线连接两个类，一方以空心菱形箭头结束

空心菱形箭头指向一方的类端口对应的关联类型必须为0……1，不需要另外标注

组成：与聚集类似，但是实心菱形箭头端口的关联类型必须是1……1

菱形箭头相反一方类的每个对象必须与菱形箭头方的个对象关联

该部分仅仅是接触一下，并不完全，了解即可。

二.关系数据理论

1.理论准备

编写一个程序，不可避免的要设计一个高效、合理的关系数据库，那么就要确定数据库表的组成和表的属性，从逻辑角度出发就是设计怎么样的关系模式？

范式：就是关系模式的标准。

规范化理论：低级范式分解为高级范式

比如上述的教学评价系统，设计的一张表，存在以下问题：

• (1)数据元余。例系主任的姓名重复多次
• (2) 修改异常。例修改计算机系的系主任名字，需要修改多出，少改一处，就会造成数据不一致。
• (3)插入异常。例新成立化工系，但还没有招学生此时无法插入系名和系主任的信息
• (4)删除异常。例数学系的学生全毕业了，删除学车带系名、系主任信息也从数据库中删除了

解决方法：分解关系模式来消除其中不合适的数据依赖，尽量一事一地，即决定因素尽可能唯一。

2.函数依赖

前面一节主要了解ER模型和UML进行概念设计，这里我们再学习一下数据库逻辑设计的工具——关系数据库的规范化理论。

关系模式的形式化定义：

• R(U,D,DOM,F)五元组
• R：关系名
• U：组成该关系的属性名集合
• D：属性组U中属性来自的域（数据类型）
• DOM：属性向域的映像集合
• F：属性间数据的依赖关系集合

数据依赖：定义属性值间的相互联系

数据依赖主要有函数依赖(FD)、多值依赖(MVD)、连接依赖

不去看定义，函数依赖X->Y读作X决定Y或Y依赖于X，简单来说就是属性X确定相等时，属性Y确定相等。

若X->Y，且X属于Y，则称为平凡的函数依赖，比如一个人确定了其血型名字什么肯定相等；而如果X->Y，且X不属于Y，称之为不平凡的依赖，现实中我们更多的研究都是不平凡依赖。

除此之外，还有完全依赖和部分依赖，比如（学号、课程号）确定成绩，但课程号自己一个也可以确定课程成绩，前者中课程号是部分依赖，后者中课程号是完全依赖。

FD与关键码：

设K为R(U,F)中的属性或属性组，若K能完全决定属性集U，则称K为R的候选码；若K能部分决定属性集U，则称K为R的超码。

3.范式

评价关系模式好坏的理论标准就是范式(NF)。

范式：是设计数据库结构中所要遵循的规则和指导方式，表示的是关系模式的规范化程度。
范式由低到高分：1NF，2NF，3NF，BCNF，4NF，5NF。

关系模式的规范化：把一个低一级的关系模式分解为高一级关系模式的过程
规范化程度越高，数据冗余越小，数据更新(增删改) 操作的复杂度越低

1NF的标准：R每个属性都是不可再分的，它是关系模式的最低标准，并没有解决任何问题。

2NF： 在满足1NF的基础上，R中每个非主属性完全函数依赖于候选码，则满足第二范式。

3NF：R的任一非主属性既不部分依赖于码也不传递依赖于码

BCNF：对于R的每个属性决定因素都包含候选码；所有非主属性都完全依赖于每个候选码，所有主属性都完全函数依赖于每个不包含他的候选码。

推论：若R满足第三范式，且候选码唯一，则R必属于BCNF。

多值依赖的定义：当且仅当对 R(U)的任一关系r，给定一对(x，z) 值，会对应一组 Y 的值，但这组值 (整体的值)仅仅决定于x值而与 值无关。此时，称关系模式 R(U)中多值依赖X->->Y成立。

4.关系模式规范化

​ 规范化程度过低的关系不一定能够很好地描述现实世界可能会存在插入异常、删除异常、修改复杂、数据冗余等问题，解决方法就是对其进行规范化，转换成高级范式。

​ 一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式集合，这种过程就叫关系模式的规范化。

关系模式规范化步骤：

若R与R1、R2、...、Rn自然连接的结果相等，则称关系模式R的这个解具有无损连接性(Lossless join)

分解具有无损连接性和分解保持函数依赖是两个互相独立的标准，具有无损连接性的分解不一定能够保持函数依赖，同样，保持函数依赖的分解也不一定具有无损连接性。