问题标签 [candidate-key]

In accordance to the third normal form, we need to avoid dependencies on no key attribute.

So if i have a database of users

And for every user I have his username, a full name, country, and a social security number (which is unique), and another number which is unique for every user. I want to use the username as the PRIMARY KEY, however if you know a person social security number you can also get all the information about that user since its also 'UNIQUE'.

Doesn't it violate the third normal form? I could split it to two or more tables, for example remove SSN from User and put it in a different table

However now I have the same problem in this table, since two keys can be used as the 'PRIMARY KEY'.

Is it okay? or does it violate the third form, and if it does, is there any clever way to solve this?

我一直在尝试使用此示例找出第二范式和第三范式之间的区别。这些定义对我没有用......

这些是功能依赖项：

我的想法：它是第一和第二，但不是第三范式，因为候选键 A 不包含两列或更多列。但是 B 是传递依赖于 D 的。所以它不在第 3 位。

那是正确的吗？特别是 A 包含少于两列的论点？

请考虑下表定义...

表定义

其他表与该表的主键列有外键关系[id]。

我希望添加一个自引用外键约束，其中父文件夹 id 引用同一文件夹表中另一条记录的 Id 字段，但 UserId 也必须匹配...

自引用外键约束

...但我收到错误...

错误

我试图向表中添加复合唯一索引以提供候选键，但这不起作用，我仍然得到同样的错误。

唯一索引

如何创建超级键/候选键，[Id]以便[UserId]我可以添加自引用外键？请记住，将主键从单个整数转换为复合键会破坏引用文件夹表的其他表上的外键。这些外键不需要知道 UserId。

编辑：

根据 Dan Guzman 的建议/评论，添加数据库约束就可以了。这是约束的定义...

约束定义

我有一组功能依赖项：

V = {ABCDEF} F = {AB → CD,ABDE → F,BC → A,C → DF}

候选键是：{ABE, BCE} 规范覆盖是：{AB→ C, BC→ A, C→ DF} [这是我的想法，可能是错误的]

但是，正如您所见，候选键的一个属性 E 不在我的规范封面中，据我所知，候选键在规范封面中应该是相同的。如果您考虑阿姆斯特朗演算中的增强规则，我们可以说它是正确的，但我很困惑。属性 E 是否必须在规范封面中表示？

考虑一个描述大学辅导室预订的关系。每个教员都会指定一个人来处理该教员所有辅导班的预订。该人的电子邮件地址作为联系人提供给大学的预订系统。预订（b_date，b_starttime，b_endtime，unit_code，contact_person，room_no，tutor_id）。

练习：如果以下业务规则适用，则确定关系的候选键和主键：

1) 辅导课程可以是 1 小时或 2 小时。

2) 一个导师在一个给定的单元中只能教授一个辅导课。

3) 辅导班不设平行时段。

我的回答：候选键 1 是 (tutor_id, d_date)。我的建议键可以使每个元组唯一但是没有约束可以防止用户输入错误，如下所示：

导师ID | d_date | b_starttime | b_endtime | 单位代码 |

AAAA | 星期一 | 下午 6 点 | 晚上 8 点 | FIT1111 |

BBBB | 星期一 | 下午 6 点 | 晚上 7 点 | FIT1111 |

或者

导师ID | d_date | b_starttime | b_endtime | 单位代码 |

AAAA | 星期一 | 下午 6 点 | 晚上 8 点 | FIT1111 |

BBBB | 星期一 | 晚上 7 点 | 晚上 8 点 | FIT1111 |

因此，我的密钥不符合业务规则 3。然后，我向候选键（tutor_id、d_date、b_starttime、b_endtime）添加了另外 2 个属性。

我的问题是，当我们选择候选键时，除了保证每个元组的唯一性之外，我们是否需要防止用户可能输入错误而破坏业务规则？如果是，例如，当我们将 4 个属性（A、B、C、D）设置为主键时，DBMS 是否如上表那样阻止用户进行错误的输入操作？

谢谢。

I am having troubles when I trying to solve this question. Can someone help me?

Consider the relation schema R=(A, B, C, D) with an unknown set of functional dependencies: What is the maximum number of (candidate) keys that R may have? Design a set of functional dependencies on R to achieve the maximum number of (candidate) keys.

编写一个程序，该程序可以从一组超级键中输入并将所有可能的候选键从输入输出到输出文件（名为“candidate-keys”）。一个示例的超级键如下所示： ABCF CDF ACDF BCDF ABCDF ABCEF CDEF ACDEF BCDEF ABCDEF

包含所有可能候选键的输出：ABCF CDF

在示例中，我不明白如何从超级键中获取该结果，任何信息都会有所帮助。谢谢

Q. 已知对于 R(A,B,C,D,E)：

1. R 正好有 5 个超级键。
2. ABC 是候选键。
3. D 是非主属性。
4. ABE 和 ACE 不是超级键。

是否有另一个候选键？如果是这样，它是什么？

编辑：问题的问题是确定 R(A,B,C,D,E) 除了 ABC 中是否还有另一个候选键，考虑到 1,2,3,4 条件成立。

我的方法是，根据第二个条件 ABC 是候选键，那么超级键是：ABC、ABCD、ABCE、ABCDE。

但是第一个条件说正好有 5 个超级键，这意味着第 5 个超级键可能是另一个候选键。根据第 3 和第 4 条条件，唯一的其他 SK/CK 可能是 BCE，因为 ACE 和 ABE 不能是 SK。

但是如果 BCE 是一个候选密钥 BCDE 应该是一个超级密钥，这样总共有 6 个超级密钥并且违反了第一个条件。

我不确定我哪里出错了。请帮我分析一下。

我正在阅读PerformanceDBA对此SQL Question提供的精彩回复。

在PerformanceDBA 'Full Example' 中，表 'user' 和 'sport' 显示每个表的两个 PRIMARY KEY 。 笔记; 如果您仔细查看PerformanceDBA响应，您会注意到主键一由一个字段组成，而主键二由三个字段组成；复合键。

鉴于Microsoft T-SQL Server 不支持每个表多个主键（我不知道 SQL ANSI 也支持），我们如何实现PerformanceDBA提出的概念作为可行的Microsoft T-SQL解决方案（即，遵循Microsoft T -SQL语法）？

PerformanceDBA提供的信息是否有可能只是包含一个错字？他忽略了一个错误？

我最初的想法是（PerformanceDBA对SQL 问题的回答中的表定义，稍作修改以适应 T-SQL）：

感谢您的时间。

当没有任何只有 1 个属性的键时，我很难找到关系的候选键，所以我必须找到复合候选键。

我有关系R(A, B, C, D, E, F, G, H, I, J, K)和 FD：

A, B → D

A → C, E

B→G

G → H, 我

C → J, K

我必须找到 R 的键，但没有任何具有 1 属性的键。为了找到 RI 的所有候选键，计算 2 个字段的每个组合，或者我只是检查组合 {A，B} 是否是候选键，因为有一个具有该组合的 FD？

提前致谢