« 業務システムを「牢獄」にしないために | トップページ | DB設計がマトモであれば何とかなる »

2018.04.04

UML版在庫データモデルの問題

 IPAによるデータベーススペシャリストの平成28年春期試験で、UMLモデルを使った問題が出されていた(これ)。最近たまたま見つけたのだが、これには驚いた。問題や解答が間違っているわけではないのだが、クラス図でデータモデルを描くことの危うさをこれほど雄弁に示している例はないので紹介したい。

 まず注意してほしいのは、問題に添えられている「データモデル」の上でPK(一次識別子)が示されていない点だ。これは、クラス図ではすべてのインスタンスがID(オブジェクトID)で識別されるためだ(つまり、すべてのPKがIDであればいちいち示す必要がない)。PKを補ってER図として描き直すと図1のようになる。

図1.倉庫と商品の関係
20180404a

 一見すると問題がなさそうだが、このまま実装すれば悲惨なことになる。具体例を書き添えてみればわかるのだが、図2で示したようなデータ状況を許してしまう。すなわち、「倉庫と商品の同一の組み合わせが商品在庫上で重複して存在してはいけない」という基本的な業務ルールがモデルに反映されていない。商品在庫上の「商品ID」や「倉庫ID」の値が、レコード追加後に更新されることを認めている点も気になる。

図2.倉庫と商品の関係(インスタンス付き)
20180404b

 この指摘に対して、「商品と倉庫の組み合わせが在庫上で重複してもかまわない、という前提であれば、問題はない」という反論があるかもしれない。たしかにロット管理あたりを前提とすれば、商品と倉庫の組み合わせが重複することは許容される。とはいえ、モデル上にロット№のような管理項目がないし、そもそもロット管理のような比較的特殊な業務をこういった問題の暗黙の前提とすることは適切でない。ふつうに考えれば商品と倉庫の組み合わせが在庫テーブル上で重複することは許されないので、そこらへんの基本的な制約が「データモデル」上で明示されていないのは重大な疎漏と言わざるを得ない。

 また、「商品別に在庫数量を合計すればいいだけのことなので、問題はない」という反論も無意味だ。たしかに商品毎に在庫数量を合計すれば正しい在庫数量が手に入る。しかしその仕様では在庫レコードがいたずらに増えるし、個々の在庫数量に意味がないし、いちいち合計する手間が面倒だ。

 別の反論として「商品と倉庫の組み合わせが在庫上で重複しないというのは”常識”なので、そこらへんの制約は入出庫アプリ上で配慮されるはずだ」という意見があるかもしれない。しかしそういった”常識的配慮”をするには一定以上の業務知識や開発経験が要る。クラス図だけ渡せば実装担当者が気を利かして必要な制約をアプリに組み込んでくれるだろう、と期待すべきではない。また、システムを動かす過程で制約に気づいて、適宜アプリに盛り込んでゆけばいいと考えるべきでもない(なんと傍迷惑な開発方針だろう)。

 まともなモデルとして描き直すと図3のようになる。在庫数量は「商品在庫ID」ではなく「倉庫ID+商品ID」に関数従属する。この場合、倉庫IDと商品IDはPKに含まれるゆえに値が更新されることはない(*1)。また、受払履歴(入庫と出庫を含む)上でも、外部キーは「商品在庫ID」ではなく「倉庫ID+商品ID」として構成される。細かい部分では、商品コードや倉庫番号はPKではなく属性項目なので値を変更することが許されるが、自然キーとしてリレーション中で重複してはいけないのでユニーク制約が付与されている({...}で囲まれた項目)。

図3.倉庫と商品の関係(改善版)
20180404c

 これほど単純なデータ要件を扱っても、クラス図でデータモデルを描くことの危うさがよくわかる。その最大の問題は、「ユニーク制約」や「更新不可制約」がクラス図にネイティブな図法表現として組み込まれていない点である。かといってそれらを制約としてこまごまと補足したり、不人気な関連クラスを駆使するくらいなら、無理せずに最初からER図を使えばいいだけの話だ。

 そういうわけなので、件の問題文を次のように修正したい。「データベーススペシャリスト」ならこれくらいは正答してほしいものだ。

【問題】
商品と倉庫の関係を、UMLを用いてデータモデルで表した。このモデルに対する批判として妥当なものはどれか。

ア 商品在庫における倉庫と商品の組み合わせが重複する恐れがある
イ 商品在庫の参照先となる倉庫や商品が切り替えられる恐れがある
ウ 商品において商品コードが重複する恐れがある
エ 倉庫において倉庫番号が重複する恐れがある

【解答】
ぜんぶ


*1.PKに含まれる項目の値が更新されると、既存のテーブル関連が失われてしまう。これを避けるために必要な制約で「更新不可制約」と呼ばれる。ところが、多くのRDBMSではPKの値の更新を許していて、現在のRDBMSの欠陥である。ゆえに、更新不可制約は個々の開発基盤上で機構化することが求められる。いずれにせよ、データモデル上でPKとして示されている項目には更新不可制約が付与されていると考えていい。

|

« 業務システムを「牢獄」にしないために | トップページ | DB設計がマトモであれば何とかなる »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: UML版在庫データモデルの問題:

« 業務システムを「牢獄」にしないために | トップページ | DB設計がマトモであれば何とかなる »