【问题标题】:3NF normalization3NF归一化
【发布时间】:2012-05-19 23:56:32
【问题描述】:

我必须在 3NF 中规范化以下内容:

Service (Service_ID, Service Item, service item cost, date of service)  
Customer (customer ID, customer name, customer telephone number, customer address)  
Vehicle (Vehicle ID, vehicle make, vehicle model, vehicle year)  
Parts (Parts ID, part code, part describtion, part cost)

标准化后得到的结果:

Service (Service_ID (PK), Service Item, service item cost, date of service, Vehicle_ID (FK))  
Customer (customer ID (PK), customer name, customer telephone number, customer address)  
Vehicle (Vehicle ID (PK), vehicle make, vehicle model, vehicle year, Customer_ID (FK))  
Parts (Parts ID (PK), part code, part describtion, part cost, Vehicle_ID (FK))

你认为我完全走错了吗?

【问题讨论】:

  • 我假设这是家庭作业?规范化是基于函数依赖的——你还没有向我们展示任何东西。您的分组看起来合乎逻辑,但可能并不“正确”。
  • 规范化通常是将表划分为较小的表,您将外键添加到表中。问题不是很清楚,编辑也很无奈。但是,规范化后的表看起来是正确的,并且不包含冗余数据。
  • 嗯 - 它似乎没有保存冗余数据,但这取决于功能依赖性。如果两辆不同的汽车可以有相同的零件,那么他/她建议的表结构将不是 3NF,因为我们将有重复的零件记录——每辆车都有一个记录。

标签: database database-design 3nf


【解决方案1】:

开始关系

  • 服务(Service_ID、服务项目、服务项目成本、服务日期)

结束关系

  • 服务(Service_ID (PK)、服务项目、服务项目成本、服务日期、Vehicle_ID (FK))

高达 3NF 的归一化识别了几种函数依赖关系,并通过投影去除了麻烦的依赖关系。 (通过创建另一个关系。)如果您通过投影删除关系中一个麻烦的依赖关系,它总是以比开始时更少的属性结束。

您的关系“服务”以 更多 列结束,而不是您开始时的列。虽然记录服务适用于哪辆车是有意义的,但这可能与标准化无关,仅基于您开始使用的内容。

识别丢失的外键虽然无疑是一件重要的事情,但它本身并不是规范化的一部分。从 {Service_ID, Service Item, service item cost, date of service, Vehicle_id, vehicle make, vehicle model, vehicle year} 开始,标准化会表示 Service_ID -> Vehicle_ID 和 Vehicle_ID -> vehicle make, vehicle model, and vehicle年。这是一个传递依赖。为了修复这种传递依赖,

  • 这四列将被投影,形成一个新关系(您的 Vehicles 表),
  • 车辆制造商、车辆型号和车辆年份将从起始关系中删除,使其属性比开始时少 3 个。

而且服务关系中还有一个vehicle id。

所以你的老师给你的作业要求你规范化。它要求您确定其他人在哪里搞砸了规范化,并修复它。这种分配没有错,但称其为规范化有很多错误。 (恕我直言)

【讨论】:

    猜你喜欢
    • 2013-03-21
    • 2016-08-18
    • 2013-11-22
    • 2011-08-26
    • 2016-03-19
    • 2021-02-20
    • 1970-01-01
    • 2016-09-27
    相关资源
    最近更新 更多