13

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

例如，我为“用户”表提供了以下属性。
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, 艾琳, 03-01-2012, 用户, 电影
6, 斯坦, 03-01-2012, 用户, 电影
7, 艾萨克, 04-01-2012, 用户, 书籍

我不明白的部分是我如何确定功能依赖关系。我最初的感觉是有两个函数依赖，它们是：
user_id -> username, regDate, type, subscription
username -> user_id, regDate, type, subscription

但是，查看讲座幻灯片中的其他示例，我怀疑这是否正确。

4

4 回答 4

8

如果“用户名”既是唯一的又是必需的（唯一的而不是空的），那么它就是一个候选键。在关系建模中，一个候选键和另一个键之间没有理论上的区别。更具体地说，在关系建模中，没有理论上的理由选择一个候选键并将其标记为“主键”。一把钥匙就是一把钥匙。

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

于 2013-01-02T14:38:31.127 回答
7

功能依赖从理论角度定义如下（维基百科）：

给定一个关系 R，当且仅当每个 X 值都与一个 Y 值相关联时，R 中的一组属性 X 被称为在功能上确定另一组属性 Y，也在 R 中，（写作 X → Y）；则称 R 满足函数依赖 X → Y。

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

于 2013-01-02T14:41:06.623 回答
3

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

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

由于所有属性在功能上都依赖于键，因此如果存在任何其他功能依赖，您将自动具有传递依赖并违反 3NF。因此，“非关键”依赖可以作为发现规范化错误的危险信号。

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

于 2013-01-03T10:11:55.703 回答
2

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

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

show tables;

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

show columns;

FD可以描述如下：

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。

当然，在您的特定情况下，您可以省略几个步骤，并且您有列而不是Aiand Bj，但您希望能够理解这个想法。

于 2013-10-26T05:01:46.010 回答