Loading learning content...
If tree structures provide the architectural skeleton of hierarchical databases, then parent-child relationships provide the connective tissue—the bonds that give the structure meaning and utility. Every edge in a hierarchical database tree represents a parent-child relationship, and understanding these relationships is essential for understanding how hierarchical databases model, store, and retrieve data.
The parent-child relationship in hierarchical databases isn't merely a structural convenience—it's a semantic statement about how data elements relate to each other in the real world. When we say that an EMPLOYEE segment is a child of a DEPARTMENT segment, we're asserting that employees belong to departments, that departments contain employees, and that this belonging is exclusive and permanent within the database structure.
This simple relationship carries profound implications: it determines how data can be accessed, what queries are efficient, how integrity is maintained, and ultimately, what kinds of real-world scenarios hierarchical databases can effectively model.
By the end of this page, you will understand parent-child relationships at a depth that enables you to design hierarchical schemas, predict query performance, identify modeling limitations, and appreciate why these relationships both empowered and constrained the hierarchical data model. You'll understand the one-to-many semantics, existence dependencies, navigation implications, and the fundamental constraints that shape hierarchical database design.
In hierarchical databases, a parent-child relationship is a directed, one-to-many association between two record types (segment types in IMS terminology). The relationship has distinct properties that differentiate it from relationships in other data models.
The hierarchical parent-child relationship is stricter than relationships in the relational model or entity-relationship model. In relational databases, foreign keys can be null, creating optional relationships. In ER models, relationship cardinalities can be many-to-many. The hierarchical model's insistence on mandatory, exclusive, one-to-many relationships is both its strength (strong integrity) and limitation (reduced modeling flexibility).
In hierarchical database design, parent-child relationships are typically expressed using hierarchical structure diagrams. A relationship between parent type P and child type C is denoted:
P
|
+-- C
Or in a more formal notation:
PCR(P, C) — A Parent-Child Relationship where P is the parent type and C is the child type.
Constraints:
Beyond structural mechanics, parent-child relationships carry semantic meaning that maps to real-world concepts. Understanding these semantics enables appropriate modeling decisions.
| Semantic Pattern | Real-World Meaning | Example |
|---|---|---|
| Containment | Parent physically or logically contains children | BUILDING → ROOM |
| Ownership | Parent owns or controls children | CUSTOMER → ORDER |
| Composition | Parent is composed of children (part-whole) | ASSEMBLY → COMPONENT |
| Classification | Parent classifies or categorizes children | DEPARTMENT → EMPLOYEE |
| Temporal Dependency | Children exist only during parent's existence | PROJECT → TASK |
| Aggregation | Parent aggregates or summarizes children | REGION → SALES_DATA |
| Authority/Responsibility | Parent has authority over children | MANAGER → DIRECT_REPORT |
A useful way to understand hierarchical relationships is through the is-part-of perspective: if you can naturally say "a child is part of a parent," the relationship maps well to the hierarchical model.
Good hierarchical fits:
Poor hierarchical fits:
The is-part-of test helps identify when hierarchical modeling is natural versus when it would require awkward workarounds.
Another useful test: Can you identify a single, unambiguous 'owner' for each child instance? If yes, hierarchical modeling works well. If ownership is shared or ambiguous, the hierarchical model will struggle. This ownership perspective was central to how early database designers approached hierarchical schema design.
While all parent-child relationships in hierarchical databases are fundamentally one-to-many, there are important nuances in cardinality and participation that affect schema design.
Parent Participation (Optional vs. Mandatory Children):
In hierarchical databases, parents can exist without children. A DEPARTMENT can exist before any EMPLOYEEs are assigned. This is optional participation on the child side.
However, some designs may require or expect children:
These expectations must be enforced by application logic—the hierarchical structure itself allows empty parent-child relationships.
Child Participation (Always Mandatory):
Children cannot exist without parents in the hierarchical model. This is mandatory participation on the parent side, or total participation in ER terms. Every child has exactly one parent; there are no orphan children.
This mandatory participation is not just a constraint—it's fundamental to the model. The tree structure physically cannot represent a child without a parent because children are stored relative to their parents.
High-cardinality relationships (many children per parent) dramatically affect query performance. To find a specific child, you may need to scan all siblings. With 10,000 children under one parent, even O(n) scans become expensive. This drove the development of secondary indices and twin pointers in systems like IMS.
Parent-child relationships define how data flows and how applications navigate the database. Understanding these patterns is crucial for designing efficient hierarchical schemas and applications.
Downward navigation moves from parent to child, following the natural direction of parent-child relationships. This is the most efficient and natural navigation pattern in hierarchical databases.
Operations:
Efficiency: Downward navigation is highly efficient because:
Use Cases:
Example Traversal:
GET CUSTOMER WHERE ID = 'C001'
GET FIRST ORDER UNDER CUSTOMER
WHILE MORE ORDERS
PROCESS ORDER
GET NEXT ORDER UNDER CUSTOMER
One of the most consequential aspects of parent-child relationships is the existence dependency—the requirement that children cannot exist without their parent. This dependency profoundly affects insertion, deletion, and update operations.
When a parent is deleted, the fundamental question arises: what happens to children? In hierarchical databases, the answer is cascading deletion—the entire subtree rooted at the deleted node is removed.
This is both powerful and dangerous:
Power: One delete operation removes all logically related data. Delete a customer, and all their orders, order lines, and shipments are automatically removed. No orphaned records, no manual cleanup.
Danger: An inadvertent parent deletion can destroy vast amounts of data. Deleting a division might remove thousands of employees, their benefits, their project assignments—all in one operation.
Implementation: Systems typically implement cascading delete through:
The existence dependency means hierarchical databases naturally model 'hard' dependencies—where component existence is tied to container existence. However, real-world data often has 'soft' dependencies (an employee can exist even if their department is disbanded). Modeling soft dependencies in hierarchical databases requires careful schema design, often involving reorganization or moving records before parent deletion.
Not all real-world relationships fit naturally into the one-parent-per-child constraint of hierarchical databases. Understanding techniques for handling complex relationships is essential for practical hierarchical schema design.
Multi-valued dependencies occur when a child entity depends on multiple parent entities. Example: A GRADE depends on both STUDENT and COURSE.
Hierarchical Solution: Choose One Path
Option 1: Student-Centric
STUDENT
└── ENROLLMENT
└── GRADE (includes course reference)
Option 2: Course-Centric
COURSE
└── ENROLLMENT
└── GRADE (includes student reference)
Tradeoffs:
IMS Approach: Logical relationships can create 'virtual' access paths from both directions, but the physical structure still has a primary path.
In hierarchical databases, parent-child relationships are defined at the schema level through database definition languages. Let's examine how IMS, the archetypal hierarchical DBMS, specifies these relationships.
1234567891011121314151617181920212223242526272829303132
DBD NAME=CORPDB,ACCESS=HDAM** Root segment - CompanySEGM NAME=COMPANY,BYTES=100,PARENT=0FIELD NAME=COMPNAME,BYTES=50,START=1,TYPE=CFIELD NAME=COMPCODE,BYTES=10,START=51,TYPE=C** Child of Company - DivisionSEGM NAME=DIVISION,BYTES=80,PARENT=COMPANYFIELD NAME=DIVNAME,BYTES=40,START=1,TYPE=CFIELD NAME=DIVCODE,BYTES=10,START=41,TYPE=C** Child of Division - Department SEGM NAME=DEPARTMT,BYTES=120,PARENT=DIVISIONFIELD NAME=DEPTNAME,BYTES=30,START=1,TYPE=CFIELD NAME=DEPTCODE,BYTES=10,START=31,TYPE=CFIELD NAME=BUDGET,BYTES=8,START=41,TYPE=P** Child of Department - EmployeeSEGM NAME=EMPLOYEE,BYTES=200,PARENT=DEPARTMTFIELD NAME=EMPNAME,BYTES=50,START=1,TYPE=CFIELD NAME=EMPNO,BYTES=10,START=51,TYPE=C,SEQFIELD NAME=SALARY,BYTES=8,START=61,TYPE=P** Child of Employee - SkillSEGM NAME=SKILL,BYTES=40,PARENT=EMPLOYEEFIELD NAME=SKILLNAM,BYTES=30,START=1,TYPE=CFIELD NAME=LEVEL,BYTES=1,START=31,TYPE=C*DBDGENFINISHENDSEGM (Segment Definition):
NAME= specifies the segment type namePARENT= explicitly declares the parent segment type (PARENT=0 for root)BYTES= specifies segment sizeFIELD (Field Definition):
SEQ indicates the sequencing field for sibling orderingRelationship Semantics Encoded:
What the Schema Tells Us:
This 5-level hierarchy represents a complete organizational database with proper parent-child relationships at each level.
Notice what's NOT in the schema: no foreign keys, no join definitions, no referential integrity constraints specified separately. In hierarchical databases, the parent-child structure itself IS the integrity mechanism. The schema defines structure, and structure enforces integrity—a fundamental difference from relational database design where structure and constraints are separate concerns.
Parent-child relationships are the defining characteristic of hierarchical databases, providing both their greatest strengths and their fundamental limitations.
With tree structures and parent-child relationships mastered, we're prepared to examine the most influential implementation of the hierarchical model: IBM's Information Management System (IMS). The next page explores IMS as a case study—how theory became practice, how design decisions shaped an industry, and why IMS's architecture continues to influence database thinking today.
You now understand parent-child relationships at the depth required for hierarchical database design and analysis. This relationship type—simple in concept, profound in implication—shaped database design for decades and remains relevant for understanding document databases, XML structures, and nested data representations in modern systems.