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で引っかからないのが気になる。「連関エンティティ」は何件もヒットするんだが。。。「連関テーブル」というのは標準語なのか？？
設問３（２）
各コードは１グループにしか属さないのかどうかが不明
各グループに名称が必要なのか不明
条件はきちんと出すべきだと思うが。。。出題者は神様ですんで。
柔軟な方，勝手に追加しない方で整理する。各コードは複数のグループに属し，グループ名称は付与しない。
H13AM38:示現塾 2005年02月20日(日) 本格版 287号 第４問
第４問 データベース技術（ＤＢ向け）
分野－5-1-3／技術レベル－III／出題頻度－中／出典：DB13-38
本問は、図表を含みますので、下記をクリックしてください。
http://zigen.cosmoconsulting.co.jp/mailmag/pic/2005-02-20-4.htm
トランザクションの並行制御において，変更喪失(lost update)の問題，コミットされていない依存性(uncommitted dependency)の問題，不整合分析(inconsistent analysis)の問題が起こる可能性がある。これらの問題を解決する技術と，この技術を使うことによって新たに発生する問題の組合せはどれか。
示現塾 2005年02月20日(日) 本格版 287号 第２問
第２問 システムの開発と運用（ＳＷ，ＤＢ，ＳＭ，ＡＵ，ＥＳ向け）
分野－3-2-1／技術レベル－II／出題頻度－高／出典：CM15-28
システム運用部門でCPU 利用率，ページフォールト頻度などを監視したところ，スラッシングの発生が多くなっていることが分かった。処理能力を改善するための当面の対応処置として，適切なものはどれか。
ア 磁気ディスクの作業域（ワークエリア）の割当てを変更する。
イ ジョブの多重度を抑制する。
ウ ページ置換方式を変更する。
エ 予備の補助記憶装置を組み込んで作業域の割当てを再配置する。
示現塾 2005年02月20日(日) 本格版 287号 第１問
第１問 コンピュータシステム（ＳＷ，ＤＢ，ＳＭ，ＡＵ，ＥＳ向け）
分野－2-3-3／技術レベル－II／出題頻度－中／出典：SM15-11
本問は、図表を含みますので、下記をクリックしてください。
http://zigen.cosmoconsulting.co.jp/mailmag/pic/2005-02-20-1.htm
iTAC掲示板派生オリジナル vol.1
過去問に飽きたころ↓に挑戦してみよう！
iTAC内テクニカルエンジニア（データベース）掲示板（2002.05.01-2003.12.31までのログ）より
設問１
健康保険被保険者証の様式をヒントにボトムアップアプローチの問題 投稿者：シカ狂う 投稿日：3/10 14:08:34システムの帳票、画面からのデータ項目の拾い出し→正規化→E-Rモデルの作成
をボトムアップアプローチといいます。
午後Ⅱの定番ですが、以下のような健康保険被保険者証の様式をヒントに、そのような問題を作問してみようと思います。
（あくまで作問に徹しているため、下の様式は現実とかけ離れている箇所もあるかと思いますがご容赦ください）健康保険被保険者証
交付年月日 ：2000年01月01日
被保険者番号 ：111111
被保険者氏名 ：川崎次郎 フリガナ：カワサキジロウ
被保険者住所 ：神奈川県川崎市高津区高津1-2-3
被保険者生年月日：1945年01月01日
資格取得年月 ：1970年08月
事業所所在地 ：神奈川県横浜市中央区中央1-2-3
事業所名称 ：あいうえお株式会社
保険者所在地 ：神奈川県横浜市○○区○○1-2-3
保険者番号 ：1111
保険者名称 ：○○社会保険事務所被扶養者氏名 フリガナ 続柄コード 続柄 生年月日 性別
川崎花子 カワサキハナコ 02 妻 1950年02月02日 女
川崎智子 カワサキトモコ 21 長女 1975年03月03日 女（念のため、住所はH13春DB午後Ⅰ問2を引用したものであり、実在するものではありません。）
まずこれを関係スキーマとして表してみます。
被保険者（交付年月日、被保険者番号、被保険者氏名、被保険者住所、被保険者生年月日、
資格取得年月、事業所所在地、事業所名称、保険者所在地、保険者番号、保険者名称、
被扶養者氏名1、被扶養者フリガナ1、続柄コード1、生年月日1、性別1、
被扶養者氏名2、被扶養者フリガナ2、続柄コード2、生年月日2、性別2、
被扶養者氏名3、被扶養者フリガナ3、続柄コード3、生年月日3、性別3、
被扶養者氏名4、被扶養者フリガナ4、続柄コード4、生年月日4、性別4）続柄（続柄コード、続柄名）
#「性別」はさすがに2値なのでコード化しないほうがよいでしょうか。
問題点1：主キー、外部キーが明示されていない。
設問1
関係スキーマ“被保険者”の主キー、外部キーを示せ。この題材のおもしろさは、“被保険者”をうまく工夫して分割して正規化すると、
家族が被扶養者から抜け出した国民健康保険被保険者証のようなスキーマが得られることです。
（ってかなりかなり無理があるでしょうか^^；）
Re:問題 投稿者：シカ狂う 投稿日：3/10 21:10:28あ、そういえばこれってけっこう業務知識がいるので、属性の意味を書き忘れてました。
とりあえず必要最低限なものだけ。被保険者番号：健康保険組合の中で一意になるように振られた、被保険者を識別する番号
健康保険組合に入った順番に新しい番号が付与される。
保険者番号：健康保険組合を一意に識別する番号
2002年10月1日現在の全国の健康保険組合数は1,687である。もしかして現実とはちょっと違うでしょうか？あまり詳しくないのでどんどん突っ込みお願いします。
問題（条件追加） 投稿者：シカ狂う 投稿日：3/10 22:50:24健康保険被保険者証は定期的に再交付せねばなりません。
健康保険被保険者証は再交付ごとに色が変わり、その一つ一つを識別したい。
Re:問題 投稿者：シカ狂う 投稿日：3/11 10:03:46> ただ、紛失などによる再交付でも色が変わるのか？
> また、被保険者証の色が保持されていなくてもいいのか？という点を確認したいところです。なるほど、では紛失などによる再交付の場合は色は変わらないものとします。
以下のように色テーブルを新たに追加し、色コードという属性を“被保険者”に追加します。
同じ色の再利用はしないものとします。また、少し勘違いしていたようなのですが、
> 被保険者番号：健康保険組合の中で一意になるように振られた、被保険者を識別する番号
> 健康保険組合に入った順番に新しい番号が付与される。
ではなく、
被保険者番号：健康保険組合に加入している会社の中で一意になるように振られた、被保険者を識別する番号
会社に入った順番に新しい番号が付与される。
であり、新たに
被保険者記号：会社を一意に識別する記号
というのを設けます。
#場合によっては、この記号と番号を一緒にして記号番号としているところもあるようですが、ここでは分けます。被保険者（交付年月日、色コード、被保険者記号、被保険者番号、
被保険者氏名、フリガナ、被保険者住所、被保険者生年月日、資格取得年月、
事業所所在地、事業所名称、
保険者所在地、保険者番号、保険者名称、
被扶養者氏名1、被扶養者フリガナ1、続柄コード1、生年月日1、性別1、
被扶養者氏名2、被扶養者フリガナ2、続柄コード2、生年月日2、性別2、
被扶養者氏名3、被扶養者フリガナ3、続柄コード3、生年月日3、性別3、
被扶養者氏名4、被扶養者フリガナ4、続柄コード4、生年月日4、性別4）続柄（続柄コード、続柄名）
色（色コード、色名称）
