AI Glossary / Data engineering and architecture / Advanced
Data hierarchy
Definition
Data hierarchy describes how smaller data components are organized into larger structures. A common introductory example moves from characters to fields, fields to records and records to files or tables. The precise levels depend on the system and purpose. The concept explains organization and containment; it does not mean every database must use a hierarchical database model or that logical structure directly determines physical storage size.
What it means
A customer name is one part of a customer record, and many customer records can form a collection. Understanding those levels helps someone distinguish a value, a field definition, a complete record and a dataset. Other contexts use hierarchies for parent-child relationships, such as a product category containing subcategories. These uses are related through organization, but they should not be treated as identical structures. A clear explanation states what each level represents and which relationship connects it to the next.
How it works
Identify the units of information and describe how they are grouped. In a record layout, several elementary fields may belong to a larger group, which belongs to a record. IBM's COBOL documentation provides a concrete example using record, group and elementary items with level numbers. The hierarchy expresses their relationship rather than simply assigning a storage size to each level. A modern application can represent similar logical groupings in different physical forms, so the diagram should explain its intended interpretation rather than imply a universal implementation.
Three practical examples
- A reporting lesson distinguishes a field such as Product Code from a complete product record containing several fields.
- A migration team examines nested address fields within customer records before mapping them to a new structure.
- An AI data-preparation workflow identifies whether a label belongs to one field, one record or an entire collection, avoiding accidental changes in scope.
Think of it this way
Imagine a filing cabinet containing folders, each with forms made up of labeled boxes. The cabinet, folder, form and box provide different organizational levels. Counting boxes is not the same as counting forms, and the meaning of a box depends on its label and surrounding form. Data hierarchy offers a similar way to understand parts and wholes. The analogy does not imply that digital data must be stored in a physical sequence matching the logical grouping.
Worked example
Consider an original product table with four records. Each record has three fields: Product ID, Name and Unit Price. There are three field definitions and twelve field-value positions across the four records. These are different counts. The number twelve does not establish the file's byte size because values can have different encodings and lengths, and the storage format can include additional information. If a fifth record is added with the same structure, the table has fifteen field-value positions but still only three field definitions. The example illustrates logical organization, not a claim that every table has a fixed physical record layout.
Illustrative case study
A fictional catalog team prepares data for a search assistant. One source stores an address as a group of street, city and postal-code fields, while another supplies one combined text value. The team maps the logical components and documents what can and cannot be separated reliably. It also checks that a product-level label is not accidentally applied to every individual field. The scenario illustrates how understanding data levels supports interpretation and conversion. It does not suggest that a nested representation is always better or that a flat table cannot express useful relationships among records.
Common misconceptions and mistakes
A data hierarchy is not necessarily a hierarchical database. A relational table can contain structured records without using a tree-based database model. Another mistake is equating one character with one byte in every encoding. Logical fields also need not have equal lengths, and a count of fields does not determine storage capacity. In parent-child structures, the intended relationship must be explicit: containment, classification and organizational reporting are different meanings. Finally, a convenient hierarchy can hide relationships that do not fit a simple tree, so it should not be forced onto every dataset.
Business use
The concept helps non-specialists ask precise questions about data scope. Clarify whether an issue affects a single value, one field across all records, an individual record or a whole collection. Use that distinction when planning corrections, migrations and AI input preparation. Document nested components where their separate meanings matter, and avoid treating a storage representation as the business concept itself. A useful hierarchy makes relationships easier to understand and inspect; it does not replace field definitions, identifiers or the rules connecting records across systems.
People also ask
Does data hierarchy require a hierarchical database product?
No. It is a broader way of describing organization.
Do three fields in four records mean twelve field definitions?
No. There are three definitions and twelve value positions in the toy table.
Can the hierarchy determine file size by itself?
No. Encoding, values, structure and storage overhead also matter.
Check your understanding
How many field definitions were in the original toy table?
Answer: Three.
How many value positions were present after adding a fifth record?
Answer: Fifteen.
Why did the number of field definitions stay unchanged?
Answer: The new record followed the same three-field structure.
Why was storage size still unknown?
Answer: The example did not specify physical representation or overhead.
Related terms
Learn next
Draw the organization of a small dataset and label each level by what it represents. Count definitions, records and value positions separately. Then describe one relationship that crosses those groupings, such as a product linked to several orders, to see where a simple containment diagram is insufficient.
More in Data engineering and architecture
- Data auditing - Data auditing is a systematic examination of data and, where relevant, the processes that handle it against stated criteria.
- Data binding - Data binding is a mechanism that connects data values to another representation so that values can be displayed, transferred or updated according to defined...
- Data blending - Data blending combines information from separate sources for an analysis or view, using agreed links and compatible levels of detail.
- Data-centric computing - Data-centric computing is an approach to computer-system design that treats the location, movement and access patterns of data as central concerns.
- Data-centric programming language - A data-centric programming language emphasizes describing, querying and transforming collections of data.
- Data-centric security - Data-centric security is an approach that organizes protection around the information itself: what it contains, how sensitive it is, who may use it and...
Sources
IBM, Levels of data in a record description entry: https://www.ibm.com/docs/en/cobol-zos/6.4.0?topic=relationships-levels-data-in-record-description-entry The product-table calculation, filing-cabinet analogy and catalog-team case are original educational illustrations. Indexed IBM documentation supports the record/group/elementary-item example; direct page retrieval was blocked. The entry does not reproduce implementation-specific layout rules or claim one universal hierarchy for all data systems.