業務ロジックをデータモデリングはどこまで表現できるか？

「業務ロジックをデータモデリングはどこまで表現できるか？」について考えたことをラフなメモ書き。

業務システムでは、データが命。
データには個人情報が含まれるために管理が重要だったり、売上データやPVデータから、どの層の顧客から売上やアクセスが多いのか、を計測することもできる。
すると、それらデータを格納するRDBが必要になり、そのテーブル設計が重要になってくる。

顧客の業務プロセスをモデリングする場合、最近ならOOAが主流。
でも、DOAの方が現代は重要性を増していると考えている。
例えば、Railsのような優れたWebフレームワークがあれば、ER図さえきちんと作れば、DBマイグレーションとプログラム雛形を自動生成することによって、テーブルのCRUDのような画面はすぐに作れてしまうからだ。

日本におけるデータモデリングの歴史は意外に古い。
TH法、T字型ER、渡辺さんのXEAD Modelerのように、たくさんの流派がある。
にも関わらず、日本の現場ではデータモデリングの技術が蓄積されていない。

「業務ロジックの制約をデータモデリングはどこまで表現できるか？」の疑問について関西IT勉強会の人たちと議論してみて、この問題はきちんと整理すべきだと考えている。
日本に流布されているDOA本は正規化の説明しかない詰まらない本ばかりで、テーブルのリレーションシップや項目の関数従属性でどこまで業務ロジックを表現できるのか、その技術とそれを適用した結果についてきちんとまとめられていない。
渡辺さんの本が唯一「DOAのアナリシスパターン」に近いと思うけれど、業務システムに仕様変更が入ったらどのように変化して進化していくべきか、を具体例と理論の両方から体系化された説明が不足していると思う。

データモデリングの技術については以下の技法があると考えている。
内容を整理していきたいと思っている。

【1】自然キー、人工キー、代理キー、代替キー、候補キー、2次識別子

候補キーと2次識別子に関する概念: プログラマの思索

データモデル表記読み替えハンドブック: プログラマの思索

DOAはOOA以前に表記法の問題点がある: プログラマの思索

主キー以外にも、キーにはいろんな種類があり、それぞれの意味を持つ。

【2】正規化と情報無損失分解

モデリング再復習DOA編part1～情報無損失分解と結合の罠: プログラマの思索

正規化したテーブルを結合して復元する時、情報が損失されてはいけないという制約が情報無損失分解になる。
複数の候補キーがあるテーブルの場合、正規化する時に情報無損失分解になるように注意が必要。

【3】2次識別子とボイスコッド正規化

2次識別子を使ったデータモデリング: プログラマの思索

渡辺さんの本がとても詳しい。
候補キーが2個以上現れる場合、必ずボイスコッド正規化せざるを得ず、その場合、unique制約(一意制約)で実装するのが一つの解決法になる。

【4】外部キーと複合キー

2つのエンティティでビジネスルール(業務の制約条件)が発生する場合、外部キーによるリレーションシップが発生する。

実践的データモデリング入門の感想: プログラマの思索

連関エンティティと関連クラス: プログラマの思索

候補キーと2次識別子に関する概念: プログラマの思索

業務ルールをどのように外部キーとして張ればいいのか、という問題に対しては、T字形ERが鮮やかに解決している。

自分流モデリング探しの旅(2)～T字形ER データベース設計技法 - papandaDiary - Be just and fear not.

(前略)
* resourceとresourceをつなぐ場合：対照表を生成する。対照表はeventである。
　（例）従業員と営業所
　　　　　従業員-営業所の対照表を作成し、リレーションシップを保全する。
* resourceとeventをつなぐ場合：event側に参照キーを持たせる。
　（例）顧客と注文
　　　　　注文entityに顧客コードを持たせる。
* eventとeventをつなぐ場合
** 「１：１」「１：ｍ」：時系列の遅い方に持たせる。
　（例）受注と請求（一つの受注に対し請求は一つ）
　　　　　請求に受注番号を持たせる。
** 「ｍ：１」「ｍ：ｍ」：対応表を生成する。
　（例）受注と請求（複数の受注に対し請求は一つ）
　　　　　受注-請求の対応表を生成し、リレーションシップを保全する。
(後略)

この方法が全ての場面で適用できるわけではないが、当てはまる場合が多いので参考にすべき。

【5】派生関係

データモデリングでもOOAと同様に継承関係つまり派生関係という概念はある。
例えば、製品の品目、仕入先と取引先、など。
但し、ER図で派生関係が出る場合、モデルの実装はとても難易度が高いので要注意。

データベース設計で派生関係は難しい: プログラマの思索

【6】暗黙的なリレーションシップ、又は、継承属性、又は、動的参照関係

正規化したテーブルに対して、外部キーとなる項目がないが、複数のテーブルを結合したビューでは参照制約が存在する時、普通は「暗黙的なリレーションシップ」があると呼ぶ。
渡辺さんの本では「継承属性」、渡辺さんのBlogでは「動的参照関係」と呼ばれている。

正規化されたER図を単純に見るだけでは「暗黙的なリレーションシップ」が存在することを見つけ出すのは難しいと思う。
「暗黙的なリレーションシップ」をRDBMSで実装することは現在はできず、アプリケーションのロジック層で実現するしか今の所はない。

Twitter / akipii: 「動的参照に伴う制約はビューに対する外部キー制約である」。いわゆる継承属性又は暗黙的なリレーションシップの明確な説明だと思う。ようやく分かった気がする。　Hot Heart, Cool Mind. 渡辺幸三氏の「動的参照関係」について http://blogs.dion.ne.jp/keis/archives/10547207.html …

Twitter / akipii: 動的参照関係のようなルールを実現するには、プログラムでアドホックに書くやり方は簡単だが検証が難しい。本来はDOAのモデル上で全ての制約を表現したい、という方向性はうなずけるものがある。

渡辺幸三氏の「動的参照関係」について: Hot Heart, Cool Mind.

「動的参照関係」を手なづける: 設計者の発言

【7】テーブルの再帰構造

アルゴリズムの再帰構造と同様に、テーブルでも再帰構造は出てくる。
例えば、生産管理の品目、組織構造、会計の科目など。
でも、無限ループにならないような制約をプログラムで実装する必要があったり、検索の性能が悪くなるので使い勝手が悪い。
結局、正規化を崩したテーブル設計になりやすい。

だが、階層構造は入れ子集合を使うと、ツリー構造をRDBに綺麗にマッピングできるらしい。
Redmineのチケットテーブルでは、issues.lft, rgtは入れ子集合でツリー構造を表現した時、2次元の円の両端の座標を表している。
すると、チケットBの親がチケットAである場合、チケットA.lft＜チケットB.lft＜チケットB.rgt＜チケットA.rgtという関係が成り立つので、このルールを使ってガントチャートを階層化して表示しているわけだ。

Redmineチケットの階層化の実装方法: プログラマの思索

このテクニックを解説している本は「達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ」だけに書かれている。

自分で理解した内容はBlogで今後まとめていく。