在 SQL 数据库中交叉 Table Dependency/Constraint
Cross Table Dependency/Constraint in SQL Database
举个例子，我有一个名为 classes 的 table 容纳大学 class 和一个名为 students 的 table 容纳学生。一个class有很多学生，一个学生只能带一个class。 （一对多关系）。如果我在 classes 中有一列存储了 class 拥有的学生总数，这感觉应该违反 3NF。但是依赖在一个单独的 table 中。这种依赖叫什么？我们可以说这违反了 3NF 吗？因为在某种意义上它具有违反 3NF 的所有问题。我想知道这是否是相关案例。
它不违反规范化，但维护而不是在查询中进行计数会很痛苦。
注意：联结表适用于多对多。
TL;DR
But the dependency is in a separate table.
你的意思是存在依赖性（在日常意义上）对另一个table。我们说对 两个table 有一个约束。 （它们相互依赖。）除了 FK（外键）约束外，每个 students classes 值都是 classes class 值。
What is this dependency called?
我们可以合理地将约束归类为"inter-table"。就是classes等于SELECT class, SUM(student) AS total FROM classes LEFT JOIN students USING (class) GROUP BY class.
And can we say this is violating 3NF?
约束不涉及违反 NF。此外，规范化仅适用于单个 table 及其 FD（函数依赖项）。
（一个简单的设计是有基数 students，基数 classes1 即原来的 classes 没有 total，和 VIEW classes AS SELECT class, SUM(student) AS total FROM classes1 LEFT JOIN students USING (class) GROUP BY class。）
If I had a column in classes that stored the total number of students a class has, this feels like it should violate 3NF.
一个table是否在给定的NF（范式）中与任何其他table无关。 （我们说一个数据库在给定的 NF 中，而它的所有 table 都是。）你的设计是否仍然很糟糕是 another matter.
由于class只有一个学生总数，所以在classes中class有total的FD（函数依赖），即class 在功能上确定 total.
We say that a set of columns functionally determines another set in a table when each subrow for the first always appears with the same subrow for the second. Normalization to higher NFs replaces a table by projections of it that join back ot it, per the FDs & JDs (join dependencies) that hold in it. 学习正确的信息建模和数据库设计。
将您的 class 学生算作 classes 中的一列可能会也可能不会违反 NF。哪些 FD 违反 NF 取决于所有存在的 FD 和 NF。 （如果您谈论的是该 NF 的特定定义的特定部分，那么谈论特定 table 中违反特定 NF 的特定 FD 才有意义。）
（如果 DBMS-calculated/computed/generated 列违反了 NF，如果没有它，那这不是问题， 因为 它是由 DBMS 控制的。你可以认为table 作为不带列的 table 的视图。）
But the dependency is in a separate table.
当一系列数据库状态无法容纳每个 table 列的所有可能值时，我们说 constraints 保持或者数据库是 约束。 FD（函数依赖）、MVD（多值依赖）、JD（连接依赖）、IND（包含依赖）、EQD（相等依赖）和其他"dependencies"（技术上是表达式给定上下文）每个都与某些约束相关联。 CKs（候选键）、PKs（主键）、超级键（SQL PK & UNIQUE NOT NULL）、FKs（外键）（技术上都是列集) & 其他概念也各自与某些约束相关联。但是任意条件都可以保持一系列数据库状态。
SQL 有一个不同但相关的概念，即 constraint 以名称和 expression/condition（上述意义上的约束）为特征，通过适当的语法声明。状态受列类型、PK、UNIQUE、NOT NULL 和 CHECK 约束的约束。 ASSERTION 给出状态的任意条件，但大多数 DBMS 不支持它。 CASCADES 支持一些州际 table 约束。 SQL TRIGGERs 强制执行任意约束。索引还以特定于 DBMS 的方式实施约束。
Because in some sense it has all the problems of a 3NF violation.
您的修改改进了您的问题。使用错误的词语或以错误的方式使用词语充其量只是表达了一些不是我们想要表达的意思。但是，当我们写的东西没有意义时，它表明我们的问题，无论它涉及什么，都涉及不知道这些词的意思。强迫自己正确使用词语可以让别人知道我们真正的意思。例如，这里可能“...在 tables 的连接中...将有一个违反 3NF 的 FD...”。即使明确地说我们不确定，我们也可以传达一些模糊的摸索，而无需说出我们不是本意的话。例如你的"this feels like ..."。但它也让我们清楚地组织我们所面临的问题。这不仅有助于解决我们正在解决的问题，而且可以改善我们解决问题的能力。
举个例子，我有一个名为 classes 的 table 容纳大学 class 和一个名为 students 的 table 容纳学生。一个class有很多学生，一个学生只能带一个class。 （一对多关系）。如果我在 classes 中有一列存储了 class 拥有的学生总数，这感觉应该违反 3NF。但是依赖在一个单独的 table 中。这种依赖叫什么？我们可以说这违反了 3NF 吗？因为在某种意义上它具有违反 3NF 的所有问题。我想知道这是否是相关案例。
它不违反规范化，但维护而不是在查询中进行计数会很痛苦。
注意：联结表适用于多对多。
TL;DR
But the dependency is in a separate table.
你的意思是存在依赖性（在日常意义上）对另一个table。我们说对 两个table 有一个约束。 （它们相互依赖。）除了 FK（外键）约束外，每个 students classes 值都是 classes class 值。
What is this dependency called?
我们可以合理地将约束归类为"inter-table"。就是classes等于SELECT class, SUM(student) AS total FROM classes LEFT JOIN students USING (class) GROUP BY class.
And can we say this is violating 3NF?
约束不涉及违反 NF。此外，规范化仅适用于单个 table 及其 FD（函数依赖项）。
（一个简单的设计是有基数 students，基数 classes1 即原来的 classes 没有 total，和 VIEW classes AS SELECT class, SUM(student) AS total FROM classes1 LEFT JOIN students USING (class) GROUP BY class。）
If I had a column in
classesthat stored the total number of students a class has, this feels like it should violate 3NF.
一个table是否在给定的NF（范式）中与任何其他table无关。 （我们说一个数据库在给定的 NF 中，而它的所有 table 都是。）你的设计是否仍然很糟糕是 another matter.
由于class只有一个学生总数，所以在classes中class有total的FD（函数依赖），即class 在功能上确定 total.
We say that a set of columns functionally determines another set in a table when each subrow for the first always appears with the same subrow for the second. Normalization to higher NFs replaces a table by projections of it that join back ot it, per the FDs & JDs (join dependencies) that hold in it.
将您的 class 学生算作 classes 中的一列可能会也可能不会违反 NF。哪些 FD 违反 NF 取决于所有存在的 FD 和 NF。 （如果您谈论的是该 NF 的特定定义的特定部分，那么谈论特定 table 中违反特定 NF 的特定 FD 才有意义。）
（如果 DBMS-calculated/computed/generated 列违反了 NF，如果没有它，那这不是问题， 因为 它是由 DBMS 控制的。你可以认为table 作为不带列的 table 的视图。）
But the dependency is in a separate table.
当一系列数据库状态无法容纳每个 table 列的所有可能值时，我们说 constraints 保持或者数据库是 约束。 FD（函数依赖）、MVD（多值依赖）、JD（连接依赖）、IND（包含依赖）、EQD（相等依赖）和其他"dependencies"（技术上是表达式给定上下文）每个都与某些约束相关联。 CKs（候选键）、PKs（主键）、超级键（SQL PK & UNIQUE NOT NULL）、FKs（外键）（技术上都是列集) & 其他概念也各自与某些约束相关联。但是任意条件都可以保持一系列数据库状态。
SQL 有一个不同但相关的概念，即 constraint 以名称和 expression/condition（上述意义上的约束）为特征，通过适当的语法声明。状态受列类型、PK、UNIQUE、NOT NULL 和 CHECK 约束的约束。 ASSERTION 给出状态的任意条件，但大多数 DBMS 不支持它。 CASCADES 支持一些州际 table 约束。 SQL TRIGGERs 强制执行任意约束。索引还以特定于 DBMS 的方式实施约束。
Because in some sense it has all the problems of a 3NF violation.
您的修改改进了您的问题。使用错误的词语或以错误的方式使用词语充其量只是表达了一些不是我们想要表达的意思。但是，当我们写的东西没有意义时，它表明我们的问题，无论它涉及什么，都涉及不知道这些词的意思。强迫自己正确使用词语可以让别人知道我们真正的意思。例如，这里可能“...在 tables 的连接中...将有一个违反 3NF 的 FD...”。即使明确地说我们不确定，我们也可以传达一些模糊的摸索，而无需说出我们不是本意的话。例如你的"this feels like ..."。但它也让我们清楚地组织我们所面临的问题。这不仅有助于解决我们正在解决的问题，而且可以改善我们解决问题的能力。