数据库设计(ER模型和UML模型及转换为关系模型的公式)

本文根据b站鲁老师的教学视频整理而来,可能会偏理论化,有点枯燥,但是如果认真看完,还是会有所收获哒。
从本文可以学习到:
对于一个即将展开的项目,我们应该怎么设计及实现数据库。
掌握概念模型(ER模型和UML模型)到关系模型的转化。

对于ER模型和UML模型不是很熟悉的小伙伴和烦恼于如何设计项目的数据库的小伙伴可以看看本文。

想画出ER模型和UML模型的朋友们可以看看这篇博客(PowerDesigner(CDM)画ER图并导出且在DBMS中运行),里面用到的PowerDesigner还可以直接帮你实现概念模型(ER图)到关系模型(代码)的转化十分方便。两篇博客结合起来,相信你能对数据库的模型设计更加得心应手。

数据库设计(DBD):构造最优的数据模型,建立数据库及其应用系统的过程。

一、数据库设计步骤

1.数据分析
2.数据建模
3.关系数据库模型
4.关系数据库管理
数据库设计(ER模型和UML模型及转换为关系模型的公式)_第1张图片
注释:概念模型(ER Model/UML Model)
上面这个图是我们设计数据库及实现的流程图,大家最好熟悉一下。

下面这个7个步骤了解就好,编写项目的小伙伴可以试着遵循下面步骤来完成项目的有关数据库设计。

1.1 规划阶段

(1)系统调查
(2)可行性分析
(3)确定数据库系统的总目标

1.2 需求分析阶段

(1)分析用户活动,产生业务流程图
(2)确定系统范围,产生系统关联图
(3)分析用户活动范围涉及的数据,产生数据流图
(4)分析系统数据,参数数据字典

1.3 概念设计阶段

目标:产生反映用户需求的数据库概念结构,即概念模型
(1)进行数据抽象,设计局部概念模型
(2)将局部概念模型综合成全局概念模型(消除冲突)
(3)评审(用户评审and 应用开发人员评审)
方法:实体联系法(ER模型)(与DBMS无关的概念模型)

1.4 逻辑设计阶段

目的:将设计好的概念模型转换成与DBMS所支持的数据模型相符合的逻辑结构(包括数据库逻辑模型和外模型)
步骤:
(1)把概念模型转化为逻辑模型
(2)设计外模型
(3)设计应用程序与数据库的接口
(4)评价模型
(5)修正模型

1.5 物理设计阶段

物理设计:对于给定的基本数据模型选取一个最合适应用环境的物理结构的过程。
步骤:
(1)存储记录结构设计
(2)确定数据存放的位置
(3)存取方法的设计
(以上三个为物理结构设计)
(4)完整性和安全性考虑
(5)程序设计

1.6 数据库的实现

(1)用DDL定义数据库结构
(2)组织数据入库
(3)编制与调试应用程序
(4)数据库试运行

1.7 数据库的运行与维护

由DBA完成
数据库的转储和恢复
数据库的安全性、完整性控制
数据库性能的监督、分析和改进
数据库的重组织和重构造

二、ER模型

2.1 re图的基本元素(略)(这个大家从课本或者很多博客都可以迅速掌握,这里就不在多说明。)
2.2 联系的设计

一个联系涉及到的实体集个体,称为该联系的元数度数
一元联系(递归联系),二元联系,三元联系。
联系类型:限制参与联系的实体的数目(如二元联系的一对多,一对一等)
例:
一元联系的1对1:运动员的顺序联系(每个运动员都有1对1的顺序)
一元联系的1对n:职工的领导联系(每个领导都有1对n的职工)
一元联系的m对n:零件的组成联系(多个零件可以组合)

2.3 采用ER模型的概念设计

(1)首先设计局部ER模型
(2)然后把各局部ER模型综合成一个全局ER模型
(3)最后对全局ER模型进行优化,得到最终的ER模型,即概念模型
两个准则:
属性不能再具有需要描述的性质
属性不能与其他实体具有联系
主体都要有一个标识符。(独特的)

设计全局ER模型
优化原则:
(1)合并实体类型
(2)消除冗余属性
(3)消除冗余联系

三、ER模型向关系模型的转化

3.1 ER图转化为关系模式集的算法

(1)实体类型的转换:将每个实体类型转换成一个关系模式,实体的属性即为关系模式的属性,实体标识符即为关系模式的键。
(2)转换联系
不同的情况做不同的处理

3.2.二元的转换关系:重重点

(1)若实体间的联系是1:1,可以再两个实体类型转换成的两个关系模式中任意的一个关系模式的属性加入另一个关系模式的键和联系类型的属性。
(2)若实体间的联系是1:n,则在n端的实体类型转换成的关系模式中加入1端实体类型的键和联系类型的属性。
(3)若实体间的联系是m:n,则将联系类型也转换成关系模式,其属性为两端实体类型的键加上联系类型的属性,而键为两端实体键的组合。

实例:(例子更好的加快我们了解概念模型向关系模型转换的公式)

如三个关系模式
系(系编号,系名,电话)
教师(教工号,姓名,性别,学分)
课程(课程号,课程名,学分)

联系1: 教师(主管)系(1:1)
这时候联系转换可以把任意一个的主键作为其中一个的外键,加入关系模式中。
但是这里我们,系是比教师少的,所以如果我们在教工号里加入一个‘系主任教工号’的话,不是每一个教师都是系主任,所以这里我们要加在系里,因为每一个系都有一个系主任。
(下面所有的关系模式中,加深代表主键,变红代表外键,加深且变红代表既是主键又是外键。)
系(系编号,系名,电话,系主任教工号)
教师(教工号,姓名,性别,学分)
课程(课程号,课程名,学分)

联系2: 系(聘用 属性:聘期)教师(1:n)
1对多关系,所以把一方的主键加到多方去
系(系编号,系名,电话,系主任教工号)
教师(教工号,姓名,性别,学分,所在系编号,聘期)
课程(课程号,课程名,学分)

联系3: 系(开设)课程(1:n)
系(系编号,系名,电话,系主任教工号)
教师(教工号,姓名,性别,学分,所在系编号,聘期)
课程(课程号,课程名,学分,所在系编号

联系4: 教师(任教 属性:教材)课程(m:n)
多对多就要将这个联系自己转化为一个新的关系模式。联系的名字就是关系模式的名字。属性是:联系双方的主键以及本身的属性。且联系双方的主键作为一个联合主键。同时这两个联合主键又是外键。通过教工号,建立起和教工之间的联系,通过课程号,建立起和课程之间的联系。
系(系编号,系名,电话,系主任教工号)
教师(教工号,姓名,性别,学分,所在系编号,聘期)
课程(课程号,课程名,学分,所在系编号
任教(教工号,课程号,教材)

二元关系的转换大家一定要掌握!!!

3.3.三元的转换关系:

(1)若实体间联系是 1 : 1 : 1 1:1:1 1:1:1,可以在转换成的三个关系模式中任意一个关系模式的属性中加入另外两个关系模式的键(作为外键)和联系类型的属性。
(2)若实体间联系是 1 : 1 : n 1:1:n 1:1:n,则在n端实体类型转换成的关系模式中加入两个1端实体类型的键(作为外键)和联系类型的属性。
(3)若实体间联系是 1 : m : n 1:m:n 1:m:n,则将联系关系也转化成关系模式,其属性为三端实体类型的键加上联系类型的属性,而键位m端和n端实体键的组合。
(4)若实体间联系是 m : n : p m:n:p m:n:p,则将联系类型也转化为关系模式,其属性为三端实体类型的键加上联系类型的属性。而键位三端实体键的组合。

总结:(这是我总结出的公式)

1.如果没有n的情况,就在所有的1中挑选一个最合理的关系模式中加入其他的主键作为外键,同时加入联系类型的属性。
2.如果有n没m的情况,就在n的关系模式中加入所有1的主键作为外键,同时加上联系类型的属性。
3.如果有m的情况,就生成一个新的关系模式,模式名为联系名,主键为m和n的主键的联合主键,同时若有1则1的主键作为外键,同时加上联系类型的属性。同时主键作为外键。

其实看完上面的规则,大家就可以总结出各种各样形式的联系转换了。

3.4.一元联系转换为关系模式


运动员(编号,姓名,性别,名次)
联系:运动员(顺序)运动员(1:1)
运动员(编号,姓名,性别,名次,上一名次编号)

职工(工号,姓名,年龄,性别)
联系:职工(领导)职工(1:n)
职工(工号,姓名,年龄,性别,经理工号)

零件(零件号,零件名,规格)
联系:零件(组成 属性:数量)零件(n:m)
零件(零件号,零件名,规格)
组成(零件号,子零件号,数量)

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

(1)导出初始关系模式集
(2)规范化处理
逐一考察关系模式
判断他们是否满足规范要求
(3)模式评价
(4)模式修正
(5)设计子模式

四、UML模型(面向对象)

数据建模:对于一个特定的应用程序,如何在数据库中表示数据

4.1 设计关系模型方法:

(1)关系模型设计理论
(2)概念设计模型
E/R–传统的
UML子集–目前常用的

4.2 UML(Unified Modeling Language)统一建模语言

UML用于面向对象建模,但现在也用于数据库建模
UML与ER模型类似,但是不提供多元的联系。

UML E/R
Class(类) Entity(实体集)
Association(关联) Binary relationship(二元联系)
Association Class(关联类) Attributes on a relationship(联系的属性)
Subclass(子类) Isa hierarchy(Isa层次关系)
Aggregation(聚集) Many-one relationship(多对一联系)
Composition(组成) Many-one relationship with referential integrity(带参照完整性的多对一联系)
4.3 UML类

Class Name类名、Attributes属性、Methods方法(封装)

Movies
titile:string PK
year: int PK
length:int
genre:string

类是具有相同属性和方法的对象的集合
属性是静态的,是状态,具有数据类型
PK表示主键
方法是动态的,是行为,包括参数的声明和返回值的声明

当UML用于数据建模时,删除方法,增加主键,属性类型可选。

4.4 UML关联

关联:两个类间对象的联系
表示方法
两个类间用直线(箭头可选)连接
连接名字通常写在直线下方
数据库设计(ER模型和UML模型及转换为关系模型的公式)_第2张图片

m…n 表示与C2类中一个对象有关的C1类对象的个数最少为m,最多为n
*表示无上限
数据库设计(ER模型和UML模型及转换为关系模型的公式)_第3张图片
每个学生最多能在5个校园申请课程
每个校园容纳学生数为10000到20000之间

关联类型的简写和默认值:
* 是 0…* 的简写
1 是 1…1 的简写
默认值为 1…1

关联也可以有属性称为关联类
与E/R图中联系的属性类似
数据库设计(ER模型和UML模型及转换为关系模型的公式)_第4张图片
也可以有自身关联。

4.5 子类(Subclasses):

数据库设计(ER模型和UML模型及转换为关系模型的公式)_第5张图片

(1)UML类都可以包含下级子类
(2)子类用连线连接父类,与父类连接除空心三角指向父类
(3)主键来自父类
(4)子类继承父类的属性(包括attributes and associations)
(5)子类可以有子类自己的属性以及与其他类的关联

UML 允许4种类型的子类
(1)Complete(完全)(父类中的每个对象都是某个子类的成员)或者partial(部分)
(2)Disjoint(分散)(一个对象不能包含在两个子类中)或overlapping(重叠)。

在Object-Oriented系统中,子类dijoint-即两个子类中不存在同一对象
E/R模型自动允许overlapping子类
E/R模型和00系统都运行complete或partial子类

4.6 聚集(Aggregations)组成(Compositions)

有两种类型的多对一(n:1)关联(many-one associations)
(1)聚集(Aggregations)
聚集用连线连接两个类,一方以空心菱形箭头结束
空心菱形箭头指向一方参与对象的个数必须为0…1,不需要另外标注
数据库设计(ER模型和UML模型及转换为关系模型的公式)_第6张图片
一个电影公司可以生产很多电影。(0…*)
但是一个电影不一定是电影公司生产。(0…1)

(2)组成(Compositions)
菱形箭头一方参与对象必须为1…1
菱形箭头相反一方类的每个对象必须与菱形箭头方的一个对象关联
组成以实心菱形表示
数据库设计(ER模型和UML模型及转换为关系模型的公式)_第7张图片

4.7 UML 转化为关系

1.类的转换
2.关联的转换

E/R风格:每个子类关系只存储其自身属性和码
OO风格(面向对象):子类关系存储其自身和其父类的所有属性
基本规则ER模型一样,这里就不再重复了。

希望这篇博客能让大家更加了解数据库在整个项目的位置和提高数据库建模的能力。

你可能感兴趣的:(数据库)