sql - 我没有得到数据库规范化 - 重复 FK 不是也在重复吗？

Question

好吧，我今天刚刚听说过，但我不明白。所以我不应该有带有日期列的事务表（因为同一天可能发生更多事务），但我应该有一个事务和一个日期列，其中一个日期对事务有一个 FK。那有什么意义，而不是日期，我将重复 FK。

一个例子：经纪人可以在任何日期进行交易。（交易则需要持有经纪人和日期信息）。

score 1 · Accepted Answer

标准化标量值（日期、数字等）通常是多余的。仅仅因为值重复并不意味着它们应该被规范化。只有与行的主键（例如地址）没有直接关系的重复值才应该是规范化的候选对象。

如果您想添加每个日期的不同表示形式（例如月份、季度等），而不必每次都进行数学运算，我可以看到标准化日期的唯一好处。否则，在我看来，drwabacks 超过了优势。

score 1 · Accepted Answer

假设你的日期表就像我们数据仓库中的周期表，它的结构可能是这样的：

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 个会计年度的统计数据，按会计期间细分”之类的问题

score 1 · Accepted Answer

将日期属性移动到另一个表中并使其成为 Transaction 表中的外键与“规范化”无关。考虑示例关系：

T{TransactionId,Date}

和依赖

{TransactionId}->{Date}

如果 TransactionId 是键，则 T 已经满足第 6 范式。将 Date 移动到另一个表中，用另一个属性替换它和/或使其成为外键不会使 T 比它已经“更规范化”。

属性值是否“重复”与规范化无关。重要的是您要在数据库模式中满足的功能依赖关系和连接依赖关系。“重复数据”是一个有时非正式地用于描述函数依赖关系的短语，但如果说仅仅因为数据重复而需要分解，则过于简单化了。

score 1 · Accepted Answer

查看：

交易日期无需标准化。

但是，想象一下 Transaction 与客户相关联，并且还必须保留客户详细信息 - 这是规范化有助于减少数据冗余的情况。

score 0 · Accepted Answer

使用日期并不是一个理想的例子。考虑与每笔交易相关的客户记录，而不是客户记录。您希望在每个交易行中存储客户的 FK。您不想重复存储客户的姓名、地址、密码！

5 回答 5