開発現場ですぐに通用する“今どきの”モデリングテクニック
|
パート2では「開発プロジェクトの工程全体の中におけるモデリング」という視点から、実際のモデリングに必要な要素や具体的な作業の進め方を解説していきます。なぜそのような視点にしたのかは本編で述べていますが、基本的には筆者のこれまでの経験上、実際の開発現場で通用するモデリングのスキルを取得するにあたっての最短の近道だと考えるからです。これまでのモデリングに関する書籍や記事とは一味違った切り口での説明になると思いますが、どうぞ最後までお付き合いください。
“教科書に載っていない”モデリング作法とは
これまでに筆者は、データモデリングに関する数多くの書籍や雑誌／Webの記事を読んできました。それらから得た知識は、確かに実践の中で活かされてきましたが、実際のプロジェクトでDB設計を担当するとなると「記事には載っていない何か」が現場では必要になったのです。世の中にある、多くのモデリングに関する書籍や記事には「モデリングそのもの」に関する情報は多く掲載されています。それは例えば、正規化理論やモデリング手法といった“モデリング理論”的なものであったり、ある特定の業種でモデリングを行なう際に気を付けるべきポイントやコツ、いわば「特定業種のモデリングTIPS集」であったり、モデリングで頻繁に直面する問題に対する解法、すなわち「モデリングパターン集」のようなものでした。 そして、“記事に載っていない、現場で必要な知識”とは、実際の開発プロジェクトの全体工程の中で「DB設計がどのように絡んでくるのか？」「どの工程でどのようなことを実施するのか？」という点にあると感じました（図1）。
図1 モデリングに関する記事の種類と本稿の位置付け
そのため、本稿は「開発プロジェクトの工程全体の中におけるデータモデリング」に焦点を当てます。また、先の「モデリング理論」「特定業種のモデリングTIPS」「モデリングパターン集」の解説は最低限に留めます。とはいえ、モデリングを実践する際にはこれらの知識も必要になってきますので、まずはそうした知識を学ぶのに適した書籍を紹介します（カコミ記事参照）。本稿は、これらの書籍を「副読本」として活用しながら読み進めて行くとより効果的ですので、ぜひ目を通してみてください。
データモデリングの工程
それではまず、データモデリングがどのような工程を経て実施されていくか見てみましょう。データモデリングの工程をまとめた図3をベースに解説を進めていきます。各フェーズの詳細はこの後で1つずつ解説しますので、まずは全体の流れをザッと見ていきましょう。
図3 データモデリングの工程 [拡大]
まず、データモデリングを行なう前に、その開発プロジェクトで何のためにモデリングを行なうかを整理するために「モデリングの目的検証」を行ないます。その後、実際のモデリング工程に着手します。パート1でも軽く触れましたが、データモデルには人が読んで理解するための「論理モデル」と、実際にデータベースとして構築される「物理モデル」があり、それぞれの設計を「論理モデル設計」「物理モデル設計」と呼びます。 論理モデル設計をさらに細かくフェーズ分けすると、「コンセプトモデル（概念モデル）設計フェーズ」（図4）と「（狭義の）論理モデル設計フェーズ」（図5）に分かれ、物理モデルは「（狭義の）物理モデル設計フェーズ」（図6）と「モデル微修正フェーズ」に分けられます。
図4 コンセプトモデル
図5 論理モデル
図6 物理モデル
こうしてデータモデルは「安定化フェーズ」となり、最終的にアプリケーションの完成と共にリリースされるというわけです。なお、昨今はRUP(注2)や、XP(注3)に代表されるアジャイル系プロセスを採用し、インクリメンタルな開発スタイル(注4)をとる開発プロジェクトも増えてきましたので、繰り返し型のプロセスにおけるモデリングの工程についても解説しておきましょう。 繰り返し型の開発プロセスとはいえ、イテレーションごとにデータモデルをイチから設計するわけではありません(注5)。「（狭義の）論理モデル設計」までは、システムの開発スコープ全体をカバーする「カタい」モデルまで 設計しておくのが、一般的と言えます。当然、これには理由があります。例えば、「商品メニュー」（図7）というエンティティを考えてみてください。これらのエンティティは新規に取り扱う商品を登録する「新規取扱商品登録」機能でも利用されますし、「注文」機能でも利用されます。また「セール情報設定」といった機能でも利用されるエンティティになります。
図7 商品メニューとその周辺のER図
このように、1つのエンティティは複数の機能から利用されるのが常です。このため、機能ごとにイテレーションを分けてリリースするとはいえ、そのたびに商品メニュー周辺のデータモデルを見直すわけにはいかないのです。もし、そうしてしまうと、ツギハギだらけでポリシーの欠如した、拡張性もへったくれもないデータモデルができてしまうでしょう（図8）。そのためデータモデルは、そのシステムの根底の思想を示す「堅固なもの」として設計される必要があると言えます。
図8 ツギハギだらけのデータモデル
（注2）Rational Unified Process（ラショナル統一プロセス）の略称。「R」を取って「UP」とも称される。
（注3）eXtreme Programingの略称。
（注4）設計～リリースを数週間の期間の「イテレーション」に分けて、繰り返しリリースを行なう開発プロセスのこと。
（注5）少なくとも筆者はそのようなスタイルを見たことがありません。