IDEF1X | Requirements Analysis: From Business Views to Architecture


Team-Fly

	Requirements Analysis: From Business Views to Architecture By David C. Hay
	Table of Contents

	Appendix B. A Comparison of Data Modeling Techniques (Syntactic Conventions)

IDEF1X

IDEF1X is a data-modeling technique that is used by many branches of the United States Federal Government [FIPS 1993] [also see Bruce 1992]. The IDEF1X version of the sample model is shown in Figure B.5.

Figure B.5. An IDEF1X Model.

graphics/bfig05.gif

Entity Types and Attributes

Entity types in IDEF1X are shown by round-cornered or square-cornered rectangles. Round-cornered rectangles represent "dependent" entity typesthose whose unique identifier includes at least one relationship to another entity type. "Independent" entity types, whose identifiers are not derived from other entity types, are shown with square corners.

The name of the entity type appears outside the box. The box is divided, with identifying attributes (here referred to as the "primary key") above the division and nonidentifying attributes below.

In multiword entity type names , the words may be separated by hyphens, underscores, or blanks.

Relationships

In IDEF1X, relationships are asymmetrical : Different symbols for optionality are used, depending on the relationship's cardinality. Unlike the other notations, symbols cannot be parsed in terms of optionality and cardinality independently. Each set of symbols describes a combination of the optionality and cardinality of the entity type next to it.

In addition to a relationship line from an entity type, the foreign key that would implement the line in a relational database design is shown as an attribute of that entity type.

If a relationship is part of an entity type's unique identifier, it is shown as a solid line; if not, it is shown as a dashed line.

Table B.1 shows, for IDEF1X and the Barker notation, all the possible combinations of cardinality and optionality on both ends of the relationship.

Cardinality/Optionality

As seen in the table, optionality is shown differently for the "many" and the "one" sides of a relationship. Most of the time, a solid circle next to an entity type means zero, one, or more occurrences of that entity type. If there is no other symbol next to the entity type on this "many" side of a relationship, the relationship is optional. See lines 1-3, and 7 in Table B.1. That is, the solid circle stands for zero, one, or more ("may be... one or more") if it is by itself. Adding the letter P makes the relationship mandatory (meaning "must be one or more") ^[1] . Adding a "1" also makes the relationship mandatory, but this changes the cardinality of the relationship to exactly one. It changes the meaning of the solid circle from "may be one or more" to "must be one and only one". (See lines 4, 6, 8, and 10 in the table.) Adding the letter Z keeps the relationship optional, but that changes the cardinality of the solid circle to "may be one and only one".

^[1] Meaning that the relationship is P ositively required.

So a solid circle may mean "must be" or "may be", and it may mean "one or more" or "one and only one", depending on the other symbols around it. That is to say, the solid circle does not convey any inherent meaning in itself.

Absence of a solid circle next to an entity type means that only one occurrence of that entity type is involved ("one and only one"). If there is no symbol next to the entity type on the "one" side of the relationship, the entity type is mandatory ("must be one and only one"), as shown in lines 1, 2, 4, 5, 1118.

Placing a small diamond symbol next to the entity type means that the other entity type in the relationship may be related to one and only one occurrence ("zero or one") of that entity type. (See lines 3, 6, 16, and 19.) This, then, is an alternative way to specify an optional one-and-only-one occurrence as an entity type. We saw above that you could also use a solid circle with a letter Z under it (see lines 2124.)

Since the solid circlewhich usually represents "may be one or more"always appears on the "many" side of a relationship, the use of the solid circle in a many-to-many relationship makes each end optional. Adding the letter "P" on one or both ends makes the end so modified mandatory (see lines 7 through 10).

Table B.1. Comparison of Barker and IDEF1X Notations

	CASE*Method Notation	CASE*Method Description	IDEF1X Description
1		Each A may be... one or more B's. Each B must be ... one and only one A. (A partially identifies B.)	One to zero or more (dependent)
2		Each A may be... one or more B's. Each B must be ... one and only one A.	One to zero or more
3		Each A may be... one or more B's. Each B may be ... one and only one A.	Zero or one to zero or more
4		Each A must be... one or more B's. Each B must be ... one and only one A.	One to one or many
5		Each A must be... one or more B's. Each B must be ... one and only one A. (A partially identifies B.)	One to one or many (dependent)
6		Each A must be... one or more B's. Each B may be ... one and only one A	One to zero or many
7		Each A may be... one or more B's. Each B may be ... one or more A's	Zero or many to zero or many
8		Each A must be... one or more B's. Each B must be ... one or more A's.	One or many to one or many
9		Each A may be... one or more B's. Each B must be ... one or more A's.	Zero or many to one or many
10		Each A must be... one or more B's. Each B may be ... one or more A's.	One or many to zero or many
11		Each A must be... one and only one B. Each B must be... one and only one A.	One to one
12	(Same as 11)	(Same as 11)
13	(Same as 11)	(Same as 11)
14	(Same as 11)	(Same as 11)
15		Each A must be... one and only one B. Each B must be... one and only one A. (B partially dependent on A.)	One to one (dependent)
16		Each A must be... one and only one B. Each B may be... one and only one A.	Zero or one to one
17		Each A may be... one and only one B. Each B must be... one and only one A.	One to zero or one
18		Each A may be... one and only one B. Each B must be... one and only one A. (A partially identifies B.)	One to zero or one (dependent)
19		Each A may be... one and only one B. Each B may be... one and only one A.	Zero or one to zero or one
20	(Same as 19)	(Same as 19)
21	(Same as 19)	(Same as 19)
22	(Same as 19)	(Same as 19)

The two ways of showing that an occurrence of one entity type "must be" related to a single occurrence of another mean that there are four different ways to represent a mandatory one to one relationship. These are shown in lines 1114. Similarly, optional one-to-one relationships can be shown in four different ways, as shown in lines 1922. One-to-one relationships that are partly optional and partly mandatory can be shown in two ways, depending on which way the model is oriented, as shown in lines 1617.

Note : The variations in notation above, which have no meaning in the conceptual model, turn out to be significant in the physical design. The difference between representations for "may be one and only one" has to do with the fact that the diamond implies an optional foreign key in the opposite entity type, while the circle with the Z simply says that there may or may not be a child occurrence. In the other cases of multiple representation of the same concept (1114, and 1922), the culprit is again physical implementation. Each of the different symbol sets is implemented in a different way. Indeed, some of the symbol combinations cannot be implemented as expressed .

In other words, the symbols are deeply linked to the implementation of the tables, not the logic of the situation. Thus, IDEF1X is fundamentally a physical database design modeling technique, not one appropriate for doing conceptual design.

Names

A relationship name is a verb or verb phrase, where multiple words are separated by spaces. Relationships are identified in both directions.

Unique Identifiers

As stated above, a unique identifier is represented in IDEF1X by the primary key which will implement it in a relational database. Since all relationships are shown by foreign-key attributes, the primary key may consist of any combination of foreign-key and non-foreign-key attributes. If a foreign key is present in the unique identifier primary key, then the otherwise dashed relationship line becomes solid, and the entity-type box acquires round corners.

Sub-type

IDEF1X shows sub-types as separate entity-type boxes, each removed from its super-type and connected to it by an "isa" relationship. (Each occurrence of a sub-type "is a[n]" occurrence of the super-type.)

There are two kinds of sub-types. In Figure B.5, the circle with two horizontal lines under it is a complete subtyping arrangement: All occurrences of the parent must be occurrences of one or the other sub-type. A circle with only one horizontal line below it is an incomplete subtyping arrangement: The sub-types do not represent all possible occurrences of the super-type.

All sub-types extending from a single sub-type symbol are mutually exclusive . Sub-types may be shown to be overlapping by being descended from different sub-type symbols attached to the same super-type entity type.

In IDEF1X, the unique identifier of the sub-type must always be identical to the identifier of the super-type. This point is reinforced by including the foreign key ("(FK)") designator next to the unique identifier of the sub-type, referring to the unique identifier of the super-type. Optionally, a "role name" may be appended to the front of the foreign-key name in the sub-type. In Figure B.5, the role names "product-code" and "service-id" are roles, appended to "item number" for the primary keys of product and service. Note that, since the keys themselves remain identical to the key of the super-type, appending role names does not change their format in any way.

An attribute used to discriminate between the sub-types is placed next to the sub-type symbol. For example, "person-organization-type" is shown in Figure B.5 to distinguish between occurrences of person and organization. If the sub-types were implemented in a single table for the super-type, this would become a separate column for discriminating between occurrences of the different sub-types.

Constraints between Relationships

IDEF1X does not have an explicit way to represent constraints between relationships. Instead of saying "A" is related to "B" or to "C", it is necessary to define an entity type, "D", and then use the sub-type notation. Thus you would say "A" is related to "D", which must be either a "B" or a "C".

The ability to express exhaustiveness and exclusivity in sub-types does carry over to this situation.

This is shown in Figure B.5 with the creation of CATALOGUE ITEM as a super-type of PRODUCT and SERVICE .

Comments

IDEF1X symbols do not map cleanly to the concepts they are supposed to model. A concept that should be represented by a single symbol requires several together, and it requires different symbols under different circumstances. That is, particular situations can be represented by more than one set of symbols, while the same symbol can mean different things, depending on context. Which symbol is used to describe a particular situation is heavily dependent on the context of that situation and on how the relationship will be implemented, not just on the situation itself.

For example, the symbol to be used for optionality depends on the cardinality of the relationship. The solid circle symbol can mean anything, depending on its setting. Similarly, a cardinality/optionality combination may be represented in different ways. This is because what is being represented is not a conceptual structure, but an implementation method.

The effect of all this is that it is prohibitively difficult to teach a nontechnical viewer to read an IDEF1X diagram.

A dominant graphic feature of any relationship line is its being solid or dashed. Barker's notation uses this feature to distinguish between relationships that are required and those that are not. Among those relationships that are, those participating in a unique identifier may be simply marked with an extra line across them, but this level of detail is often not required.

In IDEF1X, however, the solidity of a line describes the participation of one entity type in the unique identifier (primary key) of the other. This requires the analyst to begin the efforts by analyzing dependencybefore addressing the optionality or cardinality of the model's relationships.

In a real modeling situation, however, an analyst in fact normally starts by examining which entity types are required for which other entity types, and how many occurrences are involved. The details of keys or identifiers are typically not addressed until much later.

And corrections to the model are unnecessarily difficult: If you make a single error in cardinality or optionality (say, the one-to-one mandatory relationship should really be optional), then several symbols must be changed.

While it does permit showing multiple inheritance and multiple type hierarchies, the multibox approach to sub-types takes up a lot of room on the drawing, limiting the number of other entity types that can be placed on it. It also requires a great deal of space to give a separate symbol to each attribute and each relationship. Moreover, it does not clearly convey the fact that an occurrence of a sub-type is an occurrence of a super-type.

IDEF1X may be a good modeling tool to use as the basis for database design, but it does not follow the rules of good graphic design (as described at the beginning of this appendix), making it unnecessarily difficult to learn and difficult to use as a tool for analyzing business requirements jointly with users.


Team-Fly

Top