お問い合わせ

目次

シャローム!Sato-Gです。
夏休みをちゃんと取ってなかったので、本日はお休みですっ!
というわけで今日は温泉に浸かってる。
自宅から電車で駅3つの距離にある「由縁」という温泉旅館なんだけど、18Fの東京の夜景が見える露天風呂は最高!
新宿にもこんな温泉旅館ってあるんだねー
Go Toキャンペーンは有効活用しなきゃ。

さて、温泉から上がって頭がすっきりしたところで、ブログ当番だったことを思い出し、行レベルセキュリティの続きを書くことにした。
今回は最終回で、ライブ接続で行レベルセキュリティがきちんと機能するか、Redshiftに接続して検証してみる。

1. データの準備

Redshiftに以下の4つのテーブルがあるデータベースを準備した。
■ディメンションテーブル
・customers
・products
・stores
■ファクトテーブル
・sales

2. データモデリング

ライブモデルを作成し、[+データの追加]からLiveコネクタのAmazon Redshiftを選択する。

接続設定でLocation, User, Password, Default Databaseを設定し、接続を開始する。

customers, products, stores, salesのテーブルをチェックし、リレーションを設定してデータモデルを完成させる。


3. セキュリティ設定

ライブモデルの中の今回作成したデータモデルの3点リーダメニューからデータセキュリティを選択する

[+フィールドを追加]をクリックし、セキュリティ設定するフィールドを選択する。
(ここでは store_prefecture

[+ユーザー/グループの追加]をクリックし、制限を掛けるユーザ(ここではsisense_dev)を選択する。
「値」は「□北海道」を選択し、[アクセスを許可]する。

他のすべてのユーザー/グループ」は「全部」を[アクセスを許可]すると最終的に以下の設定となる。

4. 行レベルセキュリティの検証

4.1 検証用ダッシュボードの作成

作成したライブデータモデルから以下の2つのピボットテーブルを配置したダッシュボードを作成する。
左は店舗の都道府県(store_prefecture)と店舗名(store_name)毎の売上、右は顧客の都道府県(customer_prefecture)毎の売上だが、それぞれ集計するディメンションテーブルが異なる。
「sisense_dev」ユーザでサインインした際に、store_prefectureが絞り込まれ、絞り込まれた都道府県の店舗の顧客が都道府県別に集計され、総額が合致すれば成功だ。

4.2 検証

ダッシュボードをユーザ「sisense_dev」に共有し、サインアウトする。
さらに「sisense_dev」でサインインするとダッシュボードの表示は以下のとおりとなった。
ユーザ「sisense_dev」ではstore_prefectureは「北海道」に制限され、北海道の店舗である「テスカ」で集計されている。
またこの結果は、右のcustomer_prefecture毎の集計結果と総額が一致することから行レベルセキュリティは有効に機能していることが実証された。

5. まとめ

上記のとおり、Sisenseの行レベルセキュリティは、ライブモデルの場合もElastiCubeモデルと全く同じ設定で実現可能となっている。
「行レベルセキュリティ」の設定と聞くと、なんだか面倒くさそうな印象を与えるが、3回に渡り解説してきたとおり、Sisenseでの設定は他のBI製品とは全く比較にならないくらいに簡単だ。
これならマニュアルレスでもできそう。
実際、僕はマニュアルを見ないでやったんだよね。

ホント簡単すぎてごめんなさい。

ではまた!

Sato-G

執筆者 Sato-G

大学卒業後、日本電気株式会社を経て、中堅商社、リゾート運営会社にて人事総務、財務会計、マーケティング等の広範な実務を経験。その実務経験を活かし、現職にてデータ活用コンサルタントとして、これまで100社以上のプロジェクトの運営、開発実績を持つ。Qlik Luminary2020に選出。

1 分で読むことができます。

【Widget】ウィジェットの背景を変更する

3 分で読むことができます。

Hello, Sisense(サイセンス) world!

8 分で読むことができます。

【Blog】Spotify音楽データの分析①