View source for IDEF1X

{{Short description|Type of data modeling language}}
{{Distinguish|Idefix}}
[[Image:B 5 1 IDEF1X Diagram.jpg|thumb|320px|Example of an IDEF1X diagram.]]

'''[[IDEF|Integration DEFinition]] for information modeling (IDEF1X)''' is a [[data modeling]] [[modeling language|language]] for the development of [[semantic data model]]s. IDEF1X is used to produce a graphical [[information model]] which represents the structure and [[semantics]] of [[information]] within an environment or [[system]].<ref name ="FIPS184">[http://www.itl.nist.gov/fipspubs/idef1x.doc FIPS Publication 184] {{Webarchive|url=https://web.archive.org/web/20131203223034/http://www.itl.nist.gov/fipspubs/idef1x.doc |date=2013-12-03 }} released of IDEF1X by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST). 21 December 1993.</ref> 
 
IDEF1X permits the construction of semantic data models which may serve to support the management of data as a resource, the integration of information systems, and the building of computer [[database]]s. This standard is part of the [[IDEF]] family of modeling languages in the field of [[software engineering]].

== Overview ==
A [[data modeling]] technique is used to model [[data]] in a standard, consistent and predictable manner in order to manage it as a resource. It can be used in projects requiring a standard means of defining and analyzing the data resources within an organization. Such projects include the incorporation of a [[data modeling]] technique into a [[methodology]], managing data as a resource, integrating [[information systems]], or designing computer [[database]]s. The primary objectives of the IDEF1X standard are to provide:<ref name ="FIPS184"/> 
* Means for completely understanding and analyzing an organization's data resources
* Common means of representing and communicating the complexity of data
* A technique for presenting an overall view of the data required to run an enterprise
* Means for defining an application-independent view of data which can be validated by users and transformed into a physical database design
* A technique for deriving an integrated data definition from existing data resources.

A principal objective of IDEF1X is to support [[system integration|integration]]. The approach to integration focuses on the capture, [[management]], and use of a single semantic definition of the data resource referred to as a “[[conceptual schema]].” The “conceptual schema” provides a single integrated definition of the data within an enterprise which is not biased toward any single application of data and is independent of how the data is physically stored or accessed. The primary objective of this conceptual schema is to provide a consistent definition of the meanings of and interrelationships between data that can be used to integrate, share, and manage the integrity of data. A conceptual schema must have three important characteristics:<ref name ="FIPS184"/> 
* Consistent with the infrastructure of the business and true across all application areas
* Extendible, such that new data can be defined without altering previously defined data
* Transformable to both the required user views and to a variety of data storage and access structures.

== History ==
The need for [[semantic data model]]s was first recognized by the [[U.S. Air Force]] in the mid-1970s as a result of the [[Integrated Computer-Aided Manufacturing|Integrated Computer Aided Manufacturing]] (ICAM) Program. The objective of this program was to increase manufacturing productivity through the systematic application of computer technology. The ICAM Program identified a need for better analysis and communication techniques for people involved in improving manufacturing productivity. As a result, the ICAM Program developed a series of techniques known as the IDEF (ICAM Definition) Methods which included the following:<ref name ="FIPS184"/> 
* [[IDEF0]] used to produce a “[[function model]]” which is a structured representation of the activities or processes within the environment or system
* IDEF1 used to produce an “information model” which represents the structure and semantics of information within the environment or system
* IDEF2 used to produce a “dynamics model”.

The initial approach to IDEF information modeling (IDEF1) was published by the ICAM program in 1981, based on current research and industry needs. The theoretical roots for this approach stemmed from the early work of [[Edgar F. Codd]] on [[Relational model]] theory and [[Peter Chen]] on the [[entity-relationship model]]. The initial IDEF1 technique was based on the work of Dr R. R. Brown and Mr T. L. Ramey of [[Hughes Aircraft]] working with Dan Appleton and Stu Coleman  of D. Appleton Company (DACOM), with critical review and influence by [[Charles Bachman]], [[Peter Chen]], Dr M. A. Melkanoff, and [[G.M. Nijssen|Dr G.M. Nijssen]].<ref name ="FIPS184"/> DACOM and Hughes tested IDEF1 by modeling engineering data. Methodology improvements were proposed in two areas: modeling notation and modeling methodology and rules. Appleton's suggested improvements were accepted, the AF relabled its data modeling methodology  IDEF1 Xtended, or IDEF1X. 

In 1983, the U.S. Air Force initiated the Integrated Information Support System (I2S2) project under the ICAM program. The objective of this project was to provide the enabling technology to logically and physically integrate a network of heterogeneous computer hardware and software. As a result of this project, and industry experience, the need for an enhanced technique for data modeling was recognized.<ref name ="FIPS184"/> 

From the point of view of the contract administrators of the Air Force IDEF program, IDEF1X was a result of the ICAM IISS-6201 project and was further extended by the IISS-6202 project. To satisfy the data modeling enhancement requirements that were identified in the IISS-6202 project, D. Appleton Company obtained a license to database design software based on the logical database design technique (LDDT) developed by Robert Brown for the Bank of America. Appleton's technology team modified the software to meet IDEF1X modeling graphics and rules.

On September 2, 2008, the associated NIST standard, FIPS 184, has been withdrawn (decision on Federal Register vol. 73 / page 51276 [https://www.gpo.gov/fdsys/pkg/FR-2008-09-02/pdf/E8-20138.pdf]).

Since September 2012, IDEF1X has been incorporated into international standard ISO/IEC/IEEE 31320-2:2012.<ref name ="ISO31320">[https://www.iso.org/standard/60614.html ISO/IEC/IEEE 31320-2:2012] Information technology — Modeling Languages — Part 2: Syntax and Semantics for IDEF1X97 (IDEFobject).</ref> The standard describes the syntax and semantics of IDEF1X97, which consists of two conceptual modeling languages: a “key-style” language downward compatible with FIPS 184, which supports relational and extended relational databases, and a newer “identity-style” language suitable for object databases and [[object-oriented modeling]].

The Bank of America's logical database design technique (LDDT) had been developed in 1982 by Robert Brown. The central goal of IDEF1X and LDDT was the same: to produce a methodology that consistently and faithfully produced a database-neutral model of the persistent information needed by an enterprise by modeling the real-world entities involved. IDEF1X combined elements of the relational data model, the [[Entity–relationship model|E-R model]], and data generalization in a way specifically intended to support data modeling and the transformation of the data models into database designs.

IDEF1X includes an environmental (namespace) hierarchy, multiple levels of model, the modeling of generalization/specialization, and the explicit representation of relationships by primary and foreign keys, supported by a well defined role naming facility. The primary keys and unambiguously role-named foreign keys expressed sometimes subtle uniqueness and [[referential integrity]] constraints that needed to be known and honored by whatever type of database was ultimately designed. Whether the database design used the integrity constraint based keys of the IDEF1X model as database access keys or indexes was an entirely separate decision. The precision and completeness of the IDEF1X models was an important factor in enabling the relatively smooth transformation of the models into database designs. Early IDEF1X models were transformed into database designs for IBM's hierarchical database, [[IBM Information Management System|IMS]]. Later models were transformed into database designs for Cullinet's network database, IDMS, and many varieties of relational database.

Appleton produced IDEF1X data modeling software called Leverage. Leverage supported view (model) entry, view merging, selective (subset) viewing, namespace inheritance, normalization, a quality assurance analysis of views, entity relationship graph and report generation, transformation to a relational database expressed as SQL data declaration statements, and referential integrity checking SQL. Logical models were serialized with a structural modeling language.

== IDEF1X building blocks ==
<gallery class="center" classes="center">
File:1 Entity Syntax.svg|Entity syntax
File:2 Example of a Domain Hierarchy.svg|Domain hierarchy
File:A3 11 Attribute Examples.jpg|Attribute example
File:3 Attribute and Primary Key Syntax.svg|Primary key syntax
</gallery>

;Entities : The representation of a class of real or abstract things (people, objects, places, events, ideas, combination of things, etc.) that are recognized as instances of the same class because they share the same characteristics and can participate in the same relationships.
; Domains: A named set of data values (fixed, or possibly infinite in number) all of the same data type, upon which the actual value for an attribute instance is drawn. Every attribute must be defined on exactly one underlying domain. Multiple attributes may be based on the same underlying domain.
; Attributes: A property or characteristic that is common to some or all of the instances of an entity. An attribute represents the use of a domain in the context of an entity.
; Keys: An attribute, or combination of attributes, of an entity whose values uniquely identify each entity instance. Each such set constitutes a candidate key.
; Primary keys: The candidate key selected as the unique identifier of an entity.
; Foreign keys: An attribute, or combination of attributes of a child or category entity instance whose values match those in the primary key of a related parent or generic entity instance. A foreign key can be viewed as the result of the "migration" of the primary key of the parent or generic entity through a specific connection or categorization relationship. An attribute or combination of attributes in the foreign key can be assigned a role name reflecting its role in the child or category entity.

<gallery class="center" classes="center">
File:4 Relationship Cardinality Syntax.jpg|Relationship cardinality syntax
File:5 Identifying Relationship Syntax.jpg|Identifying relationship syntax
File:8 Categorization Relationship Syntax.svg|Categorization relationship syntax
File:9 Non-Specific Relationship Syntax.jpg|Non-specific relationship syntax
</gallery>

;Relationships: An association between the instances of two entities or between instances of the same entity.
; Connection relationships: A relationship having no semantics in addition to association. See constraint, cardinality.
; Categorization relationships: A relationship in which instances of both entities represent the same real or abstract thing. One entity (generic entity) represents the complete set of things, the other (category entity) represents a sub-type or sub-classification of those things. The category entity may have one or more characteristics, or a relationship with instances of another entity, not shared by all generic entity instances. Each instance of the category entity is simultaneously an instance of the generic entity.
; Non-specific relationships: A relationship in which an instance of either entity can be related to any number of instances of the other.
; View levels: Three levels of view are defined in IDEF1X: entity relationship (ER), key-based (KB), and fully attributed (FA). They differ in level of abstraction. The ER level is the most abstract. It models the most fundamental elements of the subject area - the entities and their relationships. It is usually broader in scope than the other levels. The KB level adds keys and the FA level adds all the attributes.
<!-- 
;View Presentation; 
; Model Notes & Model Note Rules
-->

== IDEF1X topics ==

=== The three-schema approach  ===
[[File:A2 3 Three schema approach.svg|thumb|280px|The [[three schema approach]] .<ref name= "ITL93">itl.nist.gov (1993) [http://www.itl.nist.gov/fipspubs/idef1x.doc ''Integration Definition for Information Modeling (IDEFIX)''] {{Webarchive|url=https://web.archive.org/web/20131203223034/http://www.itl.nist.gov/fipspubs/idef1x.doc |date=2013-12-03 }}. 21 Dec 1993.</ref>]]
The [[three-schema approach]] in software engineering is an approach to building information systems and systems information management, that promotes the [[Conceptual schema|conceptual model]] as the key to achieving [[data integration]].<ref name="STRAP08">[http://www.fas.org/irp/doddir/army/strap/strpsec2.htm STRAP SECTION 2 APPROACH]. Retrieved 30 September 2008.</ref>

A [[Model (abstract)|schema]] is a [[scientific modelling|model]], usually depicted by a [[diagram]] and sometimes accompanied by a language description. The three schemas used in this approach are:<ref>Mary E.S. Loomis (1987). [https://archive.org/details/databasebook0000loom ''The Database Book'']. p. 26.</ref>
* External schema for user views
* [[Conceptual schema]] integrates external schemata
* Internal schema that defines physical storage structures.

At the center, the conceptual schema defines the [[ontology]] of the [[concept]]s as the [[user (computing)|user]]s think of them and talk about them. The physical schema describes the internal formats of the [[data]] stored in the [[database]], and the external schema defines the view of the data presented to the [[application program]]s.<ref name ="JFS04">[[John F. Sowa]] (2004). [https://www.jfsowa.com/pubs/challenge.pdf "The Challenge of Knowledge Soup"]. published in: ''Research Trends in Science, Technology and Mathematics Education''. Edited by J. Ramadas & S. Chunawala, Homi Bhabha Centre, Mumbai, 2006.</ref> The framework attempted to permit multiple data models to be used for external schemata.<ref>Gad Ariav & James Clifford (1986). ''New Directions for Database Systems: Revised Versions of the Papers''. New York University Graduate School of Business Administration. Center for Research on Information Systems, 1986.</ref>

=== Modeling guidelines ===
[[Image:A3 2 Synthesizing an Entity.jpg|thumb|Synthesizing an entity in phase one – entity definition]]
The modeling process can be divided into five stages of model developing.

;Phase zero – project Initiation
:The objectives of the project initiation phase include:
:* Project definition – a general statement of what has to be done, why, and how it will get done
:* Source material – a plan for the acquisition of source material, including indexing and filing
:* Author conventions – a fundamental declaration of the conventions (optional methods) by which the author chooses to make and manage the model.

;Phase one – entity definition
:The objective of the entity definition phase is to identify and define the entities that fall within the problem domain being modeled.

;Phase two – relationship definition
:The objective of the relationship definition phase is to identify and define the basic relationships between entities. At this stage of modeling, some relationships may be non-specific and will require additional refinement in subsequent phases. The primary outputs from phase two are:
:* Relationship matrix
:* Relationship definitions
:* Entity-level diagrams.

<gallery class="center" classes="center">
File:A3 4 Entity Relationship Matrix.jpg|Entity relationship matrix
File:A3 5 Entity Level Diagram.jpg|Entity level diagram
File:A3 6 Phase Two (Entity Level) Diagram Example.jpg|Entity level diagram example
File:A3 7 Reference Diagram (FEO).jpg|Reference diagram
</gallery>

;Phase three - key definitions
:The objectives of the key definitions phase are to:
:* Refine the non-specific relationships from phase two
:* Define key attributes for each entity
:* Migrate primary keys to establish foreign keys
:* Validate relationships and keys.

<gallery class="center" classes="center">
File:A3 8 Example Reference Diagram.jpg|Example reference diagram
File:A3 9 Non-Specific Relationship Refinement.jpg|Non-specific relationship refinement
File:A3 10 Scope of a Function View.jpg|Scope of a function view
File:A3 11 Attribute Examples.jpg|Attribute examples
File:A3 16 No-Repeat Rule Refinement.jpg|No-repeat rule refinement
File:A3 17 Rule Refinement.jpg|Rule refinement
File:A3 19 Path Assertions.jpg|Path assertions
File:A3 21 Example of Phase Three Function View Diagram.jpg|Example of phase three function view diagram
</gallery>

;Phase four - attribute definition
:The objectives of the attribute definition phase are to:
:* Develop an attribute pool
:* Establish attribute ownership
:* Define non-key attributes
:* Validate and refine the data structure.

<gallery class="center" classes="center">
File:A3 23 Phase Four - Applying the No Repeat Rule.jpg|Applying the no repeat rule
File:A3 24 Example of Phase Four Function.jpg|Example of phase four function
</gallery>

=== IDEF1X meta model ===
[[Image:B 5 1 IDEF1X Diagram.jpg|thumb|280px|Meta model of IDEF1X.]]

A meta model is a model of the constructs of a modeling system. Like any model, it is used to represent and reason about the subject of the model - in this case IDEF1X. The meta model is used to reason about IDEF1X, i.e., what the constructs of IDEF1X are and how they relate to one another. The model shown is an IDEF1X model of IDEF1X. Such [[metamodeling|meta model]]s can be used for various purposes, such as repository design, tool design, or in order to specify the set of valid IDEF1X models. Depending on the purpose, somewhat different models result. There is no “one right model.” For example, a model for a tool that supports building models incrementally must allow incomplete or even inconsistent models. The meta model for formalization, however, emphasizes alignment with the concepts of the formalization and hence incomplete or inconsistent models are not allowed.

Meta models have two important limitations. First, they specify syntax but not semantics. Second, a meta model must be supplemented with constraints in natural or formal language. The formal theory of IDEF1X provides both the semantics and a means to precisely express the necessary constraints.

A meta model for IDEF1X is given in the adjacent figure. The name of the view is ''mm''. The domain hierarchy and constraints are also given. The constraints are expressed as sentences in the formal theory of the meta model. The meta model informally defines the set of valid IDEF1X models in the usual way, as the sample instance tables that correspond to a valid IDEF1X model. The meta model also formally defines the set of valid IDEF1X models in the following way. The meta model, as an IDEF1X model, has a corresponding formal theory. The semantics of the theory are defined in the standard way. That is, an interpretation of a theory consists of a domain of individuals and a set of assignments:
* To each constant in the theory, an individual in the domain is assigned
* To each ''n''-ary function symbol in the theory, an ''n''-ary function over the domain is assigned
* To each ''n''-ary predicate symbol in the theory, an ''n''-ary relation over the domain is assigned.
In the intended interpretation, the domain of individuals consists of views, such as production; entities, such as part and vendor; domains, such as {{Mono|qty_on_hand}}; connection relationships; category clusters; and so on. If every axiom in the theory is true in the interpretation, then the interpretation is called a model for the theory. Every model for the IDEF1X theory corresponding to the IDEF1X meta model and its constraints is a valid IDEF1X model.

== See also ==
* [[Conceptual model (computer science)]]
* [[Entity–relationship model#Crow's foot notation|Crow's foot notation]]
* [[ER/Studio]]
* [[Enterprise Architect (software)]]
* [[IDEF0]]
* [[IDEF5]]
* [[ISO 10303]]
* [[Logic Works]]
* [[Weak entity]]

== References ==
{{NIST-PD}}
{{Reflist}}

== Further reading ==
* Thomas A. Bruce (1992). ''Designing Quality Databases With Idef1X Information Models''. Dorset House Publishing.
* Y. Tina Lee & Shigeki Umeda (2000). [https://www.nist.gov/publications/idef1x-information-model-supply-chain-simulation "An IDEF1x Information Model for a Supply Chain Simulation"].

== External links ==
{{Commons category|IDEF1X}}
* [https://www.iso.org/standard/60614.html ISO/IEC/IEEE 31320-2:2012]
* [https://web.archive.org/web/20131203223034/http://www.itl.nist.gov/fipspubs/idef1x.doc FIPS Publication 184] Announcing the IDEF1X Standard December 1993 by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST). (Withdrawn by NIST 08 Sep 02 see [https://web.archive.org/web/20100801020458/http://www.itl.nist.gov/fipspubs/withdraw.htm Withdrawn FIPS by Numerical Order Index])
* [https://www.gpo.gov/fdsys/pkg/FR-2008-09-02/pdf/E8-20138.pdf Federal Register vol. 73 / page 51276] withdrawal decision
* [http://www.idef.com/idef1X.htm Overview of IDEF1X] {{Webarchive|url=https://web.archive.org/web/20160308075846/http://www.idef.com/idef1X.htm |date=2016-03-08 }} at www.idef.com
* [http://www.essentialstrategies.com/publications/modeling/idef1x.htm IDEF1X] Overview from Essential Strategies, Inc.

{{Authority control}}

{{DEFAULTSORT:Idef1x}}
[[Category:Data modeling]]
[[Category:Data modeling diagrams]]
[[Category:Data modeling languages]]
[[Category:Systems analysis]]