Referential Integrity And Warehouse Performance

Before most relational database-supported referential integrity, it was the responsibility of the programmer to guarantee the maintenance of data relationships and business rules. While this was fine for the applications, the risk came into play when ad-hoc updated SQL commands were issued using Oracles SQL*Plus. With these ad-hoc update tools, the programmatic SQL could be easily bypassed, skipping the business rules and creating logical corruption.

Relational database system such as Oracle allow for the control of business rules with "constraints." These RI rules are used to enforce one-to-many and many-to-many relationships within the relational tables. For example, RI would ensure that a row in the CUSTOMER table could not be deleted if orders for that customer exist in the ORDER table. (See Figure 8.12)

Figure 8.12  An overview of referential integrity.

Referential integrity has earned a bad reputation in Oracle because of the overhead that is created when enforcing the business rules. In almost every case, it will be faster and more efficient to write your own rules to enforce RI instead of having Oracle do it for you. Provided that your application does not allow ad-hoc query, it is relatively easy to attach a trigger with a PL/SQL routine to enforce the RI on your behalf. In fact, this is one of the best uses of a trigger, since the DML DELETE event will not take place if the RI rules are invalid. For example, consider the foreign key constraint that protects a customer from being deleted if they have outstanding orders: