无法保留功能依赖性的分解 [英] Decomposition that does not preserve functional dependency

问题描述

什么时候BCNF分解不能保留功能依赖性...我试图说出R =（V，W，X，Y，Z）

解决方案

BCNF分解的重点是消除不是 键形式为 key的功能依赖项->其他所有内容

因此，如果表具有FD，例如A-> B，那么A不是键，则意味着您在表中重新存储冗余数据。因此，您将创建一个具有A和B列的新表，其中A为键，然后从原始表中删除B。

更改，您将不再遭受删除异常的困扰，也不必为了更改A-> B关系而更新多行。

因此，对于一个简单的天真示例，假设您有一个雇员表，其中包含列：

  employeeId名称jobTitle薪水
  

假设 jobTitle- >薪金，即，具有相同职称的每个人总是薪水相同。假设一个开发人员职称相当于90,000美元的薪水。如果您的数据库中有20个开发人员，那么为每行存储相同的$ 90,000冗余值将是很愚蠢的。因此，您从雇员表中删除了薪水列，并使用以下命令创建了新的薪水表： b $ b

然后，要获得雇员的薪水，请在薪水表中查找。

When can a BCNF decomposition not preserve functional dependency... I am trying to figure this out for say R=(V,W,X,Y,Z)

解决方案

The point of a BCNF decomposition is to eliminate functional dependencies that are not of the form key -> everything else

So if a table has a FD, say A -> B, such that A is not a key, it means you're storing redundant data in your table. As a result, you create a new table with columns A and B, with A being the key, then you remove B from your original table.

As a result of this change you would no longer suffer from deletion anomalies, nor would you have to update multiple rows just to make a change to the A -> B relationship.

So for a trivial, naive example, let's say you have a employee table with columns:

 employeeId   name   jobTitle    salary

Assume that jobTitle -> salary that is, everyone with the same job title always makes the same salary. Assume a jobTitle of "developer" equates to a salary of $90,000. If you have 20 developers in your database, it would be silly to store the same redundant value of $90,000 for each row. So, you drop the salary column from your employees table, and create a new salary table with:

 jobTitle_[key]   salary

Then, to get a salary on an employee, you look it up in the salary table.

这篇关于无法保留功能依赖性的分解的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！