Navigational database
From Wikipedia, the free encyclopedia
Navigational databases incorporate both the network model and hierarchical model of database interfaces. 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:
Node6.Node4.Node5.Node1
Or
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.
But, in practice relational has yet to successfully scale down to smaller-use data. Whether this is an inherent fault of relational, or could be solved by further research into improving implementation techniques is difficult to say at this point.
Some fault the SQL language rather than relational theory in general. Another possibility is that existing relational products generally depend too heavily on fixed column widths and pre-defined types. These are sometimes seen as excessive for informal or nimble usage. Dynamically-typed and sized versions of relational tools would have to be developed and tested before being accepted by the industry.
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.
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 model 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.
