AI Glossary / Data engineering and architecture / Intermediate

Hierarchical Data Model

Definition

The hierarchical data model organizes records through parent-child relationships arranged as a tree. A parent can have several children, while a child in the basic tree has one parent. Records are understood partly through their position and path in the hierarchy. IBM IMS is a major implementation example, although its practical features extend beyond the simplest introductory tree model.

What it means

A company record might contain department records, each containing employee records. The hierarchy makes a particular containment relationship explicit and provides a natural route for accessing related information. It is especially understandable when the domain has a stable one-to-many structure. Relationships that cross branches or involve multiple parents require additional modeling or implementation mechanisms; they do not fit the basic tree without further decisions.

How it works

Define record or segment types and their permitted parent-child relationships. Store occurrences under the appropriate parent, starting from root records. Applications navigate or query the hierarchy using the system's access methods. In IMS terminology, segments are the building blocks and a database record includes a root occurrence and its dependent hierarchy. Logical relationships and other product features can support access beyond a naive tree. The conceptual hierarchy should not be confused with a claim that all related bytes are always physically adjacent on disk.

Three practical examples

• Legacy processing: an application accesses a customer and the customer's dependent orders along a defined hierarchy.
• Organizational records: departments and subordinate units are represented as a tree when each unit has a single governing parent.
• AI data extraction: a team converts hierarchical records into an analytical dataset while preserving parent identifiers and path context so child facts are not detached from their meaning.

Think of it this way

Think of a family of folders, with subfolders beneath a root. A path explains where an item belongs. The analogy is limited because database records have defined types, constraints, and access operations, and real products may support logical relationships across the physical hierarchy. A folder tree also does not establish that every business relationship can be represented by simple containment.

Worked example

A toy hierarchy has root customer C1, child orders O1 and O2, and line items beneath each order. O1 has lines L1 and L2; O2 has L1. The label L1 is unique only within its order in this example. Flattening the records into rows must preserve the relevant path: (C1,O1,L1), (C1,O1,L2), and (C1,O2,L1). If an extractor keeps only LineID, it may incorrectly merge the two L1 occurrences. Now suppose product P7 appears in several orders. Product identity is a different relationship from order-line containment. Copying product details into every line can introduce update questions, while an explicit reference or separate product representation can preserve shared identity. The correct design depends on the system's supported mechanisms and the intended facts.

Illustrative case study

Fictional example: Willow Components migrates a hierarchical parts-service database. Its first export loses the parent path for repeated child identifiers. The team revises the mapping to include the full required identity context and tests records with absent children and repeated local labels. It documents which relationships are containment and which are shared references. This invented case illustrates migration interpretation; it does not claim that every hierarchical system uses local child identifiers or that a relational target is always the best replacement.

Common misconceptions and mistakes

Do not confuse the hierarchical data model with any table that happens to store a parent identifier. Relational systems can represent trees without becoming hierarchical databases in the historical model sense. Do not assume every real implementation supports only a bare tree. Avoid treating hierarchy as a universal fit for many-to-many relationships. Also separate schema-level parent-child types from individual record occurrences, and distinguish navigation order from business chronology or priority.

Business use

Understanding the model is useful for maintaining established systems, designing tree-shaped domains, and extracting legacy data. Identify root and child types, parent context, supported access paths, and cross-branch relationships. During migration, reconcile complete records rather than only isolated segment counts. For AI pipelines, preserve enough context to explain which parent each observation belongs to and avoid treating repeated child names as global identifiers. Evaluate operational requirements before choosing a model merely because a diagram looks intuitively hierarchical.

People also ask

Can a parent have many children?

Yes. One-to-many parent-child relationships are central to the basic model.

Can the basic tree give one child two parents?

No. Representing that situation requires another modeling approach or additional implementation mechanisms.

Is a JSON document automatically a hierarchical database?

No. Nested data has a hierarchy, but the database model and access semantics require a broader description.

Check your understanding

Two orders each contain a line numbered 1. Can an export safely identify a line using only that number?

Answer: Not if the numbering is local to each order. It must preserve the parent context or another identifier that uniquely identifies the line under the actual schema rules.

Related terms

• Tree (abstract data type)
• Network Data Model
• Relational Data Model
• parent-child relationship
• root record
• segment
• IBM IMS
• tree
• hierarchical path
• logical relationship
• data migration

Learn next

draw a three-level hierarchy and label both segment types and individual occurrences. Flatten a few records into tables while preserving their identities and relationships. Add a cross-branch relationship and explain what extra mechanism is needed rather than silently duplicating a shared entity.

More in Data engineering and architecture

• HBJ model - The HBJ model, named for Helman, Bader and JáJá, is a cost model for analyzing parallel algorithms on message-passing machines.
• Head/tail breaks - Head/tail breaks is a classification method that repeatedly divides data around their arithmetic mean, focusing the next division on the smaller group of...
• Hidden algebra - Hidden algebra is a mathematical approach to specifying and reasoning about stateful systems through their observable behavior rather than their internal...
• High-throughput computing - High-throughput computing (HTC) is an approach to computing that emphasizes completing a large amount of useful work over an extended period.
• Hybrid cloud storage - Hybrid cloud storage combines storage in an organization's local environment with cloud storage as part of a connected operating arrangement.
• Hypercube (communication pattern) - A hypercube communication pattern organizes exchanges between computing processes as if the processes occupied the corners of a multidimensional cube.

Sources

Sources: IBM IMS, Parent and child segment, https://www.ibm.com/docs/en/ims/15.6.0?topic=database-parent-child-segment ; IBM IMS, Comparison of hierarchical and relational databases, https://www.ibm.com/docs/en/ims/15.4.0?topic=ims-comparison-hierarchical-relational-databases ; IBM IMS, Database hierarchy examples, https://www.ibm.com/docs/en/ims/15.5.0?topic=database-hierarchy-examples . Primary product documentation search excerpts consulted. IMS terminology is explicitly identified; the toy hierarchy and migration guidance are original illustrations rather than universal product specifications.

Previous: Hierarchical control system Next: Hierarchical decomposition