• ベストアンサー

データベースの正規化のところで質問があります。

データベースの正規化のところで質問があります。 会員とビデオがエンティティの例なんですが、 「レンタルビデオ店で会員が1度に複数のビデオを借りた場合、ビデオの情報が繰り返し項目になる」という説明が分かりません。 宜しくお願いします。

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

  • ベストアンサー
  • mitoneko
  • ベストアンサー率58% (469/798)
回答No.2

 仮に、会員情報も、貸し出し情報も全部一つのテーブルで登録するとします。  必要な項目は・・・  会員番号・氏名・住所・電話番号(他、個人情報。)  貸し出したビデオのタイトル(又は、ビデオIDコード)・貸出日・返却期限  といったところでしょうか。  さて、このテーブルの一行(一レコード)は、一人一行となるでしょう。  レンタルビデオ店は、大概複数のビデオが借りられますね。と一人で2本3本と借りていく人がいますし、何本貸すことになるかも解りませんね。人によっては一本だし、他の人は5本くらいかも・・・  では、一行に、何本になるか解らないビデオIDや貸出日・返却期限を登録するには、どうしましょうか? ビデオID1・ビデオID2・ビデオID3・・・とフィールドを並べるのが一番に思いつく方法です。  これを繰り返し項目と言います。  ところで、フィールドはいくつ並べたらいいのでしょうか?今、店の規則で一人5本までとしているから、5つ?もし、隣接店との競争の関係で一人10本に改訂されたら、どうします?とっても拡張性に問題がありますね。これが繰り返し項目を嫌う理由の一つです。もう一つは、データの検索や集計がすごく面倒になります。(SQLに話が進まないと今は理解できないかもしれません。)  別の解としては、一人一行を放棄して、ビデオテープ毎に一行を作る方法もあるでしょうが、そうすると、今度は、同じ人の住所や電話番号を山ほど登録する羽目になります。  会員さんが引っ越しをして住所が変わったら、いったいいくつのレコードを更新することになるのでしょうね。ぞっとする話であることだけは確かです。  どちらも、データベースの設計では避けるべきとされる事項です。これを考えるための方法論の一つが正規化です。  この物語の次の作業は、会員情報テーブルと、貸し出しテーブルの二つのテーブルに分離して(更にビデオ情報が要るから、3つかな?)・・・と続くのでしょうが、その辺はもう一度続きを読んで見てくださいね。 

その他の回答 (1)

回答No.1

レコードを増やすという事です。RDBでは、その「ビデオの情報」で別テーブルを作りなさい。 となりますね。ID(シーケンス番号)は設計によりますが、1回のレンタルで一つのテーブル、そこに「ビデオの情報」のIDを入れることになりますね。 その逆でも可能ですが。

関連するQ&A