Database Systems Engineer Examination

H17午後II 問1
機械式駐車場設備メンテナンス業務

設問３（１）
　駐車場設備単位の点検実績は全件保持するが，点検結果項目別の点検結果については，異常時のものだけを保持するスキーマ設計にしている。この方法で，正常時及び異常時とも管理可能である理由について
　駐車場設備単位の点検実績は全件保持＝「駐車場設備点検」はある。
　正常時は「部位装置点検結果」と「検出異常」がない。

解答例
駐車場設備点検の主キーを持つ部位装置点検結果・検出異常が存在しなければ，それぞれ部位・点検項目は正常と判断できるため。（５９文字）
※異常時のものだけを保持するスキーマ設計にしているが，この方法でも正常時のデータ登録が可能である理由
　とも読めなくも無い。。属性＠修理区分に“正常”を追加するとかｗ

設問３（２）（ａ）
同音異義語を指摘すれば良いかと。
解答例
部位装置点検項目の開始年月日と点検項目の開始年月日は同音意義語であるため参照関係を設定できない。（４８文字）

設問３（２）（ｂ）
解答例
テーブル“点検項目”の属性“開始年月日”をテーブル“部位装置点検項目”の“開始年月日”と同意にし，新たにテーブル“点検項目”に属性“正常条件開始年月日”を主キーの構成列として追加し，列として“正常条件終了年月日”を追加する。（１１２文字）
「“”」と“正常条件終了年月日”は文字数稼ぎ。

H17午後II 問1
機械式駐車場設備メンテナンス業務

設問２（２）
要件を整理し，出動目的と属性値の決定に関するデシジョンテーブルを完成させる。
出動目的は，表４ 出動目的一覧の出動目的からそのまま引用する。

埋めやすいものから手を付ける。
ｆ）　緊急呼出し年月日にＸがあるのはこれだけなので，出動目的は「緊急呼出し」
ｇ）　よく分からず，とりあえず保留
ｈ）　修理指示メーカ番号のＸと完全に一致するので，出動目的は「メーカ指示修理」
ｉ）　提案番号のＸと完全に一致するので，出動目的は「提案修理」
ｊ）　前回出動番号のＸと完全に一致するので，出動目的は「継続出動」
残るは「定期点検」のみ。よって，ｇ）は「定期点検」

解答例：設問２（２）
　ｆ）緊急呼出し
　ｇ）定期点検
　ｈ）メーカ指示修理
　ｉ）提案修理
　ｊ）継続出動

設問２（３）
要件実現の検討（未対応指摘，対応方策記述）

要件１：出動目的別の出動回数の把握
　出動→出動内訳←出動目的
　特に問題なく，対応可能。
　（目的別の出動回数合計は，本当の出動回数の合計と一致しない点には注意が必要・・・問題には関係ないが）

要件２：出動目的別部位装置別修理実績の把握
確認すべき項目は
① 出動目的→出動内訳←出動→・？・→駐車場設備修理
② 「修理」と「出動」の業務的な関係

表3「メンテナンス作業における出動指示書と報告書提出の関係」と業務の説明より確認する。
・定期点検：定期点検の結果によって，必要な修理を実施する。
・自発的部品交換：修理報告書はないが交換部品を登録する。
・メーカ指示修理
・緊急呼出し：不具合箇所の特定と修理
・継続出動：定期点検結果による修理及び緊急呼出しによる修理の2日目の作業
・提案修理

疑問１：「修理」＝「修理報告書」なのか，自発的部品交換を含むのか
疑問２：継続出動時のエンティティ「出動内訳」の扱い
　　　　　例）定期点検の場合
　　　　　　１日目）　定期点検　１レコード
　　　　　　２日目）　継続出動　１レコード
　　　　　　　なのか
　　　　　　１日目）　定期点検　１レコード
　　　　　　２日目）　定期点検，継続出動　２レコード
　　　　　　　なのか。。。
　　　　　　　デジョンテーブルに出動目的が「継続出動」のみのものがあるため，前者と思われる。
　　　
出動内訳←出動→・？・→駐車場設備修理
出動に対して，駐車場設備修理は一意に特定できる。
しかし，出動の出動内訳が複数ある場合は，どの出動内訳による修理なのか特定できない。
そもそも「どの出動内訳による修理」なのか特定する必要があるのか？
⇒表６のデジョンテーブルを見ると，修理作業がある出動目的の組合せが混在している。
　と，いうか全ての出動目的で修理作業が発生し得る。
　どの出動内訳なのか特定する必要があると思われる。

　さて，対応する方策だが，「属性の変更，追加だけで対応」という条件が付いているので，その範囲内で考える。
　一番手っ取り早いのは，エンティティ＠駐車場設備修理に属性＠出動目的番号を追加することではないだろうか。（安易過ぎるか？）

解答例①：要件２
対応できない理由
　出動目的が複数ある時に修理作業が発生した場合，どの出動目的による修理作業か特定できないため。（４６文字）
対応するための方策
　部位装置別に出動目的が管理できるよう，エンティティ“駐車場設備修理”に属性“出動目的番号”を追加する。（５０文字＠禁則処理）
　

要件３：１日で完了しなかった修理作業の把握
疑問２：継続出動時のエンティティ「出動内訳」の扱い
が，また。。。
２日目の出動内訳は，「継続出動」だけと想定する。

疑問３：「修理作業」って何？定義は？
メーカ指示修理＋提案修理？　それとも　修理報告書を提出する作業？　それとも　駐車場設備修理を行ったすべての作業？
疑問４：「提案修理」の２日目以降の「出動目的」は何？と，いういか２日目以降はデータ登録しているの？２日以上の場合，修理作業結果はどう登録するのさ？　・・・　分からん事が多すぎる。

　１日で完了しなかった修理作業＝継続出動で修理を行った作業であるが，提案修理の２日目以降の作業は「継続出動」と呼ばない。（「前回出動番号」も持っていない。）
　もうひとつ別の側面から考える。継続作業時に別の出動目的と重なり，別の出動目的で修理を行うとどうだろうか？ここが疑問２のミソなんだよなぁ。。。「継続作業時には継続作業のみを実施する。」とは書いていないし，『緊急呼出し→継続出動＠修理＋ついでに自発的部品交換＠修理』なんてな（どのみち修理には変わりないか。。。）

　１日で完了しなかった（提案修理が何日かかろうが知らないということであれば）修理作業は，継続出動をカウントすれば把握できる？とも思ったが，提案修理は２日目以降の作業を「継続作業」と呼ばない。つまり，２日目は「継続作業」ではないので，これはＮＧ。
　では，駐車場設備修理がない提案修理は１日目で完了しなかった作業か？
　疑問４が立ちはだかる。２日以上かかっても，最初の出動に修理結果を登録すると。。。ＮＧ。

解答例②：要件３
対応できない理由
　提案修理による作業は継続出動として管理されないため，何日で修理が完了したか把握できない。（４４文字）
対応するための方策
　作業日数を把握するため，エンティティ“出動”に属性“作業完了年月日”を追加する。（４０文字）

要件４：修理が発生しなかった緊急呼出し回数の把握
｛出動内訳（緊急呼出し）→出動｝
　－｛出動内訳（緊急呼出し）→出動→・？・→駐車場設備修理｝
　－｛前回出動番号の出動目的が緊急呼出しの出動内訳（継続出動）→出動→・？・→駐車場設備修理｝
差集合演算で求められる。（と，思う）

H17午後II 問1
機械式駐車場設備メンテナンス業務

設問２（１）
エンティティ「出動」の追加により，
スキーマの属性を「出動指示番号」から「出動番号」に変更するエンティティを列挙する問題。

とりあえず，追加した状態を書く。（リレーションの変更は未実施）

設問の指示どおり，
『出動指示書を発行せずに，修理情報や交換部品情報を登録できるようにする』
と，いうことで「駐車場設備修理」と「交換部品明細」のリレーションを変更する。

解答例：設問２（１）
駐車場設備修理，交換部品明細
で，ＴＡＣとＩＴＥＣの解答例は上のとおりであるが。。。

他の可能性を検討してみる。

さて，修正後の概念データモデルを見ると，点検と修理が随分遠くなった気がする。
点検の結果，修理を行う場合もあるので，もうちょっと近くに置けないかと。。。いうことで，
「駐車場設備点検」と「部位装置点検結果」，「検出異常」のリレーションも変更してみる。

ううーむ。。。これでも悪くない気がするが。。。
もしかして。。。この解答によっては，設問２（３）の解答も影響するんではないかい。。。

もう少し検討してみよう。

H17午後II 問1
機械式駐車場設備メンテナンス業務

設問１（１）
定番のエンティティタイプ名の穴埋め
図６関係スキーマにあって，図５の概念データモデルにないエンティティは
・装置タイプ
・部位装置
・部品
・基本部品
・汎用部品
の五つ。

「メンテナンス用部品には，基本部品と汎用部品がある」 → ａ，ｃ，ｄ
「部位装置汎用部品明細」に矢印がある方（d）が「汎用部品」
ｅは，リレーションから「部品番号」，「駐車場製品番号」を外部キーに持っているので「部位装置」で決まり，
ｄは，「装置タイプ」となる。
解答例：設問１（１）
　ａ）部品
　ｂ）装置タイプ
　ｃ）基本部品
　ｄ）汎用部品
　ｅ）部位装置

設問１（２）
リレーションシップの記述
・駐車場設備
・料金プラン
・契約
・個別サービス
・契約明細
とりあえず，スキーマから追う。

「駐車場設備」に引かれる矢印は充足している。
「料金プラン」に引かれる矢印は充足している。

「契約」に引かれる矢印は足りないようだ。
　・緊急呼出し料金プラン番号
　・修理工賃料金プラン番号
　・修理部品費料金プラン番号
の３つが足りていない。
　参照元は，属性名が「○○料金プラン番号」なので，「料金プラン」の「料金プラン番号」が妥当である。
　これは，それぞれ（緊急呼出し／修理工賃／修理部品費）に対して，インスタンスが排他的に対応しているハズであるが。。。（プラン01は修理部品費には使えない とか）
　これを区分するモノが「料金プラン」に含まれていないのが気がかりではある。。。（ま　いいけど）

「個別サービス」に引かれる矢印は充足している。

「契約明細」に引かれる矢印は属性が書かれていないため判断できない。
とりあえず，契約明細は契約の記述エンティティである（ハズ）なので，
　契約→契約明細
は，間違いない。
あとは，問題文から探る。
『個別部分は，・・・，駐車場設備ごとに提供される個別サービスについて規定している。』
と，いう記述から，契約明細は，駐車場設備の主キーと個別サービスの主キーを外部キーに持つと判断できる。
また，これで，記述対象のエンティティすべてに対して矢印の入/出が書けた。
解答例：設問１（２）
　契約＜－料金プラン
　契約＜－料金プラン
　契約＜－料金プラン （料金プランから契約へ３本矢印を書く）
　契約明細＜－契約
　契約明細＜－駐車場設備
　契約明細＜－個別サービス

設問１（３）
主キーと外部キーの指摘

部位装置点検項目は，図３と図５から，
部位装置汎用部品明細は，図５から 導ける。
解答例：設問１（３）
　部位装置点検項目（駐車場製品番号，部位装置番号，部位装置点検番号，点検項目番号）

　部位装置汎用部品明細（駐車場製品番号，部位装置番号，部品番号，個数）
焦っていると，点検項目番号を主キーに含めてしまうミスをしてしまうかもしれない。

H17午後I 問3
会員管理システムのSQL文

設問２（１）
とりあえず，やってみました。
ユーザ定義関数 GetAge10( )は，作成せずテーブル「会員」に列「年代」を追加しました。
あと，
「 BETWEEN taikan '1200' and '1700' 」がうまく動作しなかったので
「 taikan >= '1200' and taikan <='1700' 」としています。
※初めてMySQLをマトモ(?)に使いました。。。

mysql> select * from kaiin;
+---------+------+------------+------------+--------+--------+
| kaiinno | sex  | birth      | nyukai     | taikai | nendai |
+---------+------+------------+------------+--------+--------+
|   10001 | 男   | 1980-01-10 | 2004-09-07 | NULL   | 20     |
|   10002 | 男   | 1972-02-15 | 2004-10-06 | NULL   | 30     |
|   10003 | 女   | 1972-03-20 | 2004-11-05 | NULL   | 30     |
|   10004 | 男   | 1968-04-25 | 2004-12-04 | NULL   | 30     |
|   10005 | 女   | 1973-05-01 | 2005-01-03 | NULL   | 30     |
|   10006 | 男   | 1969-06-05 | 2005-02-02 | NULL   | 30     |
|   10007 | 女   | 1981-07-01 | 2005-03-01 | NULL   | 20     |
+---------+------+------------+------------+--------+--------+
7 rows in set (0.00 sec)

mysql> select * from riyourireki;
+------------+---------+--------+--------+
| riyou      | kaiinno | nyukan | taikan |
+------------+---------+--------+--------+
| 2005-03-06 |   10003 | 1030   | 1300   |
| 2005-03-07 |   10005 | 1200   | 1430   |
| 2005-03-07 |   10002 | 2000   | 2200   |
| 2005-03-07 |   10007 | 1900   | 2200   |
| 2005-03-08 |   10005 | 1200   | 1430   |
| 2005-03-08 |   10004 | 1700   | 1900   |
| 2005-03-09 |   10005 | 1200   | 1430   |
| 2005-03-09 |   10007 | 1900   | 2200   |
+------------+---------+--------+--------+
8 rows in set (0.00 sec)

mysql> select nendai,sex,count(a.kaiinno) as a1, coalesce(sum(b1),0) as a2,
    -> coalesce(sum(b2),0) as a3, coalesce(sum(b3),0) as a4
    -> from(select nendai,sex,kaiinno from kaiin
    -> where (taikai is null or taikai > '2005-03-31')
    -> and nyukai <= '2005-03-31') as a left outer join
    -> ( select kaiinno,
    -> sum(case when nyukan < '1200' then 1 else 0 end ) as b1,
    -> sum(case when taikan >= '1200' and taikan <='1700' then 1 else 0 end) as b2,
    -> sum(case when taikan > '1700' then 1 else 0 end) as b3
    -> from riyourireki where riyou between '2005-03-01' and '2005-03-31'
    -> group by kaiinno) as b
    -> on a.kaiinno = b.kaiinno
    -> group by nendai,sex
    -> order by nendai,sex;

+--------+------+----+------+------+------+
| nendai | sex  | a1 | a2   | a3   | a4   |
+--------+------+----+------+------+------+
| 20     | 男   |  1 |    0 |    0 |    0 |
| 20     | 女   |  1 |    0 |    0 |    2 |
| 30     | 男   |  3 |    0 |    0 |    2 |
| 30     | 女   |  2 |    1 |    4 |    0 |
+--------+------+----+------+------+------+
4 rows in set (0.00 sec)

設問２（２）

COALESCE関数についてはこちらの記事を参照：SQL: COALESCE関数
解答例：設問２（２）
使用目的：年代，性別によっては利用履歴が存在せず，時間帯別利用者数の集計値がＮＵＬＬとなる所を０と出力するため。（５１文字）

意図した状況が発生する年代と性別。
利用履歴が存在せずA2,A3,A4のすべてがNULLとなり，0に置き換えられるのは２０代男性である。
解答例：設問２（２）
年代：20
性別：男

Ｈ１７午後I 問３
設問１（１）：LEFT JOIN

SELECT 会員種別名, 会員種別 LEFT OUTER JOIN
　( SELECT 会員区分, 利用区分, COUNT( * ) AS 会員数 FROM 会員
　　WHERE ( 退会年月日 IS NULL OR 退会年月日 < '2005-03-31' )
　　AND 入会年月日 >= '2005-03-31'
　　GROUP BY 会員区分, 利用区分 ) AS 現会員 ON ( 会員種別.会員区分 = 現会員.会員区分 AND 利用区分.利用区分 = 現会員.利用区分 )
　　LEFT OUTER JOIN
　( SELECT 会員区分, 利用区分, COUNT( * ) AS 利用回数
　　FROM 利用履歴, 会員
　　WHERE 会員.会員番号 = 利用履歴.会員番号
　　AND 利用年月日 BETWEEN '2005-03-01' AND '2005-03-31'
　　GROUP BY 会員区分, 利用区分 ) AS 利用　（一部省略）
　　LEFT OUTER JOIN
　( SELECT 会員区分, 利用区分, COUNT( * ) AS 入会者数 FROM 会員
　　WHERE 入会年月日 BETWEEN '2005-03-01' AND '2005-03-31'
　　GROUP BY 会員区分, 利用区分 ) AS 入会 （一部省略）
　　LEFT OUTER JOIN
　( SELECT 会員区分, 利用区分, COUNT( * ) AS 退会者数 FROM 会員
　　WHERE 退会年月日 BETWEEN '2005-03-01' AND '2005-03-31'
　　GROUP BY 会員区分, 利用区分 ) AS 退会 （一部省略）
WHERE 会員種別.利用区分 = 利用区分.利用区分
ORDER BY 会員種別名

H17午後I 問3
会員管理システムのSQL文

設問１（１）
定番のＳＱＬ文の穴埋め
解答例：設問１（１）
ａ：COUNT(*)
ｂ：GROUP BY 会員区分, 利用区分
ｃ：ON ( 会員種別.会員区分 = 現会員.会員区分 AND 利用区分.利用区分 = 現会員.利用区分 )
もしくは
　USING ( 会員区分, 利用区分 )
ｄ：利用年月日 BETWEEN
ｅ：入会年月日 BETWEEN
ｆ：退会年月日 BETWEEN
ｇ：会員種別名
設問１（２）
外部結合の理由を問う問題。外部じゃないといけない理由を探す。
『会員種別によっては，会員が存在しない場合もある。』
つまりは，集計対象がゼロであっても，一覧表に出力しないといけないということで。
解答例：設問１（２）
指定した期間において，会員が存在しない会員種別及び利用・入退会が無かった会員種別を利用状況一覧表に出力するため。（５６文字）
設問１（３）
『(1)のSQL文を変更せずに』の条件に戸惑うかもしれないが，これは「会員」テーブル以外で管理するのはナシという布石である。
解答例：設問１（３）
テーブル名：会員
列の内容：親会員の会員番号
列の内容を答えよに対して，列名（親会員番号）で解答すると減点かもしれない。。

H17午後I 問2
受注管理システムのデータベース設計

設問２（１）
テーブルの分割。いわゆるサービス問題
注文（注文番号，会員番号，注文日，注文受付日，商品番号，注文数量，取消しフラグ）
取消しフラグがヘッダにあるのか明細になるのか間違わないように。→『注文書の取消しは，注文書単位で行う。』
解答例：設問２（１）
注文（注文番号，会員番号，注文日，注文受付日，取消しフラグ）

注文明細（注文番号，商品番号，注文数量）

設問２（２）
不足している属性の補完。
図３の発送書から不足している属性をピックアップする。
・発送日
・発送番号
・発送数量　・・・　注文数量とは異なる。
・備考
・請求金額
このうち導出可能な請求金額は省く。
解答例：設問２（２）
注文：発送日，発送番号

注文明細：発送数量，備考
設問２（３）
一括発送に対応するため，既存の１つのテーブルの構造を変更し，新たにテーブルを一つ追加
現状，注文：発送＝１：１であるのを，多：１にすれば良い。
多側に発送番号を外部キーとして残し，発送を新たな別テーブルとする。
解答例：設問２（３）
変更： 注文（注文番号，会員番号，注文日，注文受付日，取消しフラグ，発送番号）

新規： 発送（発送番号，発送日）

H17午後I 問2
受注管理システムのデータベース設計

設問１（１）
関係スキーマの主キー，外部キーを明示する定番のサービス問題。
解答例：設問１（１）
会員（会員番号，氏名，郵便番号，住所，電話番号，支払方法，クレジットカード番号，クレジットカード有効期限）

単品商品（商品番号，商品名，商品概要，写真，単価，販売開始日，販売終了日）

注文（注文番号，会員番号，注文日，注文受付日，商品番号，注文数量，取消しフラグ）
設問１（２）
データ制約上の利点を問う問題。
午後II の制約系の問題をやっていたら，すんなり思いつくのではないでしょうか。。。
ヒントもありますし，
　『商品には，一意な商品番号が付与される。』
　『各商品の商品番号は，単品商品とパック商品全体を通して一意である。』
一つのテーブルにまとめることで，商品番号を一意にし易い。ってことをそれっぽく書けば良い。
あと，追加する列の目的。
何を追加するのか，午後II のスーパータイプ／サブタイプの問題をきっちりやっていれば，ピンときます。「カテゴリ識別子」です。つまりは，単品商品かパック商品かを示す区分ですね。
解答例：設問１（２）
利点：主キーの一意性により，商品番号を商品全体を通して一意にできる点。（３２文字）

列の目的：商品が単品商品かパック商品かを区別するための区分（２４文字）
設問１（３）
これは定番っすね。組合せを管理するテーブルの追加です。
『パック商品は，複数の単品商品を組み合わせた商品，又は同じ単品商品を複数個まとめた商品である。また，一つの単品商品が，複数種類のパック商品に含まれる場合もある。パック商品を構成する単品商品ごとの数量（構成数量）は，決まっている。』
という記述から，「パック商品の商品番号」と「単品商品の商品番号」の組合せ及び単品商品の構成数量を管理すれば良いのが分かる。
主キー・外部キーを明記することを忘れずに。
解答例：設問１（２）
パック商品構成（パック商品番号，単品商品番号，構成数量）

問２の設問１は比較的簡単でした。
問１の設問１に比べりゃ，かなり素直な問題です。

H17午後I 問1
携帯電話会社の顧客情報を管理するデータベースの基礎理論

集合演算に一見戸惑うが落ち着けば全く問題ないハズ。
設問３（３）で，顧客番号“N0001”を例にしてと指定があり，手がかりと思うのか，単なる記述条件と思うのかで，悩み具合が違うようで。

設問３（１）
使用度数［年月度，電話番号］÷（（契約電話番号［顧客番号 = "N0001"］） ［電話番号］）

顧客番号が"N0001"である電話番号は，001001 と 001002
電話番号｛001001，001002｝を両方含んでいる年月度を探す。
解答例：設問３（１）　a: 200503　b: 200504
設問３（２）
　「表のすべての記入欄が埋まるとは限らない」とは書いていないので，すべて埋まるものと考える。
　かなりのサービス問題では？

設問３（２）
式① = 使用度数［年月度］
単なる射影
式①
200501
200502
200503
200504

式② = 契約電話番号［顧客番号 = "N0001"］
単なる選択
式②
N0001, 001001
N0001, 001002

式③ = 式① × （（式②）［電話番号］）
式②を射影して，式①と直積
式③
200501, 001001
200501, 001002
200502, 001001
200502, 001002
200503, 001001
200503, 001002
200504, 001001
200504, 001002

式④ = （式③） - 使用度数［年月度，電話番号］
式③と射影した使用度数との差集合演算
式③の方にだけあるタプルが残る。
式④
200501, 001002
200502, 001002

式⑤ = 式① - （（式④）［年月度］）
式①と射影した式④との差集合演算
式①の方にだけあるタプルが残る。

式⑤
200503
200504

設問３（３）
図５，図６の関係演算で正しく求められない場合を検討
考慮する記述
・解約後，電話番号は別の契約で再利用（表２）
・契約電話番号は，契約中の電話番号を保持
・契約電話番号は，新規契約日に追加され，解約日の翌月の月初日に削除される

解約ばかりに目が行くが。。。視点を変えてみて
顧客番号"N0001"において，年月度200504に，電話番号001003が追加された場合を考えると
年月度200503は２台で複数契約割引，
年月度200504は３台で複数契約割引　と，ならないといけないのだが
200503が図５，図６共に欠落しないだろうか？

ということで
Ｎ０００１の電話番号が年月度２００５０４に１台増えた場合
解答例：設問３（３）
Ｎ０００１の電話番号が年月度２００５０４にもう１台増えた場合（３０字）

H17午後I 問1
携帯電話会社の顧客情報を管理するデータベースの基礎理論

設問１に比べれば，かなりのサービス設問。
過去問をキチントこなしていれば完答できたハズっす。

顧客使用料（顧客番号，電話番号，氏名，生年月日，住所，基本料，通話料，パケット通信料，オプション料，年月度，計算開始日，計算終了日）

設問２（１）
　候補キーの指摘
　図２　破線枠内は，不完全。逆を返せば，破線枠外は完全。変な詮索はしない。
解答例：設問２（１）　｛電話番号，年月度｝
　変な詮索をすると，計算開始日→年月度，計算終了日→年月度が決まるのではないかと。。。思ってしまう。しかし，図４のインスタンスを見ると，計算開始日と計算終了日は，「年月日」ではなく，「日」だけである。

設問２（２）
　正規形の指摘とその根拠。
　図を見れば一目瞭然。
　｛電話番号，年月度｝→顧客番号→｛氏名，生年月日，住所｝　という推移関数従属がある。
　部分関数従属は存在しない。
解答例：設問２（２）　第２正規形
　候補キー｛電話番号，年月度｝に対し非キー属性が部分関数従属せず，｛電話番号，年月度｝→顧客番号→氏名という推移関数従属が存在するため。（６７文字）
設問２（３）
データ登録時の不都合の記述
解答例：設問２（２）　顧客情報である｛氏名，生年月日，住所｝を電話番号毎，年月度毎に重複登録しなければならない。（４５文字）
設問２（４）
推移関数従属を取り除く。「図１と同様の関係スキーマの形式」とあるので，候補キーは明示しない。
解答例：設問２（４）
顧客（顧客番号，氏名，生年月日，住所）
顧客使用料（電話番号，年月度，顧客番号，基本料，通話料，パケット通信料，オプション料，計算開始日，計算終了日）
ちなみに，候補キー，外部キーを明示すると
　顧客（顧客番号，氏名，生年月日，住所）
　顧客使用料（電話番号，年月度，顧客番号，基本料，通話料，パケット通信料，オプション料，計算開始日，計算終了日）
となる。

H17午後I 問1
携帯電話会社の顧客情報を管理するデータベースの基礎理論
問題が６ページ半もある難問。

設問１（１）
　不適切な関数従属性の指摘する問題。
　表１，２の意味と制約を読んで解答なんて，時間的な余裕はない。
　限りなく悪問に近い難問と思う。

図２を見ると。。。
　① ｛契約番号，契約日時｝→料金プラン種別
　② 料金プラン種別→｛基本料金使用料，基準無料額｝
　③ ｛契約番号，契約日時｝→オプション種別
　④ オプション種別→オプション使用料
　⑤ ｛契約番号，契約日時｝→割引種別
　⑥ 割引種別→｛割引率，定額料，割引定額料｝
　⑦ ｛契約番号，契約日時｝→契約種別
　⑧ ｛契約番号，契約日時｝→手数料
こいつの中から間違い探し。１個ずつ検証しないといけないから，面倒っす。
とりあえず，推移の真ん中っぽくない末端から検証する。

② 料金プラン種別→｛基本料金使用料，基準無料額｝
　料金プランごとに，基本料金使用料，基準無料額が一意に決まる（表２）。よって，正しい。

④ オプション種別→オプション使用料
　オプション種別ごとに，オプション使用料が一意に決まる（表２）。よって，正しい。

⑥ 割引種別→｛割引率，定額料，割引定額料｝
　割引種別ごとに，割引率，定額料及び割引定額料が，空値を含めて一意に決まる（表２）。よって，正しい。

ここまではどうってことない。
　｛契約番号，契約日時｝→○○　が，かなり怪しいのはミエミエである。

⑦ ｛契約番号，契約日時｝→契約種別
　新規契約，契約変更及び解約を一意に識別する記号（表２）
　では，「新規契約，契約変更及び解約」の単位は？

契約番号を確認する。
　新規契約時に付与され，契約変更及び解約の処理には同じ番号が使われる。
　つまり，契約番号では，契約種別を一意に特定できない。（　× 契約番号→契約種別）

｛電話番号，契約番号，契約日時｝→契約種別 の可能性を探る。
　契約番号→電話番号があるので，電話番号は冗長であるように見えるが，どうだろうか？

契約番号と電話番号の関係を確認。
　新規契約時に，一つの電話番号が割り当てられる（表１）。から，契約番号→電話番号が確認できる。

では，契約番号←電話番号は，どうだろうか。・・・図２破線内は，不完全。。。ビミョウｗ
　電話番号は，解約後，数か月以上経過すれば，別の契約で再利用されることがある。（表２）から　契約番号←電話番号は成立しない。よって，契約番号←→電話番号も成立しない。

そしてもうひとつ，契約番号と電話番号は１：１なのか１：Ｎなのかを確認する必要がある。
　新規契約時に，一つの電話番号が割り当てられる（表１）。
　契約番号は，契約を一意に識別する番号（表２）

　この問題が難問（悪問）所以たる点はここなんだが。。。
　かなり微妙な気がするが，１：１と仮定する。（１契約番号で，複数の電話番号はない）・・・※注１

　よって，｛契約番号，契約日時｝→契約種別 は正しい。　（残念！アイテック解答例(4/20時点)）

⑧ ｛契約番号，契約日時｝→手数料
　新規契約時，契約変更時及び解約時に，実際に発生する事務手数料
　必ずしも契約種別から一意に決まるとは限らない。
　と，いうことは，契約の候補キーに関数従属するってことで
　｛契約番号，契約日時｝→手数料 だよな。　（残念！アイテック解答例(4/20時点)）

① ｛契約番号，契約日時｝→料金プラン種別

　現時点の契約に対する料金プラン種別が分かれば良いだけなら，契約番号→料金プラン種別
　契約変更による履歴を保存する必要があれば，｛契約番号，契約日時｝→料金プラン種別
　つまりは，料金プラン種別の時系列性を保持する必要があるかどうかってことっす。
　保持する理由を探す。
　月の途中で新規契約，契約変更及び解約が発生した場合は，日割計算を行う。
　顧客使用料のインスタンスはいつ生成されるのかな。。。って記述がない！！
　一般的に考えて，利用の都度，契約変更の都度，料金を計算する。なんてことはしないハズで，特定の〆日に１ヶ月分の集計を行うとすると，月内の契約（料金プラン種別）変更時に，日割計算しなければいけないので，時系列性の保持が必要。
　また，一つの契約に対して複数の料金プラン種別は選択できない。
　よって， ｛契約番号，契約日時｝→料金プラン種別　は，正しい。

③ ｛契約番号，契約日時｝→オプション種別
　一つの契約に対して，複数のオプションを設定できる（表２）。
　これでは，契約日時をずらさないと複数のオプション種別を保持できない。
　表２の同一日に，複数の契約変更及び解約が発生することをあり得る。を満足できない？
　（同一日内で，時刻をずらせば良いから満足できる？）
　よって，｛契約番号，契約日時｝→オプション種別　は正しくない。

⑤ ｛契約番号，契約日時｝→割引種別
　一つの契約に対して，複数の割引種別を設定できる（表２）。
　③と同じ。
　これでは，契約日時をずらさないと複数の割引種別を保持できない。
　よって，｛契約番号，契約日時｝→割引種別　は正しくない。

※注１で，契約番号：電話番号＝１：Ｎと判断すると，
　アイテック解答例になるのではないでしょうか。。。

解答例：設問１（１）　③，⑤

設問１（２）
　まず，契約の候補キーを確認する。

　契約（顧客番号，電話番号，契約番号，契約日時，契約種別，手数料，料金プラン種別，オプション種別，割引種別，基準基本使用料，基準無料額）

設問１（１）で確認できている関係は。。。
　｛契約番号，電話番号｝→顧客番号
　契約番号→電話番号
　料金プラン種別→｛基準基本使用料，基準無料額｝
　｛契約番号，契約日時｝→｛料金プラン種別，契約種別，手数料｝

よって，候補キーは
　｛契約番号，契約日時，オプション種別，割引種別｝

で，部分関数従属を指摘すればよいので
解答例：設問１（２）
　契約番号→電話番号
　｛契約番号，契約日時｝→料金プラン種別
　｛契約番号，契約日時｝→契約種別
　｛契約番号，契約日時｝→手数料
のうち，２つ書けばよい。

アイテック vs ＴＡＣ は，ＴＡＣに軍配か？

Ｈ１７本試験 午後II 問２に関するコメント用

建設機材レンタル業務

設問(1) 概念データモデルの完成
マスタ及び在庫系

予約業務

貸出業務

返却業務

移動業務

設問(2) エンティティタイプの属性一覧の完成
マスタ及び在庫系

予約業務

貸出業務

返却業務

移動業務

Ｈ１７本試験 午後II 問１に関するコメント用

機械式駐車場設備メンテナンス業務

設問１（１） エンティティタイプ名の穴埋め
　ａ）部品
　ｂ）装置タイプ
　ｃ）基本部品
　ｄ）汎用部品
　ｅ）部位装置

設問１（２） リレーションシップの記述
　契約＜－料金プラン
　契約＜－料金プラン
　契約＜－料金プラン （料金プランから契約へ３本矢印を書く）
　契約明細＜－契約
　契約明細＜－駐車場設備
　契約明細＜－個別サービス

設問１（３） 主キーと外部キーの指摘
　部位装置点検項目（駐車場製品番号，部位装置番号，部位装置点検番号，点検項目番号）

　部位装置汎用部品明細（駐車場製品番号，部位装置番号，部品番号，個数）

設問２（１） モデル変更による影響範囲の把握

設問２（２） 要件の整理（デシジョンテーブル）
　ｆ）緊急呼出し
　ｇ）定期点検
　ｈ）メーカ指示修理
　ｉ）提案修理
　ｊ）継続出動

設問２（３） 要件実現の検討（未対応指摘，対応方策記述）

設問３（１） データ管理方法の記述

設問３（２）
（a） 不適切な参照関係の指摘

（b） （a）の不具合解消方法の記述

Ｈ１７本試験 午後I 問３に関するコメント用

会員管理システムのSQL文

設問１（１） ＳＱＬ文の穴埋め
ａ：COUNT(*)
ｂ：GROUP BY 会員区分, 利用区分
ｃ：ON 会員種別.会員区分 = 現会員.会員区分 AND 利用区分.利用区分 = 現会員.利用区分
　※USING でも可？
ｄ：利用年月日 BETWEEN
ｅ：入会年月日 BETWEEN
ｆ：退会年月日 BETWEEN
ｇ：会員種別名

設問１（２） 外部結合の理由

設問１（３） 新規要件に対応するための列追加
テーブル名：会員
列の内容：親会員の会員番号

設問２（１） 集計結果の穴埋め

設問２（２） COALESCE関数の目的

Ｈ１７本試験 午後I 問２に関するコメント用

受注管理システムのデータベース設計

設問１（１） 主キーと外部キーの指摘

設問１（２） テーブル統合の利点（データ制約上）の記述

設問１（３） テーブルの追加（組合せ管理）

設問２（１） テーブルの分割

設問２（２） テーブルの追加（不足分の補完）

設問２（３） 新規要件に対応するテーブルの追加

Ｈ１７本試験 午後I 問１に関するコメント用

携帯電話会社の顧客情報を管理するデータベースの基礎理論

設問１（１）

設問１（２）

設問２（１）

設問２（２）

設問２（３）

設問２（４）

設問３（１）

設問３（２）

設問３（３）

Ｈ１７本試験 午後I 問４に関するコメント用

関係データベースのテーブルを更新するプログラムの設計

設問１（１） スループット低下の理由

設問１（２） (1)の対応策

設問２（１） デッドロック発生の理由

設問２（２） (1)の対応策

設問３（１） 不具合発生理由の指摘（排他制御）

設問３（２） ＳＱＬ文の完成

Ｈ１７本試験 午前に関するコメント用

・セキュリティの問題は？
・待ち行列問題は計算問題か？
などなど。

g@kkoの第一声(?)はこちら。