共计 4279 个字符，预计需要花费 11 分钟才能阅读完成。
本文出自：blog.csdn.net/sirfei/article/details/434994，如有侵权，请告知我删除。
1. 原始单据与实体之间的关系
能够是一对一、一对多、多对多的关系。在个别状况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在非凡状况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。
这里的实体能够了解为根本表。明确这种对应关系后，对咱们设计录入界面大有益处。
〖例 1〗：一份员工履历材料，在人力资源信息系统中，就对应三个根本表：员工根本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。
2. 主键与外键
一般而言，一个实体不能既无主键又无外键。在 E—R 图中, 处于叶子部位的实体, 能够定义主键，也能够不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。
主键与外键的设计，在全局数据库的设计中，占有重要位置。当全局数据库的设计实现当前，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统外围 (数据模型) 的高度形象思维。
因为：主键是实体的高度形象，主键与外键的配对，示意实体之间的连贯。
3. 根本表的性质
根本表与两头表、长期表不同，因为它具备如下四个个性：
- 原子性。根本表中的字段是不可再合成的。
- 原始性。根本表中的记录是原始数据（根底数据）的记录。
- 演绎性。由根本表与代码表中的数据，能够派生出所有的输入数据。
- 稳定性。根本表的构造是绝对稳固的，表中的记录是要长期保留的。
了解根本表的性质后，在设计数据库时，就能将根本表与两头表、长期表辨别开来。
4. 范式规范
根本表及其字段之间的关系, 应尽量满足第三范式。然而，满足第三范式的数据库设计，往往不是最好的设计。为了进步数据库的运行效率，经常须要升高范式规范：适当减少冗余，达到以空间换工夫的目标。
〖例 2〗：有一张寄存商品的根本表，如表 1 所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”能够由“单价”乘以“数量”失去，阐明“金额”是冗余字段。然而，减少“金额”这个冗余字段，能够进步查问统计的速度，这就是以空间换工夫的作法。
在 Rose 2002 中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。
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. 避免数据库设计打补丁的办法是“三少准则”
1、一个数据库中表的个数越少越好。只有表的个数少了，能力阐明零碎的 E –R 图少而精，去掉了反复的多余的实体，造成了对主观世界的高度形象，进行了零碎的数据集成，避免了打补丁式的设计；
2、一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的外键，所以组合主键的字段个数少了，不仅节俭了运行工夫，而且节俭了索引存储空间；
3、一个表中的字段个数越少越好。只有字段的个数少了，能力阐明在零碎中不存在数据反复，且很少有数据冗余，更重要的是督促读者学会“列变行”，这样就避免了将子表中的字段拉入到主表中去，在主表中留下许多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，另外独自建一个子表。这个办法很简略，有的人就是不习惯、不驳回、不执行。
数据库设计的实用准则是：在数据冗余和处理速度之间找到适合的平衡点。“三少”是一个整体概念，综合观点，不能孤立某一个准则。
该准则是绝对的，不是相对的。“三多”准则必定是谬误的。试想：若笼罩零碎同样的性能，一百个实体 (共一千个属性) 的 E –R 图，必定比二百个实体(共二千个属性) 的 E –R 图，要好得多。
提倡“三少”准则，是叫读者学会利用数据库设计技术进行零碎的数据集成。数据集成的步骤是将文件系统集成为利用数据库，将利用数据库集成为主题数据库，将主题数据库集成为全局综合数据库。
集成的水平越高，数据共享性就越强，信息孤岛景象就越少，整个企业信息系统的全局 E—R 图中实体的个数、主键的个数、属性的个数就会越少。
提倡“三少”准则的目标，是避免读者利用打补丁技术，一直地对数据库进行增删改，使企业数据库变成了随便设计数据库表的“垃圾堆”，或数据库表的“大杂院”，最初造成数据库中的根本表、代码表、两头表、长期表横七竖八，成千上万，导致企事业单位的信息系统无奈保护而瘫痪。
“三多”准则任何人都能够做到，该准则是“打补丁办法”设计数据库的歪理学说。“三少”准则是少而精的准则，它要求有较高的数据库设计技巧与艺术，不是任何人都能做到的，因为该准则是杜绝用“打补丁办法”设计数据库的理论依据。
14. 进步数据库运行效率的方法
在给定的零碎硬件和系统软件条件下，进步数据库系统的运行效率的方法是：
- 在数据库物理设计时，升高范式，减少冗余, 少用触发器, 多用存储过程。
- 当计算非常复杂、而且记录条数十分微小时(例如一千万条)，简单计算要先在数据库里面，以文件系统形式用 C ++ 语言计算解决实现之后，最初才入库追加到表中去。这是电信计费零碎设计的教训。
- 发现某个表的记录太多，例如超过一千万条，则要对该表进行程度宰割。程度宰割的做法是，以该表主键 PK 的某个值为界限，将该表的记录程度宰割为两个表。若发现某个表的字段太多，例如超过八十个，则垂直宰割该表，将原来的一个表合成为两个表。
- 对数据库管理系统 DBMS 进行系统优化，即优化各种零碎参数，如缓冲区个数。
- 在应用面向数据的 SQL 语言进行程序设计时，尽量采取优化算法。
总之，要进步数据库的运行效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化，这三个档次上同时下功夫。
上述十四个技巧，是许多人在大量的数据库剖析与设计实际中，逐渐总结进去的。对于这些教训的使用，读者不能生帮硬套，死记硬背，而要消化了解，捕风捉影，灵便把握。并逐渐做到：在利用中倒退，在倒退中利用。