可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。
〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。
2. 主键与外键
一般而言，一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。
主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。
3. 基本表的性质
基本表与中间表、临时表不同，因为它具有如下四个特性：
(1) 原子性。基本表中的字段是不可再分解的。
(2) 原始性。基本表中的记录是原始数据（基础数据）的记录。
(3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。
(4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。
理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。
4. 范式标准
基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。
〖例2〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。
在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。
表1 商品表的表结构
商品名称 商品型号 单价 数量 金额
电视机 29吋 2,500 40 100,000
5. 通俗地理解三个范式
通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：
第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；
第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；
第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余.
没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。
6. 要善于识别与正确处理多对多的关系
若两个实体之间存在多对多的关系，则应消除这种关系。消除的办法是，在两者之间增加第三个实体。这样，原来一个多对多的关系，现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个实体，实质上是一个较复杂的关系，它对应一张基本表。一般来讲，数据库设计工具不能识别多对多的关系，但能处理多对多的关系。
〖例3〗：在“图书馆信息系统”中，“图书”是一个实体，“读者”也是一个实体。这两个实体之间的关系，是一个典型的多对多关系：一本图书在不同时间可以被多个读者借阅，一个读者又可以借多本图书。为此，要在二者之间增加第三个实体，该实体取名为“借还书”，它的属性为：借还时间、借还标志(0表示借书，1表示还书)，另外，它还应该有两个外键(“图书”的主键，“读者”的主键)，使它能与“图书”和“读者”连接。
7. 主键PK的取值方法
PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时，建议字段的个数不要太多，多了不但索引占用空间大，而且速度也慢。
8. 正确认识数据冗余
主键与外键在多表中的重复出现, 不属于数据冗余，这个概念必须清楚，事实上有许多人还不清楚。非键字段的重复出现, 才是数据冗余！而且是一种低级冗余，即重复性的冗余。高级冗余不是字段的重复出现，而是字段的派生出现。
〖例4〗：商品中的“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量”派生出来的，它就是冗余，而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数据的不一致性，因为同一数据，可能从不同时间、地点、角色上多次录入。因此，我们提倡高级冗余(派生性冗余)，反对低级冗余(重复性冗余)。
9. E--R图没有标准答案
信息系统的E--R图没有标准答案，因为它的设计与画法不是惟一的，只要它覆盖了系统需求的业务范围和功能内容，就是可行的。反之要修改E--R图。尽管它没有惟一的标准答案，并不意味着可以随意设计。好的E—R图的标准是：结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。
10. 视图技术在数据库设计中很有用
与基本表、代码表、中间表不同，视图是一种虚表，它依赖数据源的实表而存在。视图是供程序员使用数据库的一个窗口，是基表数据综合的一种形式, 是数据处理的一种方法，是用户数据保密的一种手段。为了进行复杂处理、提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。 若三层视图仍不够用, 则应在视图上定义临时表, 在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。
对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统，视图的作用更加重要。这些系统的基本表完成物理设计之后，立即在基本表上建立第一层视图，这层视图的个数和结构，与基本表的个数和结构是完全相同。并且规定，所有的程序员，一律只准在视图上操作。只有数据库管理员，带着多个人员共同掌握的“安全钥匙”，才能直接在基本表上操作。请读者想想：这是为什么？
11. 中间表、报表和临时表
中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员自己用程序自动维护。
12. 完整性约束表现在三个方面
域的完整性：用Check来实现约束，在数据库设计工具中，对字段的取值范围进行定义时，有一个Check按钮，通过它定义字段的值城。参照完整性：用PK、FK、表级触发器来实现。用户定义完整性：它是一些业务规则，用存储过程和触发器来实现。
13. 防止数据库设计打补丁的方法是“三少原则”
(2) 一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的外键，所以组合主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间；
(3) 一个表中的字段个数越少越好。只有字段的个数少了，才能说明在系统中不存在数据重复，且很少有数据冗余，更重要的是督促读者学会“列变行”，这样就防止了将子表中的字段拉入到主表中去，在主表中留下许多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，另外单独建一个子表。这个方法很简单，有的人就是不习惯、不采纳、不执行。
数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念，综合观点，不能孤立某一个原则。该原则是相对的，不是绝对的。“三多”原则肯定是错误的。试想：若覆盖系统同样的功能，一百个实体(共一千个属性) 的E--R图，肯定比二百个实体(共二千个属性) 的E--R图，要好得多。
提倡“三少”原则，是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成为应用数据库，将应用数据库集成为主题数据库，将主题数据库集成为全局综合数据库。集成的程度越高，数据共享性就越强，信息孤岛现象就越少，整个企业信息系统的全局E—R图中实体的个数、主键的个数、属性的个数就会越少。
提倡“三少”原则的目的，是防止读者利用打补丁技术，不断地对数据库进行增删改，使企业数据库变成了随意设计数据库表的“垃圾堆”，或数据库表的“大杂院”，最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章，不计其数，导致企事业单位的信息系统无法维护而瘫痪。
“三多”原则任何人都可以做到，该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的原则，它要求有较高的数据库设计技巧与艺术，不是任何人都能做到的，因为该原则是杜绝用“打补丁方法”设计数据库的理论依据。
14. 提高数据库运行效率的办法
在给定的系统硬件和系统软件条件下，提高数据库系统的运行效率的办法是：
(1) 在数据库物理设计时，降低范式，增加冗余, 少用触发器, 多用存储过程。
(2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条)，复杂计算要先在数据库外面，以文件系统方式用C++语言计算处理完成之后，最后才入库追加到表中去。这是电信计费系统设计的经验。
(3) 发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。水平分割的做法是，以该表主键PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过八十个，则垂直分割该表，将原来的一个表分解为两个表。
(4) 对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数。
(5) 在使用面向数据的SQL语言进行程序设计时，尽量采取优化算法。
总之，要提高数据库的运行效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化，这三个层次上同时下功夫。
上述十四个技巧，是许多人在大量的数据库分析与设计实践中，逐步总结出来的。对于这些经验的运用，读者不能生帮硬套，死记硬背，而要消化理解，实事求是，灵活掌握。并逐步做到：在应用中发展，在发展中应用。
数据库范式
一、基础概念
- 实体：现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”，它也可以是虚拟的，不如说“老师与学校的关系”。
- 属性：教科书上解释为：“实体所具有的某一特性”，由此可见，属性一开始是个逻辑概念，比如说，“性别”是“人”的一个属性。在关系数据库中，属性又是个物理概念，属性可以看作是“表的一列”。
- 元组：表中的一行就是一个元组。
- 分量：元组的某个属性值。在一个关系数据库中，它是一个操作原子，即关系数据库在做任何操作的时候，属性是“不可分的”。否则就不是关系数据库了。
- 码：表中可以唯一确定一个元组的某个属性（或者属性组），如果这样的码有不止一个，那么大家都叫候选码，我们从候选码中挑一个出来做老大，它就叫主码。
- 全码：如果一个码包含了所有的属性，这个码就是全码。
- 主属性：一个属性只要在任何一个候选码中出现过，这个属性就是主属性。
- 非主属性：与上面相反，没有在任何候选码中出现过，这个属性就是非主属性。
- 外码：一个属性（或属性组），它不是码，但是它别的表的码，它就是外码。
二、6个范式
首先要明白，范式的包含关系。一个数据库设计如果符合第二范式，一定也符合第一范式。如果符合第三范式，一定也符合第二范式…
第一范式（1NF）：属性不可分。
在前面我们已经介绍了属性值的概念，我们说，它是“不可分的”。而第一范式要求属性也不可分。那么它和属性值不可分有什么区别呢？给一个例子，这个表中，属性值“分”了：
| name | tel | age | |
| 大宝 | 13612345678 | 22 | |
| 小明 | 13988776655 | 010－1234567 | 21 |
这个例子，这个表中，属性值“分”了：
| name | tel | age | |
| 手机 | 座机 | ||
| 大宝 | 13612345678 | 021－9876543 | 22 |
| 小明 | 13988776655 | 010－1234567 | 21 |
这两种情况都不满足第一范式。不满足第一范式的数据库，不是关系数据库！所以，我们在任何关系数据库管理系统中，做不出这样的“表”来。
第二范式（2NF）：符合1NF，并且，非主属性完全依赖于码。
听起来好像很神秘，其实真的没什么。
一个候选码中的主属性也可能是好几个。如果一个主属性，它不能单独做为一个候选码，那么它也不能确定任何一个非主属性。给一个反例：我们考虑一个小学的教务管理系统，学生上课指定一个老师，一本教材，一个教室，一个时间，大家都上课去吧，没有问题。那么数据库怎么设计？（学生上课表）
| 学生 | 课程 | 老师 | 老师职称 | 教材 | 教室 | 上课时间 |
| 小明 | 一年级语文（上） | 大宝 | 副教授 | 《小学语文1》 | 101 | 14：30 |
一个学生上一门课，一定在特定某个教室。所以有（学生，课程）－>教室
一个学生上一门课，一定是特定某个老师教。所以有（学生，课程）－>老师
一个学生上一门课，他老师的职称可以确定。所以有（学生，课程）－>老师职称
一个学生上一门课，一定是特定某个教材。所以有（学生，课程）－>教材
一个学生上一门课，一定在特定时间。所以有（学生，课程）－>上课时间
因此（学生，课程）是一个码。
然而，一个课程，一定指定了某个教材，一年级语文肯定用的是《小学语文1》，那么就有课程－>教材。（学生，课程）是个码，课程却决定了教材，这就叫做不完全依赖，或者说部分依赖。出现这样的情况，就不满足第二范式！
有什么不好吗？你可以想想：
1、校长要新增加一门课程叫“微积分”，教材是《大学数学》，怎么办？学生还没选课，而学生又是主属性，主属性不能空，课程怎么记录呢，教材记到哪呢? ……郁闷了吧?(插入异常)
2、下学期没学生学一年级语文（上）了，学一年级语文（下）去了，那么表中将不存在一年级语文（上），也就没了《小学语文1》。这时候，校长问：一年级语文（上）用的什么教材啊？……郁闷了吧?(删除异常)
3、校长说：一年级语文（上）换教材，换成《大学语文》。有10000个学生选了这么课，改动好大啊！改累死了……郁闷了吧？（修改异常）
那应该怎么解决呢？投影分解，将一个表分解成两个或若干个表。
学生上课表新：
| 学生 | 课程 | 老师 | 老师职称 | 教室 | 上课时间 |
| 小明 | 一年级语文（上） | 大宝 | 副教授 | 101 | 14：30 |
课程表：
| 课程 | 教材 |
| 一年级语文（上） | 《小学语文1》 |
上面的“学生上课表新”符合2NF，可以这样验证：两个主属性单独使用，不用确定其它四个非主属性的任何一个。但是它有传递依赖！
在哪呢？问题就出在“老师”和“老师职称”这里。一个老师一定能确定一个老师职称。
有什么问题吗？想想：
1、老师升级了，变教授了，要改数据库，表中有N条，改了N次…… （修改异常）
2、没人选这个老师的课了，老师的职称也没了记录…… （删除异常）
3、新来一个老师，还没分配教什么课，他的职称记到哪？…… （插入异常）
那应该怎么解决呢？和上面一样，投影分解：
| 学生 | 课程 | 老师 | 教室 | 上课时间 |
| 小明 | 一年级语文（上） | 大宝 | 101 | 14：30 |
| 老师 | 老师职称 |
| 大宝 | 副教授 |
BC 范式（ BCNF ）：符合3NF，并且， 主属性不依赖于主属性
若关系模式属于第一范式，且每个属性都不传递依赖于键码，则R属于BC范式。
通常
BC范式的条件有多种等价的表述：每个非平凡依赖的左边必须包含键码；每个决定因素必须包含键码。
BC范式既检查非主属性，又检查主属性。当只检查非主属性时，就成了第三范式。满足BC范式的关系都必然满足第三范式。
还可以这么说： 若一个关系达到了第三范式，并且它只有一个候选码，或者它的每个候选码都是单属性，则该关系自然达到 BC 范式。
一般，一个数据库设计符合3NF或BCNF就可以了。在BC范式以上还有第四范式、第五范式。
第四范式：要求把同一表内的多对多关系删除。
第五范式：从最终结构重新建立原始结构。
*************************************************************************
范式:
数据库规范化(Normalization)所采用的规范模式.
首先来看一张订单(表1-1):
供应商号: 234560
供应商名: XXXXXX
============================================
商品号 商品名 数量 单价(元) 合计(元)
200 A 1000 2.00 2000.00
201 B 600 1.00 600.00
202 C 2000 10.00 20000.00
203 D 5000 20.00 100000.00
204 E 100 5.00 500.00
1. 非关系数据库表
如何通过这个订单来设计一个关系数据库的相关表?
一种最简单的办法就是将所有数据存放在一个表中,并用订单号和商品号做主键(Primary Key),
其中同一商品可以有不同的供应商
如下(表1-2:Order表):
订单号 商品号 商品名 商品描述 单价 供应商号 供应商名 供应商电话
000001 200 A ........ 2.00 234560 XXXXXX ..........
201 B ........ 1.00 234560 XXXXXX ..........
202 C ........ 10.00 234560 XXXXXX ..........
203 D ........ 20.00 234560 XXXXXX ..........
204 E ........ 5.00 234560 XXXXXX ..........
-------------------------------------------------------------------------------
000002 200 A ........ 2.00 234561 YYYYYY ..........
201 B ........ 1.00 234561 YYYYYY ..........
202 C ........ 10.00 234561 YYYYYY ..........
204 E ........ 5.00 234561 YYYYYY ..........
-------------------------------------------------------------------------------
000003 202 C ........ 10.00 234560 XXXXXX ..........
203 D ........ 20.00 234560 XXXXXX ..........
204 E ........ 5.00 234560 XXXXXX ..........
2. 满足1NF的关系数据库表(消除重复组)
但上面的这个表不是一个关系数据库表,因为所有的关系数据库表中的每一行必须有主键,
并且这个主键要满足实体完整性(Entity Integrity),实体完整性就是主键不能包含空值(NULL),
并且主键必须能够惟一地标识任一行.根据实体完整性,上表显然不是一个关系数据库的表,
因为在这个表中有些行的主键中的订单号是空.
另外,上表中的000001订单下的
203 D ........ 20.00 234560 XXXXXX
204 E ........ 5.00 234560 XXXXXX
与000003订单下的
203 D ........ 20.00 234560 XXXXXX
204 E ........ 5.00 234560 XXXXXX
完全一样,这叫重复组(Repeating Groups),关系数据库表中不能含有重复组.
对上表进行修改,使之实现实体完整,即将相应的订单号补上(表1-3:Order表):
订单号 商品号 商品名 商品描述 单价 供应商号 供应商名 供应商电话
000001 200 A ........ 2.00 234560 XXXXXX ..........
000001 201 B ........ 1.00 234560 XXXXXX ..........
000001 202 C ........ 10.00 234560 XXXXXX ..........
000001 203 D ........ 20.00 234560 XXXXXX ..........
000001 204 E ........ 5.00 234560 XXXXXX ..........
-------------------------------------------------------------------------------
000002 200 A ........ 2.00 234561 YYYYYY ..........
000002 201 B ........ 1.00 234561 YYYYYY ..........
000002 202 C ........ 10.00 234561 YYYYYY ..........
000002 204 E ........ 5.00 234561 YYYYYY ..........
-------------------------------------------------------------------------------
000003 202 C ........ 10.00 234560 XXXXXX ..........
000003 203 D ........ 20.00 234560 XXXXXX ..........
000003 204 E ........ 5.00 234560 XXXXXX ..........
上表现在成为一个关系数据库表,这个表满足1NF,即:
(1) 所有的属性(列)都已定义
(2) 没有任何重复组,即每行和每列的交汇处可以而且只能包含一个值,而不能包含一组值.
(3) 所有属性(列)都依赖于主键.
3. 满足2NF的关系数据库表(消除重复组和部分依赖)
但是,上表在实际应用中是存在诸多问题的,比如说供应商XXXXXX的商品A要被分批100次订购,
那么将会在这个表中有100个订单,而关于此商品A的记录会有100行,如:
订单号 商品号 商品名 商品描述 单价 供应商号 供应商名 供应商电话
000001 200 A ........ 2.00 234560 XXXXXX ..........
...... ... . ........ .... ....... ...... ..........
000002 200 A ........ 2.00 234560 XXXXXX ..........
000003 200 A ........ 2.00 234560 XXXXXX ..........
... ... ... ... ... ... ... ...
00000n 200 A ........ 2.00 234560 XXXXXX ..........
这将使得出现输入错误的可能性大为增加,从而产生相同的商品在同一表中不同的行中记录的
相关信息不一样的错误,即所谓有数据不一致.数据不一致性是由于相同数据的重复存放,
即冗余造成的.数据冗余不但会造成数据不一致,还会使系统的维护更加困难,也会对系统的效率产生冲击.
为了减少这种情况下的数据的冗余需要消除部分依赖.
在表(1-3)中可以看出,我们只要知道某一商品的商品号,就能知道该商品的全部信息,
即商品的其他部分信息只依赖于商品号,也就是说在表1-3的:
订单号 商品号 商品名 商品描述 单价 供应商号 供应商名 供应商电话
这些字段中,
商品名 商品描述 单价
这些字段均依赖于
商品号
字段,
因为"商品号"在表(1-3)中是主键的一部分,
所以"商品名 商品描述 单价"对于"商品号"的这种依赖关系,通常称为部分依赖.
即:部分依赖(Partial Dependency)是指只依赖于部分主键的依赖关系.
我们可以将存在部分依赖关系的列拿出来新生成一个新的表Product,
而原来的Order表中去掉了一些列,形成一个新的Order表,
在Product表中,商品号将作为其主键,同时商品号在新的Order表中将作为外键,
以实现对商品的相关信息的关联.
现在最初的(1-3:Order)表被拆分为两个新的表Order和Product,
它们之间通过商品号来进行连接:
Order表:
订单号 商品号 供应商号 供应商名 供应商电话 ...
Product表:
商品号 商品名 商品描述 单价 ...
现在,一个商品的信息只需要在Product表中存放一次,
而Product表中只有商品号在Order表中可重复存放多次,
这比起最初的Order表(1-3:Order)来说,"商品名 商品描述 单价"这些字段的数据冗余已大大减少.
我们可以看到,在1NF的规范下,我们消除了重复组,
在2NF的规范下,我们消除了部分依赖,
原来的Order表已被拆分为两个表:
Order表:
订单号 商品号 供应商号 供应商名 供应商电话 ...
与Product表:
商品号 商品名 商品描述 单价 ...
它们都满足于2NF的条件:
(1) 该表为1NF(无重复组)
(2) 该表不包含部分依赖(存在部分依赖的列已被提出形成另一个表)
4. 满足3NF的关系数据库表
现在我们再来看看满足2NF的Order表:
Order表:
订单号 商品号 供应商号 供应商名 供应商电话 ...
如果供应商的电话现在有了改变,那么在Order的所有有关这个供应商的"供应商电话"的信息将要
被修改,这种工作量是很大的.
再来看看"供应商号 供应商名 供应商电话"之间的依赖关系,
一般来说,我们只要知道了某一供应商的供应商号,就能知道该供应商的全部信息,
即,"供应商名 供应商电话"只依赖于"供应商号",但在这里,"供应商号"并不是主键的组成部分,
所以这种依赖不属于部分依赖,而叫做"传递依赖(Transitive Dependency)",
传递依赖是指一个或多个属性(列)依赖于非主键的属性(列).
现在我们把存在着传递依赖的相关列拿出来,重新生成一个叫Supplier的表,
而把"供应商号"作为Supplier表的主键,同时把供应商号保留在新的Order表中作为外键,
这样,最被的Order表到现在就被拆分为三个表:
Order表:
订单号 商品号 供应商号
Supplier表:
供应商号 供应商名 供应商电话 ...
Product表:
商品号 商品名 商品描述 单价 ...
这样的三个表,都同时满足于关系数据库表的3NF,即:
(1) 该表满足2NF(无重复组,无部分依赖)
(2) 该表不包含传递依赖(存在传递依赖的列已被提出形成另一个表)
5. 满足BCNF的关系数据库表
BCNF是鲍依斯-科得范式Boyce-Codd Normal Form的简写,
在3NF的基础上,要求表中的所有字段只依赖于关键字段.
在关键字段是组合关键字段的情况下,如:
假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量),
且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品。
这个数据库表中存在如下依赖关系:
(仓库ID, 存储物品ID) → (管理员ID, 数量) ["管理员ID, 数量"依赖于组合关键字段(仓库ID, 存储物品ID)]
(管理员ID, 存储物品ID) → (仓库ID, 数量) ["仓库ID, 数量"依赖于组合关键字段(管理员ID, 存储物品ID)]
所以,(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字,
表中的唯一非关键字段为数量,这个表是符合第三范式的。
但是,由于存在如下决定关系:
(仓库ID) → (管理员ID) ["管理员ID"依赖于"仓库ID"]
(管理员ID) → (仓库ID) ["仓库ID"依赖于"管理员ID"]
即存在关键字段决定关键字段的情况,所以其不符合BCNF范式。它会出现如下异常情况:
(1) 删除异常:
当仓库被清空后,所有"存储物品ID"和"数量"信息被删除的同时,
"仓库ID"和"管理员ID"信息也被删除了。
(2) 插入异常:
当仓库没有存储任何物品时,无法给仓库分配管理员。
(3) 更新异常:
如果仓库换了管理员,则表中所有行的管理员ID都要修改。
把仓库管理关系表分解为二个关系表:
仓库管理表:
StorehouseManage(仓库ID, 管理员ID);
仓库表:
Storehouse(仓库ID, 存储物品ID, 数量)。
即满足BCNF范式.
总结:
规范化是一个过程,该过程决定把哪些属性(列)放在哪些实体(表)中.
规范化可以帮助我们设计好的表结构,因为规范化减少了数据的冗余,
这使得系统更容易维护而且系统效率也会更高.
所谓的关系型数据库的逻辑设计就是数据库的表结构设计.
在关系数据库中,只有表中存有数据.
规范化只减少了数据的冗余而并没有消除冗余.
为了使相关的表连接起来,在规范化过程中不得不引入控制冗余(外键),
不过这种控制冗余与1NF和2NF表的数据冗余相比,
已经少得微不足道了.
1497
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
