设计数据库之概念模式：E-R模型

Chapter3：设计数据库之概念模式：E-R模型

笔记来源：《漫画数据库》—科学出版社

设计数据库的步骤：
概念模式

概念模式(conceptual schema)是指将现实世界模型化的阶段进而，是确定数据库理论结构的阶段。
概念模式的设计是通过E-R模型把握现实世界，进而规范化表格来实现的。

内部模式

内部模式是从计算机内部看到的数据库，是确定数据库物理构造的阶段。
内部模式的设计通过设计数据库高速检索方法来实现。

外部模式

外部模式是从用户和应用的角度来观察的数据库。
外部模式的设计是通过设计应用程序所必要的数据来实现的。

3.1 分析现状：E-R模型

设计数据库前需要对现实状况进行分析，这时就需要ER模型
实体就是能够认知的现实世界的事物。例如：例如将水果出口至其他国家这件事，就可以将水果和出口国作为实体来考虑。

关系就是表示实体之间有着怎样的关联。例如：水果和出口国之间就是由水果卖给出口国，这时可以把销售作为关系来考虑

实体（Entity），关系（Relationship）两个概念来考虑现实世界的模型就是E-R模型

一对一的关系
一个出口国管理一个出口记录信息。

一对多的关系
一个公主多个仆人

多对多的关系
水果销往多个出口国。
出口国购买多种水果。

3.2 规范化表格

将销售报表制作成表格

因为报表一行有两个数值，这个表格还不能直接用于数据库，如果一行只有一个数值的表格就容易处理了，这时需要把一张表拆分成多张表（一行仅有一个数值）

最初表格（非范式）分割为多个表格得到第一范式

非范式

非范式是没有除去数据重复的表格。关系数据库中是不能使用这种表格来进行数据管理的。因此需要对其做分割表格的规范化工作。

拆分为橙色圈住的一张表和蓝色圈住的一张表

第一范式

第一范式：表中每一列的属性都不可再分.
比如地址这个属性，很显然它可以分为省、市、区、乡镇等等，根据你的实际需求，如果你需要获取用户所在省份的话，很显然如果你只设计一个地址属性，是不方便直接获取省份的。
–引自如何通俗理解第一、二、三范式？

第一范式将表格分割为单纯的二元表格，即一栏中只有一个项目，每一列都是不可分割的基本数据项。分割表格时除去了重复项目。—引自《漫画数据库》—科学出版社

分成日期、出口国编码、出口国名称的表格（销售表）和商品编码、商品名称、单价、数量的表格（销售明细表（第一范式2））报表编码在两张表格中均有

我们看看第一范式2是否可以正确管理商品

在销售明细表中，如果橙子还没有销售，但此时橙子又进来货了，这是进货而不是销售，所以不能向销售明细表中更新进货的数据，至此单单一张销售明细表还不能正确管理商品，我们需要将销售明细表再次拆分
商品表（第二范式1）中商品编码是主键、销售明细表（第二范式2）中报表编码+商品编码这个组合是主键

我们再来看看第一范式1是否可以正确管理商品

我们发现销售表满足第二范式要求，由于上面第一范式2已经拆分为第二范式1和2，所以我们将其称之为第二范式3

第二范式：表中每一列的属性都不可再分，且非主属性完全依赖于主属性.
–引自如何通俗理解第一、二、三范式？
主键的值可以确定其他列的值

第二范式(second normal form)是按照通过可识别数据的键来确定其他列值的原则分割表格。这样，通过主键确定其他列的数值。
关系数据库中这种“通过某一列的值确定其他列的数值”的原则我们称之为函数依赖。
第二范式是根据主键和其他列之间的函数依赖关系分割表格的。—引自《漫画数据库》—科学出版社

如果某个国家现在没有进口我国的水果，但想将其作为未来潜在用户加入到表中，这时这个国家是不能放到销售表中的，我们将此第二范式3再次拆分，拆为销售表和出口国表

第三范式：表中每一列的属性都不可再分，且非主属性完全依赖于主属性，且每个非主属性都不传递函数依赖于主属性.
–引自如何通俗理解第一、二、三范式？
由主键唯一确定其他列的表格叫第三范式

第三范式是按照只能由主键确定其他列值的原则分割的表格。
在关系数据库的函数依赖中，“通过某一列的值间接确定其他列的值”我们称之为传递依赖
第三范式是去除传递依赖而分割表格得到的。
—引自《漫画数据库》—科学出版社

下图来自：第一范式，第二范式，第三范式，BCNF范式理解

最初的一个销售报表最终拆分为销售表、出口国表、销售明细表、商品表，四张满足第三范式的表格，主键的值确定，则其他列的值唯一确定。这个拆分过程是逐步剔除主键与非主键部分依赖和传递依赖关系的过程，使得各个表即使添加数据也不会出现不一致的数据等问题，也使得各表间的关系明确。