実践的データモデリング入門の感想

DOAの体系的方法を知るために「実践的データモデリング入門 (DB magazine selection)」を読んでいる。
IDEF1の説明から、ビジネスロジックからER図への落し込み、データモデルパターン、データモデルの物理的配置の方法まで、全ての情報を網羅しているので読みやすい。
「実践的データモデリング入門 (DB magazine selection)」を解説しているHPがあったのでメモ。

以下は、「実践的データモデリング入門」から僕が理解できた内容を抜き出している。
詳細は「実践的データモデリング入門」を参照してください。

【元ネタ】
履歴モデル

サブタイプ構造の明確化

サブタイプ分割されたエンティティから関連付けるエンティティ

取引モデル

関連が隠蔽されているモデル

同一主キーでの別エンティティ化の基準

代理キーによる複合キーの抑制

【1】「実践的データモデリング入門 (DB magazine selection)」で興味を惹いたのは、データモデルパターンで説明されている履歴パターン。
よくある問題は、注文履歴に残った商品マスタの情報が変わった時、注文履歴にある商品の情報をどのように管理すべきか、という問題。
例えば、販売期間を過ぎても売れないので、商品の価格を下げた場合、商品マスタの価格と注文履歴に残った価格に不一致が起きる。
あるいは、売り切れて今後販売しない商品をマスタから削除する場合、注文履歴の商品情報が取得できなくなる症状も同じ。

解決方法としては、2種類ある。
一つは、トランザクション(イベント)のテーブルにマスタ(エンティティ)の情報を転記して、履歴に残す方法。
他方は、マスタ(エンティティ)自身に適用年月日などを追加して履歴を管理する方法。

前者は、注文明細データを生成するときに商品マスタの情報を挿入する方法を取る。
いわゆる転写、複写に相当する。
この方法の長所は、注文明細の検索では、注文明細テーブル一つで良いこと。
テーブルに画面の検索条件に対応するカラムへインデックスを貼れば、スケーラビリティを確保しやすい。

逆に弱点は、注文明細テーブルの正規化が崩れること。
商品マスタの情報と整合性が取れなくなるので、注文明細にある商品情報にもっと他の業務要件がある場合は、注意しないくてはいけない。

後者は、商品マスタに適用開始・終了年月日を主キーに持たせて、商品マスタ自身で履歴を管理する方法。
この方法の長所は、複雑な業務ロジックが絡んでいたり、仕様変更が多いエンティティで柔軟な修正が可能なこと。
つまり、この方法は、エンティティに履歴を意味する日付を追加するので、エンティティからイベントへ変わることを意味する。
だから、普通は、商品基本属性テーブルと商品履歴テーブルのように、更に商品固有のエンティティと履歴に関するイベントのテーブルへ分割する場合が多いだろう。

逆に弱点は、エンティティが複合主キーになるし、テーブルも複雑になるので、SQLやアプリケーションロジックが複雑になりやすいこと。
商品の価格が販売期間で頻繁に変わったり、商品の基本情報が頻繁に変わりやすい場合に応用する場合が多いだろう。

普通は、注文明細を後で利用する業務がないならば、前者の方法で十分だろうと思う。

【2】他によくある問題は、テーブルに区分・フラグ・ステータスなどのカラムがたくさんあるテーブルをどのようにモデリングすべきか、という問題。
区分というカラムが存在すれば、アプリケーションでは必ず分岐が発生して、そこが仕様漏れやバグの温床になる。
駄目なモデラーほど、一つのエンティティで全ての業務ロジックを表現しようとして、区分というカラムがどんどん増える時が多い。

例えば、注文内容というテーブルがあった場合、実際の業務では、請求も絡んだり、出荷や売上計上も絡んだりしたとする。
その場合、注文内容テーブル一つで表現しようとすると、一つのデータがどの業務に対応するかという区分を持たせることになる。
しかし、業務が変われば区分を頻繁に更新する必要があるから、排他制御やデッドロックなども考慮しなくてはいけない。
つまり、無駄なアーキテクチャを考慮する必要も出てくる。

だから、業務が発生するタイミングや場所の観点で、別エンティティとして作った方がいい。
データモデルでは、動的な状態の表現が難しいからだ。

この問題のように、トランザクション系テーブルは、業務単位に別エンティティにした方がいい場合が多い。

【3】複合キーがどんどん肥大化する問題もある。
実際のデータモデリングでは、ユニークなコードに、適用年月日や区分を主キーとして追加する場合が多い。
すると、複合キーが4個、5個と増える時が多くなり、データモデルを読み解くのが難しくなる。
また、そのまま実装すると、インデックスのサイズが増える弱点もある。

そんな場合は、代理キー(サロゲートキー）を使うとよい。
つまり、複合キーは全て外部キーとして、ユニークなシーケンスを主キーにして集約しまえばいい。
この方法は、Railsが得意とするやり方で、最近のWebシステム開発では主流のデータモデリングの手法になったと言えるだろう。

代理キーの長所は、RESTと相性がよいことだ。
複合キーの場合、一つのデータにアクセスする場合、リクエストへ送るパラメータを追加することになり、URLが長く醜くなる。
しかし、代理キーならば、1個のパラメータでアクセスできるから、URLをRESTで分かりやすく表現できる。

Railsのように、複合主キーを廃止して、アプリケーションで複合主キーのロジックを実装するやり方の方が最近のWebシステム開発の主流だろうと思う。

【4】関連が明示されていないけれど、実際の業務用件を聞くと、データモデルに関連が必要であるという問題もある。
これは、エンティティ間の関連に外部キーが明示されていないという問題になる。

駄目なモデラーは、テーブルの親子関係ばかり作って、外部キーを上手に使っていない場合が多い。
外部キーはビジネスロジックと直結しているので、明示しておかないとデータを辿れない。

この問題に関係する概念として、渡辺幸三さんの本「業務別データベース設計のためのデータモデリング入門」が説明している「継承属性」がある。
継承属性とは、多重度1の関連エンティティの属性項目を表す。

例えば、注文ヘッダにある得意先コードは、注文明細にも引き継がれるということ。
実際には、注文明細には得意先コードのカラムは存在しないけれど、親テーブルの注文ヘッダから得意先コードを引き継ぐので、一つの注文データとして見れば、得意先コードが外部キーとして存在することになる。

実際のデータモデリングでは、外部キーが継承属性になっているケースが多いので、継承属性に気をつけないと、一つのデータから業務ロジックを辿る場合に見落としてしまう時があるので注意。

【5】仕様変更によってエンティティの種類を増やしたい場合、どのようにデータモデルを作ればよいか、という問題もある。
例えば、書店の業務に商品エンティティは元々、書籍しかなかったけれど、DVDやゲームソフトを販売する業務が増えた場合が相当する。

この問題に対してはオブジェクト指向のポリモルフィズムのように、テーブルの継承を使うとよいだろう。
つまり、商品基本属性という親テーブルに、書籍、DVD、ゲームソフトという子テーブルが継承関係にあるデータモデルを作ればいい。
データモデルの継承関係の実装は、子テーブルに商品コードを外部キーとして持たせて、親子関係を1対0 or 1の関係に持たせればいい。

ポリモルフィズムの最大の利点は、サブエンティティの追加の影響が少なくなることにある。
データモデルでもオブジェクト指向と同様の発想でモデリングすればいい。

【6】エンティティの役割が大きく変わる問題もある。
例えば、書店は取次店(卸問屋)を経由して書籍を仕入れていたが、出版社から直接仕入れる業務が追加されることになったとする。
すると、書店と取次店、出版社の間の関係が大きく変わり、実際は取次店がなくなるというデータモデルになる。
既に従来のモデルで動いているのに、エンティティの役割が変わってしまう場合は、既存のデータモデルでは実現しにくい。

「実践的データモデリング入門 (DB magazine selection)」では、この問題に対してロールエンティティを使うことを勧めている。
つまり、出版社が取次店の役割も担うと考えて、「出版・取次ロール」という別テーブルを作って、既存のデータモデルへの影響を少なくさせる方法。

この方法は、アナリシスパターンにおける知識・操作レベルという手法に似ている。
つまり、知識レベルという一つ上のメタレベルで、エンティティのビジネスロジックを表現しようとするやり方。
ここでは、ロールエンティティが知識レベルに相当する。

ロールモデルという考え方は、データモデリングだけでなく、OOAの概念モデリングでもよく出てくる。
ロールモデルという考え方は、最終的には「型(Type)」という概念へ辿りつくと思う。

「実践的データモデリング入門 (DB magazine selection)」には他にも色んなパターンが具体的に説明されているので分かりやすい。
最近のWebシステム開発はRailsやSeasarのように、DOAでER図がしっかり設計されていれば、ビジネスロジックの実装は以前よりも楽に開発可能になっている。
RailsやSeasarを仕事にしている人は、DOAを見直してもいいのではないかと思う。