IDEF1X Information Modeling
IDEF1X states business rules as a data structure: entities are nouns, attributes adjectives, relationships verbs — and relationships are carried by keys that migrate from parent to child, never by pointers. Every structural choice asserts a constraint, so design is making those assertions say what the business means. This skill is a methodology advisor; a separate tool draws the diagrams.
The prime directive
- One fact in one place (the normalization half) and get the business rules right (the correctness half). Theory only helps; people verify the assertions are true.
- Each denormalization changes the business rules the structure states. Argue the rule that will be lost or pushed into code, not performance.
- Verify by reading the model back as sentences and by building sample instance tables — they expose wrong rules that pass every formal check.
Key migration — the one distinction to get right
The parent's primary key migrates into the child as a foreign key. Where it lands is the whole meaning:
|
Identifying (solid line) |
Nonidentifying (dashed line) |
| FK lands in |
child key area (part of child PK) |
child data area (non-key) |
| Identification |
child can't be identified without parent |
child has its own identity |
| Existence |
child can't exist without parent |
independent unless mandatory |
| FK nullable |
never |
yes, if optional (diamond on parent) |
An identifying relationship is a deliberate decision that the parent's identity is part of the child's. Never assume it; choose it.
Quick start
To read or judge any relationship: name parent and child, read parent→child with the verb ("a MOVIE has many MOVIE-COPYs"), then ask — can the child exist or be identified without the parent? Yes → nonidentifying (FK in data area); no → identifying (FK in key area). Then confirm the rule that choice asserts is the rule the business actually wants.
References
Two sources, tagged per file: [B] Thomas Bruce's book (construct semantics, design heuristics, normalization-as-business-rules) and [F] FIPS PUB 184 (the modeling procedure). Where they overlap, the process file cross-refs the Bruce files. Load the file matching your decision:
- [F]
references/modeling-process.md — the five-phase method (0 initiation → 1 entities → 2 relationships → 3 keys → 4 attributes), team roles, source material, validation/walk-through, and each phase's decision criteria and checklists.
- [B]
references/entities-keys-relationships.md — entity types, primary-key choice, migration, identifying vs nonidentifying, cardinality (P/Z/N), recursive & nonspecific relationships, role names, unification, surrogate keys, and the "when you see X it implies Y" reading guide.
- [B]
references/generalization.md — subtypes: generic parent, discriminator, complete vs incomplete clusters, AND/OR structures, the key-substitution workaround, over-generalization.
- [B]
references/names-definitions-domains.md — naming, definitions, domains as business rules, group & derived attributes.
- [B]
references/normalization-business-rules.md — normalization as business-rule correctness, the design-problem catalog (1NF–3NF), hidden errors, the find-errors checklist.
- [B]
references/referential-integrity.md — insert/replace/delete rules (Cascade/Restrict/Set Null) per relationship type.
- [B]
references/model-types-and-method.md — ERD→KBM→FAM→TM, three-schema architecture, data-centered design, reverse-engineering limits.
- [B]
references/glossary.md — every IDEF1X term, one line each.
1---2name: idef1x3description: Use when designing, reviewing, or normalizing an IDEF1X data model, or running a phased information-modeling project — entities, key migration, identifying vs nonidentifying, subtype clusters, domains, and what the notation implies.4---56# IDEF1X Information Modeling789IDEF1X states business rules as a data structure: entities are nouns, attributes adjectives, relationships verbs — and relationships are carried by **keys that migrate from parent to child**, never by pointers. Every structural choice asserts a constraint, so design is making those assertions say what the business means. This skill is a methodology advisor; a separate tool draws the diagrams.101112## The prime directive131415- **One fact in one place** (the normalization half) and **get the business rules right** (the correctness half). Theory only helps; people verify the assertions are true.16- **Each denormalization changes the business rules the structure states.** Argue the rule that will be lost or pushed into code, not performance.17- Verify by reading the model back as sentences and by **building sample instance tables** — they expose wrong rules that pass every formal check.181920## Key migration — the one distinction to get right212223The parent's primary key migrates into the child as a foreign key. *Where it lands is the whole meaning:*2425| | Identifying (solid line) | Nonidentifying (dashed line) |26|---|---|---|27| FK lands in | child key area (part of child PK) | child data area (non-key) |28| Identification | child can't be identified without parent | child has its own identity |29| Existence | child can't exist without parent | independent unless mandatory |30| FK nullable | never | yes, if optional (diamond on parent) |3132An identifying relationship is a deliberate decision that the parent's identity *is part of* the child's. Never assume it; choose it.333435## Quick start363738To read or judge any relationship: name parent and child, read parent→child with the verb ("a MOVIE has many MOVIE-COPYs"), then ask — can the child exist or be identified without the parent? Yes → nonidentifying (FK in data area); no → identifying (FK in key area). Then confirm the rule that choice asserts is the rule the business actually wants.394041## References424344Two sources, tagged per file: **[B]** Thomas Bruce's book (construct *semantics*, design heuristics, normalization-as-business-rules) and **[F]** FIPS PUB 184 (the modeling *procedure*). Where they overlap, the process file cross-refs the Bruce files. Load the file matching your decision:4546- **[F]** `references/modeling-process.md` — the five-phase method (0 initiation → 1 entities → 2 relationships → 3 keys → 4 attributes), team roles, source material, validation/walk-through, and each phase's decision criteria and checklists.47- **[B]** `references/entities-keys-relationships.md` — entity types, primary-key choice, migration, identifying vs nonidentifying, cardinality (P/Z/N), recursive & nonspecific relationships, role names, unification, surrogate keys, and the "when you see X it implies Y" reading guide.48- **[B]** `references/generalization.md` — subtypes: generic parent, discriminator, complete vs incomplete clusters, AND/OR structures, the key-substitution workaround, over-generalization.49- **[B]** `references/names-definitions-domains.md` — naming, definitions, domains as business rules, group & derived attributes.50- **[B]** `references/normalization-business-rules.md` — normalization as business-rule correctness, the design-problem catalog (1NF–3NF), hidden errors, the find-errors checklist.51- **[B]** `references/referential-integrity.md` — insert/replace/delete rules (Cascade/Restrict/Set Null) per relationship type.52- **[B]** `references/model-types-and-method.md` — ERD→KBM→FAM→TM, three-schema architecture, data-centered design, reverse-engineering limits.53- **[B]** `references/glossary.md` — every IDEF1X term, one line each.
damusix