从非归一化关系归一化为 3NF答案

【问题标题】：Normalization to 3NF from un-normalized relation从非归一化关系归一化为 3NF
【发布时间】：2016-09-27 04:03:52
【问题描述】：

给定

INSURANCE PORTFOLIO (portfolio id, insurance company name, insurance company phone, ((agent name, agent license number, state of residence, ((policy number, policy description, annual premium, benefit, beneficiary details)), 
number of policies)), number of policies in a portfolio)

我正在尝试将其纳入 3NF。我在正确的轨道上吗？

1NF：

1NF: INSURANCE PORTFOLIO:(portfolio id, insurance company name, insurance company phone,
,agentname, number of policies in a portfolio)

agentdetails: (agent name, agent license number, state of residence, policy number,number of policies in a portfolio#)

policydetails:(agent name#,policy number#, policy description, annual premium, benefit, beneficiary details)

2NF

2NF: INSURANCE PORTFOLIO:( agent name ,portfolio id, insurance company name, number of policies in a portfolio)

Agentdetails: (agent name, agent license number, state of residence, policynumber,number of policies in a portfolio#)

policydetails:(agentname,policy number, policy description, annual premium, benefit, beneficiary details)

3NF：

 INSURANCE PORTFOLIO:( agent name ,portfolio id, phonenumber  , number of policies in a portfolio)


agentdetails:(agent name#, agent license number, state of residence,policynumber,number of policies in a portfolio#)

policydetails:(agent name#,policy number#, policy description, annual premium, benefit, beneficiary details)

感谢任何指导

【问题讨论】：

对 3NF 的规范化需要了解各种表中的函数依赖关系。你没有给他们。 PS Re 1NF 见this answer and its linked answer。
请解释输入是什么。它似乎不是关系，因为没有出现双括号的属性名称。还请解释清楚双括号的含义。从您的示例中，它们似乎意味着类似于嵌套关系的值，而不是类似于元组的值。请参考您被告知的“0NF”和“1NF”的含义以及如何从中获得“1NF”设计。这些术语没有固定的含义。

标签： database-design normalization 3nf

【解决方案1】：

您的 1NF 答案跳过 1NF 并尝试直接转到 3NF。结果，您似乎对 2NF 和 3NF 答案不知所措。

1NF 不会引入新的关系（除非您有可以为空的嵌套表）。它的作用是消除嵌套行。然后更高的范式分解关系。

您的原始架构具有以下形式：

R = (A, B, C, (D, E, F, (G, H, I, J, K), L), M)

我假设没有策略就无法存在投资组合，没有代理就无法存在策略。将其转换为 1NF 应具有以下形式：

R = (A, B, C, D, E, F, G, H, I, J, K, L, M)

并且您需要选择一个合适的主键，以便关系中的每一行都由主键的值唯一标识。在最坏的情况下，所有列的组合都是唯一的（即总是有一个键），但在这种情况下，您应该能够找到一个包含 3 列或更少的列，具体取决于嵌套级别之间的关联。

对于 2NF，查看是否可以在 1NF 模式中找到任何部分功能依赖项。如果您选择了具有单列的主键，则您的关系已经在 2NF 中，您可以向前跳过。如果存在任何部分依赖关系，请将它们拆分为单独的关系。

对于 3NF，查看是否可以在 2NF 模式中找到任何传递函数依赖项。如果有，请将它们拆分为单独的关系。

【讨论】：

如果括号表示嵌套表并且这样的表可以是空的，那么您需要使用一个键将其拆分为另一个表。
@philipxy 感谢您指出这一点。我更新了我的答案。
给定 R = (A pk, B, (C)) 其中 A -> B 和 A ->> C 和 C 可以为空，我会将其拆分为 R1 = (A pk, B ) 和 R2 = (A pk, C pk)。代理人在哪里，还是您有不同的想法？
已更正 PS：如果没有嵌套表属性的 CK，则必须引入代理项。例如 {,} 与 CK {a,b}。或者只是一个具有集合值属性的单属性关系。
PPS 候选键 A 和嵌套表属性 b 并不意味着 A ->> b 或 A ->> 未嵌套 b。

【解决方案2】：

我的大学时代已经超过 3 年了，如果我有点生疏或跳过了一些步骤，请原谅我。首先，列出所有属性并确定其描述的内容：

Attribute               Entity
=========               ======
portfolio id            Portfolio
insurance company name  Insurance Co.
insurance company phone Insurance Co.
agent name              Agent
agent license number    Agent
state of residence      Agent
policy number           Policy
policy description      Policy
annual premium          Policy
benefit                 Benefit
beneficiary details     Benefit
number of policies      Agent
number of policies      Portfolio

所以现在我们有了新实体 Insurance Co、Agent、Policy 和 Benefit。现在的问题是，“这些属性中的任何一个是否会多次出现？”是的，一份保单可能有很多好处（因此有很多细节）。每个投资组合都可以由许多政策组成。因此，我们将福利和政策分开并从 Portfolio 中删除它们的属性：

Benefit(ID, Benefit, Beneficiary Details)
Policy (ID, Policy Number, Description, Annual Premium)
Portfolio (...)

没有更多的多重或非原子属性，所以 Portfolio 现在是 1nf。现在我们提取描述投资组合以外的实体的属性。现在的设计如下所示：

Benefit (ID, Benefit, Beneficiary Details)
Policy (ID, Policy Number, Description, Annual Premium)
Insurance Co (ID, Name, Phone)
Agent (ID, Name, License No, State of Residence, Number of policies)
Portfolio (ID, InsuranceCoID, AgentID, Number of policies)

投资组合现在是 2nf。但是其他实体之间存在关系。我在这里做出假设，其中一个假设是代理人为一家公司工作，而不是像代理多家公司的经纪人一样。因此，代理将与保险公司有 1-n 的关系（一个代理最多与一家公司相关，一家公司与零个、一个或多个代理相关）。同样的关系似乎存在于保单和代理人之间、利益和保单之间（假设每个利益都是专门为每个保单量身定制的）以及保单和投资组合之间。添加这些关系如下所示：

Benefit (ID, PolicyID, Benefit, Beneficiary Details)
Policy (ID, Policy Number, AgentID, PortfolioID, Description, Annual Premium)
Insurance Co (ID, Name, Phone)
Agent (ID, CompanyID, Name, License No, State of Residence, Number of policies)
Portfolio (ID, Number of policies)

不同的假设会产生不同的结果，但过程是相同的。

现在 Portfolio 采用 3nf。我会认为 Policy 和 Portfolio 之间的耦合足够松散，可以定义一个 1-n 交集表，而不是将 Portfolio FK 作为 Policy 元组的一部分，但这并不是规范化过程的正式一部分。还有一个问题是直接将政策与公司联系起来，而不是（或以及）通过代理。这将允许代理人从一家公司转移到另一家公司，而无需随身携带所有保单。但它提出了一个问题，即如何处理保单与代理人不同的公司的情况。这些都是有效的设计考虑（我什至还没有解决两个计算字段“策略数量”），但就规范化而言，我们似乎已经完成了。我没有声称这是可以做到的最好的，这只是一个例子。

【讨论】：

您不能在不引入代理项的情况下“分解”多值属性，除非将多值属性视为关系值属性，但存在一个不包含它的候选键以在新关系变量中使用. （否则您无法重建输入。）因此，您需要证明您确实复制了 CK 以及您已“分解”的多值/关系值属性的属性。（请参阅我对 reaanb 答案的评论。）
我没有声称我的答案可以作为家庭作业问题的答案。我承认跳过了原始帖子中的步骤。我只是希望 OP 对规范化过程有一个更清晰的概念视图。
我不明白你为什么提到家庭作业。我的观点是，您的程序在一般情况下不起作用，并且您没有证明这是它适用的情况之一。
好吧，也许我只是不明白投诉。如果我在某处遗漏了代理键，也许你可以指出来，我会修复它。
我在我的第一条评论中解释了：如果您有一个 CK 和一个 MVA（“多值属性”）不是该 CK 的一部分，那么您可以从原来的 MVA 中删除并引入第二个表CK 为 MVA 的一个元素加上一个属性。但是如果 CK 和 MVA 不是不相交的，那么你就不能这样做，因为这对不会重建到原始的。在这种情况下，您必须引入代理人。我并不是说这里就是这种情况。我的意思是，如果您不介绍代理人，那么您需要证明事实并非如此。在对 reaanb 的回答的评论中查看我的示例。

【解决方案3】：

[1] 你的数据库没有传递函数依赖，所以它属于 3NF 类别

[2] 在 Agentdetails 表中添加一个唯一列 Agent_ID

[3] 在“Insurance Portfolio”和“PolicyDetails”表中调用 Agent_ID

[4] 运行报告时，如果您希望显示代理名称，则与代理详细信息表进行适当的连接

【讨论】：

如果提问者没有指定任何 FD，你怎么知道没有传递 FD？此外，规范化不会引入代理键。最后，你的回答没有解释什么。
这里的整个想法是，按照我建议的步骤，当执行步骤 [3] 时，FD 将被删除。