2005年03月02日

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

H13午後I 問3 SQL俯瞰

H13午後I 問3
設問1(1):IN

SELECT 文献番号, 著者, 作成年月, タイトル, 文献要約
  FROM 文献情報
WHERE 著者 = '田中一郎' AND
  文献情報 IN( SELECT 文献番号 FROM 文献索引
    WHERE キーワード = '生産管理'
)
ORDER BY 文献番号



設問1(2):LIKE

SELECT 文献番号, 著者, 作成年月, タイトル, 文献要約
  FROM 文献情報
WHERE 著者 = '田中一郎' AND
  文献要約 LIKE '%生産管理%'
ORDER BY 文献番号



設問2:ORDER BY

SELECT 検索ワード, COUNT(*)
 FROM 検索ログ
GROUP BY 検索ワード
ORDER BY COUNT(*) 2 DESC



設問3:EXISTS

SELECT DISTINCT キーワード
  FROM 文献索引
WHERE NOT EXISTS( SELECT * FROM 検索ログ
  WHERE 文献索引.キーワード = 検索ログ.検索キーワード
)

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

2005年02月19日

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

H13午後I 問1

H13午後I 問1(ITEC 2005予想問題集 午後I 問1-3)

設問1
 定番問題

設問2
 定番問題

設問3
 関数従属性の図を完成させる問題

 予約(物件番号,棟番号,予約番号,顧客番号,第1希望,第2希望,登録日,抽選日)
 (すでに,登録日,抽選日は図2に明記してある。)

 まずは,候補キー,非キー属性を見極める。
 予約なんで予約番号は当然,候補キーに絡むと推察する。
 表から意味と制約を調べる。

 売出単位の中で一意になるように振られた予約登録の番号。
  売出単位は,棟単位とする。
  物件は,一つ又は複数の棟から成る。
 そして,どう考えても,第1希望,第2希望は非キー属性。
 よって,{物件番号,棟番号,予約番号}は候補キーのようだ。

 同じ顧客に,同じ物件の同じ棟の予約番号を複数発行することはない。
  顧客番号:登録された顧客を一意に識別する番号
 {物件番号,棟番号,顧客番号}も候補キーとなる。

 予約は候補キーが2つあり,かつ{物件番号,棟番号}が重複する重複キーである第3正規形であることが分かる。

 非キー属性の第1希望,第2希望にが候補キーから矢印を引く。
 2つの候補キーから矢印を引くのは冗長という見解もあるが,間違いではないと思う。

 候補キー同士で,{物件番号,棟番号,予約番号}←→{物件番号,棟番号,顧客番号}が成り立つ
 よって
  {物件番号,棟番号,予約番号}→{物件番号,棟番号,顧客番号}→顧客番号
  {物件番号,棟番号,顧客番号}→{物件番号,棟番号,予約番号}→予約番号
 であるので, (これは,候補キー→候補キー→候補キーを構成する属性なので推移関数従属ではない)
  {物件番号,棟番号,予約番号}→顧客番号
  {物件番号,棟番号,顧客番号}→予約番号
 と,矢印を引く。

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

2005年01月24日

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

H13午後I 問2 vol.2

H13午後I 問2(ITEC 2005予想問題集 午後I 問3-3)
 vol.1はここ
設問2(2)

 単語に気をつけろ「利用額」と「請求額」が別物だ。
 「利用額」には「消費税額」が含まれていない!
 よって,示現塾の解答例
  「カードを使用した時に利用額を加算し,銀行口座から引き落とす時に減算する」
 は,誤りと思われる。

 また,ITECの解答例
  「クレジットカード利用時に今回利用の請求額を加算し,引落日に当月請求額を減算する」
 は,“銀行口座からの引落処理ができなかった場合”の考慮が足りない。

じゃあ,どう書くのさ。ということで,

テーブルを引用する例
 「利用明細の利用額と消費税額を加算し,利用請求の引落済表示を済にする時に当月請求額を減算する」

業務を引用する例
 「カード利用の都度,請求額を加算し,銀行口座からの引落処理時ができたら当月請求額を減算する」

なんていうのはどうでしょうか。。。


設問3
 品目の組合せは日単位に設定できること。

解答例は
  サービスポイント(組合せ番号,適用年月日,サービスポイント)
  サービスポイント品目組合せ(組合せ番号品目番号
と,なってるけど

  サービスポイント(組合せ番号,適用年月日開始,適用年月日終了,サービスポイント)
 これでも,日単位よね。
 1週間とか,1ヶ月とかキャンペーンをするならこっちだと思うんだけどな。
 1日限定とかそんなセコイことしないよね(w

 あと,この解答例(設問)は人に優しくない。
  サービス名称(組合せ番号,サービス名称)
 とかないと,人間は認識し難い。設問にはそんな要求ないんだけどね。
 でも,こいつは,品目組合せ毎にサービス名称を付けるのはめんどいよね。

 こいつをきちんと実装しようと思えば・・・
  サービス(サービス番号,サービス名称,適用年月日開始,適用年月日終了)
  サービスポイント(サービス番号組合せ番号,サービスポイント)
  サービスポイント品目組合せ(サービス番号組合せ番号品目番号
 とかかな。。。

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

2005年01月21日

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

H13午後II 問2

H13午後II 問2(ITEC 2005予想問題集 午後II 問7)

設問1(1)
 セットメニューの組合せは管理不要。
 ⇒商品種別(サイドフード,ドリンク)の群から任意に選択するため。

設問1(4)
 「販売明細」にもあるメインフードを「セット販売明細」にも登録する根拠が良く分からない。
重複登録じゃん。。。レシートの印刷を見ると,メインフードを「セット販売明細」に入れない方が,よさ気なんだけどな。

設問2(2)
・前年同週同曜日

 「週カレンダ」に前年同週の「年週番号」を追加すりゃいいかなと。安易に考えたんだけど・・・
 アイテックの解答例は,「日カレンダ」に「曜日」を追加・・・・ん?

 「曜日」の必要性は,図8 来店販売分析レポートを見れば分かるが・・・関数で出ないの?
 ⇒曜日はoracleならto_char(年月日, 'DY') でOKみたいだが,SQL標準ではないみたいね。よって属性として「曜日」は必要ということか。

 しかし,曜日の追加だけで,前年度のデータと どうやって結合処理するんだろ。
 解答例は前年同週の「曜日」をキーに と,書いてあるが
 年週番号で結合しようとしても,'2001年10週'とかなんでしょ。'2000年10週'と,どう結び付けるのよ。
 「年始からの日数」を7で割るんかいな・・・。そんなことしないよな。
 RIGHT関数かな・・・だったら第1週は'01週'にして文字長合せておかないとな。って標準SQLは無いのよねRIGHTって。
 
 さて,どうするか。。。「曜日」が必要ということなら,
 「年週番号」を分割して「年」と「週番号」にし,「日カレンダ」に「年」,「週番号」,「曜日」を追加する。というのが結合は楽そうだ。しかし,他テーブルの「年週番号」も分割しなければならないので,DB変更・アプリ変更のインパクトが大きいね。指定文字数にも収まりそうにないし。
 と,いうことは,
 「日カレンダ」に「曜日」を追加し,「週カレンダ」に「前年同週年週番号」を追加ってことじゃないのかな?
(詳細は>>2-3にて)

・前年同祝日
 えーっと,解答例は「日カレンダ」に「祝日」を追加?しかも,値は「成人の日」なのっ!?
 んで,「祝日」で結合するんだ・・・へぇ~

 さて,今年の「春分の日」を考えると・・・日曜日ですね。
 で,月曜日が「振替休日」比較の趣旨から想定すると。去年の春分の日(土曜)と今年の春分の日(日曜)の比較でなく,振替休日(春分の日)と思えますが・・・
 また,問題文では,祝日の増減は考慮しなくていいとはあるが,「祝日名」の必要性については言及がありませんね。

 ここは,「日カレンダ」に「前年同祝日年週番号」と「前年同祝日日番号」を追加しちゃいましょうよ。これでいいんだと思うんだけど。

設問3(2)
 解答例のドリンク単価をメインフードのセット単価-(メインフードの通常単価+サイドフードの通常単価)にする理由が分からない。
  条件: 販売金額≦通常単価×販売個数
 であるから,ドリンクも当然,通常単価であるべきだと思うのだが。
 変に気を使う(セットとの差額をドリンクで精算とか価格按分とか)のは必要はないのでは?

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

2005年01月10日

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

H13午後II 問1

H13午後II 問1(ITEC 2005予想問題集 午後II 問3)

出来が良くなかったので本に当たってみる

アイテック データベース予想問題集 2005

P559

なお,図7の自社工場(自社工場コード)は,おそらく,自社工場(自社工場コード,自社工場名称)の誤りであろう。

問題ページ(P299)の一番下に「図7 S社物流関連業務の関係スキーマ一覧(未完成)」
未完成って書いてあるだろーがっ!!!誤りじゃなくって未完成なんだよっ!!!!

はぁはぁはぁ・・・ 虚しい(遠い目

っておい

P560

“自社工場”の関係スキーマに自社工場名称がなく,“物流拠点”の物流拠点名称から得ると想定できるからである。

ってさっきの「誤りであろう」と矛盾してねーかよっ!!!

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

2004年12月24日

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

H13午後I 問2

H13午後I 問2(ITEC 2005予想問題集 午後I 問3-3)

会員
|会員番号|会員氏名|フリガナ|郵便番号|会員住所|生年月日|電話番号|
 |引落口座|利用限度額|登録年|登録月|基本ポイント率|家族会員数|
 |家族氏名1|家族フリガナ1|続柄コード1|生年月日1|家族会員番号1|
 |家族氏名2|家族フリガナ2|続柄コード2|生年月日2|家族会員番号2|
 |家族氏名3|家族フリガナ3|続柄コード3|生年月日3|家族会員番号3|
 |家族氏名4|家族フリガナ4|続柄コード4|生年月日4|家族会員番号4|

問題点2:利用明細書作成時,会員ごとの利用明細の集計をSQL文だけで行うと,SQL文が複雑になる。

問題点3:会員の家族会員数に拡張性がない。

設問1(2)
 問題点2と3を解決するため,“会員”テーブルを複数テーブルに分割することにした。これらのテーブル構造を表記ルールに従って示せ。
 なお,外部キーが参照する先のテーブルの表記は不要である。


まっとうに考えれば,横持ちしている家族会員の項目を分割してなんだけど。

Posted by g@kko at 2004/12/24 19:34 | 個別記事表示 | コメントを見る (0) |
この記事をLicWikiに埋め込む: