背景
データモデリングの細かいテクニックに関しては書籍やWebの記事に記されていることが多いです。
しかし、実務に耐えるようなデータモデリングの流れについては(少なくとも私が調査した中では)あまり記載されておらず、学習するときにとても困りました(例えば、第一正規化をしたら第二正規化をするだとか、要件を書き出したときの名詞がリソースエンティティでとかの、小手先のテクニックばかりで、実務ではどのようにしていいかがわからない)。
本記事の内容
本記事では、私が書籍やWebの記事を読んだり、実務で経験したり、その中で先輩エンジニアに聞いたりしたことをもとにして辿り着いた、データモデリングの流れについて記載しようと思います。
結論
私が行っているデータモデリングの流れは以下のとおりです。
- 企画者の想いを元に、要件定義を"漏れなく"行う
- 業務要件を"網羅的に"定義する
- システム要件を"網羅的に"定義する
- 各システム要件を抽象化し、データモデルの形式(エンティティ・関連・属性)に変換する
- 2.のデータモデルが1.の要件を適切に表現できているかを確認する
- 3.でうまく表現できていない部分があれば、2.に戻る / すべてうまく表現できていることが確認できれば完成
各工程の説明
1. 企画者の想いを元に、要件定義を"漏れなく"行う
要件定義に関しては、本記事のスコープから外れるため、細かい要件定義のやり方に関しては記載しませんが、データモデリングを行う上での要件定義の注意点を記載します。
それは要件を網羅的に定義することです。
データモデリングの良し悪しは、具象のユースケースが網羅的に表現できていることと、処理がいい感じに書けそうかがすべてだと思います。
しかしこれらの前提として、そもそもの要件に抜け漏れがないことが必要です(当然ですが)。
リリース後に要件漏れがあることがわかって、モデリングの根本に問題があることがわかると、その変更には大きな手間がかかります。
良いシステムを作るという観点でも、モデリングレベルの手戻りを防ぐという観点でも、要件は網羅的に定義することを特に気をつけるといいと思います。
2. 各システム要件を抽象化し、データモデルの形式(エンティティ・関連・属性)に変換する
要件は具象のできごとなので、データモデリングの形式(エンティティ・関連・属性)にするにあたって、まずは抽象化をする必要があります。
そのうえで、モデリングの形式に転写をします。
ここの抽象化と写像の仕方がセンスのでるところであり、難しいポイントだと思います。
この"センス"は何かと言語化すると、①モデリングのパターンやテクニックをどれだけ知っているかと、②いかにそれらを文脈に応じて適切に選択・組み合わせられるか、なのかなと思います。
①の習得に関しては、書籍やWebの記事に色々なパターンやテクニックが記載されているので、それらのインプットを行えばいいのだと思います。
②の習得に関しては、①に関してどれだけ深く理解するか、地頭の良さが必要だと思います。これらのスキルに関しても、様々なビジネス書などがあると思うので、それらを参考にすればいいと思います。
また、この工程の大きな進め方としては、DOA(データ中心アプローチ)で大枠(主にエンティティと関連付け)を表現し、その後POD(プロセス中心アプローチ)で詳細(エンティティの分割・統合、関連付けのブラッシュアップ、属性の付与)を表現するのが適切だと思います。
その理由は以下の書籍の第四章に記載されているので、気になる方はこちらをご参照ください(需要があれば、要点を本記事に追記します)。
システム開発・刷新のための データモデル大全
3. 2.のデータモデルが1.の要件を適切に表現できているかを確認する
適切に表現できているか確認する方法としては、UIや処理がいい感じにコードで書けそうかを確認すればいいです。
ここでうまく表現できていないものがあれば、2.に戻ります。
すべて要件をうまく表現できていれば、完了です。
おまけ
"2. 各システム要件を抽象化し、データモデルの形式(エンティティ・関連・属性)に変換する"工程で、私が特に行うことの多いことをメモがてら記載しておきます。
- 正規化
- スーパータイプ・サブタイプの表現
- イミュータブルにする(参考: WEB+DB PRESS Vol.130)
参考
- 楽々ERDレッスン
- 達人に学ぶDB設計徹底指南書
- システム開発・刷新のための データモデル大全
- 実践的データモデリング入門
- 事業分析・データ設計のためのモデル作成技術入門
- WEB+DB PRESS Vol.130
X(Twitter)
私のX(Twitter)のアカウントはこちら