〈開発者ブログ 連載〉Vol.7
~ データの可視化・分析について ~
開発者ブログ 一覧
- Vol.01 データの可視化は○○○○
- Vol.02 その分析に○○は含まれるか - メジャー編 -
- Vol.03 その分析に○○は含まれるか② - ディメンション編 -
- Vol.04 データの品質について考える
- Vol.05 "Analytics"から見たAWS re:Invent
- Vol.06 データ利活用におけるデータガバナンス
- Vol.07 データを分類する
- Vol.08 データレイヤーと内製化
- Vol.09 データプラットフォームとDX推進
- Vol.10 データを取り巻く言葉や概念を理解するために
- Vol.11 データを取り巻く言葉や概念 - Modern Data Stack -
- Vol.12 Single Source of Truth
- Vol.13 わくわくを忘れずに
- Vol.14 2時間検証:データ人材の不足は生成AIのエンパワーで補えるのか

データを分類する
データ分析・可視化に関する記事の7回目になります。
今回、そして次回は"データ"そのものにフォーカスした記事を書こうと思います。
一口にデータと言ってもその内容は様々ですね。
たとえばデータの構造に着目すると構造化データ、非構造化データという区分けがあります。
データの形式でいうとcsvやjsonなどが代表的で、データエンジニアリングではparquetやavroなどもよく使われています。
データの内容についてはどうでしょうか。
データが持つビジネス上での意味づけはいったん脇においておいて、データエンジニアリングやデータマネジメントでデータについてどのような整理がなされているかについてまとめてみようと思いました。
今回は主にデータマネジメントの側面から、DMBOK(Data Management Body Of Knowledge)の第10章を参考にデータの分類について書いていきます。
次回はデータエンジニアリングの側面からデータのレイヤリングについて書く予定です。
マスターデータとトランザクションデータ
おそらく誰にとっても、もっとも親しみがあり伝統的な分類がマスターデータとトランザクションデータだと思います。
(ドキュメントでしか見たことありませんが)ディメンションデータとファクトデータと表現することもあります
定義については検索すれば沢山でてきますので、ここでの説明は省きます。
エンタープライズ向けのシステム開発においてはマスターかトランザクションかという観点でデータ(というか多くの場合はRDBのテーブル)を分類するケースがほとんどかなと思います。<
データエンジニアリングやデータマネジメントの領域においてはもう少し細かく分類していく必要があります。
6層のデータ分類法
マルコム・チズルムという人が6層のデータ分類法を定義しました。
それが下表の内容です。
1 | 参照データ | コードとそのコードを表す意味を持ったテーブルなど |
2 | エンタープライズ構造データ | 勘定科目表など業務活動報告に使われる |
3 | トランザクション構造データ | 顧客、製品、ベンダーなどトランザクション発生時に存在している必要がある |
4 | トランザクション業務データ | トランザクションの詳細を記録する |
5 | トランザクション監査データ | トランザクションの状態を記述する |
6 | メタデータ | データを記述する |
チズルムの定義では、1から3はマスターデータに該当し、4と5がトランザクションデータに該当します。
先にトランザクションデータについて補足します。
4のトランザクション業務データというのが一般的にイメージするトランザクションデータにあたります。
5のトランザクション業務データはトランザクションのライフサイクルを追跡するデータで、サーバーログなども含まれます。
続いて、マスターデータについてです。
まず2のエンタープライズ構造データと3のトランザクション構造データについてですが、これらを明白に区別する意義というのは個人的に見出せておらず、DMBOKにおいてもそこに対する言及はされていません。
(分類として気持ちいいという感覚は理解できます)
一方で、1の参照データと2,3を区別することには明確に意味があります。
- ※
チズルムの定義では1をマスターデータに含めていますが、DMBOKでは2,3をマスターデータと呼んでいます。
- ※
当記事も以降は1を参照データ、2,3をマスターデータとして記述します
参照データとマスターデータ
MDM (Master Data Management)によってマスターデータ資産の一貫性を実現しようとした場合、マスターデータと参照データではデータ管理の焦点が異なってきます。
DMBOKには以下がデータ管理の焦点として記述されています。
- 参照データは正確で最新な値のリスト全体に組織がアクセスできるようにすること
- マスターデータは重要なビジネスエンティティに関する最も正確で最新なデータをシステム間で一貫して使用できるようにすること
一見すると何が違うのか判別しづらいですね。
参照データというのは、しばしば区分値マスターとか設定マスターとかそういったテーブルで管理されるものです。
区分1はxx、2はxxとかですね。これらは頻繁に変更されることはありません。
ですので、正確で最新なデータを共有することが目的になります。
一方で2,3のマスターデータというのは変更かかることが前提で、実務上そこには日付の概念も関わってきます。
組織変更などを思い浮かべれば、マスターデータには一貫性が必要というのは理解ができると思います。
4月1日時点で私の所属はどこで、その上位組織がどこかというのは複数のデータを一貫性を持って掛け合わせないとわかりません。一貫性というところがポイントになってきます。
これはDMBOKにおいては「エンティティの解決」という言葉で表現されいます。
従ってMDMの観点で見ると、マスターデータを対象にエンティティの解決をした一貫性のあるデータをシステム間で使用できるようにする、というのがメインの焦点になってきます。
一方で、メタデータの管理という側面になるとメインのターゲットは参照データになってくるということも同時に覚えておくと良いかもしれません。
参照データのコードの意味合いを示すというところ以外に、たとえばどのデータに準拠しているかなどの情報も管理しておきたいためです。
たとえば都道府県コードと都道府県名という参照データに対して、これは「JIS X 0401に準拠しています」というメタデータも管理するようなイメージです。
データドリブンとデータ
データドリブン組織を目指した取り組みは、トランザクションデータに重点を置いてきました。
一方でどれだけトランザクションデータをどれだけ活用できるかは、参照データとマスターデータの品質に大きく依存すると言われています。
MDMという枠組みが登場し、DMBOKがまるまる1章を参照データとマスターデータに割いていることからもその重要性が見て取れますね。
データドリブン組織というと、誰もがデータに親しんだ状態、つまりデータの民主化というキーワードがあげられます。
次回はデータのレイヤリングについて触れるとともに、データの民主化が思うように進まない要因についても考えていきたいと思います。
最後まで読んでいただきありがとうございました。
執筆者プロフィール

高坂 亮多
- ・2007年 新卒で株式会社セゾンテクノロジーに入社。
- ・所属:DI本部DP統括部 DP開発1部 副部長 および DP開発1課 課長 兼務
- (所属は掲載時のものです)
- ・好きなこと:登山やキャンプなど アウトドアアクティビティ
- ~ BI基盤(分析基盤)におけるアーキテクトとして日々業務にあたっています ~
開発者ブログ 一覧
- Vol.01 データの可視化は○○○○
- Vol.02 その分析に○○は含まれるか - メジャー編 -
- Vol.03 その分析に○○は含まれるか② - ディメンション編 -
- Vol.04 データの品質について考える
- Vol.05 "Analytics"から見たAWS re:Invent
- Vol.06 データ利活用におけるデータガバナンス
- Vol.07 データを分類する
- Vol.08 データレイヤーと内製化
- Vol.09 データプラットフォームとDX推進
- Vol.10 データを取り巻く言葉や概念を理解するために
- Vol.11 データを取り巻く言葉や概念 - Modern Data Stack -
- Vol.12 Single Source of Truth
- Vol.13 わくわくを忘れずに
- Vol.14 2時間検証:データ人材の不足は生成AIのエンパワーで補えるのか