シャローム!Sato-Gです。
東京も梅雨入り、毎日ムシムシして通勤が憂鬱。これで気温が上がったら最悪だな。

さて、ElastiCubeのデザインのポイントは3つと言われている。
・Business entity-oriented
ビジネス要件を満たすよう様々な角度から分析ができる
・Single query path
テーブル間は一つの経路で繋ぎ、クエリを効率化する
・Designer-friendly
ダッシュボードデザイナーがわかりやすい構造にする

【Data Modeling】データベースの準備~Generic JDBC Connectorで接続で取り込んだ状態のElastiCubeはまだテーブルのリレーションシップすらしていない状態なので、これを利用してデータモデリングに際して効率的な手法を紹介していく。
今回はテーブル間で2つ以上のキーが存在する場合の対処法だ。

1.リレーションシップの設定

まずはテーブルの確認。
下記のようにリレーションシップを設定していくと「注文明細」テーブルと「配送」テーブルのリレーションシップを設定しようとした時に注文番号と明細番号の2つのキー項目が存在することに気づく。

パフォーマンスを保つためにも、テーブル間は出来るだけ一つのキーで結合しておきたいよね。

2.カスタム列でカラム連結

注文番号(TEXT)     例) 1234-234
明細番号(INTEGER)    例) 1
これらを連結して、1234-34-1 という新たなキーを作りたい。
もちろんインポート時のSQLで行ってもいいのだが、今回はカスタム列を作成して行う。

2-1.カスタム列の作成

カスタム列は以下のように左ペインの該当するテーブルの右側をクリックして追加する。
データモデルビューのテーブルをクリックしてメニューを表示して行ってもよい。

2-2.カスタム列の設定

2-2 カスタム列の設定
今回連結するカラムはデータ型が異なるため、TEXTに統一したい。
そのためには【Data Modeling】CreateDate関数で日付項目のハンドリングでも説明したToStringを使用する。

・ToString(object)
数値などを文字列に変換する

またカラムを連結する時は+で行うのが正しいようだ。
SQLでの連結は”||”やCONCAT(A,B)などの方法もあるが、前者は認識してくれず、後者は3つ以上の連結には対応していない。

よって今回の数式は以下のように設定してみた。

フィールド名: 注文KEY
定義: [注文番号]+'-'+ToString([明細番号])

プレビューするとこの通り、目的とする注文KEYが生成された。
上記の手順に沿って配送テーブルでもカラムの連結を行っておく。

注文明細テーブルと配送テーブルの両方にできた注文KEYでリレーションシップを設定する。
ここで、配送テーブルの注文番号と明細番号は表示する必要がないため、非表示に設定する。
最後にビルドして完成だ。


3.ビルド時間の問題

ビルドしている最中に気づいたことなのだが、注文KEYを作成する処理はデータソースのインポート時ではなく、一旦インポートしたテーブルから注文KEYを作成しているようだ。

【Data Modeling】CreateDate関数で日付項目のハンドリングで行った日付の処理もビルドの1ステップになるようで、今回の連結フィールドも含めるとステップがそれだけ増えている。
つまりカスタム列を作成するとビルド時のステップが増える。これはデータサイズが大きい時のビルド時間に影響しそうだ。
ではどれくらい時間がかかるのか、実際に実験してみた。
transactionsというレコード数1000万件のデータでCreateDateしてカスタム列(sales_date)を作成した場合の結果は以下の通り。

・transactions(1000万件)のインポート=2分40秒
・salese_date(カスタム列)の処理=20秒
単純計算で8分の1。
※5000万件の場合はそれぞれ12分41秒と1分43秒

それなりに時間はかかるようなので、データ件数が多い場合にはカスタム列の作成はほどほどにしたほうが良さそうだ。

4.まとめ

今回はテーブル間のリレーションシップを単一のキーで設定するためのカラム連結を行ってみた。
テーブル間のリレーションシップの設定が複数のキーで構成される場合には、カラムを連結して行い、クエリのパスを最小限にしておこう。

ではまた!

この記事が気に入ったら
いいね ! しよう