数据库第三范式

有人可以确保我的数据库是第三范式，如果不是，解释为什么不呢？我需要数据库只有3个表。所以在这里，它是：数据库第三范式

Customer No. (PK)  Store No. (PK)  Sale No. (PK) 
Name     Location   Customer No. (FK) 
Telephone    Revenue   Store No. (FK) 
Address         Total 
Purchases($)        Paid 
Store No.

来源

2013-02-09 Steve2056726

这不是 - 在“购买”将是一个持续的。如果我改成了总采购会的问题被解决了应该有自己的表（也许是链接到销售表？） – 2013-02-09 09:06:29

增量值的列表？ – Steve2056726 2013-02-09 09:25:59

这是你的三个表应该是什么：表1：客户

Customer No. (PK) 
Name 
Telephone 
Address

然后表2：商店

Store no. (PK) 
Location

则表3：销售

Sale No. (PK) 
Customer No (FK) 
Store No (FK) 
Total 
Paid_yes_no

如果您试图通过Paid列追踪部分付款等，那么它将是一个单独的表格（以及更复杂的数据库）。但是，如果您的Paid栏只是表明账单是否已经支付，上述应该可以工作。

也许你需要一个Date领域有作为？

来源

2013-02-09 09:36:43

好吧，我已经打算付费列是一个布尔数据类型。谢谢你的帮助！ – Steve2056726 2013-02-09 09:52:18

标记我的答案正确，然后！ :) – 2013-02-09 09:53:31

有几个问题，其中一些可能是因为规范是家庭作业，而不是真实的世界。

在客户Store No.是一个重复的列这是合理的期望，与多个存储业务有谁使用多个商店的客户 - 除非你的规范说，否则在这种情况下，分类（命名）应该扩大，可以考虑第一家店铺号码或家店铺号码改为。如果它仍然存在，它应该被标记为外键。
在客户表Purchases($)是这将改变其他数据依赖。由于它来源于其他信息，所以不应该存储它。
Address不是一列 - 它有多个部分，如街道，城市，州，国家&邮政编码可能需要额外的表格细节，以完全满足第二范式。同样Telephone不可能只是一个数字。

每次你需要知道应该出现一次且唯一的事情。如果你能从别的东西算出来，你应该这样做，而不是存储答案。在现实世界中，您有时可能会将某些信息缓存在表中或进行批处理以获得性能，但这些信息稍后会应用并且仅在必要时应用。

数据库规范化的简要概述为http://databases.about.com/od/specificproducts/a/normalization.htm，你或许应该通过再加工项目前。

来源

2013-02-09 10:27:56

数据库第三范式

回答

相关问题