IDEF1X has proven to be a useful and powerful tool for modeling a conceptual schema. IDEF1X models define data in a fully normalized structure, which allows an initial model to be extended without altering the initial set of entities, relationships, and attributes. An IDEF1X model of a conceptual schema can be easily subsetted and formally mapped through relational algebra to both external and internal schema. The U.S. Air Force IISS and IDS projects have successfully demonstrated the use of IDEF1X mo dels and its formal mappings to manage data stored under the control of each of the classical database models (hierarchical, network, and relational). IDEF1X models are also being used to automatically generate database designs and data integrity control logic.
IDEF1X semantic constructs are formally defined mathematically (using both set theory and first order logic) based on extensions to the relational theory work of Dr. Ted Codd and the entity-relationship modeling work of Dr. Peter Chen. IDEF1X also incorporates ideas such as property inheritance and semantic constructs for generalization, aggregation, classification, and association developed as a result of AI research on semantic networks. IDEF1X provides a full set of semantic modeling capabilities wh ile maintaining the "economy of concepts" associated with basic E-R modeling.
The result of applying the IDEF1X modeling technique is a specification of data meanings and rules typically represented by the following:
In key-based and fully attributed models, a distinction is made between two types of entities. An entity is "identifier-independent" or simply "independent" if each instance of the entity can be uniquely identified without determining its relationship to another entity. An entity is "identifier-dependent" or simply "dependent" if the unique identification of an instance of the entity depends upon its relationship to another entity.
An entity is represented as a box as shown in Figure 4-1. If the entity is identifier-dependent then the corners of the box are rounded. Each entity is assigned a unique name and positive integer which are separated by a slash, "/", and placed above the box. The entity name is a noun phrase (a noun with optional adjectives and prepositions) that describe the set of things the entity represents. The noun phrase is singular, not plural. Abbreviations and acronyms are permitted; however, the entity name must be meaningful and consistent throughout the model. A formal definition of the entity and a list of synonyms or aliases must be defined in the model glossary. Although an entity may be drawn in any number of diagrams, it only appears once within a given diagram.
Figure 4-1 Entity Syntax
A non-specific relationship, also referred to as a "many to many relationship", is an association between two entities in which each instance of the first entity is associated with zero, one, or many instances of the second entity and each instance of the second entity is associated with zero, one, or many instances of the first entity. For example, if an employee can be assigned to many projects and a project can have many employees assigned, then the connection between the entities EMPLOYEE and PROJECT can be expressed as a non-specific relationship. This non-specific relationship can be replaced with specific relationships later on in the model development by introducing a third entity, such as PROJECT-ASSIGNMENT, which is a common child entity in specific connection relationships with the EMPLOYEE and PROJECT entities. The new relationsh ips would specify that an employee has zero, one, or more project assignments and that a project has zero, one or more project assignments. Each project assignment is for exactly one employee and exactly one project. Entities introduced to resolve non-specific relationships are sometimes called "intersection" or "associative" entities.
A non-specific relationship is depicted as a line drawn between the two associated entities with a dot at each end of the line. See Figure 4-2. A non-specific relationship is named in both directions. The relationship names are expressed as a verb phrase (a verb with optional adverbs and prepositions) placed beside the relationship line and separated by a slash, "/".
Figure 4-2 Non-Specific Relationship Syntax
The connection relationship may be further defined by specifying the cardinality of the relationship. That is, the specification of how many child entity instances may exist for each parent instance. Within IDEF1X, the following relationship cardinalities can be expressed:
If an instance of the child entity is identified by its association with the parent entity, then the relationship is referred to as an "identifying relationship". For example, if one or more tasks are associated with each project and tasks are only uniquely identified within a project, then an identifying relationship would exist between the entities PROJECT and TASK. That is, the associated project must be known in order to uniquely identify one task from all other tasks. (Also see Foreign Keys Semantics )
If every instance of the child entity can be uniquely identified without knowing the associated instance of the parent entity then the relationship is referred to as a "non-identifying relationship". For example, although an existence-dependency relationship may exist between the entities BUYER and PURCHASE-ORDER, purchase orders may be uniquely identified by a purchase order number without identifying the associated buyer.
Assertions that affect multiple relationships may also be defined. One type of assertion may specify a Boolean constraint between two or more relationships. For example, an "exclusive OR" constraint states that for a given parent entity instance if one type of child entity instance exists, then a second type of child entity instance will not exist. However, if both the parent and child entities refer to the same real world thing, then a potential categorization relationship exists (See Categorization R elationship Semantics).
Another type of constraint is a "path assertion," which constrains the specific instances of parent and child entities when two entities can be related either directly or indirectly through two different sequences of relationships. For example, the entity DEPARTMENT may have two child entities, EMPLOYEE and PROJECT. If the entities EMPLOYEE and PROJECT have a common child entity called PROJECT-ASSIGNMENT, then PROJECT-ASSIGNMENT is indirectly related to DEPARTMENT via two different relationship paths. A path assertion might state that "employees may only be assigned to projects which belong to the same department for which they work".
A specific connection relationship is depicted as a line drawn between the parent entity and the child entity with a dot at the child end of the line. The default child cardinality is zero, one, or many. A "P" (for positive) is placed beside the dot to indicate a cardinality of one or more. A "Z" is placed beside the dot to indicate a cardinality of zero or one. If the cardinality is an exact number, a positive integer number is placed beside the dot. See Figure 4-3.
A solid line depicts an identifying relationship between the parent and child entities. See Figure 4-4. If an identifying relationship exists the child entity is always an identifier-dependent entity, represented by a rounded corner box, and the primary key attributes of the parent entity are also inherited primary key attributes of the child entity. (Also see Foreign Keys Semantics).
The parent entity in an identifying relationship will be identifier-independent unless the parent entity is also the child entity in some other identifying relationship, in which case both the parent and child entity would be identifier-dependent. An entity may have any number of relationships with other entities. However, if the entity is a child entity in any identifying relationship, it is always shown as a identifier-dependent entity with rounded comers, regardless of its role in the other relationshi ps.
A dashed line depicts a non-identifying relationship between the parent and child entities. See Figure 4-5. Both parent and child entities will be identifier-independent entities in a non-identifying relationship unless either or both are child entities in some other relationship which is an identifying relationship.
A relationship is given a name, expressed as a verb phrase (a verb with optional adverbs and prepositions) placed beside the relationship line. The name of each relationship between the same two entities must be unique, but the relationship names need not be unique within the model. The relationship name is always expressed in the parent-to-child direction, such that a sentence can be formed by combining the parent entity name, relationship name, cardinality expression, and child entity name. For example , the statement "A project consists of one or more tasks" could be derived from a relationship showing PROJECT as the parent entity, TASK as the child entity with a "P" cardinality symbol, and "CONSISTS OF" as the relationship name. Note that the relationship must still hold true when stated from the reverse direction, although the child-to-parent relationship is not named explicitly. From the previous example, it is inferred that "a task is part of exactly one project."
A "complete categorization relationship" is a relationship between two or more entities, in which each instance of one entity, referred to as the generic entity, is associated with exactly one instance of one and only one of the other entities, referred to as category entities. Each instance of the generic entity and its associated instance of one of the category entities represents the same real-world thing and, therefore, have the same unique identifier. From the previous example, EMPLOYEE is the gen eric entity and SALARIED-EMPLOYEE and HOURLY-EMPLOYEE are category entities.
Category entities for a generic entity are always mutually exclusive. That is, an instance of the generic entity can correspond to the instance of only one category entity. In the example, this implies that an employee cannot be both salaried and hourly. The IDEF1X syntax does allow, however, for an incomplete set of categories. If it is possible that an instance of the generic entity is not associated with any of the category entities, then the relationship is defined as an "incomplete categorizatio n relationship."
An attribute value in the generic entity instance determines to which of the possible category entities it is related. This attribute is called the "discriminator" of the categorization relationship. In the previous example, the discriminator might be named EMPLOYEE-TYPE.
A categorization relationship is shown as a line extending from the generic entity to a circle which is underlined. Separate lines extend from the underlined circle to each of the category entities. Cardinality is not specified for the category entity since it is always zero or one. Category entities are also always identifier-dependent. See Figure 4-6. The generic entity is independent unless its identifier is inherited through some other relationship.
If the circle has a double underline, it indicates that the set of category entities is complete. A single line under the circle indicates an incomplete set of categories.
The name of the generic entity attribute used as the discriminator is written beside the circle. Although the relationship itself is not named explicitly, the generic entity to category entity relationship can be read as "can be." For example, an EMPLOYEE can be a SALARIED-EMPLOYEE. If the complete set of categories is referenced, the relationship may be read as "must be." For example, an EMPLOYEE must be a SALARIED-EMPLOYEE or an HOURLY-EMPLOYEE. The relationship is read as "is a/an" from the rever se direction. For example, an HOURLY-EMPLOYEE is an EMPLOYEE.
The generic entity and each category entity must have the same key attributes. However, the role names may be used in the category entities. (Also, see Foreign Keys Semantics)
|Management Structure||Management Structure||Management Structure|