数据冗余

参照完整性约束只是“数据库约束一般”的子集。 规范化和数据库约束是截然不同但相互交织的概念。 假设您有一个表CUSTOMERORDER（custID，custName，orderID），该表表示\“由＃custID＃标识并且名为＃custName＃的客户已下达＃orderID＃\的订单”。 由于可能适用的FD custID-> custName，此表不太可能位于3NF中。但是请说我们仍然保留此一表设计。然后，我们必须做什么来确保数据的一致性？我们必须执行上述FD。我们必须确保，如果同一位客户下第二笔订单，那么两行中的custName将相同。我们必须禁止在表格中同时出现（1，Smith，2）和（1，Jones，7）之类的行。这是一种要强制执行的数据库约束，以使我们的设计与所有规定的业务规则匹配。 但是请注意，我们在这里没有任何“参照”约束。显然，因为没有第二张表可供参考。 还要顺便指出，这种“自动”单表设计会强制实施某些其他约束，这些约束可能不会立即显现出来。例如，我们的单表设计使得在没有对应的custID和custName也存在的情况下，orderID不可能存在。 （如果您正在考虑空值，请停止这样做。在关系理论中，不存在诸如\'null \“之类的东西。）\” rule \“，即如果注册了orderID，则还必须存在一个对应的custID加上custName，由我们的设计（一个表一）强制“隐式”执行。 但是现在，按照传统的规范化理论的规定，我们将设计分解为两张表格： CUSTOMER（custID，custName）密钥custID; ORDER（custID，orderID）密钥custID，orderID; 我们必须执行的业务规则仍然相同，即：（a）不能有两个客户具有相同的custID但名称不同（即我们的FD），并且（b）不能有任何订单而没有该订单对应的custID加上custName。 让我们看看我们的两表设计如何处理这些业务规则。 （a）显然是通过将custID声明为CUSTOMER的键来强制执行的。至于（b），很明显，如果不同时记录custID，就不可能在ORDER中记录orderID。但这是否足以保证所有ORDER行也有相应的custName？显然没有。这就是为什么我们需要在ORDER和CUSTOMER之间引入明显的参照完整性规则。 因此，从某种意义上来说，RI约束确实“有助于解决数据冗余问题”，即通过分解表并将RI约束引入总体设计，它们可以消除某种冗余，同时保留某些数据保证。诚信。没有可能在设计中引入RI约束，我们只会以数据一致性为代价来消除冗余。     

它可以提供帮助，但如果数据库设计未规范化则无济于事。参照完整性约束可用于您的设计中，以减少/删除数据冗余。 为了获得最佳效果，请确保您将BCNF标准化为3NF以上。这可能仍然有一些冗余，但是对于大多数用途来说都可以。     

参照完整性只能保证参照完整性。 这是布置数据库以防止冗余的方式（请参阅Oded指出的规范化）。