レコードの所有者であるユーザとチームの違い

1.レコード所有者の基本

エンティティの属性である「企業形態」を「ユーザまたはチーム」に設定した場合に、「所有者」というフィールドが自動的に作成されます。

所有者はレコードの所有者のことです。ユーザまたはチームになります。デフォルト所有者はユーザです。また、部署は「既定のチーム」として、レコードの所有者に設定できます。

レコードの所有者と、所有者の部署を使い合わせて、エンティティへのアクセスレベルを5段階で構成できます。
・選択なし、ユーザ、部署、部署配下、組織全体

逆に、レコードに所有者がない場合、エンティティへのアクセスレベルは2段階でしか構成できません。
・選択なし、組織全体

2.所有者をチームにする場合の注意点

データを新規登録するとき、デフォルトの所有者はログインユーザになっているので、ログインユーザのチームに書き換えると、カスタマイズが必要です。

このため、以下運用的な協力も必要です。
・ユーザを事前にチームに登録しておく
・同じユーザを複数のチームに登録した場合、どのチームをデフォルト所有者にするのかを決めておく

また、ユーザとチーム両方に、セキュリティロールを設定しなければいけません。
データの閲覧にログインユーザの権限が聞かれます。データを保存するときに、所有者であるチームの権限が求められます。

3.所属異動と組織変更への対応

所有者がユーザ、チーム別に、所属異動時と部署統廃合時に必要な処理を下表に纏めています。

レコードの割り当てはエンティティ毎に行うので、エンティティ数とデータ量の多い場合、大変な操作になります。

よって、部署統廃合が多い組織では、所有者をユーザに、所属異動の多い組織では、所有者をチームにすると検討してはいかがでしょうか。

以上

複数の部署を動的に検索する

まず、検索条件を動的に設定できる項目を確認します。

1.個々のエンティティに存在する動的検索可能項目および条件

2.個々のエンティティから、関連エンティティ経由で設定できる動的に検索可能項目および条件

上記2つの表が示すように、ログインユーザの所属部署を動的に、検索条件に追加できます。
Dynamicsでは、ユーザはただ一つの部署に所属するので、一つの部署だけ、検索条件に追加できることも分かります。

ここで、部署とチームをフルに活用して、複数の部署を動的に検索する方法を紹介します。

まず、下図のように、組織を構成します。

この組織構造を説明します。
・ユーザをチームに所属させます。Dynamicsでは任意ですが、ここでは必須です。
・ユーザを部署に所属させます。Dynamicsでは必須です。
・チームを部署に所属させます。Dynamicsでは必須です。
・Dynamicsのチームを実務の中の部署として使います。

更に、レコードの所有者(OwnerId)はチームとします。

こうすると、ユーザ、組織、データの関係は次のようになります。

最後に、
ビューのフィルター条件で、「所有チーム（チーム）の部署が現在の部署に等しい」と設定します。

チームを部署と見直せば、複数部署を動的に検索できるようになったと思いませんか。

以上

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

二つのエンティティに、N：N関連付けを作成すると、関連情報を格納する「関連エンティティ」が自動的に作成されます。

関連エンティティを画面経由でアクセスできません。データベースを直接確認すると、以下４列で構成されいることがわかります。
・.一つ目のエンティティのレコードID
・二つ目のエンティティのレコードID
・システムユーザID
・バージョンナンバー

N対Nの関連を持つ部署と従業員を例に、N：N関連付けの作成画面を確認します。

関連エンティティ名項目が設けられていることから、エンティティが作成されていることがわかります。表示オプションは、フォームナビゲーションに、相手エンティティのサブグリッド画面に遷移するリンクを表示するかどうかの選択です。

Dynamicsでは、エンティティ間の関連付けを確認しやすいように、N：N関係を持つエンティティのどちらからでも、関連付を確認できます。

関連エンティティに、N：N関係を持つ二つのエンティティのレコードID（外部キー）を格納します。データの追加と削除は次のタイミングで行われます。

例の部署と従業員を用いて説明すると、
・部署に、従業員を追加、または削除するとき
・従業員に、部署を追加、または削除するとき

１：N関連と違って、部署データまたは従業員データを新規作成するとき、相手データと関連付けできません。必ずデータを作成してから、追加する形で、関連付けしなければいけません。

また、部署から、従業員を削除すること、または従業員から部署を削除することは、関連エンティティのデータを削除することです。決して従業員、または部署そのものを削除するわけではないことを理解すれば、N：Nの関連付けは理解できていると思います。

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

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

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

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

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

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

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

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

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

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

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

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



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


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

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

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

以上