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

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

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

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

  • ベストアンサー
  • 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