BIが流行り出した今こそ知りたい「データ」を正規化する方法


前回は「キレイなデータ」の作り方として、概念設計について報告しました。

概念設計で網羅した、目的別に枠線で囲われた「データ列名」を分析しやすい形に整える「正規化」について、今回は報告したいと思います。

 

正規化とは、データ列名を3つの段階に分かれる正規形(化)と呼ばれる「形」に当てはめる作業です。正確に言うと6つまで手順がありますが、この記事では主要な第3段階までとします。

第1正規化:データ内の繰り返しを無くす

概念設計で洗い出したデータ列名を1つのテーブルにまとめてみます。概念設計の段階で複数のテーブルに分かれている場合は、そのままで良いと思います。

イメージがわきやすいので、いくつかの行を挿入してみました。決まった列に対して行が挿入されると、以下の図のように表のようになります。

 

図:1つのテーブルにまとめられたデータ列名と行

 

表をよく見ると、顧客の氏名や住所など、いくつかの行でデータが繰り返されていることが解ります。

第一段階の正規化では、こうした「同じ意味のデータの繰り返しを無くすこと」を目的に、テーブルにまとめられた「データ列名」を分析しやすい形に整えます。

 

なぜ繰り返しが発生しているかを考えると、1人の顧客が複数の注文を購入することを想定していないテーブルの構成になっているからです。

つまり1つの商品購入に対して1行必要なデータの管理方法になっているので、毎行必ず商品を購入した顧客のデータが繰り返されることになります。

そこで、1回の購入体験をした顧客に対して1行のデータを持つ商品購入履歴テーブルと、1件の商品購入に対して1行のデータを持つ商品購入詳細テーブル、2つに分割します。

 

図:第1正規化により2つのテーブルに分かれる

 

こうすれば同じ意味を持つデータの繰り返しが発生しなくなります。不必要な繰り返しが無くなりスッキリしました。

これを第1正規化と言います。

第2正規化:主キーの概念を導入する

次に、テーブルに対して「主キー」の考え方を持たせます。主キーに指定された列は、行の中で重複を許しません。言い方を変えると、主キーを使って同じように見えるデータを違うデータであると識別する役割を担っています。

例えば取引先に全く同名の企業が2社あったとします。このとき、同名でありながら異なる企業と識別するのが主キーの役割です。

主キーとして「企業ID」という列を作り、それぞれの企業にIDを1、2と割り振ります。そうすることで、同名であっても異なる企業として識別することができます。

これが第二段階の正規化です。「主キーによって、主キー以外の列にある行を一意(重複が無い状態)に識別できること」を目的に、テーブルにまとめられた「データ列名」をさらに分析しやすい形に整えます。

ちなみに、主キーは1列とは限りません。2列で主キーとすることもあります。ただし、1つのテーブルに主キーは1つだけという制限があります。

 

さて、まず商品購入履歴テーブルを見てみましょう。

 

図:注文IDが主キーの商品購入履歴テーブル

 

このテーブルでは注文IDが主キーになります。

注文IDによって、その他の注文日や顧客ID、顧客氏名、顧客住所が解ります。つまり、このテーブルは既に第2段階の正規化が済んでいると言えます。

次に商品購入詳細テーブルを見てみましょう。

 

図:注文IDと商品IDが主キーの商品購入詳細テーブル

 

注文IDだけを主キーにしてしまうと、注文ID. 97490や注文ID. 97493で重複が発生してしまいます。注文IDと商品IDの2列を主キーにすれば解消しますから、この2列が主キーになりそうです。

この2列で、残りの商品名や値段、個数が解ります。

ただし、商品名と値段は商品IDだけで一意に特定できるものです。もう1列の主キーである注文IDは不要です。

ここでルールと実際に矛盾が生じてしまいます。正規化のルールに準拠するために、商品購入詳細テーブルを商品購入詳細テーブルと商品テーブルに分割します。

 

図:第2正規化により2つのテーブルに分かれる

 

こうすれば、主キーのみで主キー以外の列の値を一意に識別できます。

 

ちなみに、商品購入詳細テーブルや商品購入履歴テーブルは日々の業務で都度処理が走るごとに増減するため、一般的にはトランザクションテーブルと呼ばれます。

一方で商品テーブルは業務の基幹データにあたり、トランザクションテーブルほど頻繁に更新されることも無いため、一般的にはマスタテーブルと呼ばれます。

一般的にはトランザクションテーブルとマスタテーブルを一緒に管理することは無いと言われています。頻繁に更新するデータと、あまり更新しないデータは、同居させないほうが良いからです。「キレイなデータ」の3条件にもつながる話です。

第3正規化:何を扱うデータかはっきりさせる

最後に、テーブルの役割を明確にさせます。概念設計で各データを役割に応じて枠線で囲ったのと同じことをやります(ルールはこちらの方が厳密です)。

これが第三の正規化です。「主キーによってのみ、主キー以外のデータ列名が決まること」を目的に、テーブルにまとめられた「データ列名」をさらにさらに分析しやすい形に整えます。

つまり、主キーを見れば、何を扱っているか解るようにします。言い換えると主キーを除くすべてのデータ列名は、主キーに紐付くようにテーブルをまとめる必要があります。

 

さて、まず商品購入履歴テーブルを見てみましょう。

注文IDが主キーとなり、このテーブルは注文情報を扱っていることがわかります。ただし、顧客名や住所は注文IDによって決まるのではなく、顧客IDによって決まるはずです。

 

図:顧客関連のデータ列名は主キーによって決まらない

 

顧客IDに紐付くデータは、注文IDが主キーのテーブルに持たせる必要はありません。他のテーブルで持たせるのが適切ですから、顧客テーブルと商品購入履歴テーブルに分割します。

 

図:第3正規化により2つのテーブルに分かれる

 

注文IDが扱っているデータ、顧客IDが扱っているデータが明確になり、かなりすっきりしました。

商品テーブルと購入詳細テーブルはすでに主キーのみが他の列のデータを決めているので、正規化されていることがわかります。

 

これで正規化は完成です。

最初は1つのテーブルでしたが、最終的には4つのテーブルに分かれました(少し意図的だった部分もありますが…)。

それぞれ、整理されていて、初めて見ても何を表しているか直ぐに解るテーブルです。抜け落ちさえ気をつければ、「キレイなデータ」の3条件が揃った分析しやすいデータに仕上がります。

まとめ

概念設計、正規化というテクニックを使って、「キレイなデータ」の作り方を明らかにすることができました。

ちなみに、今回紹介した方法はRDBMSの考え方を前提にしていて、hadoop等でテキストマイニングするためのデータ準備には向いていない部分があると思います。ご了承ください。

 

少しシステム寄りな見方が多かったですが、このようにデータを整理することで、分析しやすい形になることが解りました。

膨大なエクセルを前にしていきなり分析するのではなく、このように順番に解きほぐすことで、データは「キレイ」になっていきます

 

この記事のように、マーケティングメトリックス研究所では、分析だけでなく、
そのための準備に関するアドバイスも請け負っています。
ご興味のある方は是非、お問い合わせください。