渡辺式データモデリングの復習

渡辺幸三さんのデータモデリングの手法について、復習と理解のために残す。
以下メモ書き。
間違っていたらあとで直す

【1】サロゲートキーの注意点

サロゲートキーは、トランザクションテーブルに多い。
受注番号、注文番号のように、シーケンスとして単に採番される。

しかし、実際のテーブル設計では、サロゲートキーを持つテーブルは、主キーとは異なる一意なキー項目が存在する場合がある。
たとえば、商品マスタのJANコード、従業員マスタの社会保障番号などだ。
あるいは、発注テーブルの受払Noなどもそうだ。

サロゲートキーはWebシステムではとても相性が良い。
しかし、何でもかんでもテーブルをサロゲートキーによる主キーで設計すると、業務要件をカラム間の関数従属性で表現しきれなくなる。
すると、そのような従属性はアプリ層で実装するようになり、システムが肥大化していく弱点がある。
だから、一意制約を持つキー項目でその従属性を表現すると上手くいく場合がある。

サロゲートキーの日常性と心得之条: 設計者の発言

(引用開始)
「サロゲートキー心得之条」
必要なユニーク制約が組み込まれているか注意すべし。また、ユニーク制約に含まれる項目値の更新に対処できているか注意すべし。なお、以って怠りし由（よし）にて死すとも、屍拾う者なし。死して屍拾う者なし
(引用終了)

渡辺幸三さんのデータモデリングでは、一意制約ないし2次識別子を使った技法が多い。
一意制約ないし2次識別子は、ボイスコッド正規化で必要なテクニックであるが、慣れた人でなければ理解しにくいと思う。

【2】動的参照の制約～ビューに対する参照制約(暗黙的なリレーションシップ)

複数テーブルを結合したビューに対し、外部キーによる参照制約がある場合が相当する。
継承属性とか、暗黙的なリレーションシップと呼ばれる。

例えば、渡辺幸三氏の「動的参照関係」について: Hot Heart, Cool Mind.にある例では、地域別配達方法マスタと顧客マスタが動的参照の例になる。

地域別配達方法マスタ----●顧客マスタ●----都道府県マスタ

上記のように、顧客マスタ単独では、地域別配達方法マスタと参照制約をもたせられない。
しかし、顧客マスタと都道府県マスタを結合させると、参照制約が現れる。

他に、生産管理システムの品目マスタと品目構成マスタなどの事例がある。
この動的参照の制約、または暗黙的なリレーションシップを一目で見抜くのはかなりの熟練の業を要すると思う。

「暗黙的なリレーションシップ」をRDBMSで実装することは現在はできず、アプリケーションのロジック層で実現するしか今の所はない。

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

「有効期間」を含むテーブルとの参照関係: 設計者の発言

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

業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索

【3】在庫監視推移方式～派生関係のテーブル間の一意制約

前回のIT勉強宴会で、渡辺幸三さんのライブモデリングを見て、初めて理解できたパターン。
「受払テーブル△--発注テーブル」「受払テーブル△--受注テーブル」という派生関係に対し、受払テーブルの主キーである受払Noを2次識別子として、発注テーブルと受注テーブルに持たせるやり方。

この手法を使うと、発注テーブルで在庫の発注履歴、受注テーブルで在庫引当のデータを受払テーブルで一貫して管理することができる。
つまり、在庫の過去から未来を受払テーブルで監視することができる。

第39回IT勉強宴会の感想～花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索

このパターンも、2次識別子という一意制約を上手く適用している。

【4】売掛金増減履歴～汎用アクセスキーの例(2次識別子かつ参照制約かつ排他の関係)

テーブル関連の「排他性」をモデル上で表現する: 設計者の発言

例えば、下記のような参照関係があったとする。

売掛金増減履歴●-----受領明細、出荷明細、・・・・・

上記の参照関係にあるテーブル群に対し、取引管理Noが2次識別子としてセットされているとする。
売掛金増減履歴にある2次識別子である取引管理Noは、他の参照先のテーブル群(受領明細、出荷明細・・)で排他の関係、つまりテーブル群の中で一意になるような関係を指すらしい。
このようなデータモデリングの設計ができるのはかなりの熟練の業を要すると思う。

このパターンも、2次識別子という一意制約を適用している事例になる。

【5】逆方向バリデーション～ビューによる検査制約(Check制約)

逆方向バリデーションを自動化する: 設計者の発言

「商品---●受注」という参照関係があった時、商品テーブルと受注テーブルを結合したとする。
そのビューに対し、商品テーブルの販売まるめ数が受注テーブルの受注数の整数倍になる検査制約(Check制約)を持たせる場合を指す。
例えば、販売まるめ数が10ならば、受注数は20、30などしかセットできない。

逆方向バリデーションとは、販売まるめ数を10から20に変更した時、既にセットされている受注テーブルの受注数へのCheck制約を課すかどうかを指す。
例えば、受注数が30のデータが既にセットされていた場合、販売まるめ数を20に変更したら、エラーを検知すべき。
しかし、業務用件によっては、逆方向バリデーションを実施しない時もあるらしい。

上記のように、ビューによるCheck制約は、DBMS上の制約では実現できない。
渡辺幸三さんの考え方では、開発基盤上で妥当性確認を実装すべきであるという思想がある。
例えば、XEAD Driverでは、正方向・逆方向バリデーションに対応しているらしい。

【6】感想
渡辺幸三さんの考え方では、上記のような関数従属性の制約は、DBMS上の参照制約・一意制約・検査制約で表現しきれるものではなく、一つ上のレイヤーである開発基盤で表現して実装すべきものだ、という主張が貫かれている。
確かに、通常のDBMSでは、上記のような制約は実現しきれないだろう。

業務ロジックをデータモデリングで表現しようとするために、開発基盤として強化する考え方はとても興味深い。
他にも理解できた事例があったら、記録しておきたい。