( すべて |  1  |  2 ) 次へ

2005年03月27日

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

H15午後I 問3 vol.2

H15午後I 問3(ITEC 2005予想問題集 午後I 問3-1)
設問2(2)

9氏からのコメント依頼
 元記事

599 :名無し検定1級さん :2005/03/26(土) 21:33:48
午後1のSQLは、今年も例年通り何の変哲もない問題なのだろうか?
SQL99まで押さえてないとだめかな?
いきなり突拍子もない問題だされたら困るなあ。

ところで、平成15年午後1の「セットメニュー」「セット料理」の問題って、
どういう議論に落ち着いていたのか知ってる人いる?
愛テックの解答だと、「セットメニュー(主料理番号、セット料理番号)」
が最もスマートな解ということになってるが。

601 :名無し検定1級さん :2005/03/26(土) 21:46:49
>>599
出ても1設問。影響は少ないんでは?
平成15年午後1はそれでいいと思うよ

602 :599:2005/03/26(土) 21:51:42
ぼくは当時「セットメニュー(主料理番号、セット料理番号)」に加えて
「セット料理(セット料理番号,セット構成料理番号)」も書いてしまったんだ。
やっぱ冗長だってことで、減点あるいはゼロだったのかな。当時も勿論落ちたけど。
今年が3度目の挑戦なのねん。 612 :名無し検定1級さん :2005/03/27(日) 01:25:01
http://www5a.biglobe.ne.jp/~ISI01/db2003.html
H15午後I問3設問2(2)の解答って、

[示現塾] http://zigen.cosmoconsulting.co.jp/images/ANW-H15DB-PM1.pdf
セットメニュー(主料理番号,セット料理番号)
セット料理構成(セット料理番号,料理番号)

[TAC] http://school.edu.yahoo.co.jp/school/answer/jyouhousyori/20030401/20030401-04.pdf
セットメニュー(主料理番号,セット料理番号)

[自分が使ってる参考書]
セット料理(セット料理番号,セット料理名,価格)
セット料理内容(セット料理番号,料理番号)
セットメニュー(セット料理番号,主料理番号)

全部違う。
いったいどれが一番高得点の回答なんでしょう。

613 :名無し検定1級さん :2005/03/27(日) 01:31:15
って、すぐ前の>>599に同じネタが。スマソ。
自分も、セットメニュー(主料理番号、セット料理番号)だけだと思うなぁ。
問題文にはごちゃごちゃと細かく説明してるけど、
注文管理上はセット料理の詳細なんて無関係だし。


と,いうことで
出題者の意図
問題点④ セット料理及びセットメニューの管理が漏れている。
を汲んだ解答としては,伝統的な
(解答例:A)
 セット料理(セット料理番号,セット料理名,価格)
 セット料理内容(セット料理番号料理番号)
 セットメニュー(セット料理番号主料理番号)

が,一番良いと思います。


TAC解答速報,アイタック本
(解答例:B)
 セットメニュー(主料理番号セット料理番号)
 (※アイタック本はセット料理,セット料理内容,セットメニューの3テーブルを別解としている)
と,なっています。
非常に合理的な解答であると思いますが,出題者の意図とズレる気がするのと,午後I でここまでの汎化は求めないでしょう。。。

 それと,
 料理(料理番号,料理名,単価,料理区分
 料理区分:単品料理なのか主料理なのかセット料理なのか区別するためのカテゴリ識別子が欲しいところ。この区分がないとアプリ側の負担が大きいと思われます。

“意図とズレる気がする”というのは,
 料理(料理番号,料理名,単価)でセット料理が管理をするのであれば,「セット料理の管理が漏れている」とは書かないのではないでしょうか。。。この解答例だと「主料理とセット料理,及びセット料理を構成する単品料理の管理が漏れている」という表現になると思うんだけどな。


次に示現塾解答例
(解答例:C)
 セット料理内容(セット料理番号,料理番号)
 セットメニュー(セット料理番号,主料理番号)

 セット料理(セット料理番号,セット料理名,価格) は,
 料理(料理番号,料理名,単価) で管理するパターン。
 インスタンス例:料理(4400,サラダセット,250)

セット料理には,それを構成する単品料理とは別の料理番号を付与する。
とあるので,料理番号の重複もないのでこの解答例は別解でOKな気もしますが,解答例Bの“意図とズレる気がする”と同じっすな。。。


ひとつ気になるのは。。。「解答欄の大きさ」w
どのくらいだったんでしょうね。。。


類問
 H13午後I 問2 設問3
 H13午後II 問2 設問1(4)


関連記事
 H15午後I 問3

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

2005年03月25日

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

H15午後I 問1 vol.3

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

9氏からのコメント依頼
 元ネタ記事

574 :名無し検定1級さん :2005/03/25(金) 14:08:52
H15午後1問1設問3(2)
http://school.edu.yahoo.co.jp/school/answer/jyouhousyori/20030401/20030401-04.pdf
http://zigen.cosmoconsulting.co.jp/images/ANW-H15DB-PM1.pdf
どっちが正解だろう。翔泳社の回答例もメタデータとメタメタデータの違いとあるけど、
図2がなぜメタデータを表すと解釈できるのかわからん。
単に基準の違いだと思うんですけど。。。

まずは各解答例を確認。

示現塾
図2の対象は、通常のデータであるのに対して、図4の対象は、メタデータである

TAC解答速報
図2の対象はメタデータのみであるが,図4はメタデータを定義するメタデータを含む

DB Magazine
図2は実業務に関わるデータ構造、図4はデータ構造の管理構造を対象としている。
(メタデータとメタメタデータの違い)

アイテック解答速報
図2はメタデータレベルを対象とするが、図4はメタメタデータレベルを対象とする。

アイテック本
図2は属性データであるが,図4は属性データのメタデータで,データレベルが違う。

iTAC
図2は各属性に関する記述だが、図4は各属性の定義に関する記述が主である

ほう,アイテックは少数派だったんですな。。。

メタデータの定義を確認。
IPA > IT人材の発掘・育成関連 > 人材育成推進センター > 研修カリキュラム > テクニカルエンジニア(データベース)

(3)メタデータ
 1 メタデータの役割
  データに関する情報のこと
 2  メタデータ含まれる内容
  データ定義,データ構造,ルール(制約),データの意味,データの出所,データの保管場所

一般的な解釈としては。。。
データ総研 > 技術情報 > DRI通信 > 【第89号】メタデータ扱いの進化
■ メタデータ
「メタデータとは、データのデータである」などと説明されています。これは定義として不十分ですが、たとえば社員レコード
[1] -(椿正明、男、68、会長)
[2] -(竹下茂、男、62、専務)

 [社員番号]-(社員氏名、性別、年齢、役職)
として捉えるときの、社員番号、社員氏名、性別などである、と言えばおおむね理解していただけるでしょう。

■ メタメタデータ
これらのメタデータを捉えるフレームワークとして、
 [属性番号]-(属性名、所属エンティティ、属性区分、属性値区分、桁数)
 ただし、属性区分:KEY、RKEY、加工データなどの別
     属性値区分:コード、テキスト、数量などの別
などを規定することができます。これはメタデータについてのメタデータということで、メタメタデータと言うことがあります。メタメタデータは、メタデータの構造を明示するものということができます。

と,いうことで
一般的な解釈で行けば,「図2はメタデータで図4はメタメタデータ」ということですが,
標準カリキュラムのメタデータは一般的な解釈のメタデータとメタメタデータを含んだような意味に取れる気がします。

また,問題文にある「データ型」,「商品属性名」,「許容値リスト」は標準カリキュラムのメタデータの説明と同意にも取れます。

詰まるところ
顧客番号 と表現するか, データ型 をメタ とするか
基準を何と書くか次第ではないでしょうか。

576 :名無し検定1級さん :2005/03/25(金) 14:53:10
>>574
メタの基準をどこにおくかによるのだが
「個々の」商品や売り上げのデータから言えば「商品番号」などはメタデータ。
どっちでもいいだろうね。
と同意見ですね。


「図2はデータで図4はメタデータ」はさすがにNGだと思いますが。。。(図2はデータじゃないので)

私的には標準カリキュラムを尊重した方が出題者の意図に近いと思います。


関連記事
 H15午後I 問1 vol.2
 H15午後I 問1
 図で見る関数従属性:H15春午後I 問1

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

2005年03月07日

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

H15午後II 問1 vol.3

H15午後II 問1(ITEC 2005予想問題集 午後II 問1) vol.3
vol.1,vol.2

設問1(1)
リレーションをスーパータイプ側に引くか,サブタイブ側に引くかを考える。

発端は,
 物流拠点→配送ルート

これを
 出荷拠点→幹線ルート
 物流拠点→支線ルート
でも良いのではないか?と思ったから。

こう考えた理由は,発地物流拠点コードが取る値の範囲が違うから。(なんか染み込んできてるw)
 幹線ルートの発地物流拠点コードは,出荷拠点しか示さず
 支線ルートの発地物流拠点コードは,物流拠点(出荷拠点,積替拠点)を示すから

 結論としては,発地物流拠点コードはスーパータイプ/サブタイプの主キーを構成する属性なんで,スーパータイプ側に引かないとマズイ。ということでとりあえず整理。(物流拠点→配送ルート)

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

2005年03月06日

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

H15午後II 問2 vol.3

H15午後II 問2(ITEC 2005予想問題集 午後II 問6) vol.3
vol.1,vol.2の続きです。

vol.2の案件
 「もう少し時間をかけて各解答例を検証する必要がありそうだ。vol.3にて。」
と,いうことで。

設問4(2)
参照要件(a)
変更前後の販売実績テーブルは以下のとおり
 
当時大分類コードで選択(WHERE)すれば要件を満たせる。
解答:×

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

2005年02月25日

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

H15午後II 問2 vol.2

H15午後II 問2(ITEC 2005予想問題集 午後II 問6) vol.2
vol.1の続きです。
設問4(1)

 中分類P12の商品コードM122の商品の販売を終了し,その後継品として商品コードM125の販売を開始した。この場合の業務系システムのどのテーブルに対して,どのようなデータ操作を行う必要があるか?

と,いうことであるが,関係あるテーブルは,商品,売価,SKUの3テーブルである。
 商品:
  商品コードM122:終売年月日の設定
  商品コードM125:商品コード追加,商品名の入力,M122から商品の特徴と分類を表す属性(中分類コード,柄コード,デザインコード,素材コード)及び販売期間(販売開始月日,販売終了月日)の継承,発売年月日の設定
 売価:商品コードM125の販売価格の設定
 SKU:商品コードM125のSKUコードの設定 もしくは 商品コードM122と同じカラーコード,サイズコードを自動設定??

もっと書けば,商品販売計画や店舗販売計画,仕入計画は??
これを60文字で書くことは無理だ。。。設問の仕方が悪い気がするのは私だけではあるまい。
ここでの設問の意図は,後継品への属性継承を問うている。と納得しよう。

示現塾解答例

商品マスタに,商品コードM125を発売年月日=商品の切替日で追加し,同時に商品コードM122の終売年月日を同日で更新する。

iTAC解答例
商品テーブルの商品コードM122のレコードに終売年月日を設定し属性と販売期間を継承した商品コードM125のレコードを追加

TAC解答例(web)
商品テーブルに対して商品M122 の終売年月日を登録し,中分類コードP12 などM122 の値を継承した商品M125 を追加する

アイテック解答例(web)
商品テーブル上の商品M122の終売年月日へ販売の終了日を設定し更新する。次に後継品のM122を商品テーブルへ追加する。

DBMagazine解答例
商品テーブル上の商品M122の行の終売年月日に最終販売日を設定した後、商品M125を追加し発売年月日等の情報を設定する。

 ここで注意したい点は,「M122の終売年月日=M125の発売年月日」とか「M122の終売年月日=M125の発売年月日-1日」とかにしなければならないなどドコにも要件が書いていない点である。要件として書いていないことを,勝手に解釈するのは危険と思う。

設問4(2)
(c)
 アイテック解答例(本)は,設問3(1)の後継品テーブルを前提としている。設問4の文章にその前提がないため,後継品テーブルを前提とするのはマズイと思われる。
[解答例]
a,b,c
×××:アイテック(本)
××○:TAC(Web),iTAC,アイテック(web),DB Magazine,g@kko
×○○:示現塾

設問4(3)
 前提条件をどうとらえるのか

サマリテーブルである“大分類別月別販売実績”,“SKU別日別店舗別販売実績”は,それぞれ月末,当日の夜間のバッチ処理で作成される。

 これを読む限り,前月(日)以前のサマリテーブルを現時点で有効な分析軸で再構計算するようには読めない。当月(日)分だけ作成されると読むのが普通だろう。
 この前提条件をどう読むのかで,解答が変わる。
[解答例]
a,b,c
××○:アイテック(web)
○×○:アイテック(本)
×○○:示現塾,DB Magazine,iTAC,TAC(web),g@kko

※アイテックの解答例が,Webと問題集とで食い違っている。。。何を信じれば良いのやら。。。
もう少し時間をかけて各解答例を検証する必要がありそうだ。vol.3にて。

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

2005年02月20日

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

H15午後II 問2

H15午後II 問2(ITEC 2005予想問題集 午後II 問6)
 平成15年の午後II の難しい方。データウェアハウスに関する問題ということもあるが,問題文に説明不足をかなり感じる。

設問1(1)
冷静に考えれば問題ないハズ。
販売実績の販売実績金額を含めないようにしなければならない。
これは,販売実績伝票毎の実績金額。つまりは,当該販売実績伝票の明細の販売価格の合計である。
ひっかからないようにしよう。

設問1(2)
店舗コードの上位階層のエリアコードを忘れないこと。業務内容だけ見てしまうと見落としてしまう。

あとは属性名の付け方(属性名のニュアンス)で悩む。
アイテック解答例

販売目標(目標番号,大分類コード,店舗コード,エリアコード,年度,月,販売目標金額)

示現塾・TAC解答例

販売目標(目標番号,大分類コード,販売店舗コード,エリアコード,年度,月,販売目標金額)

iTAC解答例

販売目標(目標番号,SKUコード,商品コード,当時中分類コード,当時大分類コード,販売店舗コード,エリアコード,月,年度,販売目標金額)

gakko解答例
 販売目標(目標番号,当時大分類コード,販売店舗コード,エリアコード,年度,月,販売目標金額)

 大分類コードは,目標計画当時の大分類コードであるはずなので,「当時大分類コード」とした。
 店舗コードは,他のファクトテーブルと合わせるのが良い。一瞬,まだ販売していないのだから販売と冠することに抵抗があるが,販売計画テーブルも,販売店舗コードとなっているので問題ないと思う。

設問2(1)
 「分析軸テーブルの列名を“階層”としてツールに設定する」の一文を見落とすと痛い。
 年月日を日にしたり,年度を年にしたりするようなミスに繋がる。
 また,業務の言葉を列名に変換せずに,半期コードを半期と書いたり,週番号を週としてしてしまう。
 こういうミスが一番勿体無い。何を書けばいいのかきちんと確認しなければならない。

設問2(2)

(1) 前年対比
 W社の販売実績は,平日と比較して休日の方が多いなど,曜日や祝日かどうかによって異なる傾向にある。日別販売実績の前年対比を行うために,前年の同週同曜日,前年の同一祝日に相当する日及び“前年対応年月日”を管理している。“前年対応年月日”とは,暦日の前年同一日,前年同週同曜日,前年同一祝日のいずれか一つの日付を,前年対比のための標準的な日付として定義したものである。

カレンダ(年月日,週番号,[ 解答 ])


[ 解答 ]に何を追加するか。。。

A:標準しか対象にしなければ,前年対応年月日
B:「管理している」を尊重して,前年同週同曜日,前年同一祝日,前年対応年月日
C:標準SQLで,曜日,祝日が求められない点もフォローして,曜日,祝日区分,前年同週同曜日,前年同一祝日,前年対応年月日
アイテック・TAC・iTAC解答例はB
示現塾解答例はC

gakko解答例は,暦日前年同一日,年同週同曜日,前年同一祝日,前年対応年月日
と,してみた。暦日前年同一日は冗長で省略可と考えることもできるので,その場合はBと同じになる。
 分析ニーズをどう捕らえるかで解答がぶれる気がする。

設問2(3)
 “商品軸テーブルには,現時点で有効な商品階層のデータだけを格納する”を読んで,商品軸に仕入年を入れることが世代管理と思うかどうか,判断しかねる。
 現時点で有効な仕入年だけ格納すれば問題ない。と,いう考え方もできる。

アイテック解答例:販売実績
示現塾・TAC解答例:販売実績,SKU別日別店舗別販売実績
iTAC解答例:販売実績,SKU別日別店舗別販売実績,SKU

販売実績は,まぁ良いとして
 SKU別日別店舗別販売実績には賛同できない。仕入年を追加してしまうと「SKU別仕入年別日別店舗別販売実績」になってしまい,テーブル名が体を現さないことと,元の使い方ができなくなることが理由だ。
 SKUは何故,SKUを追加した意図が読めない。SKUに仕入年を追加してしまうと,
  仕入年毎にSKUコードを変更する(商品の管理単位を変える)か
  図1の商品階層が1階層追加されることになり,{SKUコード,仕入年}が主キーになるか
 のどちらかである。
 前者は問題の大前提をひっくり返すことになり,後者はSKUコードを参照している箇所にすべて仕入年を追加することになる。

設問3(1)
 アイテック解答例の「連関テーブル」という単語が1件もgoogleで引っかからないのが気になる。「連関エンティティ」は何件もヒットするんだが。。。「連関テーブル」というのは標準語なのか??

設問3(2)
 各コードは1グループにしか属さないのかどうかが不明
 各グループに名称が必要なのか不明
 条件はきちんと出すべきだと思うが。。。出題者は神様ですんで。
 柔軟な方,勝手に追加しない方で整理する。各コードは複数のグループに属し,グループ名称は付与しない。

設問4(1) 次回vol.2にて
設問4(2) 次回vol.2にて
設問4(3) 次回vol.2にて

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

2005年02月18日

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

H15午後I 問2 SQL俯瞰

H15午後I 問2(ITEC 2005予想問題集 午後I 問2-1)

設問1(1):外結合

SELECT 部門.部門コード, 部門.部門名, COUNT(社員.社員番号),
  COUNT(受講集計.社員番号),
  SUM(年間受講ポイント数 + 繰越ポイント数),
  SUM(使用ポイント数)
FROM 部門, 社員 LEFT JOIN
  (SELECT 社員番号, SUM(受講ポイント数) AS 使用ポイント数
  FROM 受講, コース
  WHERE 受講.コースコード = コース.コースコード
  AND 受講開始年月日 BETWEEN '2002-04-01' AND '2002-09-30'
  GROUP BY 社員番号 ) 受講集計
  ON 社員.社員番号 = 受講集計.社員番号
WHERE 部門.部門コード = 社員.部門コード
GROUP BY 部門.部門コード, 部門.部門名
ORDER BY 部門.部門コード



設問1(2):IN演算子

SELECT コース.コースコード, コース.コース名
FROM コース, 必修コース, 社員
WHERE 社員番号 = 123456
AND 必修コース.コースコード = コース.コースコード
AND (必修コード.担当職務コード = 社員.担当職務コード1 OR
  必修コード.担当職務コード = 社員.担当職務コード2
)
AND コース.コースコード NOT IN
  (SELECT コースコード
  FROM 受講
  WHERE 社員番号 = 123456
)



設問2(2):外結合

SELECT 部門.部門コード, 部門.部門名, COUNT(社員.社員番号),
  COUNT(受講集計.社員番号),
  SUM((年間受講ポイント数 + 繰越ポイント数) * 兼務比率) AS 利用可能ポイント数合計,
  SUM(使用ポイント数 * 兼務比率) AS 利用ポイント数合計
FROM 部門, 所属, 社員 LEFT JOIN
  (SELECT 社員番号, SUM(受講ポイント数) AS 使用ポイント数
  FROM 受講, コース
  WHERE 受講.コースコード = コース.コースコード
  AND 受講開始年月日 BETWEEN '2002-04-01' AND '2002-09-30'
  GROUP BY 社員番号 ) 受講集計
  ON 社員.社員番号 = 受講集計.社員番号
WHERE 部門.部門コード = 所属.部門コード AND 所属.社員番号 = 社員.社員番号
GROUP BY 部門.部門コード, 部門.部門名
ORDER BY 部門.部門コード

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

2005年02月11日

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

H15午後I 問1 vol.2

H15午後Ⅰ問1(ITEC 2005予想問題集 午後Ⅰ問1-1)

 図2の関数従属図の関数従属図だけ見て設問1~設問2(2)までは解ける。
 しかし,設問2(3)で躓くはずだ。

 第2正規形でないことを指摘するために図2で部分関数従属を探すが・・・あれ?ない??という感じかな。
 図2は主な関数従属性で完全ではない。完全と思い込んでいると迷路の中だ。
 ここは表1の「主要な属性及びその意味」の「主商品番号」,「副商品番号」を見ないと思考の迷路から抜け出せない。

о 午後Ⅰ基礎理論を選択して問題を解く(読む)前に,関数従属図があって「主な」若しくは「未完成」があればアンダーラインか○で囲んどこう。
о 一般的な属性名でも意味の確認は忘れずに。そこには関数従属性が潜んでいる。かも。


関連記事
 H15午後I 問1 vol.3
 H15午後I 問1
 図で見る関数従属性:H15春午後I 問1

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

2005年02月06日

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

H15午後II 問1 vol.2

H15午後II 問1(ITEC 2005予想問題集 午後II 問1) vol.2 vol.1

設問3

Commented by 9 at 2005年02月05日 16:55
ここは設問3以降が鬼問難問なわけで、当時の俺は手も足も出なかったw
その頃の某ログではこの鬼問を選択しない神の一声も合格には必要って声があったくらいw

確かに・・・(2)は,まぁいいとして

設問3(1)
 「図9で示した範囲のエンティティタイプについて,発生するスキーマ構造の変化の内容を50字以内で述べよ。」
 「スキーマ構造の変化の内容」?
 最初は何を書いていいのか戸惑った。
 そして,苦し紛れに
 「出荷明細毎に幹線便の配送車手配情報を保持できる」とか書いたりして(苦笑

 解答例見て,あぁ~関係スキーマの変更点を言えば良かったのね。と。反省しました。
 「構造」という単語で設問の主旨を見失ってました。

設問3(3)
 (1)がB案,(2)がC案。(3)はA案。。。想像はついたw

 しかし,
 〔荷ぞろえスペースの調整業務〕の
  ・製品別の出荷件数
  ・製品別の出荷1件当たりの平均数量
 を誤解してしまい,道(答え)を誤る。

 前の設問(2)のインスタンスを書いた時点で,1行が1件と錯覚していた。
 一つの出荷を分割していたことを失念していたのだ。

 で,何も考えずそのままC案と書く。・・・ A案,B案の検証もせずに(汗;
 (時間に余裕はあったんだけどね)

 適切と考えられる理由は,正解のA案で書いてたら部分点もらえるかな?程度。
 C案で書いていたら部分点は無いんだろうね。(たぶん)

 ホント,午後Ⅱのどちらを解くか見極める眼力が必要だね。
 でも,この年の問2設問4も難問だと思うな・・・。これはまた別の機会に。

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

2005年02月05日

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

H15午後II 問1

H15午後II 問1(ITEC 2005予想問題集 午後II 問1)
 2005予想問題集の午後II の1問目

 問題集の書き込みを後で消しゴムで消すのが面倒くさいとからと言って,書き込みをせずに問題を解くと必ず見落としがある(苦笑

設問1(1)
 設問1の概念データモデルの問題も,関係スキーマをまず先に見て外部キーをきっちり認識した上で,問題文の業務説明と比較しながらリレーションを書いていけば間違わないハズだ。

 この問題は,スキーマも完成形(一部未完とか書いてないし)だし,データモデルへのエンティティ追加もない。午後II の中では簡単な方に分類される問題である。チェックミスで点を落とすのはあまりにも惜しい。
 本番でも問題集には書き込むハズだ。問題集とはいえ,同じ体勢で挑まないと点を落としてしまう。

設問2(3)(オ)
 ITECの解答例はあんまりだ。
  解答例:「(ウ),(エ)以外の出荷の場合」
 (ウ)か(エ)を間違えば,自動的に(オ)も間違う書き方。

 (オ)を具体的に書くのが安全サイドなのか,書かない方が安全サイドなのかは,(ウ),(エ)の書きっぷり次第だろが,少なくとも(ウ),(エ),(オ)の解答に自信がなければ,部分点狙いで具体的に書いた方が良いだろう。

Posted by g@kko at 2005/02/05 15:23 | 個別記事表示 | コメントを見る (2) |
この記事をLicWikiに埋め込む:
( すべて |  1  |  2 ) 次へ