引用完整性约束是否有助于解决数据冗余问题？
最佳答案
引用完整性约束只是“一般数据库约束”的一个子集。
规范化和数据库约束是截然不同但又相互交织的概念。
假设您有一个表customerOrder（custID、custName、orderID），其中表示“由custID标识的客户和名为custName的客户已经下了由orderID标识的订单”。
这个表不太可能在3nf中，因为fd custid->custname可能适用。但是假设我们仍然保留这个单表设计。然后我们需要做什么来增强数据的一致性？我们必须执行上述FD。我们必须确保，如果同一个客户下了第二个订单，那么两行中的custname将是相同的。我们必须禁止（1，smith，2）和（1，jones，7）这样的行同时出现在表中。这是一种需要强制执行的数据库约束，以便使我们的设计与所有声明的业务规则匹配。
但请注意，这里没有任何“引用”约束。显然，因为没有第二个表可供参考。
还要注意的是，这个单表设计“自动”执行了一些其他的约束，这些约束可能不是很明显。例如，我们的一个表设计使得OrdID不可能存在，而不存在相应的CuthID和CuSTNEID。（如果你考虑的是空值，就不要这样做。在关系理论中，不存在“NULL”之类的东西。“规则”，如果一个OrrIdID被注册，那么也必须存在一个相应的CUCITD加CUSTNED，我们的设计是一个单表的“隐式”强制执行。
但现在我们将我们的设计分解为两个表一，正如传统的规范化理论所规定的那样：
客户（custid，custname）密钥custid；
订单（custid，orderid）键custid，orderid；
我们必须执行的业务规则仍然是相同的，即：（a）不能有两个客户具有相同的custid但具有不同的名称（这是我们的fd），并且（b）不能有任何订单没有相应的custid加上该订单的custname。
让我们看看我们的双表设计如何处理这些业务规则。（a）显然是通过将custid声明为客户的密钥来执行的。至于（b），很明显，不同时记录custid就不可能按顺序记录orderid。但这是否足以保证所有订单行也有相应的custname？显然不是。这就是为什么我们需要在订单和客户之间引入明显的引用完整性规则。
因此，ri约束确实“有助于解决数据冗余问题”，也就是说，通过分解一个表，并在总体设计中引入ri约束，它们可以消除某些类型的冗余，同时保持数据完整性的某些保证。如果不可能在设计中引入ri约束，我们只会以牺牲数据一致性为代价消除冗余。
关于database - 数据冗余，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/5647590/