Re:DB 設計 (主キー、ABD、etc.)

id:aufheben:20060907 の続き。
id:yojikさんにコメント&トラックバックをもらったので、自分でもモデルを描いてみました。お題はこれ。

まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される(つまり、商品と倉庫の組み合わせで棚が決まる)ことになっているとする(在庫管理では典型的な業務要件だ)。

まずは、オリジナルに敬意を表して ER 図で。フリーで使えるツールを探してみたけれど、なかなかいいものが見つかりません。IDEF1X で代替キー(Alternate Key)が表示されるのが良かったんだけど。お望みのツールは商用かつめちゃ高、とても個人では購入できません。
結局 kdmsnrさんが 紹介 されていた Toad Data Modeler Freeware を使ったんだけど、烏足表記はともかく、代替キーが表示できない。主キーにこだわる理由はこんなところにもあるのかも。
http://homepage2.nifty.com/glad/work/hatena/20060910/inventory-erd.png
で、モデルの説明ですけど、前回書いたとおり主キーは ID に。「商品と倉庫の組み合わせで棚が決まる」については、「商品をどの棚に入れるかという情報と商品の在庫を同じテーブルに入れるのは気持ち悪い」ので「保管ルール」という別エンティティにした。保管ルールが倉庫と商品の組合せで決まることは、一意制約で表した。はぶさんのモデル をまねて、入庫・出庫を入れてみたけれど、在庫も含めて倉庫の棚を管理する必要性がよく分からなかったので、倉庫に関連を引いた。要件が変わっても主キーが ID だから大丈夫。
棚の配置は在庫管理にあまり関係なさそうだから省略。というより、興味があるのは「棚」そのものより「倉庫に配置された棚」ですかね。


せっかくなので UML でも描いておく。もちろんツールは JUDE で(何でやねん^^;)。
http://homepage2.nifty.com/glad/work/hatena/20060910/inventory-uml.png
基本的な構成は ER 図と同じ。全部のエンティティに機械的に ID を振るという約束ならば、書くと冗長になるので省略。
属性の制約 {unique} は独自記法。一意制約は OCL で書いてみた。限定子で表しても良かったかも。

前も書いたけれど、関連クラスは原則として使わない。
これについては、気が向いたらあとで書く。