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

このQ&Aのポイント
  • 概念データモデルの問題で、部門と生産現場、倉庫の関係と、取引先と部材メーカの関係について疑問がある。
  • 現在の解答では、部門がスーパータイプであり、生産現場と倉庫がサブタイプとされているが、外部キーを使った1対1または1対多の関係ではないかと思われる。
  • テーブル構造には、部門、生産現場、倉庫、取引先、部材メーカの5つがあり、それぞれのテーブルの属性が明示されている。
回答を見る
  • ベストアンサー

データベーススペシャリスト午後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

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

  • ベストアンサー
  • mizukix
  • ベストアンサー率100% (1/1)
回答No.4

確かに,この問題は,vanilla87さんがおっしゃるとおり,「部門」と「生産現場」「倉庫」,「取引先」と「部材メーカ」,で,1対1の関係になります。 問題文〔在庫管理業務の分析結果〕1.在庫管理業務に関する組織 に, (4)拠点は,Y社の一部の部門又は一部の取引先からなる在庫管理業務上の組織の呼称 とあります。 つまり,拠点というのは,在庫管理業務を行う組織のことで,部門又は取引先と同じ単位です。1対多の関係ではないところに注意が必要です。 そして,スーパータイプ,サブタイプは,1対1の関係の一種です。 全体を包含するスーパータイプの中に排他的なサブタイプがあるときに,それを切り出すことができます。 今回の場合,例えば部門では,問題文に 1.(1)部門には,幾つかの種類があり,その分類は,部門種類によって識別される。 とあり,その部門種類で,部門は「生産現場」「倉庫」および「拠点以外の部門」に分けられます。 ですので,これらを部門のサブタイプとして識別することが可能です。 そのうち,「拠点以外の部門」については,特に特有の属性はないので,わざわざ記述する必要はありません。 (書いても誤りではないとは思いますが) 同様に,取引先についても,取引先種類で,「部材メーカ」と「部材メーカ以外の取引先」に分けられます。 ですので,サブタイプとして2つを識別し,そのうち固有の属性がある「部材メーカ」のみを,サブタイプとして記述します。 以上です。 。。。とはいえ,この問題文を読んだだけで,部門,取引先のサブタイプを識別するのは,かなり難しいです。 解答例を見て,「こういう風に考えるんだ」という学習の材料にすればいいのかな,と考えています。

vanilla87
質問者

補足

mizukixさん回答いただきありがとうございます。 (3)在庫把握やものの移動の管理を必要とする場所を拠点と呼ぶ。 (4)拠点は、Y社の一部の部門又は一部の取引先からなる在庫管理業務上の組織の呼称であり、拠点コードで一意に識別される。 3では、拠点は「場所」ととれ、4では「組織」ととれますよね・・・。 今回質問させていただいた最大の目的は、公式解答に納得がいかないというもは勿論ですが、「スーパータイプとサブタイプの考え方や理解が間違ってたの?!」と不安になったので再確認の意味が大きかったです。 お二方にご回答いただき、スーパータイプとサブタイプにつきましては納得できましたので、この問題はあくまで試験問題とその解答として捉えることにします。 お手数をとらせてしまい感謝します。 ありがとうございました。

その他の回答 (3)

noname#156136
noname#156136
回答No.3

たびたび、すみません。これで終わりにします(回答を修正できればいいのですが)。 この問題では、スーパータイプ「拠点」に対して、サブタイプ「生産現場」「倉庫」「部材メーカ」を設けているのでした。そのため、テーブル構造は 拠点(拠点コード[PK],拠点区分,事業所コード)  生産現場 (拠点コード[PK],…生産現場だけに必要な非キー…)  倉庫   (拠点コード[PK],…倉庫だけに必要な非キー…)  部材メーカ(拠点コード[PK],…部材メーカだけに必要な非キー…) となります。ただし、26ページの設計方針(3)で、サブタイプの主キーの呼称を「拠点分類名で修飾した属性名」にするよう指示があるので、 拠点(拠点コード[PK],拠点区分,事業所コード)  生産現場 (生産現場拠点コード[PK],…生産現場だけに必要な非キー…)  倉庫   (倉庫拠点コード[PK],…倉庫だけに必要な非キー…)  部材メーカ(部材メーカ拠点コード[PK],…部材メーカだけに必要な非キー…) にしています。 生産現場と倉庫については、部門のサブタイプでもあるので、先ほどの回答のとおり、部門コードでも一意に区別できます。拠点コードでも部門コードでも一意に区別できるので、もし部門キーを主キーにしたなら、拠点コードが外部キーになります。ご質問のとおり、生産現場と倉庫に関しては、拠点コードと部門コードは1対1の対応となります。 ※生産現場拠点コードと倉庫拠点コードがに同じ値があってもよい、というのは誤りです。訂正します。

vanilla87
質問者

補足

keijimさん詳しく回答いただきありがとうございます。 私が一番腑に落ちない点は、問題文と一般的な認識から「倉庫と生産現場は『場所』であり、部門は『組織』」と考えたのですがどうなんでしょう。 そこから間違ってるのでしょうか。 スーパータイプサブタイプは、「数種類に分類される場合、共通する部分をスーパータイプ、それぞれ独自の属性をサブタイプ」と理解しています。 例えば、以下のような場合がわかりやすいと思うのですが、 車仕様(車種コード(PKEY)、グレード、価格)  セダン車仕様(車種コード(PKEY)、独自の属性)  ワンボックス車仕様(車種コード(PKEY)、独自の属性)  軽車仕様(車種コード(PKEY)、独自の属性) どれも「車」であり、スーパータイプとサブタイプはイコールですよね。 今回の問題に関して、「拠点」がスーパータイプ、「生産現場」「倉庫」「部材メーカ」がサブタイプはとても理解できます。 同じ「場所」ですから。 しかし、倉庫と生産現場は『場所』であり、部門は『組織』だと考えるとスーパータイプサブタイプとするのは不適切だと思ったのです。 仮に「部門」を「場所」と考えスーパータイプサブタイプとするにしても、主キーは同じでないとおかしいと思うのですがどうなんでしょう。 26ページの設計方針(3)で、サブタイプの主キーの呼称を「拠点分類名で修飾した属性名」にするよう指示に関しては、主キー外部キーの持たせ方ではなく、あくまで「属性名のつけ方」の指示であると理解しています。 倉庫と生産現場は『場所』であり、部門は『組織』だとして、外部キーで参照するなら、スーパータイプサブタイプは適切だとどうしても思えないのですが・・・。

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坪) この場合、生産現場拠点コードと倉庫拠点コードに同じ値が現れても問題ありません。

noname#156136
noname#156136
回答No.1

そのテーブル構造は間違っています。スーパータイプとサブタイプの関係を理解されていないと思います。 =============== 「部門」は、「生産現場」と「倉庫」に分類できます。しかし、分類しなくてもいいです。 分類しない場合のテーブル構造は、こうなります。[PK] は主キーです。 ※話を分かりやすくするため、問題文と異なる属性で説明します。 部門(部門コード[PK],部門名,所在地,電話番号,生産物品,生産能力,収容物品,床面積) ・部門コード,部門名,所在地,電話番号………生産現場でも倉庫でも必要な属性です。 ・生産物品,生産能力………生産現場だけに必要な属性です。 ・収容物品,床面積………倉庫だけに必要な属性です。 =============== ここに、生産現場部門のレコードを入れるとしたら、こうなります。 (101,"テレビ生産部","東京都●●区","03xxxxyyyy","テレビ","1000台/日",NULL,NULL) (102,"洗濯機生産部","大阪府▲▲市","06xxxxyyyy","洗濯機","2000台/日",NULL,NULL) また、倉庫部門のレコードを入れるとしたら、こうなります。 (501,"テレビ倉庫部","神奈川県▼▲市","045xxxyyyy",NULL,NULL,"テレビ",5000坪) (502,"洗濯機倉庫部","兵庫県■■市","072xxxyyyy",NULL,NULL,"洗濯機",3000坪) 生産現場部門と倉庫部門で重複しないよう、部門コードを割り振っていますので、これで問題ないです。 しかし、生産現場部門のレコードでは収容物品,床面積に NULL が入るし、倉庫部門のレコードでは生産物品,生産能力に NULL が入るので、無駄ですし、見た目も美しくありません。 =============== そこでサブタイプの登場です。 主キー →→→ スーパータイプでもサブタイプでも同じです。 スーパータイプの非キー →→→ すべてのレコードに必要な属性を残します。必要なら、サブタイプの種類を表す属性を追加します。 サブタイプの非キー →→→ そのサブタイプだけに必要な属性を移します。 そうすると、正しいテーブル構造はこうなります。 部門  (部門コード[PK],部門名,所在地,電話番号,部門種類)  生産現場(部門コード[PK],生産物品,生産能力)  倉庫  (部門コード[PK],収容物品,床面積) 主キーはすべて「部門コード」であることに留意してください。 ただし、意味は変えずに、次のように呼称だけ変更しても構いません。 部門  (部門コード[PK],部門名,所在地,電話番号,部門種類)  生産現場(生産現場コード[PK],生産物品,生産能力)  倉庫  (倉庫コード[PK],収容物品,床面積) 呼称を変更しただけですので、生産現場コードと倉庫コードに同じ値は使えません。 =============== 先ほど考えたレコードをここに入れると、次のようになります。 部門テーブル (101,"テレビ生産部","東京都●●区","03xxxxyyyy",0) (102,"洗濯機生産部","大阪府▲▲市","06xxxxyyyy",0) (501,"テレビ倉庫部","神奈川県▼▲市","045xxxyyyy",1) (502,"洗濯機倉庫部","兵庫県■■市","072xxxyyyy",1) 生産現場テーブル (101,"テレビ","1000台/日") (102,"洗濯機","2000台/日") 倉庫テーブル (501,"テレビ",5000坪) (502,"洗濯機",3000坪) NULL 値がなくなり、見た目もすっきりしました。 サブタイプには、スーパータイプに足りない属性だけ入れるのです。 くどいですが、スーパータイプとサブタイプの主キーは同じです。同じ値の主キーどうしを結び付けて参照します。外部キーではありません。

関連する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

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

専門家に質問してみよう