データの正規化とは？ | データ活用とBI導入の下準備

前回のおさらいと今回の内容

データ活用について、前回はデータ活用の事例と分析に必要なデータについてお話しました。受注パイプライン分析や購買情報トレンド分析など、会社の売上や利益に貢献するとても重要なものになります。

そんなに効果が出るなら今すぐにでもはじめたい！と飛びつく経営者は多いでしょう。
飛びついたはいいけど、分析するためのデータがあまりにも整備されておらず、それを収集する手順もこれから考えないといけないという状況のため、データ活用を挫折する経営者もまた多いのではないでしょうか。

どうもITに関するトレンドワードは、それさえ入れれば万事解決できる魔法のように捉えられる節が未だにあるような気がしています。
売るほうもメディアもそういう宣伝をするから、いつまでたっても真のITの恩恵を受けられず、毎回騙された感だけが残っていきIT投資に消極的になっていくのではないでしょうか。

特にセルフBIと呼ばれるTableauなどを使いこなそうと思うと、データ整備は必須事項です。対象がデータベースソフトでなくExcelであったとしても、分析可能な形になっていれば活用することは容易になります。

今回はデータを分析可能な形にするための知識、「データの正規化」についてお話していきたいと思います。

データの正規化について

データベースを名乗るために必要なルール

正規化とは簡単に言うと「データの重複をなくすためのルール」です。
見積作成のための品目マスタと作成した見積と注文を管理するデータを例にします。

このデータは正規化されていません。
正規化されていない場合、どのような問題があるでしょうか。

月次の注文情報の集計や未注文／注文済みの区分ごとの集計、例では全て同じ商品種別（ノートパソコン）ですが、複数種別になった時に集計すべき種別がどれだけあるかわかりにくい等、他にも色々な問題があります。

正規化されていないデータは、メンテナンスやデータ追加のために複数個所の変更が発生するため、修正誤りや修正漏れが発生しやすくなります。また検索・集計の方法毎にデータを並べ替えたり、他のデータと結合したりと手間もかかりますし、前回の集計情報と同じ集計方法にならなくなる恐れもあります。

データベースはデータを効率的に取り扱える状態で保存しておくことが基本です。ExcelだろうがAccessだろうがSQLServerだろうがOracleだろうが、「データベース」を名乗るのであれば正規化は必須条件になります。
「Excelは表計算ソフトだ」という突っ込みは許容しますが、実運用としてExcelベースで管理されたデータも多数あるのは事実ですし、BIツールすらExcelをデータソースとして読み込むことを想定してものもあるため、ここではExcelも対象とします。

第１正規化：項目の重複・繰り返しを排除する

正規化の第一歩は項目の重複・繰り返しの排除です。
最初の例でいくと、商品１、商品２…のような繰り返し項目があります。
これを全て「商品」というカテゴリで並び替えてしまいましょう。

ここで各表のデータがそれぞれ一意になるように主キー（PrimaryKey＝PK）を設定します。主キーが同じデータは登録することができないルールです。これで誤って複数回データが登録されることを防ぎます。

第２正規化：主キーについて部分関数従属する項目を分離する

「部分関数従属」とは何かというと、「一方が決まると他方が自動的に決定する関係」です。商品がわかれば単価が決まるのだから、単価は１か所で持てばよい、という考え方です。何故かというと、単価を複数の場所で管理すると、それぞれに記載する内容に齟齬が生じる可能性があり、データの管理が複雑になるからです。

先ほどの例で言えば注文情報について「品名」がわかれば「単価」は品目マスタを見ればわかります。つまり単価は品目マスタだけに持てばいいということになります。
ところで注文情報にあるのは「品名」になっていますが、これは品目マスタの主キーではありません。品目マスタの品名が変わった時に自動的に連動してほしいので、注文情報で管理するのは「品名」ではなく「商品コード」にしておきます。

また、よく見ると注文情報の「注文番号」が同じ場合、「発注先」「見積作成日」「発注日」は全て同じになります。
同じ「注文番号」の行のこれらの情報をいちいち繰り返しで記載するのはよろしくありません。そこでこういう管理に変えてみることにします。

注文情報は「どの発注元にいつ見積を提示して、いつ注文を受けたのか」だけを管理して、「注文情報詳細」に「内訳はどの商品を何個なのか」という管理にしました。

よく見る形として「注文情報詳細」に「注文番号枝番」のような明細番号を設定する場合があります。正規化の考え方を説明する上では同一商品番号を別行として管理できてしまう可能性があるのであえて作成していません。

システム画面を利用してこれらのデータを作成する場合、システム画面でのデータ登録時の論理チェックとして同一商品番号の別行をエラーとするようなチェックを行うことで、データ上の主キーは「注文番号」と「注文番号枝番」とすることが可能です。

このチェックが無いと「注文番号」「注文番号枝番」「商品コード」の３項目で主キーを作成してしまうと、注文番号枝番が異なるけど商品コードが同一という行の作成を許してしまうことになります。
つまり同じ商品の情報が何件も分かれて登録されてしまうことになり、総量として何件なのかがわかりにくくなってしまう恐れがあるのです。

また、「注文情報詳細」の「注文番号」「商品コード」はそれぞれ「注文情報」「品目マスタ」の主キーと連動しています。これらの表に存在しないデータを登録してはいけません。こういった制約を外部キー（ForeignKey＝FK）といいます。

第３正規化：主キー以外で部分関数従属する項目を分離する

第２正規化と同じようなことを主キー以外でも考えてみましょうということです。
今回の例のデータではわかりにくいですが、「商品種別名」や「メーカー名」もコード化して他で別で管理することができます。複数の種別の商品を取り扱う場合や、同一メーカーの複数商品を取り扱う場合、このような管理が有効になります。

マスタが変更になることを考慮した場合：履歴管理

正規化したが故に発生する問題として、「マスタが変更になった場合に、過去データの情報が変更されてしまう」ということです。

商品単価が未来永劫同じということはまずありえません。第３正規化までされた状態のデータで見た場合、単価を直接変更してしまうと、変更前に行った注文の金額が変わってしまいます。「注文情報」「注文情報詳細」に金額情報を持たせたとしても、品名マスタから再計算した場合に金額が合わず、データ全体といての整合性がとれなくなってしまいます。

そこでマスタが履歴を持てるようにしておきます。
見積日時点、あるいは注文日時点の品目マスタを取得することで、その時点での単価を取得することができます。

中締め

今回はデータ活用の前提としてのデータ整備を行うために必要なデータ正規化についてお話しました。

第３正規化は可能であればでいいとしても、第１正規化、第２正規化は必須条件といっていいと思います。
正規化が完全に行われていなくてもデータ活用のための分析をある程度行うことはできるかもしれませんが、継続的なデータ分析のためには継続的なデータ収集が必要です。
そしてデータ収集を継続的に行うためには、データの追加・更新が誤りなく行える仕組みを整備しておく必要があります。

今回までの話は「データを活用してできること」→「活用できるようなデータの管理方法」と進んできました。次回は「まずはデータを集めること」の話をしていきます。
収集→整理→分析の流れの逆から説明しているのは、必要性がわからないとデータ収集が進まないからです。
何に使うかわからないけどとりあえずデータを入れてもらう、というのは至難の業ですし、それで集まったデータが正しい分析に活用できる品質のものかというと難しいと言わざるを得ません。

その辺りを次回詳しくお話していきたいと思います。