【问题标题】:Identifying Functional Dependencies II识别功能依赖 II
【发布时间】:2018-04-24 02:51:09
【问题描述】:

我对上一篇文章有​​点困惑,所以我找到了一个很好的例子,它应该可以解决问题。

hiredDate 和 carReg 是主键。所以我的问题除了我在下面确定的那些之外,任何人都可以找到任何额外的功能依赖项......也欢迎修改:

fd1 carReg -> make, model, outletNo, outletLoc
fd2 custNo -> custName
fd3 outletNo -> outletLoc
fd4 model -> make (only if we assume a model name is unique to a make)
fd5 carReg, hireDate -> make, model, custNo, custName, outletNo, outletLoc 

我不确定以上是否正确,我相信还有更多。请有人能帮我最终理解这些该死的FD!

编辑:基于 catcall\'s answer.... 我的问题是这样的: custName -> custNo 如何是有效的 FD?对于上述关系,当然,一个客户名称映射到一个客户编号,但凭直觉,我们知道可以将多个 J SMith 添加到表中。如果是这种情况,则此 FD 无效,因为它形成 1..* 关系。我们真的可以说 custName -> custNo 知道这个事实吗?我们只是基于样本数据的 FD 吗?或者我们是否考虑了可以添加的可能值?

标签: database database-design relational-database functional-dependencies


【解决方案1】:

乍看上去 。 . .

custName -> custNo
model -> make
outletLoc -> outletNo
carReg, custNo -> hireDate
carReg, custName -> hireDate

我敢肯定还有其他人。示例数据不具有代表性,当您尝试从数据中确定功能依赖关系时,这是一个问题。假设您的样本数据只有一行。

carReg    hireDate make  model  custNo  custName  outletNo  outletLoc
--
MS34 0GD  14/5/03  Ford  Focus  C100    Smith, J  01        Bearsden

FD 回答了这样一个问题:“给定 'x' 的一个值,我是否只知道 'y' 的一个值?”基于该单行样本数据集,每个属性都决定了其他所有属性。 custNo 决定了租用日期。 hiredDate 确定 outletLoc。 custName 确定模型。

当样本数据不具有代表性时,很容易发现无效的 FD。您需要更具代表性的样本数据来清除一些无效的函数依赖关系。

custName -> custNo isn't valid ('C101', 'Hen, P')
carReg, custNo -> hireDate isn't valid ('MS34 0GD', 'C100', '15/7/04')
carReg, custName -> hireDate isn't valid ('MS34 0GD', 'Hen, P', '15/8/03')

您可以使用 SQL 调查示例数据中的函数依赖关系。

create table reg (
  CarReg char(8) not null,
  hireDate date not null,
  Make varchar(10) not null,
  model varchar(10) not null,
  custNo char(4) not null,
  custName varchar(10) not null,
  outletNo char(2) not null,
  outletLoc varchar(15) not null
);

insert into reg values
('MS34 OGD', '2003-05-14', 'Ford', 'Focus', 'C100', 'Smith, J', '01', 'Bearsden'),
('MS34 OGD', '2003-05-15', 'Ford', 'Focus', 'C201', 'Hen, P', '01', 'Bearsden'),
('NS34 TPR', '2003-05-16', 'Nissan', 'Sunny', 'C100', 'Smith, J', '01', 'Bearsden'),
('MH34 BRP', '2003-05-14', 'Ford', 'Ka', 'C313', 'Blatt, O', '02', 'Kelvinbridge'),
('MH34 BRP', '2003-05-20', 'Ford', 'Ka', 'C100', 'Smith, J', '02', 'Kelvinbridge'),
('MD51 OPQ', '2003-05-20', 'Nissan', 'Sunny', 'C295', 'Pen, T', '02', 'Kelvinbridge');

型号决定品牌吗?

select distinct model 
from reg
order by model;

model
--
Focus
Ka
Sunny

三个不同的模型。 . .

select model, make
from reg
group by model, make
order by model;

model   make
--
Focus   Ford
Ka      Ford
Sunny   Nissan

是的。每个型号都有一个。根据样本数据,模型 -> 制造。

carReg、custName -> 雇佣日期吗?

select distinct carReg, custName
from reg
order by custName;

carReg
--
MH34 BRP  Blatt, O
MS34 OGD  Hen, P
MD51 OPQ  Pen, T
MS34 OGD  Smith, J
NS34 TPR  Smith, J
MH34 BRP  Smith, J

carReg 和 custName 的六种不同组合。

select carReg, custName, hireDate
from reg
group by carReg, custName, hireDate
order by custName;

carReg  custName  hireDate
--
MH34 BRP  Blatt, O  2003-05-14
MS34 OGD  Hen, P    2003-05-15
MD51 OPQ  Pen, T    2003-05-20
MH34 BRP  Smith, J  2003-05-20
NS34 TPR  Smith, J  2003-05-16
MS34 OGD  Smith, J  2003-05-14

是的。 carReg 和 custName 的每个组合都有一个租用日期。因此,根据样本数据,{carReg, custName} ->hireDate。

【讨论】:

  • 你好,谢谢你的回复。我不同意你提到的一些 FD..1) custName -> custNo 不可能是正确的,因为可以存在几个 J Smiths。 2) 制造 -> 型号不可能正确,因为福特制造了几种型号的汽车。 3) outletLoc -> outLetNo 不正确,因为一个位置内可能有许多出口。 4) carReg, custNo ->hireDate AND carRegs, custName ->hireDate 不正确,例如 J Smith 可以在不同的日子租用同一辆车两次...
  • 我认识到您的 FUND 是针对关系中显示的特定实例的,但是 FD 是否必须为域内的所有可能值保留...?
  • 您发布的示例数据支持我确定的每个 FD。或许你应该再看一遍我写的,尤其是“样本数据不具有代表性,这是个问题……”开头的部分。以及以“当样本数据不具有代表性时……”开头的部分
  • 当您发现您的样本数据不具有代表性时,请修复样本数据。例如,请参阅我在“custName -> custNo 无效”之后发布的示例数据。当您的样本数据具有代表性时,自动化工具可以生成所有可能的 5NF 模式。当您的样本数据不具有代表性时,所有赌注都将失败。
  • 是的。样本数据成为您的测试数据的基础。它越能代表现实世界越好。它也是您和您的客户之间共同理解的具体表现。 (也就是说,您的客户可以签署它。这并不意味着如果他们改变约束并且事情变成梨形,他们不会责怪您,但他们可能无法赢得有关这方面的诉讼。)
【解决方案2】:

好吧,既然你要求第二个意见,我会给你一个。

第二个意见是第一个(CatCall's)是完全正确的。

样本数据不足以识别/确定数据中的功能依赖关系。识别/确定数据中的功能依赖关系所需的是用户需求、数据库旨在支持的业务环境的描述/定义,......

只有您的用户才能以一种或另一种方式告诉您应用了哪些功能依赖项。 (不要将此解释为您应该告诉用户他们应该告诉您“适用的 FD 是什么”,因为您的用户通常不知道该术语的含义。但是,适用的 FD 是什么,可以仍然来自用户提供给您的业务规范。)

(相反,PS 样本数据可能确实足以证明某个给定的 FD 肯定不适用。但这不是你的问题。)

【讨论】:

  • “相反,样本数据可能确实足以证明某个给定的 FD 肯定不会适用”-> 好的,因为样本数据不足以说明 custName -> custNo 是错误的,这样说是否正确这组数据,它是有效的FD吗?
  • 不完全正确。说这组特定的数据满足 FD 是正确的。说FD是“有效的”,只是对语言的草率和不精确的使用。说FD适用(“坚持”或类似的东西)是说某个规则(唯一性规则)是有效的在现实世界.说FD Name->ID适用,也就是说 Name 是您在业务中打交道的人的独特属性(这可能是一个谎言)。说 FD 是“有效的”(对不起,如果这看起来冒犯)是冗长的,没有说什么。
  • 如果我的评论似乎过于挑剔,请考虑一下:(a)计算机是否是精确机器,从某种意义上说,它们总是如此正如他们被告知的那样? (b) 如果这个问题的答案是“是”,那么它对那些为这些计算机编程的人来说有多重要准确地说?
【解决方案3】:

FD(函数依赖)表示关系的某个属性值或变量.我们可以说它对给定关系成立或不成立(满足或不满足)(对或不满足)给定关系价值.当我们说它对关系成立或不成立时多变的我们的意思是它对应用程序中可能出现的变量的每个可能值都成立或不成立。

此外,如果我们被赋予一个值我们被告知,它满足的 FD 是可以容纳它的变量满足的 FD然后由那个假设变量的 FD 是值的 FD。 (这有时被称为变量的“代表数据”。)但是如果我们只是给定一个变量可能出现的值,那么我们只知道

  • FD保持值也不在变量中
  • 琐碎的两者都持有的FD
    (形式 S -> S 的子集)
    (无论值如何都必须保持,仅基于属性)
    (值和变量必须相同)

另见this answer

【讨论】:

    【解决方案4】:

    这是我对人际关系的尝试:

    【讨论】:

    • 这些many:1“关系”是外键在对原作的一些分解中,不功能依赖在原件中成立(这将证明分解是合理的)。
    猜你喜欢
    • 2011-08-12
    • 2013-03-25
    • 2011-12-08
    • 2016-08-13
    • 1970-01-01
    • 2021-07-05
    • 2013-09-10
    相关资源
    最近更新 更多