SQL数据库中的交叉表依赖性/约束

Question

以我有一个表的示例为例，该表classes包含大学课程，一个表students包含学生。一堂课有很多学生，一个学生只能上一堂课。（一对多关系）。如果我在其中有一列classes存储了一个班级的学生总数，那感觉它应该违反了3NF。但是依赖关系在单独的表中。这种依赖关系叫做什么？我们可以说这违反了3NF吗？因为从某种意义上说，它具有违反3NF的所有问题。我想知道这是否是一个相关案例。

Answer 1

TL; DR

但是依赖关系在单独的表中。

您的意思是（在日常意义上） 对 另一个表有依赖性。我们说这两个表有一个 约束 。（它们彼此依赖。）除了FK（外键）约束之外，每个students
classes值都是一个classes class值。

这种依赖关系叫做什么？

我们可以将约束合理地分类为“表间”。这是classes平等的SELECT class, SUM(student) AS total FROM classes LEFT JOIN students USING (class) GROUP BY class。

我们可以说这违反了3NF吗？

约束不涉及违反NF。此外，规范化仅适用于单个表及其FD（功能依赖性）。

（一个简单的设计是具有base students，而baseclasses1是原始的，classes不带total和VIEW classes AS SELECT class, SUM(student) AS total FROM classes1 LEFT JOIN students USING (class) GROUP BY class。

如果我在其中有一列classes存储了一个班级的学生总数，那感觉它应该违反了3NF。

一个表是否为给定的NF（标准格式）与任何其他表无关。（我们说一个数据库的所有表都在一个给定的NF中。）您的设计是否仍然很糟糕是另一回事。

由于一个类只有一个学生的总数，有一个FD（功能依赖性）total上class在classes，即，class在功能上确定total。

我们说，当第一个子行的每个子行始终与第二个子行的相同子行出现时，一组列在功能上决定了表中的另一组。根据保留在其中的FD和JD（联接依赖项），对较高NF的规范化将通过将表重新连接到该表的投影来替换该表。当两个表对业务/应用程序情况说的相同时，数据库中就有冗余。但并非所有冗余都是不好的。了解适当的信息建模和数据库设计。

让您的班级学生计入的列可能会违反NF，也可能不会违反classes。哪些FD违反NF取决于存在的所有FD和NF。（并且，如果您正在谈论该NF特定定义的特定部分，那么在特定表中谈论特定FD违反特定NF才有意义。）

（如果DBMS计算/计算/生成的列违反了没有它就可以容纳的NF，那不是问题， 因为 它是由DBMS控制的。您可以将表视为没有该列的表的视图。）

但是依赖关系在单独的表中。

当数据库状态序列无法容纳表的每列的所有可能值时，我们称 约束 成立或数据库被 约束
。FD（功能依赖项），MVD（多值依赖项），JD（联接依赖项），IND（包含依赖项），EQD（相等依赖项）和其他“依赖项”（从技术上讲是给定上下文的
表达式 ）均与某些特定项相关联约束。CK（候选键），PK（主键），超键（SQL PK＆UNIQUE NOT NULL），FK（外键）（技术上都是
列集 ）和其他概念也都与某些约束相关联。但是，任意条件都可以保留一系列数据库状态。

SQL具有一个独特但相关的概念，即constraint以适当的语法声明的名称和表达式/条件（具有上述意义的约束）为特征。的状态被通过柱打字，约束PK，UNIQUE，NOT NULL＆CHECK约束。ASSERTION在状态上给出任意条件，但是大多数DBMS不支持该条件。CASCADES支持一些州际表间约束。SQLTRIGGER强制执行任意约束。索引还以特定于DBMS的方式强制执行约束。

因为从某种意义上说，它具有违反3NF的所有问题。

您的修改改善了您的问题。使用错误的单词或以错误的方式使用单词充其量只能说出不是我们的意思。但是，当我们写的东西没有任何意义时，则表明我们的问题，无论涉及什么其他问题，都涉及到不知道单词的含义。强迫自己正确使用单词可以使其他人知道我们的真正意思。例如，这里可能是“
…在表的连接中……会有违反3NF的FD
…”。即使明确表示我们不确定，我们也可以传达一些含糊其词的摸索，而不必说些我们不是要说的话。例如，您的“感觉就像……”。但这也使我们清楚地组织了所面临的问题。这不仅有助于解决我们正在解决的问题，而且可以改善解决问题的能力。