Question

我目前正在为一个大学项目工作，现在我对功能依赖项部分有点困惑。对于这个项目，我必须根据自己的项目规范创建逻辑数据模型，并确定功能依赖性。

例如，我为'User'表提供了以下属性。
R（user_id，用户名，regDate，类型，订阅）

主键： user_id
唯一键：用户名
外键：订阅

示例数据集可能类似于：

1，JohnS，01-01-2012，管理员，NULL
  2，PeterB，02-01-2012，版主，电影
  3，PeterA，02-01-2012，用户，电影
  4，Gary，03-01-2012，用户，书籍
  5，Irene，03-01-2012，用户，电影
  6，Stan，03-01-2012，用户，电影
  7，Isaac，04-01-2012，用户，书籍

我不明白的部分是我如何确定功能依赖性。我最初的感觉是有两个功能依赖，它们是：
user_id - ＆gt;用户名，注册日期，类型，订阅
用户名 - ＆gt; user_id，regDate，type，subscription

然而，看一下演讲幻灯片中的其他例子，我怀疑这是否正确。

Answer 1

如果“username”既是唯一的又是必需的（唯一且非空），那么它就是候选键。在关系建模中，一个候选键与另一个候选键之间没有理论上的差异。更具体地说，在关系建模中，没有理论上的理由来选择一个候选密钥并将其标记为“主密钥”。钥匙是钥匙。

所以你是对的。这里有两个功能依赖。（或8，如果您将右侧分解为单个列。user_id -> username，user_id -> regDate等。）

Answer 2

功能依赖性从理论角度定义如下（Wikipedia）：

给定关系R，R中的一组属性X在功能上被称为确定另一组属性Y，也在R中，（写成X→Y）如果，并且只有当每个X值恰好与一个Y值相关联时; [R 然后据说满足功能依赖性X→Y。

从技术角度来看，您正在尝试查找唯一标识其他属性的属性。作为快捷方式，确定候选键以及依赖它们的属性。您的示例是正确的，因为username, regDate, type, and subscription都取决于user_id的值。如果username是唯一的且不为空，则它是候选键并且还标识属性集。

Answer 3

除了其他人所说的，如果属性（或一组属性）是候选键，那么 all 属性必须在功能上依赖于它。

“功能依赖”A-> B只是意味着没有两个不同的B值与相同的A相关。Wikipedia给出了稍微更正式的定义，但实质上就是它。
由于键必须是唯一的，即使两个元组包含某些属性的相同值，键值也必须不同。因此，不同的值永远不会与相同的键值相关。

由于所有属性在功能上都依赖于密钥，因此如果存在任何其他功能依赖关系，则会自动拥有transitive dependency并违反3NF。因此，“非关键”依赖关系可以作为发现规范化错误的红色标记。

您也可以从相反的方向考虑它：首先确定哪些功能依赖在您的域中有意义，然后使用它们来识别哪些属性可以作为键。

Answer 4

我将假设您使用的是MySQL，但如果没有，您可以在任何其他RDBMS中实现您的想法。

运行以下命令以获取所有表：

show tables;

然后迭代所有表并为每个表运行以下命令：

show columns;

FDs可以描述如下：

Determinant -> Dependent,
Determinant = {A1, ..., Am},
Dependent = {B1, ..., Bn}

其中Ai和Bj是列。您需要为Determinant和Dependent生成所有可能的方案。对于每个方案，您将需要查看是否存在至少两个单独的记录，其中行列式列匹配且至少一个从属列不匹配。如果是，则该场景不是FD，否则它是FD。示例：假设m = 3且n = 2：

select count(*) from mytable t1, mytable t2 where ((t1.A1 = t2.A1) and (t1.A2 = t2.A2) and (t1.A3 = t2.A3)) and ((t1.B1 <> t2.B1) or (t1.B2 <> t2.B2))

将返回打破FD规则的记录数。如果值为0，则场景为FD。

当然，在您的特定情况下，您可以省略几个步骤，而您的列不是Ai和Bj，而是希望您理解这个想法。

如何确定功能依赖性

4 个答案: