Loading article…
データベースモデルとは、データベースの論理構造を決定するデータモデルの一種です。これは、データの格納、整理、操作方法を根本的に決定します。最も一般的なデータベースモデルは、テーブルベースの形式を使用するリレーショナルモデルです。
データベースの一般的な論理データモデルには、以下のようなものがあります。
オブジェクトリレーショナルデータベースは、これら2つの関連する構造を組み合わせたものである。
物理データモデルには以下が含まれます。
その他のモデルには以下が含まれます。
特定のデータベース管理システムは、1つまたは複数のデータモデルを提供する場合があります。最適な構造は、アプリケーションのデータの自然な構成と、トランザクションレート（速度）、信頼性、保守性、拡張性、コストなどのアプリケーションの要件によって異なります。ほとんどのデータベース管理システムは特定のデータモデルに基づいて構築されていますが、複数のモデルをサポートする製品も存在します。
様々な物理データモデルを用いて、任意の論理モデルを実装することができる。ほとんどのデータベースソフトウェアは、ユーザーが物理実装を調整するための一定の制御機能を提供している。なぜなら、物理実装の選択はパフォーマンスに大きな影響を与えるからである。
モデルは単にデータを構造化する方法ではなく、データに対して実行できる一連の操作も定義します。[ 1 ]例えば、リレーショナルモデルは、選択、射影、結合などの操作を定義します。これらの操作は特定のクエリ言語では明示的に定義されていないかもしれませんが、クエリ言語が構築される基盤となります。
フラット（またはテーブル）モデルは、単一の2次元データ要素配列で構成され、特定の列のすべての要素は同じ値であると想定され、行のすべての要素は互いに関連していると想定されます。たとえば、システムセキュリティデータベースの一部として使用される名前とパスワードの列がこれに該当します。各行には、個々のユーザーに関連付けられた特定のパスワードが含まれます。テーブルの列には、多くの場合、文字データ、日付または時刻情報、整数、または浮動小数点数として定義される型が関連付けられています。この表形式は、リレーショナルモデルの前身です。
これらのモデルは1960年代、1970年代に人気がありましたが、現在では主に古いレガシーシステムで見られます。主な特徴は、論理表現と物理表現の間に強い関連性を持つナビゲーション型であることと、データ独立性に欠けることです。
階層型モデルでは、データはツリー状の構造に整理され、各レコードに単一の親レコードが存在します。ソートフィールドは、兄弟レコードを特定の順序で保持します。階層構造は、IBMのInformation Management System (IMS)などの初期のメインフレームデータベース管理システムで広く使用され、現在ではXMLドキュメントの構造を記述しています。この構造により、2 種類のデータ間の 1 対多の関係が可能になります。この構造は、レシピ、目次、段落/詩の順序、ネストされたソート済みの情報など、現実世界の多くの関係を記述するのに非常に効率的です。
この階層構造は、ストレージ内のレコードの物理的な順序として使用されます。レコードへのアクセスは、ポインタとシーケンシャルアクセスを組み合わせてデータ構造を下方向にたどることで行われます。そのため、各レコードに完全なパス（上方向リンクとソートフィールドではなく）が含まれていない場合、この階層構造は特定のデータベース操作において非効率的になります。このような制限は、後のIMSバージョンで、基本となる物理階層に論理階層を追加することで補われています。
ネットワークモデルは階層構造を拡張したもので、複数の親を持つツリー状の構造で多対多の関係を可能にします。リレーショナルモデルに取って代わられる以前は最も普及しており、CODASYL仕様で定義されています。
ネットワークモデルは、レコードとセットという2つの基本的な概念を用いてデータを整理します。レコードにはフィールドが含まれます（フィールドは、プログラミング言語COBOLのように階層的に構成できます）。セット（数学的な集合とは異なります）は、レコード間の1対多の関係を定義します。つまり、1つの所有者に対して複数のメンバーが存在します。1つのレコードは、任意の数のセットの所有者にも、任意の数のセットのメンバーにもなり得ます。
セットは、循環連結リストで構成され、各循環リストには、セットの所有者または親となるレコードタイプが1つずつ1回ずつ出現し、従属または子となるレコードタイプが複数回出現する場合があります。このようにして、任意の2つのレコードタイプ間に階層構造を確立できます。例えば、タイプAがタイプBの所有者である場合などです。同時に、BがAの所有者となる別のセットを定義することもできます。したがって、すべてのセットは、一般的な有向グラフ（所有権によって方向が定義される）またはネットワーク構造を構成します。レコードへのアクセスは、順次アクセス（通常は各レコードタイプ内）または循環連結リスト内のナビゲーションによって行われます。
ネットワークモデルは、階層モデルよりも効率的にデータの冗長性を表現でき、祖先ノードから子孫ノードへのパスは複数存在し得る。ネットワークモデルの操作はナビゲーション方式であり、プログラムは現在の位置を保持し、レコードが属する関係をたどることで、あるレコードから別のレコードへと移動する。レコードは、キー値を指定することによっても検索できる。
ネットワークデータベースは、モデルの必須機能ではないものの、一般的に、ディスク上のレコードの位置を直接指し示すポインタを用いて、集合間の関係を実装する。これにより、データベースのロードや再編成といった処理速度は低下するものの、優れたデータ検索性能が得られる。
これを利用した人気のDBMS製品としては、Cincom SystemsのTotalとCullinetのIDMSが挙げられる。IDMSはかなりの顧客基盤を獲得し、1980年代には、独自のツールと言語に加えて、リレーショナルモデルとSQLを採用した。
1990年代に開発されたほとんどのオブジェクトデータベースは、ナビゲーションの概念を用いてオブジェクトネットワークを高速にナビゲートし、一般的にオブジェクト識別子を関連オブジェクトへの「スマート」ポインタとして使用します。例えば、 Objectivity/DBは、データベースをまたいで使用できる、名前付きの1対1、1対多、多対1、多対多のリレーションシップを実装しています。多くのオブジェクトデータベースはSQLもサポートしており、両方のモデルの長所を兼ね備えています。
転置ファイルまたは転置インデックスでは、データのコンテンツがルックアップテーブルのキーとして使用され、テーブル内の値は、特定のコンテンツ項目の各インスタンスの場所へのポインタとなります。これは、ルックアップテーブルの特定の列のコンテンツのみを使用する現代のデータベースインデックスの論理構造でもあります。転置ファイルデータモデルでは、既存のフラットデータベースファイルの隣に一連のファイルにインデックスを配置することで、これらのファイル内の必要なレコードに効率的に直接アクセスできます。
このデータモデルを採用した代表的な例として、 1970年に発表されたSoftware AG社のADABAS DBMSが挙げられる。ADABASは多くの顧客を獲得し、現在もなお存続・サポートされている。1980年代には、従来のツールや言語に加え、リレーショナルモデルとSQLを採用した。
文書指向データベースであるClusterpointは、転置インデックスモデルを使用して、XMLやJSONデータオブジェクトなどの高速な全文検索を提供します。
関係モデルは、データベース管理システムを特定のアプリケーションからより独立させる方法として、1970年にEF Coddによって導入されました[ 2 ] 。これは述語論理と集合論の観点から定義された数学モデルであり、その実装はメインフレーム、ミッドレンジ、マイクロコンピュータシステムで使用されています。
一般的にリレーショナルデータベースと呼ばれる製品は、実際にはコッドが定義した数学的モデルの近似モデルを実装しているに過ぎません。リレーショナルデータベースモデルでは、リレーション、属性、ドメインという3つの重要な用語が広く用いられます。リレーションとは、列と行を持つテーブルのことです。リレーションの列名は属性と呼ばれ、ドメインとは属性が取り得る値の集合のことです。
リレーショナルモデルの基本的なデータ構造はテーブルであり、特定のエンティティ（例えば従業員）に関する情報は、行（タプルとも呼ばれる）と列で表されます。したがって、「リレーショナルデータベース」における「リレーション」とは、データベース内の様々なテーブルを指し、リレーションはタプルの集合です。列はエンティティの様々な属性（例えば、従業員の名前、住所、電話番号など）を列挙し、行はリレーションによって表されるエンティティ（特定の従業員）の実際のインスタンスです。結果として、従業員テーブルの各タプルは、1人の従業員の様々な属性を表します。
リレーショナルデータベースにおけるすべてのリレーション（したがってテーブル）は、リレーションとして認められるためにいくつかの基本ルールに従う必要があります。まず、テーブル内の列の順序は重要ではありません。次に、テーブル内に同一のタプルまたは行が存在してはなりません。そして最後に、各タプルは、その属性ごとに単一の値を持つ必要があります。
リレーショナルデータベースは、それぞれが「フラット」データベースモデルのテーブルに似た複数のテーブルで構成されています。リレーショナルモデルの強みの一つは、原則として、2つの異なるレコード（同じテーブルに属するレコードでも、異なるテーブルに属するレコードでも）に現れる値は、それらのレコード間の関係を意味するという点です。しかし、明示的な整合性制約を強制するために、テーブル内のレコード間の関係は、カーディナリティ（1:1、(0)1:M、M:M）を割り当てることで特徴付けられる親子関係を識別するか、識別しないことによって、明示的に定義することもできます。また、テーブルには、テーブル内の各タプルを一意に識別するために使用できる「キー」として機能する、指定された単一の属性または属性のセットを持たせることもできます。
テーブル内の行を一意に識別するために使用できるキーは、主キーと呼ばれます。キーは、2つ以上のテーブルのデータを結合または組み合わせるためによく使用されます。たとえば、EmployeeテーブルにはLocationという名前の列があり、その列にはLocationテーブルのキーと一致する値が含まれている場合があります。キーは、大規模なテーブルからデータを高速に取得するためのインデックスの作成にも不可欠です。どの列もキーとして使用でき、複数の列をまとめて複合キーにすることもできます。すべてのキーを事前に定義する必要はありません。元々キーとして意図されていなかった列でも、キーとして使用できます。
外部的な、現実世界で意味を持つキー（人名、書籍のISBN、自動車のシリアル番号など）は、「自然キー」と呼ばれることがあります。適切な自然キーがない場合（例えば、ブラウンという名前の人がたくさんいる場合）、任意のキーまたは代替キーを割り当てることができます（従業員にID番号を付与するなど）。実際には、ほとんどのデータベースには生成キーと自然キーの両方があります。これは、生成キーは内部的に行間のリンクを作成するために使用でき、そのリンクは切断できないためです。一方、自然キーは、信頼性は低いものの、検索や他のデータベースとの統合に使用できます。（例えば、独立して開発された2つのデータベースのレコードは、社会保障番号が間違っている、欠落している、または変更されていない限り、社会保障番号で照合できます。）
関係モデルで最も一般的に使用されるクエリ言語は、構造化クエリ言語（SQL）です。
ディメンションモデルは、データウェアハウス内のデータをオンライン分析処理（OLAP）クエリを使用して簡単に集計できるように表現するために使用される、リレーショナルモデルの特殊な応用です。ディメンションモデルでは、データベーススキーマは、ディメンションとメジャーを使用して記述される事実の単一の大きなテーブルで構成されます。ディメンションは、事実のコンテキスト（誰が参加したか、いつどこで発生したか、種類など）を提供し、クエリで関連する事実をグループ化するために使用されます。ディメンションは離散的である傾向があり、多くの場合階層的です。たとえば、場所には建物、州、国が含まれる場合があります。メジャーは、収益など、事実を記述する量です。メジャーは意味のある集計が可能であることが重要です。たとえば、異なる場所からの収益を合計することができます。
OLAPクエリでは、ディメンションが選択され、ファクトがグループ化および集計されてサマリーが作成されます。
ディメンションモデルは、多くの場合、リレーショナルモデルの上にスタースキーマを使用して実装されます。スタースキーマは、事実を含む高度に正規化された1つのテーブルと、各ディメンションを含む非正規化されたテーブルで構成されます。スノーフレークスキーマと呼ばれる別の物理的実装では、ディメンション内の多階層構造を複数のテーブルに正規化します。
データウェアハウスには、ディメンションテーブルを共有する複数のディメンションスキーマを含めることができ、それらを連携させて使用できます。標準的なディメンションセットを作成することは、ディメンションモデリングの重要な部分です。
その高い性能により、ディメンションモデルはOLAPにおいて最も人気のあるデータベース構造となっている。
リレーショナルモデルよりも汎用的なデータモデルを提供する製品は、ポストリレーショナルに分類されることがある。[ 3 ]代替用語には、「ハイブリッドデータベース」、「オブジェクト拡張RDBMS」などがある。このような製品のデータモデルはリレーションを組み込んでいるが、 EF Coddの情報原則によって制約されていない。情報原則では、
データベース内のすべての情報は、リレーション内の値として明示的に表現されなければならず、他の方法で表現されてはならない。
こうした関係モデルの拡張機能の中には、関係モデル以前の技術の概念を取り入れているものもある。例えば、ノードにツリー構造を持つ有向グラフの表現を可能にするものなどがある。ドイツの企業sonesは、自社のGraphDBでこの概念を実装している。
リレーショナルシステムから派生した製品の中には、リレーショナルシステムに非リレーショナルな機能を追加することで拡張したものもあれば、リレーショナルシステムから派生した製品にリレーショナルな機能を追加することで同様の境地に達したものもある。逆説的ではあるが、これにより、PICKやMUMPSなど、歴史的にリレーショナルシステムから派生した製品が、リレーショナルシステムから派生した製品であると説得力のある主張をすることが可能になる。
リソース空間モデル（RSM）は、多次元分類に基づく非関係データモデルである。[ 5 ]
グラフデータベースは、ネットワークデータベースよりもさらに汎用的な構造を可能にする。どのノードも他のどのノードにも接続できる。
マルチバリューデータベースは、リレーショナルデータベースと全く同じ方法でデータを格納できるという点で「塊状」のデータと言えますが、リレーショナルモデルではサブテーブルを使って近似的にしか表現できないレベルの深さも許容します。これは、XMLがデータを表現する方法とほぼ同じで、特定のフィールド／属性には同時に複数の正解が存在する可能性があります。マルチバリューは、XMLの圧縮形式と考えることができます。
例として請求書を挙げると、マルチバリューデータまたはリレーショナルデータでは、(A) 請求書ヘッダーテーブル - 請求書ごとに 1 つのエントリ、(B) 請求書明細テーブル - 明細項目ごとに 1 つのエントリとして見ることができます。マルチバリューモデルでは、詳細を表す埋め込みテーブルを持つ 1 つのテーブルとしてデータを格納するオプションがあります。(A) 請求書テーブル - 請求書ごとに 1 つのエントリ、他のテーブルは不要。
利点は、請求書（概念）と請求書（データ表現）の原子性が1対1であることです。これにより、読み取り回数が減り、参照整合性の問題も少なくなり、特定のトランザクション量をサポートするために必要なハードウェアが大幅に削減されます。
1990年代、オブジェクト指向プログラミングのパラダイムがデータベース技術に適用され、オブジェクトデータベースと呼ばれる新しいデータベースモデルが誕生しました。これは、オブジェクトとリレーショナル間のインピーダンスミスマッチ、つまりデータベース内での情報表現（例えばテーブルの行）とアプリケーションプログラム内での情報表現（通常はオブジェクト）間の変換に伴うオーバーヘッドを回避することを目的としています。さらに、特定のアプリケーションで使用される型システムをデータベース内で直接定義できるため、データベースは同じデータ整合性不変条件を強制できます。オブジェクトデータベースはまた、カプセル化やポリモーフィズムといったオブジェクトプログラミングの重要な概念をデータベースの世界に導入しました。
データベースにオブジェクトを格納するために、さまざまな方法が試みられてきました。一部の製品は、アプリケーションプログラミング側からこの問題に取り組み、プログラムによって操作されるオブジェクトを永続化しています。これは通常、何らかのクエリ言語を追加する必要があります。なぜなら、従来のプログラミング言語では、オブジェクトの情報に基づいてオブジェクトを検索する機能がないためです。また、データベース側からこの問題に取り組み、データベースのオブジェクト指向データモデルを定義し、従来のクエリ機能だけでなく、完全なプログラミング機能も備えたデータベースプログラミング言語を定義しています。
オブジェクトデータベースは標準化の欠如によって苦境に立たされました。ODMGによって標準が定義されたものの、製品間の相互運用性を確保できるほど十分に実装されることはありませんでした。それでも、オブジェクトデータベースは多くのアプリケーションで成功裏に利用されてきました。ただし、主流の商用データ処理ではなく、エンジニアリングデータベースや分子生物学データベースといった特殊なアプリケーションがほとんどです。しかし、オブジェクトデータベースの考え方はリレーショナルデータベースのベンダーにも取り入れられ、これらの製品、ひいてはSQL言語の拡張に影響を与えました。
オブジェクトとリレーショナルデータベース間の変換の代替手段として、オブジェクトリレーショナルマッピング（ORM）ライブラリを使用する方法がある。