【４つの結合方法】MotionBoardのモデル機能を解説【難易度：中】

#最初に
MotionBoardは綺麗でわかりやすいグラフや画面を作ることができます。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/04c48011-e65b-88dd-f666-a838819636e4.png" width=60%>
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/e777e485-f3d0-3dc7-57e2-ddddd2df8860.png" width=60%>
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/7bc601e7-ace8-cafa-2313-c2d66b9de500.gif" width=60%>
綺麗な上に、動いたりもします。
気になる人は下記リンクをクリックしてください。体験デモもできます。
[MotionBoard　体験デモについて（公式HPより）](https://www.wingarc.com/product/motionboard/demo/index.html)

<details><summary>【MotionBoardとは】</summary><div>
様々なデータソースからデータをあつめ、１つの画面上で統合するMotionBoard。
クラウドサービスとの接続もでき、チャットツール送信もできるのでとてもおもしろいです。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657180/877897e8-35d1-b055-a80c-b9051866bc38.png" width=60%>
※キャプチャはウイングアーク1st社のホームページより抜粋
[ウイングアーク１ｓｔ株式会社　MotionBoard](https://www.wingarc.com/product/motionboard/index.html)
</div></details>


さて、今回はMotionBoardの数ある結合方法の中のひとつである「モデル機能」について、特徴とメリデメをまとめます。
簡易的な結合であるマスター項目に比べ、キチンと設計をしなければならないモデル。でもひとつつくってしまえばボードをまたいで活用でき、全体でつかえるデータソースとなりますので、MotionBoardを効率的に運用できます。

#モデルとは
まずは[マニュアル](https://cs.wingarc.com/manual/mb/6.1/ja/UUID-8a56cc50-782c-6dff-17ac-ab7f442bb2e3.html)を見つつ、モデルとはなんぞやというところを理解しましょう。
マニュアルの最初の文を抜粋すると
>MotionBoardでは、異なるデータソースの明細データをJOINやUNIONで結合した「モデル」を作成できます。特別なデータ加工をすることなく、異なるデータソースのデータをMotionBoard上で論理的に結合可能です。

とあります。
イメージとしてはAccessのクエリの簡易版で、下図のようにテーブルを結合させることが可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/461d0989-34ab-b76b-6560-710e978966a1.png)



テーブル同士を結合させるJOINや、昨日の売上データと今日の売上データでCSVが異なる場合に、ひとつにがっちゃんこするUNION、テーブルの列を行に変換するUNPIVOTなどの機能が使えます。
（今回はデータ結合で使うのでJOINについての記事です）

#前提
モデルは使用しているMotionBoardがクラウド版かパッケージ（オンプレミス）版かでちょっと内容が変わってきます。
こちらのマニュアルは[クラウド目線で書いているオンプレとの機能差異ガイド](https://cs.wingarc.com/manual/mb/cloud/ja/UUID-5408a59c-8492-1a04-44f4-2403b22b4e4c.html#UUID-5408a59c-8492-1a04-44f4-2403b22b4e4c_d38915e2378)です。

注目すべきはこちら
>モデルのデータ格納先は、「DataStorage」のみ選択できます（ファイルコネクターやDr.Sumは選択肢として表示されません）。ただし、インメモリOLAPのオプションがある場合は、インメモリテーブルも格納先として選択できます。

クラウド版の格納先は主にDataStorageというMotionBoard Cloudにセットでくっついているデータベースです。
オンプレMotionBoardにはそれがなく、ファイルコネクターやDr.Sumを別に用意する必要があります。
[こちらのマニュアル](https://cs.wingarc.com/manual/mb/6.1/ja/UUID-29723350-9918-dfff-fa90-79fadc7ed331.html#UUID-29723350-9918-dfff-fa90-79fadc7ed331_d38915e180731)に書いてます。

さて、前提が確認できたら、いよいよつくり方を習得していきましょう。

#つくり方
今回は売上データに対し、店舗マスタと担当者マスタをJOINで結合させて、
店舗名称ごと担当者別の売上をチャートにして見たいと思います。

売上データ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/b6c31f5b-d841-0466-5a98-aa9d6ef761e3.png)

店舗マスタ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/fca536f8-f90a-69dd-993c-d1ec6b2fb1b4.png)


担当者マスタ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/0271c629-d471-2cb6-a02f-7f03326e54dd.png)




##モデル編集（クエリっぽいところ）
モデルは[ボード編集画面]から作成していきます。
[管理]→[格納データ管理]→[モデル管理]をクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/55f7f390-cd10-2b78-ac86-81e2a57a0481.png)

[モデル新規作成]をクリックし、モデルの名前を決めます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/694e6118-bdc9-ef54-542b-08213631c6fb.png)

モデルエディタ画面が出てきます。
こちらの画面上部の赤枠で、JOINになっていることを確認します。
ギアボタンをクリックすると、JOIN、UNION、UNPIVOTを切り替えることができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/359ffd07-65d9-2e49-351c-5cb3505ff5e6.png)
そして画面左上の集計表っぽいアイコンの２つが、ファクトテーブルとディメンションテーブルです。
ファクトテーブルはデータ結合の基となる売上データを指定します。
ディメンションテーブルはマスタとなる店舗マスタと担当者マスタを指定します。

まずはファクトテーブルなので、上図の赤枠をクリックします。
データソースがあれば指定ができますが、今回は一から作るので、新規作成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/070ed583-d7bb-0d38-a67e-b1710bd55e5c.png)

こちらは注意点なのですが、モデルの基となるデータはボード専用のtextやExcelが使えません。
ボードを超えた全体で取り扱うものだからですね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/64f25fb6-c8d8-8863-82d2-5e0d48d20b03.png)

そのため、事前に共有アイテムにCSVを取り込んでおきました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/d93395fb-1dcb-c924-b4c4-80b1fa9467fe.png)

今回はデータソースエディタは何もせずに[OK]です。
本来はここで必要な項目のみにしたり、追加項目でカスタム項目をつくったりします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/67d7d1cd-625d-c94c-ffa7-3332f286d541.png)

つくりました[DS_売上データ]を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/1766b95f-42a8-3a48-6d97-1bdffc3e62cb.png)

モデルエディタ内にセットされました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/70f005df-7ed9-c1c0-e540-aef7f9295121.png)

ファクトをひとつ置くと、赤枠のように次にファクトテーブルは置けません。
**モデルはファクトテーブル（別名：トランザクション）に対して、ディメンションテーブル（別名：マスタ）を複数つける形となります。**


さて、同じやり方でディメンションテーブルにマスタを２つセットします。
（同じパターンなので、やり方は省略です）

設定が終わるとこうなります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/f9a89764-dd4d-9337-8671-16add2dd4ab8.png)

次はテーブルの結合です。
下図のやり方となります。
![tests12.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/a0718b1f-a4ed-b4de-0d17-f374d836a121.gif)

① 売上データを縦にのばす（任意）
② 売上データの店舗コードと店舗マスタの店舗コードを結合
③ 売上データの担当コードと担当者マスタの担当コードを結合
④ ②のリレーションを左外部結合に変更
⑤ ③のリレーションを左外部結合に変更

結合の種類につきましては[こちらのサイト](https://sql55.com/t-sql/t-sql-join-3.php)を参照してください。
今回は「店舗マスタに売上データに入っている店舗コードがなくても、データとして残しますよ」とする左外部結合にしています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/d57fb48c-41a6-debf-26a5-b23106e23d18.png)


さて、テーブルの結合ができたので、今度は使用するデータを指定します。
各テーブルの右側にあるチェックボタンをクリックしていくのですね。

今回は重複しているコード以外のすべてを選びました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/e067d914-43e1-abbf-35d5-076110614a24.png)


これでモデルの設計は終了です。
どんな形でデータを組み合わせるかが決まりました。

[OK]をクリックします。


##データ取り込み設定
さて、このモデルというものは対象を実体化させる必要があります。
つまり☝️で指定した形を基にして、データを取り込むのです。
クラウド版の場合は、データストレージに取り込まれます。
オンプレ版の場合は[こちらのマニュアル](https://cs.wingarc.com/manual/mb/6.1/ja/UUID-29723350-9918-dfff-fa90-79fadc7ed331.html#UUID-29723350-9918-dfff-fa90-79fadc7ed331_d38915e180731)に記載しています。（前提の項で参照したものです）

データを実体化させているので、データ集計のレスポンスは早いです。
その代わり、リアルタイムなデータではなくなるというデメリットもあります。こちらはメリット & デメリットの項で解説します。

では取り込みの設定です。
今回はスケジュール実行をせずに、一回だけの手動取り込みとします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/002a0a63-52ca-ac4f-6141-9ef3713a0181.png)

タスク設定の実行ユーザーの[検索]をクリックし、そこから出てくるユーザーを選択します。
MotionBoardにログインしていない時間にもデータのロードをできるようにするため、データ取り込みをするユーザーを決めています。

毎日データをロードするのであれば、繰り返しタイプを[毎日]にしますが、今回は[実行しない]を選びます。
設定ができましたら[OK]をクリックすると、下図のようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/e4654cfd-8def-bc06-03ea-a467cc479559.png)


##データを取り込んでみる
それではデータを取り込んでみましょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/a2b134dc-0cb6-cd2d-1419-deb80b934dba.png)

赤枠のところをクリックします。
リロードしますか？　という選択画面で[OK]とすると、実行結果が表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/2c6af50e-8e90-f761-5c81-ae1591cc5557.png)

こちらも[OK]をクリックします。
これでデータの取り込み処理が開始されました。


では最後にデータを見にいきましょう。
ひとつ集計表を作ってみます。

接続先はDataStorageを選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/a749bf44-7b17-4130-7a30-8b86e8121f17.png)

[UTB_demo_モデル]を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/74544d91-99c6-2ed0-b43d-865c47e3d02e.png)

項目一覧を見てみると、ちゃんと結合した名称が表示されていますね。
赤枠が店舗マスタの項目で、青枠が担当者マスタの項目です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/b423add2-7521-d5ae-ea85-ee53f2d78bf8.png)

あとはこちらをドラッグ&ドロップしてチャート化していくだけです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/657414/5b498887-383b-f646-9a30-19567560db29.png)

モデルのつくり方については以上です。

今回、UTBテーブルを選択しました。
ではMDLテーブルは何者？　と疑問が出てくるかと思います。
ぼくもそうでしたので、解説記事を書きました。気になる方はあわせてお読みください。
[MotionBoardのモデル機能のUTBとMDLの違いについて調査してみた](https://qiita.com/Ryo---san/items/315c1aa9329201b18b42)


#メリット & デメリット
別記事で書きました[マスター項目](https://qiita.com/Ryo---san/items/2f6455d23d5cc24e4708)よりもかなり手数が多いと思います。
しかし、モデルの魅力は一度つくってしまえば、活用が容易なんです。
データソースを選択したら、もう項目がくっついているのであとはドラック&ドロップをするだけです。
なのでデータつくりには時間がかかりますが、ボードつくりには時間がかかりません。

またデータの結合は事前に済んでおりますので、画面への描画のスピードが早いです。
マスター項目やMotionBoard Viewは画面描画中に結合をしますので、描画のスピードが遅くなります。


デメリットは必ずデータをDataStrageやDr.Sumなどに保管しなければならない、つまりリアルタイム性が失われてしまうところです。
例えば基幹システムのデータベースをMotionBoardが直接参照すると、基幹システムで売上入力をしたデータをすぐにMotionBoardで閲覧することが可能ですが、モデルをつかっている場合は、データを取り込む処理を加えなければなりません。

またモデルが多くなると、夜間にモデル構築をする処理が走ることが多くなります。
他のモデルとタイミングがかちあうと遅かったりエラーが出たりしてしまうので、運用を計画的に考えなければなりません。

こちらの記事は手動取り込みの例ですが、MotionBoardのログを表示しつつ、成功したら次のデータ取り込みを実行する、という機能をつくったものです。
[MotionBoardにデータストレージにデータを入れよう〜手動で入れてログをチェックする方法〜](https://qiita.com/Ryo---san/items/c5cf5253cb5130d58334)

モデルの取り込み数が増えた時、上記のようなハンドリングの検討も必要になります。


#さいごに
いかがだったでしょうか。
マスター結合はちょちょっとつくりたいときに、モデルはしっかりと根を張ってつくるときという風に使い分けられるかと思います。

モデルをつくってしまえば、ボード作成の難易度も低くなるので、ボード作成をするメンバーを増やすこともできます。
ぜひモデルのつかい方を覚えていただき、効果的に活用してくだされば幸いです。