SQL数据库中的跨表依赖/约束

举个例子，我有一个名为

classes

的表格，其中包含大学课程，还有一个名为

students

的表格，其中包含学生。一个班级有很多学生，一个学生只能上一节课。（一对多关系）。如果我在

classes

中有一列存储了一个班级的学生总数，这感觉应该违反3NF。但是依赖关系在一个单独的表中。这种依赖关系叫什么？我们能说这违反了3NF吗？因为从某种意义上讲，它存在着违反3NF的所有问题。我想知道这是否是一个相关的案例。

这并不违反规范化，但在查询中维护而不是进行计数会很痛苦

注：连接表适用于多对多

TL；DR

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

你的意思是（在日常意义上）对另一个表有依赖性。我们说这两个表有一个约束。（它们相互依赖。）除了FK（外键）约束之外，每个

学生

类

值都是

类

类

值

这种依赖关系叫什么

我们可以合理地将约束归类为“表间约束”。就是说，

classes

equals

SELECT class，SUM（student）作为左班级的总数，使用（class）分组方式将学生加入到班级中

我们能说这违反了3NF吗

约束不涉及违反NF。此外，规范化仅适用于单个表及其FDs（函数依赖项）

（一个简单的设计是让基本
学生
，基本
类1
，即原始
类
，无
总计
，以及
将类视为选择类，将类1中的（学生）总和视为总计，使用（类）按类分组加入学生
）


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

表是否为给定的NF（标准形式）与任何其他表无关。（我们说一个数据库在一个给定的NF中，而它的所有表都在NF中。）不管您的设计是否糟糕都是错误的

由于一个班级只有一个学生总数，因此在
班级
中的
班级
上有一个FD（功能依赖性）
total
，即
班级
从功能上决定了
总数

对更高级别NFs的规范化通过表的投影来替换表，这些投影根据表中的FDs和JDs（连接依赖项）连接回表。学习正确的信息建模和数据库设计

在
classes
中将班级学生作为一列计算可能违反NF，也可能不违反NF。哪些FD违反NF取决于存在的所有FD和NF。（只有当您谈论的是NF的特定定义的特定部分时，在特定表中谈论违反特定NF的特定FD才有意义。）

（如果一个DBMS计算/计算/生成的列违反了一个NF，而该NF在没有它的情况下仍然有效，那么这不是问题，因为它是由DBMS控制的。您可以将该表视为没有该列的表的视图。）

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

当一系列数据库状态不能容纳表列中所有可能的值时，我们称之为约束保持或数据库被约束。FD（功能依赖项）、MVD（多值依赖项）、JD（连接依赖项）、IND（包含依赖项）、EQD（相等依赖项）和其他“依赖项”（技术上是给定上下文的表达式）都与某些约束相关。CKs（候选键）、PKs（主键）、超级键（SQL
PK
&
UNIQUE NOT NULL
）、FKs（外键）（技术上都是列集）和其他概念也都与某些约束相关。但是，任意条件都可以保留一系列数据库状态

SQL有一个独特但相关的
约束概念
，其特征是名称和表达式/条件（上述意义上的约束），由适当的语法声明。状态受列键入、
PK
、
UNIQUE
、
notnull
&
CHECK
约束的约束<代码>断言

给出了状态的任意条件，但大多数DBMS不支持该条件<代码>级联支持一些状态间表间约束。SQL

TRIGGER

s强制执行任意约束。索引还以特定于DBMS的方式强制执行约束

---

因为从某种意义上讲，它存在着违反3NF的所有问题

---

你的编辑改进了你的问题。使用错误的词语或以错误的方式使用词语充其量只能说明我们所说的不是我们的意思。但是当我们写的东西没有意义的时候，它表明我们的问题，不管它涉及到什么，包括不知道这些词的意思。强迫自己正确地使用词语可以让别人知道我们真正的意思。例如这里可能“…在表的连接中…会有一个3NF违反FD…”。即使明确地说我们不确定，我们也可以在不说我们不想说的话的情况下传达一些模糊的摸索。你的“这感觉像……”。但它也引导我们清楚地组织我们所面临的问题。这不仅有助于解决我们正在研究的问题，而且有助于提高我们解决问题的能力。

我假设一个学生只能上一节课。

学生总数

是一个计算字段。这违反了3NF。@Sephersobhani如果它违反了3NF，您能指出它违反了哪个1NF规则或部分或传递函数依赖关系吗？Hugo，在Chen的方法中，所有关系最初都由“连接表”表示。一对一和一对多bi