|
|
|
|
"Information Engineering" was originally developed by Clive Finkelstein in Australia the late 1970’s. He collaborated with James Martin to publicize it in the United States and Europe [Martin & Finkelstein 1981], and then Martin went on from there to become predominantly associated with it [Martin & McClure, 1985]. Mr. Finkelstein later published his own version [Finkelstein 1989] and [Finkelstein 1992]. Because of the dual origin of the techniques, there are minor variations between Mr. Finkelstein’s and Mr. Martin’s notations The Information Engineering version of our test case ( with some of the notations from each version) is shown in Figure 3.
In the example, each party is vendor in zero, one, or more purchase orders, each of which initially has zero, one or more line items, but eventually it must have at least one line item. Each line item, in turn, is for either exactly one product or exactly one service.
Entities and attributes
Mr. Finkelstein defines entity in the designer’s sense of representing "data to be stored for later reference". [Finkelstein 1992, 23] Martin, however, adopts the analyst’s definition that "an entity is something (real or abstract) about which we store data." [Martin & McClure 1985, 249]
Entities are shown in square-cornered rectangles. An entity’s name is inside its rectangle. Attributes are not shown at all. Mr. Finkelstein shows them in a separate document, the "entity list". Mr. Martin has another modeling technique, called "bubble charts", specifically for modeling attributes, keys, and other attribute characteristics.
Names of entities are common terms, and the words in multi-word names are separated by spaces.
Relationships
Relationships are shown as solid lines between pairs of entities, with symbols on each end to show cardinality and optionality.
Cardinality/optionality
Each relationship in Information Engineering has two halves, with each half described by one or more symbols. If an occurrence of the first entity may or may not be related to occurrences of the second, a small open circle appears near the second entity. If it must have at least one occurrence of the second, a short line crosses the relationship line instead. If an occurrence of the first entity can be related to no more than one of the second entity ("one and only one"), another short line crosses the relationship. If it can be related to more than one of the second entity ("one or more"), a crow’s foot is put at the intersection of the relationship and the second entity box.
For example, in Figure 3, a party is vendor in zero, one, or more purchase orders. A purchase order, on the other hand, is to one and only one (1,1) party.
Mr. Finkelstein has a unique notation, shown in the Figure. Note that each purchase order initially may have one or more line items, but eventually it must have at least one. That is, it is possible to create a purchase order without having to fill in the line items immediately, but at least one must be added later. The bar across the line between the circle and the crow’s foot shows this.
Names
Mr. Martin names relationships with verbs, often only in one direction. Mr. Finkelstein doesn’t name relationships at all. In this example, relationship names are read in a clockwise direction.
Unique identifiers
Unique identifiers are not represented in an Information Engineering data model. Mr. Martin shows them separately in "bubble diagrams".
Sub-types
Mr. Martin represents sub-types as boxes within their super-type box. (Each occurrence of a sub-type "is a[n]" occurrence of the super-type.) This is shown in the figure. PERSON and ORGANIZATION are sub-types of PARTY. Mr Finkelstein portrays them as separate boxes, with a linked with "isa" relationship lines.
Constraints between relationships
In Information Engineering notation, a constraint between relationships is shown by the relationship halves of the three (or more) entities involved meeting at a small circle. If the circle is solid, the relationship between the relationships is "exclusive or", meaning that each occurrence of the base entity must (or may) be related to occurrences of one other entity, but not more than one. This is shown in the Figure where each line item is for either one product or is for one service, but not both. If the circle is open, it is an "inclusive or" relationship, meaning that an occurrence of the base entity must (or may) be related to occurrences of one, some, or all of the other entities.
Comments
Information Engineering is widely practiced. It is reasonably concise and attractive, consistent, and has a minimum of clutter. It is, however, missing important notations for attributes and unique identifiers. Mr. Martin’s approach to sub-types is compact and therefore desirable it models are to be presented to the non-technical community. Mr. Finkelstein’s notation for "initially may be but eventually must be" is a very ingenious solution to a common modeling situation, not found in any other notation.