data-modeling - エンティティ関係モデリング: エンティティの「役割」を実装する方法は?

Question

最近、データ モデリングについて少し読んだことがありますが、エンティティが果たす役割について質問があります。

会社があり、会社がサプライヤー、顧客、ディストリビューターなど、またはこれらの役割の組み合わせであるという単純なケースを考えてみましょう。したがって、会社 X はサプライヤーと顧客の両方である可能性があります。

データ レベルでは、CompanyS のテーブルがあり、次に Company テーブルを参照する SupplierS、CustomerS などのテーブルがある場合があります。少なくとも、これはそれがどのように表現されるかだと思います。

さて、アプリケーションランドのどこかに、CustomerS や SupplierS などのクラスがあります。それぞれが Company で構成され、その特定のクラスに関するその他の特別な要素が含まれます。

一度に 1 つのエンティティ クラスだけを操作する限り、これで問題ありません。会社から始めて、それがどのような役割を果たしているのかを確認したい場合はどうすればよいでしょうか? したがって、アプリケーションで Company をプルアップすると、それがサプライヤーとディストリビューターであることがわかります。

これを行うにはいくつかの方法が考えられますが、この問題領域は非常に古いため、これらの概念をモデル化するための実証済みの真のパターンが必要であると感じています。

したがって、私がここで探しているのは、アプリケーション レベルでエンティティ ロールをモデル化するための一般的な戦略またはパターンです。この特定のテーマに関する特定の参考資料は大歓迎です (ブログや書籍など)。

Answer 1

ほとんどのDBMSは、必要な柔軟性に欠けているため、この問題には適していません。これが、1977 年にCharles Bachmanがロールの概念を追加することで、 CODASYL ネットワーク データ モデルの拡張を思いついた理由だと思います (ロール データ モデルの再検討( PDF ) も参照)。しかし、IMHO Bachman はまだ階層データ モデルの影響を受けすぎており、所有者/メンバーの関係セットの観点から考えていました。

概念的には、当面の問題はグラフ/ネットワークに対応します。エンティティをノードとしてモデル化すると、エッジ (関係) に役割を示すラベルが付けられます。たとえば、Order エンティティは、Person、Company、またはその他のエンティティに接続された "ordered by" 関係を持ちます。"ordered by" 関係に従うと、ターゲット ノードが Orderer インターフェースを実装するエンティティを表していることがわかります。

数学用語でここで必要なのは、ラベル付けされた有向マルチグラフです。Neo4j (私が関与しているオープン ソース プロジェクト) のようなネイティブ グラフ データベースまたはRDFの両方でそれを見つけることができます。RDBMSの上に RDF 実装もあります。おそらく、グラフの概念は、これをゼロから実装する方法についてのヒントを与えることもできます。役割の概念については、私のブログ記事「データ モデリングにおける柔軟性」でも簡単に説明しています。

Answer 2

継承は最後の手段としてのみ使用することをお勧めします。このような関係は簡単ではなく、初期の最適化の形で簡単に設計を台無しにしてしまいます。会社がサプライヤーおよび/またはディストリビューターの両方になることができる場合、サプライヤーまたはディストリビューターの属性を持つ会社を作成したくありません。代わりに、データベースを正規化するのと同じように考えてください。次のような一連の概念があります

• 会社(CompanyID、name、attrib1、attrib2)
• 会社であるサプライヤー( SupplierID、CompanyID[外部キー]、attrib1、attrib2)
• 会社でもあるディストリビューター(DistributorID、CompanyID、attrib1、attrib2)
• VendorRelationship (RelationshipID, SupplierID, DistributorID, attrib1, attrib2) サプライヤーとディストリビューター間の接続に関する詳細を追跡する必要がある場合

これにより、会社、サプライヤー、ディストリビューター間の結合が低く保たれます。

この別の例は、クラスに状態がある場合です。多くの場合、概念モデルは継承を使用して、さまざまな可能な状態を処理するために、クラスがポリモーフィックな子を持つクラスのインスタンスであることを示します。これは、インスタンスの状態を変更する必要があり、ポインタが無効になったり、影響を受けるインスタンスが複製されたり、コレクション内で複製されたりする可能性があることに気付いたときに問題を引き起こします。別のクラスの新しいインスタンスを作成してから、ポインターを対象の Company に置き換える必要があるため、コピーが多数ある場合や、インスタンスがコンテナーまたはリスト内に含まれている場合、これは困難な場合があります。よりシンプルでクリーンな解決策は、子クラスとして可能な状態を持つ BaseClass 型の要素をクラスに含めることです。こちらです、

Answer 3

Object Role Modelingを使用してデータベース設計を確認することをお勧めします。基本的に、質問文で使用するタイプの式を使用して、オブジェクト (エンティティ) が相互に関連して果たす役割を主張します。他の機能の中でも特に、完全なリレーショナル データベース設計を生成できます。

ここに別の参照があります。

Answer 4

残念ながら、この問題に対処する方法を「一般的なパターン」に与えることはできません。ただ、「唯一無二」というパターンは全く無いとも思います。

その理由は、モデリングがどういうわけか「あいまい」だからです。ドイツのコンピューター雑誌で、似たようなモデリングの問題がいくつかあったことを覚えています。それは一種のコンテストであり、彼らは提出されたさまざまな解決策を示しました。解決策はまったく異なりますが、それらはすべて何らかの形で有効です。目の前の問題の内容にもよると思います。「無駄のない」ソリューションが美しい場合もあれば、プロジェクトのニーズを満たすために「大きく、太く、壮大な」ソリューションを実行する必要がある場合もあります...

など、モデリングは依然として自由なパラメータが多いクリエイティブな作業です。

もちろん、合意された「メタパターン」がいくつかあります。たとえば 、有名な "Gang of Four" による"Design patterns"の本や、他にも多数の書籍があります。しかし、まだ多くの問題が存在し、合意された「最善の」解決策が存在しません。

あなたの場合、サブクラス化を使用することが可能です（これは特殊化と同等です）。また、「サプライヤ」などを、企業によってサポートされている/されていないインターフェイスにすることもできます (これは、抽象的なエンティティからのオプションの特殊化と見なすことができます)。しかし、同じ問題に構成を使用することもできます。ロールは、会社によってリンクされたオブジェクト (エンティティ) である可能性があります (たとえば、関係「役割を持つ」)。