数据库关系异常
Database Relation Anomalies
我的任务是找出这种关系中的异常情况。我发现了一些插入、删除和更新异常。
Commission Percentage: the percentage of the total sales made by a salesperson that is paid as commission to that salesperson.
Year of Hire: the year the salesperson was first hired
Department Number: the number of the department where the salesperson works
Manager Name: name of the manager of the department
然而，我对我拉出的异常感到困惑。以下是声明：
公司中不能有同名的经理，因为经理实体除了姓名外没有主要标识符，名称在公司内可能重复。
请问上面的语句应该怎么表达，应该放在哪个(update/deletion/insertion)异常下？
谢谢
我还可以请求以下额外帮助吗：
- 您将如何更改当前设计以及您的新设计如何解决您在当前设计中发现的问题。
我目前的设计是把它分成三个关系：
Salesperson(salespersonNumber, salespersonName, commissionPercentage, YearOfHire, deparetmentNumber)
Product(productNumber, productName, unitPrice)
Manager(managerNumber, managerName, departmentNumber)
但是，我遗漏了数量实体。
数量需要 productNumber 和 salespersonNumber 的组合键。
我应该自己建立另一个关系吗？
Quantity(productNumber, salespersonNumber)
- 异常
在识别识别（潜在）异常时，您列出了受异常影响的相关属性（顺便说一句，您忘记了 Salesperson Name）。具体来说，您列出了依赖于键 (Salesperson Number, Product Number) 子集的属性，因此违反了 2NF。你走在正确的轨道上。
但是，请注意不要将属性与异常混淆。更新异常是 Bilstein 的 3 个实例中的 1 个被更改。 （假定的）功能依赖性 Salesperson Name depends on Salesperson Number 将被破坏，数据将不一致（销售人员编号 437 将与多个名称相关联）。请记住，规范化旨在消除冗余 关联 .
- 身份
按姓名识别经理的问题表明建模决策不佳。正如您所说，公司的一组经理并不是通过名字唯一标识的，因此逻辑数据模型与其建模的世界之间存在不匹配。只要我们对不同的管理器使用不同的值，就不会导致插入、更新或删除异常，但会妨碍管理器的方便识别。可能的改进是使用多个属性（抽象域通常很容易通过属性组合识别，但像人这样的自然域通常不是，例如 Manager Name, Birthdate 会更容易识别，但仍然不是一个好的解决方案），转将 Manager Name 转换为代理键（例如 Scott1、Scott2），或引入新的代理键（例如数字 ID）。
- 提议的改进
您提出的设计规范了原始 table 并解决了识别问题。这是一个很好的答案，除了两个问题：它不包括销售人员和经理之间的关联，并且在您的 Quantity 关系中，您忘记将数量作为相关属性包含在内。
到目前为止一切顺利，希望对您有所帮助。
我的任务是找出这种关系中的异常情况。我发现了一些插入、删除和更新异常。
Commission Percentage: the percentage of the total sales made by a salesperson that is paid as commission to that salesperson.
Year of Hire: the year the salesperson was first hired
Department Number: the number of the department where the salesperson works
Manager Name: name of the manager of the department
然而，我对我拉出的异常感到困惑。以下是声明：
公司中不能有同名的经理，因为经理实体除了姓名外没有主要标识符，名称在公司内可能重复。
请问上面的语句应该怎么表达，应该放在哪个(update/deletion/insertion)异常下？
谢谢
我还可以请求以下额外帮助吗：
- 您将如何更改当前设计以及您的新设计如何解决您在当前设计中发现的问题。
我目前的设计是把它分成三个关系：
Salesperson(salespersonNumber, salespersonName, commissionPercentage, YearOfHire, deparetmentNumber)
Product(productNumber, productName, unitPrice)
Manager(managerNumber, managerName, departmentNumber)
但是，我遗漏了数量实体。 数量需要 productNumber 和 salespersonNumber 的组合键。 我应该自己建立另一个关系吗？
Quantity(productNumber, salespersonNumber)
- 异常
在识别识别（潜在）异常时，您列出了受异常影响的相关属性（顺便说一句，您忘记了 Salesperson Name）。具体来说，您列出了依赖于键 (Salesperson Number, Product Number) 子集的属性，因此违反了 2NF。你走在正确的轨道上。
但是，请注意不要将属性与异常混淆。更新异常是 Bilstein 的 3 个实例中的 1 个被更改。 （假定的）功能依赖性 Salesperson Name depends on Salesperson Number 将被破坏，数据将不一致（销售人员编号 437 将与多个名称相关联）。请记住，规范化旨在消除冗余 关联 .
- 身份
按姓名识别经理的问题表明建模决策不佳。正如您所说，公司的一组经理并不是通过名字唯一标识的，因此逻辑数据模型与其建模的世界之间存在不匹配。只要我们对不同的管理器使用不同的值，就不会导致插入、更新或删除异常，但会妨碍管理器的方便识别。可能的改进是使用多个属性（抽象域通常很容易通过属性组合识别，但像人这样的自然域通常不是，例如 Manager Name, Birthdate 会更容易识别，但仍然不是一个好的解决方案），转将 Manager Name 转换为代理键（例如 Scott1、Scott2），或引入新的代理键（例如数字 ID）。
- 提议的改进
您提出的设计规范了原始 table 并解决了识别问题。这是一个很好的答案，除了两个问题：它不包括销售人员和经理之间的关联，并且在您的 Quantity 关系中，您忘记将数量作为相关属性包含在内。
到目前为止一切顺利，希望对您有所帮助。