我正在阅读候选键和复合键.我才知道
对于复合键,我已经引用了这个链接
如何使用SQL Server Management Studio创建复合键?
因此,当候选键和复合键都是列的组合时,它们可以作为主键.那究竟是什么区别?你能用例子解释一下吗?
在这里我发现了这个:
定义:数据库表中的决定因素是可用于确定分配给同一行中其他属性的值的任何属性.
示例:考虑具有employee_id,first_name,last_name和date_of_birth属性的表.在这种情况下,字段employee_id确定剩余的三个字段.名称字段不确定employee_id,因为公司可能有多个具有相同名字和/或姓氏的员工.同样,DOB字段不确定employee_id或名称字段,因为多个员工可能共享同一个生日.
候选键的定义是否也适用?
我一直在研究这个问题,似乎无法找到答案.
R = (A, B, C, D, E)
Run Code Online (Sandbox Code Playgroud)
功能依赖是:
A => B
ED => A
BC => E
Run Code Online (Sandbox Code Playgroud)
然后它将候选键列为:
ACD, BCD, CDE
Run Code Online (Sandbox Code Playgroud)
这些候选密钥是如何从上述FD中获得的?
同样,在哪里R = (A, B, C, D):
功能依赖是:
D => B
AB => D
AB => C
C=> A
Run Code Online (Sandbox Code Playgroud)
然后它将候选键列为:
AB, BC, CD, AD
Run Code Online (Sandbox Code Playgroud)
同样,我的问题是我不确定候选密钥是如何从FD中派生出来的?
提前感谢你.
为了理解什么是第二范式,我正在阅读一些文章,还有一些我不理解的东西.
在文章这里
的客户表它说,它不是在2NF,因为there are several attributes which don’t completely rely on the entire Customer table primary key.这里的主键,我认为这意味着{客户ID,雇员}

如果我们选择{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个属性R(A1,A2,...,An)的关系模式R. R的最大可能超级密钥数是多少?请证明你的答案.
给定具有n个属性R(A1,A2,...,An)的关系模式R. R的可能候选键的最大数量是多少?请证明你的答案.
我仍然想知道如何回答这两个问题.我认为第一个问题的答案是(2 ^ n) - 1,因为不包括空集.
至于第二个问题.我的回答是n ariributes.
你们有什么感想?
请考虑以下表格定义...
表定义
CREATE TABLE [dbo].[Folders](
[Id] [int] IDENTITY(1,1) NOT NULL,
[UserId] [int] NOT NULL,
[ParentFolderId] [int] NULL
PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
Run Code Online (Sandbox Code Playgroud)
其他表与此表的主键列具有外键关系[id]。
我希望添加一个自引用外键约束,其中父文件夹ID引用同一Folders表中另一条记录的ID字段,但UserId也必须匹配...
自引用外键约束
ALTER TABLE [dbo].[Folders] WITH CHECK ADD CONSTRAINT [FK_Folders_ParentFolder] FOREIGN KEY([UserId], [ParentFolderId])
REFERENCES [dbo].[Folders] ([UserId], [Id])
GO
ALTER TABLE [dbo].[Folders] CHECK CONSTRAINT [FK_Folders_ParentFolder]
GO
Run Code Online (Sandbox Code Playgroud)
...但是我遇到了错误...
失误
Msg 1776, Level 16, State …Run Code Online (Sandbox Code Playgroud) 我无法理解如何识别函数依赖项中的键.我一直在看例子,例如:
给定ABCD关系,找到所有不包括超密钥的密钥
A -> BC, C -> D, CD -> AB.
Run Code Online (Sandbox Code Playgroud)
这给出了密钥C和A.我认为接近这个问题的方式是BC和D都依赖于A和C,AB依赖于CD,这意味着它们都是密钥,但是因为CD是一个超级密钥(C是一个也是一个密钥的子集),CD不被认为是一个最小的超级密钥.
但是,在另一个例子中,
ABCDE
AB ? CD
E ? A
D ? A
Run Code Online (Sandbox Code Playgroud)
这里唯一的关键显然是BE.为什么这是真的,任何人都可以澄清找到这些问题的关键步骤吗?
谢谢.
relational-database relation functional-dependencies candidate-key
假设关系 R(A,B,C,D) 存在且没有函数依赖。那么什么应该被视为它的候选键呢?显然,任何单个属性或所有属性的适当子集都不能成为候选键,因为它们绝不可以识别非主要属性。那么 ABCD 可以被认为是候选键吗?或者这个关系不会有任何候选键?
我在理解如何确定关系是否在 BCNF、3NF 中以及通常识别关系的候选键时遇到问题。
考虑R = (A, B, C, D)与函数依赖关系:
AB -> C
C -> D
D -> A
Run Code Online (Sandbox Code Playgroud)
问题包括:
一种。列出 R
b的候选键。确定 R 是否在 BCNF 或 3NF 中。
解决方案解决
一种。R 的 3 个候选键是 AB、BC 和 BD。
湾 R 属于 3NF,但不属于 BCNF。
我已经阅读了 3NF 和 BCNF 有什么区别?并且在引用数据库模式中的非任意词时可以理解 3NF 和 BCNF 之间的区别。正如问题中给出的那样,在尝试确定具有减少关系的关系时,我最终迷失了方向。
有人能解释一下上面的候选键是如何确定的,为什么 R 在 3NF 而不是 BCNF?
在一个关系中我们可以有多个候选键。但是我们可以在长度不同的关系中拥有两个候选键吗?
假设我有一个关系 R(A,B,C,D,E),并且我们只有两组唯一标识该关系中的元组的属性:{A,B,C} 和 {D,E}。
那么我们可以说 {A,B,C} 和 {D,E} 都是候选键吗?
candidate-key ×10
database ×6
sql ×2
3nf ×1
bcnf ×1
key ×1
rdbms ×1
relation ×1
relational ×1
sql-server ×1
unique-key ×1