| name | idef1x |
| description | 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. |
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 |
