• ベストアンサー

SWの平成15年・午後2の問題で

設問3での答えが疑問です。 答えは以下の通りとなっていますよね? (主キーは【】でくくってあります) 会議室(【会議室番号】、会議室タイプ) 予約簿(【予約番号】、【使用時間帯区分コード】、利用者番号、会議室番号、使用予定日) 会議室料金表(【会議室タイプ】、【使用時間帯区分コード】、料金) 時間帯(【使用時間帯区分コード】、使用時間帯) 利用者台帳(【利用者番号】、氏名、住所、電話番号) このとき、『予約簿』における「使用時間帯区分コード」は主キーなのでしょうか? 『予約簿』においては図2に例がありますが、これをみても使用時間帯については他の予約とかぶる部分があり一意性が無いと言えますよね? つまり主キーにはなりえないと思うのですが・・。 主キーとは一意性があり、かつNULL値を許さないという条件がありますよね? 『予約簿』以外でも『時間帯』以外では一意性が無いと感じるのですが・・。 まだ、主キーがはっきり分かっていないだけなのかもしれませんが、なぜ「使用時間帯区分コード」は主キーではないのでしょうか?

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

  • ベストアンサー
  • bnosuke-x
  • ベストアンサー率39% (43/110)
回答No.3

問題をちょっとしか見ていない上での回答です。 #2さんの言うとおりです。 予約番号と使用時間帯区分コードの二つを併せて初めて主キーになるということです。 こういう「複数の項目で成されるキー」を日本語では「複合キー」と言います。(だったと思います) 主キーが複合キーだったら「複合主キー」だったかな? 問題文より >(3)申込者が予約を承諾した場合,受付係は予約番号(予約ごとに一意),氏名,住所,電話番号,会議室番号,使用予定日,使用時間帯を予約簿に記入するとともに,会議室予約台帳へ予約番号を記入し予約登録を行う。 > なお,1件の予約は,1日限り,1室限りとする。使用時間帯については,複数指定できる。 の通りに予約簿テーブルに予約内容が登録されますが、この文章から、 1)[予約番号]は1件の予約に付き1つずつ 2)[予約番号」が同じで、[使用時間帯区分コード]の異なる レコードが予約簿テーブルに存在しうる。 と言うことを読み取らねばなりません。 (おそらく使用時間帯をまたいでの予約を見越しての仕様でしょう) 2)から、[予約番号]だけを指定してもこのテーブルからひとつのレコードを特定できるとは限らないということがわかります。 ですから、予約番号と仕様時間帯区分コードの2つがそろって初めて主キーとなるのです。 おまけ 「このテーブルの主キーはどれ?」と聞かれたら、 これを外したらレコードを確実に1つに特定できないよな・・・ と思う項目を全て挙げればよいのです。 問題文をよーーく読めばそう難しいことではないと思います。

その他の回答 (2)

  • bin-chan
  • ベストアンサー率33% (1403/4213)
回答No.2

> 最下部にリンクがあります。 過去問、みました。 > 予約簿(【予約番号】、【使用時間帯区分コード】、利用者番 と捉えられていらっしゃる部分に問題があります。 「予約番号」「使用時間帯区分」の2つを別々に主キーとするなら、表1の表記は「Y」ふたつでないとおかしい。 セル結合(で良いのか?)した上で「Y」と書いてありますよね。 「使用時間帯区分コード」は主キーの一部ではありますが、主キーそのものでは無い。 「予約番号と使用時間帯区分のセット」(コンポジットキーだったか?)こそが主キーです。

  • bin-chan
  • ベストアンサー率33% (1403/4213)
回答No.1

問題のリンクがどこかにありますかネ? 予約番号と使用時間帯区分が1:1ならそれでも良いでしょうが、ひとつの予約番号で複数の使用時間帯をとることができる(1:n)なら、【予約番号+使用時間帯区分】が主キーとなるのかも。 ここの部分が重要と思います。

mezasedaiken
質問者

補足

問題のリンクはあります。 直リンクは避けた方が良いと思いしませんでした。 googleにて、「ソフトウェア開発 過去問」と入力後一番上に表示されるページの最下部にリンクがあります。 (抽象的すぎてすみません)  本題に戻って、確かに問題文を見ると予約簿の図は1:nになっています。 1つの予約番号に対して複数の使用時間帯をとることができます。 この場合は使用時間帯区分も主キーになるんですか? 中には予約番号が違っても使用時間帯区分が同じ場合もあります。 この場合確かに予約番号に一意性があっても、使用時間帯区分には無いと思うのですが・・・。 もしよろしければ、重要ポイントの説明をお願いしたいです。 (1:nであれば、主キーになりえる理由です)

関連するQ&A

  • ER図について

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

  • データベーススペシャリスト午後II問題 問2

    平成23年春期データベーススペシャリスト午後II問題 問2設問番号なし(2)の問題について (設問数が1問のため設問番号はありません。) 概念データモデルを完成させる問題ですが、ひとつどうしても納得のいかない箇所があります。 「部門」と「生産現場」「倉庫」の関係と、「取引先」と「部材メーカ」の関係です。 解答では、「部門」がスーパータイプ、「生産現場」と「倉庫」がサブタイプで、 「取引先」がスーパータイプ、「部材メーカ」がサブタイプとなっています。 (画像の赤丸の部分です。) どう考えてもこの2つそれぞれの関係は、スーパータイプサブタイプではなく、外部キーでマスタを参照する1対1又は1対多の関係だと思うのですが・・。 各テーブル構造は以下です。 部門〔部門コード(主キー)、部門名、部門種類〕 生産現場〔生産現場拠点コード(主キー)、部門コード(外部キー)、現場区分〕 倉庫〔倉庫拠点コード(主キー)、部門コード(外部キー)、倉庫区分〕 取引先〔取引先コード(主キー)、取引先名、取引先種類〕 部材メーカ〔部材メーカ拠点コード(主キー)、取引先コード(外部キー)、物流費負担率〕 ※テーブル構造は問題と解答から引用しています。 問題文で関係する箇所を引用します。 --------------------------------------------------------------------- ・部門は、部門コードで一意に識別される。部門には、いくつかの種類がありその分類は、部門種類によって識別される。 ・取引先は、取引先コードで一意に識別される。取引先には、いくつかの種類があり、その分類は、取引先種類によって識別される。 ・在庫把握やものの移動の管理を必要とする場所を拠点と呼ぶ。 ・拠点は、Y社の一部の部門又は一部の取引先からなら在庫管理業務上の組織の呼称であり、拠点コードで一意に識別される。 ・ある拠点が、Y社の部門である場合は、Y社のどの部門に相当するかを識別するために、Y社の部門コードが与えられている。 ・拠点は、生産現場、倉庫、部材メーカの3つに大別され、拠点区分によって識別される。 --------------------------------------------------------------------- すみませんが誰かわかる方教えてください。 問題 http://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2011h23_1/2011h23tokubetsu_db_pm2_qs.pdf 解答 http://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2011h23_1/2011h23tokubetsu_db_pm2_ans.pdf

  • 平成19年度 春期 午後問02について

    ある情報システム開発会社は,顧客であるA社の組織情報を関係データベースにすることになり, まず,部門と所属についての設計を行った。A社の部門は,英字2文字からなる部門コードで 一意に識別できる。A社の社員は,4けたの数字からなる社員番号で一意に識別でき, 必ず一つの部門に所属しているものとする。図1にA社の部門と所属の情報を示す。 括弧内は,部門コード又は社員番号である。 ----- |営業|-----(8612)関さん |経理|-----(8713)菅さん |(EG)| |(KR)| ----- 図1 A社の部門と所属の情報 設問1 次の記述中の に入れる正しい答えを,解答群の中から選べ。  情報システム開発会社の初級技術者B君は,案1と案2の二つの関係データベースの構造を考えた。 しかし,上級技術者から,案1と案2の両方で,A社の組織を表すには不都合な[????]という現象が起こり, 案1では,更に同姓同名の社員を登録できないという不都合な現象も起こることが指摘された。 そこでB君は,指摘に基づき,案3を考えた。 案1~3を,図2に示す。下線は,その項目が主キーであることを表す。 ●案1 組織 ---------------------------------------- | 氏名 | 社員番号| 部門名 | 部門コード | |------ ---------------------------------------- ●案2 組織 ---------------------------------------- | 社員番号 | 氏名| 部門名 | 部門コード | |---------- ---------------------------------------- ●案3 部門 ------------------------ | 部門コード | 部門名 | |------------ ------------------------ 社員 -------------------------------- | 社員番号 | 氏名 | 部門コード | |---------- --------------------------------        図2 案1~3 [?????]に入るのはア~オの内どれになるか。 ア 転属した社員の所属部門を,変更することができない イ 新入社員を,登録することができない ウ 退職した社員を,削除することができない エ 同姓同名の社員を,登録することができない オ 配属者未定の新設部門を,登録することができない という問題があります。 答えは「オ」となっておりますが、これになる理由がさっぱりわかりません。 何故「配属者未定の新設部門」を登録ができないメカニズムがつかめず、 悩んでしまいます。新入社員を登録することができるのであれば、 できることだと思われるのですが。 ご教授の程お願い致します。

  • データベーススペシャリスト平成23年午後II問2

    データベーススペシャリスト平成23年午後II問2について質問です。 (4)の関係スキーマを完成させる問題で、v、w、yの解答が腹に落ちません。 これらの解答では、”入庫元拠点コード”属性の代わりに外部キー”出庫番号”属性が入っています。 この場合、”出庫番号”属性があれば、”入庫元拠点コード”属性以外の”入庫拠点コード”、”部品部材番号”属性についても外部キーから参照できるため、不要とならないでしょうか。 ある解説によると、 「人為的なミスや不慮の事故などにより、出庫の記録と実績とが異なる場合がある。具体的に言うと、入庫拠点、対象部材、及び、入庫数である。実績を確認できるのは入庫の時点である。したがって、これらの属性を入庫側に持たせる必要がある。」 とありましたが、上記を想定するならば、”入庫元拠点コード”属性も入庫側にもたせる必要があると思うのですが…。 もやもやが晴れず、是非ご回答頂ければと思います。

  • データベース22年度 午後I 問2 設問2

    ”会員”テーブルの項目は、NULL不可となることが静的に決まらないので、列ごとにNOT NULL制約を定義できない。そこでNULL不可であることを動的に管理する”項目チェック”テーブルを図のように定義した。・・・ というNULL不可を動的に管理する”項目チェック”テーブルの空欄埋め問題で、解答は以下の通りでした。 項目チェック(一連番号,会員列名称,会員区分,職業区分) 一連番号が主キー しかしながら一連番号がどうして必要なのか分かりません。 たとえ新たな職業区分を追加したとしても{会員列名称,会員区分,職業区分}を主キーにしておけばまかなえると思うのですが。 一連番号がサロゲートキーにしか思えないのですが、どなたか解説お願いいたします。

  • 概念データモデル

    少し抽象的な質問になるのですが、以下のテーブルがあったとします。 聞きたいことを絞るため全テーブルは記載していません。 ※[]主キー 店舗([店舗番号],店舗名,住所) 店舗構成部門([店舗番号],[部門コード]) 勤務時間帯([店舗番号],[勤務コード],勤務開始時刻,勤務終了時刻,休憩時間,実労働時間) 部門勤務時間帯([店舗番号],[部門コード],[勤務コード]) 部門最少人数([店舗番号],[部門コード],[勤務コード],[曜日コード],最少人数) 休憩申請([店舗番号],[従業員番号],[年月日]) ・・・・・・・・・・・・・・・・・・・・・ このようなテーブル構成の時、店舗テーブル以外の表に関して、店舗番号がわかれば、店舗テーブルは一意に決まります。よってリレーションとして、店舗テーブルから店舗テーブル以外のテーブルに対して、→(矢印)のマークが記載されることとなりますか??(矢印の先が多関係)

  • リレーショナル型データベースについて

     このような問題についてです。  以下に示す学生の成績表をリレーショナル型データベースで管理することとした。第3正規化の結果できあがるリレーションのスキーマを表の下に示した「スキーマの表現例」に倣って記述しなさい(1つとは限らない)。正規化されたリレーションスキーマの名称は適切なものを指定すること。また、主キーには○を施すこと。なお、学籍番号、科目番号は、それぞれ学生と科目を一意に識別する値である。学生は1つの学部に所属している。学部名は一意であり、所在地も学部によって一意に決まっているものとする。担当科目教員も課目によって一意に決まっているものとする。 成績表 (学籍番号、学生氏名、所属学部名、学部所在地、科目番号、科目名、担当教員名、成績) ※スキーマ表現例  商品を表すリレーションが3つの属性、商品コード、商品名、価格から構成されているとき、「商品(商品コード、商品名、価格)」と表す。ここで、商品コードが主キーである。 自分なりに考えた答えがこれです。 学生(○学籍番号、学生指名、所属学部名) 学部(○所属学部名、学部所在地) 科目(○科目番号、科目名、担当教員名) 成績(○学籍番号、○科目番号、成績) になりました。これでよいでしょうか。よろしくお願いします。

  • FileMakerのUniqueKeyについて

    FileMakerに一意性のあるKeyや 主Key(PrimaryKey)を複数組み合わせた複合キーの設定はできるのでしょうか? MicroSoft OfficeのAccessにはそれがあるのは知っているのですが、 FileMakerはどうなのでしょうか? 今、新しいDatabaseを作ろうとしていて、 (今までDatabaseを作ったこともないのですが。。) 色々調べた結果、私にはAccessはちょっと難しいかなとおもい、FileMakerのほうが使い(組み)易そうかなと思っています。 解らないなりに、Databaseを考えた結果、多分、主キーやサブキーが設定されていないとDataの抽出が難しそうなのです。 例えば見積情報 見積見出しテーブル    キー項目 項目名        属性    主キー  見積ユニーク番号   数値          見積日         Date 見積金額        数値            ......     参照キー顧客ユニーク番号   数値   参照先:顧客担当者マスター     参照キー顧客担当者番号   数値    参照先:顧客担当者マスター           ..... 見積明細テーブル    主キー  見積ユニーク番号   数値    主キー  アイテム番号      数値           商品コード       数値            商品名         文字          数量          数値          数量単位       文字                   単価          数値          金額          数値          納期          Date          ..... 例えば見積明細テーブルの様に見積ユニーク番号とアイテム番号で一意にしたいと考えています。 見積明細の抽出には見積ユニーク番号を使用しますが、アイテム番号の重複は避けたいです。 また、顧客担当者マスターの様に顧客ユニーク番号と顧客担当者番号を組み合わせて、参照する事は可能でしょうか? FileMakerの体験版でトライしてみたのですが、解りませんでした。 可能であれば設定方法等も教えていただけると有りがたいです。 あまりDatabaseやコンピュータに詳しくはなく、まだまだ勉強中なのですが、 できれば早急にどのDatabaseSoftwearを使うかを決めたいと思っています。 助けていただければ嬉しいです。 もし、他の質問で同じようなことを聞いていらっしゃる方がいれば、 そちらのURLを教えていただければ助かります。 FileMakerは購入前ですが、バージョン11を検討しております。 どうぞよろしくお願いいたします。

  • テーブルのアイテム番号を一意にするには?

    今PHPとデータベースを使ってメールの送受信をするというものを作っています。 テーブルの主キーはu_id(そのメールを送信または受信したユーザ)と、m_id(一意のメールの番号)です。 m_idに一意の番号をつけていくにはどうしたらいいのでしょうか? ・メールを削除することも出来ます。 ご回答の程よろしくお願いします。

    • ベストアンサー
    • PHP
  • 関係データベースについて(ITパスポート)

    ITパスポートの勉強をしているのですが、その中で関係データベースについて参考書やネットで検索をしてもまったく理解ができません。 下記の2点の問題についてですが、回答の解説を読んでも理解が全くできず、なぜこの答えが正しいのかがわかりません。 できるかぎり詳しく解説をして頂ければと存じます。 (1) 問)関係データベースにおいて主キーを指定する目的はどれか? 答)主キーに指定した属性(列)で、レコード(行)を一意に識別できるようにする (2) 問)関係データベースを利用する際に、データの正規化を行う目的として、適切なものはどれか? 答)データが重複したり、データの更新の際に矛盾が生じたりしないようにする。

専門家に質問してみよう