规范化自引用属性答案

【问题标题】：Normalizing self referencing attributes规范化自引用属性
【发布时间】：2013-04-20 03:16:19
【问题描述】：

在包含persons 信息的数据库中规范化spouse 信息的最佳方法是什么？

数据包括：

person_id
first name
middle name
last name
phone number
address
vehicle
house
health
destiny
items
spouse first name
spouse middle name
spouse last name
spouse phone number
spouse address

我正在考虑保留一个表来考虑所有persons（配偶或其他）并区分spouse，如果它的行具有另一个person_id 的值person。这种自我参考是否可取？

我还打算为重复数据创建表。如health、vehicle等

【问题讨论】：

我没有看到您所指的lead_id 列。
我的错，我改正了。

标签： sql database-design relational-database normalization

【解决方案1】：

规范化配偶信息将包括删除spouse * 列。如果你想要一个自引用表，你应该有一个引用person_id 的spouse_id 列；但不要重复所有配偶信息，例如姓名、地址和电话号码。

对于像人对车辆这样的一对多关系，是的，您需要在“多”端（例如vehicle）带有person_id FK 列的表格。

另外，强烈考虑将address 拆分到自己的表中。如果您打算将地址的所有元素存储在这一列中，那是非常非规范化的（3NF）：它们应该分成不同的列（例如street、municipality、region 等等);而且这些真的要求放在一个不同的表中。

自引用表是否可取？这真的取决于情况；但是根据我的经验，它们在数据中自然出现的地方是有意义的：我认为您所概述的通用“人”场景是合格的。相比之下，考虑一个相当做作的“图片”场景 - 表 picture 包含一个 of_picture_id 列，以涵盖图片的图片......图片......（嗯，现在这对我来说听起来并不那么做作。 ..；但希望你能明白。）

【讨论】：

【解决方案2】：

配偶也是一个“人”，因此必须将配偶的详细信息作为单独的记录来获取。唯一可行的方法是引入spouse_id 作为自引用键。您显示的上表未标准化，因为一个人的表包含另一个人的详细信息。我建议您通过以下方式修改“人员”架构

 person_id
 first_name
 middle_name
 last_name
 phone_number
 address
 vehicle
 house
 health
 destiny
 items
 spouse_id

【讨论】：

它没有标准化（至少到 3NF）有几个原因，我已经概述了其他一些原因。删除spouse * 并添加spouse_id 近半小时前就很清楚了。 :) 该问题还询问了诸如spouse_id 所涉及的这种自我引用关系的可取性。
对。我已经对你的回答 @J0e3gan 投了赞成票。我的意思是让 OP 清楚修改后的表格应该是什么样子 :)
清晰有价值，我承认列的列表更清晰 - 至少在 spouse * 和 spouse_id 方面。

【解决方案3】：

PARTY
id
name

PARTY_RELATIONSHIP
from_party_id not null references party(id)
to_party_id not null references party(id)
from_date not null
to_date null
primary key (from_party_id, to_party_id, from_date)
check (from_party_id <> to_party_id)

【讨论】：