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

  This chapter is intended for those who are vague about such terms as
  relation, primary index, and normalisation.

  Understanding these terms is crucial to excellent use of both Clipper
  and Artful. If you do not understand these terms explicitly, please
  read this chapter.

  Entities and Relationships

  An entity, such as a customer, embodies a variety of information.
  Some is simple, such as the customer name. Often, but not always,
  each customer operates under a unique name. One customer, one name:
  this is a one-to-one relationship. Some information includes a cluster
  of detail: a given customer has a history with your firm, a history
  of sales, invoices and payments. For a given customer, there are many
  such details. This is called a one-to-many relationship.

  There are several ways of storing this data; they correspond to the
  history of thinking about database management. The earliest model
  is the flat file. One possible model is called the hierarchical model.
  Another is the relational model. Another is the record-oriented, or
  quasi-relational, model. Lastly, just now beginning to emerge in actual
  products, is the object-oriented model.

  Clipper belongs to the record-oriented school of thinking. This has
  several advantages. You can do anything you want: in other systems,
  your abilities stem directly from your position in the database. In
  an SQL system, for example, you cannot move to the previous record
  in a table: you can only process sets of records. A record-oriented
  model, by contrast, lets you move from record to record in whatever
  fashion you choose. The downside is that you do not have available
  many of the powerful SQL constructs that deal with sets of
  records.

  Nevertheless, we feel that the advantages of the record-oriented model
  outweigh the liabilities. For one thing, in the record-oriented model,
  you are free to construct set-oriented functions. This is precisely
  what Artful has done, in fact. It can provide control over cascading
  replaces and deletes, for example.

  Depending on how you set up your engine, you can specify what sort
  of chain reactions should occur upon a given event. For example, should
  the user wish to change a Customer account number, you can automatically
  cause updates in all child tables (Payments, Orders and Invoices),
  simply by setting the dictionary flags for the master table appropriately.