なんで今更データモデリング？
昨今、データの重要性が非常に上がってきている実情があります。IoTや機械学習、深層学習、AIに代表されるように、データをビジネスに活用しようとする動きが加速しています。そんな中で、データをどう取り扱うかを考える必要があります。
特に、私の会社（某大手ITベンダー子会社）では、新人に限らず、中堅クラスのメンバーにまで、データモデリング勉強会を実施しています。
今一度、データモデリングとは何かを改めて整理しなおし、何か役に立つ情報を公開できればと考えています。
データモデリングとは
まず、はじめにデータモデリングとは何なのでしょうか？
平たく言えば、「システムに必要なデータ項目を整理し可視化する活動」となります。
では、その目的は何でしょうか？
なぜデータモデリングが必要なのか
その前に、ITシステムにおいてのコンポーネントの役割を考えてみましょう。
例えば、ネットワークにはどんな役割がありますか？データという視点で、考えると「データを転送すること」となります。
また、APサーバーであれば、「データの処理加工やロジックを通す」ということにつきます。
結局、主要なコンポーネントのほとんどがデータを何らかの形で扱うことになるわけです。（運用系サーバーなどになると少し視点が違いますが）
話を戻すと、データモデリングの目的とは「可視化することで、アプリケーション開発およびインフラ構築において共通認識を取れるようにして、システム開発を円滑に進めるため」と言えるでしょう。
つまり、アプリにもインフラに影響し、システムの中核にあると言っても過言ではありません。極論、データの質がシステムの品質に影響する場面もあるでしょう。
実際、冷静に考えてみると、データの存在しないITシステムは無いはずです。データを理解する活動は必須と言うべきことなのです。
データモデリングの用語整理と実装との対応関係
| 用語 | 意味 |
|:-----------|------------|:------------:|
| 属性（Attribute） | データ項目 | This |
| 実体（Entity） | データ項目を意味のある集合にまとめたもの | あああ |
| キー（Primary Key） | エンティティの中で、レコードを一意に定めるもの | ううう |
| 関係（Relation） | エンティティ間の数の関係を線で表現したもの | ううう |
データモデラーが作る成果物
・ER図
・DDL（任意のView含む）
・コード値一覧
・データドメイン管理表
・命名標準
各フェーズにおけるデータモデル
標準的には概念、論理、物理の３段階のデータモデルを経て、開発が進みます。
通常は、概念⇒論理⇒物理と、前段のモデルをベースに作り上げていくことになります。
概念データモデル:
システム対象で登場するであろうエンティティと思いつく限りのデータ項目、PKやリレーションが洗い出せて、全体像が見えて、議論することができるレベルのデータモデルです。
抽象度が高いもので構いません。
例えば、以下を整理しておくと十分でしょう。（論理データモデルの中でやっても問題はありません）
・エンティティ名
・各エンティティのキー候補
・各エンティティの意味の整理
・エンティティを何らかのグルーピングしたもの
・各エンティティがマスタ系かトランザクション系かの選別
論理データモデル:
業務をデータの観点で整理したデータモデルです。全てのエンティティおよびデータ項目、PK、リレーションが洗い出せた状態にあることをゴールとしたいです。
ビジネス的な正しさが担保されていることが必要です。
ポイントを整理すると、以下を論理データモデルで担保できるようにしておくと良いでしょう。
・データの正規化と1fact-1placeの原則
・ビジネス的な表現ができていること（想定しているアプリのロジックが動かせること）
・データ型の確定
・ビジネスキーとサロゲートキー（ビジネス的に無意味な一意のIDデータ）の利用選定
・サンプルデータの準備
物理データモデル:
論理データモデルでの整合性を失わせず、実装の観点で整理しなおしたデータモデルです。論理モデルの構造から大きく変わることが多々あります。例えば、SQLでのjoinが多発しパフォーマンスに影響するために、リレーションを見直すことで、エンティティを統合することがあります。他には、アプリの判定ロジックを簡素にするために、フラグデータなどを追加しても良いです。
データモデル上には表れないですが、RDBであれば索引を準備することもあります。そのあたりも検討しましょう。DBインフラ担当とは、ストレージ上の配置なんかも決めたりします。
全体的にはデータ量というのも見ておくと良いでしょう。
物理データモデルで大切なことは、パフォーマンスの劣化を抑え、アプリが使いやすいことを重視して作っていくことになります。
各フェーズでの作成物
まとめると以下のようなることが理想的とされています。
| 種類 | フェーズ | 作成物 |
|---|---|---|
| 概念 | 要件定義 | 概念データモデル図、エンティティ一覧 |
| 論理 | 概要設計 | ER図、データドメイン管理表、命名標準 |
| 物理 | 詳細設計 | ER図、DDL、コード値一覧 |
ただし、これはあくまで理想であり、現実にはこんなに正しいステップを踏めることは稀です。
プロジェクトでは、論理データモデルを作っても、レビューするのが面倒だから、早速物理データモデルから作ってとか、普通に言われます。
大切なことは上記のステップを踏むことよりは、今自分がどのデータモデルを作っているか、そして、前の種類のモデルが無いことで不測の事態が起こりえないか、ということを考えることです。特に、論理データモデル無しで、物理データモデルを作っているときに、データの変更があった場合に、どうやってビジネス的な正しさを担保するか、ということを考えておく必要があります。（データの規模がそれほど大きくないなら、影響は小さいでしょう）
データモデリングのアプローチ
大きくは、トップダウンアプローチと、ボトムアップアプローチと呼ばれる２種類があります。
以下のアプローチの違いを説明します。
アプローチの種類
トップダウンアプローチ
ゼロベースでデータモデルを構築するアプローチです。要件に合わせてデータ項目なども必要に応じて作り出しながら進めます。
新規事業におけるシステムを考えるときに取ることが一般的です。
ボトムアップアプローチ
一方で、既存のインプットからデータモデルを構築するアプローチです。既存のシステムがあれば、そのデータモデルが使えます。また、帳票や画面などの実物のあるインプットを使ってデータモデルを考えていきます。
システム更改やシステム統合などの場合に、こちらを取ることが一般的です。
実際には
IoTなどのシステムのようなものを作るときには、両方のハイブリッド型のようになることが一般的です。IoTのデータについては、取得できるものが判明していることが多いので、ここはボトムアップとして取り組み、それ以外のシステムを運用するために必要なデータ、例えば、分析モデルを使うのであれば、その管理を行うようなデータや、履歴などは新規の追加のため、トップダウンとして考えることになります。
常に、どちらかひとつの方法だけになるとは限らないということです。
次回への予告
今回は、データモデラーがどうプロジェクトの中でデータモデリングをしていくことで考えるべき基礎的なことに絞りました。
次回は、ER図の描き方のプロセスを整理していきます。