Sql 数据库规范化问题

我刚刚开始学习数据库规范化，我对我的一个表有一个问题。我的数据库现在的结构非常糟糕，其中一个原因是因为我有一个类似这样的表

客户表

ID |  Date_Entered   |  First_Name  |  Middle_Name |  Last_Name |    Maiden_Name 

Address__street_source2  |  Address_state_source2  |  Address_city_source2  | etc

因为我的公司从多个来源获得地址数据，所以地址一直在继续。但是，当然，对于我们的一些客户来说，其中一些地址将是空的。所以我想我需要一个单独的地址表，像这样连接到Customers表

地址

ID  |   Number  |    Street    |  State  |   Zip  |    Source (drop down menu)

Source_ID  |    Source

ID  |   Number  |    Street    |  State_ID  |   Zip

ID | Customer_ID | Address_ID | Source_ID

但我当时认为数据源是冗余数据。那么，我需要这样一个单独的源表吗

ID  |   Number    |  Street    |  State  |   Zip    |  Source _ID (drop down)

来源

ID  |   Number  |    Street    |  State  |   Zip  |    Source (drop down menu)

Source_ID  |    Source

ID  |   Number  |    Street    |  State_ID  |   Zip

ID | Customer_ID | Address_ID | Source_ID

然后像这样更改地址表

ID  |   Number    |  Street    |  State  |   Zip    |  Source _ID (drop down)

它似乎不正确，因为现在源代码是多余的…请帮助

如果您能告诉我是否应该在Customer表中包含处女名和中间名，因为它们也可能为空（如果不是，新表将如何构造？）

---

很抱歉，我不是一名SQL专家，但以下是我认为您想要描述的内容

作为唯一实体的客户有一个当前地址，可以有许多其他地址，如果这是正确的是，您应该将其他地址分离到他们自己的表中

其次，您发现客户有x个地址的方式是，您为每个客户从不同的公司获取此信息，如果是这种情况，我将为这些公司创建一个单独的表，并按照您的计划记录此信息，是的，您将有重复的源代码行，但情况就是这样，因为它们提供了许多不同客户的信息

与婚前和中间姓名相关的是您的业务规则要求的吗？如果需要，请在需要时保存它们

同样，我的SQL开发实际上只是学生级别的，但据我所知，我将这样做

---

希望这能有所帮助，如果有人能提供更多的专家信息，那就用它吧。

我会用类似的方法

客户

ID |  Date_Entered  |  First_Name  |  Middle_Name | Last_Name | Maiden_Name

地址

ID  |   Number  |    Street    |  State  |   Zip  |    Source (drop down menu)

Source_ID  |    Source

ID  |   Number  |    Street    |  State_ID  |   Zip

ID | Customer_ID | Address_ID | Source_ID

客户地址

ID  |   Number  |    Street    |  State  |   Zip  |    Source (drop down menu)

Source_ID  |    Source

ID  |   Number  |    Street    |  State_ID  |   Zip

ID | Customer_ID | Address_ID | Source_ID

这允许您从多个来源获得相同的地址。您可能还希望为街道设置单独的表，可能类似于

Table_Street (ID | State_ID | Name)

然后在

地址

表中，您将只有

街道ID

，而不是

街道

和

州ID

。这还允许您在用户选择状态时显示街道的选择列表

---

我想说，在客户表中使用处女名和中间名是可以的，即使它们很少使用。

您的问题部分与规范化有关，部分与规范化无关。这并不意味着你的部分问题不重要。这只是意味着它的重要性与正常化无关

从某种意义上说，你的地址本质上是一个重复的组。因此，将其从客户中移除是有意义的。（这与规范化有关；重复组违反1NF。）

“源”不是冗余数据，决定是否用ID号替换文本与规范化无关

将表格从较低的法线形式移动到较高的法线形式时，原始表格的列数会减少。用ID号替换文本不会更改列数

---

而且，用一个无意义的ID号替换文本的每一列都需要一个联接来获取有意义的文本。按照同样的逻辑，您也可以用无意义的ID号替换街道、州和邮政编码，但这将需要四个连接才能获得有意义的数据

您也可以尝试以下方法：

客户

ID |  Date_Entered  |  First_Name  |  Middle_Name | Last_Name | Maiden_Name

客户ID（主键）|输入日期|名字|中间名|姓|| 娘家姓

地址

ID  |   Number  |    Street    |  State  |   Zip  |    Source (drop down menu)

Source_ID  |    Source

ID  |   Number  |    Street    |  State_ID  |   Zip

ID | Customer_ID | Address_ID | Source_ID

客户ID（PK）（FK）|源ID（PK）|编号|街道|州|邮编

---

这假设客户和地址之间存在一对多关系。它还完全消除了Customer_Address表，支持使用两个表（Customer和Addresses），并将Addresses表的复合主键定义为CustomerId和SourceID。在这个模型中，CustomerId和SourceId唯一地确定数字、街道、州和邮政编码。它还通过确保每个客户在每个源中只能有一个地址来加强数据完整性。让我知道这是否有帮助，或者我是否偏离了底线。我还在学习

在这一点上，我同意你的看法，尽管OP可能不需要多源/多客户地址优化（尽管这可能是个好主意）

Maiden_Name

对于同一个客户可能是不同的名字（以前的名字，也就是不同的姓氏），这取决于用例。嘿，你说得对，别难过。我们在这里提供帮助（特别是措辞巧妙的具体问题）。尽管我认为，从我不断听到的关于Access的信息来看，有些人会推荐一种不同的数据库产品。。。（我自己从未使用过，所以不能说）。数据库规范化旨在使数据更可靠、更易于使用、结构更易于理解。为了实现这三个目标，您应该完全规范化您的数据。然而，过度规范化数据库是很有可能的。如果为了可靠性起见，为一条信息创建另一个表是不必要的，而只是在公共查询中强制另一个联接，那么就不要这样做。处女名/中间名是一种可以将其留在主表中的情况。您需要复制一个类似Source_ID的字段，这样它将允许您连接两个不同表的记录。这是复制数据的例外，它是如何