継承とリレーショナルコンセプトを接続するのに役立ちます

Question

私はプログラマーの仲間と相続について話していました。彼は大きな支持者であり、私は少し怠惰です。私は、データベース - >アプリケーション - >プレゼンテーション（正直なところ、私はフロントエンドの人ではないので、しばしばプレゼンテーションを他の誰かに任せています）の下からシステムを設計する傾向があります。リレーショナルデータベースシステムは、他のテーブルとの1対1の関係がなければ、継承をサポートしていないことがわかります。

私が概念的な観点から設計している場合、管理者はUser is a Personです。データベースから始めると、管理者はUserType = "Administrator"のユーザーです。これらのアプローチを調整することは難しいようです。したがって、永続化されていないオブジェクトでのみ継承を使用します。

私の考えは何ですか？伝統的なリレーショナル構造とこれらの固有の非互換性がある場合、継承はなぜOOの重要な側面ですか？または、継承をリレーショナルデータに適切にマッピングしていないのは私ですか？私にこれを明らかにする助言がありますか？

ご質問にお答えいただき、ありがとうございます。ご回答いただきありがとうございます。応答にコードを含めると、C＃は私の "母国語"です。

Answer 1

これは俗に呼ばれてきたObject-Relational Impedance Mismatch：

スキーマの継承 - ほとんどのリレーショナルデータベーススキーマの継承をサポートしていません。このような機能はOOPとの競合を減らすために理論的に追加することができるが、階層ベースの分類法やサブタイプ化の有用性は、セットベースの分類法や分類システムをより強力で柔軟性のあるものと見なす傾向があるため、木よりも。 OOの主張者は、継承/サブタイプのモデルはツリーに限定する必要はないと指摘しています（これはJavaなど多くの一般的なOO言語の制限です）。しかし、ツリー以外のOOソリューションは、リレーショナルが好まれるテーマ管理技術です。少なくとも、関係代数でよく使用される手法とは異なります。

も参照してください：Agile Data、C2 Wiki

Answer 2

C＃でそのような関係を表現する方法はたくさんあります。リレーショナルデータベースは単純に制限されています（これは利点でも欠点かもしれません）。データベース内で永続化されるオブジェクト階層を設計するときは、データベーススキーマを事実上すべてのオブジェクトの関係にマッピングできるため、データベーススキーマを最初に起動する方が簡単ですケース。

この特定のケースでは、管理者の構図をモデル化することができます。管理者テーブルには、追加の管理状態と適切なユーザーのキーが追加されます。ユーザーFKも管理者のPKになります。

Answer 3

相続には様々な種類があります。開発者はインターフェースと行動の面で考えるかもしれません。

あなたの世界では、管理者の「userType」はどういう意味ですか？

暗黙の意味は、どこかのコードがそのuserTypeを見て、そのタイプのユーザーの操作を承認するということです。だから、おそらく管理者は他のユーザーを作成できますか？開発者は、クラスのユーザーの余分な機能

class Administrator() extends User { createUser() {...}; approvePurchase() {...} } 

と

class User() { viewData(){ ...} ; signReport() {...} } 

とクラス管理者（DBA）タイプ管理者の目的は、ユーザーができることをどこでも使用することができている可能性があります。その場合には

。この多態的な振る舞いは、インプリメントするときに役立ちます。今、あなたのデータベースは、この事件をかなり当然に支持しています。しかし、管理者が特定のタスクを実行するために少しだけ余分なデータが必要な場合はどうしますか？たとえば、purchaseApproval（）は一定の上限までですが、新しいフィールドとしてその制限が必要ですが、管理者のみに適用されます。

"タイプ"の概念が暗示している動作面は、余分なデータと関連していることが多いと思います。

Answer 4

あなたはPatterns of Enterprise Application Architectureをお読みください。継承パターンがどのように関係構造を表現することができ、表現するべきかを示します。覚えておくべき

重要なことは、継承は、概念モデリングの事です。リレーショナル構造とOOコードは、それらの概念モデルの単なるマテリアライゼーションであり、すべてのオブジェクト指向であるとみなされるべきではありません。

tutorialはここのもののこのタイプにあります。

Answer 5

リレーショナルパラダイムとOOパラダイム間の隔たりは、しばしば議論されています。

基本的に、RDBMSとOO間のマッピングを提供するには、の両方の機能を犠牲にする必要があります。システム。あなたはどちら側にあなたの妥協がより重く重み付けされているかを決めなければなりません。

どちらのパラダイムは、非常に強力で便利です。しかし、それらの間をシームレスにマップしようとすると、未解決の問題になります。

Answer 6

はい、継承はデータベースとのマッピング時におそらく適切なツールではありません。あなたは異なる動作をするオブジェクトの種類を持っているが、それでも彼らは共通する部分を持っているフレームワークを構築する際に

継承がはるかに便利です。

はたとえば、一つのサーバと他の間で渡さ異なる「メッセージ」を持つことができます。各メッセージには独自のロジックがあるため、異なるクラスが必要です（巨大なswitch（）文を避けるため）が必要ですが、共通の部分があります。例えば、すべてのメッセージがストリームにシリアライズ/デシリアライズする方法Messageのすべてのサブクラスはオーバーライドする必要があります）。 また、すべてのメッセージがMessageを継承すると、Listを持ち、1つずつ移動してSerializeメソッドを呼び出すことができます。

しかし、あなたがしているのは一般的なビジネス/ DBロジックなので、継承はあなたのやり方に立つ可能性が非常に高いでしょう。それは 従来のリレーショナル構造と これらの固有の非互換性を持っている場合

Answer 7

なぜOOの継承など OFT-有名な側面はありますか？

これは興味深い引用です。なぜリレーショナル構造が「伝統的」であると言いますか？彼らは本質的にRDBMSの標準ですが、私はDB以外の言語の文脈では非常に少ないリレーショナルライブラリを見てきました。

OOが普及している理由は、支配的な手続き型モデルよりも大幅に改善されたためです。継承を使用することで、コードの信頼性を向上させることができます（型チェックによる）、より簡単な変更（メソッドの特殊化による）、テストの容易化（簡単なオーバーライドによる）手続き型モデルと比較して、OOはと多く、と高品質のソフトウェアを開発するのが簡単です。

もちろん、オブジェクト指向とリレーショナルモデルの間のマッピングは難しいです。これは「オブジェクト・リレーショナル・ミスマッチ」と呼ばれ、"the Vietnam of computer science"と命名されています。リレーショナルデータベースにOOデータを格納するためのさまざまな戦略がありますが、いずれも完璧ではありません。現代で最も普及しているのはactive record patternに基づくフレームワークです。

Answer 8

正規化されたリレーショナルデータベーススキーマは、DBAの世界で一般的に「ベストプラクティス」とみなされない限り、実際に多型をサポートしていません。これはいかなる手段によっても新たな問題ではなく、問題自体は何千もの異なる方法で解決されています。

実際の問題は、データを扱うときに発生します。データセットを使用している場合は、多様性を実装しようとする課題が引き続き発生します。しかし、ドメインエンティティのセットをリレーショナルモデルにマッピングする場合、リレーショナルデータベーススキーマの限界を克服するのに役立つ多くのツールがあります。

あなたはC＃開発者ですから、次の2つのプロジェクトを調べることで始めましょう。そのうちの1つに最新の.NETサービスパックが付属しています。

ADO.NET Entity Frameworkの：

http://msdn.microsoft.com/en-us/library/bb386876.aspx

NHibernateは：

http://nhforge.org/Default.aspx

Answer 9

Admininstratorは、 "管理者" ののUserTypeを持つユーザーであることのあなたの具体的な例は一例です"Single Table Inheritance"パターンのこれは主要なORMのいくつかで実装されています。特に "Rails ActiveRecord"とHibernate。

Answer 10

私は、問題の継承モデルに欠陥があると主張します。それはあまりにも文字通り、あるいは現実の世界に基づいています。はい、私は実世界の管理者であり、したがって管理者であると主張することができます。は人です。しかし、オブジェクトの設計と継承は、コード空間内で表現され、共有された振る舞いにより基づいていなければなりません。私はユーザーが役割を持っているルートをさらに進めていきます。管理者はロール、または特定の状態に設定されたロールのインスタンスです。ユーザーは個人ではありません（バッチジョブには、たとえばユーザーアカウントが必要な場合があります）。

デビッド・ウェスト（David West）がObject Thinkingを読み、オブジェクトデザインのイントロダクションをお勧めします。しかし、彼はObject Relation Mismatchをカバーしていませんが、人々はすでにそのトピックのリソースに多くのリンクを与えています。

Answer 11

Hibernateは継承を単純化します。 Example