Deferred referential integrity checking based on determining whether row at-a-time referential integrity checking would yield the same results as deferred integrity checking6098075Abstract A method, apparatus, and article of manufacture for a computer implemented data manager. A statement is executed in a computer. The statement being performed by the computer to access data from a database stored on a data storage device connected to the computer. A determination is made as to whether to defer referential integrity checking when executing the statement. When it is determined that referential integrity checking is to be deferred, each record is processed that is specified in the statement. Keys for select records are stored as each record is processed. Then, after executing the statement, referential integrity checking is performed on the stored keys. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
TABLE 1
______________________________________
COL1 COL3
(Parent key)
COL2 (Foreign key references COL1)
______________________________________
A 1 A
B 2 A
C 3 B
D 4 B
E 5 A
F 5 E
G 5 F
H 8 A
I 9 H
J 3 H
K 1 H
______________________________________
FIG. 2 illustrates a graphical representation of the data of TABLE 1, using a tree structure 200, in which each node represents a row (COL1, COL2, COL3), such as (A,1,A). Dependent rows (i.e., rows that reference a parent key of another row) are placed under the parent rows (i.e., the row whose parent key is referenced), except for row (A,1,A), which is a dependent of itself. Consider the following SQL statement in reference to the above TABLE 1 and tree structure: DELETE FROM T WHERE COL2=5; When referential integrity checking is deferred on the above DELETE statement, the success of the delete does not depend on the order of execution. In fact, the Data Manager 118 will delete all the specified (i.e., selected) rows and then check for referential integrity. In the following example, TABLE 2 duplicates TABLE 1, except that row (B,2,A) has been changed to (B,5,A).
TABLE 2
______________________________________
COL1 COL3
(Parent key)
COL2 (Foreign key references COL1)
______________________________________
A 1 A
B 5 A
C 3 B
D 4 B
E 5 A
F 5 E
G 5 F
H 8 A
I 9 H
J 3 H
K 1 H
______________________________________
Then, the following statement is executed: DELETE FROM T WHERE COL2=5; The above statement would be unsuccessful with a DELETE rule on the self-referencing table. In this case, the Data Manager 118 first deletes all four qualifying rows, (B,5,A), (E,5,A), (F,5,E), (G,5,F), and then performs referential integrity checking. The referential integrity checking will be unsuccessful because rows (C,3,B) and (D,4,B) would be orphans (i.e., if row (B,5,A) were deleted, then foreign keys that reference the parent key "B" would exist). When the referential integrity checking is unsuccessful, the Data Manager 118 will back out all the deletes and return an error (e.g., "THE RELATIONSHIP constraint-name RESTRICTS THE DELETION OF THE ROW WITH RID X rid-number"). High Level Design In one embodiment, the DELETE rule on a self-referencing table leads to deferred referential integrity checking for what is termed a "DELETE rule of NO ACTION". The DELETE rule of NO ACTION has the same effect as a DELETE rule of RESTRICT, except when the deleted rows belong to a self-referencing table. A DELETE rule of RESTRICT will not allow a row in a parent table to be deleted when there are still rows in the dependent table whose foreign key corresponds to the parent key of the parent table. The DELETE rule of RESTRICT causes referential integrity checking to be performed as the rows are deleted. Therefore, in the case of self-referencing tables, where the order in which the rows are processed affects the success of referential integrity checking, the DELETE rule of RESTRICT is not allowed. With the DELETE rule of NO ACTION for self-referencing tables, the referential integrity checking is performed after all the qualifying rows have been deleted, so that the order in which the rows are deleted will not matter. One or more rows of a self-referencing table can be deleted with a DELETE rule of NO ACTION. One or more rows of a non self-referencing table can also be deleted with a DELETE rule of NO ACTION, however, in these cases, the delete will have the same effect as a DELETE rule of RESTRICT. The Data Manager 118 enforces the NO ACTION rule in delete processing. When the Data Manager 118 checks for and finds a (RESTRICT or (NO ACTION and--self-referencing)), the Data Manager 118 processes the delete as a DELETE rule of RESTRICT. The Data Manager 118 also checks for (NO ACTION and self-referencing) tables, in which case a delete is processed as a DELETE rule of NO ACTION, with deferred referential integrity checking. Each data row specified in the DELETE and that row's index will be deleted and processing will continue, even if the row contains a parent key, until all the rows in that table and its dependent tables are processed. The deleted rows that contain parent keys are tracked in an array referenced by a pointer. The array will describe work files in which the actual parent keys are saved. At the end, the Data Manager 118 will use this array and the work files to determine whether there are still some orphans left in the table. However, when referential integrity checking is deferred until all of the rows to be deleted are processed, there is a good chance that all the potential orphans have also been deleted. If there are no orphans, the delete is successful. If there are any orphans left at the end, all the deletes are backed out in a typical manner and an error message is returned. The following pseudocode represents the technique used to defer referential integrity checking for a DELETE rule on a self-referencing table: 1. For each row of the table T to be deleted: a. If the row is not a parent row, delete the row. (i.e., the parent key of the row is not referenced by another row) b. If the row is a parent row, (i.e., the parent key of the row is referenced by another row) 1) Delete the row's entry from the index and delete the row, 2) Put the Parent Key in the work file. 2. For each Key in the work file: a. Identify the Parent Key of each dependent row for the Parent Key (if any), and b. If any identified Parent Key is in the index, back out and return error. This technique is built around already existing DELETE logic. The highlights of the changes and some deviations from the original technique include the following: The creation of a referential integrity work file control block when a problem row is first encountered while executing a DELETE rule for a self-referencing table. The processing of a referential integrity work file control block and related work files. While processing the table, deleting the index and the data of a row containing a parent key and adding the row and work file information to the referential integrity work file. At the end of processing the table, deletion of the referential integrity work file control block and related work files. FIG. 3 is a flow diagram illustrating the steps performed by the Data Manager 118 to process a DELETE rule on a self-referencing table. In Block 300, the Data Manager 118 selects the next row of the table, starting with the first row. In Block 302, the Data Manager 118 deletes the row and its index entry. In Block 304, the Data Manager 118 determines whether the row is a parent row. When the row is not a parent row, the Data Manager 118 continues at Block 308, otherwise, the Data Manager 118 continues at Block 306. In Block 306, the Data Manager 118 adds the parent key of the selected row to a work file. In Block 308, the Data Manager 118 determines whether all rows have been selected. When all rows have been selected, the Data Manager 118 continues to Block 310, otherwise, the Data Manager 118 loops back to Block 300 to select the next row. In Block 310, the Data Manager 118 processes the work file. FIG. 4 is a flow diagram illustrating the steps performed by the Data Manager 118 to process a work file for a DELETE rule on a self-referencing table. In Block 400, the Data Manager 118 selects the next key in the work file, starting with the first key. In Block 402, the Data Manager 118 identifies the parent key of each row that is being deleted. In Block 404, the Data Manager 118 determines whether there are any identified parent keys in the index. In particular, the Data Manager 118 scans the foreign key index of dependent tables to locate keys that match the identified parent keys. When one or more of these parent keys are found in the index, the Data Manager 118 continues at Block 406, otherwise, the Data Manager 118 continues at Block 410. In Block 406, the Data Manager 118 aborts the delete operation and backs out any changes. In Block 408, the Data Manager 118 backs out the delete and returns an error message indicating that the delete was unsuccessful. In Block 410, the Data Manager 118 determines whether all keys have been selected. When all keys have been selected, the Data Manager 118 continues to Block 412, otherwise, the Data Manager 118 loops back to Block 400 to select the next key for processing. In Block 412, the Data Manager 118 is done processing the work file, and the delete operation is successful. The following are examples provided to aid understanding of the present invention. In the following examples, the column values for COL2 in TABLE 1 will be modified to create different scenarios. EXAMPLE 1 Delete is Successful The following TABLE 3 and its Index contains data used for Example 1, including a row identifier (RID), a parent key (COL1), column data (COL2), and a foreign key reference (COL3). Additionally, the Index contains a key (KEY) and a row identifier (RID).
TABLE 3
______________________________________
INDEX
COL3
(Foreign
COL1 key
(Parent references
RID key) COL2 COL1) KEY RID
______________________________________
00000201
A 1 A A 00000201
00000202
B 2 A B 00000202
00000203
C 3 B C 00000203
00000204
D 4 B D 00000204
00000205
E 5 A E 00000205
00000206
F 5 E F 00000206
00000207
G 5 F G 00000207
00000208
H 5 A H 00000208
00000209
I 5 H I 00000209
0000020A
J 5 H J 0000020A
0000020B
K 5 H K 0000020B
______________________________________
For Example 1, the following statement is executed in which the delete is on a self-referencing table: DELETE FROM T WHERE COL2=5; For each row of table T to be deleted, suppose that the delete occurs in the Parent Key (COL1) order. The first row selected for delete would be (E,5,A). Since "E" is a key of the row which is the parent of the row containing the foreign key "F", the data (i.e., row data) and entry for (E,5,A) are deleted and the key "E" is stored in the work file. For the next row (F,5,E), "F" is a key of the row which is the parent of the row containing the foreign key "G", therefore, the row data and index entry are deleted, and the key is stored in the work file. For row (G,5,F), "G" is a key of a row that is not the parent for any other row, so the row data and index entry are deleted. For row (H,5,A), since "H" is a key of a row that is a parent of several rows, the row data and index entry are deleted, and the parent key is stored in the work file. For row (J,5,H), since "J" is a key of a row that is not the parent for any other row, the row data and index entry are deleted. For row (K,5,H), since "K" is a key of a row that is not the parent for any other row, the row data and index entry are deleted. After processing the DELETE for the rows of the table, the updated data of TABLE 3 would be as shown in TABLE 4:
TABLE 4
______________________________________
INDEX
COL3
(Foreign
COL1 key
(Parent references
RID key) COL2 COL1) KEY RID
______________________________________
00000201
A 1 A A 00000201
00000202
B 2 A B 00000202
00000203
C 3 B C 00000203
00000204
D 4 B D 00000204
______________________________________
After processing the DELETE for the rows of the table, the work file would contain the following keys: "E", "F", and "H". For each of these keys, their associated index entries are deleted from the Index and their row data is deleted in TABLE 4. Next, for each key in the work file, the Data Manager 118 performs referential integrity checking. Key "E" has only one dependent key, "F", which is not on the Index (which means that "F" is a possible delete or was already deleted), so Key "E" is deleted from the work file and processing continues to the next key. Key "F" has no dependents, because "G", which was a dependent key, was already deleted earlier, so Key "F" is deleted from the work file and processing continues to the next key. Key "H" has no dependents, because "I", "J" and "K" were already deleted earlier, so Key "H" is deleted from the work file and processing continues to the next key. After processing all of the keys in the work file, if all of them are deleted from the work file, the delete is successful and the work file is deleted. EXAMPLE 2 Delete is Unsuccessful The following TABLE 5 and its Index contain data used for Example 2:
TABLE 5
______________________________________
INDEX
COL3
(Foreign
COL1 key
(Parent references
RID key) COL2 COL1) KEY RID
______________________________________
00000201
A 1 A A 000201
00000202
B 2 A B 000202
00000203
C 3 B C 000203
00000204
D 4 B D 000204
00000205
E 5 A E 000205
00000206
F 5 E F 000206
00000207
G 5 F G 000207
00000208
H 5 A H 000208
00000209
I 5 H I 000209
0000020A
J 6 H J 00020A
0000020B
K 5 H K 00020B
______________________________________
For Example 2, the following statement is executed: DELETE FROM T WHERE COL2=5 For each row of T to be deleted, suppose that the delete occurs in the Parent Key (COL1) order. The first row selected for delete is (E,5,A). Since "E" is a key of a row that is a parent of the row containing key "F", the row data and index entry for row (E,5,A) are deleted and its parent key is stored in the work file. The next row selected for delete is (F,5,E). Since "F" is a key that is a parent of a row containing key "G", the row data and index entry for row (F,5,E) are deleted and its parent key is stored in the work file. Next, for row (G,5,F), since "G" is a key of a row that is not a parent to another row, the row data and its index entry are deleted. For row (H,5,A), since "H" is a key of a parent row that is referenced in other rows, the row data and index entry for this row are deleted, and the parent key is stored in the work file. For row (I,5,H), since "I" is not referenced in other rows, the row data and index entry for this row are deleted. For row (K,5,H), since "K" is not referenced in other rows, the row data and index entry for this row are deleted. After processing the DELETE for the rows of the table, the updated data of TABLE 5 would be as shown in TABLE 6:
TABLE 6
______________________________________
INDEX
COL3
(Foreign
COL1 key
(Parent references
RID key) COL2 COL1) KEY RID
______________________________________
00000201
A 1 A A 00000201
00000202
B 2 A B 00000202
00000203
C 3 B C 00000203
00000204
D 4 B D 00000204
0000020A
J 6 H J 0000020A
______________________________________
After processing the DELETE for the rows of the table, the work file contains the following keys: "E", "F", and "H". For each of these keys, their associated index entries are deleted in the Index and their row data is deleted in TABLE 6. For each key in the work file, referential integrity checking is performed. Key "E" has only one dependent, "F", which is not on the Index, so Key "E" is deleted from the work file and processing continues to the next key. Key "F" has no dependents, because key "G" was already deleted earlier, so Key "F" is deleted and processing continues to the next key. Key "H" has a dependent "J" remaining in TABLE 6, and keys "I" and "K" were deleted earlier. Referential integrity checking ensures that a parent key is not deleted from a table when foreign keys referencing the parent key remain in the table. The parent key of row (J,6,H) is "J", which exists in the Index. This indicates that key "J" was neither deleted earlier nor is a target for delete, therefore, row (H,5,A) cannot be deleted. Therefore, the deletes are backed out using data logged in a log file in a typical manner. Then, an error message is returned. When the delete is unsuccessful, the work file is deleted and control is returned to the caller. EXAMPLE 3 Cycle Relationship in which Delete is Unsuccessful In Example 3, there is a cycle in the data. In this case, the row (A,1,D) references parent key "D" in row (D,1,B), which references parent key "B" in row (B,1,A), which references parent key "A" in row (A,1,D), making a cycle (i.e., "A" is a child of "D", "D" is a child of "B", and "B" is a child of "A"). The following TABLE 7 and its Index contain data used for Example 3:
TABLE 7
______________________________________
INDEX
COL3
(Foreign
COL1 key
(Parent references
RID key) COL2 COL1) KEY RID
______________________________________
00000201
A 1 D A 000201
00000202
B 1 A B 000202
00000203
C 1 B C 000203
00000204
D 1 B D 000204
00000205
E 5 A E 000205
00000206
F 5 E F 000206
00000207
G 5 F G 000207
00000208
H 5 A H 000208
00000209
I 5 H I 000209
0000020A
J 6 H J 00020A
0000020B
K 5 H K 00020B
______________________________________
For Example 3, the following statement is executed: DELETE FROM T WHERE COL2=1 Initially, the row data and index entries for rows (A,1,D), (B,1,A), (C,1,B), and (D,1,B) are deleted, along with the row data and index entry for (C,1,B). After processing the DELETE for the rows of the table, the work file contains the following keys: "A", "B", and "D". When referential integrity checking is performed on key "A", its child "E" is still present in the index, so the delete cannot be processed. Therefore, the deletes are backed out, and an error message is returned. EXAMPLE 4 Cycle relationship, delete is Successful In Example 4, there is a cycle in the data. In this case, the row (H,6,K) references parent key "K" in row (K,6,H), which, in turn, references parent key "H" in row (H,6,K), making a cycle (i.e., "H" is a child of "K" and "K" is a child of "H"). The following TABLE 8 and its Index contain data used for Example 4:
TABLE 8
______________________________________
INDEX
COL3
(Foreign
COL1 key
(Parent references
RID key) COL2 COL1) KEY RID
______________________________________
00000201
A 1 A A 000201
00000202
B 1 A B 000202
00000203
C 1 B C 000203
00000204
D 1 B D 000204
00000205
E 5 A E 000205
00000206
F 5 E F 000206
00000207
G 5 F G 000207
00000208
H 6 K H 000208
00000209
I 6 H I 000209
0000020A
J 6 H J 00020A
0000020B
K 6 H K 00020B
______________________________________
For Example 4, the following statement is executed: DELETE FROM T WHERE COL2=6 Initially, the row data and index entries for rows (H,6,K), (I,6,H), (J,6,H) and (K,6,H) are deleted and the row data and index entries for rows (I,6,H) and (J,6,H) are also deleted. After processing the DELETE for the rows of the table, the work file contains the following keys: "H" and "K". When referential integrity checking is performed on the first key, "H", its child, "K", is not present in the index, so Key "H" is deleted from the work file and processing continues to the next key. When referential integrity checking is performed on the next key, "K", its child, "H", is not present in the index, so Key "K" is deleted from the work file. Since all keys have been deleted from the work file, the entire delete is successful. Multiple-row UPDATE of Parent Keys and Modifications of Foreign Keys that Reference UNIQUE Keys In the present invention, multiple-row updates of parent keys are allowed. The Data Manager 118 of the present invention also enables updating multiple parent keys within one table with one searched update. The Data Manager 118 defers referential integrity checking until all of the updates have been performed. This type of multiple-row update of parent keys statement is rare. The technique for deferring referential integrity checking is built on the multiple-row update of unique keys. The technique is optimized by keeping track of parent keys that are being updated, and then performing referential integrity checking after all of the updates are completed. The Data Manager 118 of the present invention allows the update of multiple rows because of a parent key change. The following are examples of this type of SQL statement, in which the column names that start with "PK" are parent keys and those that start with "FK" are foreign keys: UPDATE T SET PK=PK+1, FK=FK+1; (i.e., the value of a parent key, PK, is increased by one; the value of a foreign key, FK, is increased by one) In the present invention, a foreign key can reference a non-parent, unique key. On the other hand, in some systems, a foreign key could only reference a pre-designated parent key. Additionally, in some systems, both the CREATE and ALTER TABLE statements have the FOREIGN KEY clause, but this clause implicitly refers to the parent key of the parent table. In the present invention, the FOREIGN KEY clause is enhanced to refer to a parent key which can be either a unique key or parent key of the parent table. If the foreign key refers to a non-primary unique key, then the columns of the key are explicitly specified in the REFERENCES sub-clause in the FOREIGN KEY clause. Otherwise, the default is to refer to the columns of the parent key of the parent table. The foreign key defined with the CREATE and ALTER TABLE statements must have the following attributes as the parent key: The same number of columns. The same description column by column, except for their names, default values, null attributes and check constraints. The same field procedure and identical field description, when the field procedure is specified. The following pseudocode represents the technique of the preferred embodiment of the present invention used to defer referential integrity checking for multiple-row updates of parent keys and foreign keys that reference unique keys: 1. For each row of the table T: a. Attempt to identify multiple relationships (i.e., foreign keys that reference unique keys). b. If multiple relationships were identified on table T or this is a multiple-row update, 1) Defer referential integrity checking of the parent key update; 2) If any of the columns being updated is a parent key, a) Set the Parent Key updated bit to on; and b) Save the Parent Key in a work file for deferred referential integrity checking. c. Update the Parent Key and delete its index entry. d. Try to insert a new index entry for the updated Parent Key, and if the new index entry is a duplicate of an existing index entry, then save the RID of the row of the updated Parent Key in a RIDLIST and set a defer key processing bit to on. e. If any of the columns being updated contain a Foreign Key (FK), 1) If FK references PK, defer referential integrity checking by saving the Foreign Key in a work file (i.e., when the foreign key is self-referencing, save the key in a work file); 2) Otherwise, update the Foreign Key. f. Perform referential integrity checking for any key for which referential integrity checking is not to be deferred. g. If referential integrity checking is unsuccessful, backout and return error. 2. For each row in the RIDLIST, if the defer key processing bit is on, a. Insert an index entry for the Parent Key value; and b. If duplicate, backout and return error. 3. For each key in the work file, if the parent key updated bit is on, a. Perform referential integrity checking on the key's foreign keys, if it is a parent key b. Perform referential integrity checking on this key's parent key, if it is a foreign key; c. If referential integrity checking is unsuccessful, backout and return error. FIG. 5 is a flow diagram illustrating the steps performed by the Data Manager 118 to process modifications of a table for multiple-row updates of parent keys and foreign keys that reference unique keys. In Block 500, the Data Manager 118 selects the next row of the table, starting with the first. In Block 502, the Data Manager attempts to identify multiple relationships (i.e., foreign keys referencing unique keys) or a multiple-row update. In Block 504, the Data Manager 118 determines whether multiple relationships were identified. When multiple relationships are identified, the Data Manager 118 continues to Block 506, otherwise, the Data Manager 118 continues to Block 514. In Block 506, the Data Manager 118 defers referential integrity checking. In Block 508, the Data Manager 118 determines whether any of the columns being updated is a parent key. When any of the columns being updated is a parent key, the Data Manager 118 continues to Block 510, otherwise, the Data Manager 118 continues to Block 514. In Block 510, the Data Manager 118 sets the parent key updated bit to ON. In Block 512, the Data Manager 118 saves the parent key that has not been updated in a work file. In Block 514, the Data Manager 118 updates the parent key and deletes its index entry. In Block 516, the Data Manager 118 attempts to insert a new index entry, and if there is a duplicate index entry already in the Index, the Data Manager 118 adds the RID of the row to a RID list. In Block 518, the Data Manager 118 determines whether any of the columns being updated is a foreign key. When any of the columns being updated is a foreign key, the Data Manager 118 continues to Block 520, otherwise, the Data Manager 118 continues to Block 528. In Block 520, the Data Manager 118 determines whether the foreign key (FK) references the parent key (PK). When the parent key is in a self-referencing relationship, the Data Manager 118 continues to Block 522, otherwise the Data Manager 118 continues to Block 526. In Block 522, the Data Manager 118 defers referential integrity checking. In Block 524, the Data Manager 118 saves the foreign key in the work file. In Block 526, the Data Manager 118 updates the foreign key. In Block 528, the Data Manager 118 performs referential integrity checking for each key for which referential integrity checking is not to be deferred. In Block 530, the Data Manager 118 determines whether the referential integrity checking was successful. When the referential integrity checking is successful, the Data Manager 118 continues to Block 532, otherwise the Data Manager 118 continues to Block 536. In Block 532, the Data Manager 118 determines whether all rows have been selected. When all rows have been selected, the Data Manager 118 loops back to Block 500 to select the next row, otherwise, the Data Manager 118 continues to Block 534. In Block 534, the Data Manager 118 processes the RID list and the work file. In Block 536, the Data Manager 118 backs out the updates and returns an error message. FIG. 6 is a flow diagram illustrating the steps performed by the Data Manager 118 to process a RID list and a work file for modifications of a table for multiple-row updates of parent keys and foreign keys that reference unique keys. In Block 600, the Data Manager 118 selects the next row in the RID list whose defer key processing bit is on, starting with the first. In Block 602, the Data Manager 118 inserts an index entry into the Index for the parent key value. In Block 604, the Data Manager 118 determines whether the inserted index entry is a duplicate of an existing index entry. When the inserted index entry is a duplicate, the Data Manager 118 continues to Block 606, otherwise, the Data Manager 118 continues to Block 608. In Block 606, the Data Manager 118 backs out modifications and returns an error message. In Block 608, the Data Manager 118 determines whether all rows have been selected. When all rows have not been selected, the Data Manager 118 loops back to Block 600 to select the next row, otherwise, the Data Manager 118 continues to Block 610. In Block 610, the Data Manager 118 selects the next key in the work file if parent key updated bit is on, starting with the first. In Block 612, the Data Manager 118 performs referential integrity checking on the selected key's foreign keys, when the selected key is a parent key. In Block 614, the Data Manager 118 performs referential integrity checking on the selected key's parent key, when the selected key is a foreign key. In Block 616, the Data Manager 118 determines whether the referential integrity checking was successful. When the referential integrity checking is successful, the Data Manager 118 continues to Block 620, otherwise, the Data Manager 118 continues to Block 618. In Block 618, the Data Manager 118 backs out modifications and returns an error message. In Block 620, determines whether all keys have been selected. When all keys have not been selected, the Data Manager 118 loops back to Block 610 to select the next key, otherwise, the Data Manager 118 continues to Block 622. In Block 622, the Data Manager 118 is done, and the modification was successful. Conclusion This concludes the description of the preferred embodiment of the invention. The following describes some alternative embodiments for accomplishing the present invention. For example, any type of computer, such as a mainframe, minicomputer, or personal computer, or computer configuration, such as a timesharing mainframe, local area network, or standalone personal computer, could be used with the present invention. In summary, the present invention discloses a method, apparatus, and article of manufacture for a computer-implemented data manager. The present invention provides the intelligence to select either immediate or deferred referential integrity checking. Moreover, the present invention provides deferred referential integrity checking when executing a delete rule for a self-referencing table. The present invention also provides deferred referential integrity checking for multiple-row updates of a parent key. Additionally, the present invention provides deferred referential integrity checking when modifying tables in which foreign keys reference unique keys. The foregoing description of the preferred embodiment of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto.
|
Same subclass Same class Consider this |
||||||||||