Who is AIS? News about this site Reviews of CASE products Reading - White Papers CASE technology training  & consulting CASE technology training  & consulting
Who is AIS? Users' Groups & Feedback Opinions - We have strong ones! Links to Other Pages of Interest Training & Consulting
AIS CASE Home Page Site Table of Contents Private Pages E-mail to AIS  

IDEF
 
 
 


16 Feb 1996

Methodology

 

 

IDEF

See Bruce for the definitive exposition of the IDEF methodolgy and its history.  
             

IDEF0

Process modeling ...  
             

IDEF1X

(e.g., ER/Studio, ERwin, Info-
Modeler)

Note bene: We dislike IDEF1X. It is a low-level, physically oriented method which makes some narrow and arbitrary constraints on the design process. IDEF1X is unsuited for large scale data modeling and we personally do not know any enterprise data architects who suffer its use willingly.

IDEF1X immediately requires every attributes to be either primary or non-primary. Life doesn't work that way. We gather facts, classify them ,and much later in the logical modeling refinement we impose artificial schemes of identifiication.
IDEF1X classifies entites as either independent or dependent. While this may be helpful in noting certain common implementations of business facts, independence or dependence is not a fundamental characteristic of an entity but rather a human means of classifying. Once again IDEF1X leads its practitioners into illogical and obscuring word traps.

IDEF1X insists that all generalization (sub-type) hierarchies are automatically and implicitly exclusive. Therefore a super-type instance can never occur in more than one sub-type instance. This is nonesense. Can a person be only one of customer or employee? Of course not. And other generalization methods allow specialization (sub-type) sets which are exclusive or non-exclusive.

Since IDEF1X is a purely physical representation of data structures, it does not recognize that conceptual super-type/sub-type hierarchies may not be impletmented directly in mirrored tables. Thus all the possibilities of upward and downward denormalization are ignored.

IDEF1X treats non-specific relationships as comments and requires that the designer eliminate them manually before generating DDL. While this is good practice and we recommend the same steps, ER/1 allows the user to leave non-specific relationships in place with no warning that they will generate nothing in the DDL. PowerDesigner and other non-IDEF1X tools will automatically convert many-to-many relationships into associative tables, which is a lot safer than ignoring them.

 
             

IDEF3

Process modeling ...  

 

Copyright 1997 Applied Information Science