From 780b92ada9afcf1d58085a83a0b9e6bc982203d1 Mon Sep 17 00:00:00 2001 From: Lorry Tar Creator Date: Tue, 17 Feb 2015 17:25:57 +0000 Subject: Imported from /home/lorry/working-area/delta_berkeleydb/db-6.1.23.tar.gz. --- docs/programmer_reference/am_foreign.html | 188 ++++++++++++++++-------------- 1 file changed, 99 insertions(+), 89 deletions(-) (limited to 'docs/programmer_reference/am_foreign.html') 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 @@
-

Library Version 11.2.5.3

+

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +
Prev Chapter 3.  - Access Method Operations - Chapter 3.  Access Method Operations  Next
@@ -39,124 +37,136 @@

- 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 - constrained database. This database is actually a - secondary database which is associated with a primary database. The - other database in this relationship is the - foreign key database. Once this relationship has - been established between a constrained database and a foreign key - database, then: -

+ 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 constrained database. This database + is actually a secondary database which is associated with a + primary database. The other database in this relationship is + the foreign key database. Once this + relationship has been established between a constrained + database and a foreign key database, then: +

  1. - Key/data items cannot be added to the - constrained database unless that same key - already exists in the foreign key - database. -

    + Key/data items cannot be added to the constrained + database unless that same key already exists in the + foreign key database. +

  2. - 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. -

    + 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. +

- 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. -

+ 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. +

- Deletions of keys in the foreign key database affect the constrained database - in one of three ways, as specified by the application: -

+ Deletions of keys in the foreign key database affect the + constrained database in one of three ways, as specified by the + application: +

- 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. -

+ 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. +

+

+ 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. +

- 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. -

+ 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. +

+

+ The customer database, then, is the foreign key database. + It is associated to the order database's secondary index using + the DB->associate_foreign() method. In this way, an order cannot + be added to the order database unless the customer ID already + exists in the customer database. +

+

+ 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. +

- 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. -

-

- The customer database, then, is the foreign key database. It is - associated to the order database's secondary index using the - DB->associate_foreign() method. In this way, - an order cannot be added to the order database unless the customer ID - already exists in the customer database. -

-

- 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. -

-

In SQL, this would be done by executing something like the following:

+ In SQL, this would be done by executing something like the + following: + 

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);
-
-

In Berkeley DB, this would work as follows:

+ ON DELETE CASCADE); +

+ In Berkeley DB, this would work as follows: + 

struct customer {
        char cust_id[4];
-- 
cgit v1.2.1