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に埋め込む: