【教科書系】
・　新版 データベース技術（ＩＴＥＣ） [レビュー]
・　データベース完全教本〈2006年版〉　iTac＠水岡氏著　（日本経済新聞社）
・　情報処理教科書 テクニカルエンジニア [データベース] 2006年度版　（翔泳社）
　（経林書房）
・　テクニカルエンジニア データベース合格完全対策〈2006年版〉　（経林書房）
・　３週間完全マスター テクニカルエンジニア(データベース)2006年版　（日経BP社）

【午前対策】
・　テクニカルエンジニア データベースコンパクトブック（リック） 正誤表
・　テクニカルエンジニアデータベース午前合格精選400題試験問題（東京電機大学出版）

【午後対策】

【過去問集】
・　テクニカルエンジニア データベース過去問題&分析〈2006年版〉

【オススメ副読本】
　グラス片手にデータベース設計~販売管理システム編
　　⇒午後II の物流・販売関係の問題の下支えに。
　業務別データベース設計のためのデータモデリング入門
　　⇒モデリングの入門用。この本の正規化論は試験の参考にしない方が良い。第２部のモデリング例は午後II の下支えになるかも。
　生産管理・原価管理システムのためのデータモデリング
　実践的データモデリング入門
　データモデリング基礎講座

便利なプラグインがあるっぽいが，今回は，DB(MySQL)をSQLで直接更新してしまおうと思い立つ。

と，いうことで，phpMyAdminを開きSQLを流す。

あるブログＩＤのエントリーのコメントのオープンをクローズに
（とりあえず今回は，６月までの記事をクローズに）

update `mt_entry` set `entry_allow_comments` = 2 where `entry_blog_id` = 「ブログのID」 and `entry_allow_comments` = 1 and `entry_created_on` < '2005-07-01 00:00:00'

あるブログＩＤのエントリーの「トラックバックを受けつける」のチェックをオフに

update `mt_entry` set `entry_allow_pings` = 0 where `entry_blog_id` = 「ブログのID」 and `entry_allow_pings` = 1 and `entry_created_on` < '2005-07-01 00:00:00'

ブログにコメント／トラックバックをいただいても気付かない可能性大です。

記事の検索はgoogleより，左の「サイト内の検索」が便利です。

※スパム対策にコメントをクローズ，トラックバックを受け付けない設定に変更しました。
　秋試験が終わった頃に，オープンにしたいと思います。

早速明日，会社で一時金の申請をしますです。

メールを送って中洲にでも連れて行ってもらおうｗ

緑は合格者（JITECの発表より）

（※教室に一番乗りで到着したので，座席表を写真で撮っておきました）

私が受験した教室は受験申込者数は110名。で，合格者は6名。
合格者/申込者 = 5.45%

全体では，合格者：956/申込者：22610 = 4.23%
110人の教室で，合格者は平均4.7人

プロマネもこのくらいの率だよな。。。
キアイを入れなおさないと。

みなさまのご協力の甲斐ありまして，
情報処理を生業としていない素人の私が無事，合格することができました。
コメント（ツッコミ）を頂いた みなさま，本当にありがとうございました。 m(_ _)m

結果は，
　
午後I と午後II の手応えとスコアが逆転しています。。
午後I が難しく，午後II が簡単だったということですかね。

統計資料の方に目を向けると，合格率は7.6%と前年より，0.9ポイント減でした。
　（ 合格者数／受験者数　＝　956／12,546 ）

自己採点との対比は手元に資料がないので，後ほど。

いよいよ明日，正午です。

合否はタイトルでｗ
　合　格：素人が目指したテクニカルエンジニア（データベース）
　不合格：素人が来年も目指すテクニカルエンジニア（データベース）

http://www.jitec.jp/1_05goukaku/kaitourei.html

設問３（１）
　駐車場設備単位の点検実績は全件保持するが，点検結果項目別の点検結果については，異常時のものだけを保持するスキーマ設計にしている。この方法で，正常時及び異常時とも管理可能である理由について
　駐車場設備単位の点検実績は全件保持＝「駐車場設備点検」はある。
　正常時は「部位装置点検結果」と「検出異常」がない。

解答例
駐車場設備点検の主キーを持つ部位装置点検結果・検出異常が存在しなければ，それぞれ部位・点検項目は正常と判断できるため。（５９文字）
※異常時のものだけを保持するスキーマ設計にしているが，この方法でも正常時のデータ登録が可能である理由
　とも読めなくも無い。。属性＠修理区分に“正常”を追加するとかｗ

設問３（２）（ａ）
同音異義語を指摘すれば良いかと。
解答例
部位装置点検項目の開始年月日と点検項目の開始年月日は同音意義語であるため参照関係を設定できない。（４８文字）

設問３（２）（ｂ）
解答例
テーブル“点検項目”の属性“開始年月日”をテーブル“部位装置点検項目”の“開始年月日”と同意にし，新たにテーブル“点検項目”に属性“正常条件開始年月日”を主キーの構成列として追加し，列として“正常条件終了年月日”を追加する。（１１２文字）
「“”」と“正常条件終了年月日”は文字数稼ぎ。

設問２（２）
要件を整理し，出動目的と属性値の決定に関するデシジョンテーブルを完成させる。
出動目的は，表４ 出動目的一覧の出動目的からそのまま引用する。

埋めやすいものから手を付ける。
ｆ）　緊急呼出し年月日にＸがあるのはこれだけなので，出動目的は「緊急呼出し」
ｇ）　よく分からず，とりあえず保留
ｈ）　修理指示メーカ番号のＸと完全に一致するので，出動目的は「メーカ指示修理」
ｉ）　提案番号のＸと完全に一致するので，出動目的は「提案修理」
ｊ）　前回出動番号のＸと完全に一致するので，出動目的は「継続出動」
残るは「定期点検」のみ。よって，ｇ）は「定期点検」

解答例：設問２（２）
　ｆ）緊急呼出し
　ｇ）定期点検
　ｈ）メーカ指示修理
　ｉ）提案修理
　ｊ）継続出動

設問２（３）
要件実現の検討（未対応指摘，対応方策記述）

要件１：出動目的別の出動回数の把握
　出動→出動内訳←出動目的
　特に問題なく，対応可能。
　（目的別の出動回数合計は，本当の出動回数の合計と一致しない点には注意が必要・・・問題には関係ないが）

要件２：出動目的別部位装置別修理実績の把握
確認すべき項目は
① 出動目的→出動内訳←出動→・？・→駐車場設備修理
② 「修理」と「出動」の業務的な関係

表3「メンテナンス作業における出動指示書と報告書提出の関係」と業務の説明より確認する。
・定期点検：定期点検の結果によって，必要な修理を実施する。
・自発的部品交換：修理報告書はないが交換部品を登録する。
・メーカ指示修理
・緊急呼出し：不具合箇所の特定と修理
・継続出動：定期点検結果による修理及び緊急呼出しによる修理の2日目の作業
・提案修理

疑問１：「修理」＝「修理報告書」なのか，自発的部品交換を含むのか
疑問２：継続出動時のエンティティ「出動内訳」の扱い
　　　　　例）定期点検の場合
　　　　　　１日目）　定期点検　１レコード
　　　　　　２日目）　継続出動　１レコード
　　　　　　　なのか
　　　　　　１日目）　定期点検　１レコード
　　　　　　２日目）　定期点検，継続出動　２レコード
　　　　　　　なのか。。。
　　　　　　　デジョンテーブルに出動目的が「継続出動」のみのものがあるため，前者と思われる。
　　　
出動内訳←出動→・？・→駐車場設備修理
出動に対して，駐車場設備修理は一意に特定できる。
しかし，出動の出動内訳が複数ある場合は，どの出動内訳による修理なのか特定できない。
そもそも「どの出動内訳による修理」なのか特定する必要があるのか？
⇒表６のデジョンテーブルを見ると，修理作業がある出動目的の組合せが混在している。
　と，いうか全ての出動目的で修理作業が発生し得る。
　どの出動内訳なのか特定する必要があると思われる。

　さて，対応する方策だが，「属性の変更，追加だけで対応」という条件が付いているので，その範囲内で考える。
　一番手っ取り早いのは，エンティティ＠駐車場設備修理に属性＠出動目的番号を追加することではないだろうか。（安易過ぎるか？）

解答例①：要件２
対応できない理由
　出動目的が複数ある時に修理作業が発生した場合，どの出動目的による修理作業か特定できないため。（４６文字）
対応するための方策
　部位装置別に出動目的が管理できるよう，エンティティ“駐車場設備修理”に属性“出動目的番号”を追加する。（５０文字＠禁則処理）
　

要件３：１日で完了しなかった修理作業の把握
疑問２：継続出動時のエンティティ「出動内訳」の扱い
が，また。。。
２日目の出動内訳は，「継続出動」だけと想定する。

疑問３：「修理作業」って何？定義は？
メーカ指示修理＋提案修理？　それとも　修理報告書を提出する作業？　それとも　駐車場設備修理を行ったすべての作業？
疑問４：「提案修理」の２日目以降の「出動目的」は何？と，いういか２日目以降はデータ登録しているの？２日以上の場合，修理作業結果はどう登録するのさ？　・・・　分からん事が多すぎる。

　１日で完了しなかった修理作業＝継続出動で修理を行った作業であるが，提案修理の２日目以降の作業は「継続出動」と呼ばない。（「前回出動番号」も持っていない。）
　もうひとつ別の側面から考える。継続作業時に別の出動目的と重なり，別の出動目的で修理を行うとどうだろうか？ここが疑問２のミソなんだよなぁ。。。「継続作業時には継続作業のみを実施する。」とは書いていないし，『緊急呼出し→継続出動＠修理＋ついでに自発的部品交換＠修理』なんてな（どのみち修理には変わりないか。。。）

　１日で完了しなかった（提案修理が何日かかろうが知らないということであれば）修理作業は，継続出動をカウントすれば把握できる？とも思ったが，提案修理は２日目以降の作業を「継続作業」と呼ばない。つまり，２日目は「継続作業」ではないので，これはＮＧ。
　では，駐車場設備修理がない提案修理は１日目で完了しなかった作業か？
　疑問４が立ちはだかる。２日以上かかっても，最初の出動に修理結果を登録すると。。。ＮＧ。

解答例②：要件３
対応できない理由
　提案修理による作業は継続出動として管理されないため，何日で修理が完了したか把握できない。（４４文字）
対応するための方策
　作業日数を把握するため，エンティティ“出動”に属性“作業完了年月日”を追加する。（４０文字）

要件４：修理が発生しなかった緊急呼出し回数の把握
｛出動内訳（緊急呼出し）→出動｝
　－｛出動内訳（緊急呼出し）→出動→・？・→駐車場設備修理｝
　－｛前回出動番号の出動目的が緊急呼出しの出動内訳（継続出動）→出動→・？・→駐車場設備修理｝
差集合演算で求められる。（と，思う）

解答冊子
　webで公開されているものと同じ。

分析資料
　メルマガの初見より掘り下げた内容
午前：時間的難易度がやや高め
g@>そ・そうかな？？

午後I：ページの量に驚く。時間的な面でも技術的な面でも難易度は高め
　難：問３＝問４＞問１＞問２：易
g@>基礎理論は時間的に，ＳＱＬは技術的（というか知っているか／知らないか）に難しかった。

午後II：難易度はやさしめ
　難：（該当なし）＞問１＞問２：易
g@>H16問2＞問１だからねぇ。。

g@>分析資料は，受験後じゃなく，受験前に去年の分析資料を見たかったかも。。
g@>公式解答例が出る前になんとか，自己納得作業(?)を終わらせたいが。。。目前に別の試験が。

設問２（１）
エンティティ「出動」の追加により，
スキーマの属性を「出動指示番号」から「出動番号」に変更するエンティティを列挙する問題。

とりあえず，追加した状態を書く。（リレーションの変更は未実施）

設問の指示どおり，
『出動指示書を発行せずに，修理情報や交換部品情報を登録できるようにする』
と，いうことで「駐車場設備修理」と「交換部品明細」のリレーションを変更する。

解答例：設問２（１）
駐車場設備修理，交換部品明細
で，ＴＡＣとＩＴＥＣの解答例は上のとおりであるが。。。

他の可能性を検討してみる。

さて，修正後の概念データモデルを見ると，点検と修理が随分遠くなった気がする。
点検の結果，修理を行う場合もあるので，もうちょっと近くに置けないかと。。。いうことで，
「駐車場設備点検」と「部位装置点検結果」，「検出異常」のリレーションも変更してみる。

ううーむ。。。これでも悪くない気がするが。。。
もしかして。。。この解答によっては，設問２（３）の解答も影響するんではないかい。。。

もう少し検討してみよう。

設問１（１）
定番のエンティティタイプ名の穴埋め
図６関係スキーマにあって，図５の概念データモデルにないエンティティは
・装置タイプ
・部位装置
・部品
・基本部品
・汎用部品
の五つ。

「メンテナンス用部品には，基本部品と汎用部品がある」 → ａ，ｃ，ｄ
「部位装置汎用部品明細」に矢印がある方（d）が「汎用部品」
ｅは，リレーションから「部品番号」，「駐車場製品番号」を外部キーに持っているので「部位装置」で決まり，
ｄは，「装置タイプ」となる。
解答例：設問１（１）
　ａ）部品
　ｂ）装置タイプ
　ｃ）基本部品
　ｄ）汎用部品
　ｅ）部位装置

設問１（２）
リレーションシップの記述
・駐車場設備
・料金プラン
・契約
・個別サービス
・契約明細
とりあえず，スキーマから追う。

「駐車場設備」に引かれる矢印は充足している。
「料金プラン」に引かれる矢印は充足している。

「契約」に引かれる矢印は足りないようだ。
　・緊急呼出し料金プラン番号
　・修理工賃料金プラン番号
　・修理部品費料金プラン番号
の３つが足りていない。
　参照元は，属性名が「○○料金プラン番号」なので，「料金プラン」の「料金プラン番号」が妥当である。
　これは，それぞれ（緊急呼出し／修理工賃／修理部品費）に対して，インスタンスが排他的に対応しているハズであるが。。。（プラン01は修理部品費には使えない とか）
　これを区分するモノが「料金プラン」に含まれていないのが気がかりではある。。。（ま　いいけど）

「個別サービス」に引かれる矢印は充足している。

「契約明細」に引かれる矢印は属性が書かれていないため判断できない。
とりあえず，契約明細は契約の記述エンティティである（ハズ）なので，
　契約→契約明細
は，間違いない。
あとは，問題文から探る。
『個別部分は，・・・，駐車場設備ごとに提供される個別サービスについて規定している。』
と，いう記述から，契約明細は，駐車場設備の主キーと個別サービスの主キーを外部キーに持つと判断できる。
また，これで，記述対象のエンティティすべてに対して矢印の入/出が書けた。
解答例：設問１（２）
　契約＜－料金プラン
　契約＜－料金プラン
　契約＜－料金プラン （料金プランから契約へ３本矢印を書く）
　契約明細＜－契約
　契約明細＜－駐車場設備
　契約明細＜－個別サービス

設問１（３）
主キーと外部キーの指摘

部位装置点検項目は，図３と図５から，
部位装置汎用部品明細は，図５から 導ける。
解答例：設問１（３）
　部位装置点検項目（駐車場製品番号，部位装置番号，部位装置点検番号，点検項目番号）

　部位装置汎用部品明細（駐車場製品番号，部位装置番号，部品番号，個数）
焦っていると，点検項目番号を主キーに含めてしまうミスをしてしまうかもしれない。

設問２（１）
とりあえず，やってみました。
ユーザ定義関数 GetAge10( )は，作成せずテーブル「会員」に列「年代」を追加しました。
あと，
「 BETWEEN taikan '1200' and '1700' 」がうまく動作しなかったので
「 taikan >= '1200' and taikan <='1700' 」としています。
※初めてMySQLをマトモ(?)に使いました。。。

mysql> select * from kaiin;
+---------+------+------------+------------+--------+--------+
| kaiinno | sex  | birth      | nyukai     | taikai | nendai |
+---------+------+------------+------------+--------+--------+
|   10001 | 男   | 1980-01-10 | 2004-09-07 | NULL   | 20     |
|   10002 | 男   | 1972-02-15 | 2004-10-06 | NULL   | 30     |
|   10003 | 女   | 1972-03-20 | 2004-11-05 | NULL   | 30     |
|   10004 | 男   | 1968-04-25 | 2004-12-04 | NULL   | 30     |
|   10005 | 女   | 1973-05-01 | 2005-01-03 | NULL   | 30     |
|   10006 | 男   | 1969-06-05 | 2005-02-02 | NULL   | 30     |
|   10007 | 女   | 1981-07-01 | 2005-03-01 | NULL   | 20     |
+---------+------+------------+------------+--------+--------+
7 rows in set (0.00 sec)

mysql> select * from riyourireki;
+------------+---------+--------+--------+
| riyou      | kaiinno | nyukan | taikan |
+------------+---------+--------+--------+
| 2005-03-06 |   10003 | 1030   | 1300   |
| 2005-03-07 |   10005 | 1200   | 1430   |
| 2005-03-07 |   10002 | 2000   | 2200   |
| 2005-03-07 |   10007 | 1900   | 2200   |
| 2005-03-08 |   10005 | 1200   | 1430   |
| 2005-03-08 |   10004 | 1700   | 1900   |
| 2005-03-09 |   10005 | 1200   | 1430   |
| 2005-03-09 |   10007 | 1900   | 2200   |
+------------+---------+--------+--------+
8 rows in set (0.00 sec)

mysql> select nendai,sex,count(a.kaiinno) as a1, coalesce(sum(b1),0) as a2,
    -> coalesce(sum(b2),0) as a3, coalesce(sum(b3),0) as a4
    -> from(select nendai,sex,kaiinno from kaiin
    -> where (taikai is null or taikai > '2005-03-31')
    -> and nyukai <= '2005-03-31') as a left outer join
    -> ( select kaiinno,
    -> sum(case when nyukan < '1200' then 1 else 0 end ) as b1,
    -> sum(case when taikan >= '1200' and taikan <='1700' then 1 else 0 end) as b2,
    -> sum(case when taikan > '1700' then 1 else 0 end) as b3
    -> from riyourireki where riyou between '2005-03-01' and '2005-03-31'
    -> group by kaiinno) as b
    -> on a.kaiinno = b.kaiinno
    -> group by nendai,sex
    -> order by nendai,sex;

+--------+------+----+------+------+------+
| nendai | sex  | a1 | a2   | a3   | a4   |
+--------+------+----+------+------+------+
| 20     | 男   |  1 |    0 |    0 |    0 |
| 20     | 女   |  1 |    0 |    0 |    2 |
| 30     | 男   |  3 |    0 |    0 |    2 |
| 30     | 女   |  2 |    1 |    4 |    0 |
+--------+------+----+------+------+------+
4 rows in set (0.00 sec)

設問２（２）

COALESCE関数についてはこちらの記事を参照：SQL: COALESCE関数
解答例：設問２（２）
使用目的：年代，性別によっては利用履歴が存在せず，時間帯別利用者数の集計値がＮＵＬＬとなる所を０と出力するため。（５１文字）

意図した状況が発生する年代と性別。
利用履歴が存在せずA2,A3,A4のすべてがNULLとなり，0に置き換えられるのは２０代男性である。
解答例：設問２（２）
年代：20
性別：男