AdventureWorks 有插入/更新/删除异常吗？答案

【问题标题】：AdventureWorks have Insert/Update/Delete anomalies?AdventureWorks 有插入/更新/删除异常吗？
【发布时间】：2012-03-22 14:20:23
【问题描述】：

AdventureWorks 表存在插入/更新/删除异常。这不被认为是糟糕的设计吗？

我们以下表为例。

Sales.SalesReason(SalesReasonID, Name, ReasonType, ModifiedDate)

其中 ReasonType 的类型为 nvarchar(50)

我们是否应该为 ReasonType 提供另一个表，所以模型看起来像这样：

SalesReason(SalesReasonID, Name, ReasonTypeId, ModifiedDate)  
ReasonType(ReasonTypeId, Name)

这种方式在更新 ReasonType 的名称时，应该只在一条记录上进行更改（防止更新异常）。此外，它将通过将可用类型保留在 db 中来防止删除/插入异常，而不管是否有与它们相关的实际数据。

我能谈谈你对这件事的看法吗？

【问题讨论】：

标签： database-design normalization

【解决方案1】：

将 ReasonType 删除到另一个表不会有任何改进。大概每个 ReasonType 仍然有一个 ReasonTypeId，因此您仍然有相同数量的潜在更新要做。我猜您假设您需要更新 ReasonTypeId 的频率低于 ReasonType。在不了解更多业务需求的情况下，这只是一种可能性，但与解决数据库设计理论通常关注的“更新异常”类型没有任何关系。

从归一化理论的角度考虑该表。如果依赖项是：

{SalesReasonID}->{Name}
{SalesReasonID}->{ReasonType}
{SalesReasonID}->{ModifiedDate}

如果 SalesReasonID 是唯一的键，则该表已经处于第五范式。所以它不需要任何进一步的分解。

The Relational Database Dictionary 对“更新异常”一词有这样的看法：

一个有点老式的术语，从来没有非常精确的定义，用于在不完全标准化的情况下可能会出错的事情数据库

Carlo Zaniolo 说：

在不了解异常情况的情况下无法给出明确的异常描述用户设想的操作

（ACM Transactions on Database Systems，第 6 卷，第 1 期，1981 年 3 月）

【讨论】：

感谢您的回答。我不确定您是否正确理解了我，可能我不是很清楚。我们以这个数据为例：SalesReason: (1,"Name1", "Some Reason", 1/1/2001), (2,"Name2", "Some Reason", 6/5/2001), (3,"Name3", "Some other reason", 7/6/2001), (4,"Name4", "Best Reason", 8/9/2001)
所以，我想将“某些原因”的名称更改为“具有全新名称的原因”。为了做到这一点，我必须对两行进行更新。这是一个简单的示例，但假设我有其他具有 ReasonType 列的表。如果我把它当作外键，我所要做的就是更新 ReasonType 表上那条记录的名称。此外，仅通过查看数据库，我真的不知道所有可用的和可能的原因类型。您对此有何看法？
刚刚找到一个支持AdventureWork异常的话题，请看一下：http://stackoverflow.com/questions/4824024/how-important-are-lookup-tables
@Poke，我认为这些是否是“异常”的问题并不有趣或重要（请参阅我编辑的答案）。鉴于我提到的“明显”的一组依赖关系，我认为我们可以说 SalesReason 表已经在 5NF 中。这并不意味着无法进行进一步可能令人满意的改进。
我明白你在说什么，谢谢。最后一件事，例如，如果业务需求使得 ReasonType 是一组众所周知的预定义值，那么创建一个单独的引用表是否有意义？