Is a navigational database necessarily hierarchical?

No. Hierarchical and network database approaches can both support navigation, with different relationship structures.

Must an application always begin at the first record?

No. Available indexes and access methods may locate a suitable starting record directly.

Can such a database support SQL access?

Some products can expose SQL interfaces. The interface and the underlying data model are distinct questions.

AI Glossary / Data engineering and architecture / Intermediate

Navigational database

Definition

A navigational database is a database accessed by following defined paths between related records. The application typically locates a starting record and then moves through relationships to reach other records. The term is commonly associated with hierarchical and network database approaches, where knowing the available relationships is central to retrieving information.

What it means

Navigation here means moving through data relationships, not finding a geographical route. A program might find a customer, move to that customer's orders and then visit the items within each order. The path is part of the application's access procedure.

This differs from a declarative request that primarily describes the desired result and leaves the database engine to choose an execution strategy. The distinction concerns the access approach, not a claim that navigational systems cannot have query interfaces. Database products can expose multiple ways to use the same underlying data.

How it works

The database defines record types and their relationships. A hierarchical arrangement organizes records through parent-child relationships; a network arrangement can use owner-member sets to express linked records. Applications use the system's access operations to locate records and move along those relationships.

The program must handle its current position, missing records, relationship membership and the end of a sequence. Broadcom's IDMS documentation illustrates why this matters: an application retrieving an owner from an optional or manually populated set must check membership rather than assume the current record belongs to that set.

Indexes and other access methods can provide starting points. Navigation does not necessarily mean reading every record from the beginning. The precise access rules, storage organization and transaction behavior depend on the database product and design.

Three practical examples

1. Order processing: A program locates an order and visits its linked line items to calculate the amount due. It must distinguish an order with no items from a failed retrieval.

2. Equipment records: A maintenance application follows a machine record to its service events and the parts associated with each event. Its extraction procedure preserves which parts belong to which service visit.

3. Data migration: A team exports a legacy database into analytical tables. It traverses relationships while recording identifiers and parent links so that the exported rows retain their original context.

Think of it this way

Think of following signposts through a large archive: start at a known cabinet, follow a reference to a folder and then inspect its enclosed documents. The sequence tells you how to reach the information.

The analogy has limits. Database links are managed structures, and a system may offer indexes or alternative paths that avoid the obvious route. The application also needs precise rules for concurrent updates and retrieval failures that a simple archive walk does not capture.

Worked example

Suppose a fictional database contains customer C4 with orders O10 and O11. O10 has two items worth 30 and 20 currency units; O11 has one item worth 15. A navigational procedure first locates C4, visits O10 and totals its items to 50, then moves to O11 and totals its item to 15. The customer total is 65.

The procedure must reset the order subtotal when moving from O10 to O11. Otherwise, it could wrongly report O11 as 65 rather than 15. It must also stop each item traversal at the correct order boundary.

Now consider a request for every order containing a particular part across all customers. The customer-first path may be inconvenient. An alternative index or relationship could help, depending on the system. This example shows why expected access patterns influence design; it does not prove that navigation is always faster or slower than relational querying.

Illustrative case study

Fictional case study: PathMeadow builds a reporting feed from an established service database. Its first export flattens service visits and replacement parts into separate files but omits the relationship identifiers. Analysts can count parts, yet cannot reliably attach them to the correct visits.

The team revises its traversal to capture each visit identifier, its machine identifier and every part's visit association. It checks a sample against the source application, including machines with no visits and visits with several parts.

PathMeadow learns that successful record retrieval is only part of a migration. The meaning carried by relationships must survive the export. Its reconciliation checks concern completeness and association, not merely whether every file opened successfully.

Common misconceptions and mistakes

A common mistake is treating a navigational database as a database for maps. Another is assuming that every relationship requires a full scan or that all linked records must be physically adjacent on disk.

Do not equate a navigational access pattern with every modern graph database feature. Graph products can provide declarative query languages and different modeling capabilities. Likewise, the presence of an SQL interface does not automatically mean the underlying database has become relational. Examine the data model, available operations and application dependencies separately.

Business use

Understanding navigational databases is useful when maintaining established operational systems or connecting their information to reporting and AI pipelines. Existing access paths can be effective for predictable transactions, while unfamiliar analytical questions may require additional extraction or access planning.

Before changing a system, document the relationships that applications rely on, their termination conditions and their handling of missing or optional links. For an AI dataset, verify that extracted records preserve entity identities and associations. A misplaced relationship can produce misleading training examples even when every individual field looks valid.

Check your understanding

An export includes every service visit and part but removes the links between them. Has it preserved all useful information?

Answer: No. The records remain, but their associations may be lost. A reliable export must preserve the identifiers or mappings needed to reconstruct the intended relationships.

Related terms

Index
Relational database
Referential integrity
Hierarchical database
network database model
database record
access path
data migration

Learn next

Sketch one record traversal, including its starting point, relationship boundaries and missing-link behavior. Then show how the same relationships would be preserved in an analytical export.

Sources

Broadcom, CA IDMS documentation, “Accessing Owner Records”: https://ftpdocs.broadcom.com/cadocs/0/CA%20IDMS%2018%205%20User%20Bookshelf-ENU/Bookshelf_Files/HTML/IDMS_Navigational_DML_ENU/1194558.html

Broadcom, “Hierarchies and Sets”: https://ftpdocs.broadcom.com/cadocs/0/CA%20IDMS%2018%205%20User%20Bookshelf-ENU/Bookshelf_Files/HTML/IDMS_DLI_Transparency_ENU/1224791.html

IBM, IMS comparison of hierarchical and relational databases, indexed documentation: https://www.ibm.com/docs/en/ims/15.6.0?topic=ims-comparison-hierarchical-relational-databases

These product sources illustrate relationship structures and access behavior. The order calculation and PathMeadow case are fictional teaching examples.

Previous: Natural sort order Next: Nearest Centroid Classifier