bcnf

0热度

1回答

主属性和键

是一个主要的属性只候选键的成员，或者它也可以superkeys？我有点困惑，因为我正在阅读某个主要属性可能是任何键的成员的地方，而其他人则说它需要成为候选键的成员。

-1热度

1回答

将以下关系分解为BCNF

给定与属性A，B，C，D，E的关系R以及功能依赖关系A-> B，BC-> E，ED-> A的集合。将其分解为高正常形式。

0热度

1回答

BCNF - 正常形式

想知道如果您认为下面的表格将数据库中的员工存储在BCNF中会考虑数据库吗？ - Employee Table Employee_ID (Primary Key, unique) First_Name Surname Religion Sex Job Title Nationality - Employee_Address Table Employee_ID (Foreign

0热度

1回答

确定BCNF侵犯

所以我有FD的关系模式，它看起来像这样： R(A,B,C,D): AB -> C, B -> D, CD -> A, AD -> B 现在我试图找到所有的BCNF侵犯，然后分解表。我计算的所有FD的左侧，发现这个： AB+ = {A, B, C, D} B+ = {B, D} <- violation CD+ = {C, D, A, B} AD+ = {A, D, B, C} 所以我

0热度

1回答

如何BCNF分解时的属性与任何其他人没有关系

分配：考虑的关系（,,,,,,）和FD组= {→，→，→，→ ，→，→}。如果它不在BCNF中，则将它分解成一组BCNF关系。确保你的分解是无损的 - 加入。说明嗨，我的工作我的数据库作业（设计相关章节）。我想我已经根据课堂上的例子命令了基本过程。然而，这里棘手的部分是我们有一个属性'H'，与其他人没有任何关系，这使我深深地困惑。我应该如何处理它？试图回答 • We start fr

2热度

1回答

BCNF分解后获得相同的FD？

我对一个有5个函数依赖关系的关系进行BCNF分解，最后得到5个关系。但是，每个新的关系都具有与原始功能依赖关系相同的属性和FD。例如一个函数依赖是AB - > C，并且我最终得到的5个关系之一具有ABC与AB - > C函数依赖关系的属性。对于其他四种关系（与原始FD中的一个相同的属性和FD）也是如此。这是否意味着我错误地进行了BCNF分解？我发现这个问题Specific BCNF deco

0热度

2回答

sql数据库：带有2列（id名称）和2个主键的表第三范式Boyce-Codd范式

想象一下下表。在我的情况下，我完全确定name需要为unique和not null [unique + not null = primary key]。因此name是主键。由于某些原因（可能是习惯），我自然创建了一个int类型的主键id。其他假设：我绝对需要在我的表中保留name，并且我绝对确定name（类型varchar）永远不会超过20个字符。现在我的第一个问题是[可能是否有预期的接近问题

1热度

1回答

是否需要分解关系后保留所有函数依赖关系？

在将关系转换为BCNF之后，如果可用于原始模式的函数依赖关系（FD）丢失，则创建新的“冗余”表以便保留所有原始FD。如果可能的话，创建新的“冗余”表。我了解FD对于分解，但分解后它们的用途是什么？为什么我们必须尝试保留所有的FD？将关系转换为BCNF后，一个或两个FD是否丢失是否真的很重要？

0热度

1回答

如何指出违规BCNF？

本周我有一个数据库期中，我在识别BCNF违规时遇到了问题。我知道如何分解关系，并找出哪些是关键，哪些是超级关键。我也可以写出隐含的FD。我正在看以下视频：https://www.youtube.com/watch?v=hTFyG5o8-EA。概括起来，这位女士解释应用BCNF算法如下关系开始（她用学生的例子，但我已经转换成字母简化它）： R（A，B ，C，D，E，F，G，H）与FD：A→BCG，

0热度

1回答

减少到BCNF

我如何减少到BCNF对于这个问题，你能帮我查一下， R（A，B，C，d，E）文件描述符：A - > B，d - > E，C - > d 减少到BCNF： R1（A，B），R2（d，E）中，R 3（C，d）我我不确定我的工作。谢谢