Question

鉴于

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)

感谢任何指导

Answer 1

您的1NF答案会跳过1NF并尝试直接转到3NF。结果，您在2NF和3NF答案中无所适从。

<1> 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模式中找到任何传递函数依赖项。如果有的话，将它们分开以分开关系。

Answer 2

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

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

所以现在我们有了新的实体保险公司，代理，政策和福利。现在的问题是，“这些属性中是否会出现多次？”是的，一项政策可能有很多好处（因此很多细节）。每个投资组合都可以由许多政策组成。因此，我们打破了收益和政策，并从投资组合中删除了他们的属性：

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

不再有多个或非原子属性，因此Portfolio现在为1nf。现在我们提取出描述除Portfolio之外的实体的属性。设计现在看起来像这样：

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)

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

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

Answer 3

[1]您的数据库没有传递功能依赖性，因此它属于3NF类别

[2]使用Agentdetails表添加一个唯一的列Agent_ID

[3]在＆＃34;保险组合中调用Agent_ID＆＃34;和＆＃34; PolicyDetails＆＃34;表

[4]在运行报告时，如果您希望显示代理名称，请使用Agentdetails表进行适当的连接

从非标准化关系归一化为3NF

3 个答案: