H15(2003)アイテック公開模擬テスト午後Ⅰ問3 【DB設計】

部分関数従属性を指摘する場合の非キー属性に注意！

設問１（１）
主キーの識別、外部キーの指摘。

設問１（２）
第２正規形でない理由。発生時点の管理（非正規化の手法）。

非キー属性のうち、取引先コード・受注年月日は受注番号に関数従属することが
“受注”から明らかだが、発注年月日・納品年月日・請求年月日・入金年月日は、
具体的な説明がない。そのためこれら（発注年月日・納品年月日・請求年月日・入金年月日）
を回答に記述してしまうと思わぬ減点を食らうことになるので、「分からないことは書かない。」が鉄則である。

設問１（３）
第２正規形でなくても良い理由。

①性能向上（第３正規形にした場合に必要となる結合処理不要・結合演算不要）。
②時系列性の保持が行える。
③参照系であれば重複更新がない（一度設定されると変更されることはない）。

この場合は②である。

第２正規形でなくても良い理由を述べよ。と問われれば、
・商品名や単価が変わっても受注時点（発生時点）での商品名と単価で取引実績データを管理するためである。
・商品データに関する時系列性を保持するためである。

第３正規形にした場合の（構造上の）問題点を指摘せよ。と問われれば、
・商品名や単価が変わった場合、受注時点での商品名と単価が分からなくなる（参照できない）。
・商品名と単価が時系列管理されていない。
・最新の商品名や単価しか分からない（参照できない）。

設問２
１対多関係を見い出しテーブル構造を考える問題。

①既存のエンティティに属性追加
②独立のエンティティを追加

この問題は「テーブル追加」なので②。
多側のテーブルに１側の主キーを埋め込む。

設問３（１）
設問２で追加したテーブルを時系列管理したい場合に
追加すべき列名の指摘。設問３は、全て期間の管理に関する問題。

列名について特に条件がなければ、
発生時点の管理（年月日）でもいいが、「列名を２つ指摘せよ」とあるので、
期間の管理（開始年月日、終了年月日）を指摘する。

設問３（２）
設問３（１）で指摘した項目（開始年月日、終了年月日）についての
現時点を管理する場合の値の設定方法と期間（過去）を管理する場合の値の設定方法を指摘させる問題。現時点を管理する場合、終了年月日をナル値とすれば良いが、
ＡＬＬ‘９’でも問題ないと思う。

設問３（３）
設問３（１）で列名を追加した場合の主キーの指摘。

設問３（２）で現時点を管理する場合、終了年月日をナル値とする考えた場合は、
主キーに開始年月日を追加するが、
終了年月日にＡＬＬ‘９’を設定すると考えた場合は、主キーに開始年月日を追加してもよいし、終了年月日を追加しても良い。

H18午後Ⅰ問2 【DB設計】

本番と自宅では全然違う。落ち着いてやれば何も難しい箇所はない。
それにしても当問題で登場するテーブル数は、図４だけでも１５個もある。

設問１（１）
主キーの識別、外部キーの指摘。

設問１（２）
テーブル構造を考え、主キーの識別、外部キーの指摘。

設問２（１）
第２正規形でない理由。

“シフト勤務表”の部分関数従属性を指摘。
｛店舗番号、従業員番号、年月日｝→｛日休憩時間、日実労働時間｝に気付くかどうか。

設問２（２）
部分関数従属性の排除。第２正規形への分解。

“シフト勤務表”の部分関数従属性の排除。
①部分関数従属性に着目してテーブル分割する方法。勤務コードは縦持ち。
②勤務コード１、勤務コード２を横持ちにする方法。

※外部キー線は引く必要なし。年度により回答要求が微妙に変えてきているので
　設問は注意深く読む必要がある。

設問３（１）
時系列性の保持しないことによる問題点。

「～」が時系列管理されていない場合・・・「～」は、この設問の場合、所属部門・雇用区分
①最新の「～」しか管理することができない。
②過去の「～」を管理することができない。
③「～」が更新された場合、更新前の情報を参照することができない。

設問３（２）
時系列性の保持を考慮したテーブル構造。

雇用契約の内容を時系列保持するようにテーブル構造を考える。
設問２（２）同様、外部キー線は引く必要なし。

H17午後Ⅰ問2 【DB設計】

最近の問題は本当に素直というか問題条件がクリアになっているとつくづく感じる。

設問１（１）
定番問題
主キー・外部キーを指摘する問題。特にひっかけとなる箇所はない。

設問１（２）
テーブル統合する場合の利点。
・統合した“商品”の商品番号の一意性制約が保証される。
・“注文”の商品番号と統合した“商品”の主キーとの間に参照制約の設定が可能となる。

設問１（３）
定番問題
多対多関連を見つける→連関エンティティの作成

設問２（１）
定番問題
図４の“注文”の部分関数従属性に着目しテーブル分割を行う。

設問２（２）要注意！
設問を読み誤ると、“発送”と“発送明細”を作ってしまうことになるｗ
テーブルを追加しろとは書いてありません！
問題文より“注文”と“発送”の関係が、１対１となる。

設問２（３）要注意！
問題条件より“注文”と“発送”の関係が、多対１となる。
“注文”の発送日が冗長となるため、“発送”へ移動。
“注文”の発送番号は“発送”への外部キーとなるので残す。

H13午後Ⅰ問2 【DB設計】

設問１（１）
“利用明細”の利用会員番号に外部キーの破線を引いてはいけない。
“利用明細”の利用会員番号は家族全体の会員番号をあらわしており、
また、“会員”の家族会員番号１～４が横持ち構成であるため、参照制約を
設定できないことによる。縦持ち構成であれば参照制約は設定可能である。

設問１（２）
会員（会員番号、会員氏名、フリガナ、郵便番号、会員住所、生年月日、
　　　電話番号、引落口座、利用限度額、登録年、登録月、基本ポイント率、
　　　家族会員数）
※主キー線：会員番号
　外部キー線：なし
家族会員（家族会員番号、家族氏名、家族フリガナ、続柄コード、生年月日、
　　　　　利用者番号、会員番号）
※主キー線：家族会員番号
　外部キー線：会員番号、続柄コード

ここで注意すべき点は、“家族会員”の家族会員番号に本会員も含めなければ、
“利用明細”で参照制約を設定できない。そうすると、“会員”の
会員氏名、フリガナ、生年月日が冗長となるので結局以下のようになる。

会員（会員番号、郵便番号、会員住所、
　　　電話番号、引落口座、利用限度額、登録年、登録月、基本ポイント率、
　　　家族会員数）
※主キー線：会員番号
　外部キー線：なし
家族会員（家族会員番号、家族氏名、家族フリガナ、続柄コード、生年月日、
　　　　　利用者番号、会員番号）
※主キー線：家族会員番号
　外部キー線：会員番号、続柄コード

また、“家族会員”を通番方式を使って作成すると、
家族会員（会員番号、利用者番号、家族会員番号、家族氏名、家族フリガナ、続柄コード、生年月日）
※主キー線：会員番号、利用者番号
　外部キー線：続柄コード
家族会員番号は、候補キーであり、“利用明細”の参照制約は設定可能である。

設問２（１）
定番問題

設問２（２）
クレジットカード利用時に利用控えの請求額
を加算し、引落し時に当月請求額を減算する・・・４０／４０文字

設問３
設問の意図があいまいな感じがする。

「②品目の組合わせは、日単位に設定できること。」とあるが、
組合せ番号を再利用する場合と再利用しない場合でテーブル構成が変わると考えた。

・組合せ番号を再利用する場合・・・組合せ構成を日ごとに変えられる
特定品目組合せサービスポイント（組合せ番号、設定年月日、サービスポイント数）
※主キー線：組合せ番号、設定年月日
　外部キー線：なし
特定品目組合せ（組合せ番号、設定年月日、品目コード）
※主キー線：組合せ番号、設定年月日、品目コード
　外部キー線：なし

・組合せ番号を再利用しない場合・・・組合せ構成が変わるたびに組合せ番号が変わる
特定品目組合せサービスポイント（組合せ番号、設定年月日、サービスポイント数）
※主キー線：組合せ番号
　外部キー線：なし
特定品目組合せ（組合せ番号、品目コード）
※主キー線：組合せ番号、品目コード
　外部キー線：なし

◆蛇足
こんなのはいいのかどうか分からないが、こんなやり方は許されるだろうか。
サービスポントは固定で、品目コードの組合せだけ日ごとに管理したい場合、
特定品目組合せサービスポイント（組合せ番号、サービスポイント数）
※主キー線：組合せ番号
　外部キー線：なし
特定品目組合せ（組合せ番号、設定年月日、品目コード）
※主キー線：組合せ番号、設定年月日、品目コード
　外部キー線：なし
　

H8午後Ⅰ問3 【DB設計】

ひっかかった“貸出”の主キー

設問１（１）
“貸出”の属性は、｛書籍コード、利用者コード、貸出日、返却期限、返却日、貸出期間｝である。

書籍の貸出及び返却の状況は下記の通り。
①同じ書籍が２冊以上ある場合は、それぞれに別の書籍コードを付与する。
②利用者コードは、利用者ごとに一意。
③当日返却もある。
④同じ利用者が同じ書籍（同一書籍コード）を何回も借りることがある。
⑤返却日に再度貸出を行うことがある。
⑥一日で同じ利用者が同じ書籍（同一書籍コード）を「貸出→返却→貸出→返却」　を行った場合、貸出管理上は一回の「貸出→返却」として管理している。
⑦書籍コード、利用者コード、貸出日、返却期限は、貸出時に値を設定。
　返却日、貸出期間は、返却時に値を設定。　

｛書籍コード、貸出日｝だけで行を一意に特定できると思ったが、
同じ日に別の利用者が同じ書籍コードを借りた場合に行を登録できなくなってしまうため、｛書籍コード、利用者コード、貸出日｝が正しい。

設問１（２）
第２正規形でない理由。定番問題。

・部分関数従属の例を指摘するだけ。

設問１（３）
第２正規形が設計上妥当である理由。定番問題。

・一事実複数箇所を認めるということは→更新されないから。
　または、発生時点の情報を管理したいから。
・テーブル分割しない→テーブル結合処理が発生しない分、処理は速くなる。

設問２
“貸出”を“貸出管理”と“貸出履歴”に分割した場合の“貸出管理”のテーブル構成上の欠点を指摘する問題。
“貸出管理”テーブル構成は、｛利用者コード、書籍コード１、貸出日１、・・・、書籍コード６、貸出日６｝となっている。
図書館利用カードは不要といった記述から、返却処理の際には、各行の書籍コード１～６までを該当の書籍コードが見つかるまで検索し続けなければならない。

設問３（１）（２）
昔のＤＢ設計の設問３は、性能調整の問題が定番だったのか。
検索業務と更新業務における“貸出”テーブルに対するアクセス競合とその解決策を述べる問題。
検索処理と更新処理を矛盾無く（直列可能性を保障して）行えるようにするためにはどのようなＤＢＭＳを選定すれば良いのかを考える。

・ロックの粒度がレコード単位等、小さくできるＤＢＭＳを選定する。
・多バージョンデータベース機能を備えたＤＢＭＳを選定する。

H9午後Ⅰ問4 【DB設計】

難しい。。。うまくまとめられた気がしない（特に設問２）が、思いつくままに書くと・・・

設問１（１）
・一度に２つ以上の眼鏡を購入した場合
・破損や視力変化によりフレーム、レンズを単独で購入した場合
→ここは簡単

設問１（２）
・フレームとレンズの組み合わせの管理（関連）がないため
・フレームとレンズは単独で管理されており眼鏡の単位で管理されていないため

設問２（１）
・顧客に販売した商品を眼鏡の単位で管理できるようになるため
・顧客とフレームで関連付けを行うようにするため

設問２（２）
眼鏡に対する補修履歴を販売テーブルを参照せず時系列で管理できるようにするため

設問３
“眼鏡”のレンズ商品番号に値を設定しなくてもタプルを追加できるため。
→ここ間違えた。レンズ商品番号を必ず設定すれば交換前のフレームは特定可能。

H9午後Ⅰ問3 【DB設計】

本試験だったら設問３は白紙だろうか。。。

設問１（１）
発生時点の管理（非正規化の手法）の典型的な問題である。

設問１（２）
特に問題ないが、図１の利用明細書が会員番号単位に作成されていると誤認してしまい、“利用明細”の主キーに会員番号を含めてしまいそうになる。

設問１（３）
「第３正規形にせよ」と指示しているのだから、利用額、ポイント数は導出項目と判断し除外した。
しかし、経林書房の解答は、分割した“利用控え明細”テーブルに利用額、ポイント数を含めている。

・利用額、ポイント数を含めなければならないなら設問の指示が不十分。
・設問の指示通りに回答するなら、
利用控え（利用店名、利用番号、売場名、利用年月日、会員番号）
利用控え明細（利用店名、利用番号、品目コード、数量）

設問２
追加する列名
未引落し請求額累計

値の設定方法
クレジットカード利用時に、利用控えの請求
額を加算し、銀行口座に引落し処理時に、当
月請求額で減算する。・・・５０／５０文字


設問３
物理設計に疎いので回答できなかった。
レコード・クラスタリング（クラスタインデックス）についての理解が必要。

H10午後Ⅰ問5 【DB設計】

設問１
初期本数について
「各店に備える貸出用ビデオテープの保有本数を決め」

現本数について
「貸出状況の推移を見ながら各店のビデオテープの保有本数を減らしていく」

以上から、｛店番号、タイトル番号｝→｛初期本数、現本数｝と解釈した。

しかし、ss2004さんがおっしゃる通り、これら２項目の直接的な説明が無いので、
回答に際してはこれらを記述しないのがベターなのではなかろうか。

設問２
「返却時は、返却されたビデオテープのバーコードを読み取り返却年月日を記録する」と言う記述と、図１の貸出業務用シールの様式を見比べて気付くかどうか。

設問３
図３の貸出状況推移を表示するための項目を保持するテーブルを考える。

H11午後Ⅰ問1 【DB設計】

この問題は短時間で解くには辛いものがある。

設問１
Ｅ－Ｒ図を書かなければ解けない気がする。
頭でイメージするだけでは時間がかかってしまう。
“座席”がテーブルをあらわしていることをヒントに、
新たにテーブルを追加しなければならないことが分かる。

設問２
定番問題。
ただ、更新時異状を非正規化の理由に挙げさせる設問は他にないようなので、良い練習になった。

設問３
「教科ごとにクラス編成及び座席番号を定める」から、
一教科ごとにクラス編成及び座席番号を定めると解釈した。
従って、“クラス”テーブルに教科を追加したが、経林で確認する限り「科目」とは、４教科／２教科を区別する区分のようなものらしい。
また、「クラス名は、現行のままとする。」が何を言いたいのか読み取れなかったが、“クラス”テーブルは変えるなとでも言いたいのだろう。

H12午後Ⅰ問1 【DB設計】

設問２
異なる薬番号で同一の「効能／副作用など」を管理するには、２つ方法がある。

・串刺し方式を使って、分類番号を追加する
・自己参照を使って、ある(親)薬番号を追加する

設問３
最初は
（１）の２種類の組み合わせを
※依存リレーションシップ
注意事項／副作用（薬番号１、薬番号２、注意事項／副作用など）
主キー：薬番号１、薬番号２　とした。
しかし、（２）は（１）で回答したテーブルに列を一つだけ追加して、３種類以上の組み合わせを管理する構造にしなければならない。

そこで、（１）の回答を
※非依存リレーションシップ
注意事項／副作用（分類番号、薬番号１、薬番号２、注意事項／副作用など）
主キー：分類番号　とし、
（２）は、通番を追加し、
注意事項／副作用（薬組合せ番号、通番、薬番号１、薬番号２、注意事項／副作用など）
主キー：薬組合せ番号、通番　とした。
例えば、通番を１から始まる連番とした場合で、
薬１～薬３の組み合わせを管理したい場合には、
連番１のレコードには、薬１（薬番号１）、薬２（薬番号２）を管理し、
連番２のレコードには、薬３（薬番号１）を管理すればよく、薬番号２はナル値を
設定できる。