数据库数据的规范化？答案

【问题标题】：Normalization of data for database?数据库数据的规范化？
【发布时间】：2013-11-10 21:45:14
【问题描述】：

1NF

客户 ID [名字 (PK)、姓氏 (PK)、电话、地址、城镇、邮政编码、电子邮件]

预订[日期（PK）、房间（PK）、类型、入住人数、夜数、到达时间]

ExtraID [项目名称、项目成本、日期 (FK)、房间 (FK)]

名字 + 姓氏 = 复合键

日期 + 房间 = 复合键

这样好吗？

还要进入 2NF，我必须确定部分依赖关系。据我所知，电话、地址、城镇、邮政编码和电子邮件都需要组合键的两个部分？那么这已经在 2NF 中了吗？

谢谢。

【问题讨论】：

名称作为主键从来都不是一个好主意。它们不能保证是唯一的，有时会发生变化。
@DanBracuk - 如果不是名字，那么电子邮件似乎是我最好的选择？制作一个由名字、姓氏和电子邮件组成的复合键怎么样 - 这实用吗？谢谢。
电子邮件也不是一个好的主键，因为它可能会改变，因此不建议成为复合键的一部分。顺便问一下，这是课堂作业吗？
好吧，这是我最后的想法——在 Customer_ID 表中创建一个合成键？是的，这是课堂作业，你为什么要问？
@Barboro37 我查看了您提供的数据，其中包括邮政编码。那是什么？那是独一无二的吗？至于我问这是否是一项作业，因为这里的一些人对作业特别是学生根本没有表现出努力的作业过敏;-) 但到目前为止你已经完成了你的工作，所以不用担心。

【解决方案1】：

使用合成密钥通常是个好主意。这与人有关，尤其是——没有一个自然键真正适合主键目的（我们可能会在这里讨论生物识别，但这有点离题了）。

因此，需要有一张客户表，其主键可以是 RDBMS 中的一个序列，也可以是 GUID (http://en.wikipedia.org/wiki/Globally_unique_identifier)。

应该有一个房间的历史表——价格往往会发生变化，以及其他房间的特征。我们可以将房间定义为唯一的物理对象，还可以决定房间在改造后是否保持不变（这有优缺点，这取决于业务角度）。

我会为 extras 创建一个单独的字典（我们可以在其中使用收据 ID 和 CDR 的引用），然后通过具有自己的主键的表将 extras 与预订链接，外键到预订的主键和外键额外主键的键。

现在，bookings 的表应该有它自己的主键，然后是客户的键、房间的键、日期（它们可以是日期类型，或者我们可以创建一个单独的时间维度，我们可以在其中列出各种有用的信息，例如是否高季节或如果有一些当地活动），入住人数，额外费用的总和（嗯，可能不是所有想法中最好的）和赠款总额。

您可以为每个表的键使用单独的序列，也可以只为所有的键使用一个序列——后者更优雅一些。

【讨论】：