DB Stories

DBに関する過去、現在、未来の話題をプロフェッショナルの視点で紹介

ディメンションテーブルの整合性(conformed dimensions) (4)

ディメンションテーブルのデータの違い

前回も紹介した図において、商品テーブルのデータそのものについても違いからくる問題点が存在しています。 f:id:good-value:20180228222713j:plain

  • データフォーマットの違い(商品名と分類) 受注(order)スターの商品(prduct)についての商品名(product name)と分類(category)については大文字小文字が混在しています。返品(retuen)スターの商品テーブルについては大文字に統一されています。また、区切り(カンマ)の扱い方も異なります。これらの違いは横断検索時にこれらの値を利用したマージ段階で問題となります。横断検索フェーズ2
  • 商品名について統一されていない。"SKU 3333-01"は受注スターにおいては"9 x 12 bubble mailer"であり、返品スターにおいては"STANDARD MAILER"になっています。商品名の変更についてTYPE 1変更によるデータの上書きが受注スターにおいて実施されており、返品スターにおいては無視(実施されていない)されていることが推測されます。この名称の不一致は商品名を含む検索結果をマージするタイミングで問題となることになります。
  • 受注スターにおける商品テーブルのナチュラルキー(SKU)"4444-22"は1行ですが、返品スターでは2行該当しています。このことは、受注スターで商品分類(category)の変更はTYPE1変更(つまり上書き)で実施されており、返品スターではTYPE2変更による新規レコード追加で実施されたと推測できます。
  • "SKU 6666-22"について、受注スターには存在していますが、返品スターには含まれていません。これは横断検索で問題となることはないのですが、この2つのスター間におけるデータ管理の違いがあることを示唆しています。
  • "SKU 5555-22"について2つのスターにサロゲートキーの違いが存在しています。これについての配慮がテーブル結合時に必要です。

繰り返しますが、上記のようなデータ上の制限のいくつかは暫定的な対応により回避することが可能ですが、レポート処理(つまり集計処理)における違いについては回避することができません。例えば、1つ目の違い(大文字小文字/カンマの扱い)については、集計時に文字の変換(大文字に統一、カンマを取り除く)を行うことで対応可能です、データの集約前にこれらの変換処理を行うため性能上においても不利なものとなります。しかしながら"SKU 333-01"といったように商品名が違う場合については対応することができません。

これらのスター間のディメンションテーブルのデータ内容が違うという制約については、それぞれのスターに対して検索を行い、一方のスターのディメンションテーブルの値を「正」としてディメンションの値を決定させます。これをそれぞのスターの集約結果をマージするタイミングで実施することになります。繰り返しになりますがこの対応についてもパフォーマンスに影響を与えます。またレポート作成におけるこの手の対応については経験豊富な技術者の対応が必要となることからBIツールによるクイックな横断検索の実装といったことを妨げることになります。さらにこの手法についても、片方のスターのディメンションテーブルから特定商品のデータが欠落していたり、複数のレコードが存在する場合においては対応することができません。

ここまで説明してきたような一時的な対応についてデータ利用という点で妨げになることは間違いありません。

  1. 受注と返品の商品データが異なる場合にどのように比較すればよいのか。
  2. レポート作成上どちらの商品名を利用するのが正しいのか。
  3. 比較にあたってもう片方ではどのような商品名が使われているのか。

2,3については直接的には横断検索に影響は与えないのですが、2つのスターの分析をするにあたって該当の商品がもう片方のスターと誤って関連付けてしまうことによる誤りが発生する可能性が残ります。

データ整合性(データ準拠)の前提条件

横断検索(二つのスターのデータ比較)を行うにあたって、設計では先ほどの図にあったような不整合を避ける必要があります。 この二つの商品ディメンションテーブルの不整合という問題は、二つのテーブルを同一のものとして扱うことによって対応することができます。データの整合性を考えるにあたって「構造(テーブル定義)」「データ内容」という2つの前提が存在します。

同一の構造

構造とはディメンションテーブルにて同一の列定義(つまりテーブル定義)を持つことを意味します。このことは、別スターのデータを集約する際の欠落を防ぐことになります。(図でいうところの返品(retuen)商品ディメンションの商品タイプ(type)が該当します)この同一定義とした列は、同一の項目データであることを明確に示すよう名称も同一である必要があります。また、データ内容が同一であることを意味するようデータ型につても同一にする必要があります。

これらの構造の同一性は業務横断検索のフェーズ1で関連します。ディメンションテーブルの列はファクトテーブルの集約方法(集約単位)に依存します。業務横断検索のフェーズ1ではファクトテーブルの検索はディメンション項目についてここで紹介した「データ整合性のための個別対応」を行ことなしに検索を実施できます。しかし、フェーズ2検索におけるデータのマージにを行う際に(データの同一性も需要ではあるのですが)構造の同一性が役に立ちます。

同一のデータ内容

データの内容についてもディメンションテーブルの列定義は同一である必要があります。商品名の定義(SKU 3333-01)において、受注スターの定義が「9 x 12 bubble mailer」であれば返品スターにおいても「9 x 12 bubble mailer」である必要があります。このデータの同一性は2つのスターの検索結果(中間結果)を結合してマージを行う業務横断検索のフェーズ2にて有用となります。同一のデータが利用されていると、不要データの除去やデータの変換の実行が不要になるため、中間結果のマージ処理が容易になります。

テーブル構造に同一性がある場合データ取得時方法順番を入れ替えたとしても問題がなくなります。ディメンションテーブルのデータ同一性という観点でいうと、「同一のサロゲートキーで識別される列の集合を保持」して、「同一の緩やかな変更ルールを持つ」ということになります。これらの要件があったとしても、ディメンションテーブルのデータ粒度の違いがある場合はさらに問題が残ることになります。

(つづく)