DBの主キーについての質問です。

日本の国公立中学校で児童達・生徒達の情報を管理する為に、
もしデータベースを設計するのでしたら、
どんな正規化が望ましいのかを知りたいですので、
過去に私が伺いました内容を踏まえまして、再度の質問を致します。

そこで、一先ず、下記の通りに3つのテーブルを考えました。
(1)学生ID/氏名/緊急連絡先/現住所/保護者氏名
(2)学校ID/学校名/所在地/代表電話番号/創立時期
(3)学校ID/教師ID/教師名/担当役職名

そして、更に纏める為に、次の3テーブルを追加しました。
(4)年度/学年/クラス/教師ID/性別/出席番号/学生ID
(5)学生ID/試験実施日/教科番号/取得点数/平均点
(6)教科番号/教科名/教師ID

でも、いざ纏めてみますと、残念乍ら、
(4)～(6)のテーブルの主キーがどれなのかが私には分からなくなりました。

従いまして、非常に恰好が悪いのですが、
それぞれの主キーを教えて頂けませんでしょうか？

No.6 ベストアンサー 回答者： jjon-com 回答日時： 2012/09/05 15:41

ANo.2，ANo.3，ANo.4に賛成。

http://oshiete.goo.ne.jp/qa/7600713.html の私の回答ANo.2 の最初の段落


(4)クラステーブルとクラス名簿テーブルを分離すべき。
教師というのが，クラス担任・副担任のようにクラスに紐づけられたものなのか，
教師Aはある学生を担当，教師Bは別の学生を担当のように学生に紐づけられたものなのか，
によってテーブル設計も主キーも変わります。

(5)試験テーブルと試験受験テーブルを分離すべき。
同一試験だけれどクラスによって実施日が異なる，一部の公欠学生のために同一試験を日程変更して実施した，などのニーズがあります。試験という実体に対しては試験コードを割り当てるのが常套。

(6)教科テーブルと教科担当テーブルを分離すべき。
同一教科を複数の教師が担当することがあります。教科名は教科という実体に紐づけるものであり教科担当講師に紐づける必要はありません。

この回答への補足

有り難う御座います。

主題に即した回答に感謝を致します。

補足日時：2012/09/06 00:09

No.5 回答者： jacob-wk9 回答日時： 2012/09/05 15:22

前質問みたいで書き飛ばします。

すいません。
主キー（あるいは重複しないインデックス=unique）と考えれば、分かりやすいでしょうか。
恐らく学生ＩＤは、未来永劫Uniqueだと思います。（私は大学のうん十年前の学生番号を覚えています）

まずこれを大基に考えます。
学生ＩＤ（学生さん）に関する、複数の情報を持つ場合、これは別のキーを作ってあげます。


さて、Uniqueキーは、必ずしも実際に運用されている番号である必要はありません。
情報対象数にもよりますが、オートナンバーなどを利用する方法もあります。

（１）の学生ＩＤは、　Ａ中学校とＢ中学校の学生番号が被る場合があります。よって、uniqueではないことが考えられます。
　　　学生に唯一の番号を振る必要があります。
　　　オートナンバーでもいいですし、意味を持たせるなら、文字列にして学校ＩＤがＸ桁＆学生番号がＹ桁でも良いでしょう。
　　　（１）は、学生ＩＤ／氏名／（略）／学校ID/学生番号みたいな感じになります。
　　　　（１）と（２）を学校IDでリレーションします。


（２）中学校の学校情報ですね。

（３）これはあとからテストの成績とヒモ付けするための中学教師の担当教科でしょうか。役職と担当教科が別であれば、いちおう担当教科欄も付け足したほうがいいです。そして、教師ＩＤも唯一である必要があります。
　　　オートナンバーでもいいですし、意味を持たせるなら、文字列にして学校ＩＤがＸ桁＆教師番号がＹ桁でも良いでしょう。
　　　（３）は、教師ＩＤ／教師名／担当役職名／（担当教科）／学校IDになります。

　　　　（２）と（３）を学校ＩＤでリレーションします。

（４）は学年毎の情報ですね。
性別、学年変わると変わりますかね。今の中学は複雑ですね。特に配慮が不要であれば性別は(1)に。
　　　　　　この場合の教師ＩＤは担任ということで良いでしょうか。

　　　　　　このテーブルはテーブルの一意性の都合上、ユニークなデータがないことから、先頭に割と無意味なオートナンバーＩＤをつけます。
(4)ID(オートナンバー)/学生ID/年度/学年/クラス/出席番号(そういえば中学ってクラス内の1～４０くらいの番号だった)/教師ID
　　　　　　　（１）－（４）を学生IDでリレーション　（３）－（４）を教師ＩＤでリレーション

（５）は学生のテストの成績ですね。
　　　　（５）にも唯一のキーがありませんから、オートナンバーでＩＤを振ります。”ＳcoreＩＤ”にしておきますか。
（５）ScoreID(オートナンバー）/学生ID/試験実施日/教科番号/取得点数/(平均点ってなにの？個人全科目?全体?たぶん、場所はここじゃないです)
　　　　　　　　　　(1)-(5)を学生IDでリレーション (5)-(6)を教科番号でリレーション
（６）　　教科番号が唯一キーでいいと思います。　ただ、全中学校の「英語I」の成績となった場合は、少し意味合いが変わってきます。「教科名」という文字列でフィルターを掛けるのは、もし記入した文字列にタイプミスがあった場合、統計が取りづらいからです。
　　　　(6)教科番号／教科名　　これを全中学校共有のマスターテーブルにします。
Ａ中学校の教科番号１番は誰先生が担当しているか。
　　　　これは、（５）テーブルに情報持たせるのかなぁ。（５）ScoreID/(略)／教科番号/教師ID/
　

なんか、わからなくなってきました（笑）　言葉で伝えるのはむずかしいですね。

この回答への補足

有り難う御座います。

転校にも対応させ得るだろうと予想しまして、
『出席番号』の他に、一意の『学生ID』を準備したつもりでいました。

でも、3年間に渡って同じ学校に同じ生徒が留まっている状況が、
日本社会では趨勢を占めていますので、
其の『学生ID』とは違うコードを各生徒達に紐付けませんと、
此のDB設計は簡単に行き詰まるのですね。

補足日時：2012/09/06 00:09

この回答へのお礼

(4)の『性別』を(1)の側へと移す正規化の方が比較的に望ましい、
との旨の御指摘を賜りましたので、じっくりと考えさせて頂きました。

但し、当質問の締め切りの後で畏れ入りますが、
其の過程の途上で、私は別の見解に至りました。

そもそも、学生毎の家庭事情の都合で苗字が変わる可能性さえもが御座いますので、(1)の内容は(4)の各キーによって一意の値に絞られ難い、
と私には思われますが、(4)は違う様です。

つまり、もし(4)へと『学期』が追加されましたら、
其の場合には、たとえ転校が有ったとしましても、
『年度』・『学期』・『学生ID』が主キーになって、
『学年』・『クラス』・『(担任)教師ID』・『性別』・『出席番号』が一意に決まりますでしょう。

従いまして、矢張り、
『性別』は(4)のテーブルの属性なのではないでしょうか？

因みに、下記URLのページでも御指導を賜れますと、
非常に助かります。
http://okwave.jp/qa/q7684686.html

お礼日時：2012/09/07 02:46

No.4 回答者： ShowMeHow 回答日時： 2012/09/05 15:04

では、言い方を変えてみよう。

（4）を考えるにあたっては、
どの時点で、どの学校にどういうクラスが存在するのか？
とそれぞれの生徒がどのクラスにいつからいつまで所属しているのか？

を別に考えないと、正規化がうまくできなくなり、メインキーをどうつけたらよいのかはわかりにくくなるのではないでしょうか？

この回答への補足

有り難う御座います。

地方自治体全体で分かる通し番号としまして、
生徒IDを割り当ててみたつもりでした。

でも、確かに『学期』を更に追加させませんと、
年度途中での転校を盛り込めませんね。

補足日時：2012/09/06 00:09

No.3 回答者： FEX2053 回答日時： 2012/09/05 14:46

何を管理したいのかはっきりしない気がするんですが？

管理したいものがはっきりしないので、正規化した各DBの
主キーが判らなくなっているんです。

メインになるテーブルは、「最終的に管理したいデータ」に
直結していないと、実際の実行時に効率が悪くなります。

この回答への補足

有り難う御座います。

そもそも、最初の時点では、
学生の個人名の絞り込みの為のDBを考えてみたのですが、
重複し得る内容の存在に気付きましたので、
其処への配慮を踏まえた編成を行なっています内に、
収拾が着かなくなって参りました。

此処迄の正規化は不毛なのでしょうか？

補足日時：2012/09/05 14:55

No.2 回答者： s806099d 回答日時： 2012/09/05 14:42

ちょっとDBの役割が見えないです。

簡単に(1）～（６）のテーブルの名称、何を管理するテーブルかを説明してください。
本来役割が分かっていれば主キーがわからないということはありえないはずです。

この回答への補足

有り難う御座います。

又、後で下の枠へも追記を致しますが、
此の質問は次のURLのページからの続きです。
http://okwave.jp/qa/q7679251.html

補足日時：2012/09/05 14:47

No.1 回答者： ShowMeHow 回答日時： 2012/09/05 14:38

素人の私が言うのもなんですが、

インデックスに関してはもう少し、
構造を考え直すしてからにしましょう。
（4）転校にどのように対応するのですか？

この回答への補足

有り難う御座います。

そうですね。

但し、現状の私の学習の段階では、
其処迄の余裕が御座いませんでしたから、
畏れ入りますが、今回には、
此処迄の内容での御容赦を賜れますと、助かります。

補足日時：2012/09/05 14:43

この回答へのお礼

(4)へと『学期』を追加しますと、御指摘の通りに、
『血液型』等のセンシティブ情報さえをも其処へ盛り込める様に、
当該DBが改良されますね。

因みに、次のURLのページに此の話題を発展させましたので、
其処でも御指導を賜れますと、幸甚に存じます。
http://okwave.jp/qa/q7686382.html

お礼日時：2012/09/08 05:54