点击关注上方“程序员的私房菜”，设为“顶级或明星”，技术干货第一时间送出。

来源：blog.csdn.net////

1、原始收据与实体的关系

它可以是一对一、一对多或多对多关系。 通常情况下，它们是一对一的关系：即一张原始收据对应一个且仅一个实体。 特殊情况下，可能是一对多或多对一的关系，即一张原始报检单对应多个单位，或者多张原始报检单对应一个单位。

这里的实体可以理解为基本表。 明确了这些对应关系之后，对于我们设计输入界面将会有很大的好处。

〖示例1〗：员工的简历数据对应人力资源信息系统中的三个基本表：员工基本信息表、社会关系表、工作简历表。 这是典型的“一份报检单对应多个主体”的典型案例。

2.字段和主键

一般来说，一个实体不能同时是无域和无域的。 在ER图中，叶子部分的实体可以定义字段，也可以不定义字段（因为它没有后代），但它必须有主键（因为它有儿子）。

字段和字段的设计在全局数据库的设计中起着重要的作用。 全局数据库设计完成后，一位日本数据库设计专家表示：“钥匙，到处都有钥匙，不仅有钥匙，而且什么都没有。” 系统核心（数据模型）的高度具体的想法。

因为：场是实体的高度具体化，场与场的配对代表了实体之间的联系。

3.基本表的性质

基本表不同于中间表和临时表，因为它有以下四个特点：

了解了基本表的本质后，在设计数据库时就可以将基本表与中间表和临时表区分开来。

4.范式标准

基本表及其数组之间的关系应尽可能满足第三范式。 而且，满足第三范式的数据库设计往往不是最好的设计。 为了提高数据库的运行效率，往往需要增加范式标准：适当减少冗余，达到以空间换时间的目的。

〖例2〗：有一个存储商品的基本表，如表1所示，数组“金额”的存在表明该表的设计不满足第三范式。 由于“数量”可以通过“单价”乘以“数量”得到，也就是说“数量”是一个冗余数组。 而且，减少“量”的冗余数组可以提高查询统计的速度，这就是用空间换时间的做法。

在中，规定的列有两种：数据列和估计列。 “金额”等列称为“计算列”，“单价”和“数量”等列称为“数据列”。

表1 商品表表结构

5. 三种范式的简单理解

简单了解这三种范式，对数据库设计大有裨益。 在数据库设计中，为了更好的应用三大范式，需要了解三大范式（表面的理解是充分的理解，而不是最科学、最准确的理解）：

没有冗余的数据库设计可以做到这一点。 而且，没有冗余的数据库不一定是最好的数据库。 有时为了提高运行效率，需要降低范式标准，适当保留冗余数据。

具体方法是：在设计概念数据模型时，违反第三范式，在化学数据模型设计中考虑添加范式标准的工作。 添加范例意味着减少数组并允许冗余。

6、善于识别并正确处理多对多关系

如果两个实体之间存在多对多关系，则应删除这些关系。 移除它的方法是降低中间的第三个实体。 这样，原来的一对多关系现在变成了两个一对多关系。 原本两个实体的属性要合理分配给三个实体。

这里的第三个实体其实是一个比较复杂的关系，它对应一个基本表。 一般来说，数据库设计工具无法识别多对多关系，但可以处理多对多关系。

〖例3〗：在“图书馆信息系统”中，“图书”是一个实体，“读者”也是一个实体。 这两个实体之间的关系是典型的多对多关系：一本书可以在不同时间被多个读者借阅，一个读者可以借阅多本书。

因此，为了减少两者之间的第三个实体，将该实体命名为“借还书”，其属性为：借还时间、借还标志（0表示借书，1表示还书），此外，它还应该有两个字段（一个字段用于“Book”，一个字段用于“”），以便它可以与“Book”和“”链接。

7.野外PK的取值方法

PK是程序员在表之间使用的连接工具。 可以是一串没有化学意义的数字，通过程序手动加1实现。 它也可以是具有化学意义的数组名称或数组名称的组合。 但后者优于前者。 当PK为数组名组合时，建议数组个数不要过多。 如果太多，不仅索引会占用大量空间，而且速度也会变慢。

八、正确理解数据冗余

多个表中重复出现的字段和主键不属于数据冗余。 这个概念一定要清楚。 其实很多人还不清楚。 非键数组的重复出现就是数据冗余！ 而且是低级冗余，即重复冗余。 中间冗余不是数组的重复出现，而是数组的派生出现。

〖示例4〗：商品中有“单价、数量、金额”三个数组。 “数量”由“单价”乘以“数量”得出。 它是冗余的，而且是一种中间冗余。 冗余的目的是提高处理速度。

只有低级冗余才能减少数据不一致，因为相同的数据可能会从不同的时间、地点和角色多次输入。 为此，我们提倡中级冗余（派生冗余），反对低级冗余（重复冗余）。

9、E--R图没有标准答案

信息系统的ER图没有标准答案，因为它的设计和绘制方法并不是唯一的，只要覆盖了系统需求的业务范围和功能内容，就是可行的。 反之，应改变E--R图。

虽然它没有唯一的标准答案，但并不意味着可以随便设计。 好的ER图的标准是：结构清晰、关联简单、实体数量适中、属性分布合理、无低级冗余。

10、视图技术在数据库设计中的用处

与基本表、代码表、中间表不同，视图是依赖于数据源真实表而存在的虚拟表。 视图是程序员使用数据库的窗口，是合成基表数据的方式intellij idea 数据库关系图，是数据处理的方式，也是对用户数据保密的手段。

为了进行复杂的处理、提高计算速度和节省存储空间，视图深度定义通常不能超过三层。 如果三层视图还不够，应该在视图上定义临时表，然后在临时表上定义视图。 这样，重复定义，并且视图的深度不受限制。

对于关系到国家政治、经济、技术、军事和安全利益的个人信息系统，观点的作用更为重要。 本系统基本表的数学设计完成后，立即在基本表上构建第一层视图。 这一层视图的数量和结构与基本表的数量和结构完全相同。 而且规定所有程序员只允许对视图进行操作。

只有数据库管理员，拥有多人持有的“安全钥匙”，才能直接对基础表进行操作。 请读者思考：为什么？

11. 中间表、报告和临时表

中间表是存储统计数据的表。 它是专为数据库机房、输出报表或查询结果而设计的。 有时它没有字段和主键（数据库机房除外）。 临时表是程序员设计的，用于存储供个人使用的临时记录。 基表和中间表由DBA维护，临时表由程序员自己手动维护。

12、诚信约束表现在三个方面

域的完整性：使用Check来实现约束。 在数据库设计工具中，定义数组的取值范围时，有一个勾选按钮来定义数组的值。

参照完整性：通过 PK、FK 和表级触发器实现。 用户定义的完整性：是一些业务规则，通过存储过程和触发器来实现。

13、避免数据库设计打补丁的方法是“三少原则”

1.数据库中的表越少越好。 只要表的数量少，就可以表现出系统的ER图小而精确，去除多余多余的实体，产生对客观世界的高度表征，整合系统数据，避免打补丁风格设计；

2. 表中组合字段的数组越少越好。 由于字段的作用，一是构建字段索引，二是作为子表的主键，所以组合字段的数组数量较少，不仅节省了运行时间，而且也节省了索引存储空间；

3.一张表中的数组越少越好。 只要数组的数量很少，就可以说明系统中不存在数据重复，数据冗余很少。 更重要的是，敦促读者学会“变列为行”，从而避免需要将子表中的数组拉入主表中，而在主表中留下许多空数组。 所谓“列转行”，就是把主表中的部分内容拉出来，单独创建一个子表。 这个方法很简单，有的人就是不习惯，不采纳，不执行。

数据库设计的实用原则是在数据冗余和处理速度之间找到合适的平衡点。 “三少”是一个整体的概念，一个综合的观点，不能孤立地遵循一定的原则。

原则是相对的，不是绝对的。 “三个以上”的原则肯定是错误的。 试想：如果覆盖系统相同的功能，100个实体（共1000个属性）的ER图肯定比200个实体（共2000个属性）的ER图好很多。

提倡“三少”原则，就是要求读者学会使用数据库设计技术进行系统的数据集成。 数据集成的步骤是将文件系统集成到应用数据库中，应用数据库集成到主题数据库中，主题数据库集成到全局综合数据库中。

集成度越高，数据共享越强，信息孤岛现象越少，整个企业信息的全局ER图中实体数、主键数、属性数越少系统。

提倡“三少”原则的目的是防止读者借助打补丁技术不断对数据库进行增删改查，使企业数据库成为随意设计的数据库表的“垃圾堆”，或数据库表的“大院子”。 致使数据库中的基础表、码表、中间表、临时表杂乱无章intellij idea 数据库关系图，数不胜数，企事业单位的信息系统难以维护和瘫痪。

任何人都可以实现“三多”原则，这是“打补丁”数据库设计的谬论。 “三少”原则就是少而精的原则。 它对数据库的设计方法和艺术要求很高，不是任何人都能达到的，因为这个原则是避免使用“打补丁”设计数据库的理论基础。

14.提高数据库运行效率的方法

在给定的系统硬件和系统软件条件下，提高数据库系统运行效率的途径是：

事实上，要提高数据库的运行效率，必须在数据库系统级优化、数据库设计级优化和程序实现级优化三个层面下功夫。

以上十四种方法是很多人在大量的数据库分析和设计实践中逐渐总结出来的。 对于这种经验的应用，读者不要死记硬背，而要消化理解，实事求是，灵活掌握。 并逐步做到：在应用中开发，在开发中应用。

（超过）

最近热门推荐

1.

2.

3.

4.

5.

如有侵权请联系删除！