前回は、テーブル: TRAN_02 を使い、リレーション・キーに使用している項目が複数行ある場合の集計について説明しました。今度は、CST テーブル側が複数の場合についてみていきましょう。

これは、データベースの正規化の原則からすると、あまり好ましい状態ではありません。しかしながら、実務では（何故か）こんなことも起こります。何かの間違いか？　データ・モデリングが間違っているのか？　本来はデータ元を正すべきですが、"リレーション" の動作検証を行うためにこれでやってみます。

使用するサンプルデータはこちらに置いときます。ダウンロードしてご使用下さい。
Google Drive フォルダー

今回は、TRAN_02 と CST_02 で "リレーション" を行ってみましょう。

CST_02 は以下の内容になっています。

C_CST_CD: b と c が２行あります。b は C_CST_GENDER が m 、c は f と m があります。また C_CST_AGE はそれぞれ異なっています。早速、２つのテーブルを CST_CD でリレーションし、結果を確認してみましょう。

bさんの年齢は合計45、数量は70、cさんの年齢は合計65、数量は30 になっています。このことから、"リレーション"では個々のテーブルで集計が行われてから、"リレーション" キーで２つのテーブルが完全外部結合されていることが解ります。また、C_CST_GENDERを追加した場合は、各行の集計を行いつつも、総計は個々のテーブルの総計が維持されていることが解ります。

これを従来の結合で同様のことを行う次の結果になってしまいます。

ｂさんの年齢の合計は 20x2+25x2 =90 になり、数量は 20x2+50x2 =140 になってしまいます。"結合" の場合、"結合" キーのレコードが複数存在するとその分だけ行数を増やし、その結果を集計することになるからです。一般的にどちらが求めている集計結果でしょうか？　あえてこのような結果を出したい場合があるかも知れませんが、"リレーション" のほうが自然な集計結果だと思います。"結合" の場合も、 LOD計算を駆使すれば "リレーション"と同様の結果を出すことは可能ですが、かなり難しい計算になります。前回の繰り返しになりますが、"リレーション" は、人間が考える自然な集計に近く、さらに選択したディメンション項目に応じて、柔軟な集計を行ってくれます。

では、Tableauが 今回 の "リレーション" で行った処理を SQLで確認してみましょう。今回も、双方のテーブルの集計が行われていますで、２つの SQLが発行されています。

一つ目のクエリーは、データの流れを書くとこんな感じです。

　二つ目のクエリーは結構複雑です。データの流れを書くとこんな感じです。

この２つのクエリーが Tableau上でマージされて結果表示となっています。

このようなケースで SQLを見てみたのは初めてだったのですが、想像していたものと少し違いました。多少面倒な SQLになっていますが、あらゆるケースを想定してこのようになっているのでしょうか？　何れにせよ、Tableauのワークシートでの５回のドラッグ＆ドロップ操作で、こんな SQLが書かれてるとは驚きました（これを頭で考えながら素で書いたら1時間位かかるかも）。

最後に年齢の合計には違和感がありますので、おまけで対処方法の例を動画で上げときます。よかったら参考にしてみて下さい。 "カーディナリティ" の設定で解決する方法もあるのですが、難解なところがありますので、また後日説明します。　(カーディナリティの設定では、正しい計算結果を得られませんでしたのでこの部分のコメントは削除します 2023/1/8追記 )