【问题标题】:transformation into BCNF with only a relation and no data转换为只有一个关系而没有数据的 BCNF
【发布时间】:2021-05-15 20:25:35
【问题描述】:

我必须将以下关系转换为 BCNF。但该练习并未表明主要决定因素是什么。没有下划线。我知道不同的步骤,但是我在编写函数依赖项时遇到了一些困难,因为我只有关系而没有数据...... 你能帮我或指导我如何开始

将以下关系转换为 BCNF。对函数依赖做出并陈述适当的假设,并展示转换的步骤

INVOICE (Number,CustomerName,CustomerNumber,CustomerAdress,ItemNumber,ItemPrice,ItemQuantity,SalespersonNumber,SalespersonName,Subtotal,Tax,TotalDue)

如果我们只有上面的关系,我的问题是如何编写函数依赖

我试过了,但我不确定,我只是通过猜测来做到这一点

Number ---> (CustomerName,CustomerNumber,CustomerAdress)

客户编号--->(客户名称,客户地址)

ItemNumber---> (Number,ItemPrice)

(Number,ItemNumber)--->(ItemQuantity,SalespersonNumber,SalespersonName,Subtotal,Tax,TotalDue)

谢谢

【问题讨论】:

  • 这能回答你的问题吗? Finding functional dependency
  • 现在您只是要求我们用定制的教程重写教科书并完成您的(家庭)作业,而您没有对答案进行任何研究。请参阅How to Ask,点击谷歌搜索“stackexchange 作业”和投票箭头鼠标悬停文本。根据教科书/参考资料显示您的工作步骤,并在您遇到问题的第一个地方提出 1 个经过研究的特定非重复问题。引用您所依赖的定义、定理、算法和启发式方法。所有步骤也是常见问题解答。带有和不带有“site:stackoverflow.com”的 Google。
  • 您关系中的编号是发票编号,而不是客户编号。隐含客户编号。这就是为什么您永远不应该有一个名为 Number 或 ID 的数据库列的主要原因。太混乱了,
  • 关系变量(表)在任何有效元组(行)集合的特定 NF 中,包括空集。 NF 在逻辑设计级别上确定,在 SQL CREATE TABLE 执行之前。坚持逻辑,请参阅 Renzo 的回答。
  • 我不是要求做作业。我发布了整个问题并说我的问题是编写功能依赖项并且我编写了它们!我的问题是,即使我们没有要分析的数据,是否可以编写这些依赖项

标签: dataframe database-design rdbms database-normalization functional-dependencies


【解决方案1】:

如果人们了解不同属性的含义,通常可以解决此类练习,因为函数依赖关系涉及数据的含义。

我们可以猜想,在你的例子中,所有前缀为“Customer”、“Item”和“Salesperson”的属性代表不同对应实体的属性,而其他属性与发票相关,这涉及从(单一?)销售人员向(单一?)客户销售(单一?)产品。当然,这只是一个猜测,可能是非常错误的。

在这些假设下,以及带有后缀 Number 的属性唯一标识某个实体的假设下,我们可以定义以下函数依赖关系作为关系 FD 的覆盖:

CustomerNumber -> CustomerName, CustomerAddress
ItemNumber -> ItemPrice, ItemQuantity
SalespersonNumber -> SalespersonName
Number -> CustomerNumber, ItemNumber, SalespersonNumber, Subtotal, Tax, TotalDue

如果这是正确的,那么关系的 BCNF 分解可能如下:

Customers (CustomerNumber, CustomerName, CustomerAddress)
Items (ItemNumber, ItemPrice, ItemQuantity)
Salespersons (SalespersonNumber, SalespersonName)
InvoiceData (Number, CustomerNumber, ItemNumber, SalespersonNumber, Subtotal, Tax, TotalDue)

当然,我再说一遍,这只是基于(假定的)命名约定的猜测。

例如,打破上述假设的约定,另一种可能是 ItemQuantity 不是 Item 的属性,而是 Invoice 的属性。

因此,在这种情况下,FD 的封面应该如下:

CustomerNumber -> CustomerName, CustomerAddress
ItemNumber -> ItemPrice
SalespersonNumber -> SalespersonName
Number -> CustomerNumber, ItemNumber, ItemQuantity, SalespersonNumber, Subtotal, Tax, TotalDue

如果这是正确的,那么关系的 BCNF 分解可能如下:

Customers (CustomerNumber, CustomerName, CustomerAddress)
Items (ItemNumber, ItemPrice)
Salespersons (SalespersonNumber, SalespersonName)
InvoiceData (Number, CustomerNumber, ItemNumber, ItemQuantity, SalespersonNumber, Subtotal, Tax, TotalDue)

哪个是正确答案?好吧,除非确定数据的含义,否则没有人能说出来。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-01-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-07-31
    • 2020-07-20
    相关资源
    最近更新 更多