複合キーの利用方法

質問

はじめまして。
Perl＋RDBMSを利用してWEBシステムの構築を考えております。
テーブルの組み方についてご意見伺えればと思います。

【質問】
1)
私は作成するテーブルに対して、既に存在している複合の項目で一意性が保たれていたとしても、必ず連番（serial id）の項目を追加しそれを主キーとしております。
このやり方は何か問題ありますでしょうか？

2)
質問1)に関連しているのですが、以下の例を元に、テーブル構成を2パターン記載致しますので、どちらの構成のほうがベター（或いはスタンダード）かをご助言頂ければと思います。
＜例＞
---------------------
親子関係のテーブル
Table A
└ Table B
└ Table C
---------------------
＜考えられる上記例のテーブル構成＞
---------------------
【P1-人工キーを用いた構成】
Table A:{A_ID}
Table B:{B_ID},A_ID
Table C:{C_ID},B_ID
【P2-複合キーを用いた構成】
Table A:{A_ID}
Table B:{B_ID,A_ID}
Table C:{C_ID,B_ID,A_ID}
---------------------
私が用いているのはP1の構成です。P1の構成を用いた場合の認知している問題点は、Table Cから一気にTable Aを参照できないことにあると思っております。
対してP2の場合、P1の問題は解決しますがテーブルのレイヤーが下がれば下がるほど、追加しないとならない項目が増えてしまって、管理の面やデータ量、またPG作成でも面倒が発生してしまうと思っています。
どちらのパターンが正規化などの観点から見ても良いものなのでしょうか？

長文申し訳ございません。
よろしくお願い致します。

回答No.2

angband · ベストアンサー

>申し訳ございません、この部分は例えばどのような場合になるのでしょうか？
>
この例でいきますと、内容が同じ受注を２つ受けた場合に、
TableB(受注明細情報(作業内容))とTable C(受注明細に付属する
オプション(作業場所))の両方が重複するように思います。
（【P1-人工キーを用いた構成】の場合)

逆に上記のケースでレコードが重複しない場合は、TableBとTableCには
同じ内容のレコード(主キーだけ違う)が許されるわけで、その場合は
第二正規形でなくなってしまうように思います。

フィールド内容の実世界での関係によりますが、話をうかがっている限りでは
TableCが実際には、TableAに関係があるように思ってしまってます。
ここで本当にTableCがTableBだけの依存で関係を表現できるかが大切に
思えます。（勘違いだったらすいません）
----------------
>以下、別の質問になってしまうかもしれませんが・・・
これは難しい問題ですね。僕もよく悩みます。例えば会員を扱っている
テーブルで、法人区分が個人か法人かで、個人名か会社名どちらかが必要な
場合などですよね。ちょっと調べてみます。
・・

お礼

度々のご回答有難うございました。

>・・・その場合は第二正規形でなくなってしまうように思います。

なるほど、人工キーを主キーとしたTableCが存在したら確かに主キーから見た従属関係はなくなってしまいますね。
気づいておりませんでした。有難うございます。

> ここで本当にTableCがTableBだけの依存で関係を表現できるかが大切に思えます。（勘違いだったらすいません）

あ、いえ、ストライクです（笑）依存関係の視点で見てみるということですね。確かに私の頭の中ではCはAに依存していることが前提となっておりましたが、人工キーを用いた場合にはその前提を表現しきれておりませんでした。こちらも良く理解できました。有難うございます。

> これは難しい問題ですね。僕もよく悩みます。例えば会員を扱っている・・・

まさにそのような場合です。
DB構成は正解が見えにくい（というかあるのでしょうか 汗）ので、決定にはいつも悩まされますね。。
ですので、こういう場でも他の人の意見は大変参考になります。有難うございます。

回答No.1

angband

1)主キーを連番で作るのは良いアイデアだと思います。
2)ぱっと見たところでは、P1は問題があるように見えます。
TableAとTableBは1対多の関係かと思います(親子なので)。
でもTableCはTableBに対して、1対多だとレコードが重複するのではないですか？
1対１だとすると正規化の観点からはTableBとTableCは１つのテーブルで
よいように思います。

お礼

ご回答有難うございます。

> でもTableCはTableBに対して、1対多だとレコードが重複するのではないですか？

申し訳ございません、この部分は例えばどのような場合になるのでしょうか？
度々ですがご教授頂ければ幸いです。

> 1対１だとすると正規化の観点からはTableBとTableCは１つのテーブルでよいように思います。

以下、別の質問になってしまうかもしれませんが・・・
補足に記載した例のような場合だとよく発生するのですが、特定の条件化によって入力対象の項目が異なってくる場合があります。
例えば、あるテーブルの項目<1>に○が入力される場合は項目<2>にデータを入力、×が入力される場合は項目<3>にデータを入力、といった時です。
そのような場合、項目<2>と<3>は別テーブルにし、項目<1>が存在するテーブルとは1:1の関係にしているのですが、こういったことは普通、行わないものなのでしょうか？第3正規化に引っかかるのでしょうか・・・

補足

質問文の例のところで、インデントがおかしく、Table BとTable Cが並列かのように見えてしまっていますが、文章にすると以下のような関係です。

TableBの親はTableA。
TableCの親はTableAとTableB。

具体例をひとつ出しますと、
Table Aは受注情報（受注No）
Table Bは受注明細情報（作業内容）
Table Cは受注明細に付属するオプション（作業場所）
といった感じです。
AとBの関係は1:M、BとCの関係も1:Mになります。