2005年05月31日

[ テクニカルエンジニア(データベース)/H17 ]

H17午後II 問1設問3

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

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

解答例
駐車場設備点検の主キーを持つ部位装置点検結果・検出異常が存在しなければ,それぞれ部位・点検項目は正常と判断できるため。(59文字)

※異常時のものだけを保持するスキーマ設計にしているが,この方法でも正常時のデータ登録が可能である理由
 とも読めなくも無い。。属性@修理区分に“正常”を追加するとかw

設問3(2)(a)
同音異義語を指摘すれば良いかと。
解答例
部位装置点検項目の開始年月日と点検項目の開始年月日は同音意義語であるため参照関係を設定できない。(48文字)

設問3(2)(b)
解答例
テーブル“点検項目”の属性“開始年月日”をテーブル“部位装置点検項目”の“開始年月日”と同意にし,新たにテーブル“点検項目”に属性“正常条件開始年月日”を主キーの構成列として追加し,列として“正常条件終了年月日”を追加する。(112文字)

「“”」と“正常条件終了年月日”は文字数稼ぎ。

Posted by g@kko at 2005/05/31 10:36 | 個別記事表示 | コメントを見る (0) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H17 ]

H17午後II 問1設問2(2),(3)

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

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

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

解答例:設問2(2)
 f)緊急呼出し
 g)定期点検
 h)メーカ指示修理
 i)提案修理
 j)継続出動

設問2(3)
要件実現の検討(未対応指摘,対応方策記述)

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

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

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

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

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

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

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

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

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

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

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


要件4:修理が発生しなかった緊急呼出し回数の把握
{出動内訳(緊急呼出し)→出動}
 -{出動内訳(緊急呼出し)→出動→・?・→駐車場設備修理}
 -{前回出動番号の出動目的が緊急呼出しの出動内訳(継続出動)→出動→・?・→駐車場設備修理}
差集合演算で求められる。(と,思う)

Posted by g@kko at 2005/05/31 09:54 | 個別記事表示 | コメントを見る (2) |
この記事をLicWikiに埋め込む:

2005年05月03日

[ テクニカルエンジニア(データベース)/H17 ]

H17午後II 問1設問2(1)

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

設問2(1)
エンティティ「出動」の追加により,
スキーマの属性を「出動指示番号」から「出動番号」に変更するエンティティを列挙する問題。

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

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

解答例:設問2(1)
駐車場設備修理,交換部品明細

で,TACとITECの解答例は上のとおりであるが。。。

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

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

ううーむ。。。これでも悪くない気がするが。。。
もしかして。。。この解答によっては,設問2(3)の解答も影響するんではないかい。。。

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

Posted by g@kko at 2005/05/03 18:20 | 個別記事表示 | コメントを見る (15) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H17 ]

H17午後II 問1設問1

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

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

「メンテナンス用部品には,基本部品と汎用部品がある」 → a,c,d
「部位装置汎用部品明細」に矢印がある方(d)が「汎用部品」
eは,リレーションから「部品番号」,「駐車場製品番号」を外部キーに持っているので「部位装置」で決まり,
dは,「装置タイプ」となる。
解答例:設問1(1)
 a)部品
 b)装置タイプ
 c)基本部品
 d)汎用部品
 e)部位装置

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

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

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

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

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

設問1(3)
主キーと外部キーの指摘

部位装置点検項目は,図3と図5から,
部位装置汎用部品明細は,図5から 導ける。
解答例:設問1(3)
 部位装置点検項目(駐車場製品番号部位装置番号部位装置点検番号点検項目番号

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

Posted by g@kko at 2005/05/03 16:24 | 個別記事表示 | コメントを見る (1) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H17 ]

H17午後I 問3設問2

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

設問2(1)
とりあえず,やってみました。
ユーザ定義関数 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)
と,いうことで。 解答例:設問2(1) h:2  i:1  j:4  k:0

設問2(2)

COALESCE関数についてはこちらの記事を参照:SQL: COALESCE関数
解答例:設問2(2)
使用目的:年代,性別によっては利用履歴が存在せず,時間帯別利用者数の集計値がNULLとなる所を0と出力するため。(51文字)


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

Posted by g@kko at 2005/05/03 00:18 | 個別記事表示 | コメントを見る (4) |
この記事をLicWikiに埋め込む:

2005年05月02日

[ テクニカルエンジニア(データベース)/H17 ]

H17午後I 問3 SQL俯瞰

H17午後I 問3
設問1(1):
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 会員種別名

Posted by g@kko at 2005/05/02 22:25 | 個別記事表示 | コメントを見る (0) |
この記事をLicWikiに埋め込む:

2005年05月01日

[ テクニカルエンジニア(データベース)/H17 ]

H17午後I 問3設問1

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

設問1(1)
定番のSQL文の穴埋め
解答例:設問1(1)
a:COUNT(*)
b:GROUP BY 会員区分, 利用区分
c:ON ( 会員種別.会員区分 = 現会員.会員区分 AND 利用区分.利用区分 = 現会員.利用区分 )
もしくは
 USING ( 会員区分, 利用区分 )
d:利用年月日 BETWEEN
e:入会年月日 BETWEEN
f:退会年月日 BETWEEN
g:会員種別名

設問1(2)
外部結合の理由を問う問題。外部じゃないといけない理由を探す。
『会員種別によっては,会員が存在しない場合もある。』
つまりは,集計対象がゼロであっても,一覧表に出力しないといけないということで。
解答例:設問1(2)
指定した期間において,会員が存在しない会員種別及び利用・入退会が無かった会員種別を利用状況一覧表に出力するため。(56文字)

設問1(3)
『(1)のSQL文を変更せずに』の条件に戸惑うかもしれないが,これは「会員」テーブル以外で管理するのはナシという布石である。
解答例:設問1(3)
テーブル名:会員
列の内容:親会員の会員番号

列の内容を答えよに対して,列名(親会員番号)で解答すると減点かもしれない。。

Posted by g@kko at 2005/05/01 17:09 | 個別記事表示 | コメントを見る (11) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H17 ]

H17午後I 問2設問2

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

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

注文明細(注文番号商品番号,注文数量)

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

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

新規: 発送(発送番号,発送日)

Posted by g@kko at 2005/05/01 13:25 | 個別記事表示 | コメントを見る (9) |
この記事をLicWikiに埋め込む:

2005年04月30日

[ テクニカルエンジニア(データベース)/H17 ]

H17午後I 問2設問1

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

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

単品商品(商品番号,商品名,商品概要,写真,単価,販売開始日,販売終了日)

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

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

問2の設問1は比較的簡単でした。
問1の設問1に比べりゃ,かなり素直な問題です。

Posted by g@kko at 2005/04/30 23:32 | 個別記事表示 | コメントを見る (0) |
この記事をLicWikiに埋め込む:

2005年04月24日

[ テクニカルエンジニア(データベース)/H17 ]

H17午後I 問1設問3

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

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

設問3(1)
使用度数[年月度,電話番号]÷((契約電話番号[顧客番号 = "N0001"]) [電話番号])

顧客番号が"N0001"である電話番号は,001001 と 001002
電話番号{001001,001002}を両方含んでいる年月度を探す。
解答例:設問3(1) a: 200503 b: 200504
設問3(2)
 「表のすべての記入欄が埋まるとは限らない」とは書いていないので,すべて埋まるものと考える。
 かなりのサービス問題では?

設問3(2)
式① = 使用度数[年月度]
単なる射影
式①
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

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

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

ということで
N0001の電話番号が年月度200504に1台増えた場合
解答例:設問3(3)
N0001の電話番号が年月度200504にもう1台増えた場合(30字)

Posted by g@kko at 2005/04/24 16:38 | 個別記事表示 | コメントを見る (2) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H17 ]

H17午後I 問1設問2

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

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

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

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

設問2(2)
 正規形の指摘とその根拠。
 図を見れば一目瞭然。
 {電話番号,年月度}→顧客番号→{氏名,生年月日,住所} という推移関数従属がある。
 部分関数従属は存在しない。
解答例:設問2(2) 第2正規形
 候補キー{電話番号,年月度}に対し非キー属性が部分関数従属せず,{電話番号,年月度}→顧客番号→氏名という推移関数従属が存在するため。(67文字)

設問2(3)
データ登録時の不都合の記述
解答例:設問2(2) 顧客情報である{氏名,生年月日,住所}を電話番号毎,年月度毎に重複登録しなければならない。(45文字)
設問2(4)
推移関数従属を取り除く。「図1と同様の関係スキーマの形式」とあるので,候補キーは明示しない。
解答例:設問2(4)
顧客(顧客番号,氏名,生年月日,住所)
顧客使用料(電話番号,年月度,顧客番号,基本料,通話料,パケット通信料,オプション料,計算開始日,計算終了日)

ちなみに,候補キー,外部キーを明示すると
 顧客(顧客番号,氏名,生年月日,住所)
 顧客使用料(電話番号年月度顧客番号,基本料,通話料,パケット通信料,オプション料,計算開始日,計算終了日)
となる。

Posted by g@kko at 2005/04/24 15:29 | 個別記事表示 | コメントを見る (0) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H17 ]

H17午後I 問1設問1

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

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

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

② 料金プラン種別→{基本料金使用料,基準無料額}
 料金プランごとに,基本料金使用料,基準無料額が一意に決まる(表2)。よって,正しい。

④ オプション種別→オプション使用料
 オプション種別ごとに,オプション使用料が一意に決まる(表2)。よって,正しい。

⑥ 割引種別→{割引率,定額料,割引定額料}
 割引種別ごとに,割引率,定額料及び割引定額料が,空値を含めて一意に決まる(表2)。よって,正しい。

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

⑦ {契約番号,契約日時}→契約種別
 新規契約,契約変更及び解約を一意に識別する記号(表2)
 では,「新規契約,契約変更及び解約」の単位は?

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

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

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

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

そしてもうひとつ,契約番号と電話番号は1:1なのか1:Nなのかを確認する必要がある。
 新規契約時に,一つの電話番号が割り当てられる(表1)。
 契約番号は,契約を一意に識別する番号(表2)

 この問題が難問(悪問)所以たる点はここなんだが。。。
 かなり微妙な気がするが,1:1と仮定する。(1契約番号で,複数の電話番号はない)・・・※注1

 よって,{契約番号,契約日時}→契約種別 は正しい。 (残念!アイテック解答例(4/20時点))

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

① {契約番号,契約日時}→料金プラン種別

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

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

⑤ {契約番号,契約日時}→割引種別
 一つの契約に対して,複数の割引種別を設定できる(表2)。
 ③と同じ。
 これでは,契約日時をずらさないと複数の割引種別を保持できない。
 よって,{契約番号,契約日時}→割引種別 は正しくない。


※注1で,契約番号:電話番号=1:Nと判断すると,
 アイテック解答例になるのではないでしょうか。。。

解答例:設問1(1) ③,⑤


設問1(2)
 まず,契約の候補キーを確認する。

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

設問1(1)で確認できている関係は。。。
 {契約番号,電話番号}→顧客番号
 契約番号→電話番号
 料金プラン種別→{基準基本使用料,基準無料額}
 {契約番号,契約日時}→{料金プラン種別,契約種別,手数料}

よって,候補キーは
 {契約番号,契約日時,オプション種別,割引種別}

で,部分関数従属を指摘すればよいので
解答例:設問1(2)
 契約番号→電話番号
 {契約番号,契約日時}→料金プラン種別
 {契約番号,契約日時}→契約種別
 {契約番号,契約日時}→手数料
のうち,2つ書けばよい。

アイテック vs TAC は,TACに軍配か?

Posted by g@kko at 2005/04/24 14:52 | 個別記事表示 | コメントを見る (3) |
この記事をLicWikiに埋め込む:

2005年04月17日

[ テクニカルエンジニア(データベース)/H17 ]

H17本試験午後II問2(建設機材レンタル業務)

H17本試験 午後II 問2に関するコメント用

建設機材レンタル業務

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

予約業務

貸出業務

返却業務

移動業務


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

予約業務

貸出業務

返却業務

移動業務

Posted by g@kko at 2005/04/17 16:10 | 個別記事表示 | コメントを見る (21) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H17 ]

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

H17本試験 午後II 問1に関するコメント用

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

設問1(1) エンティティタイプ名の穴埋め
 a)部品
 b)装置タイプ
 c)基本部品
 d)汎用部品
 e)部位装置

設問1(2) リレーションシップの記述
 契約<-料金プラン
 契約<-料金プラン
 契約<-料金プラン (料金プランから契約へ3本矢印を書く)
 契約明細<-契約
 契約明細<-駐車場設備
 契約明細<-個別サービス

設問1(3) 主キーと外部キーの指摘
 部位装置点検項目(駐車場製品番号部位装置番号部位装置点検番号点検項目番号

 部位装置汎用部品明細(駐車場製品番号部位装置番号部品番号,個数)

設問2(1) モデル変更による影響範囲の把握

設問2(2) 要件の整理(デシジョンテーブル)
 f)緊急呼出し
 g)定期点検
 h)メーカ指示修理
 i)提案修理
 j)継続出動

設問2(3) 要件実現の検討(未対応指摘,対応方策記述)

設問3(1) データ管理方法の記述

設問3(2)
(a) 不適切な参照関係の指摘

(b) (a)の不具合解消方法の記述

Posted by g@kko at 2005/04/17 16:10 | 個別記事表示 | コメントを見る (11) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H17 ]

H17本試験午後I問3(会員管理システムのSQL文)

H17本試験 午後I 問3に関するコメント用

会員管理システムのSQL文

設問1(1) SQL文の穴埋め
a:COUNT(*)
b:GROUP BY 会員区分, 利用区分
c:ON 会員種別.会員区分 = 現会員.会員区分 AND 利用区分.利用区分 = 現会員.利用区分
 ※USING でも可?
d:利用年月日 BETWEEN
e:入会年月日 BETWEEN
f:退会年月日 BETWEEN
g:会員種別名

設問1(2) 外部結合の理由

設問1(3) 新規要件に対応するための列追加
テーブル名:会員
列の内容:親会員の会員番号

設問2(1) 集計結果の穴埋め

設問2(2) COALESCE関数の目的

Posted by g@kko at 2005/04/17 13:40 | 個別記事表示 | コメントを見る (28) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H17 ]

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

H17本試験 午後I 問2に関するコメント用

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

設問1(1) 主キーと外部キーの指摘

設問1(2) テーブル統合の利点(データ制約上)の記述

設問1(3) テーブルの追加(組合せ管理)

設問2(1) テーブルの分割

設問2(2) テーブルの追加(不足分の補完)

設問2(3) 新規要件に対応するテーブルの追加

Posted by g@kko at 2005/04/17 13:40 | 個別記事表示 | コメントを見る (3) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H17 ]

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

H17本試験 午後I 問1に関するコメント用

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

設問1(1)

設問1(2)

設問2(1)

設問2(2)

設問2(3)

設問2(4)

設問3(1)

設問3(2)

設問3(3)

Posted by g@kko at 2005/04/17 13:40 | 個別記事表示 | コメントを見る (28) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H17 ]

H17本試験午後I問4(関係データベースのテーブルを更新するプログラムの設計)

H17本試験 午後I 問4に関するコメント用

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

設問1(1) スループット低下の理由

設問1(2) (1)の対応策

設問2(1) デッドロック発生の理由

設問2(2) (1)の対応策

設問3(1) 不具合発生理由の指摘(排他制御)

設問3(2) SQL文の完成

Posted by g@kko at 2005/04/17 13:40 | 個別記事表示 | コメントを見る (2) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H17 ]

H17本試験 午前

H17本試験 午前に関するコメント用

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

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

Posted by g@kko at 2005/04/17 11:10 | 個別記事表示 | コメントを見る (49) |
この記事をLicWikiに埋め込む: