オブジェクトとリレーショナルのインピーダンス不一致

オブジェクトとリレーショナル間のインピーダンス不一致は、リレーショナル データ ストアのデータとドメイン駆動型オブジェクト モデルのデータの間で生じる一連の困難さです。リレーショナル データベース管理システム(RDBMS) は、専用データベースにデータを格納する標準的な方法ですが、オブジェクト指向(OO) プログラミングは、プログラミング言語におけるビジネス中心の設計のデフォルトの方法です。問題は、リレーショナル データベースや OO プログラミングにではなく、2 つのロジック モデル間のマッピングの概念的な困難さにあります。両方の論理モデルは、データベース サーバー、プログラミング言語、設計パターン、またはその他のテクノロジを使用して、それぞれ異なる方法で実装できます。問題は、格納されたリレーショナル データがドメイン駆動型オブジェクト モデルで使用される場合 (またはその逆)、アプリケーションからエンタープライズ スケールまで多岐にわたります。オブジェクト指向データ ストアでは、この問題を他の実装の困難さと交換できます。

インピーダンス不整合という用語は、電気工学におけるインピーダンス整合に由来します。

数学的には、オブジェクト指向は、オブジェクトが相互に参照する有向グラフです。リレーショナルは、リレーショナル代数を使用したテーブル内のタプルです。タプルは、型指定されたフィールドを持つ「行」にグループ化されたデータ フィールドです。リンクは可逆的 (INNER JOIN は外部キーを逆方向にたどる対称的) であり、無向グラフを形成します。

オブジェクトの カプセル化により、内部が隠されます。オブジェクトのプロパティは、実装されたインターフェースを通じてのみ表示されます。ただし、多くのORM は、データベース列を操作するためにプロパティを公開します。メタプログラミング ORM は、カプセル化の違反を回避します。

「プライベート」と「パブリック」は、リレーショナルではニーズに基づいています。OO では完全にクラスに基づいています。分類と特性の相対性と絶対性は衝突します。

オブジェクトは、内部を公開するためにインターフェースを実装する必要があります。リレーショナルでは、ビューを使用して視点と制約を変更します。クラス、継承、ポリモーフィズムなどの OO の概念が欠けています。

ORM が適切に機能するためには、外部キー/主キー関係を介してリンクされたテーブルを、オブジェクト指向分析の関連付けにマッピングする必要があります。

リレーショナルでは参照渡し (ポインタなど) が禁止されていますが、OO では参照渡しが認められています。スカラー型はリレーショナルとオブジェクト指向で異なるため、マッピングが妨げられます。

SQL は、最大長の文字列(最大長がない場合よりも高速) と照合をサポートします。OO には、ソート ルーチンを使用した照合と、メモリによってのみ制限される文字列があります。SQL は通常、比較文字中に末尾の空白を無視しますが、OO ライブラリは無視しません。OO は、プリミティブの制約を使用して newtype を行いません。

オブジェクトは他のオブジェクトを構成したり、特化したりできます。リレーショナルはネストされておらず、リレーション (同じヘッダーを持つ タプル) は OO には適合しません。

リレーショナルでは、スカラー型、属性、リレーション変数、および/またはグローバルに宣言的な制約を使用します。OO では、オブジェクトの内部を保護する例外を使用します。

リレーショナルではデータ操作に標準化された演算子を使用しますが、OO ではクラスごと、ケースごとに命令型を使用します。OO 宣言型サポートはリストとハッシュ テーブル用であり、リレーショナルのセットとは異なります。^[要出典]

リレーショナルの単位はトランザクションであり、これは OO クラス メソッドよりも大きくなります。トランザクションには任意のデータ操作の組み合わせが含まれますが、OO ではプリミティブ フィールドへの個別の割り当てのみが可能です。OO には独立性と永続性がないため、原子性と一貫性はプリミティブのみで実現されます。

解決策は、論理システム間の違いを認識することから始まります。これにより、不一致を最小限に抑えるか、補うことができます。^[1]

1. NoSQL。不一致は OO と DBMS の間にはありません。オブジェクト リレーショナル インピーダンス ミスマッチは、本質的に OO と R DBMS の間にのみ存在します。NoSQLやXML データベースなどの代替手段はこれを回避します。
2. 関数型リレーショナルマッピング。 関数型プログラミングは、オブジェクト指向プログラミングの一般的な代替手段です。 関数型プログラミング言語の内包表記は、リレーショナルクエリと同型です。^[2]一部の関数型プログラミング言語は、関数型リレーショナルマッピングを実装しています。^[3] 内包表記とクエリが直接対応しているため、オブジェクトリレーショナルマッピングの問題の多くを回避できます。

不一致を回避するためのオブジェクトデータベース（OODBMS）は存在しますが、リレーショナルデータベースほど成功していません。OOはスキーマの基礎としては不十分です。^{[4]将来のOOデータベース研究には}トランザクションメモリが含まれます。

もう 1 つのソリューションは、ドメインとフレームワークのロジックを階層化します。この場合、OO はリレーショナル アスペクトを静的にではなく実行時にマッピングします。フレームワークには、タプル クラス (行またはエンティティとも呼ばれます) とリレーション クラス (データセットとも呼ばれます) があります。

• データの転送、表示、検証に関するフレームワークと自動化が簡単
• より小さく、より速く、より素早いコード^{[引用が必要]}
• 動的データベーススキーマ
• 名前空間と意味の一致
• 表現上の制約
• 複雑なマッピングを回避

• 静的型付けはありません。型付けされたアクセサーによってこの問題が緩和されます。
• 間接パフォーマンスコスト
• 多態性などの概念を無視する

OO レベルの議論を混在させるのは問題です。主にフレームワークのサポートが、モデリング レベルでデータ操作とプレゼンテーション パターンを自動化することで補います。リフレクションとコード生成が使用されます。リフレクションはコードをデータとして扱い、自動データ転送、プレゼンテーション、整合性を実現します。生成はスキーマをクラスとヘルパーに変換します。どちらもレベル間で異常があり、生成されたクラスにはドメイン プロパティ (例: Name、Address、Phone) とフレームワーク プロパティ (例: IsModified) の両方があります。

オブジェクトリレーショナルインピーダンスミスマッチはオブジェクト指向プログラミング全般で発生する可能性がありますが、特に問題となるのはオブジェクトリレーショナルマッパー（ORM）です。^{[5] ORMは構成、注釈、制限された}ドメイン固有言語の観点から指定されることが多いため、インピーダンスミスマッチを解決するための完全なプログラミング言語のような柔軟性がありません。

Christopher J. Dateは、真のリレーショナルDBMSは、ドメインとクラスが同等であるため、この問題を克服すると述べています。 ^{[6] [7] [8]}リレーショナルとOOのマッピングは間違いです。^[9]リレーショナルタプルは、エンティティを関連付けるものであり、表現するものではありません。OOの役割は、フィールドの管理のみになります。

ドメイン オブジェクトとユーザー インターフェイスには不一致なインピーダンスがあります。生産性の高い UI は、不正なトランザクション (データベース制約違反) を防ぎ、オペレーターやその他の非プログラマーがデータを管理できるようにする必要があります。これには、名前とタイプ以外のデータベース属性に関する知識が必要であり、リレーショナル スキーマでロジックが重複します。

フレームワークは、参照整合性制約やその他のスキーマ情報を活用して、ケースバイケースのコードから処理を標準化します。

SQL はドメイン タイプがないため、OO モデリングを妨げます。^{[議論中–議論]} DBMS とアプリケーション (OO かどうかは関係ありません) の間では損失が発生します。ただし、NoSQL やベンダー固有の代替クエリ言語は避ける人が多くいます。DBMS はBusiness System 12と Tutorial D も無視します。

Oracle や Microsoft SQL Server などの主流の DBMS がこの問題を解決します。OO コード (それぞれ Java と .NET) はそれらを拡張し、DBMS に組み込まれているかのようにスムーズに SQL で呼び出すことができます。複数のスキーマ間でライブラリ ルーチンを再利用することは、サポートされている最新のパラダイムです。

OO がバックエンドにあるのは、ISO SQL-99 委員会が手続き型の追加を望んでいるにもかかわらず、SQL が今日のプログラマー向けの最新のライブラリや構造を取得することは決してないためです。SQL を変更するのではなく、それらを直接使用する方が合理的です。これにより、「アプリケーション プログラミング」と「データベース管理」の間の責任の分担があいまいになります。制約とトリガーを実装するには、DBA と OO の両方のスキルが必要になるためです。

この主張は意味がないかもしれません。RDBMS はモデリング用ではありません。SQL はモデリングに悪用された場合にのみ損失が発生します。SQL はビッグ データのクエリ、並べ替え、フィルタリング、および保存に使用されます。バックエンドの OO は、ビジネス ロジックがデータ層にあってはならないため、不適切なアーキテクチャを促進します。

リレーショナルでは、DBMS が権威を持ち、OO プログラムのオブジェクトは一時的なコピー (データベースが同時に変更された場合は古くなる可能性があります) であると言われています。OO では、オブジェクトが権威を持ち、DBMS は永続性のためだけのものであると言われています。

新しい機能はコードとスキーマの両方を変更します。スキーマは DBA の責任です。DBA は信頼性に責任があるため、プログラマーによる不必要な変更を拒否します。ステージング データベースは役立ちますが、承認をリリース時に延期するだけです。DBA は、欠陥がそれほど壊滅的ではないコードへの変更を抑制したいと考えています。

コラボレーションを増やすことで、この問題を解決できます。スキーマ変更の決定は、ビジネス ニーズに基づいて行う必要があります。新しいデータやパフォーマンスの向上は、どちらもスキーマを変更します。

重要な哲学的違いが存在します:

• 宣言型インターフェースと命令型インターフェース – リレーショナルは宣言型データを使用するのに対し、OO は命令型動作を使用します。トリガーとストアド プロシージャでリレーショナルを補うものはほとんどありません。
• スキーマの制限 – リレーショナルでは、行がエンティティ スキーマに制限されます。OO の継承 (ツリーかどうかに関係なく) も同様です。OO では属性を追加することもできます。新しいいくつかの動的データベース システムでは、リレーショナルに対してこの制限はありません。
• アクセス ルール - リレーショナルでは標準化された演算子が使用されますが、OO クラスには個別のメソッドがあります。OO の方が表現力に優れていますが、リレーショナルには数学的な推論、整合性、および設計の一貫性があります。
• 名詞と動詞の関係 – OOクラスは、動詞の動作と密接に関連付けられた名詞エンティティです。これが概念を形成します。リレーショナルは、その密接な関連付けの自然さや論理性に異議を唱えます。
• オブジェクト ID  – 同じ状態を持つ 2 つの可変オブジェクトは異なります。リレーショナルではこの一意性は無視され、候補キーを使用して作成する必要がありますが、この識別子が現実世界に存在しない限り、これは適切な方法ではありません。リレーショナルでは ID は永続的ですが、OO では一時的なものになる可能性があります。
• 正規化 – オブジェクト指向ではリレーショナル正規化が無視されます。ただし、ポインターを介して相互リンクされたオブジェクトは、ネットワーク データベースであると言えるでしょう。これは、極めて非正規化されたリレーショナル データベースであると言えるでしょう。
• スキーマ継承 – リレーショナル スキーマは OO の階層継承を拒否します。リレーショナルはより強力な集合論を受け入れます。あまり一般的ではない非ツリー (非Java ) OO も存在しますが、リレーショナル代数よりも困難です。
• 構造と動作 – OO は構造 (保守性、拡張性、再利用性、安全性) に重点を置いています。リレーショナルは動作 (効率性、適応性、フォールト トレランス、活性、論理的整合性など) に重点を置いています。OO コードはプログラマー向けですが、リレーショナルはユーザーに見える動作を重視します。ただし、タスク固有のビューは一般にサブタスクに情報を提示するため、リレーショナルでは非固有のものである可能性がありますが、IDE はこれを無視し、オブジェクトが使用されていると想定します。
• セット関係とグラフ関係 – リレーショナルはセット理論に従いますが、オブジェクト指向はグラフ理論に従います。同等ではありますが、アクセスと管理のパラダイムは異なります。

そのため、支持者は相手の技術を放棄すべきだと主張する。^[10] RDBMS DBAの中には、オブジェクトがトランザクションよりも長く存続すべきではないとして、オブジェクト指向よりも手続き型を主張する者もいる。オブジェクト指向は、リレーショナルに代わるOODBMS技術を開発すべきだと反論する。しかし、ほとんどのプログラマーはこれを支持せず、オブジェクトとリレーショナルのインピーダンス不一致を単なる障害とみなしている。

ORMは状況に応じて利点を提供します。懐疑論者は欠点を挙げ、盲目的に適用した場合の価値はほとんどないと言います。^[11]

• オブジェクトリレーショナルマッピング – プログラミングテクニック
• オブジェクトリレーショナルデータベース - データベース管理システム

• オブジェクトとリレーショナルのインピーダンスの不一致 – Agile Data エッセイ
• コンピュータサイエンスのベトナム - ミスマッチ問題の例