问题标签 [candidate-key]

I understand that a candidate key can not have NULL values. But a candidate key can itself be a combination of many attributes which are called prime attributes. Can these prime attributes have NULL as a value?

Regards,

我对如何计算一组 FD 下的闭包感到困惑。我的实际问题是

关系 R{A, B, C, D, E} 满足以下 FD：A→D AB → CE→B

在这组 FD 下计算 {A,E}+ 的闭包。还有什么是候选键？

这是我认为的答案，但我不知道我是否正确。我尝试在网上查找它，但没有任何帮助。所以希望这里有人可以帮助我。

候选键是 A。

这个对吗？另外我不知道为什么格式看起来很奇怪......我缩进了4个空格的代码......

我的作业有问题。我的老师根本没有教我好，我真的很想学习如何做这些问题。我不是在要求答案，我只是要求有人将我指向一个网站或问题，这将帮助我回答我自己的问题。这是我的问题。

现在我在网上找到的我应该将FD分解为AB→C AB→D CD→E CD→F，但我真的不知道从哪里开始。我知道候选键是可以访问所有属性的东西，所以我假设这个问题的候选键是 AB。我不知道如何确定它是否在 2NF 中。再一次，如果有人能指点我一些对我有帮助的事情。我不是在要求答案。

假设，我有一个包含列的表：

• person_id（主键）
• 名
• 姓
• 生日

我对组合 {first_name, last_name} 也有一个唯一约束（我知道更多人可以有相同的名字，但我想让我的示例保持简单）。我想知道这个表是否是第三范式。

我的推理（编辑前）：

• 所有字段只能包含原子值，因此表是第一范式。
• 候选键是 1) person_id, 2) [first_name, last_name]
• 唯一的非主要属性是生日。
• 属性生日在功能上不依赖于候选键 1 的一部分（无论如何这是不可能的，因为候选键 1 中只有 1 个属性）
• 属性生日在功能上不依赖于候选键 2 的一部分
• 因此，该表是第二范式。
• 属性生日（是/不是）非传递依赖于候选键 1
• 属性生日不传递依赖于候选键 1

问题（编辑前）：

我无法回答的问题是生日是否非传递依赖于 person_id。从功能上讲，这个身份证号码和生日完全没有关系。

1. 这是否意味着存在传递依赖（生日取决于 [first_name, last_name]，每个组合 [first_name, last_name] 映射到一个 id），因此不在 3NF 中？
2. 这是否意味着根本没有依赖关系，因此不在 3NF 中？
3. 我是否误解了难懂的语言，这张表是 3NF 中的吗？

我的推理（编辑后）：

• 如果你知道 person_id，你就知道他的名字、姓氏和他的生日，所以有 FD {person_id} -> {first_name}、{person_id} -> {last_name} 和 {person_id} -> {birthday}。
• 如果你知道一个人的名字和姓氏，你就知道他的 person_id 和生日，所以有 FD {first_name, last_name} -> {person_id} 和 {first_name, last_name} -> {birthday}。

• 如果您知道一个人的生日，那么您对他的 person_id 或姓名一无所知，因此没有从生日到另一个（一组）属性的 FD。

• 所有字段只能包含原子值，因此表是第一范式。

• 候选键是 1) {person_id}, 2) {first_name, last_name}
• 唯一的非主要属性是 {birthday}。
• {birthday} 属性在 CK 1 的一部分上不是 FD（无论如何这是不可能的，因为 CK 1 中只有 1 个属性）
• 属性 {birthday} 在 CK 2 的一部分上不是 FD

• 因此，该表是第二范式。

• 有一个 FD {person_id} -> {birthday}，所以属性 {birthday} 是非传递依赖于 CK 1

• 有一个 FD {first_name, last_name} -> {birthday}，所以属性 {birthday} 非传递依赖于 CK 2
• 因此，该表是第三范式。

有一个依赖 {person_id} -> {first_name, last_name} -> {birthday}，但由于还有一个直接依赖 {person_id} -> {birthday}，所以这个依赖不是传递的。

问题（编辑后）：

我没有从书中预定义的一组 FD，所以我不确定 FD 是否正确。有人可以确认这一点，或者如果他们看起来不正确，请展示我如何在这个实际示例中找到 FD？

第三个推理（第二次编辑）：

FD：

• 如果你只知道一个人的person_id，你就知道他的名字、姓氏和他的生日（不能有多个人具有相同的person_id）
  • FD：{person_id} -> {first_name}
  • FD：{person_id} -> {last_name}
  • FD：{person_id} -> {birthday}
• 不再需要考虑包含 {person_id} 的超集
• 如果你只知道一个人的名字，你就不知道这个人的任何其他字段（可以有多个人的名字相同）
  • 不是 FD：{first_name} -> {person_id}
  • 不是 FD：{first_name} -> {last_name}
  • 不是 FD：{first_name} -> {birthday}
• 如果您只知道一个人的姓氏，则您不知道此人的任何其他字段（可以有多个具有相同姓氏的人）
  • 不是 FD：{last_name} -> {person_id}
  • 不是 FD：{last_name} -> {first_name}
  • 不是 FD：{last_name} -> {birthday}
• 如果你只知道一个人的生日，你不知道这个人的任何其他字段（可以有多个人的生日相同）
  • 不是 FD：{birthday} -> {person_id}
  • 不是 FD：{birthday} -> {first_name}
  • 不是 FD：{birthday} -> {last_name}
• 如果你知道一个人的 first_name 和 last_name，你就知道他的 person_id 和他的生日（不能有多个人具有相同的 first_name 和 last_name）
  • FD：{first_name, last_name} -> {person_id}
  • FD: {first_name, last_name} -> {birthday}
• 不再需要考虑包含 {first_name, last_name} 的超集
• 如果您知道一个人的名字和生日，则您不知道此人的任何其他字段（可能有多个人的名字和生日相同）
  • 不是 FD：{first_name,birthday} -> {person_id}
  • 不是 FD：{first_name,birthday} -> {last_name}
• 如果您知道一个人的姓氏和生日，则您不知道此人的任何其他字段（可以有多个具有相同姓氏和生日的人）
  • 不是 FD：{last_name,birthday} -> {person_id}
  • 不是 FD：{last_name,birthday} -> {first_name}

正常形式：

• 所有属性只能包含单个值，因此表是第一范式。

• 查看 FD，有两个候选键：1) {person_id}, 2) {first_name, last_name}

• 唯一的非主要属性是 {birthday}。
• {birthday} 属性在 CK 1 的一部分上不是 FD（无论如何这是不可能的，因为 CK 1 中只有 1 个属性）
• 属性 {birthday} 在 CK 2 的一部分上不是 FD（即没有 FD {first_name} -> {birthday} 或 FD {last_name} -> {birthday}）

• 因此，该表是第二范式。

• 当存在满足 S -> X 和 X -> T 而不是（X -> S）的 X 时，S 可传递地确定 T

• 让 S = CK1 = {person_id} 和 T = {birthday}。当 X = {first_name, last_name} 时，唯一的 X 使得 S -> X 和 X -> T。然而，那么 X -> S 也成立。因此，S 非传递地确定 T。
• 让 S = CK2 = {first_name, last_name} 和 T = {birthday}。当 X = {person_id} 时，唯一的 X 使得 S -> X 和 X -> T。然而，那么 X -> S 也成立。因此，S 非传递地确定 T。
• 因此，该表是第三范式。

为了理解什么是第二范式，我阅读了一些文章，有些东西我不明白。

在客户表中的文章 中，它说它不在 2NF 中，因为.这里的主键我认为它的意思是 {customerId,EmployeeId}there are several attributes which don’t completely rely on the entire Customer table primary key

如果我们选择 {customerId,employeeId} 作为候选键，那么 Customername,customerCity,PostalCode 确实仅部分取决于候选键，因此不依赖于 2NF。但是，如果我们将候选键单独视为 customerId，那么 Customer 表中的所有列都完全依赖于 customerId 对吗？（因为 employeeId 依赖于 customerId ）。
同样，由于CustomerId单独可以是候选键，我们可以将 {CustomerId,EmployeeId} 作为候选键，因为候选键不能包含另一个候选键作为其一部分。

因此，如果我们仅将 customerId 作为候选键，该表不是 2NF 形式吗？
但是在文章中它说 2NF 形式的表应该服务于一个目的，这里这个客户表有两个目的。
To indicate which customers are called upon by each employee To identify customers and their locations.
然后我感觉这张表不在2NF。
那么这个表中的候选键是什么？

我的第二个问题在这篇文章中

这些表在 3NF 中。在表 TABLE_BOOK 中，候选键是 bookId 对吗？我们不能选择 {bookId,genereId} 作为候选键，对吗？如果选择它就不会在 2NF 中，因为价格不依赖于genreId。

有人可以帮我更好地理解标准化背后的这个理论吗

在 n 列的表中是否可以有超过 n 个候选键？我知道我可以在表中恰好有 n 个候选键 fe，其中每条记录的每条都不同。但是更多的候选键呢？

复合键是候选键池的子集吗？如果它是一个子集，那么为什么会有一个新的组合键术语，如果候选键也可以由多个列组成。

更新

1. 简单键 - 简单键是只有一个属性的键。

2. 候选键 - 关系的候选键是该关系的最小超级键；也就是说，一组属性，例如：

   一个。该关系没有两个不同的元组（即通用数据库语言中的行或记录），这些属性的值相同（这意味着属性集是一个超级键）

   湾。这些属性没有正确的子集（1）成立（这意味着集合是最小的）。

   我想坚持认为候选键是最小的超级键。

复合键 - 复合键是由两个或多个唯一标识实体出现的属性组成的键。

2. 一个复合键至少包含一个复合键和一个属性。复合键还可以包括简单键和非键属性。

现在复合键不满足最小超键候选键的条件。

我可能错了，但请帮助我理解这个概念。

正如创建此问题时所建议的那样，我确实检查了许多不同的相关帖子。我还从在线资源以及类似问题中完成了不同的示例问题。但是，我特别关注下面的问题。

给定以下关系 R 和 R 上的函数依赖集 S，找到 R 的所有候选键。展示你的工作。

最初，我将属性分为几组：仅在左侧、仅在右侧和两侧（分别为 D、ABCE 和 F）找到的属性。我也知道我应该尝试计算 D 的闭包。这就是我卡住的地方。乍一看，这似乎我无法解决这个问题，这不是真的。我还尝试计算 (AD)、(BD)、(CD) 和 (ED) 的闭包，因为我认为 D = D 的闭包。有什么想法吗？

早上好！我正在寻找一种技巧来维护可能发生一对多关系的唯一键列表。

问题

我正在使用一个可怕的非标准化数据库，不幸的是，重新设计是不可能的。我有一个 1NF 主表，其中包含许多类似于此的传递和部分键依赖项：

我经常需要提取一个唯一的GroupID 列表，但要求通常Group_Desc也需要该字段。不幸的是，由于上游数据输入限制不佳，此描述字段可能包含多个条目，Group这会导致重复，因为该Group字段在大多数数据提取中应该是唯一的。Group_Desc出于我的目的，只要我能保持 1Group对 1的关系，我并不真正关心我拉哪条记录Group_Desc。

我想出了一个丑陋的解决方案，Inline View每当我需要Group_Desc在更大的查询中引用该字段时，我将其称为一个，但这会影响我的性能：

问题

有没有人有一个性能友好的技巧来在同一个查询中重复拉回单行的多个值？我希望能够撤回Group并且只Group_Desc出现第一个。

我正在设想这样的事情：

一位开发人员提到该RANK函数是一种可能的解决方案，但我不知道如何使用它来消除值。

您能提供的任何帮助将不胜感激！

- - - - - - - - 编辑 - - - - - - - - - - -

因此，经过一些额外的分析，我能够指出我原来的相关子查询中的一个遗漏，这导致了一个过长的执行计划。通过添加一些额外的谓词，优化器能够创建一个更好的计划，将我的执行时间从大约 12 分钟更改为 2 分钟，这符合我的预期。

我对 Ponder Stibbons 下面建议的 Analytics 解决方案做了很多试验。他的解决方案非常优雅，我选择作为这个问题的答案，但是，我无法在这个特定查询中使用它，因为执行时间比我的原始解决方案慢得多，主要是因为我能够在我的相关子查询。

我毫不怀疑，在公平的比较中，Analytics 解决方案的运行与 Correlated SubQuery 解决方案相当或更好。感谢大家对这个问题的帮助！

我正在做一些教科书练习，要求找出关系 R 的候选键以及超级键。

我已经解决了候选键，但我不确定如何解决超级键？我只是有点困惑。

这是关系模式和功能依赖关系：

所以我发现 {A, AB} 是解决后的候选键。我只是不确定如何为此找到超级键。任何帮助将不胜感激。谢谢你们。