« システム開発企業のスリム化戦略 | トップページ | NoSQLでもデータモデリングが必要 »

2018.12.01

「発効日」を主キーに含むデータモデル

 最近、あるプロジェクトのデータモデルをレビューして驚いた。マスター系テーブルのほとんどの主キーに「発効日」が含まれていたからだ。たしかに、レコードの有効期間をそのように管理することはある。しかしそこまで徹底されると異様だし、明らかな問題を含んでいた。あらためて「発効日」を主キーに含むモデリングについて考えてみたい。

 まずは、発効日を含む「まとも」なモデリング例を見よう。図1では、{仕入先ID,商品ID,発効日}の組み合わせに「契約単価」が関数従属している。発注管理ではありきたりなシステム要件だ(発効年月を用いるほうが自然なのだが、ここではテーマに沿って発効日にしてある)。

図1.発効日を含むまともなモデル
Image1

 契約仕入単価テーブル上の「失効日」は、同一の{仕入先ID+商品ID}を持つレコード群の中で、当該レコードの発効日に後続する発効日が代入される論理フィールド(仮想フィールド)である。また、発注明細から契約仕入単価への参照キー(外部キー)は{仕入先ID,商品ID,発効日}ということになるが、発注明細上の仕入先IDと発効日は、対応する発注見出しの内容から算出される論理フィールドだ。このように論理フィールドを含む参照キーを基礎とする参照関係を私は「動的参照関係」と呼んで、通常の参照関係(静的参照関係)と区別している。

 ここで、このモデルに含まれるマスターテーブルである「商品」と「仕入先」の主キーに「発効日」を組み込んでみよう(図2)。主キーに組み込まれた項目が、関連テーブルにも組み込まれる点に注目してほしい。ひととおりのマスターについて主キーに発効日を組み込むようなことをすれば、システム仕様はこのように急激に複雑化する。

図2.複雑だが破綻のないモデル
Image2

 さすがにやり過ぎという感じだが、破綻しているわけではない。ところが、レビューして驚いた件のモデルはこのようではなく、論理的には次の図3のようであった。図2よりはシンプルではあるがいかにも危うい。このモデルには「やり過ぎ感」と「手抜き感」が同居している。

図3.よりシンプルだが破綻しているモデル
Image3

 問題は「仕入先発効日」、「商品発効日」、「単価発効日」といった意味の異なる項目がすべて「発効日」とされている点だ。いかにも「マスターテーブルの主キーには発効日を含める」というローカルルールに誠実に従っただけ、という感じだ。結果的に、契約仕入単価の主キーが無意味なものになっているし、テーブル関連も意味的に破綻している(併記されたインスタンス上の日付値も矛盾せざるを得ない)。一言でいえば「気の利いたことをやろうとしたが中途半端」なモデルである。とはいえ形式的には間違っているわけではないので、レビューを素通りしてしまうかもしれない。

 想像してみればわかるが、こういう粗忽なモデルを基礎とすれば、どんなにプログラミングをがんばっても、バグが出やすく保守性の悪いシステムしか生まれない。それほどにDB設計は影響甚大かつ難易度の高い課題なのである。UI設計や動くソフトウエアを作ることを先行させても、的確なモデルとしてまとまる保証は何もない(大事な問題の検討を後回しにするゆえに事態はむしろ悪化する)。また、「いろいろと面倒だから、もう主キーは全部"ID"でいいじゃないか」と考える向きやそのためのフレームワークもあるが、問題が潜行してもっとややこしくなるだけだ(参考記事)。

 なお、有効期間別に項目値を管理するための効果的な方策がないわけではない。図4のように、どうしても期間別に管理したい項目だけを切り出して別テーブルにまとめたらいい。マスター本体の主キーは変わらないので、発効日を組み込んだことの影響を局所化できる。これはようするに、発効日を含んでいてもいなくても、それぞれの主キーに関数従属する項目を真面目に考えようという当たり前の話だ。

図4.「期間別管理属性」を組み込む
Image4

 まとめよう。有効期間別にレコードを管理すること自体は何も間違っていない。必要ならばやればいい。ただしそれを破綻なくやろうとすれば、仕様が想像以上に複雑化することを覚悟してほしい。エンジニアリングというのは、要件の複雑さと実装・運用コストとのバランスを考える活動である。その発効日は本当に必要か。じっくり悩んで落としどころを探ろう。

|

« システム開発企業のスリム化戦略 | トップページ | NoSQLでもデータモデリングが必要 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「発効日」を主キーに含むデータモデル:

« システム開発企業のスリム化戦略 | トップページ | NoSQLでもデータモデリングが必要 »