ナビゲーショナルデータベース

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索

ナビゲーショナルデータベースNavigational Database)とは、データベースの種類であり、何らかのオブジェクトから参照を辿ることでレコード英語版オブジェクトを検索する。ナビゲーショナルなインタフェースは通常手続き的だが、XPathなどの現代的システムはナビゲーショナルであると同時に宣言的でもある。

ナビゲーショナルなアクセスは古くからデータベースインタフェースのネットワークモデル階層モデルに結びついており、中には集合指向の機能を持つものもある[1]

概要[編集]

ナビゲーショナル技術は「ポインタ(pointer)」と「パス(path)」を使ってデータレコード間で誘導(navigate)を行う。対照的にリレーショナルデータモデルリレーショナルデータベースで実装されている)では「宣言型(declarative)」または論理プログラミング技法を使う。一般にリレーショナルデータベースへの問い合わせは "what" であるのに対して、ナビゲーショナルデータベースへの問い合わせは "how" である。

例えば、ある目的地を与えるナビゲーショナルな手法は、「25号線を8マイル進み、赤い納屋が左に見えたら Horse Road で曲がり、三番目の家で停まる」などといった指示で表される。一方、宣言的手法は「……の座標にある緑色の家」といった形になる。

階層型データモデルもナビゲーショナルの一種と考えられる。階層型データモデルを扱うとき、上位に登ったり(up)、下位に下ったり(down)する「パス」があり、これは階層型ファイルシステムのパスに類似している。一般にナビゲーショナルシステムはパスと前置詞("next"、"previous"、"first"、"last"、"up"、"down"など)の組み合わせを用いる。

データベースのノード群の例。6個の頂点と7個の辺を持つラベル付きグラフで表している。番号は便宜的なもので、通常はもっと意味のある名前をつける。また、名前以外にも様々な属性を持つのが一般的だが、ここでは省略している。

「パス」は一般にノード名またはノードアドレスの連鎖で構成される。以下に右図に対応したパスの例を示す。

 Node6.Node4.Node5.Node1

または

 Node6/Node4/Node5/Node1

指定したパスに対応したリンクが実際には存在しない場合、エラーと判定され "Invalid Path" などのメッセージが表示される。例えば、"Node6.Node2.Node1" というパスは6と2の間に直接のリンクが存在しないので、多くのシステムで不正と判断される。

歴史[編集]

この用語はチャールズ・バックマンが講演で用いたのが最初である。その中で彼は、自身の提唱する種類のデータベースにアクセスするプログラマを「ナビゲータ」と称した[2]

データベースの一種でもある階層型ファイルシステムを除いて、ナビゲーショナル技術は1980年代には凋落することとなった。しかし、オブジェクトデータベースXMLによってナビゲーション技術に再び関心が集まり、議論を発生させた。

現在使われているナビゲーショナルな構造の例として、JavaScriptと密接に関連してWebブラウザで使われているDocument Object Model(DOM)がある。DOMエンジンは軽量なナビゲーショナルデータベースの一種である。World Wide Web 自体やウィキペディアもナビゲーショナルデータベースの一種とみなすことができるが、データを集積しているというよりも人間が読める文書を集積したものという側面が強い。ウェブは全体としてはネットワーク型であり、ドメイン名やURLは階層型である。一方で、セマンティック・ウェブにおける Linked Open Data はコンピュータが処理できるデータのウェブを構築することを目指しており、ナビゲーショナル的考え方が含まれている。

近年、新たな種類のナビゲーショナルデータベースとしてグラフデータベース英語版が登場している。このようなデータベースはNoSQLデータベースの一種とされることが多い。

ナビゲーショナル 対 リレーショナル[編集]

ナビゲーショナル技術に批判的な人々は、これを「構造化されていないスパゲッティのめちゃくちゃ状態」と見なし、構造化プログラミング以前のGoto文のようなものと言う。すなわち、制御構造にとっての Goto文とデータ構造にとってのナビゲーショナル技術を似たような関係と見るのである。この観点では、リレーショナルモデル (関係モデル) に基づくリレーショナル技術 (リレーショナルデータベース) は集合論述語論理に基づいてデータ構造とその使用法に洗練された規則と一貫性をもたらす。

しかし実際には、リレーショナルモデルではデータセットを可能な限り小さくする必要がある。これがリレーショナルモデル固有の問題なのか、将来の実装技術の改善によって解決される問題なのかは現時点では不明である。

一部の人々はリレーショナル理論全体ではなくSQL言語に批判的である。また、現状のリレーショナルデータベース製品が固定カラム幅と事前定義された型に依存しすぎているとの指摘もある。このため、リレーショナルデータベースをちょっとした仕事に素早く利用するのは難しい。

一部の人々は、リレーショナルデータベースに比較してナビゲーショナルデータベースエンジンの方が構築が簡単でメモリ消費も少ないと指摘する。しかし、SQLをサポートしていなかった1980年代終盤のリレーショナルデータベースのエンジンは非常に小さく、この指摘が当てはまらないことを意味している。理由はどうあれ、小さな構造を扱う場合、ナビゲーショナル技術はよく使われている。

興味深いことに、データ構造図の形式として一般に使われているものは全てネットワーク型データモデルに基づくグラフィカル表現である(バックマン線図ER図、Partnership Model、UML)。これは、ナビゲーショナルな構造の方が視覚的に自然であることを示唆している。相対的(relativistic)な多次元データを視覚化することは難しい。しかし、リレーショナルモデルを擁護する人々は、相対主義(relativism)はリレーショナルデータモデルの一部に過ぎないと主張する。

脚注[編集]

関連項目[編集]