ビューの使い方で個人的に感心してしまったので、備忘録として。
複雑なユーザとチームと部署
まずは、エンティティ構成のおさらいからしましょう。
Dynamicsにおいては、ユーザの所属をまとめる単位として、部署とチームがあります。
どちらも、ユーザを束ねるエンティティですが、部署は階層で構成されているのに対し、チームは上下関係を持たずに任意のユーザを所属させることができます。
いわゆるネットワーク型というヤツです。
ユーザは必ず1つの部署に所属しています。
また、あまり知られていませんが、チームにも必ず1つの部署に所属しています。
つまり、部署とユーザは1:Nの関係です。
同様にチームと部署も1:Nの関係です。
ユーザは複数のチームに所属ができます。
所属するチームがなくても構いません。
つまり、ユーザとチームはN:Nの関係です。
エンティティのレコードは所有者フィールドを持っています。
この所有者、一部エンティティは除きますが、ユーザにもチームにもつけることが可能で、チームにつけた場合はそのチームが所属するメンバーにレコードの操作が委ねられます。
これらのことを踏まえて、ユーザやチームを条件としてビューを作ってみましょう。
所有者を絞り込むビューを作る
では、ここから実践。
色々なケースでビューを作ってみることにします。
自分が所有者のレコードを表示
まずは小手調べとして、シンプルに自分が所有者であるレコードを抽出するビューから作ってみましょう。
フィルター条件を以下のようにすれば自分が所有者であるビューが作れます。
所有ユーザー(ユーザー) 値が設定済み ユーザー が現在のユーザーと等しい
これは簡単ですね。
自分が所属する部署メンバーが所有するレコード
お次は自分が所属する部署のメンバーが所有するレコードを出す時のフィルタ条件。
これは、所有ユーザーが持っている部署を条件に絡めてあげることによって抽出が可能です。
所有ユーザー(ユーザー) 値が設定済み 部署 が現在の部署に等しい
まぁ、ここまではチームは関係ないので簡単ですね。
次から難易度がグッと上がります。
自分が所属するチームが所有するレコード
今度は所有者が自分が所属するチームであるレコードを抽出します。
所有がチームであることが前提となっているため、所有者がユーザのものは条件に含まれなくなります。
所有ユーザー(チーム) 値が設定済み ユーザー 値が設定済み ユーザー が現在のユーザーと等しい
このように、チームに遡って、それから関連するユーザーエンティティに条件を設定することにより、まず自分の所属するチームを抽出して、それを所有チームの条件として使用しているわけです。
SQL文的に書くとこうなります。
所有チーム IN (Select チームID From チーム Where 自分が所属するチーム)
フィルタ条件として書くと何だか分かりづらくなりますが、副問い合わせを行ってIN句で引っ掛けてるイメージを考えていただくと分かり易いかもしれません。
自分が所属するチームのメンバーが所有するレコード
次は自分が所属するチームのメンバーが所有するレコードを抽出します。
メンバー所有なので、この場合は所有者がチームではなくユーザであることが前提となります。
所有ユーザー(ユーザー) 値が設定済み チーム 値が設定済み ユーザー 値が設定済み ユーザー が現在のユーザーと等しい
これは分割して考えると分かり易いんですが、赤枠の部分で自分が所属しているチームを抽出しています。
上記の図で言うと、チームT1とT2ですね。T3はMeが所属していないので赤枠の条件には入ってきません。
あとは、残りの条件で、抽出されたチームT1とT2のメンバーそれぞれに対して条件を引っ掛けています。
自分が所属するチームの部署メンバーが所有するレコード
次は複雑さMaxのフィルタ条件。
所有ユーザー(ユーザー) 値が設定済み 部署 値が設定済み チーム(部署) 値が設定済み ユーザー 値が設定済み ユーザー が現在のユーザーと等しい
SQL文的に書くとこのようなイメージ。
所有者.部署 IN (Select 部署ID From チーム Where 自分が所属するチーム)
エンティティに跨ってのOR条件は使えない
このように使いこなせれば、複雑な形でもフィルタがかけられることができるビューですが、万全ではありません。
フィルタ条件をエンティティ単位で掘り下げて設定していくことになりますが、エンティティを跨ったフィルタ条件に対してはOR条件を設定することができません。
例えば、所有者がユーザとチームの両方に対して設定をかけたいときなどはフィルタ条件で表現することが出来ません。
どんな形のリレーションでも対応できる
このように、ビューを実際に作ることでお分かりいただけたと思いますが、フィルタ条件は1:N、N:1、N:Nのいずれのケースに対しても使うことができます。
子エンティティから親エンティティへは対象が1レコードしかないので分かりやすいですが、親エンティティから子エンティティに対しても条件を引っ掛けることができるので、子レコードが複数あった場合に条件を満たすレコードが含まれていれば抽出するという使い方ができます。
前述したように、1:N(1からN)、N:Nの場合は、SQLの副問い合わせを使用してIN句で条件を満たすレコードを拾っているイメージです。
親をたどったり、子供をみたりと頭がこんがらがりそうですが、これを知っていれば、ビューでの表現の幅が広がっていくので、覚えておいて損はありませんよ！
動作確認もしたかったけど、環境作りが大変なので機会ができたら別途載っけたいと思います。
コメント