データモデリングとは、システムで扱うデータの種類や項目、データ同士の関係を整理し、データの設計図であるデータモデルを作る作業です。設計図がないままシステムを作ると、同じ情報が複数の場所に登録されたり、必要なデータを後から取り出せなかったりと、開発後の手戻りや分析のしにくさにつながりかねません。
本記事では、データモデリングの意味や基本要素、利用目的ごとのモデルの違い、設計から運用までの流れ、データモデルを形骸化させないポイントまでを、システム開発やデータ基盤の整備を担当する方に向けて解説します。自社のデータ設計を見直す際の参考にしてください。
データモデリングとは、業務やシステムで扱うデータの種類、項目、相互の関係を整理し、図などの形で表したデータの設計図を作る作業を指します。
データモデルは、抽象度に応じて次の3つの段階に分けて作るのが一般的です。
混同されやすい言葉に、データアーキテクチャとデータベース設計があります。データアーキテクチャは、組織全体でデータをどう集め、保存し、活用するかを定める全体設計で、データモデリングはその中で個々のデータの定義と関係を具体化する役割を担います。一方、データベース設計は、データモデルをもとに特定のデータベースへ実装する形を決める作業で、物理データモデルの作成と重なる部分が大きい工程です。
データモデルは、ER図と呼ばれる図で表されることが多く、いくつかの基本要素の組み合わせでできています。ここでは、データモデル図を読み解くために押さえておきたい4つの要素を解説します。
エンティティとは、顧客、商品、受注など、データとして管理する対象のまとまりです。データモデル図では四角形で表され、最終的にはデータベースのテーブルにあたることが多い要素です。
エンティティには、顧客や商品のように実体があるものだけでなく、受注や出荷、支払いのように業務上の出来事も含まれます。たとえば通販の業務であれば、「顧客」「商品」「受注」「受注明細」「配送」などがエンティティの例です。
どこまでを1つのエンティティとして扱うかは、業務での使われ方によって変わります。そのため、エンティティを決める際は、業務の担当者と認識をすり合わせておきましょう。
属性とは、顧客名や商品価格など、エンティティがもつ個々の項目です。エンティティをテーブルとすれば、属性はその列にあたり、1件ごとのデータがどのような情報をもつかを表します。
「顧客」エンティティであれば、顧客番号、氏名、住所、電話番号、登録日などが属性になります。属性ごとに、文字か数値か日付かといったデータの型や、桁数もあわせて定義しておくのが基本です。
また、属性の中から、1件のデータを一意に特定するための項目を主キーとして決めておきます。顧客番号のように重複しない値を主キーにしておけば、同姓同名の顧客も正しく区別できます。
リレーションシップとは、顧客と受注など、エンティティ同士の関係を表す要素です。データモデル図では、エンティティをつなぐ線で示されます。
リレーションシップでは、関係の有無だけでなく、件数の対応も定義します。たとえば「1人の顧客は複数の受注をもつが、1件の受注は1人の顧客にしか属さない」という関係は1対多、「1件の受注には複数の商品が含まれ、1つの商品も複数の受注に含まれる」という関係は多対多です。
多対多の関係は、そのままではデータベースで扱いにくいため、「受注明細」のような中間のエンティティを置いて1対多の関係に分解するのが一般的です。関係を正しく定義しておくことで、データを組み合わせて集計する際の誤りも防げます。
制約・ルールは、必須項目や重複の可否など、データが満たすべき条件を定める要素です。項目や関係を決めても、どのような値を許すかが決まっていなければ、誤ったデータが登録されてしまうためです。
代表的な制約には、空欄を許さない必須項目、同じ値の登録を認めない一意性、別のエンティティに存在する値だけを受け付ける参照の制約などがあります。たとえば「受注の顧客番号は、顧客エンティティに登録済みの番号でなければならない」と決めておけば、存在しない顧客への受注は登録できません。
ほかにも、数量は0以上、ステータスは決められた値のみといった業務上のルールもあわせて定義しておきましょう。
データモデリングでは、データを何に使うかによって適した構造が変わります。ここでは、業務システム、DWH・BI、AI・機械学習という3つの利用目的ごとに、モデリングの考え方を紹介します。
業務システム向けのモデリングでは、データの登録や更新を正確におこなえることを重視します。受注や在庫の管理など、日々の処理で同じデータが何度も更新されるため、矛盾のない状態を保つ必要があるためです。
そのため、業務システムでは正規化と呼ばれる手法で、データの重複をできるだけ減らします。たとえば、受注データの中に顧客の住所を毎回書き込むのではなく、住所は顧客エンティティだけにもたせ、受注からは顧客番号で参照する形にします。住所が変わっても顧客エンティティを1か所直すだけで済み、受注ごとに住所が食い違うこともありません。
一方で、正規化を進めるほどテーブルの数が増え、集計の際に多くのテーブルを結合する必要が出てきます。分析の用途では、別の考え方でモデルを作るのが一般的です。
DWH・BI向けのモデリングでは、集計や分析の速さと分かりやすさを重視します。大量の過去データを、さまざまな切り口で繰り返し集計するためです。
代表的な手法が、スタースキーマです。売上の金額や数量といった分析の対象となる数値をまとめたファクトテーブルを中心に置き、日付、商品、店舗、顧客といった分析の切り口をまとめたディメンションテーブルを周囲に配置します。図にすると星の形に見えることが、スタースキーマという名前の由来です。
スタースキーマでは、正規化をあえて弱めてテーブルの数を抑えるため、BIツールで「月別・店舗別の売上」のような集計を速く、分かりやすく実行できます。DWHにデータを集める流れは、データパイプラインとは？仕組みや種類、ETLとの違いと構築のポイントを解説もあわせてご覧ください。
AI・機械学習向けのモデリングでは、学習や予測に必要なデータを継続的に取り出せる構造を設計します。AIのモデルは、過去の傾向を学ぶための履歴データと、予測に使う最新のデータの両方を必要とするためです。
たとえば需要予測であれば、日別・商品別の販売実績に、天候や販促の有無などを組み合わせたデータを用意します。予測に使う入力項目は特徴量と呼ばれ、「直近7日間の平均販売数」のように加工した値も特徴量の1つです。特徴量を毎回作り直さずに済むよう、計算方法と保存先をモデルとして定義しておくと、学習と予測で同じ値を使えるようになります。
設備の異常検知のようにリアルタイムのデータを扱う場合は、センサーから届くデータを時刻とともに蓄積できる構造も必要です。過去の値を上書きせずに残す設計にしておけば、あとから学習データとして使い直すこともできます。
データモデリングは、要件の整理からモデルの作成、関係者の確認までを段階的に進めることで、実際に使われる設計図になります。ここでは、運用に至るまでの5つのステップを解説します。
データモデリングを始める際は、まず目的と対象範囲を決めましょう。範囲を決めずに始めると、関係する業務やシステムが次々に広がり、いつまでもモデルが完成しないためです。
たとえば「受注から出荷までの業務システムを刷新する」のか、「販売データを分析するための基盤を作る」のかによって、対象となる業務も、作るべきモデルの形も変わります。対象とする業務、システム、部門を書き出し、今回は扱わない範囲もあわせて明記しておきます。
範囲をはっきりさせておけば、関係者を集める際に誰の協力が必要かも判断しやすくなるはずです。
次に、業務から必要なデータを洗い出しましょう。データモデルは業務の実態を表すものなので、業務で実際に扱われている情報を把握しなければ正しく作れないためです。
洗い出しには、業務マニュアルや帳票、画面、既存システムのテーブル定義などの資料を使います。資料だけでは分からない例外の処理や、現場だけで使われている管理表は、担当者へのヒアリングで確認するのが確実です。集めた情報から、管理の対象となる名詞をエンティティの候補に、その対象がもつ項目を属性の候補として抽出していきます。
同じものが部署によって別の名前で呼ばれていることも多いため、用語の意味もこの段階で確かめておきましょう。
エンティティと属性がそろったら、データ同士の関係とルールを定めましょう。関係とルールがあいまいなままでは、データを正しく結びつけられず、誤ったデータの登録も防げないためです。
各エンティティの主キーを決め、どのエンティティとどのような件数の関係でつながるかを整理します。あわせて、必須項目、重複を認めない項目、値の範囲といった制約も定義します。「1件の受注に複数回の出荷はあり得るか」のように、業務によって答えが変わる点は、担当者に確認してから決めることが重要です。
判断の理由も記録に残しておくと、後からモデルを見直す際に役立ちます。
関係とルールが決まったら、目的に適したデータモデルを作成しましょう。同じ業務のデータでも、業務処理に使うのか分析に使うのかによって、最適な構造が異なるためです。
業務システムであれば正規化を進めて重複の少ない構造に、DWHやBIであればスタースキーマのように集計しやすい構造に落とし込みます。そのうえで、使用するデータベースに合わせてテーブル名、データ型、インデックスなどを決め、物理データモデルまで具体化していきます。
作成したモデルは、ER図として図にまとめるとともに、各項目の意味や型を一覧にした定義書も用意しておきましょう。
データモデルができたら、関係者によるレビューをおこないましょう。作成者だけで確認すると、業務の実態との認識違いや、データの不足に気づきにくいためです。
レビューには、業務の内容を知る担当者と、システムを実装する開発者の両方に参加してもらいます。業務担当者には「この項目で必要な情報を表せるか」「例外のケースに対応できるか」を、開発者には「実装や性能の面で問題がないか」を確認してもらうと、立場の違いによる見落としを減らせます。
指摘を反映したモデルは、関係者の合意を得てから開発や基盤の構築に進みましょう。
ブライセンのデータエンジニアリングサービスは、データの意味と関係を整理するデータ設計から、設計にもとづく基盤の構築、業務で使える形でのデータ提供までを支援するサービスです。
弊社は、データの収集・蓄積にとどまらず、目的起点のデータ設計から基盤構築、運用・改善までを一貫して支援しています。日本とベトナムの開発体制により品質とコストの両立を図り、自動車業界をはじめ、製造業やプラント分野の企業様を支えてきた実績があります。
システムごとに定義がばらばらで全体の設計図を描けていない、分析やAIに使えるデータ構造を一から整えたいという方は、お気軽にご相談ください。
データモデリングは、データの種類や項目、相互の関係を整理し、データの設計図を作る作業です。データモデルは、エンティティ、属性、リレーションシップ、制約・ルールという基本要素で構成され、概念・論理・物理の段階を経て具体化していきます。
最適なモデルの形は、利用目的によって異なります。業務システムでは正規化で正確な更新を、DWHやBIではスタースキーマで集計のしやすさを、AIでは履歴や特徴量を継続的に扱える構造を重視しましょう。
データモデルは、作って終わりではなく、システムの変更にあわせて更新し続けることで価値を保てます。データの意味と関係を明確にした設計図を、開発や分析の共通言語として育てていきましょう。
