Database 识别功能依赖关系2

Database 识别功能依赖关系2,database,database-design,relational-database,functional-dependencies,Database,Database Design,Relational Database,Functional Dependencies,我对上一篇文章有点困惑,所以我找到了一个很好的例子,应该可以把事情弄清楚 hireDate和carReg是主键。因此,我的问题是,除了我在下面确定的依赖项之外,任何人都可以找到任何额外的功能依赖项……也欢迎修改: fd1 carReg -> make, model, outletNo, outletLoc fd2 custNo -> custName fd3 outletNo -> outletLoc fd4 model -> make (only if we assum

我对上一篇文章有点困惑,所以我找到了一个很好的例子,应该可以把事情弄清楚

hireDate和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的回答。。。。我的问题是:custName->custNo如何成为有效的FD?对于上面的关系,当然,一个客户名称正好映射到一个客户编号,但是凭直觉,我们知道可以向表中添加多个J SMith。如果是这种情况,则此FD无效,因为它形成1..*关系。我们真的能说卡斯特不知道这个事实吗?我们是否仅仅基于样本数据进行FD?或者我们是否考虑了可以添加的可能值?

一目了然

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
FDs回答了这样一个问题:“给定一个‘x’值,我是否知道一个且仅知道一个‘y’值?”。卡斯特诺决定雇佣谁。hireDate确定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->hireDate吗

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.

好吧,既然你征求了第二个意见,我就给你一个

第二种意见是第一种意见(CatCall)是完全正确的

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

只有您的用户才能以某种方式告诉您应用了哪些功能依赖项。(不要将此理解为你应该告诉你的用户他们应该告诉你“适用的FD是什么”,因为你的用户通常不知道该术语的含义。但是,适用的FD是什么,只能从用户提供给你的业务规范中派生出来。)


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

以下是我对关系的尝试:

函数依赖(FD)表示关系值或变量的特定属性。我们可以说它适用于或不适用于(满足于或不满足于)(适用于或不适用于)给定的关系值。当我们说它对关系变量有效或无效时,我们的意思是它对应用程序中可能出现的变量的所有可能值都有效或无效

另外,如果给我们一个值,并且我们被告知它满足的FDs是一个变量可以容纳它满足的FDs,那么根据该假设,变量的FDs是该值的FDs。(这有时被称为变量的“代表性数据”),但如果我们只是得到一个变量可能出现的值,那么我们只知道这一点

  • 值中不包含的FD也不包含在变量中
  • 两者的微不足道的FD都有效
    (表格S->S子集中的那些)
    (无论值是多少都必须保持的,仅基于属性)
    (值和变量必须相同)

另请参见。

您好,谢谢您的回复。我不同意你提到的一些FD..1)custName->custNo不能正确,因为有几个J Smith可以存在。2) make->model不可能是正确的,因为福特生产了几种车型。3) outletLoc->outLetNo不能正确,因为一个位置内可能有多个出口。4) carReg,custNo->hireDate和carRegs,custName->hireDate不可能是正确的,例如J Smith可能会在不同的日子将同一辆车租出去两次……我知道您的FD是针对所示关系的特定实例,但是FD不一定要保留域中所有可能的值吗…?您发布的示例数据支持我识别的每个FD。也许你应该再读一遍我写的内容,特别是开始“样本数据不具有代表性,这是一个问题…”的部分,以及开始“样本数据不具有代表性…”的部分,当你发现样本数据不具有代表性时,修复样本数据。例如,请参见我在“custName->custNo无效”之后发布的示例数据。当您的示例数据具有代表性时,自动化工具可以生成所有可能的5NF模式。如果您的样本数据不具有代表性,则所有赌注都将无效。是。示例数据成为测试数据的基础。它越能代表现实世界就越好。这也是你和你的客户之间共同理解的具体表现。(也就是说,你的客户可以签字确认。这并不意味着如果他们改变了约束条件,事情变得一团糟,他们不会责怪你,但他们可能无法就此赢得诉讼。)“相反,样本数据可能确实足以证明某个给定的FD肯定