Building information structures
An information model consists of two fundamental relation types; those who make up structures and those who relate, or interconnect, such structures. This article focuses on those that make up the structure. For information on interrelating relations see
Referencing an entity.
This article covers relationships corresponding to the
List and
Tree stereotypes available in RISE, see
how to use stereotypes for further details.
Let's look at an example. An invoice is an entity that, apart from having various attributes, has a number of rows. These rows are complex involving information on article, amount, pricing and so forth. Thus, we introduce an entity InvoiceRow to accomodate the storage of each row of invoice data. To signal ownership and structure, two principles are involved:
The cardinality of the sub-object is a matter of interpretation. Obviously, one could argue that an invoice has at least one row. This indicates that we should select cardinality 1-many rather than 0-many for the InvoiceRow node of the relation. However, if the Invoice refers to the invoice object throughout its entire life-cycle we need to create it before adding any rows and, thus, the 1-many cardinality is inappropriate.
The above structure can be repeated to accomplish any limited depth. For instance, in a general model the InvoiceRow could be implemented as having any number of columns by introducing an InvoiceColumn, or InvoiceRowColumn, entity. Another kind of structure is that of unlimited, or undefined, depth. Such a structure means using self-referencing entities.
A generic structure of undefined depth is accomplished by applying the following principles:
- Add a "0-1 to 0-many" self-refence to the entity
- Rename the single cardinality (0-1) node, for instance to Parent, to reflect its purpose
In the above example we've declared an entity, Node, such that each node might be related to a single node called Parent and have any number of sub-nodes. The unnamed, child-end, of the relation must be 0-many since a node might have zero children, otherwise the tree would "never stop". The named end, named Parent, has cardinality 0-1 since the top node doesn't have any parents, otherwise the tree "couldn't start".
If we combine these two approaches we'll end up with the necessary structure for, for instance, a file system. In this case we have a structure of folders where each folder may contain any number of documents. A document, on the other hand, must be placed in exactly one folder in the structure.
Related articles:
