Navigational access is traditionally associated with the
network model and
hierarchical model of
database, and conventionally describes data manipulation APIs in which records (or objects) are processed one at a time, iteratively. The essential characteristic as described by Bachman, however, is finding records by virtue of their relationship to other records: so an interface can still be navigational if it has set-oriented features. From this viewpoint, the key difference between navigational data manipulation languages and relational languages is the use of explicit named relationships rather than value-based joins: versus find employees, departments where employee.department-code = department.code and department.name="Sales". In practice, however, most navigational APIs have been procedural: the above query would be executed using procedural logic along the lines of the following pseudo-code: get department with name='Sales' get first employee in set department-employees until end-of-set do { get next employee in set department-employees process employee } On this viewpoint, the key difference between navigational APIs and the
relational model (implemented in
relational databases) is that relational APIs use "declarative" or
logic programming techniques that ask the system
what to fetch, while navigational APIs instruct the system in a sequence of steps
how to reach the required records. Most criticisms of navigational APIs fall into one of two categories: • Usability: application code quickly becomes unreadable and difficult to debug • Data independence: application code needs to change whenever the
data structure changes For many years the primary defence of navigational APIs was performance. Database systems that support navigational APIs often use internal storage structures that contain physical links or pointers from one record to another. While such structures may allow very efficient navigation, they have disadvantages because it becomes difficult to reorganize the physical placement of data. It is quite possible to implement navigational APIs without low-level pointer chasing (Bachman's paper envisaged logical relationships being implemented just as in relational systems, using primary keys and foreign keys), so the two ideas should not be conflated. But without the performance benefits of low-level pointers, navigational APIs become harder to justify. Hierarchical models often construct primary keys for records by concatenating the keys that appear at each level in the hierarchy. Such composite identifiers are found in
computer file names (/usr/david/docs/index.txt), in URIs, in the
Dewey decimal system, and for that matter in postal addresses. Such a composite key can be considered as representing a navigational path to a record; but equally, it can be considered as a simple primary key allowing associative access. As relational systems came to prominence in the 1980s, navigational APIs (and in particular, procedural APIs) were criticized and fell out of favour. The 1990s, however, brought a new wave of
object-oriented databases that often provided both declarative and procedural interfaces. One explanation for this is that they were often used to represent graph-structured information (for example spatial data and engineering data) where access is inherently recursive: the mathematics originally underpinning SQL (specifically,
first-order predicate calculus) does not have sufficient power to support recursive queries, even those as simple as a
transitive closure. More recent SQL implementations do support
hierarchical and recursive queries. A current example of a popular navigational API can be found in the
Document Object Model (DOM) often used in web browsers and closely associated with
JavaScript. The DOM is essentially an in-memory hierarchical database with an API that is both procedural and navigational. By contrast, the same data (
XML or
HTML) can be accessed using
XPath, which can be categorized as declarative and navigational: data is accessed by following relationships, but the calling program does not issue a sequence of instructions to be followed in order. Languages such as
SPARQL used to retrieve
Linked Data from the
Semantic Web are also simultaneously declarative and navigational. ==Examples==