数据库规范化三个范式应用实例

第一范式（1NF）

　　把数据库或数据库的表转换为第一范式一般都相当简单。第一范式要求消除数据中重复的组，这是通过建立相关数据的单独表来实现的。它通过观察数据和表结构来确定表以完成第一范式。

　　第一范式是通过把重复的组放到每个独立的表中，把这些表通过一对多关联联系起来这种方式来消除重复组的。

　　没有重复的属性以及没有重复的一组值--这听起来足够简单了。但是，有时候由于没有其它的选择，使人们相信只有简单地给设计添加任何其它集合却很困难，但是这也是你所做的事情。

　　如果我们想使理赔表达到第一范式，我们就需要找到真正与某个理赔相关联的所有属性。到底是什么构成了理赔？

　　· 理赔要有编号。

　　· 理赔要有提出要求的人。

　　· 理赔要有报告日期。

　　· 理赔要有事故或生病日期。

　　· 理赔要有由于事故或者生病引起的某种物品保留的数量。

　　· 理赔属于或者依据某种策略编写。

　　· 理赔能够结束。

　　· 理赔能够重新开始。

　　· 理赔有某种覆盖面吗？或者某种策略有更多的的事情？

　　· 理赔有起因吗？或者事故或生病有起因吗？

　　· 支付了理赔吗？或者支付了发票吗？

　　· 理赔有社会保障号码吗？或者有时候某个社会保障号码属于提出要求的人吗？

　　· 死亡日期是个有趣的部分。理赔的人死亡了吗？没有，但是如果是生命保险，它可能与理赔相关，因此应该留着。

　　修改与理赔直接相关的列，得到的结果如图2所示：

CLAIM_NUM、 CLAIM_STATUS、 ACCIDENT_YR、 ACCIDENT_DT、 REPORTED_DT、 ENTERED_DT、 CLOSED_DT、 DEATH_DT、 ASSIGNED_DT、 ADJSTER_CD、 ADJUSTER_NAME、 AGENT_CD、 AGENT_NAME、 AWARD_CD、 AWARD_DESC、 PAYMENT_NUM、 LOCATION、 SITE、 DEDUCTIBLE_RECOVER、DEDUCTIBLE_REMAIN、 POLICY_NO、 POLICY_DESCRIPTION、 STATE、 RUN_DT、 ACTIVITY_DT、 ENTRY_DT、 REOPEN_DT、 INSURED_NAME、 INSURED_ADDRESS、 INSURED_PHONE、 INSURED_CITY、 INSURED_STATE、 INSURED_ZIP、 CLAIMANT_NAME、 CLAIMANT_ADDRESS、 CLAIMANT_CITY、 CLAIMANT_STATE、 CLAIMANT_ZIP、 CLAIMANT_PHONE、 GROSS_PD

图2：第一范式的理赔表

符合第一范式的理赔表修订版本将包含仅仅与理赔相关的信息，没有包含支付或发票、策略或事故。

Payment_num	Claim_status	Accident_dt	Accident_yr	Reported_dt	Entered_dt
123456789	Open	20-JUN-2000	2000	28-JUN-2000	29-JUN-2000
234567890	Reviewed	15-FEB-1984	1984	19-FEB-1984	20-FEB-1984
147258369	Reopened	08-APR-2003	2003	10-APR-2003	11-APR-2003
258369147	Closed	18-DEC-1980	1980	18-DEC-1980	19-DEC-1980

　　如果你有支付表，并且存储了特定理赔的保留数量以供支付其它不同的帐单，为什么不把它们存储在支付表中呢？总之，你在支付表中存储了一些信息，因此为什么不把这些内容也放在它里面而不要放在理赔表中呢？

　　如果把这些信息放入理赔表的唯一原因是某个用户在理赔时可能需要这些信息，那么理赔表和支付表可以连接（join）起来，而且信息可以来自单个理赔发生的所有支付总和。并且由于你拥有不同类型的保险策略（因此有不同类型的理赔），为什么不把所有类型的理赔的支付信息存储在一张表中呢？把所有的支付信息存储在相同的表中符合逻辑。与某种支付（属性）相关联的大多数信息是相同的，不管是那种类型的支付或那种类型的理赔。但是，不同类型的理赔的帐号信息有些不同。

　　 第二范式（2NF）

　　第二范式处理冗余数据的删除问题。当某张表中的信息依赖于该表中其它的不是主键部分的列的时候，通常会违反第二范式。

　　如果新的第一范式理赔表的列如下，那么可以迅速、轻易看到的冗余数据就是被保险人的城市和州和提出理赔要求的人的城市和州。城市和州都直接依赖于Zip代码，而不依赖于与理赔相关的任何东西。

CLAIM_NUM、 CLAIM_STATUS、 ACCIDENT_YR、 ACCIDENT_DT、 REPORTED_DT、 ENTERED_DT、 CLOSED_DT、 DEATH_DT、 ASSIGNED_DT、 ADJSTER_CD、 ADJUSTER_NAME、 AGENT_CD、AGENT_NAME、 AWARD_CD、 AWARD_DESC、 LOCATION、 SITE、 DEDUCTIBLE_RECOVER、 DEDUCTIBLE_REMAIN、 POLICY_NO、 POLICY_DESCRIPTION、STATE、 RUN_DT、 ACTIVITY_DT、 ENTRY_DT、 REOPEN_DT、 INSURED_NAME、 INSURED_ADDRESS、 INSURED_PHONE、 INSURED_CITY、 INSURED_STATE、 INSURED_ZIP、 CLAIMANT_NAME、 CLAIMANT_ADDRESS、 CLAIMANT_CITY、 CLAIMANT_STATE、 CLAIMANT_ZIP

图3.第二范式的Claim

Claim_num	Claimant_name	Claimant_address	Claimant_city	Claimant_state	Claimant_zip
123456789	Jennifer Smith	1234 Main	Pittsburgh	PA	15201
234567890	Bill Smith	7852 Eagle	Pittsburgh	PA	15202
147258369	John Jones	4562 Edge	Eighty Four	PA	15330
258369147	Eleanor Stillwater	7531 West Eastern	Somerset	PA	15510

Zip_Code	City	State
15330	Eighty Four	PA
15510	Somerset	PA
15201	Pittsburgh	PA
15202	Pittsburgh	PA
15203	Pittsburgh	PA
15204	Pittsburgh	PA
15205	Pittsburgh	PA
15206	Pittsburgh	PA
15207	Pittsburgh	PA
15208	Pittsburgh	PA
15209	Pittsburgh	PA
15210	Pittsburgh	PA

　　因为Pittsburgh、Eighty Fou和Somerset、PA都不依赖于理赔，而依赖于与信息相关的Zip代码，它不是直接归属于支付表的。尽管这并不是此表的唯一问题，但是它消除了与城市、州、Zip代码依赖所引发的困难。

Claim_num	Claimant_name	Claimant_address	Claimant_zip
123456789	Jennifer Smith	1234 Main	15201
234567890	Bill Smith	7852 Eagle	15202
147258369	John Jones	4562 Edge	15330
258369147	Eleanor Stillwater	7531 West Eastern	15510

　　其它的能够迁移到其它表从而使理赔表符合第二范式的信息包括赔偿金编号和赔偿金描述组合，只需要把赔偿金编号存储在理赔表中。采用这种方法时，任何对于给定编号而对描述进行的更新需要做一些改变，它可以改变赔偿金表中的某行的某列，而且这不会发生更新异常，但是如果你更新某个影响成百上千个实体的表的某一列就可能发生更新异常了。相同的逻辑可以应用在调解人和代理人上，把他们的信息迁移到自己的表中，只需要在理赔表中存储编号列的值，这样就容易通过连接访问辅助信息了。

award_cd

award_desc

adjuster_cd

adjuster_name

agent_cd

agent_name

　　 第三范式（3NF）

　　第三范式规则查找以消除没有直接依赖于第一范式和第二范式形成的表的主键的属性。我们为没有与表的主键关联的所有信息建立了一张新表。每张新表保存了来自源表的信息和它们所依赖的主键。

　　注意：通常把第三范式说成是"键，全都是键，除了键之外没有任何信息"。

CLAIM_Num、CLAIM_STATUS 、ACCIDENT_DT、REPORTED_DT、 ENTERED_DT、 CLOSED_DT 、 DEATH_DT、 ASSIGNED_DT、 ADJSTER_CD、 AGENT_CD、AWARD_CD、 LOCATION、SITE 、 DEDUCTIBLE_RECOVER、 DEDUCTIBLE_REMAIN 、 POLICY_NO 、 STATE、 RUN_DT、 ACTIVITY_DT、 ENTRY_DT、 REOPEN_DT、 INSURED_NAME、 INSURED_ADDRESS、 INSURED_PHONE、 INSURED_ZIP、 CLAIMANT_NAME、 CLAIMANT_ADDRESS、 CLAIMANT_ZIP

图4：第三范式的理赔表

　　在第三范式中可以看到理赔表的更多的变化，在该表中被保险人姓名、地址、电话号码、Zip代码更加依赖于签订的策略而不是理赔本身。因此，我们能把被保险人的信息放入策略表中。这使得理赔表的剩余信息与理赔更加直接相关，把其它所有信息放入自己的表中而保证了足够（没有遗漏）信息。这些表的一个简单的连接能够重新构造源表的信息，这也是关系代数和关系运算（关系理论和关系数据库依赖的基础）的目标。

POLICY_NO

INSURED_NAME

INSURED_ADDRESS

INSURED_PHONE

INSURED_ZIP

　　第三范式通常是人们能够得到的规范化的最高等级，它一般也是实践中规范化和标准化数据的最高层次。但是还有更多的范式。层次越高，采用简单的步骤完成的困难就越大，而它就越来越靠近理论了。

　　规范化或者没有规范化--以及你可以采用的规范化扩展--通常是相关人员综合的结果。如果有足够的重要的需求，把某片信息存储在某个位置，而它不一定严格符合某种范式的定义，这种存储也是应该被尊重的。另外，规范化的结果需要以表和数据库的使用为基础。通常，在决策支持系统或数据仓库中，由于数据仓库的时间变量组件的映象，我们会强烈渴望得到极端的没有规范化的信息（特别是在事实表中）。

　　在面向团队的环境中，这些决定都是部门的决定（或者是共同的指导决定）。希望这些指导方针能够帮助你了解规范化，帮助你作出更有见识的决定。