読書メモ: DMBOK2 第5章 データモデリングとデザイン

このポストについて

DMBOK2 を読み進めていくシリーズ。
今回は第5章「データモデリングとデザイン」について。
第4章でデータモデリングについて言及されていたが、ここで詳しく見ていく。

以降、特に注釈のない引用は DMBOK2 第5章からの引用とする。

データモデリングとは

データモデリングとは、データ要件を洗い出し、分析し、取扱スコープを決めるプロセスであり、データ要件を記述し伝えるために、明確に定義されたデータモデルと呼ばれる様式が用いられる。このプロセスは反復的であり、概念、論理、物理モデルが含まれる。

第4章 データアーキテクチャ ではエンタープライズ・データモデルという言葉が登場したが、この第5章ではそのデータモデルがより具体的に解説されている。
データモデルは効果的なデータマネジメントを行うにあたり必要なものとされている。
次のような意義がある。

• データに関する共通語彙を提供する
• 組織のデータや情報システムに関しての明示的な知識を捉え文書化する
• プロジェクトにおいて主なコミュニケーションツールとして使われる
• アプリケーションをカスタマイズ、統合、リプレースする際の出発点となる

データモデルは組織が把握した現状、またはあるべき姿として組織のデータを記述する。
カテゴリー情報、リソース情報、業務イベント情報、詳細取引情報がその対象となる。

データモデルの構成要素

ほとんどのデータモデルはエンティティ、リレーションシップ、属性、ドメインにより構成される。

エンティティ

エンティティとはある組織が情報を収集する対象のこと。
組織が使う名詞。

以下は Marmaid の Entity Relationship Diagrams でエンティティを表現した例。
学校を例にしており、学生、コース、インストラクタがエンティティとして表されている。

---
title: Entity
---
erDiagram
    Student
    Course
    Instructor

リレーションシップ

リレーションシップはエンティティ間の関連性を表す。
以下の例は学生はコースを “履修する”、インストラクタはコースを “教える” ことを表している。

---
title: Relationship
---
erDiagram
    Student }|--|{ Course : take
    Instructor }|--|{ Course : teach

線の両端の形はリレーションシップの cardinality (多重度) を表している。
この場合ではそれぞれカラスの足状になっているが、それぞれ「1またはそれ以上」という意味で、「学生は1つ以上のコースを履修する」「コースは1人以上の学生に履修される」ということを表している。

リレーションシップの arity (項数) は一般的には二項型 (バイナリリレーションシップ) であることが多く、2つのエンティティ間の関係を表す。
一方で線の両端が同じエンティティにつながっている単項型、3のエンティティが関連する三項型もある。
以下は単項型の例で、前提となるコースの履修が必要であることを示す。

---
title: Unary Relationship
---
erDiagram
    Course }|--|| Course : "prerequisite course is required"

2つのエンティティ間でリレーションシップがある場合、外部キーが暗黙的に作成されることがある。

属性

属性はエンティティを識別、記述、評価するプロパティ。
属性はドメインを持つことができる。(後述)

以下の例では学生のエンティティに属性を付与した。

---
title: Attribute
---
erDiagram
    Student {
        int student_id PK
        string first_name
        string last_name
        date birthday
    }

ここで学生番号 student_id は単体で PK (primary key) に指定されており、インスタンスを一意に識別する1つの属性、つまりシンプルキーであると言える。

ドメイン

ドメイン (定義域) は属性が取りうる値一式のこと。
例えばコース開始日という属性があった場合は、現実に存在する日付として有効な値がドメインに含まれることになる。
コース開始日は開校日以降とする、のように範囲を限定することもできる。

余談だが…
エンティティ、リレーションシップ、属性などのデータモデルの構成要素は概念データモデルのレベルで説明した方がよかったかもしれない。
しかし Mermaid の ER 図はおそらく物理データモデル用のものとなっており、物理っぽい例になってしまった。

データモデリング・スキーム

スキームとはデータの表現方法のようなもので、DMBOK2 では以下に示す6種類のスキームが紹介されている。
各スキームそれぞれに表記法がいくつか存在する。

スキームごとにどの (物理的な) データベースで使用できるか、またどの詳細レベルで使用できるかが決まっている。
例えばリレーショナルスキームでは3つの詳細レベルすべてで RDBMS 状にモデルを構築できるが、他のタイプのデータベースでは概念モデル (CDM) と論理モデル (LDM) のみを構築できる。

DMBOK2 表10 スキームとデータベースの相互参照表

このポストではこのうち2つだけ触れておく。

リレーショナルスキーム

1970年、Edward Codd により提唱された。
業務データを正確に表現し、冗長性を除去することが設計目標である。
IE 表記法というのがもっとも一般的とのことで、Mermaid の ER 図も IE 表記法に近い。

erDiagram
    Student }|--|{ Course : take

ディメンショナルスキーム

ディメンショナルモデルでは大量データに対する問い合わせと分析を最適化しようとしている。
特定の業務プロセスに的を絞った業務上の設問に対応する。
以下の例は入学申請というプロセスを表したものであり、例えば学生が所属するゾーンごとに分析できる。
ゾーンから地域、国へと分析を拡大できる。

この分析軸表記法は DMBOK2 では有用とされているがネットで検索してもほとんど出てこない…
ただしデータウェアハウスの設計でよく目にする Kimball のディメンショナルモデリングは正にこれなので重要である。
ファクトテーブルやディメンションテーブルという概念もここで出てくる。

ちなみにフラットで単一なディメンショナル構造を正規化し、階層構造やネットワーク構造のコンポーネントを作ることをスノーフレーク化というとのこと。
あの Snowflake の製品名はここから来ているのだろうか？

詳細レベル

データモデリングには概念・論理・物理の3つの詳細レベルがあり、新しいアプリケーションを開発するときなどはこの順にモデリングを進めることになる。

概念モデル

概念データモデルには、関連する概念の集合体としてデータ要件の概要が取り込まれる。ここには、特定の領域や業務機能に関する基本的で重要なビジネスエンティティのみが含まれ、各エンティティの説明とエンティティ間のリレーションシップが含まれる。

ここは実装によらずあくまで業務を説明するものであり、したがって table 名や column 名ではなく業務の言葉で表現されることになる。

論理モデル

論理データモデルは、詳細なデータ要件が表現されたものであり、通常、アプリケーション要件のような特定の使用シナリオに適応する。論理データモデルも技術や具体的な実装上の制約から独立している。論理データモデルは概念データモデルの拡張として始まることが多い。

リレーショナルスキームの場合、概念モデルに属性を追加して拡張し、正規化を適用する。

物理モデル

物理データモデル (PDM) は詳細な技術的ソリューションを表す。このモデルは論理データモデルを出発点として作成されることが多く、そこからハードウェア、ソフトウェア、ネットワークツールを組み合わせた環境に適応するように設計される。

このモデルは実装方法に依存しており、具体的な table 名や column 名で記述される。
パフォーマンスのために非正規化されることがある。
ビューにするかやパーティションなどについても考慮する。

データモデリングの導入・推進

ビジネスアナリスト、データモデラーによって以下のように進められる。

1. データモデリング計画
2. データモデルの構築
3. データモデルのレビュー
4. データモデルの維持と更新管理

データモデルの構築において、新しいアプリケーションを開発する際に要件定義から始めるプロセスをフォワードエンジニアリングと呼ぶ。
フォワードエンジニアリングでは概念 -> 論理 -> 物理の順にデータモデリングを行い、具体的にしていく。
その逆順で行われるのがリバースエンジニアリングであり、既存のデータベースを文書化するプロセスとなる。

データモデルのレビューにおいては Data Model Scorecard (Hoberman, 2015) というものが使われる。

まとめ

曖昧な理解だったデータモデリングについて把握できた。
例えば dbt はデータモデリングツールだと言われることがあるが、あればリレーショナル物理モデリングの一部を行っている、という言い方が正しそうだ。

モダンなデータ基盤では概念・論理モデルはどのやって構築するのがベストプラクティスなのだろうか？
それともあまり概念・論理のモデリングは行われていないのだろうか？

詳細レベルの話は結構大事だと思っていて、3つのレベルを分けずにまとめてやることが多かったのであまり良くなかったと反省した。
まとめてやると物理を殴れるエンジニアがやるしかないが、レベルを分ければ概念モデルなどはデータアナリスト、営業などが参加しやすくなる。
今の仕事のデータ追加のフローを改善できそうな気がしてきた。