連合データベースシステム

連合データベース システム( FDBS ) は、メタデータベース管理システム(DBMS)の一種で、複数の自律データベース システムを単一の連合データベースに透過的にマッピングします。構成データベースはコンピュータ ネットワークを介して相互接続され、地理的に分散している場合があります。構成データベース システムは自律性を維持しているため、連合データベース システムは、複数の異なるデータベースをマージするという (ときには困難な) 作業の代替手段となります。連合データベース、または仮想データベースは、連合データベース システム内のすべての構成データベースの複合体です。データ連合の結果として、構成する異なるデータベースで実際のデータ統合が行われることはありません。

データの抽象化により、連合データベース システムは統一されたユーザー インターフェイスを提供できます。これにより、ユーザーとクライアントは、単一のクエリで複数の非連続データベースにデータを格納および取得できます。これは、構成データベースが異種であっても同じです。このために、連合データベース システムは、クエリをサブクエリに分解して、関連する構成DBMSに送信でき、その後、サブクエリの結果セットを合成する必要があります。さまざまなデータベース管理システムで異なるクエリ言語が採用されているため、連合データベース システムはサブクエリにラッパーを適用して、適切なクエリ言語に変換できます。

McLeodとHeimbigner ^[1]は、1980年代半ばに連合データベースシステムを最初に定義した人々の一人です。

FDBS とは、「中央権限を最小限に抑えながら、データベース システム間の部分的な共有と調整をサポートするアーキテクチャとデータベースの相互接続を定義する」ものです。^{[1]この説明は、McLeod/Heimbigner [1]}の連合データベースの定義を正確に反映していない可能性があります。むしろ、この説明は、McLeod/Heimbigner が複合データベースと呼んだものに適合します。McLeod/Heimbigner の連合データベースは、エクスポート スキーマとアクセス操作を公開することで、連合の他のメンバーにデータを利用できるようにする自律コンポーネントのコレクションです。連合のメンバーから利用できる情報を網羅する、統一された中央スキーマはありません。

他の調査では、^{[2]の実践者は連合データベースを、自律的で}異機種混在の可能性のある協力するコンポーネントシステムの集合として定義しています。

FDBSの3つの重要な構成要素は、自律性、異種性、分散性です。^[2]また、考慮されているもう1つの次元は、ネットワーク環境コンピュータネットワーク、たとえば、LAN上の多数のDBS 、またはWAN上の多数のDBS 、参加しているDBSの更新関連機能（たとえば、更新なし、非アトミック遷移、アトミック更新）です。

DBMSは、集中型または分散型に分類できます。集中型システムは単一のデータベースを管理し、分散型は複数のデータベースを管理します。DBMS 内のコンポーネントDBSは、集中型または分散型です。複数 DBS​​ (MDBS) は、コンポーネント DBS の自律性に応じて、連合型と非連合型の 2 種類に分類できます。非連合型データベース システムは、自律性のないコンポーネントDBMSの統合です。連合型データベース システムは、自律性がありながらも連合に参加して、データの部分的かつ制御された共有を可能にする コンポーネントDBSで構成されます。

フェデレーション アーキテクチャは、コンポーネント データベース システムとの統合レベルとフェデレーションによって提供されるサービスの範囲によって異なります。FDBS は、疎結合システムまたは密結合システムとして分類できます。

• 疎結合では、コンポーネント データベースが独自のフェデレーションスキーマを構築する必要があります。ユーザーは通常、マルチデータベース言語を使用して他のコンポーネント データベース システムにアクセスしますが、これにより場所の透過性が失われ、ユーザーはフェデレーション スキーマを直接知る必要があります。ユーザーは、必要なデータを他のコンポーネント データベースからインポートし、それを自分のデータベースと統合してフェデレーション スキーマを形成します。
• 密結合システムは、独立したプロセスを使用して統合された連合スキーマを構築および公開するコンポーネント システムで構成されます。

FDBS が特定のタイプである複数の DBS は、分散、異種性、自律性の 3 つの次元に沿って特徴付けることができます。別の特徴付けは、ネットワークの次元 (たとえば、LAN または WAN 内の単一のデータベースまたは複数のデータベース) に基づくことができます。

FDBS 内のデータの分散は、FDBS が構築される前に複数の DBS が存在するためです。データは、1 台のコンピューターまたは複数のコンピューターに保存できる複数のデータベースに分散できます。これらのコンピューターは、地理的に異なる場所に配置できますが、ネットワークによって相互接続されています。データ分散の利点は、可用性と信頼性の向上、およびアクセス時間の改善に役立ちます。

データベースの異質性は、構造、データのセマンティクス、サポートされている制約、またはクエリ言語の違いなどの要因によって生じます。構造の違いは、特殊化と継承をサポートするオブジェクト指向 (OO) モデルと、それらをサポートしないリレーショナル モデルなど、2 つのデータ モデルが異なるプリミティブを提供する場合に生じます。制約による違いは、2 つのモデルが異なる制約をサポートする場合に生じます。たとえば、CODASYLスキーマのセット タイプは、リレーションシップ スキーマの参照整合性制約として部分的にモデル化される場合があります。CODASYLは、参照整合性だけでは捕捉されない挿入と保持をサポートします。1 つのDBMSでサポートされているクエリ言語が、他のコンポーネントDBMS間の異質性の一因となる場合もあります。たとえば、同じデータ モデルを持つクエリ言語の違いや、クエリ言語の異なるバージョンが異質性の一因となる場合があります。

意味の異質性は、データの意味、解釈、または使用目的について意見の相違がある場合に発生します。スキーマとデータ レベルでは、考えられる異質性の分類には次のものが含まれます。

• 名前の競合 (例:同じ概念を表すのに異なる名前を使用するデータベース)。
• ドメイン競合またはデータ表現競合 (例:同じ概念を表すために異なる値を使用するデータベース) 。
• 精度の競合 (例:同じデータに対して異なる基数のドメインからの同じデータ値を使用するデータベース)。
• メタデータの競合 (例: 同じ概念がスキーマレベルとインスタンス レベルで表されます)。
• データの競合（例：属性の欠落）
• スキーマの競合 (例: テーブル対テーブルの競合、名前の競合、データの競合など)

フェデレーテッド スキーマを作成する場合、コンポーネント DB スキーマを統合する前に、このような異種性を解決する必要があります。

互換性のないデータ型やクエリ構文の処理は、FDBS の具体的な実装に対する唯一の障害ではありません。トップダウンで計画されていないシステムでは、意味的には同等だが名前が異なる部分を異なるスキーマ(= データ モデル) (テーブル、属性) から一致させるという一般的な問題があります。n個の属性間のペアワイズ マッピングはマッピング ルール (同等性マッピングが与えられている場合)になりますが、この数はすぐに実用上大きすぎます。一般的な解決策は、すべてのメンバー スキーマの関連部分を含むグローバル スキーマを提供し、データベース ビューの形式でマッピングを提供することです。マッピングの方向によって、2 つの主なアプローチがあります。 ${\displaystyle n(n-1) \over 2}$

1. グローバル・アズ・ビュー（GaV）：グローバル・スキーマは基礎となるスキーマに基づいて定義される
2. ローカル・アズ・ビュー（LaV）：ローカル・スキーマはグローバル・スキーマに基づいて定義される

どちらも、スキーマ マッチング問題と呼ばれるデータ統合の例です。

MDBS と FDBS の違いの根本にあるのは、自律性の概念です。コンポーネント データベースの自律性の側面を理解し、コンポーネント DBS が FDBS に参加するときにどのように対処できるかを理解することが重要です。対処される自律性には 4 種類あります。

• 設計の自律性とは、データ、クエリ言語、概念化、システム実装の機能に関係なく、設計を選択できる能力を指します。

FDBS の 異質性は、主に設計の自律性に起因します。

• 通信の自律性とは、DBMS が他のDBMSと通信するかどうかという一般的な動作を指します。
• 実行の自律性により、コンポーネント DBMS はローカル操作および外部操作によって要求された操作を制御できます。
• 関連付けの自律性により、コンポーネント DBS はフェデレーションから自身を切り離す権限を持ちます。つまり、FDBS は単一のDBSから独立して動作できます。

ANSI/X3/SPARC 研究グループは、データベースの概念スキーマ、内部スキーマ、外部スキーマの 3 レベルのデータ記述アーキテクチャを概説しました。ただし、この 3 レベルのアーキテクチャは、FDBS のアーキテクチャを記述するには不十分です。そのため、FDBS の 3 つの次元、つまり分散、自律性、異種性をサポートするように拡張されました。5 レベルのスキーマ アーキテクチャについては、以下で説明します。

異種性と自律性の要件は、FDBS における同時実行制御に関する特別な課題を提起します。これは、同時実行トランザクションを正しく実行するために重要です (グローバル同時実行制御も参照)。これらの要件の下で、主要な正確性基準であるグローバル直列化可能性を実現することは、非常に困難で未解決であると考えられてきました。^[2]

5 レベルのスキーマ アーキテクチャには次のものが含まれます。

• ローカルスキーマは基本的に、ネイティブデータモデルで表現されたコンポーネントデータベースの概念モデルです。^[3]
• コンポーネントスキーマは、所有者組織がFDBSの他のユーザーと共有するローカルスキーマのサブセットであり、共通データモデルに変換されます。^[3]
• エクスポートスキーマは、特定のフェデレーションで使用できるコンポーネントスキーマのサブセットを表します。^[3] 特定のフェデレーションユーザーによる使用に関するアクセス制御情報が含まれる場合があります。エクスポートスキーマは、データの制御フローの管理に役立ちます。
• フェデレーテッドスキーマは複数のエクスポートスキーマを統合したものです。これにはエクスポートスキーマを統合する際に生成されるデータ分布に関する情報が含まれます。^[3]
• 外部スキーマはフェデレーションスキーマから抽出され、特定のフェデレーションのユーザー/アプリケーション用に定義されます。^[3]

上記の 5 レベル スキーマ アーキテクチャは、データ統合の最新技術を正確に表していますが、IT によって課せられた外観と操作感という大きな欠点があります。現代のデータ ユーザーは、データの表示方法を制御することを要求しており、そのニーズは、データ統合に対するこのようなボトムアップ アプローチとは多少矛盾しています。

• エンタープライズ情報統合(EII)
• データ仮想化
• マスターデータ管理(MDM)
• スキーママッチング
• 普遍的な関係の仮定
• リンクされたデータ
• スパルク

• DB2 と連合データベース
• 結合（別名「プッシュダウン」）を実行する場所やその他のパフォーマンス特性の問題
• Oracle、Informix、DB2、Excel を統合した実例
• フレイタス、アンドレ、エドワード・カリー、ジョアン・ガブリエル・オリベイラ、ショーン・オリアン。 2012. 「リンクト データ ウェブ上の異種データセットのクエリ: 課題、アプローチ、および傾向」 IEEE インターネット コンピューティング 16 (1): 24–33。
• IBM Gaian データベース: 動的分散フェデレーテッド データベース
• 連合システムおよびそのようなシステムを実装および使用する方法とメカニズム