Navigational database

From Wikipedia, the free encyclopedia

This article needs additional citations for verification.
Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (July 2007)

Navigational databases are characterized by the fact that objects in the database are found primarily by following references from other objects. Traditionally navigational interfaces are procedural, though one could characterize some modern systems like XPath as being simultaneously navigational and declarative.

Navigational access is traditionally associated with the network model and hierarchical model of database interfaces and have evolved into Set-oriented systems ^[1]. Navigational techniques use "pointers" and "paths" to navigate among data records (also known as "nodes"). This is in contrast to the relational model (implemented in relational databases), which strives to use "declarative" or logic programming techniques in which you ask the system for what you want instead of how to navigate to it.

For example, to give directions to a house, the navigational approach would resemble something like, "Get on highway 25 for 8 miles, turn onto Horse Road, left at the red barn, then stop at the 3rd house down the road". Whereas, the declarative approach would resemble, "Visit the green house(s) within the following coordinates...."

Hierarchical models are also considered navigational because one "goes" up (to parent), down (to leaves), and there are "paths", such as the familiar file/folder paths in hierarchical file systems. In general, navigational systems will use combinations of paths and prepositions such as "next", "previous", "first", "last", "up", "down", etc.

"Paths" are often formed by concatenation of node names or node addresses. Example:

Sample database nodes: A labeled graph on 6 vertices and 7 edges. (Numbers are used for illustration purposes only. In practice more meaningful names are often used. Other potential attributes are not shown.)

 Node6.Node4.Node5.Node1

 Node6/Node4/Node5/Node1

If there is no link between given nodes, then an error condition is usually triggered with a message such as "Invalid Path". The path "Node6.Node2.Node1" would be invalid in most systems because there is no direct link between Node 6 and Node 2.

The usage of the term "navigational" allegedly is derived from a statement by Charles Bachman in which he describes the "programmer as navigator" while accessing his favored type of database. [1]

Except for hierarchical file systems (which some consider a form of database), navigational techniques fell out of favor by the 1980s. However, object oriented programming and XML have kindled a renewed, but controversial interest in navigational techniques.

Critics of navigational techniques view them as "unstructured spaghetti messes", and liken them to the "Go to" of pre-structured programming. In other words, they are allegedly to data organization what go-to's were to behavior flow. In this view, relational techniques provide improved discipline and consistency to data organization and usage because of its roots in set theory and predicate calculus.

Some also suggest that navigational database engines are easier to build and take up less memory (RAM) than relational equivalents. However, the existence of relational or relational-based products of the late 1980's that possessed small engines (by today's standards) because they didn't use SQL suggest this is not necessarily the case. Whatever the reason, navigational techniques are still the preferred way to handle smaller-scale structures.

A current example of navigational structuring can be found in the Document Object Model (DOM) often used in web browsers and closely associated with JavaScript. The DOM "engine" is essentially a light-weight navigational database. The World Wide Web itself and Wikipedia could even be considered forms of navigational databases. (On a large scale, the Web is a network model and on smaller or local scales, such as domain and URL partitioning, it uses hierarchies.)

It is interesting that all of the forms of data structure diagrams, whether the original Charles Bachman form, the Peter Chen ERD form, the newer Partnership Model form, or the Unified Modeling Language, are graphic representations of a network model of the subject.

This suggests that the visual nature of navigational structures is another reason for their continued use. The relativistic, multi-dimensional nature of relational data can make it difficult to visually represent. However, defenders of relational will argue that the relativism is part of its power.