Loading article…
ナビゲーションデータベースとは、レコードやオブジェクトが主に他のオブジェクトからの参照をたどって見つかるタイプのデータベースです。この用語は、チャールズ・バックマンが1973年にチューリング賞を受賞した論文「ナビゲーターとしてのプログラマー」のタイトルによって広く知られるようになりました。[ 1 ]この論文では、新しいディスクベースのデータベースシステムでは、プログラマーがレコード間の関係をたどって任意のナビゲーション経路を選択できることが強調されており、これは、データアクセスが厳密に順次的であった以前の磁気テープやパンチカードシステムの制約とは対照的です。
初期の航海データベースの一つに、1960年代にバッハマンがゼネラル・エレクトリック社向けに開発した統合データストア（IDS）がある。IDSは1969年にCODASYLデータベースモデルの基礎となった。
バッハマンはナビゲーションの概念を抽象的に説明したが、ナビゲーションアクセスの考え方は、CODASYLデータ操作言語の手続き型設計と強く結びつくようになった。例えば、1982年に執筆したツィクリツィスとロホフスキー[ 2 ]は、「通貨の概念はナビゲーションの概念の中心である」と述べている。通貨の概念とは、プログラムが処理中のレコードのシーケンス内で現在の位置を（明示的または暗黙的に）維持し、やなどの操作によってGET NEXTこのGET PRIOR現在の位置を基準としてレコードを取得すると同時に、取得したレコードに合わせて現在の位置を変更するという考え方を指している。
こうして、ナビゲーション型データベースプログラミングは本質的に手続き型であると見なされるようになり、さらに、現在の状態を保持する一連のグローバル変数（通貨指標）の暗黙的な維持に依存するものとされた。そのため、このアプローチは、リレーショナルモデルで使用される宣言型プログラミングスタイルとは正反対であると見なされた。SQLなどのリレーショナル言語の宣言的な性質は、プログラマの生産性を向上させ、より高いレベルのデータ独立性（つまり、データベース構造が進化してもプログラムが動作し続ける能力）を提供した。結果として、ナビゲーション型インターフェースは、1980年代を通じて宣言型クエリ言語に徐々に取って代わられていった。
1990年代に入ると、複雑なデータを扱う特定のアプリケーション（例えば、空間データベースやエンジニアリングデータベース）においては、関係式計算には限界があることが明らかになり始めました。当時、データベース市場全体の見直しが始まり、いくつかの企業が「NoSQL」というマーケティング用語を用いて新しいシステムを発表しました。これらのシステムの多くは、通貨インジケータを持つCODASYL DMLとは大きく異なるものの、バッハマンの「ナビゲーション」というビジョンを実装したものと理解できるデータ操作言語を導入しました。これらの言語の中には手続き型言語もあれば、XPathのように完全に宣言型言語もあります。ナビゲーションの概念から派生したグラフデータベースなどは、現代のトランザクション処理ワークロードにおいて新たな用途を見出しました。
ナビゲーションアクセスは従来、データベースのネットワークモデルと階層モデルに関連付けられており、レコード（またはオブジェクト）が反復的に一度に 1 つずつ処理されるデータ操作 API を慣習的に説明しています。しかし、Bachman が説明した本質的な特徴は、他のレコードとの関係によってレコードを見つけることです。したがって、インターフェースがセット指向の機能を持っていれば、ナビゲーションである可能性があります。[ 3 ]この観点から、ナビゲーションデータ操作言語とリレーショナル言語の主な違いは、値ベースの結合ではなく、明示的な名前付き関係を使用することです。 fordepartmentwithname="Sales",findallemployeesinsetdepartment-employeesfind employees, departments where employee.department-code = department.code and department.name="Sales"
しかし実際には、ほとんどのナビゲーションAPIは手続き型であり、上記のクエリは、次の擬似コードのような手続き型ロジックを使用して実行されます。
名前が「Sales」の部署を取得し、部署従業員セットの最初の従業員を取得し、セットの最後まで繰り返す：部署従業員セットの次の従業員を取得し、従業員を処理する。この観点からすると、ナビゲーションAPIとリレーショナルモデル（リレーショナルデータベースで実装されている）の主な違いは、リレーショナルAPIが「宣言的」または論理プログラミング技術を使用してシステムに何を取得するかを尋ねるのに対し、ナビゲーションAPIは必要なレコードに到達する方法を一連の手順でシステムに指示するという点です。
ナビゲーションAPIに対する批判のほとんどは、次の2つのカテゴリーのいずれかに分類されます。
長年にわたり、ナビゲーションAPIの主な利点はパフォーマンスでした。ナビゲーションAPIをサポートするデータベースシステムは、多くの場合、あるレコードから別のレコードへの物理的なリンクまたはポインタを含む内部ストレージ構造を使用します。このような構造は非常に効率的なナビゲーションを可能にする一方で、データの物理的な配置を再編成することが困難になるという欠点があります。低レベルのポインタ追跡なしでナビゲーションAPIを実装することは十分に可能です（バッハマンの論文では、主キーと外部キーを使用してリレーショナルシステムと同様に論理関係を実装することを想定していました）。したがって、この2つの考え方を混同すべきではありません。しかし、低レベルのポインタによるパフォーマンス上の利点がなければ、ナビゲーションAPIの正当性はより困難になります。
階層モデルでは、階層の各レベルに現れるキーを連結することで、レコードの主キーを構築することがよくあります。このような複合識別子は、コンピュータのファイル名/usr/david/docs/index.txt、URI、デューイ十進分類法、そして郵便住所などに見られます。このような複合キーは、レコードへのナビゲーションパスを表すものと考えることもできますが、同時に、連想アクセスを可能にする単純な主キーと考えることもできます。
1980年代にリレーショナルシステムが普及するにつれ、ナビゲーションAPI（特に手続き型API）は批判され、人気が衰えた。しかし、1990年代には、宣言型と手続き型の両方のインターフェースを提供するオブジェクト指向データベースの新たな波が到来した。その理由の一つは、アクセスが本質的に再帰的なグラフ構造の情報（例えば空間データやエンジニアリングデータ）を表現するためによく使われたからである。SQLの基盤となる数学（具体的には一階述語論理）は、推移閉包のような単純なものでさえ再帰クエリをサポートするのに十分な能力を持っていなかった。より最近のSQL実装では、階層型クエリと再帰クエリがサポートされている。
現在よく使われているナビゲーションAPIの例として、 Webブラウザでよく使われ、 JavaScriptと密接に関連しているDocument Object Model （DOM）が挙げられます。DOMは基本的に、手続き型とナビゲーション型の両方のAPIを備えた、メモリ上の階層型データベースです。これに対し、同じデータ（XMLやHTML ）はXPathを使ってアクセスすることもできます。XPathは宣言型かつナビゲーション型に分類できます。つまり、関係性をたどってデータにアクセスしますが、呼び出し元のプログラムは、順番に実行すべき一連の命令を発行しません。セマンティックWebからリンクトデータを取得するために使用されるSPARQLなどの言語も、宣言型とナビゲーション型の両方の性質を併せ持っています。