COLUMN

データベースを扱うための基礎の基礎

column1

最近では、DB(データベース)業界のエンジニアだけにとどまらず、一般のOfficeユーザーの方を中心に、Power BIを業務やビジネスデータの分析に使う方が増えています。

それに伴い、様々な社内の「データ」を集めてPower BIで統合し、使うことが増えてきます。扱うデータの種類が増えることで、今までのExcelでの集計と考え方が異なってくるため、Power BIでの分析を改良したいと思っても、「どうやってデータやチャートを作ればいいのか…」と悩んでしまうこともあるようです。

今回は、表計算とは少し違う、データベースの考え方について、基礎的なところをおさらいしてみたいと思います。

 

同じ売上データでも構造が間違っていると分析できない

Excelは、様々なデータを作成することができ、関数やPivotテーブルなどを使うことで集計・分析も可能です。しかし根本的に違うのは、Excelでは「今必要な集計済みのデータ」を扱うケースが多いこと。BIツールでは、「データベースなどから生のデータを直接取り込んで利用する」ケースが多いことです。その違いは、自由度や掘り下げの可能性にあります。

ここでは例として、ある店舗の担当者別売上の集計表を見てみましょう(図1)。社内でよく見かける形式のExcelデータですね。

column_0329_01
図1:担当者別の売上

このデータは、日ごとの売上高を担当者別に表していることが分かります。しかし、これでは詳細の分析はできません。どんなところに問題があるのでしょうか? 

お気づきの方も多いと思いますが、図1からは「何を」「どの時間帯に」売ったのかなどの情報が分かりませんよね。
2行目から、「山田さんがたくさん売った」という結果は分かりますが、その理由を探ることはできません。その理由を知るためには、このデータの1段階前のデータ、つまり売上の内訳が分かるデータが必要です。一般的には次のようなデータとなります(図2)。

column_0329_02
図2:売上のレコード

図2のデータは、北川さん、山田さんが製品を販売するたびに記録を残したデータです。一般的にレジなどでは販売の都度に情報を記録しますから、事実を最小単位まで記録したデータだと言えます。

図2のデータを図1のデータと比較すると「なんだ、担当者の売上総額がわからない。長いシートを使って集計しなくてはならないのか…。」と思われる方もいるでしょう。

その通りです。そこがポイントです。
詳細のデータを保持したまま、必要な情報を都度ピックアップして集計するのがデータベースを使った集計の鉄則です。集計後の合計だけ使って元データを捨ててしまうと、「山田さんは何を売ったのだろう」「どの時間帯の売上が多いのだろう」「バッテリーは、複数フロアで扱っているが、何階で一番売れるのだろう」といった疑問が発生したときに、データを掘り下げて分析することができません。この掘り下げがいわゆる「ドリルダウン」です。ドリルダウンは、詳細情報を保持したままのデータであるからこそ、行うことができるのです。

ここで覚えておきたいデータベースの超基礎の1つ目のポイントは、データベースは、1回の出来事が発生するたびに1つずつの項目を実直に記録していった、その記録の集まりである、ということ。図2でいうと、「誰が何時に何をいくらで、どの階で売ったか」を1回の売上ごとにすべて記録しています。省略や統合をしてしまわないことも重要です。1回の出来事の記録は1行にまとまっており、この1行のまとまりをデータベースでは1レコードといいます。

 

別の記録を「1行にまとめて」はいけない

では次に、図3の表を見てみましょう。
ある別の店舗での担当者別の売上表です。

column_0329_03
図3:担当者別の売上詳細のわかる表

図1、図2とは少し違います。これなら、北川さんと山田さんがそれぞれ何をいくらで売ったのかが分かりますね。このデータなら、きっとドリルダウンができるはず・・・。

しかし、答えは「NO」なのです。

なぜでしょう。
それは、「売上1件(1回の出来事)を1行(1レコード)にする」というルールに従っていないからです。
もう一度、図2と3を比較してみましょう。「誰が何をいくらで売ったか」という1つの記録は、どのように入力されているでしょうか?

column_0329_04
図4:図2と図3の比較。図3の集計表は、1行のなかに売上金額が複数記載されてしまっている。

図2の表では、1行に1件の売上情報だけが記載されているのに対し、図3の表では、「おすすめ1」「おすすめ2」「その他」の3件の売上情報を1行にまとめてしまったために、「おすすめ2」について分析するとなると、扱いづらいデータになってしまっています。

なぜ、このような違いが起きたのでしょうか?
それは、「人間が見るために作ったか(図3)」「データベースに入れてプログラムが計算するために作ったか(図2)」の違いです。
図3は表としては見やすいかもしれませんが分析の際は、図2の表のようにデータベースとして使用できる明細が記録されたデータを使用するよう意識していきましょう。

図3のデータをプログラムに理解させるためには、おすすめ1の売上だけ集計したいときは、その他の商品はカウントしない、おすすめ2を集計するときは…など、例外が複数できてしまい非効率です。

データベースでのレコード作成時のシンプルなルールは、1件の情報を1行にまとめること。たとえ2件目の情報に類似情報(同じ担当者や同じ日付)があっても1行にまとめずに、次の行に分けるということです。

では図3をデータベースで使いやすい形に直しましょう。図5のようになるはずです。

column_0329_05

図5:データベースで扱いやすい状態の表の形状

この形状なら、行数は増えますが、分析をする際の計算はしやすくなるはずです。

今回のコラムのポイントは、次の2つです。

ポイント1.
データ作成の際は、データを構成する最小単位の情報まで記載することが重要。
⇒ドリルダウンの分析ができる

ポイント2.
1行に含める情報は1つに絞る。
⇒「分析しづらい」「うまく分析できない」といった原因になる。

いかがでしょうか?なるほど!と思っていただけましたか。ExcelではOKなのに、なぜかBIで使えないデータ…にはこんな理由がありました。

 

さてこの続きは、春からの新担当となる横井から紹介していきます。

私の登場するPOWER BI FORUMのコラムは今回で最終回になりますが、今後もPower BIとデータ分析の界隈を広げていくお手伝いをしていきますので、どこかでみなさんとお会いすることもあると思います。

どうぞ、みなさんのビジネスに、Power BIをさらにお役立てください。

kitagawa_2
北川剛(キタガワツヨシ)
日本マイクロソフト株式会社
日本マイクロソフトで Azure を含むサーバー製品を担当するプロダクトマネージャー。 大学時代にインターネットの洗礼を受け、研究室でデータベースを利用したウェブシステムを構築するというきっかけを得たことから、データベースの道に進むことに。現在はデータベースだけではなく、クラウド上のサービス群もカバーするという難題を NIKU を燃料に対応している。