The elements of any class fall into two broad types. First there are "fields" which are places to put data (discussed later). Second, there are "labels" which often identify fields the way "Name" precedes and explains a blank on an income tax form, or "Information about spouse" introduces a group of related blanks. You will see labels referred to as "tags" in the ACEDB technical literature.
It is simplest to start the discussion of model elements with the labels. One function of labels is that they provide the class definition with its indented outline structure. To make this easier to see, I have copied the ?TShirt model and stripped off its fields and comments:
?TShirt Characteristics Color Background Red
Green
Purple
Grey
Blue
Faded
Blotched
Size
Graphics Front
Back
Sleeves
Composition
Resembles
History Price
Purchased Year
Source Store
Manufacturer
Borrowed_by
Damage
Disposal
Remarks
Wear_on_days
Notice the sectioning suggested by the different levels of
indentation. I am using sectioning to group together things that have
something in common. There are three major sections,
"Characteristics", "History", and "Wear_on_days". These branch into
subsections; for example, "Characteristics" has divisions "Color",
"Size", "Graphics", and "Composition". "Color" itself divides into
"Background", "Faded", and "Blotched". Finally, "Background" divides
into "Red", "Green", "Purple", "Grey", and "Blue". The divisions
reflect my view of what is important in the t-shirt world. You could
create an alternative structure if you wanted.The ACEDB software senses the vertical and horizontal alignment of labels and uses it to interpret the structure in terms of a tree, with branches and forks. Each label (and ultimately each field) has a unique position on the tree. To make this a little clearer, I have transformed ?TShirt to emphasize its treeishness. The labels are now underscores, each field a "#", and related branches are connected by dots and vertical bars:
?______.._______________.._____.__________.___
| | | |____
| | | |_____
| | | |___
| | | |___
| | |____
| | |_______
| |___ #
| |_______._____ #
| | |___ #
| | |______ #
| |__________ # #
| |________ #
|______.._____ #
| |________.____ #
| | |_____._____ #
| | |___________ #
| |__________ #
| |_____ # #
| |_______ # #
| |______ #
|___________ #
You must be careful with your indentation. When you want to divide a
category into subcategories, the subcategories must be aligned, i.e.,
justified left. The first sub-category appears to the right of the
category and on the same line; any other sub-categories in the same
group appear under the first one. Thus "Characteristics", "History",
and "Wear_on_days", which represent the major categories in the model,
are aligned. When "Characteristics" divides into "Color", "Size",
"Graphics" and "Composition", these labels are also aligned. The
alignment must be maintained or the relationship between a division
and its subdivisions is lost. If you wanted to make "Remarks" a major
category along with "Characteristics" and "History", it would have to
be aligned with them. It would not do to move it left only partway;
ACEDB would not know what that means and would signal an error.Subdivisions descending from different divisions do not have to be aligned. This is why the section consisting of "Color", "Size", "Graphics", "Composition", and "Resembles" is not aligned with the section containing "Price", "Purchased", "Borrowed_by", "Damage", "Disposal", and "Remarks". You could align them if you wanted; go ahead and use as many spaces as you need. But ACEDB understands that the first group descends from "Characteristics" and the second from "History". Sub-branches originating from the same branch are connected at the branch point; subcategories originating from the same category are justified left. Additional alignments are not interpreted although they may make the model easier for you to look at.
Back to Table of Contents