エンティティ関連付けのデータ構造 （１：N）

「１：N」関連付けを理解するには、「関連名」と「検索フィールド」を抑えればいいと思います。

一つのエンティティに、複数の関連付けを追加できます。関連付けを識別するのに、関連名を使います。Dynamicsでは、親エンティティからでも、子エンティティからでも関連を確認できます。親エンティティから見た「１：N」の関連は子エンティティから見たN：１の関連になります。

検索フィールドは、子エンティティ側が持ちます。親エンティティのレコードID（外部キー)を格納します。

下図は、親エンティティにて、「１：N」関連付けを作成する画面です。

主エンティティが「親」、関連エンティティが「子」なので、親からみて、子と１：Nの関連を持ちます。
この画面に、検索フィールドを設定するので、「親」エンティティに検索フィールドを追加すると誤解しがちですが、検索フィールドは子エンティティに作られることを理解するのが肝心です。

関連名は親からも、子からも確認できる画面を見てみましょう。
下記画面が示している通り、「new_new_oya_new_ko」という関連名は親にも子にもあります。

関連付けと検索フィールドはセットで作られますが、検索フィールドは子エンティティにあることを次の画面で確認できます。

では、子が持っている検索フィールドに、値（親のレコードID）がいつ格納されるのでしょうか。タイミングは二つあります。

一つは、親のフォームナビゲーションから、子を作成するとき、親のレコードIDが自動的に、子が持つ検索フィールドに入ります。

子のフォーム画面に、検索項目を設置しなくても、親のレコードIDが入ります。これは、上記手順で子データを作ると、親から子へのマッピングが動作しているからです。
※マッピングは関連付けを作成するときに、自動的に作られます。

もう一つは、子のフォーム画面に、検索フィールドを設置します。検索入力するときに、親のレコードIDが入ります。



アプリケーションナビゲーションから、子データを作成すると、親画面を経由しないので、マッピングが動作しません。しかし、検索項目を画面に設置することによって、親レコードIDをいつでも追加または削除できます。


最後に、子データの表示を考えます。

アプリケーションナビゲーションから、子エンティティ一覧を表示する場合、親に関わらす、すべての子データを一覧表示できます。

親のフォームナビゲーションから、子データを一覧表示する場合、検索フィールドを、表示中の親のレコードIDで検索し、一致するものだけ表示することになります。

以上