• ベストアンサー
※ ChatGPTを利用し、要約された質問です(原文:データベーススペシャリスト午後II問題 問2)

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

noname#156136の回答

noname#156136
noname#156136
回答No.2

申し訳ありません。 テーブル構造が間違っていると書きましたが、公式解答がそうなっていますね。 追加説明です。 部門  (部門コード[PK],部門名,所在地,電話番号,部門種類)  生産現場(部門コード[PK],生産物品,生産能力)  倉庫  (部門コード[PK],収容物品,床面積) とテーブルを設計すれば、一般的にはOKです。 ただ、この問題では26ページの設計方針(3)で、サブタイプの主キーを「拠点分類名で修飾した属性名」とする指示があります。 そこで、生産現場には部門コードとは別に「生産現場拠点コード」を付与して主キーとします。倉庫も同様です。その結果として、 部門  (部門コード[PK],部門名,所在地,電話番号,部門種類)  生産現場(生産現場拠点コード[PK],部門コード[FK],生産物品,生産能力)  倉庫  (倉庫拠点コード[PK],部門コード[FK],収容物品,床面積) という形の解答になります(FKは外部キー)。 生産現場と倉庫では部門コードが重ならないよう付与されているので、本来は部門コードを主キーにできます。 ただ、部門コードを見ただけでは、それが生産現場なのか倉庫なのか区別しにくいなどの事情があるのでしょう。冗長になることを承知の上で、生産現場拠点コードと倉庫拠点コードを付与しています。 先ほどの例ですと、次のようにします。 部門テーブル (101,"テレビ生産部","東京都●●区","03xxxxyyyy",0) (102,"洗濯機生産部","大阪府▲▲市","06xxxxyyyy",0) (501,"テレビ倉庫部","神奈川県▼▲市","045xxxyyyy",1) (502,"洗濯機倉庫部","兵庫県■■市","072xxxyyyy",1) 生産現場テーブル (A01,101,"テレビ","1000台/日") (A02,102,"洗濯機","2000台/日") 倉庫テーブル (B01,501,"テレビ",5000坪) (B02,502,"洗濯機",3000坪) この場合、生産現場拠点コードと倉庫拠点コードに同じ値が現れても問題ありません。

関連するQ&A

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

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

  • 平成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 [?????]に入るのはア~オの内どれになるか。 ア 転属した社員の所属部門を,変更することができない イ 新入社員を,登録することができない ウ 退職した社員を,削除することができない エ 同姓同名の社員を,登録することができない オ 配属者未定の新設部門を,登録することができない という問題があります。 答えは「オ」となっておりますが、これになる理由がさっぱりわかりません。 何故「配属者未定の新設部門」を登録ができないメカニズムがつかめず、 悩んでしまいます。新入社員を登録することができるのであれば、 できることだと思われるのですが。 ご教授の程お願い致します。

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

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

  • プライマリキー

    インターネットでプライマリキーを調べると、「行を一意に識別する列」という風に書いてあって、プライマリキーはテーブルに一つで、一意でなければならないというふうに書いてあるんですが、 例えば、複数拠点を持つ販売店があるとして、販売店のコードと拠点のコードの2つで、レコードを識別する際は、販売店コードと拠点コードはプライマリキーになるのでしょうか?

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

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

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

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

  • 概念データモデル

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

  • 帝国データバンク企業IDを1社で複数持っている意味

    こんばんは。 ある企業について色々思う事があり、帝国データバンクのホームページでサーチしてみました。 すると、同じ会社なのにTDB企業コードが3つありました。住所と業種からしても全く同じ会社です。 ちなみに、企業コードについては下記の説明がありました。 企業識別コードによる名寄せの必要性 取引先管理を行なう上で、データベース登録した情報を企業単位にまとめていないと、企業単位の取引履歴管理ができず、取引先全体に占める企業単位の販売実績等の動向把握ができません。 同一企業に対する売掛金等の総額が把握できず、その企業に設定している与信限度額をオーバーしてしまいます。 同一企業に対する営業状況全般を把握できず、ダイレクトメールを二重に発送するなど、マーケティングを効率的に行なえません。 企業単位にまとめるために商号を利用すると、取引先企業が商号変更した場合、旧商号のまま修正されない取引データがあると名寄せができません。 取引先に同商号の企業が存在すると、商号では企業を特定できないため名寄せできません。 単純な入力ミス、商号に関する入力ルールの不徹底により同一企業が複数パターンで登録されるため名寄せができません。 TDB企業コードの利用 こうした問題を解消するのが1社=1コードで設定されるTDB企業コードです。 TDB企業コードを利用するとそれぞれの取引について、企業識別コードを抽出キーとして一元化できるため、企業単位の取引実態を把握しやすくなります。 商号・住所変更前後の取引を、企業識別コードをキーとして一元管理できます。 登録上の共通ルールがないデータベース間でも、企業識別コードで紐付けることによりデータベース連携を実現できます。 企業識別コードとしてのTDB企業コードを利用することで、効率的に名寄せができ、取引先管理が正確に行なえるようになります。 TDB企業コードは、当社が独自に取材・収集した企業情報に加え、各種公的情報を基に1社=1コードとして厳格に設定され、原則変更されません。そのため、各種データベース管理用の企業識別コードとして、多くのお客さまにご利用いただいています。 2010年11月現在、当社ホームページ(「TDB企業サーチ」)上で検索対象となっている企業コードは、195万社です。 上にもありますが、1社=1コードとして厳格に設定されとあります。 別に帝国データバンクの言っている事を疑っている訳ではなく、何故同一企業なのに3つもIDを振られる事が出来るのか、というのが疑問です。まぁ理由は私がこれを調べる原因になった事でもあらかた想像はつくのですが…。 どなたかお知恵を拝借出来れば幸いです。 宜しくお願いします。

  • オラクルデータベース抽出方法について

    現在、Oracle11gを使用したデータベースより、データを抽出するSQL文を作成してるのですが、「障害管理情報.受付者」、及び「障害管理情報.二次対応依頼先」がブランクの場合、主キーの一貫番号と一致したデータを抽出する条件を回避するSQL文がうまく動かなくて困っています。 SQL文は、下記と成ります。 SELECT 障害管理情報.管理NO , 障害管理情報.情報区分 , TO_CHAR(障害発生日時, 'YYYY/MM/DD HH24:MI') , TO_CHAR(障害受付日時, 'YYYY/MM/DD HH24:MI') , 障害管理情報.部門 , T_サイト情報.顧客名 , T_サイト情報.サイト名 , 連絡先情報.姓 || ''' ' || 連絡先情報.名 , T_ユーザ情報.姓 || ''' ' || T_ユーザ情報.名 , 障害管理情報.状況 , 障害管理情報.現象 , 障害管理情報.原因 , 障害管理情報.対策 , 障害管理情報.備考 , 障害管理情報.対策完了日時 , T_サイト情報.部門サイトコード , 障害管理情報.受信区分 FROM 障害管理情報 , T_サイト情報 , 連絡先情報 , T_ユーザ情報 WHERE ( CASE WHEN 障害管理情報.受付者コード Is Not Null THEN 障害管理情報.受付者コード Else 連絡先情報.一貫番号 End =連絡先情報.一貫番号) AND (CASE WHEN 障害管理情報.二次対応依頼先コード Is Not Null THEN 障害管理情報.二次対応依頼先コード Else T_ユーザ情報.一貫番 End =T_ユーザ情報.一貫番) このSQL文のCASE条件文で、「障害管理情報.受付者コード」、及び「障害管理情報.二次対応依頼先コード」 がブランク(Null)の場合、「連絡先情報.一貫番号=障害管理情報.受付者コード」、及び「T_ユーザ情報.一貫番号=障害管理情報.二次対応依頼先コード」の条件を回避するように、記述しているのですが、エラーが発生します。「’’T_ユーザ情報"."一貫番号":無効な識別子です。」とのメッセージがでます。何か、記述が間違っているのでしょうか。このCASE条件文でエラーが出ているのは確かです。又、他に良い方法があればご教示願います。 ちなみに、CASE条件文を下記の条件文にすると、うまくいくのですが、「障害管理情報.受付者コード」、及び「障害管理情報.二次対応依頼先コード」がブランク の場合、ブランクが主キー「連絡先情報、及びT_ユーザ情報」の一貫番号にないため、該当するデータが抽出できません。 下記条件文: ( 連絡先情報.一貫番号=障害管理情報.受付者コード ) AND ( T_ユーザ情報.一貫番号=障害管理情報.二次対応依頼先コード )

  • データベーススペシャリスト試験H22年午後I問3

    表題のデータベースの保守・運用に関する問題について質問です。 問題文に出てくるバックアップの「差分」と「増分」の意味が逆の気がします。 テーブルの回復にすべてのバックアップが必要になるのは「増分」の方ですよね??? 詳しい方、アドバイスいただけると助かります。

専門家に質問してみよう