下記のような回答をした場合、何か問題文とマッチしない誤りはありますでしょうか？


模範解答は下記なのですが、
① 問題文に「分野ごとに定められた表示順」とあるので、分野に表示順をもたせるほうが自然だと考えた
② 投稿番号は電子会議内の連番との記載は特にないので、単体でユニークな番号と考えた

という経緯です。

---

また以下余談ですが、実務で1対多を表現する際、
- 私の回答のように子エンティティ側には別途ユニークなキーを用意してPKとし、外部キーとして親のPKをもたせる
- 模範解答のように子エンティティ側を複合主キーとして、親PKを含める
のどちらが多いのでしょうか？ケースバイケースでしょうか？

長くなってしまいすみませんが、よろしくおねがいいたします。

この投稿は投稿者により削除されました。(2022.10.03 23:02)

大事な情報が漏れていました… 問1  です。
（運営者様、もしお見かけしましたらタイトルを「H29 午後1 問1 設問1 (2) 関係スキーマ」にご変更いただければ幸いです）

  分野名の表示順になってしまうのと、表1の投稿番号に当てはまらなくなるのかと思います。

  単独主キーと複合主キーという事でしたら、複合主キーを全く使わない設計は無いよねぇという派閥に属しています。設計図の半分くらいには複合主キーが含まれていないと・・・と思うのですが、うーん、どうなんでしょうね。

サロゲートキーだけでアンチパターン本らしくやってける現場がなかなか想像つかないですね。
ブログとかだとできるとかあったりするけど、なかなかそれはきびしい

模範解答のように子エンティティ側を複合主キーとして、親PKを含める派。

実際は、外部設計を固めた後ですら平気でDB構造を変えてきやがるので、前者のようなサロゲートだと実はユニークにされると・・・とか平気でほざかれる上に下手すると主キーすら設定できずにプログラム側で主キーを置いたような意識をするだけとかバカげたことが頻発するので、
SQLアンチパターンのサロゲートだけは夢物語だと思っています。ユーザはいってもきかないので、泣く子とユーザには勝てねえってやつです。

「分野ごとに定められた表示順」という表現はたしかにわかりにくいですね。
「その分野内で割り振られる表示順」というような書き方にしてほしいものです。
イメージとしては下記のような感じになると思います。

【分野】

分野番号┃分野名
━━━━━━━━
1001    ┃国語
1002    ┃数学


【電子会議】

電子会議番号┃            議題              ┃分野番号┃表示順
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    9001    ┃2021年●●大学の古文について  ┃1001    ┃1
    9002    ┃2019年■■大学の現代文について┃1001    ┃2
    9003    ┃2020年●●大学の漢文について  ┃1001    ┃3
    9004    ┃2022年△△大学の数列について  ┃1002    ┃1
    9005    ┃2020年◇◇大学の微分について  ┃1002    ┃2

皆様さっそくありがとうございます。

まず自分の回答の問題点について理解できました。お恥ずかしながら 表1 を全く見ずに解いていました…そこに全て書かれてましたね、失礼しました。
ストラトスさん、わかりやすい例示ありがとうございました！

以下、単独主キーと複合主キーについて…

> 設計図の半分くらいには複合主キーが含まれていないと・・・と思うのですが、うーん、どうなんでしょうね。

> サロゲートキーだけでアンチパターン本らしくやってける現場がなかなか想像つかないですね。

なるほど、複合主キーの方がよく使われる、という感覚なのですね。参考になります。

例えば本問だと、上記のように 投稿 では複合主キーが使われていますがユーザを見ると単一主キーになっていて、主務グループIDをFKで持っていますね。
理由としては
- ユーザ は 主務グループ を移動する可能性がある
- 兼務グループ や メッセージ送信先 など他のリレーションシップもあるため、複合主キーだとカラムが増えて煩雑
を想像しました。

> 実際は、外部設計を固めた後ですら平気でDB構造を変えてきやがる

というのも踏まえると余計に、サロゲートキーのような独立したキーをとりあえず設定しておくほうが、後々に候補キーやリレーションシップが変わっても対応しやすそうに素人目では思えたのですが… 実際に手を動かして、運用して、体感したいところですね。

 「SQLアンチパターン」 知らなかったので、そちらも読んでみようと思います！ありがとうございます。

>兼務グループ や メッセージ送信先 など他のリレーションシップもあるため、複合主キーだとカラムが増えて煩雑

元々実務のテーブルはカラムが元からやたら多いので、大して気にならんのですね。そういう設計のをひきずって使う（＝ほんとうに初期からスクラッチ状態で入ることが少ない）とかよくあるので、スクラッチ分はまじめに考えますが、スクラッチ出来ない分ははきだめのままです。

まあ、たしかにスクラッチ分をサロゲートでやった（設計案で出した）こともありました。
ユニークキーをチマチマ変えていくとか色々あるでしょう・・・が、
やれ直感的でないとか触る側のことを考えろとかとかく名ばかりの保守性を期待するので、
せいぜいサロゲートが使えるのは元々自動採番が使える番号だけで主キーになるようなやつ（製造の現場の原価管理とか、そういうの）とかくらいかもしれんですね。
いまはSAPっちゅうのとかで管理したデータをRDBに持ってきたりとかして、SAPはSAPでサロゲートか？っていうとたしかにサロゲートくさいところはあります・・・が、
サロゲートキー（自動採番の番号を複数組み合わせる）を複数主キーにしてみたり、色々「・・・」と思うことはなくはないので、
ここは経験してあきらめをおぼえます。

大手ベンダの案件のDBチームの仕事を見ると、午後2みたいに要件定義から起こしてるか？っていうと、案外そうでもないんですよねえ。元にするシステムの再利用とかで、効率性を考えないからそのままズルズルいってしまうのかもしれない。おまえただ昔の外部設計パクっただけだろ、みたいな。