データベーススペシャリスト 試験情報＆徹底解説

試験問題には「連関エンティティ」と「複合キー」が良く出てくると思います。
学習をしていて、どのような場面なら複合キーもしくは連関エンティティにするべきなのだろうと疑問を抱くようになりました。
現状、明細系のエンティティには親テーブルのPKを使って複合キーにするケースが多いなくらいのイメージしかないのです。(サロゲートの時もありますが。)
調べてみても属性が少ないときは複合主キーでも良いのじゃない？くらいしか出てこなくて。。。本当にそうなのか？？という状態です。
出来れば現場でお仕事をされている皆さんのご意見を参考にさせていただきたいです。

>学習をしていて、どのような場面なら複合キーもしくは連関エンティティにするべきなのだろうと疑問を抱くようになりました。

>現状、明細系のエンティティには親テーブルのPKを使って複合キーにするケースが多いなくらいのイメージしかないのです。(サロゲートの時もありますが。)
基本どこまでいっても基準は、そのエンティティの中身というのは何が最低限あれば識別（一意になる）できるんだ、ということに尽きるわけです。明細というのは、例えばAmazonの買い物をして、1回のボタンで2種類の商品を買ったとき、ヘッダとして誰が買ったんだ、いつ買ったんだとかの共通の情報があって、何を買ったんだという情報というのは明細に来るわけですが、明細で最低限必要なことというのを考えるときに、なんのタイミングのときの買い物なのか？がヘッダのキー項目なわけです。じゃあヘッダが特定できたら明細も特定できるんか、というと複数あり得るわけで、じゃあどう特定するんだ、ということで、その特定項目に意味はないがとりあえず識別できればいい、ということでシーケンシャルな番号が振られて明細番号とかで識別して、明細のエンティティのキーが決まったね、とかなるわけです。
連関エンティティは多対対をRDBでは解決できないので中間テーブルで解決する手法です。
fmhelp.filemaker.com/help/18/fmp/ja/index.html#page/FMP_Help/many-to-many-relationships.html
多対多のリレーションシップ

じゃあサロゲートはどう使うんだ、というので、平成25年の午後1あたりにサロゲートに切り替えるのがありましたが、じゃあ普段からサロゲートへのシフトをそんなにやっているのかというと、あんまりないですね。DWHとか、たとえば
一覧を表示し、「編集」ボタンをクリックすると、そのレコードの編集画面が出るような場合
に、便宜上そのレコードを特定するためにサロゲートとしてUUIDとかを生成して振ってやるとか、そういうのくらいじゃないです？必要だから使うだけで、なんでも使いたがるヤツというのは、

www.nurs.or.jp/~ogochan/essay/archives/5398
みたいなところがあります。

 関数従属性に従って正規化するだけじゃないのかしら？