【数据库学习笔记】数据库建模

数据库建模

A.概述

1.概述

在设计数据库时，对现实世界进行分析、抽象

并从中找出内在联系，进而确定数据库的结构

这一过程就称为数据库建模

2.作用

a.模型能准确表达设计意图，更易于进行技术交流

b.模型可以用来高效地产生代码、脚本、技术文档，可以做到“一处改动，多处同步”的效果

c.模型驱动的开发能使开发过程保持一致性，提高开发人员的效率，而且能保持我们的设计模型能被准确的实现，而不产生歪曲

d.模型驱动的开发能更快速地应对需求的变动

3.步骤

a.需求分析阶段

准确了解与分析用户需求，使整个设计过程的基础

是最困难、最耗费时间的一步

b.概念结构设计阶段：CDM

是整个数据库设计的关键，通过用户需求进行综合、归纳与抽象

形成一个独立于具体DBMX的概念模型

对现实生活模拟，不用考虑外建，只是站在应用架构师的角度

抽象实体Entity和实体之间的关系Relation

c.逻辑数据模型：LDM

需要考虑数据的存储结构，是关系的还是面向对象的

对数据进行符合数据库设计范式的规范，但不关心物理数据库

d.物理数据模型

需要考虑实际具体数据库对应的功能以及在必要时，需要规范化的设计

e.总结

概念模型是把现实世界中实体和关系抽象到计算机世界

逻辑模型就是一种跟具体数据库无关的数据库模型

物理模型是对某一款数据库进行设计的数据库模型

所以在数据库开发当中，先进行概念模型

然后进行逻辑模型，再进行物理模型的建模

B.E-R图

1.概述

实体-联系图(Entity Relationship Diagram)提供了表示实体型、属性和联系的方法

用来描述现实世界的概念模型

2.构成E-R图的基本要素

a.实体

同一类实体具有相同的特征和性质，用实体名以及其属性名集合来抽象和刻画同类实体，在E-R图中，用矩形表示，矩形框内写明实体名，比如员工，就是实体

b.属性

实体所具有的某一特性，一个实体可由若干个属性来刻画，在E-R图中，用椭圆表示，并用无向线段将其与相应的实体连接起来，比如员工的姓名，性别等都是属性

c.联系

信息世界中，反映实体内部或实体之间的联系

实体内部的联系通常是指组成实体的属性之间的联系

实体之间的联系是指不同实体集之间的联系

在E-R中用菱形表示，框内写明联系名，并用无向线分别与有关实体连接

同时在无向线段旁边标上联系的类型(1:1,1:n,n:n)

3.E-R图

C.设计范式

1.概述

构建数据库必须遵循一定的规则，而关系数据库中的关系

必须满足一定的要求，即满足不同的范式

目前关系数据库常用的有三种范式：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)

在第一范式基础上，进一步满足更多要求的成为第二范式，其余范式以此类推

一般来说，数据库只需满足第三范式就行了

2.三大范式

a.第一范式

数据库表的每一列都是不可分割的基本数据

同一列中不能有多个值，增强的是列的原子性

也就是列不能再分成其他几列

在同一个关系数据库中，第一范式是对关系模式的基本要求

不满足第一范式的数据库就不是关系数据库

实体中某个属性有多个值时，必须拆分不同的属性

思考：一个通讯录表，字段：姓名、性别、电话

分析：一个联系人有家庭电话和公司电话，因此该表不符合第一范式

解决：姓名、性别、家庭电话、公司电话

b.第二范式

首先满足第一范式，另外包含两个内容

1)必须有一个主键

2)其余键必须完全依赖于主键，不能只依赖于主键的一部分

一行数据只做一件事，只要数据列中出现数据重复，就要把表拆分

思考：学生选课，学生信息，课程信息

分析：主键是一个联合主键(学号，课程编号)，学生信息依赖于学号，课程信息依赖于课程编号，而成绩依赖于学号+课程编号

需要三张表：

1)学生表：学生信息 + 选课编号

2)课程表：课程信息

3)成绩表：学号+课程编号+成绩

缺点：数据重复，浪费空间，更新异常，更新学分，需要跟新多行数据

c.第三范式

必须满足第二范式，消除表中的传递依赖

第三范式是为了消除数据库中字段之间的依赖关系

传递依赖是指x-->y,y-->z，得到x-->z

分析：假设有学生表(学号、姓名、院系id、院系)，学号为主键，院系id为外键。另一个院系表(院系id、院系名称)，院系为主键，次数存在传递依赖，学号可以唯一确定院系id，院系id又唯一确定院系名称

3.例子

关于学生选课的关系表

概念模型

逻辑模型

物理模型