シャローム！Sato-Gです。
Go Toキャンペーンとは全く関係ないけど今は札幌。
朝晩、犬の散歩に連れていくんだけど、すっかり甘えん坊になり、部屋でZoomでビデオ会議を始めると吠えられる。
どうも仲間に入れてほしいらしい。
お客さんとのZoomだとちと恥ずかしい。
さて、行レベルセキュリティの第２回めはScope Limitationsの設定で、セキュリティがどう変わるかを実証してみる。
1. Scope Limitationsの種類
第１回めはデフォルトである「常にこのルールを適用する」を指定して、[売上地域]で行レベルセキュティの挙動を確認した。
今回は以下の４つの設定でどのように変化するかを確認してみる。
①常にこのルールを適用する
②このテーブルを含むクエリにのみ適用する
③次のテーブルのいずれかがクエリに含まれる場合、このルールを適用する
④クエリ内の全てのテーブルが次のリストからのものである場合、このルールを除外する
尚、ピボットテーブルで使用するフィールドは以下のテーブルに含まれている。
■ディメンションテーブル
Area : 売上地域・売上都道府県
Store：店舗名
category_product：商品大分類
■ファクトテーブル
Sales：売上金額
データモデルは以下のとおり
2. Scope Limitationsの違いを確認する
2.1 常にこのルールを適用する
「常にこのルールを適用する」を選択した場合、以下のように制限される。
売上地域・売上都道府県・店舗名の全てが制限されている。
ファクトテーブル[Sales]に対して、[Store]と[Area]は同一系統のディメンション上にあるため、全く結合の異なる[category_product]の商品大分類で表示してみる。
２つのピボットテーブルで総計が合致していることから、商品大分類でも北海道に制限されていることがわかる。
2.2 このテーブルを含むクエリにのみ適用する
「このテーブルを含むクエリにのみ適用する」を選択すると売上地域・売上都道府県が[Area]テーブルに含まれているため、この２つのフィールドに制限が及ぶはず。
[Area]テーブルを含むクエリの場合は、売上地域・売上都道府県・店舗名で「北海道地域」に制限される。
一方、[Area]テーブルにない[店舗名]のみのクエリでは制限がかからない。
総計が一致しない。つまり商品大分類においては、やはり制限がかからない。
2.3 次のテーブルのいずれかがクエリに含まれる場合、このルールを適用する
「次のテーブルのいずれかがクエリに含まれる場合、このルールを適用する」を選択し、テーブルとして[Store]を指定する。
行レベルでキュリティを指定した[売上地域]を含む[Area]テーブルか[Store]テーブルのいずれかが含まれる場合、「北海道地域」に制限されている
[category_product]テーブルは含まれていないため、総計が異なる（商品大分類の集計には制限は及ばない）
[category_product]を追加指定してみる
当然だが、商品大分類も制限されていることがわかる
ファクトテーブルである[Sales]を追加してみる。
（各ピボットテーブルの数式で[売上金額]が含まれている）
全てのクエリに売上金額のある[Sales]テーブルが含まれているため、「北海道地域」に制限がかかる。
2.4 クエリ内の全てのテーブルが次のリストからのものである場合、このルールを除外する
「クエリ内の全てのテーブルが次のリストからのものである場合、このルールを除外する」を選択し、[Store]と[Sales]のテーブルを指定する。
[Store]の店舗名と[Sales]の売上金額を含む集計だけが、ルールが除外されている。
[Store]と[Sales]で構成されていない、商品大分類の集計ではルールは除外されない。
3. まとめ
Scope Limitationsの設定による行レベルセキュリティの効果について確認してきた。
整理すると...
「①常にこのルールを適用する」では行レベルセキュティを設定したフィールドのフィルタ状態が全てに及ぶ。
通常はこの設定が多いと思う。
ただ、全社合計を出す必要がある場合は、この設定は好ましくない。
「②このテーブルを含むクエリにのみ適用する」では、ここで指定したテーブルが含まれるクエリに制限が及ぶようになる。
これは売上地域別では制限を掛け見せないにも関わらず、店舗名や商品大分類での集計では行レベルセキュリティを掛けない。
全体数値は把握できるが、地域別集計では制限するような場合に有効。
「③次のテーブルのいずれかがクエリに含まれる場合、このルールを適用する」では、ここで指定したテーブルのいずれかがクエリに含まれる場合に制限がかかる。「いずれか」だからOR条件であることに留意する。
つまり指定したテーブルのいずれかが含まれれば制限がかかるようになっている。
今回のケースでは[Area]と[Store]は依存関係があるため、[Area]と[Store]を指定しておけばよい。Areaが絞り込まれているのに店舗が見えてしまってはおかしいよね。
インジケータでは全社数値が見えるようにしておき、全体業績に対しての自分の地域の業績を把握したいケースで有用。
「④クエリ内の全てのテーブルが次のリストからのものである場合、このルールを除外する」では、特定の条件下でのみ全体数値が見えるようにしたい場合に有効だ。
これらの設定は行レベルセキュリティの制限を掛けつつ、どんな場合に全体の数値を把握できるようにするかで選択が変わる。
うまく使いこなせば、細かい要求にも応えられそうだ。
でもちょっと複雑かな...
設定間違ったら想定外のデータが見えてしまう可能性もあるので、慎重に利用したい。
ではまた！
Sisenseを体験してみませんか？
INSIGHT LABではSisense紹介セミナーを定期開催しています。Sisenseの製品紹介や他BI製品との比較だけでなく、デモンストレーションを通してSisenseのシンプルな操作性やプレゼンテーション機能を体感いただけます。
