数据库系统-建模

oifengo

已于 2023-05-13 14:22:07 修改

阅读量1.9k

点赞数 2

分类专栏：数据库系统文章标签：数据库

于 2023-03-28 09:40:42 首次发布

本文链接：https://blog.csdn.net/weixin_39381833/article/details/129660306

版权

数据库系统专栏收录该内容

10 篇文章 2 订阅

订阅专栏

本文详细介绍了数据建模的思想，包括ER模型中的实体、属性和联系，以及IDEFx方法的扩展。接着，阐述了从需求分析到物理数据库设计的全过程，涉及概念设计、逻辑设计和物理设计阶段。此外，还讨论了函数依赖、范式理论（1NF至BCNF）以及模式分解，旨在确保数据库的正常运行和优化。

摘要由CSDN通过智能技术生成

一、建模思想

数据模型：表达计算机世界的模型
概念模型：表达信息世界的模型，全称概念数据模型

在这里插入图片描述

数据建模就是 理解区分(抽象) 命名表达

1.2 ER

Entity-Relationship Model
世界是由一组实体的基本对象和这些对象之间的联系构成的

给出了一系列概念，可以刻画信息世界
在这里插入图片描述

1.2.1 实体

可以关存在并可相互区分的事物
实体有类(实体) & 个体(实体的实例实体的值) 的概念) 在这里插入图片描述

1.2.2 属性

实体所具有的某一方面的特性
在这里插入图片描述
属性有很多类型：

单一属性复合属性(家庭详细地址省市区社区小区楼单元户)
单值属性多值属性(多个电话)
可空值非空值
导出属性
- 其他属性推导而来 “出生年月----> 年龄”

关键字/码 ：实体中能够区分唯一实例，不能重复

1.2.3 联系

实体 & 实体之间可能发生的联系
在这里插入图片描述
联系的元度
有几个属性是和外表有关联的

但是有一些联系都是由同一级实体发生的

部门1 = 部门2 + 部门3
如何区分部门123？

角色
实体在联系中的作用称为实体的角色
上面的例子就需要显性的指明其角色(role)
在这里插入图片描述

联系的种类

1:1
1:m / m:1
m:n

联系的基数：1:1 ，1：m,m:n

以实体参与联系的最小基数和最大基数来标记(MinCard…MaxCard)
完全参与联系：实例至少有一个参与到联系中，最小基数为1(1…m)
部分参与联系：实例可以不参与联系，最小基数为0（0…m）

空值只能是部分参与联系

1.3 ER的表示方法

chen方法
Crow’s Foot方法
IDEF1X方法(工程化方法)

1.3.1 chen方法

在这里插入图片描述

一般常用数字表达方法

在这里插入图片描述

1.3.2 Crow’s foot方法

在这里插入图片描述

二、工程化方法

2.1 IDEFx概念

IDEF1x数据建模方法
将ER模型进行扩充语义含义而形成的，或者说，IDEFx是ER图的细化
IDEFx是一种心境数据建模|数据库设计的工程化方法

IDEFx的概念

实体entity
- 独立标识符实体/独立实体/强实体/identifier-independent entity
- 从属标识实体/从属实体/弱实体/identifier-dependent entity

在这里插入图片描述

联系relationship
- 可标定连接联系：父实体的关键字是子实体的关键字的一部分
- 非标定连接联系
- 分类联系：一般实体实例 & 多个分类实体实例构成
- 非确定联系：一对多的联系
属性/关键字
- 属性
- 主关键字/主码
- 次关键字/候选码
- 外来关键字/外来码

2.1.1 实体

独立实体：一个实体的实例都能被唯一的标识而不决定其他实体的联系
从属实体: 一个实体的实例的唯一标识依赖于该实体与其他实体的联系

从属实体需要从其他实体继承属性作为关键字
主关键字包含了外来属性的实体为从属实体
在这里插入图片描述

2.1.2 联系

标定、非标定、分类、非确定

标定联系：子实体的实例都是由他父实体的联系而确定的

非标定联系：子实体的实例都能够唯一标识无需依赖与其他实体的联系，父实体的关键字不是子实体的关键字
子实体也是独立实体
在这里插入图片描述
工程画法
标定联系用直线表示，非标定联系用虚线表示

非确定联系：实体之间多对多的联系

确定联系通过属性继承实现两个实体之间的联系
非确定联系通过引入相交实体实现两实体的联系

分类联系：一个实体实例由一个一般实体实例 & 多个分类实体实例构成
一个一般实体由若干具体实体的类
分类实体与一般实体有相同的关键字
在这里插入图片描述

具体化：实体的实例集中，某些实例子集具有区别与该实例集内部其他实例的特征，分组分类的过程称为具体化。

自顶向下、逐步求精
面向对象的：父类–子类
子类=特例=更小的实例集合=等多的属性

泛化：多个实体具有共同的性质，可以组合成一个较高层的实体

自底向上
具体化的逆过程
强调相似属性

完全分类联系：非完全分类联系
在这里插入图片描述

三、数据建模&数据库设计

3.1 总览

需求分析
概念数据库设计
逻辑数据库设计
物理数据库设计

在这里插入图片描述

3.1 需求分析

output：需求分析报告
业务规则 & 属性处理规则
在这里插入图片描述

3.2 概念数据库设计

output：概念数据库报告：

实体的发现、划分、定义
实体属性的发现、分析、定义
实体联系的发现、分析、定义
外部试图(模式) * 概念视图(模式)的定义

最后用ER模型、IDEF1x模型描述出来

两种思路：

先局部后总体
先总体后局部

在这里插入图片描述

3.2.1 局部ER模型设计

在这里插入图片描述

3.2.2 全局ER图设计

在这里插入图片描述

3.3.3 概念设计属性可能冲突

检查并消除冲突

属性冲突
- 属性域的冲突：类型、取值范围不同(学校编码方式不同)
- 属性取值单位冲突(磅千克)
结构冲突
- 同一对象在不同应用中抽象不同(职工在A应用中式实体、B是属性)
- 实体在属性组成不同
- 联系呈现不同的类型
命名冲突
- 同名异议：不同意义的对象具有相同的名字
- 异名同义

绘制不同层级的ER图/IDEF1x图：实体级图、键级图、完整图
在这里插入图片描述

O：实体的占有属性(一定确定有的属性)
I：实体的继承属性（PK）
K：实体的主键属性（关键字）

3.3 逻辑数据库设计

逻辑数据库设计报告

将ER、IDEF1x-------> 逻辑设计模式
关系范式
折中设计，提醒开发者可能存在的问题
外模式&概念模式的定义
将关系模式进行规范化处理

关系模式、网状模型、层次模型
在这里插入图片描述

3.3.2 ER—>关系模式

属性的转换

在这里插入图片描述
复合属性转换

多值属性转换

联系的转换

一对一联系

联系双方都参与(0…1),则将联系定义为一个新的关系，属性为参与双方的关键字属性
联系A全部参与（1…1），将B的关键字作为A的关系的属性

在这里插入图片描述

一对多联系

单方实体作为多方实体对应的关系的属性

多对多联系

联系定义为新的关系，属性为双方实体的关键字

弱实体的转换

关键字 = 弱实体的区分属性 + 依赖的强实体的关键字
在这里插入图片描述

泛化具体化

高层实体（泛化实体）& 低层实体（具体化实体）分别转换成不同的关系
低层实体包含高层实体的关键字
在这里插入图片描述

多元联系的转换

继承各个实体的关键字，可以新增一个区分属性
在这里插入图片描述
数据模型：对数据和数据之间关系的抽象和描述，用于说明如何在计算机上存储和管理数据（网状/层次模型、关系模型、对象模型）

概念模型：描述数据和数据之间关系的高层次概念模型（ER）

3.4 物理数据库设计

目的：结合制定DBMS物理数据库管理方法，给出该你那数据库的物理模式描述
提交物：物理数据库设计报告
确定存储结构，文件类型：定长文件、不定长文件、堆文件、B+tree索引文件
评估磁盘空间

四、函数依赖

4.1 函数依赖

X Y是U上的子集，对R(U)的任意一个可能得关系r，r中不可能有两个元祖满足在x中属性值相等而在Y中的属性值不相等，则称“X函数决定Y”“Y函数依赖于X”
在这里插入图片描述

X–>Y & Y不属于X ， X–>Y 为非平凡的函数依赖
X–>Y & Y属于X ， X–>Y 为平凡的函数依赖（学号，性别）—> 性别

4.1.2 部分完全函数依赖

在这里插入图片描述

4.1.2 传递函数依赖

在这里插入图片描述

4.2 函数依赖的概念

超键：K是S的一个候选键，S包含K，S为R的一个超键
超键没有最小属性

超键 = 候选键 + 多余属性

超键：只要含有“学号”或者“身份证号”两个属性的集合就叫超键，
例如R1（学号 性别）、R2（身份证号 身高）、R3（学号 身份证号）等等都可以称为超键！

逻辑蕴涵：

F是R的函数依赖集合，X Y 是R 的子集，如果从F中的函数依赖能够推导出X–>Y ,则称F函数蕴涵X—>Y
在这里插入图片描述
简单讲：就是从之前的—> 中推导出新的 ---->

闭包

被F逻辑蕴涵的所有函数依赖集合称为F的闭包，记作F+
若F+ = F，说明F是一个全函数依赖族(函数依赖完备集)

在这里插入图片描述
闭包讲解

4.3 函数依赖公理

Armstrong’s Axioms A1~A3
在这里插入图片描述

自反律：（软件学院，软件工程）----> 软件工程
增广律：软工1901 ----> 软件工程 推导出：(软工1901，张三) ----> (软件工程，张三)
传递律：软工1901 ----> 软件工程，软工工程 ----> 软件学院  推导出  软工1901 ----> 软件学院

在这里插入图片描述

合并律 = 增广 + 传递
伪传递律 = 增广 + 传递（另一种用法）
分解律 = 自反 + 传递（也约等于废话）

属性集闭包

在这里插入图片描述
这个属性集根据关系能推导出的全部的属性

最小覆盖Cover

在这里插入图片描述

五 3NF

5.1 1NF

原子不可再分

5.2 2NF

U中的每一个非主属性完全函数依赖于候选键，则R(U)为第二范式
在这里插入图片描述

5.3 3NF

在这里插入图片描述
没有传递函数依赖的

5.4 BCNF

在这里插入图片描述
依赖都和候选键有关

候选键只能在左边，左边没有的都不行

5.5 多值依赖

在这里插入图片描述

5.6 4NF

在这里插入图片描述
若R属于4NF, 则必有R属于BCNF

依赖左边只能是主属性（BC范式） & 不包含多值依赖
在这里插入图片描述

1NF：属性不可分割。

2NF：不存在非主属性对候选码的部分依赖。

	例如 已知候选码是BC，非主属性是D，函数依赖中除了BC->D，还有B->D或者C->D，该模式不符合2NF

3NF：不存在非主属性对候选码的传递依赖。（左边超键or右边为主属性）

	例如 已知候选码是AB，非主属性是D，函数依赖中有AB->C和C->D，所以该模式不符合3NF

BCNF：不存在主属性对候选码的部分依赖和传递依赖。（左边为候选键）

4NF：非主属性不应该有多值依赖


例1.已知R(A,B,C),F={B->C,AC->B}、

	Step1.通过闭包运算，(AB)+=ABC,(AC)+=ABC，所以候选码是AB，AC

	Step2.根据候选码知，A，B，C都是主属性，例1中没有非主属性

	Step3.根据范式的定义，至少为3NF（因为不存在非主属性）。现在来判断是否满足BCNF，我们发现存在主属性对候选码的部分依赖B->C，所以不满足BCNF。故例1为3NF

例2.已知R(A,B,C),F={B->C,B->A,A->BC}

	Step1.通过闭包运算，(A)+=ABC,(B)+=ABC，所以候选码是A，B

	Step2.根据候选码知，A，B都是主属性，剩下的C是非主属性

	Step3.不存在非主属性C对候选码的部分/传递依赖，至少为3NF。现在来判断是否满足BCNF，我们发现不存在主属性对候选码的部分/传递依赖，所以满足BCNF。故例2为BCNF

例3.已知R(A,B,C,D),F={AB->D,BC->D,A->C,C->A}

	Step1.通过闭包运算，(AB)+=ABCD,(BC)+=ABCD，所以候选码是AB，BC

	Step2.根据候选码知，A，B，C都是主属性，剩下的D是非主属性

	Step3.不存在非主属性D对候选码的部分/传递依赖，至少为3NF。现在来判断是否满足BCNF，我们发现存在主属性对候选码的部分依赖A->C,C->A，所以不满足BCNF。故例3为3NF