オブジェクトロールモデリング（ORM）で、タイプのエンティティと関係があり、タイプエンティティが存続するように指定でき、モノエンティティが生年月日の値を持つことができるモノのエンティティが与えられた場合、どのように指定しますか？モノに関連付けられたタイプのインスタンスがライブに設定されていない場合に、モノのインスタンスが生年月日の値を持つことを除外する制約。下の図を参照してください...
制約されるモデルのORM図http://img197.imageshack.us/img197/6551/dynamictypeorm.jpg
私の質問の背後にある目的は、タイプが何であるかが不明であるが、タイプの特性がわかっている場合に、システム内のタイプのモデリングを可能にすることです。より適切なアプローチがあると思われる場合は、ORMに関する回答である必要はありません。読んでくれてありがとう、うまくいけばあなたは私を助けることができます。
ジョン・サンダースが推薦した本は、私が今まで読んだ中で最高の本の 1 つです。また、すべての ORM に関する質問は、ほとんどの場合、それを読むことで解決できます。
ただし、質問に直接答えるために（そしてモデルの有効性に関する質問を回避するために）、それをそのまま制約する2つの明白な方法があります。
実際にキャプチャしたいものに応じて、サブセット制約または等式制約のいずれかを使用できます。
役割間に平等制約 (Right) を割り当てることで、生きているタイプのモノには生年月日があり、生年月日を持つモノは生きているタイプであることを概念的に要求する制約を生成できます。
ロール間にサブセット制約 (左) を割り当てることで、DateOfBirth を持つ Type の Thing は生きている Type でなければならないようにモデルを制約できます。これは、等式制約とは異なり、物事が生きているタイプであることを許可しますが、生年月日はありません。
追加機能:
これらのタイプのサブセットおよび等価制約を作成するには、「結合パス」と呼ばれるものを使用する必要があります。結合パスを使用すると、制約の両側で複数のロールにまたがる結合サブセット制約と結合等価制約を作成できます。 結合パスの例は、明白でわかりやすい場合があります。しかし、時には少し圧倒されて複雑になることもあります。また、ここで説明されているように、NORMA は結合パスの作成をサポートしていますが、等式、サブセット、および除外制約では、それらの動詞化は 100% 完全ではありません。. これは、モデルの正確性を概念的に検証する方が簡単であるため、現時点でサブセットを使用する方が簡単な理由の 1 つでもあります。
サブセット、等式、または除外制約の役割を割り当てるときに NORMA で結合パスを作成するには、まずパスの一部であるすべての役割を 1 回のクリックで割り当て、次にダブルクリックして次のパスに移動します。制約がパスを結合できる場合、その制約に含まれるロールには [#] ではなく [#.#] というラベルが付けられます。したがって、制約を作成するとき、ロール [1.1]&[1.2] はロール [2.1]/[2.1] のサブセット/等しいと言えます。各役割で役割を果たすファクトも一致する必要があることに注意してください。したがって、彼は NORMA から言語化され
ます。あるモノはあるタイプであり、そのモノはあるタイプです。そのタイプは生きています。これは、次のように表現する方が適切です。そのタイプは生きています。
ただし、これを制限できる 3 番目の (そして望ましい) 方法があります。生きているものと生きていないものは大きく異なるため、おそらくそれらを同じテーブルにマッピングしたくないでしょう。ここでは、Type ファクトを OrganicTypes と NonOrganicTypes の 2 つのサブタイプに分割します。2 つのサブタイプ間の Exclusive Or 制約は、すべてのタイプが Organic または NonOrganic のいずれかであることを示しています。注は、タイプが属するグループを決定するために使用する導出規則を示しています。そこから、[Thing is of Type] ロールを [LivingThing is of OrganicType] に再定義します。そして、OrganicThings は定義上生命が可能であるため、DOB/is Living の制約がモデルに組み込まれています。
実際、モデルには、たとえそれが単純であっても、複数の問題があります。それが今まで生きていたならば、物は生年月日を持っているかもしれません。かつては生きていたかもしれませんが、今は死んでいます。
また、「タイプが生きている」という事実がないことは「タイプが生きていない」（閉世界仮説）を意味するのか、それとも「タイプが生きていることが知られていない」（開世界仮説、I考える）。
私が持っているもう1つの懸念は、同じ「文」に「リレーショナルモデル」と「ORM」を組み合わせて、あなたの質問がやや混乱しているように見えることです。オブジェクトロールモデリングは、概念モデルを作成するための概念モデリングツールであり、リレーショナルスキーマにマッピングできます。既存のリレーショナルスキーマをリバースエンジニアリングしている場合でも、正しい概念モデルを作成するために使用する情報の一部としてのみスキーマを使用するのが最善です。さらに、有効な入力と出力の例を使用し、ドメインの専門家との話し合いも行います。これは、リレーショナルスキーマによってキャプチャされなかった、または誤ってキャプチャされた可能性のある重要な制約を発見するのに役立つことがよくあります。
ところで、優れたORMツールについては、NORMAを参照してください。これは、Visual Studio 2005または2008（Standard Edition以降）へのアドインであり、最新のORM2表記を使用します。ERダイアグラム、さらにはコードだけでなく、いくつかの異なるデータベースのSQLを生成できます。
また、本を参照してください：
私が理解しているORM（およびドメインモデル）は、ソリューションを設計する代わりに、ビジネスドメインを分析するために使用される概念モデルです。この層に「型」や「動的型」などの概念を持ち込むのは時期尚早であり、モデルの目的に合わない。
オブジェクトの役割モデリングから: 概要
代替テキスト http://i.msdn.microsoft.com/Aa290383.dv_vsea_ormoverview_06%28en-us,VS.71%29.gif
「生きている」と「生年月日がある」の間に等式制約 (「=」記号で囲まれた点線) を入れることができます。「在職中」と「契約中」に似ています。
データベースのコンテキストでは、3 つの個別のテーブルがあると仮定して、エンティティとその型の間の結合で行数をカウントする関数を作成します。DOB を保持するテーブルでこの関数を使用して、DOB が null であるかカウントが 1 であることを確認します。
擬似コード:
function fn_count_living(id)
declare @count int
select @count = count(*)
from entities inner join types on entities.typeid = types.id
where entities.id = id and types.living = 1
return @count
end
制約
fn_count_living(entity_id) = 1 or dob is null