彩票走势图

dbForge Studio For MySQL是一个在Windows平台被广泛使用的MySQL客户端，它能够使MySQL开发人员和管理人员在一个方便的环境中与他人一起完成创建和执行查询，开发和调试MySQL程序，自动化管理MySQL数据库对象等工作。

点击下载dbForge Studio For MySQL最新试用版

数据库设计基础

为了设计数据库模式，让我们回顾7种规范形式以及规范化和非规范化的概念。它们是所有设计规则的基础。

让我详细说明7种正常形式：

1.一对一关系：

1.1强制性关系：

一个例子是拥有护照的公民（每个公民必须拥有护照，护照是每个公民的护照）。

此关系以两种方式实现：

1.1.1在一个实体（表）中：

图1。“公民”实体

在这里，公民表代表公民实体，并且PassportData属性（字段）包含公民的所有护照数据，并且不能为空（NOT NULL）

1.1.2。在两个不同的实体（表）中：

图2。公民和PassportData实体之间的关系

“公民”表代表公民实体，“护照数据”表代表公民护照数据的实体。公民实体包含PassportID属性（字段），该属性引用PassportData表的主键。护照数据实体具有CitizenID属性（字段），该属性引用Citizen表的CitizenID主键。

确保CitizenID字段和PassportData表的完整性，以提供一对一的关系也很重要。也就是说，Citizen表中的PassportID字段和PassportData表中的CitizenID字段必须引用相同的记录，就好像它是第1.1.1段中说明的一个实体（表）一样。

1.2可选关系：

这里的一个示例是可以拥有护照数据并且可能没有指定国家/地区的人。因此，在第一种情况下，他是给定国家的公民，而在第二种情况下，他不是。

此关系以两种方式实现：

1.2.1在一个实体（表）中：

图3。人员实体

在此，“人”表代表人实体，“ PassportData”属性（字段）包含一个人的所有护照数据，并且可以为空（NULL）

1.2.2在两个实体（表）中：

图4。Person和PassportData之间的关系

 在此，“人”表代表人实体，“护照数据”表代表人的护照数据实体（即护照本身）。人员实体包含PassportID属性（字段），该属性引用PassportData表的主键。而护照数据实体在“个人”表中具有“个人ID”属性（字段）。人员表的PassportID字段可以为空（NULL）。

保证PersonID字段和PassportData表的完整性，以提供一对一的关系也很重要。也就是说，Person表的PassportID字段和PassportData表的PersonID字段必须引用相同的记录，就好像它是第1.2.1节中所示的一个实体（表）一样，或者这些字段必须未指定，即，包含NULL。

2.一对多关系

2.1强制性关系：

这方面的一个例子可以是父母及其子女。每个父母都有至少一个孩子。

您可以通过两种方式实现这种关系：

2.1.1在一个实体（表）中：

图5。上级实体

这里，Parent表代表父实体，而ChildList属性（字段）包含有关子项（即子项本身）的信息。该字段不能为空（NOT NULL）。ChildList字段类型通常是半结构化数据（NoSQL），例如XML，JSON等。

2.1.2在两个实体（表）中：

图6。父子实体之间的关系

在此，父表代表父实体，子表代表子实体。子表的ParentID字段引用了Parent表的主ParentID键。子表的ParentID字段不能为空（NOT NULL）。

2.2）可选关系：

例如可能有孩子或没有孩子的人。

此关系以两种方式实现：

2.2.1在一个实体（表）中：

图7。人员实体

在这里，Parent表代表父实体，而ChildList属性（字段）包含有关子项（即子项本身）的信息。该字段可以为空（NULL）。通常的ChildList字段类型是半结构化数据（NoSQL），例如XML，JSON等。

2.2.2在两个实体（表）中：

图8。人与子实体之间的关系

在此，父表代表父实体，子表代表子实体。子表的ParentID字段引用了Parent表的主ParentID键。子表的ParentID字段可以为空（NULL）。

同样，在子实体和父实体（表）具有相同的属性集（字段）而不引用父实体的情况下，存在引用自身的第三种方法：

图9。具有自我参照的Person实体

这里，Person实体（表）包含引用同一表Person的主PersonID键的ParentID属性（字段），并且可以具有空值（NULL）。

这是具有可选性质的多对一关系的实现。

3.多对一关系

该关系反映了上面所示的一对多关系。这就是子实体与父实体之间的关系，如果孩子至少有一个父辈，并且如果我们带走所有孩子（包括孤儿院中的孩子），则这种强制关系是可能的，那么这种关系具有选择性。

通过添加引用相应实体主键的必要属性，也可以通过两个以上的实体来实现一对多和一对多关系。此实现类似于上面的1.1.2和1.2.2段中的示例。

4.多对多关系

在这种情况下，一个示例可能是一个人或几个人拥有的房地产。同时，一个人可以拥有几所房屋或拥有许多房屋的所有权份额。

您可以按照上面针对先前关系描述的方式，使用NoSQL来实现此关系。但是，在关系模型中，通常通过3个实体（表）实现此关系：

图10。人与房地产实体之间的关系

在此，Person和RealEstate表分别代表一个人的实体和不动产。这些实体（表）通过PersonRealEstate实体（表）通过PersonID和RealEstateID属性（字段）相关联，这些属性分别引用Person表的主键PersonID和RealEstate表的RealEstateID。请注意，该对（PersonID; RealEstateID）在PersonRealEstate表中始终是唯一的，因此它可以成为PersonRealEstate链接实体（表）的主键。

通过添加引用相应实体主键的必要属性，可以通过3个以上的实体来实现此关系。这样的实现类似于第1.1.2和1.2.2段中描述的示例。

那么您可能想知道这7个范式在哪里？

好吧，这里是：

1. 第1条（第1.1条和第1.2条）是第一和第二条正式规则。
2. 参数2（参数2.1和参数2.2）是第三和第四条正式规则。
3. 第3条（类似于第2条）是第五和第六条正式规则。
4. 第4条是第七条正式规则。

只是在上面的文本中，这7个范式被分为4个功能块。

标准化消除了数据冗余，因此降低了数据异常的风险。但是，分解实体（表）时的规范化将导致更复杂的查询构建以进行数据操作（插入，更新，选择和删除）。

相反的过程是非规范化。它通过添加冗余数据（例如，如上文在2.1.1和2.2.1中提到的借助于半结构化数据（NoSQL））简化了数据访问的查询处理。

您确定要使用7种范式吗？您确实掌握了它，而不仅仅是熟悉它。问问自己，是否会在几个小时内为任何数据域或任何信息系统设计一个数据库模型（即使实体过多）。您可以稍后通过询问分析人员和客户代表来完善复杂性和细节。

如果这个问题使您措手不及，并且您认为完成此任务的可能性很小，那么您知道这7种正常形式，但不了解它们。

消息来源中并没有以某种方式表明，实体之间的这些关系不仅是被建立而且是被发现的。也就是说，从一开始，它们实际上就存在于真实世界中，介于主体和客体之间。

除此之外，这些关系可以改变，从一对一转变为一对多，或转变为多对一，或转变为多对多，从而改变其强制性或保留其强制性。

我认为您应该尝试观察人们并检测主体之间以及主体与客体之间的现有关系（上面的示例将公民和护照视为具有强制性质的一对一关系，而将人和护照视为具有强制性质的一对一关系）。一对一关系（可选）。

深入了解7种标准形式后，您可以轻松地为任何信息系统设计具有任何复杂性的数据库模型。

除此之外，您将了解可以多种方式实现关系，并且关系本身可以更改。因此，数据库模型（模式）是实体在特定时间点之间关系的快照。因此，必须同时指定两个实体（它们是真实世界或领域对象的图像），并考虑到将来的变化来确定它们之间的关系。

一个经过精心设计的数据库模型，充分考虑了现实中和主题领域中的关系更改，长期以来不需要任何更改。对于数据存储而言，更改涉及重新保存大量数据（从几GB到几TB的数据）特别重要。

注意：在关系数据库模型中，它是实体之间的关系，而行（元组）是这些关系的示例。但是为了简单起见，我们通常是按表表示实体，按行表示实体实例，并按外部键关系表示它们之间的关系。