Question

AdventureWorks表具有插入/更新/删除异常。这不是一个糟糕的设计吗？

我们以下表为例。

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

其中ReasonType的类型为nvarchar（50）

我们不应该有另一个ReasonType表，所以模型看起来像这样：

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

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

我能否对此事有所了解？

Answer 1

将ReasonType移除到另一个表不会改善任何事情。据推测，每个ReasonType仍然会有一个ReasonTypeId，因此您仍然可以进行相同的潜在更新次数。我猜你假设你需要比ReasonType更频繁地更新ReasonTypeId。不了解更多关于业务需求的可能性，但它与解决数据库设计理论通常关注的“更新异常”类型没有任何关系。

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

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

如果SalesReasonID是唯一的密钥，那么该表已经是第五范式。所以它不需要任何进一步的分解。

The Relational Database Dictionary有关“更新异常”一词的说法：

一个有点古老的术语，从来没有非常精确地定义在不完全正常化的情况下可能出错的事情数据库

Carlo Zaniolo说：

在不知情的情况下，不能给出明确的异常描述用户设想的操作

（ACM Transactions on Database Systems，Vol.6，No。1，1981年3月）

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

1 个答案: