2005年03月27日
H15午後I 問3 vol.2
Ｈ１５午後I 問３（ITEC 2005予想問題集 午後I 問３－１）
設問２（２）
599 ：名無し検定１級さん ：2005/03/26(土) 21:33:48
午後１のＳＱＬは、今年も例年通り何の変哲もない問題なのだろうか？
ＳＱＬ９９まで押さえてないとだめかな？
いきなり突拍子もない問題だされたら困るなあ。ところで、平成１５年午後１の「セットメニュー」「セット料理」の問題って、
どういう議論に落ち着いていたのか知ってる人いる？
愛テックの解答だと、「セットメニュー（主料理番号、セット料理番号）」
が最もスマートな解ということになってるが。601 ：名無し検定１級さん ：2005/03/26(土) 21:46:49
>>599
出ても１設問。影響は少ないんでは？
平成１５年午後１はそれでいいと思うよ602 ：599：2005/03/26(土) 21:51:42
ぼくは当時「セットメニュー（主料理番号、セット料理番号）」に加えて
「セット料理（セット料理番号，セット構成料理番号）」も書いてしまったんだ。
やっぱ冗長だってことで、減点あるいはゼロだったのかな。当時も勿論落ちたけど。
今年が３度目の挑戦なのねん。 612 ：名無し検定１級さん ：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 ：名無し検定１級さん ：2005/03/27(日) 01:31:15
って、すぐ前の>>599に同じネタが。スマソ。
自分も、セットメニュー(主料理番号、セット料理番号)だけだと思うなぁ。
問題文にはごちゃごちゃと細かく説明してるけど、
注文管理上はセット料理の詳細なんて無関係だし。
と，いうことで
出題者の意図
問題点④ セット料理及びセットメニューの管理が漏れている。を汲んだ解答としては，伝統的な
（解答例：Ａ）
セット料理(セット料理番号，セット料理名，価格)
セット料理内容(セット料理番号，料理番号)
セットメニュー(セット料理番号，主料理番号)
が，一番良いと思います。
TAC解答速報，アイタック本は
（解答例：Ｂ）
セットメニュー(主料理番号，セット料理番号)
（※アイタック本はセット料理，セット料理内容，セットメニューの３テーブルを別解としている）
と，なっています。
非常に合理的な解答であると思いますが，出題者の意図とズレる気がするのと，午後I でここまでの汎化は求めないでしょう。。。
それと，
料理（料理番号，料理名，単価，料理区分）
料理区分：単品料理なのか主料理なのかセット料理なのか区別するためのカテゴリ識別子が欲しいところ。この区分がないとアプリ側の負担が大きいと思われます。
“意図とズレる気がする”というのは，
料理（料理番号，料理名，単価）でセット料理が管理をするのであれば，「セット料理の管理が漏れている」とは書かないのではないでしょうか。。。この解答例だと「主料理とセット料理，及びセット料理を構成する単品料理の管理が漏れている」という表現になると思うんだけどな。
次に示現塾解答例
（解答例：Ｃ）
セット料理内容(セット料理番号,料理番号)
セットメニュー(セット料理番号,主料理番号)
セット料理(セット料理番号,セット料理名,価格) は，
料理（料理番号，料理名，単価） で管理するパターン。
インスタンス例：料理（4400，サラダセット，250）
セット料理には，それを構成する単品料理とは別の料理番号を付与する。とあるので，料理番号の重複もないのでこの解答例は別解でＯＫな気もしますが，解答例Ｂの“意図とズレる気がする”と同じっすな。。。
ひとつ気になるのは。。。「解答欄の大きさ」ｗ
どのくらいだったんでしょうね。。。
類問
H13午後I 問２ 設問３
H13午後II 問２ 設問１（４）
関連記事
H15午後I 問3
2005年03月25日
H15午後I 問1 vol.3
Ｈ１５午後I 問１（ITEC 2005予想問題集 午後I 問１－１）
574 ：名無し検定１級さん ：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
どっちが正解だろう。翔泳社の回答例もメタデータとメタメタデータの違いとあるけど、
図２がなぜメタデータを表すと解釈できるのかわからん。
まずは各解答例を確認。
示現塾ほう，アイテックは少数派だったんですな。。。
図２の対象は、通常のデータであるのに対して、図４の対象は、メタデータであるＴＡＣ解答速報
図２の対象はメタデータのみであるが，図４はメタデータを定義するメタデータを含むDB Magazine
図２は実業務に関わるデータ構造、図４はデータ構造の管理構造を対象としている。
（メタデータとメタメタデータの違い）アイテック解答速報
図２はメタデータレベルを対象とするが、図４はメタメタデータレベルを対象とする。アイテック本
図２は属性データであるが，図４は属性データのメタデータで，データレベルが違う。iTAC
図２は各属性に関する記述だが、図４は各属性の定義に関する記述が主である
メタデータの定義を確認。
IPA > IT人材の発掘・育成関連 > 人材育成推進センター > 研修カリキュラム > テクニカルエンジニア(データベース)
（３）メタデータ
１ メタデータの役割
データに関する情報のこと
２ メタデータ含まれる内容
データ定義，データ構造，ルール（制約），データの意味，データの出所，データの保管場所
一般的な解釈としては。。。
データ総研 > 技術情報 > DRI通信 > 【第89号】メタデータ扱いの進化
■ メタデータ
「メタデータとは、データのデータである」などと説明されています。これは定義として不十分ですが、たとえば社員レコード
［１］ －（椿正明、男、６８、会長）
［２］ －（竹下茂、男、６２、専務）
を
［社員番号］－（社員氏名、性別、年齢、役職）
として捉えるときの、社員番号、社員氏名、性別などである、と言えばおおむね理解していただけるでしょう。■ メタメタデータ
これらのメタデータを捉えるフレームワークとして、
［属性番号］－（属性名、所属エンティティ、属性区分、属性値区分、桁数）
ただし、属性区分：ＫＥＹ、ＲＫＥＹ、加工データなどの別
属性値区分：コード、テキスト、数量などの別
などを規定することができます。これはメタデータについてのメタデータということで、メタメタデータと言うことがあります。メタメタデータは、メタデータの構造を明示するものということができます。
と，いうことで
一般的な解釈で行けば，「図２はメタデータで図４はメタメタデータ」ということですが，
標準カリキュラムのメタデータは一般的な解釈のメタデータとメタメタデータを含んだような意味に取れる気がします。
また，問題文にある「データ型」，「商品属性名」，「許容値リスト」は標準カリキュラムのメタデータの説明と同意にも取れます。
詰まるところ
顧客番号 を 何 と表現するか， データ型 をメタ 何 とするか
基準を何と書くか次第ではないでしょうか。
576 ：名無し検定１級さん ：2005/03/25(金) 14:53:10と同意見ですね。
>>574
メタの基準をどこにおくかによるのだが
「個々の」商品や売り上げのデータから言えば「商品番号」などはメタデータ。
どっちでもいいだろうね。
「図２はデータで図４はメタデータ」はさすがにＮＧだと思いますが。。。（図２はデータじゃないので）
私的には標準カリキュラムを尊重した方が出題者の意図に近いと思います。
2005年03月07日
H15午後II 問1 vol.3
Ｈ１５午後II 問１（ITEC 2005予想問題集 午後II 問１） vol.3
vol.1,vol.2
設問１（１）
リレーションをスーパータイプ側に引くか，サブタイブ側に引くかを考える。
発端は，
物流拠点→配送ルート
これを
出荷拠点→幹線ルート
物流拠点→支線ルート
でも良いのではないか？と思ったから。
こう考えた理由は，発地物流拠点コードが取る値の範囲が違うから。（なんか染み込んできてるｗ）
幹線ルートの発地物流拠点コードは，出荷拠点しか示さず
支線ルートの発地物流拠点コードは，物流拠点（出荷拠点，積替拠点）を示すから
結論としては，発地物流拠点コードはスーパータイプ／サブタイプの主キーを構成する属性なんで，スーパータイプ側に引かないとマズイ。ということでとりあえず整理。（物流拠点→配送ルート）
2005年03月06日
H15午後II 問2 vol.3
2005年02月25日
H15午後II 問2 vol.2
Ｈ１５午後II 問2（ITEC 2005予想問題集 午後II 問6） vol.2
vol.1の続きです。
設問４（１）
中分類P12の商品コードM122の商品の販売を終了し，その後継品として商品コードM125の販売を開始した。この場合の業務系システムのどのテーブルに対して，どのようなデータ操作を行う必要があるか？
と，いうことであるが，関係あるテーブルは，商品，売価，SKUの３テーブルである。
商品：
商品コードM122：終売年月日の設定
商品コードM125：商品コード追加，商品名の入力，M122から商品の特徴と分類を表す属性（中分類コード，柄コード，デザインコード，素材コード）及び販売期間（販売開始月日，販売終了月日）の継承，発売年月日の設定
売価：商品コードM125の販売価格の設定
SKU：商品コードM125のSKUコードの設定 もしくは 商品コードM122と同じカラーコード，サイズコードを自動設定？？
もっと書けば，商品販売計画や店舗販売計画，仕入計画は？？
これを60文字で書くことは無理だ。。。設問の仕方が悪い気がするのは私だけではあるまい。
ここでの設問の意図は，後継品への属性継承を問うている。と納得しよう。
示現塾解答例
商品マスタに，商品コードM125を発売年月日＝商品の切替日で追加し，同時に商品コードM122の終売年月日を同日で更新する。
iTAC解答例
商品テーブルの商品コードＭ１２２のレコードに終売年月日を設定し属性と販売期間を継承した商品コードＭ１２５のレコードを追加
TAC解答例(web)
商品テーブルに対して商品M122 の終売年月日を登録し，中分類コードP12 などM122 の値を継承した商品M125 を追加する
アイテック解答例(web)
商品テーブル上の商品Ｍ１２２の終売年月日へ販売の終了日を設定し更新する。次に後継品のＭ１２２を商品テーブルへ追加する。
DBMagazine解答例
商品テーブル上の商品M122の行の終売年月日に最終販売日を設定した後、商品M125を追加し発売年月日等の情報を設定する。
ここで注意したい点は，「M122の終売年月日＝M125の発売年月日」とか「M122の終売年月日＝M125の発売年月日－１日」とかにしなければならないなどドコにも要件が書いていない点である。要件として書いていないことを，勝手に解釈するのは危険と思う。
設問４（２）
（ｃ）
アイテック解答例(本)は，設問３（１）の後継品テーブルを前提としている。設問４の文章にその前提がないため，後継品テーブルを前提とするのはマズイと思われる。
[解答例]
ａ，ｂ，ｃ
×××：アイテック(本)
××○：TAC(Web)，iTAC，アイテック(web)，DB Magazine，g@kko
×○○：示現塾
設問４（３）
前提条件をどうとらえるのか
サマリテーブルである“大分類別月別販売実績”，“SKU別日別店舗別販売実績”は，それぞれ月末，当日の夜間のバッチ処理で作成される。
これを読む限り，前月（日）以前のサマリテーブルを現時点で有効な分析軸で再構計算するようには読めない。当月（日）分だけ作成されると読むのが普通だろう。
この前提条件をどう読むのかで，解答が変わる。
[解答例]
ａ，ｂ，ｃ
××○：アイテック(web)
○×○：アイテック(本)
×○○：示現塾，DB Magazine，iTAC，TAC(web)，g@kko
※アイテックの解答例が，Ｗｅｂと問題集とで食い違っている。。。何を信じれば良いのやら。。。
もう少し時間をかけて各解答例を検証する必要がありそうだ。vol.3にて。
2005年02月20日
H15午後II 問2
Ｈ１５午後II 問2（ITEC 2005予想問題集 午後II 問6）
平成15年の午後II の難しい方。データウェアハウスに関する問題ということもあるが，問題文に説明不足をかなり感じる。
設問１（１）
冷静に考えれば問題ないハズ。
販売実績の販売実績金額を含めないようにしなければならない。
これは，販売実績伝票毎の実績金額。つまりは，当該販売実績伝票の明細の販売価格の合計である。
ひっかからないようにしよう。
設問１（２）
店舗コードの上位階層のエリアコードを忘れないこと。業務内容だけ見てしまうと見落としてしまう。
あとは属性名の付け方（属性名のニュアンス）で悩む。
アイテック解答例
販売目標（目標番号，大分類コード，店舗コード，エリアコード，年度，月，販売目標金額）
示現塾・ＴＡＣ解答例
販売目標（目標番号，大分類コード，販売店舗コード，エリアコード，年度，月，販売目標金額）
iTAC解答例
販売目標（目標番号，SKUコード，商品コード，当時中分類コード，当時大分類コード，販売店舗コード，エリアコード，月，年度，販売目標金額）
gakko解答例
販売目標（目標番号，当時大分類コード，販売店舗コード，エリアコード，年度，月，販売目標金額）
大分類コードは，目標計画当時の大分類コードであるはずなので，「当時大分類コード」とした。
店舗コードは，他のファクトテーブルと合わせるのが良い。一瞬，まだ販売していないのだから販売と冠することに抵抗があるが，販売計画テーブルも，販売店舗コードとなっているので問題ないと思う。
設問２（１）
「分析軸テーブルの列名を“階層”としてツールに設定する」の一文を見落とすと痛い。
年月日を日にしたり，年度を年にしたりするようなミスに繋がる。
また，業務の言葉を列名に変換せずに，半期コードを半期と書いたり，週番号を週としてしてしまう。
こういうミスが一番勿体無い。何を書けばいいのかきちんと確認しなければならない。
設問２（２）
(1) 前年対比
W社の販売実績は，平日と比較して休日の方が多いなど，曜日や祝日かどうかによって異なる傾向にある。日別販売実績の前年対比を行うために，前年の同週同曜日，前年の同一祝日に相当する日及び“前年対応年月日”を管理している。“前年対応年月日”とは，暦日の前年同一日，前年同週同曜日，前年同一祝日のいずれか一つの日付を，前年対比のための標準的な日付として定義したものである。カレンダ（年月日，週番号，[ 解答 ]）
[ 解答 ]に何を追加するか。。。
A:標準しか対象にしなければ，前年対応年月日
B:「管理している」を尊重して，前年同週同曜日，前年同一祝日，前年対応年月日
C:標準SQLで，曜日，祝日が求められない点もフォローして，曜日，祝日区分，前年同週同曜日，前年同一祝日，前年対応年月日
アイテック・TAC・iTAC解答例はB
示現塾解答例はC
gakko解答例は，暦日前年同一日，年同週同曜日，前年同一祝日，前年対応年月日
と，してみた。暦日前年同一日は冗長で省略可と考えることもできるので，その場合はBと同じになる。
分析ニーズをどう捕らえるかで解答がぶれる気がする。
設問２（３）
“商品軸テーブルには，現時点で有効な商品階層のデータだけを格納する”を読んで，商品軸に仕入年を入れることが世代管理と思うかどうか，判断しかねる。
現時点で有効な仕入年だけ格納すれば問題ない。と，いう考え方もできる。
アイテック解答例：販売実績
示現塾・TAC解答例：販売実績，SKU別日別店舗別販売実績
iTAC解答例：販売実績，SKU別日別店舗別販売実績，SKU
販売実績は，まぁ良いとして
SKU別日別店舗別販売実績には賛同できない。仕入年を追加してしまうと「SKU別仕入年別日別店舗別販売実績」になってしまい，テーブル名が体を現さないことと，元の使い方ができなくなることが理由だ。
SKUは何故，SKUを追加した意図が読めない。SKUに仕入年を追加してしまうと，
仕入年毎にSKUコードを変更する（商品の管理単位を変える）か
図１の商品階層が１階層追加されることになり，｛SKUコード，仕入年｝が主キーになるか
のどちらかである。
前者は問題の大前提をひっくり返すことになり，後者はSKUコードを参照している箇所にすべて仕入年を追加することになる。
設問３（１）
アイテック解答例の「連関テーブル」という単語が１件もgoogleで引っかからないのが気になる。「連関エンティティ」は何件もヒットするんだが。。。「連関テーブル」というのは標準語なのか？？
設問３（２）
各コードは１グループにしか属さないのかどうかが不明
各グループに名称が必要なのか不明
条件はきちんと出すべきだと思うが。。。出題者は神様ですんで。
柔軟な方，勝手に追加しない方で整理する。各コードは複数のグループに属し，グループ名称は付与しない。
2005年02月18日
H15午後I 問2 SQL俯瞰
Ｈ１５午後I 問２（ITEC 2005予想問題集 午後I 問２－１）
設問１（１）：外結合
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 部門.部門コード
設問１（２）：IN演算子
SELECT コース.コースコード, コース.コース名
FROM コース, 必修コース, 社員
WHERE 社員番号 = 123456
AND 必修コース.コースコード = コース.コースコード
AND (必修コード.担当職務コード = 社員.担当職務コード１ OR
必修コード.担当職務コード = 社員.担当職務コード２)
AND コース.コースコード NOT IN
(SELECT コースコード
FROM 受講
WHERE 社員番号 = 123456)
設問２（２）：外結合
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 部門.部門コード
2005年02月11日
H15午後I 問1 vol.2
Ｈ１５午後Ⅰ問１（ITEC 2005予想問題集 午後Ⅰ問１－１）
図２の関数従属図の関数従属図だけ見て設問１～設問２（２）までは解ける。
しかし，設問２（３）で躓くはずだ。
第２正規形でないことを指摘するために図２で部分関数従属を探すが・・・あれ？ない？？という感じかな。
図２は主な関数従属性で完全ではない。完全と思い込んでいると迷路の中だ。
ここは表１の「主要な属性及びその意味」の「主商品番号」，「副商品番号」を見ないと思考の迷路から抜け出せない。
о 午後Ⅰ基礎理論を選択して問題を解く（読む）前に，関数従属図があって「主な」若しくは「未完成」があればアンダーラインか○で囲んどこう。
о 一般的な属性名でも意味の確認は忘れずに。そこには関数従属性が潜んでいる。かも。
2005年02月06日
H15午後II 問1 vol.2
Ｈ１５午後II 問１（ITEC 2005予想問題集 午後II 問１） vol.2 vol.1
設問３
Commented by 9 at 2005年02月05日 16:55
ここは設問3以降が鬼問難問なわけで、当時の俺は手も足も出なかったｗ
その頃の某ログではこの鬼問を選択しない神の一声も合格には必要って声があったくらいｗ
確かに・・・（２）は，まぁいいとして
設問３（１）
「図９で示した範囲のエンティティタイプについて，発生するスキーマ構造の変化の内容を５０字以内で述べよ。」
「スキーマ構造の変化の内容」？
最初は何を書いていいのか戸惑った。
そして，苦し紛れに
「出荷明細毎に幹線便の配送車手配情報を保持できる」とか書いたりして（苦笑
解答例見て，あぁ～関係スキーマの変更点を言えば良かったのね。と。反省しました。
「構造」という単語で設問の主旨を見失ってました。
設問３（３）
（１）がＢ案，（２）がＣ案。（３）はＡ案。。。想像はついたｗ
しかし，
〔荷ぞろえスペースの調整業務〕の
・製品別の出荷件数
・製品別の出荷１件当たりの平均数量
を誤解してしまい，道（答え）を誤る。
前の設問（２）のインスタンスを書いた時点で，１行が１件と錯覚していた。
一つの出荷を分割していたことを失念していたのだ。
で，何も考えずそのままＣ案と書く。・・・ Ａ案，Ｂ案の検証もせずに（汗；
（時間に余裕はあったんだけどね）
適切と考えられる理由は，正解のＡ案で書いてたら部分点もらえるかな？程度。
Ｃ案で書いていたら部分点は無いんだろうね。（たぶん）
ホント，午後Ⅱのどちらを解くか見極める眼力が必要だね。
でも，この年の問２設問４も難問だと思うな・・・。これはまた別の機会に。
2005年02月05日
H15午後II 問1
Ｈ１５午後II 問１（ITEC 2005予想問題集 午後II 問１）
2005予想問題集の午後II の１問目
問題集の書き込みを後で消しゴムで消すのが面倒くさいとからと言って，書き込みをせずに問題を解くと必ず見落としがある(苦笑
設問１（１）
設問１の概念データモデルの問題も，関係スキーマをまず先に見て外部キーをきっちり認識した上で，問題文の業務説明と比較しながらリレーションを書いていけば間違わないハズだ。
この問題は，スキーマも完成形（一部未完とか書いてないし）だし，データモデルへのエンティティ追加もない。午後II の中では簡単な方に分類される問題である。チェックミスで点を落とすのはあまりにも惜しい。
本番でも問題集には書き込むハズだ。問題集とはいえ，同じ体勢で挑まないと点を落としてしまう。
設問２（３）（オ）
ITECの解答例はあんまりだ。
解答例：「（ウ），（エ）以外の出荷の場合」
（ウ）か（エ）を間違えば，自動的に（オ）も間違う書き方。
（オ）を具体的に書くのが安全サイドなのか，書かない方が安全サイドなのかは，（ウ），（エ）の書きっぷり次第だろが，少なくとも（ウ），（エ），（オ）の解答に自信がなければ，部分点狙いで具体的に書いた方が良いだろう。
