学生 科目 課題のリレーション

質問

テーブルの設計をしています。
現在はACCESS2003で設計しており、ゆくゆくはSQLSERVER2005にしたいと考えています。

今現在あるテーブルは学生・科目履修・科目です。
順に1対多、多対１でリレーションを作成しています。

これに課題テーブルを作成したいのですが、どのようにリレーションすればいいか、分りません。以下課題の条件です。
・課題には課題コードがあります。
・1科目には必ず複数個の課題があります。
・科目により課題の個数は違います。
・学生１人１人に課題の点数を入力する必要があります。
私なりに１週間ほど考えたのですが、結局は科目履修とは別に、学生・実習・課題のようにテーブルを定義して１対多、多対１のリレーションしかないのでしょうか？
しかしあまりにひどいリレーションになってしまいます。入力も時間がかかります。もっときれいに理論的に整理されたリレーションが作れないでしょうか？
お手数でしょうが、ご教授ください。

回答No.2

jamshid6

リレーショナルデータベースでテーブルを分割するのは正規化するためです。
正規化の目的は入力の効率化・省力化ではなく、データの整合性維持です。
テーブルを分割すると一般的に入力負荷は増えます。しかし逆にいうと、ここまで分割しないとデータの整合性が失われる可能性があるということなのです。

今回のエンティティ群から部分関数従属と推移的関数従属を排除して第三正規化すると、質問者さんの結果になります。
これは質問者さんにとっては「理論的」ではないということでしょうか。

どうしてもテーブルの数を抑えたいという場合、（許されるならばですが）科目と課題を階層データと見做して、統合してしまうという方法はあるにはあります。
・学生　　（学生ID*, 氏名）
・科目課題（科目課題ID*,科目課題名,親科目課題ID)
・履修実習（学生ID*,科目課題ID*,点数）
この場合、科目課題テーブルは親科目課題IDがないものが「科目」で、テーブル内にリレーションを持つ状態（自己参照）になります。
ただ、実務上は扱いやすい構造とはいえないでしょうね。

補足

jamshid6様　本当にありがとうございます。
テーブルの構造で本当にいろいろ悩んで最終的に上の結果になったのですが自信がなくて、本当に困っていました。回答を見てこれでよかったんだと思いました。

正規化はデータの整合性維持ですね。肝に銘じます。

回答No.1

anmochi

・科目[科目コード(PK),科目名]
・学生[学生ID(PK),氏名]
・科目履修[科目コード(FK→科目.科目コード),学生ID(FK→学生.学生ID)]
に対して、
・課題[課題コード(PK),科目コード(FK→科目.科目コード),課題名]
・実習[課題コード(FK→課題.課題コード),学生ID(FK→学生.学生ID),実習日,点数]
の形で特に問題ないと思います。なんら論理的じゃないという風には思えません。課題は科目に対してぶら下がる必然性があり、実習は課題と学生に対してぶら下がる必然性がありますよね。
　全テーブルで見るからごちゃごちゃしているように見えるだけで、「側面」ごとにテーブルレイアウトを見れば問題ないと思います。学生が科目を履修するから科目履修というリレーションが存在し(科目-科目履修-学生の側面)、学生が科目の課題をこなしたから実習結果が記録される(科目-課題-実習-学生の側面)。
　入力の手間がかかるのはテーブルレイアウトとは別問題なのではないでしょうか。まずテーブル構造を見ると、学生と科目と課題がマスターテーブルとなり、実習はトランザクションテーブル(ジャーナルテーブルやログテーブルとも言われます)になりますよね。科目履修はマスターリレーションの場合もジャーナルリレーションの場合も考えられますが、ここではマスターリレーションとさせていただきます。つまり実習結果登録画面なるような画面があった場合、入力(画面初期表示処理)はマスターデータを取得し、(点数を初期値0として)実習テーブルに入れる内容をずんどこずんどこ作る処理を行い、点数をオペレーターに設定させた上で出力(登録処理)として実習テーブルに実際にずんどこ書き込んで行く、というIPO(Input-Process-Output)になるのが妥当なところだと思いますが、課題コード別に学生一覧を表示して点数を入れていく方式(以下「課題別点数一覧」)と学生ID別に課題一覧を表示して点数を入れていく方式(以下「学生別点数一覧」)ではだいぶ入力のしやすさが変わってくると思います。まさか課題と学生を組み合わせた一覧が画面に出てきてずんどこずんどこ点数を入れていくなんて画面ではないでしょう？　課題別点数一覧と学生別点数一覧はどちらが優れているというモノではなく運用によって変わってきますし両方の機能を用意する場合もある事でしょう。

　長々と書きましたが結局私が言いたいのは「問題なのはテーブルレイアウトじゃなくて入力画面デザインではないか」という事です。
　リレーションが複雑そうに見えるのは全く問題ではなく、それを解決するためにビュー(MS-ACCESSでは「クエリー」)があるという事ですね。テーブルは「データを格納するのに最も適した形」を考え、ビューは「データを取得するのに最も適した形」を考えるといいましょうか。

　蛇足ですが、今設計段階なのであれば、後でSQL Serverにアップサイジングするよりも最初からSQL Serverをバックエンドにしておく方が良いと思います。SQL Server 2005はすぐインストールできますし、最初からADPで開発する事を強くお勧めします。