Hierarchical Database

Hierarchical database technology:: "IBM introduced the first generation of database technology, known as hierarchical, when it installed IMS (Information Management System - See IbmIms on Wiki) in its mainframe computers in the mid-1960s. This technology was upgraded in the mid-1970s to network database technology. Both hierarchical and network databases are often described by the term hierarchical database.
: "As the term implies, in a hierarchical database records are grouped in a logical hierarchy, connected in a branching structure similar to an organizational chart. An application retrieves data by first finding the primary record and then following pointers stored in that record to other connected records."

...

"Although still in use by a few thousand mainframe computer installations, hierarchical database systems gave way to relational database (RDB) technology for two major reasons:

"Hierarchical database systems are difficult to use. They require application developers to program navigation through the connected records [...]
"They also require developers to predict all possible access patterns in advance and design the database accordingly. A database access pattern that is not included in the design becomes very difficult and inefficient."

See IbmIms for more on the IMS product.

Would this be like an XmlDatabaseServers?

Yes, XML is a hierarchical representation, and navigation is normally hierarchical.

XML is likely to suffer from both limitations listed above - complexity of navigation and difficulty in redesign, should you rethink the hierarchical relationships. The redesign issue could be most significant, particularly in the current generation of XmlDatabaseServers.

XmlDatabases are graphs of data with semistructured information in each node. The graphs are typically in the form of a directed acyclic graph, but not necessarily. The "not necessarily" naturally leads to problems as does the semi-structured nature. Structure = static information = fast.

How about "a file system" ! Or the WindowsRegistry?.

TopMinds rant against hierarchical file systems and other trees: http://www.geocities.com/tablizer/sets1.htm

An HDB is any database built out of parent-child or container-contained relationships, rather than peer-peer relationships as in a RelationalDatabase. Hierarchical dbs predate RDBMS. By allowing multiple parents you get a NetworkDatabase (think: file system links).

Most commercial relational schemas have to represent hierarchies, since a lot of business problems involve tree-like structures. The RDBMS vendors often provide non-standard extensions to their SQLs to handle this. These aren't much used, so most schemas end up having a lot of odd-looking recursive relations in them, plus stored procedures/strangulated queries for navigating those relations as a tree.

Examples? I don't encounter the need for trees very often while using RDBMS. About the only place I encounter them is some kind of menu structure. Taxonomies of products or services are sometimes represented as trees, but I find sets more appropriate for large taxonomies because some items need to be in multiple categories.

A classic example is the hierarchy of managers of employees. However, it is not uncommon for a person to have multiple bosses in larger companies.

The problem of multiple categories is inherent to taxonomies and to representation of properties as classes, and indeed sets are more natural (and also a stronger point of relational databases than are trees).

Of course, sets can be used to represent trees even when the problem domain is inherently hierarchical. This can be inefficient, and various alternative tradeoffs are discussed in various RDBMS resources such as JoeCelko's "SqlForSmarties". -- Doug Merritt

Oracle has some built-in hierarchy handling operations in their brand of SQL, as long as you follow their tree setup conventions.

An HierarchicalDatabase is an implementation of storage that can be described using the CompositePattern. Composites are ubiquitous in software engineering. Composites are common, easy to model, offer easy control of ownership. When a hierarchy works, no reason to get any fancier. But InterestingProblems usually require a data model that need more than a tree.

{It's worthwhile to note that composite is just one view of data in software engineering. It has good properties for ownership (and security), and can be quite efficient when utilized in the intended manner, but it has poor properties for several other tasks. Unfortunately, support for multiple different views is made difficult in a HierarchicalDatabase. You're pretty much stuck with the particular hierarchy forced upon you by whatever view the original implementor took of the data. OptimizationHindersEvolution. This isn't an issue if nobody else plans to view the data, of course... but, in the experience of many here, data usually long outlives the applications.}

If you look at say bicycle or car parts, the relationship is not really hierarchical, although it can be forced into a hierarchy to create a UsefulLie. But a bigger problem is that not all "access paths" are going to be hierarchical. For example, if we search for all electrical switches, we are not interested in any physical composition since they may be spread all over, but rather the "kind" of part. The larger the system we are modeling, the more alternative access paths there will be. Something large enough will be analyzed by accountants, quality control experts, etc. in ways that may not relate to physical proximity. This has always been a drawback of larger hierarchical or compositional databases.

{Indeed.}

Seems that XML databases are again getting popular with REST, Web 2.0, etcetera. Now their time has come? Or still a bad idea (in general) to move away from RDBMS?

ADG

CategoryDatabase, CategoryHierarchy