【问题标题】:Database normalization - 4NF数据库规范化 - 4NF
【发布时间】:2019-01-26 12:56:16
【问题描述】:

我有以下关系,我需要将其规范化为4NF

Relation

首先,我尝试找到所有保留的 FD 和 MVD。

AB ->> C (MVD)
C -> D (FD)  
D -> E (FD)
ABC -> F (FD)

接下来,使用这些依赖项,我设法找到了候选键:ABC。 让我知道我到目前为止所做的是否正确。另外,在 4NF 中有一个多值依赖可以吗?喜欢AB ->> CABC -> F

谢谢。

【问题讨论】:

  • 您是在规范化该值还是保持该值的变量?如果是一个变量,那么一个值只能告诉我们不成立的 FD 和 MVD,而不是那些成立的 - 除非我们被告知该值是专门设计的。此外,当 FD 持有某些其他 FD 和 MVD 时。此外,我们需要知道所有持有知道 CK 的 FD,所以如果我们得到一些但不是所有的 FD 并且预计会得到 CK,那么我们一定被告知 FD 形成了一个 cover .等等。也许你可以明白为什么家庭作业应该给出确切的作业,并在引用教科书之后显示所有工作步骤。
  • 请使用文本,而不是图像/链接,用于文本,包括表格和 ERD。仅使用图像来增强文本或提供文本不能提供的内容。仅使用链接来增加文本和图像;让您的问题自成一体。

标签: database database-normalization functional-dependencies bcnf


【解决方案1】:

一般的依赖关系描述了对数据的重要约束,例如函数依赖X → A意味着X的某个值唯一确定A的某个值(即每次我们在一个元组中找到X 的某个值,我们总是会找到相同的 A 值)。此类约束无法通过表的(几)行来推断,其中数据的含义是未知的。

充其量,我们可以推断出一组可能的函数依赖关系包含在表的那个特定实例中,希望(但没有任何特殊原因)那些函数依赖依赖关系将保留在表的每个实例上,这是我们可以“规范化”关系的唯一条件(而不是简单地找到存储该表的特定实例的非冗余方式)。

例如,在您的情况下,由于表的行数很少,因此可以将许多功能依赖关系视为包含在其中,例如至少以下内容:

F → AB
E → AD
D → AE
C → ADE
B → A
EF → ABCD
DF → ABCE
CF → ABDE
CB → ADEF

(而ABC → F 可以从CB → ADEF 派生,而AB →→ C 不成立)。

如果我们应该对该实例应用归一化算法(例如 3NF 的合成算法),我们将把关系分解为大量子模式:

R1(AB), R2(BCF), R3(CD), R4(ADE), R5(CEF),

具有六个属性的表的五个关系!

【讨论】:

  • 为什么 AB →→ C 不成立?因为对于每一个 AB 都有不止一个对应的 C 值。
  • 如果依赖 AB →→ C 成立,那么 AB →→ DEF 也成立,并且 DEF 的值应该独立于 C 的值。但这意味着对于每个不同的 C 值具有某些 AB,同一个 AB 应该重复 DEF 的不同值(参见wikipedia)。
  • 好的,我明白了。还有一个问题,如果有多个候选键,我应该在执行规范化时全部使用它们还是只选择一个作为主键?
  • @Robert,这取决于您使用的算法。例如对于 3NF 的合成算法,如果最后没有关系包含原始关系的候选键,那么您必须添加一个具有一个候选键(任何候选键)的新关系。
猜你喜欢
  • 2012-03-08
  • 2012-10-08
  • 2012-06-21
相关资源
最近更新 更多