diff options
Diffstat (limited to 'docs/programmer_reference/am_foreign.html')
| -rw-r--r-- | docs/programmer_reference/am_foreign.html | 188 |
1 files changed, 99 insertions, 89 deletions
diff --git a/docs/programmer_reference/am_foreign.html b/docs/programmer_reference/am_foreign.html index 677f9554..ff175021 100644 --- a/docs/programmer_reference/am_foreign.html +++ b/docs/programmer_reference/am_foreign.html @@ -14,7 +14,7 @@ <body> <div xmlns="" class="navheader"> <div class="libver"> - <p>Library Version 11.2.5.3</p> + <p>Library Version 12.1.6.1</p> </div> <table width="100%" summary="Navigation header"> <tr> @@ -22,9 +22,7 @@ </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="am_second.html">Prev</a> </td> - <th width="60%" align="center">Chapter 3. - Access Method Operations - </th> + <th width="60%" align="center">Chapter 3. Access Method Operations </th> <td width="20%" align="right"> <a accesskey="n" href="am_cursor.html">Next</a></td> </tr> </table> @@ -39,124 +37,136 @@ </div> </div> <p> - Foreign keys are used to ensure a level of consistency between - two different databases in terms of the keys that the databases use. - In a foreign key relationship, one database is the - <span class="emphasis"><em>constrained</em></span> database. This database is actually a - secondary database which is associated with a primary database. The - other database in this relationship is the - <span class="emphasis"><em>foreign key</em></span> database. Once this relationship has - been established between a constrained database and a foreign key - database, then: -</p> + Foreign keys are used to ensure a level of consistency + between two different databases in terms of the keys that the + databases use. In a foreign key relationship, one database is + the <span class="emphasis"><em>constrained</em></span> database. This database + is actually a secondary database which is associated with a + primary database. The other database in this relationship is + the <span class="emphasis"><em>foreign key</em></span> database. Once this + relationship has been established between a constrained + database and a foreign key database, then: + </p> <div class="orderedlist"> <ol type="1"> <li> <p> - Key/data items cannot be added to the - constrained database unless that same key - already exists in the foreign key - database. - </p> + Key/data items cannot be added to the constrained + database unless that same key already exists in the + foreign key database. + </p> </li> <li> <p> - A key/data pair cannot be deleted from the foreign - key database unless some action is also taken to - keep the constrained database consistent with - the foreign key database. - </p> + A key/data pair cannot be deleted from the foreign + key database unless some action is also taken to keep + the constrained database consistent with the foreign + key database. + </p> </li> </ol> </div> <p> - Because the constrained database is a secondary database, by ensuring - it's consistency with a foreign key database you are actually ensuring - that a primary database (the one to which the secondary database is - associated) is consistent with the foreign key database. -</p> + Because the constrained database is a secondary database, + by ensuring it's consistency with a foreign key database you + are actually ensuring that a primary database (the one to + which the secondary database is associated) is consistent with + the foreign key database. + </p> <p> - Deletions of keys in the foreign key database affect the constrained database - in one of three ways, as specified by the application: -</p> + Deletions of keys in the foreign key database affect the + constrained database in one of three ways, as specified by the + application: + </p> <div class="itemizedlist"> <ul type="disc"> <li> <p> - <code class="literal">Abort</code> - </p> - <p> - The deletion of a record from the foreign database will not proceed if that key - exists in the constrained primary database. Transactions must be used to prevent - the aborted delete from corrupting either of the databases. - </p> + <code class="literal">Abort</code> + </p> + <p> + The deletion of a record from the foreign database + will not proceed if that key exists in the constrained + primary database. Transactions must be used to prevent + the aborted delete from corrupting either of the + databases. + </p> </li> <li> <p> - <code class="literal">Cascade</code> - </p> - <p> - The deletion of a record from the foreign database will also cause any records - in the constrained primary database that use that key to also be - automatically deleted. - </p> + <code class="literal">Cascade</code> + </p> + <p> + The deletion of a record from the foreign database + will also cause any records in the constrained primary + database that use that key to also be automatically + deleted. + </p> </li> <li> <p> - <code class="literal">Nullify</code> - </p> - <p> - The deletion of a record from the foreign database will cause a user specified - callback function to be called, in order to alter or nullify any records - using that key in the constrained primary database. - </p> + <code class="literal">Nullify</code> + </p> + <p> + The deletion of a record from the foreign database + will cause a user specified callback function to be + called, in order to alter or nullify any records using + that key in the constrained primary database. + </p> </li> </ul> </div> <p> - Note that it is possible to delete a key from the constrained database, - but not from the foreign key database. For this reason, if you want the - keys used in both databases to be 100% accurate, then you will have to - write code to ensure that when a key is removed from the constrained - database, it is also removed from the foreign key database. -</p> + Note that it is possible to delete a key from the + constrained database, but not from the foreign key database. + For this reason, if you want the keys used in both databases + to be 100% accurate, then you will have to write code to + ensure that when a key is removed from the constrained + database, it is also removed from the foreign key database. + </p> + <p> + As an example of how foreign key indexes might be used, + consider a database of customer information and a database of + order information. A typical customer database would use a + customer ID as the key and those keys would also appear in the + order database. To ensure an order is not booked for a + non-existent customer, the customer database can be associated + with the order database as a foreign index. + </p> <p> - As an example of how foreign key indexes might be used, consider a database - of customer information and a database of order information. A typical - customer database would use a customer ID as the key and those keys - would also appear in the order database. To ensure an order is not - booked for a non-existent customer, the customer database can be - associated with the order database as a foreign index. -</p> + In order to do this, you create a secondary index of the + order database, which uses customer IDs as the key for its + key/data pairs. This secondary index is, then, the constrained + database. But because the secondary index is constrained, so + too is the order database because the contents of the + secondary index are programmatically tied to the contents of + the order database. + </p> + <p> + The customer database, then, is the foreign key database. + It is associated to the order database's secondary index using + the <a href="../api_reference/C/dbassociate_foreign.html" class="olink">DB->associate_foreign()</a> method. In this way, an order cannot + be added to the order database unless the customer ID already + exists in the customer database. + </p> + <p> + Note that this relationship can also be configured to + delete any outstanding orders for a customer when that + customer is deleted from the customer database. + </p> <p> - In order to do this, you create a secondary index of the order - database, which uses customer IDs as the key for its key/data pairs. - This secondary index is, then, the constrained database. But because - the secondary index is constrained, so too is the order database - because the contents of the secondary index are programmatically tied - to the contents of the order database. -</p> - <p> - The customer database, then, is the foreign key database. It is - associated to the order database's secondary index using the - <a href="../api_reference/C/dbassociate_foreign.html" class="olink">DB->associate_foreign()</a> method. In this way, - an order cannot be added to the order database unless the customer ID - already exists in the customer database. -</p> - <p> - Note that this relationship can also be configured to delete any - outstanding orders for a customer when that customer is deleted from - the customer database. -</p> - <p>In SQL, this would be done by executing something like the following:</p> + In SQL, this would be done by executing something like the + following: + </p> <pre class="programlisting">CREATE TABLE customers(cust_id CHAR(4) NOT NULL, lastname CHAR(15), firstname CHAR(15), PRIMARY KEY(cust_id)); CREATE TABLE orders(order_id CHAR(4) NOT NULL, order_num int NOT NULL, cust_id CHAR(4), PRIMARY KEY (order_id), FOREIGN KEY (cust_id) REFERENCES customers(cust_id) - ON DELETE CASCADE); -</pre> - <p>In Berkeley DB, this would work as follows:</p> + ON DELETE CASCADE); </pre> + <p> + In Berkeley DB, this would work as follows: + </p> <a id="prog_am18"></a> <pre class="programlisting">struct customer { char cust_id[4]; |