IDEF
16 Feb 1996
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|||
IDEF |
||||||
|
Methodology |
|||||
|
See Bruce for the definitive exposition of the IDEF methodolgy and its history. | |||||
|
Process modeling ... | |||||
|
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 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. |
|||||
|
Process modeling ... | |||||
|
||||||