時系列データの蓄積とスキーマ
前回、「時系列に蓄積するとは？」および「どんなスキーマが適しているのか？」という見出しで書いた疑問に関しまして、この項で私の考えを述べさせていただこうと思います。
時系列データの3通りの見方
マスタデータのすべての変更履歴が蓄積されているとしたら、データはどのように見ることができるのか、このことを商品マスタの属性である「商品分類」を例にとって考えてみようと思います。
たとえば商品の一つである『紙コップ』の分類が、時間の経過とともに「雑貨」→「紙容器」→「食器」と変化し、現在は「食器」として分類・集計されているとします。現時点において過去の一定期間を集計する場合、どのような集計が可能でしょうか。
集計の仕方としては、次の3通りが考えられます。
- 現在の分類「食器」で集計する。
- 集計期間の終点の分類「紙容器」で集計する。
- 「雑貨」の期間は雑貨として集計し、「紙容器」の期間は紙容器として集計する。
この3通りの集計の仕方をデータの見方として書き直すと、各集計方法は次のように表現できます。
- 現在（最新）のマスタの属性値でトランザクションデータを見る。
- 過去のある時点のマスタの属性値でトランザクションデータを見る。
- 発生時点のマスタの属性値でトランザクションデータを見る。
つまり、時系列データには、この3通りの見方があるということです。
時系列データの見方とスキーマの関係
時系列データの3通りの見方とスキーマの関係を考えてみようと思います。
スキーマには、フラットスキーマ（大福帳）、第3正規形、ディメンジョナルモデル（スタースキーマ）、スノーフレークスキーマなど具体的な形はいろいろありますが、マスタデータの変更履歴を蓄積するという観点では大きく2つのグループに分類することができます。それは、マスタデータをトランザクションデータに埋め込むタイプと埋め込まないタイプであり、フラットスキーマは前者、それ以外は後者です。ここでは便宜的に、前者を「非正規型」、後者を「正規型」のスキーマと呼ぶことにします。
非正規型スキーマは、トランザクション発生時点の属性値がトランザクションデータに埋め込まれているため、ある一時点のマスタの属性値を抜き出して集計対象のトランザクションデータに一律に適用することができません。つまり、③の見方はできますが、①と②の見方ができません。
これに対して正規型スキーマは、非正規型とはまったく逆で、ある一時点のマスタデータの状況をトランザクションデータに一律に適用する形でデータ全体を見ますので、①と②の見方はできますが、③の見方ができません。
どちらのタイプを採用するか
それでは、マスタデータの変更履歴を蓄積しようとする場合、正規型と非正規型のいずれのスキーマを採用すべきでしょうか。
通常、業務系システムでデータを見るときは、①（現在を過去にシフトすれば②）の見方をしています。つまり、ある一時点（最新の時点）のマスタデータの状況をトランザクションデータに一律に適用する形でデータを見ているのです。したがって、もし過去の任意の時点で出力した内容とまったく同じデータをデータウェアハウスから取得する必要があるならば、正規型スキーマ（マスタデータはマスタデータとして独自に変更履歴を蓄積する）を採用すべきだということになります。
例外について
しかし、これには例外があります。
マスタデータの属性の中には、③の見方を要求されるものがあるのです。たとえば「単価」や「会員年代」といった属性で、これらは商品マスタや会員マスタの属性ですが、トランザクション発生時点の値を記録しなければならず、このために業務系システムでは必ずと言ってよいほどトランザクションデータに埋め込まれています。私はこのような属性を「結合型」の属性、それ以外を「分離型」の属性と呼んでいます。
余談ですが、正規化を崩すことを非正規化といい、重複データ、導出データ、テーブル結合、水平分割などさまざまな手法があります。ではなぜ非正規化が必要かといえば、データへのアクセス方法を簡略化することで性能を向上させるのが目的です。しかし、リレーショナルデータモデルの特性上、必ず非正規化しなければならない属性があり、それが③の見方を要求される「結合型」の属性です。
さて話を戻しますと、例外というのは、この結合型の属性です。これは業務系システムと同じようにデータウェアハウスにおいてもトランザクションデータに埋め込む必要があります。マスタデータの変更履歴を蓄積するならば、「単価」などの結合型の属性も独自に変更履歴を蓄積すれば同じことではないかと思われるかもしれませんが、そうではありません。独自に変更履歴を蓄積するということは、時系列データの3通りの見方の①と②の見方をするため、つまり一時点の状況が切り出されることが前提になっているのです。
なお、独自に変更履歴を蓄積しつつ③の見方を可能にする方法として、代理キーを使用するという考え方がありますが、私は代理キー方式は結局はフラットスキーマを作成するのと同じことになるか、あるいはハイブリッドなスキーマになるため、導入には積極的ではありません。
