Click above to get retro games delivered to your door ever month!

                              +--------------+
                              | Customer     |
                              |--------------|
                           +--| Account_No   |-+
  +--------------+         |  | Company      | |      +--------------+
  |     Orders   |         |  | Phone_No     | |      | Payments     |
  |--------------|         |  | ...          | |      |--------------|
+-| Order_No     |         |  +--------------+ |      | Payment_No   |
| | Account_No   |.--------+                   +-----.| Account_No   |
| | Order_Date   |                                    | Pmt_Date     |
| | ...      +--------------+                         | ...          |
| +----------| Order Items  |                         +--------------+
|            |--------------|       +--------------+
+-----------.| Order_No     |       | Products     |  #######################
             | Product_No   |--+    |--------------|  #   Legend:           #
             | Qty_Orderd   |  +---.| Product_No   |  #                     #
             | ...          |       | Qty_OnHand   |  # --. parent/child    #
             +--------------+       | ...          |  # --. lookup          #
                                    +--------------+  # Primary Key         #
                                                      # Foreign Key         #
                                                      #######################


  A tree has one trunk and several branches. A branch may have several limbs,
  and each limb might subdivide even further. Eventually, however, we arrive
  at the leaf.

  To knit all these separate tables together, we create links between them.
  In each table, we create a unique identifier for each record, for example,
  the customer Account Number. Then whenever we wish to create in another
  table a reference to a given customer, we simply use that customer number.

  One more step is required to make all this work. We must create indexes for
  all the relational links. Then we can use the Clipper command SET
  RELATION to link the files together. Continuing with our invoice example,
  we'll create the following indexes:

       CUSTOMER      Account Number
       INVOICES      Account Number
       INVOICES      Invoice Number
       INVOICE       Items Invoice Number
       INVOICE       Items Product Number
       PRODUCT       Product Number

  Where we go from here depends on what we wish to accomplish. To quickly
  find the water distillers sold in the past year, we use the Product
  Number index on the ITEMS table and SEEK the requested number.

  To list the invoices issued to a given customer, we use the Account
  Number index on the ORDERS table and SEEK the desired number. To
  print an invoice, we set up a relational tree whose trunk is the orders
  table. Then we SET RELATION to the CUSTOMER file, on the field
  Account number, and to the ITEMS file, on the field Order
  number.

  First, we set a relation from the items file to the products file: now
  whenever we move in the items file, the product file automatically moves to
  the matching record. Next we set a relation from the orders file to the
  items file, using the order number: now whenever we move in the orders
  file, the items file moves automatically to the first matching item.
  Finally, we add a relation to the customer file, using the account number.
  As we move within the Invoices file, we now point automatically to both the
  customer and the items file, while the items file points in turn to the
  matching product.

  Here's a slightly different, but common way of describing these relations.
  Since the CUSTOMER table generates the account number and is
  responsible for it, it is a parent of the ORDERS and INVOICES
  tables.  Other tables which use the account number field for referencing
  customers are children of the customer table.  Similarly, ORDERS is
  parent to ITEMS and ITEMS is child to ORDERS.