参照完整性约束是否有助于解决数据冗余问题？
答案 0 :(得分：3)
参照完整性约束只是“一般数据库约束”的一个子集。
规范化和数据库约束是截然不同但交织在一起的概念。
假设你有一个表CUSTOMERORDER（custID，custName，orderID），它表示“由＃custID＃标识的客户和名为＃custName＃的客户已经放置了由#orderID＃标识的订单。”
由于可能适用的FD custID-＆gt; custName，此表不太可能在3NF中。但是说我们保持这种单桌设计。那么我们必须做些什么来强制数据的一致性？我们必须强制执行上述FD。我们必须确保如果同一个客户下了第二个订单，那么两行中的custName将是相同的。我们必须禁止诸如（1，Smith，2）和（1，Jones，7）之类的行出现在表中。这是一种要强制执行的数据库约束，以使我们的设计符合所有规定的业务规则。
但请注意，我们这里没有任何“参考”约束。显然，因为没有第二个表可供参考。
另外请注意，这个单表设计“自动”强制执行一些可能不会立即明显的其他约束。例如，我们的单表设计使得orderID不可能在没有相应的custID AND custName的情况下存在。 （如果你正在考虑空值，请停止这样做。在关系理论中，不存在诸如'null'之类的东西。）“规则”如果注册了orderID，那么还必须存在相应的custID PLUS custName ，我们的设计是一个一个表格，“隐含地”强制执行。
但现在我们将设计分解为两个表格，正如传统的规范化理论所规定的那样：
CUSTOMER（custID，custName）KEY custID; ORDER（custID，orderID）KEY custID，orderID;
我们必须执行的业务规则仍然相同，即：（a）不能有两个客户具有相同的custID但具有不同的名称（即我们的FD），以及（b）没有任何订单没有该订单的相应custID PLUS custName 。
让我们看看我们的双表设计如何处理这些业务规则。 （a）显然是通过将custID声明为CUSTOMER的关键来强制执行的。至于（b），很明显，如果不记录custID，也不可能在ORDER中记录orderID。但这足以保证所有ORDER行都有相应的 custName 吗？显然没有。这就是为什么我们需要在ORDER和CUSTOMER之间引入明显的引用完整性规则。
因此，RI约束确实“有助于解决数据冗余问题”，在某种意义上，通过分解表，并将RI约束引入整体设计，它们可以消除某种类型冗余，同时保留数据完整性的某些保证。如果没有在设计中引入RI约束的可能性，我们只会以数据一致性为代价来消除冗余。
答案 1 :(得分：1)
它可以提供帮助，但如果数据库设计没有规范化则不行。可以在设计中使用参照完整性约束来减少/消除数据冗余。
答案 2 :(得分：0)
参照完整性仅保证参照完整性。
这就是你布置数据库以防止冗余的方式（参见Oded指出的normalization）。