
階層型データベースモデルとは、データがツリー状の構造に整理されたデータモデルです。データはレコードとして格納され、レコードは1つ以上のフィールドの集合です。各フィールドには単一の値が格納され、レコード内のフィールドの集合によってその型が定義されます。フィールドの1つの型としてリンクがあり、これは特定のレコードを関連するレコードに接続します。リンクを使用することで、レコードは他のレコードにリンクし、さらに他のレコードにもリンクしてツリーを形成します。例として、「顧客」レコードにはその顧客の「注文」へのリンクがあり、さらに「注文」は「明細項目」にリンクしています。
階層型データベースモデルでは、各子レコードは親レコードを1つだけ持つことが義務付けられていますが、各親レコードは0個以上の子レコードを持つことができます。ネットワークモデルは、複数の親レコードと子レコードを許可することで階層型を拡張しています。これらのデータベースからデータを取得するには、ルートノードから始めてツリー全体をたどる必要があります。どちらのモデルも、通常テープドライブに保存されるデータに適しており、テープドライブではデータを取得するためにテープを端から端まで移動させる必要がありました。
関係データベースモデルが登場した際、階層型データベースモデルに対する批判の一つとして、アプリケーション固有の実装への依存度が高いことが挙げられた。この制約に加え、関係モデルの使いやすさも相まって、既存のネットワーク型や階層型モデルに比べて当初はパフォーマンスが劣っていたにもかかわらず、関係データベースの人気が高まった。[ 1 ]
階層構造は1960年代にIBMによって開発され、初期のメインフレームDBMSで使用されました。レコード間の関係はツリー状のモデルを形成します。この構造はシンプルですが、関係が1対多に限定されるため柔軟性に欠けます。IBM Information Management System(IMS)とRDM Mobileは、同じデータに対して複数の階層を持つ階層型データベースシステムの例です。
階層型データモデルは、コッドのリレーショナルモデルが事実上すべての主流データベース管理システムで使用される標準となったことで、勢いを失いました。階層型モデルのリレーショナルデータベース実装は、1992年に初めて論文として発表されました[ 2 ] (ネストセットモデルも参照)。階層型データ編成スキームは、1990年代後半のXMLの登場とともに再び注目を集めました[ 3 ] ( XMLデータベースも参照)。階層構造は、現在では主に地理情報やファイルシステムの格納に使用されています。
現在でも階層型データベースは、銀行、医療、通信など、非常に高いパフォーマンスと可用性が求められるアプリケーションで広く使用されています。最も広く使用されている商用階層型データベースの1つはIMSです。[ 4 ] 階層型データベースの使用例としては、Microsoft WindowsオペレーティングシステムのWindowsレジストリがあります。[ 5 ]
組織は、従業員番号、名、姓、部署番号などの属性/列を含むテーブルに従業員情報を保存する。組織は必要に応じて各従業員にコンピュータハードウェアを提供するが、コンピュータ機器は割り当てられた従業員のみが使用できる。組織は、各部品のシリアル番号、種類、およびそれを使用する従業員を含む別のテーブルにコンピュータハードウェア情報を保存する。テーブルは次のようになる。
このモデルでは、employeeデータテーブルが階層構造の「親」部分を表し、computerテーブルが階層構造の「子」部分を表します。コンピュータソフトウェアのアルゴリズムで一般的に見られるツリー構造とは異なり、このモデルでは子が親を指し示します。図に示すように、各従業員は複数のコンピュータ機器を所有できますが、個々のコンピュータ機器の所有者は従業員1名のみです。
次の構造を考えてみましょう。
この場合、「子」は「親」と同じ型です。従業員番号10が従業員番号20の上司であり、従業員番号30と40がそれぞれ従業員番号20に報告するという階層構造は、「ReportsTo」列で表されます。リレーショナルデータベースの用語では、ReportsTo列は従業員番号列を参照する外部キーです。「子」のデータ型が異なる場合は、別のテーブルになりますが、それでも従業員テーブルの従業員番号列を参照する外部キーは存在します。
このシンプルなモデルは、一般的に隣接リストモデルとして知られており、関係モデルでは階層的なデータをモデル化できないという初期の批判を受けて、エドガー・F・コッド博士によって提唱されました。しかし、このモデルはグラフにおける一般的な隣接リストの特殊なケースにすぎません。