ER図でクラスのライバル関係を表現する方法は?

このQ&Aのポイント
  • データベースの勉強を始めたばかりの人が、クラスのライバル関係をER図で表現する方法について質問しています。
  • 生徒テーブルとライバルテーブルを作成し、生徒とライバルの関係を1対0以上のリレーションで結びつける方法について考えています。
  • ただし、異なる生徒同士のライバル関係に対してどのようにテーブルを定義すればよいかわからないと悩んでいます。
回答を見る
  • ベストアンサー

こんな場合のER図はどうなりますか?

こんにちは。データベースの勉強を始めて間もない者です。 例えば、ある中学校の1つのクラスの振る舞いを、ER図で表現することを考えます。各生徒をあらわす「生徒」テーブルを作ります。主キーは出席番号とします。 主キー以外には、名前、生年月日、得意科目、、、などを入れるのですが、「ライバル」という属性も入れたいと思います。自分(今、対象としている生徒)から見てライバルだと思うクラスメイトにあたるものです。 生徒によっては0人だったり多数だったりするので、「生徒」テーブルから出し、「ライバル」テーブルを作り、「生徒」:「ライバル」=1:0以上のリレーションをはります。「ライバル」テーブルの主キーは親の生徒の出席番号(外部キー)とライバルだと思われた生徒の出席番号のペアでいいや、と思ったのですが、ここで問題に気づきました。 出席番号1さんがライバルだと思っているのが、出席番号3さん、5さんとします。3さんは1さんのことをライバルと思っていませんが、5さんは1さんのことをライバルだと思っています。この時の「ライバル」テーブルは、主キーに1と5のペアを持つレコードが2つできてしまって問題になるのでしょうか?それとも、外部キーが異なるので問題はないのでしょうか? 問題があるとすると、どのようにテーブルを定義すればよいのでしょうか。さっきの例では「ライバル」テーブルに1と3のペアをキーとするレコードが1つできますが、これも「1から3へ」という意味が消えないような設計をしたいのですが、よくわからなくなりました。

  • aneja
  • お礼率93% (379/405)

質問者が選んだベストアンサー

  • ベストアンサー
  • jjon-com
  • ベストアンサー率61% (1599/2592)
回答No.1

> 出席番号1さんがライバルだと思っているのが、 > 出席番号3さん、5さんとします。 > 3さんは1さんのことをライバルと思っていませんが、 > 5さんは1さんのことをライバルだと思っています。 という関係は,「ライバル」テーブルに次の3行を登録すれば表現できます。 (user_id, rival_id) = ((1, 3), (1, 5), (5, 1)) (user_id, rival_id) = (1, 5) と (user_id, rival_id) = (5, 1) は,主キーの値はまったく別です。 ちなみに, 「ライバル」テーブルのrival_idが「生徒」テーブルの主キーを参照する外部キーであるのと同様, 「ライバル」テーブルの user_idも「生徒」テーブルの主キーを参照する外部キーです。 それから。 出席番号というのはクラス内の連番を指す概念ですか? であるなら。 変則的な理由で年度の途中で出席番号が変わる可能性もありえますし,1年→2年→3年の進級によっても出席番号は維持できません。学籍番号(学生番号)に代表される,入学以降変化しない識別値を「生徒」テーブルの主キーにすべきです。

aneja
質問者

お礼

こんにちは。早速のご回答、ありがとうございます。 >(user_id, rival_id) = (1, 5) と >(user_id, rival_id) = (5, 1) は,主キーの値はまったく別です。 ということで、当初考えた通りに作れそうで安心しました。 また、 >学籍番号(学生番号)に代表される,入学以降変化しない識別値を「生徒」テーブルの主キーにすべきです。 そうですね。その年度以降も使えるようにするには学年全体で考えた方がよさそうですね。中学校には学生番号は無いので、入学年度かクラス番号を組み合わせて、考えようと思います。 アドバイス、ありがとうございました。

関連するQ&A

  • ER図について

    現在、資格の勉強をしているのですが、 E-R図についてわからないことがあります。 ホテルの客室予約システムのER図です。 ER図のなかの必要と思われる部分だけを抜粋します。 カレンダ((P)宿泊日、シーズン) 予約((P)予約番号、会員番号、宿泊日、ホテルコード、部屋タイプ、予約室数) 料金((P)ホテルコード、(P)部屋タイプ、(P)シーズン、料金) (P)は主キーで複数あるときはすべてあわせて主キーです。 なお、ホテル、部屋タイプはそれぞれ複数あり、 同じ部屋でもシーズンによって値段がことなります。 シーズンにはオン、ミドル、オフのみっつがあり、 カレンダ表には、日付と、それに対応するシーズンが かくのうされています。なお、一つの予約番号に対して1日分の宿泊で、複数日宿泊するときは、複数の 予約番号が必要となります。 この3つの表のリレーションは、 カレンダ 1対多 予約 多対1 料金 となっています。 私は今まで、1対多のカーディナリティは、多の側の 表の行が決まれば1の側の行も1意にきまるだけでなく、必ず、主キー、外部キーで連結されるものと 思っていました。  料金表とカレンダ表の関係で見ると、ホテルコード、部屋タイプまでは共通していますが、シーズンが 足りず、これでは結合条件不足かと思います。 料金表を一意に特定できないかと思うのですが。  確かに、予約表の宿泊日が分かっていればシーズンもおのずと分かり、料金表を一意にとくていできます。そういう意味では正しいかと思うのですが。 長々となってしまいもうしわけありません。 要するに、属性や主キーの決まったER図における リレーションやカーディナリティは、必ず外部キーと 主キーをとおして連結されているのでしょうか。  もし、それ以外の場合もありましたらお教えください。よろしくお願いいたします。

  • ER図でリレーションを決めるときの二つの疑問

    ER図でリレーションを決めるときの二つの疑問 (1)ER図において、「科目:学生」などの関係は「多:多」になっています。  その関係はできるだけ排除するようにし、間に「受講状況」をはさみます。  「科目:受講状況」=「多:1」、「学生:受講状況」=「多:1」に分解します。  というように、「多:多」のリレーションはなるだけ、「1:多」に分解したほうが  よいと書かれていました。これは、なぜでしょうか? (2)また上記のような「科目:受講状況」=「多:1」、「学生:受講状況」=「多:1」の  リレーションで「受講状況エンティティ」は学生とは「学籍番号」で、科目とは  「科目コード」で紐付けられていましたが、その二つはいずれも「主キー」になっていました。  「多」ではさまれるエンティティは主キーは二つにしたほうがよいと記述されていました。  これはなぜでしょうか? 以上、宜しくお願いします。

  • ER図の外部キー

    はじめまして ER図の書き方でFK(外部キー)として記載できるもしくは そう呼べるのはinnodbでの環境に限るのでしょうか? mysqlでmyisamにて構築しているのですが 例えば注文テーブルに商品IDや顧客ID、受注スタッフID、発注スタッフID等の カラムがあったとして、そらぞれのカラムは商品テーブル、顧客テーブル、 スタッフテーブルのプライマリーキーです。 この場合、商品IDは外部キーと呼べるのでしょうか。 また発注スタッフIDが必ず登録されているとは限らないのですがこれも外部キー と呼べるのでしょうか。 よろしくお願いします

    • ベストアンサー
    • MySQL
  • ER図について

    ER図を書く練習をしています。 就職するために会社に申請し、審査後に応募者(申請者)を受け入れる(合格)か拒否するか(不合格)を決めるケースを想定してER図を描きました。焦点は、「合格/不合格の情報をどのテーブルに持たせるのがよいか」です。添付のURLに(1)、(2)の2つのケースを考えて書いてみました。いずれのテーブルもものすごく簡単に書いたので突っ込みどころは満載だと思いますが、あくまでも、合格/不合格の情報をどこに持たせるかだけに特化したものと考えてください。 (1)http://www.dotup.org/uploda/www.dotup.org15911.jpg.html (2)http://www.dotup.org/uploda/www.dotup.org15912.jpg.html 申請書テーブルは、申請者から受け取った書類を管理するテーブルです。受け取った日や、本件のステータス、結果を応募者に送信したかなどの情報を持ちます。イベント系(トランザクション系)のテーブルです。 (1)のやり方 申請者テーブルには申請者の情報そのものを書類から入力するリソース系(マスタ系)のテーブルです。名前、年齢、前職。。その他諸々を保持します。ここに、合格か不合格かをok_ngというbooleanで持たせることとします。 (2)のやり方 (1)と同様、申請者のテーブルはあるのですがok_ngという属性を持たせずに、代わりに別リソース系テーブル「合格者」を作ります。申請者と合格者の関係は1対1です。お互いがお互いのプライマリキーを参照する外部キーを持ちます。申請者テーブルと合格者テーブルのオプショナリティは必須対任意とします。つまり、申請者のうち、合格した人のみが合格者テーブルに登録されるということです。 上記2点の設計は、どちらも有効でしょうか?有効だとするとメリット、デメリットなどありますでしょうか? (2)のやり方を書いた理由は、とある本に飛行機の「乗客テーブル」と「マイレージプログラム加入者テーブル」のER図があり、その関係が丁度本件の「申請者テーブル」と「合格者テーブル」のような関係になっているのを見た事があるからです。コメント等あれば宜しくお願いします。

  • 2つのaccessテーブルのレコード数を合わせたい

    一つは200レコードあるリンクテーブルです。 このリンクテーブルとあるテーブル(Bテーブル)を合体させたいと思いました。 そのあるテーブルは主キーであるIDとチェックボックスの2つのフィールドだけです。 このB]テーブルの主キーとリンクテーブルの主キーとリレーションでつなげました。 しかし、そのBテーブルはレコードが全く無いのでチェックボックスが出て来ません。 リンクテーブルのレコード数分、手動で作成したらチェックボックスと組み合わさります。 これでは、毎回毎回リンクテーブルのレコード数を数えて同じ分だけBテーブルでレコードを作成しなくてはいけません。 自動で同じだけのレコードを作ることはできますでしょうか? VBAでレコード数を数えて・・・・とかするのでしょうか?

  • Access2002 参照整合性について

    テーブル間にリレーションシップを設定する場合、リレーションテーブル側に主テーブルにないレコードがあると参照整合性を設定できないにも関わらず、「結合の種類」で「3」(リレーションテーブル側の全レコードと主テーブル側の同じ結合フィールドのレコードだけを含める)を選べるのは何故でしょうか。 参照整合性を設定できた時点で、リレーションテーブル側には主テーブルにないレコードは無いということだと思うのですが・・・。 よくわからなくなってしまいました。 お答え、よろしくお願いいたします。

  • アクセスのフォーム、コードを入れると名前が出るのはなぜ?

    アクセス初心者ですが、フォームを作成時、疑問に思って考えるほど混乱してしまいました。 例えば、 Aテーブル:日付、店コード、売上のフィールドを作る。(主キーなし) Bテーブル:店コード、店名(主キーは店コード) リレーションは店コード(B)→店コード(A)に結び、すべての整合性にチェック それぞれのテーブルに、数件のデータを入力 この状態で入力フォームをウィザードで作ったのです。 Aテーブルからすべてのフィールド、Bテーブルから生徒氏名を選び、ウィザード任せにフォームを作りました。 このとき、できたフォームで出席番号を入れると何もしないのに、自動的に生徒氏名が入ってしまいます。 人に聞くと当たり前でしょ、みたいに言われたのですが、なんとなくわかるようでわかりません。どうして自動的に入るのでしょうか?ふりがなの自動入力みたいな設定をしたというのならわかるのですが、何もしてないのに。 すみません、自分でも、リレーションとか整合性とかについて、あるいはまだフォームとテーブルの関係について、よくわかってないせいなのだろうとは思うのですが、そこの所も合わせ、どなたか、分かりやすく教えていただけますか?宜しくお願いします。

  • Sqliteリレーションについて2

    連続投稿すみません。 ■利用環境 Sqlite3.3.5 ■質問 リレーションの概念について、理解できない部分があり 質問させてください。 下記のようなテーブルが1:Nのリレーション関係 にあった場合、お互いのテーブルにリレーションを 貼っていれば、テーブルAのある行データを削除した ときに、テーブルBの同外部キーに該当するデータも 連動して削除されるのでしょうか? それとも、自身で削除する必要があるのでしょうか? テーブルA(主キー蔵書ID) 蔵書ID 購入日 書名 テーブルB(主キー貸し出しID 外部キー蔵書ID) 貸し出しID 蔵書ID 貸し出し日 借りた人 

  • 一対一の追加が出来ません。

    今回つまづいたのは、一対一のリレーションのテーブルの中で新規にレコードが追加できないことです。 テーブルをA,B,Cとします。メインとなるのがAです。B,Cは機密上テーブルを分けてあります。 新しくAのレコードを追加してそのレコードのBもしくはCにレコードを追加しようとすると下記のようにエラーになります。 「テーブル '<テーブル名>' にリレーションシップが設定されたレコードが必要なので、レコードの追加や変更を行うことはできません。」 リレーションシップが問題のようなので全てのリレーションを一旦切断して(各クエリの接合も)、A,B,Cをつなげるクエリのみで行ってもこのようなエラーになります。 また、もともとあったAのレコードに対してのB,Cの入力はエラーが出ません。新しく作ったAレコードに対してエラーが出ます。 試験的にレコードを減らしており、Aには100件、B,Cには何も入れておりません。 クエリのリレーションは外部接合で行っています。 フィールドは以下のようになっています。 A:注文ID(主)、受付日、名前、金額 B:注文ID(主)、送付日、・・・ C:注文ID(主)、・・・ 助言宜しくお願いします

  • リレーションシップで一対多となる条件

    今Access2000を使っているのですが、 リレーションを組む際に、一対一と一対多になる違いを教えてください。 リレーションを組みたいのは、 主テーブルの主キー[登録CD]テキスト型 リレーションテーブル [登録CD]テキスト型 このテーブルの主キーはオートナンバーで[NO]としています いつも通りに作ってハズなのですが、 リレーションを組むと自動的に一対一になってしまいます。 リレーションテーブルになるためにフィールド数の制限などがあるのでしょうか? 宜しくお願いします。