代理キーとかサロゲートキーとか。

恐れ多いですが、わたなべさんのモデルに対しての自分の意見を。
要件はこんなところですね。

倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする
それぞれの商品は倉庫毎の特定の棚に保管される（つまり、商品と倉庫の組み合わせで棚が決まる）

こんな感じになりました。

わたなべさんがおっしゃられてることに反応。

じつは「サロゲートキーにこだわるモデリングスタイル」には、目立たないがやっかいな問題がある。
複数のidが複合してユニーク制約を構成している事実を見落としやすい点だ。

同意です。
ユニーク制約をつければいい、って話でもあるのかもしれませんが、
DDL見ない・疑問を持たない実装者とか、DB設計者と実装者のコミュニケーション不足とかあると思うんで
怖くてできないかも。。

「ある商品のある倉庫における現在庫数量」と「ある商品のある倉庫における棚」は、
同一の識別子｛商品、倉庫｝に関数従属する項目です。
ゆえに、これらは同じテーブルの属性項目とみなせます。
データ項目のライフサイクルが違いすぎる場合にはテーブルを分けることもありますが、
そういう意味でもこの場合は分ける必要はありませんね。

個人的には、「ある商品のある倉庫における現在庫数量」と「ある商品のある倉庫における棚」は明らかにライフサイクルが違うと思います。
棚を増設したりしたときに、ある商品がある倉庫の複数の棚に分散されることあると思うからです。
棚が無限に大きいのなら別ですが。。

はぶさんのモデルは、倉庫の棚が複数の倉庫で使いまわされて配置ルールとなる、ように見えてしまうのは私だけ。。？