https://www.ap-siken.com/kakomon/04_haru/pm06.html

図１の利用プランテーブルで、主キーが施設コードとプランコードの複合キーになっています。個人的には主キーはプランコードのみで成り立つと思うのですが、それでは無理なのですか？

たとえば、お一人様プランというのがあったとして、同じ内容のプランをアパホテル各店舗でやるとして、お一人様プラン_東京池袋店とか店舗ごとに同じレコードで名前だけ変えてやるというならまあできなくもないですが、ふつう同じことをやらんです。

私の設計になりますが、このテーブル設計から推測するにプランコードは
表意コード（ニーモニックコード）をつけていると想定できます。
表意コードなので、値の例として
SINGLE  一人用
TWIN    二人用
FAMILY  家族用
のような値をとると考えられます。

もし、主キーをプランコードのみにする場合は、全ての施設で
一意のコードを付ける必要があり、
・001～999の単なる意味のない単なるシリアル番号
・SHISETU0001_SINGLEなどのコード内に施設を含む表意コード
を付ける必要があります。
しかし、上の２つのどちらのコード体系もアプリケーション処理ロジックにおいて
取り回しが不便になると考えられます。

SINGLEのような別の施設でも同じコードを利用している場合は、
SELECT文でSINGLEを検索することによって、一人用のプランを実施している
施設を特定する際に都合がいいです。

ならば、利用プランテーブルは
利用プラン（主キー:施設コード、外部キー:プランコード）
利用プラン明細（主キー:プランコード、最小利用人数、最大利用人数、1名分利用料金）
の2つのテーブルに分割できるように見えます。
実際はそうはいかないです。
例としてプランコード:FAMILY の場合、
施設毎に（最小利用人数、最大利用人数、1名分利用料金）が変化する
可能性があるため、分割はできないです。

E-R図は静的なDBの設計を図表にしたものです。
それを利用するアプリケーションによって意味をもつようになります。
E-R図を見るときはアプリケーションによってどう処理されるかを
想像すると理解しやすいかもしれません。

この投稿は投稿者により削除されました。(2023.03.12 10:31)

この投稿は投稿者により削除されました。(2023.03.12 10:31)

返答ありがとうございます！理解できました。
不便かどうかもより深く考えていきます。