好吧,我今天刚刚听说过,但我没理解。所以我不应该有Transaction表和Date列(因为更多的事务可以在同一天发生)但是我应该有一个Transaction和一个Date列,其中Date对事务有FK。那么重点是什么,而不是约会,我将重复FK。
示例:经纪人可以在任何日期进行交易。 (然后交易需要持有经纪人和日期信息)。
答案 0 :(得分:1)
退房:
http://en.wikipedia.org/wiki/Database_normalization#Normal_forms
交易日期无需规范化。
但是,假设交易与客户联系在一起,并且还必须保留客户详细信息 - 这种情况下规范化有助于减少数据冗余。
答案 1 :(得分:1)
假设您的日期表类似于我们数据仓库中的期间表,它的结构可能是这样的:
Field date, datatype date (not datetime) primary key
other fields include fiscal year and holiday information
然后你的交易表可能类似这样:
broker_id, foreign key to broker
date, foreign key to date
transaction time
other fields as necessary
你的问题是,“有什么意义?”。这种数据库设计使您可以轻松回答诸如“给我经纪人x过去5个会计年度的统计数据,按财政期间细分”的问题。
答案 2 :(得分:1)
标准化标量值(日期,数字等)通常是过度的。仅仅因为重复值并不意味着它们应该被标准化。仅重复与行的主键(例如地址)不直接相关的值应该是标准化的候选者。
如果您想要添加每个日期的不同表示(例如,月,季等),我可以看到标准化日期的唯一好处,而无需每次都进行数学计算。否则,在我看来,摔跤行为超过了优势。
答案 3 :(得分:1)
将日期属性移动到另一个表中并使其成为Transaction表中的外键与“规范化”无关。 考虑示例关系:
T{TransactionId,Date}
和依赖
{TransactionId}->{Date}
如果TransactionId是密钥,那么T已经满足第6范式。将日期移动到另一个表中,将其替换为另一个属性和/或使其成为外键将不会使T任何“更加规范化”而不是它已经。
属性值“重复”是否与标准化无关。您要在数据库模式中满足的功能依赖关系和连接依赖关系是什么问题。 “重复数据”是一个有时用非正式来描述功能依赖性的短语,但仅仅因为数据重复而需要进行分解是过于简单化的。
答案 4 :(得分:0)
使用日期不是一个理想的例子。考虑而不是与每笔交易相关的客户记录。您希望在每个事务行中存储客户的FK。您不想重复存储客户的姓名,地址和密码!