2005年01月29日

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

H11午後I 問1

H11午後I 問1(ITEC 2005予想問題集 午後I 問3-4)
設問2(3)
 “試験成績”テーブルの構造を第2正規形にし,主キーとなる列に下線を引け。

 ※ここでは,表現の都合,テーブル構造ではなく,スキーマで表現する。

 試験成績(校番号,児童番号,学力試験番号,教科,得点,校内順位,塾内順位,塾内平均点,塾内標準偏差,塾内偏差値)

 を,第2正規形に分割

 児童試験成績(児童番号学力試験番号教科,得点,校内順位,塾内順位,塾内偏差値)
 塾試験統計(学力試験番号教科,塾内平均点,塾内標準偏差)

ここで,
 児童(校番号,児童番号
を,あえて記載するかどうか悩ましい。児童テーブルは既に存在しているからだ。
ITEC,アイタック,どちらの解答例も,児童を記載している。
やはり,書くべきなのだろうか・・・


ちなみに,こいつの収め先を・・・

児童試験成績に校番号を含めると,
 児童番号→校番号の関係があるので,部分関数従属性が存在することになり,設問の第2正規形の条件を満たさない。

塾試験統計に校番号を含めると,
 候補キーは,{学力試験番号,教科,校番号}となるが,{学力試験番号,教科}→{塾内平均点,塾内標準偏差}であるため部分関数従属となり,第2正規形の条件を満たさない。


以下追記(05/01/29)
 {校番号,児童番号,学力試験番号,教科}→校内順位
 {児童番号,学力試験番号,教科}→{得点,塾内順位,塾内偏差値}
と,校内順位を分割できる。

 {校番号,児童番号,学力試験番号,教科}→{得点,校内順位,塾内順位,塾内偏差値}
という見解もある。(この場合は校番号は非キー属性ではなく,候補キーの一部である)

 設問は「第2正規形の条件を満たせ」ということなんで,第2正規形の条件を満たす第3でもボイスコッドでも第4でも第5でも良い。つまりは,解答例はひとつではないということなのかな?

Posted by g@kko at 2005/01/29 18:32 | 個別記事表示 | コメントを見る (4) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/セキュリティと標準化, 誤答管理 ]

示現塾 2005年01月29日(土) 本格版 265号 第5問

示現塾 2005年01月29日(土) 本格版 265号

第5問 セキュリティと標準化(AU向け)
分野-6-1-2/技術レベル-III/出題頻度-中/出典:SS14-27

 リスク分析手法 JRAM(JIPDEC Risk Analysis Method)において,JRAM 質問表を
使用する分析はどれか。

ア 事故原因分析           
イ ぜい弱性分析
ウ 損失分析             
エ 費用対効果分析

Posted by g@kko at 2005/01/29 10:36 | 個別記事表示 | コメントを見る (0) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H15午前, データベース技術 ]

H15AM30: 示現塾 2005年01月29日(土) 本格版 265号 第4問

示現塾 2005年01月29日(土) 本格版 265号

第4問 データベース技術(DB向け)
分野-5-1-2/技術レベル-III/出題頻度-中/出典:DB15-30

本問は、図表を含みますので、下記をクリックしてください。
 http://zigen.cosmoconsulting.co.jp/mailmag/pic/2005-01-29-4.htm

 複数の事業部,部,課及び係のような組織階層の概念データモデルを,第3正規形の表,

   組織(組織ID, 組織名, …)
として実装した。組織の親子関係を表示するSQL文として, □ の中に入れるべき条件はどれか。ここで,“組織”表記述中の下線部は,主キーを表し,追加の属性を想定する必要がある。概念モデル中の多重度の“*”は0以上を表し,記述のないところは1とする。関連線にはターゲット側にロールを書き添えた。{階層}は組織階層がループしたり,ネットワークになったりしないことを指示する制約記述である。

ア 組織1.親組織ID = 組織2.子組織ID
イ 組織1.親組織ID = 組織2.組織ID
ウ 組織1.組織ID = 組織2.親組織ID
エ 組織1.組織ID = 組織2.組織ID

Posted by g@kko at 2005/01/29 10:25 | 個別記事表示 | コメントを見る (0) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/システムの開発と運用 ]

示現塾 2005年01月29日(土) 本格版 265号 第2問

示現塾 2005年01月29日(土) 本格版 265号

第2問 システムの開発と運用(SW,DB,SM,AU,ES向け)
分野-3-1-7/技術レベル-II/出題頻度-高/出典:SD15-12

 ERP パッケージを導入するときに,製品トレーニングが終了した時点から実稼働までに行う作業の手順として,適切なものはどれか。

a カスタマイズ
b 業務概要の把握
c プロトタイピング
d 要件定義

ア b → c → d → a         
イ b → d → c → a
ウ c → b → d → a         
エ c → d → b → a

Posted by g@kko at 2005/01/29 10:23 | 個別記事表示 | コメントを見る (0) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/コンピュータシステム, 誤答管理 ]

示現塾 2005年01月29日(土) 本格版 265号 第1問

示現塾 2005年01月29日(土) 本格版 265号

第1問 コンピュータシステム(SW,DB,SM,AU,ES向け)
分野-2-3-2/技術レベル-II/出題頻度-中/出典:CM15-05

本問は、図表を含みますので、下記をクリックしてください。
 http://zigen.cosmoconsulting.co.jp/mailmag/pic/2005-01-29-1.htm

 表に示す仕様の磁気ディスク装置において,500バイトのデータの読取りに要する平均時間は何ミリ秒か。

ア 12.15      
イ 16.05       
ウ 18.05      
エ 24.05 

Posted by g@kko at 2005/01/29 10:17 | 個別記事表示 | コメントを見る (0) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H10以前 ]

H10午後I 問5

H10午後I 問5 3週間本(2003)P443~

設問1(1)
 候補キー(若しくは主キー)の一部であるタイトル番号に対して非キー属性のタイトル名,貸出開始日付,旧作指定日付,ジャンル,新旧区分が関数従属すること(部分関数従属性が存在すること)を文字数内で表現できていれば良いかと。
 候補キー(若しくは主キー)に全ての非キー属性が完全関数従属しない。という表現でも問題ない。

※ここでは,テーブルの主キーが問題内に明示してあるので,候補キー(若しくは主キー)の列{店番号,タイトル番号}を明記する必要はないと思われる。むしろ非キー属性の方を示すべきではないだろうか。


設問1(2)
 店保有タイトル(店番号タイトル番号,初期本数,現本数)
 タイトル(タイトル番号,タイトル名,貸出開始日付,旧作指定日付,ジャンル,新旧区分)
 ※表現の都合,関係スキーマで表したがテーブル構造で示すこと。


設問2(1)
 返却時の処理を考える。問題文での返却処理はふたつ
 ・『返却時は,返却されたビデオテープのバーコードを読み取り,返却年月日を記録する。』
 ・『返却予定年月日を過ぎて返却されたときは,遅延料金を徴収する。』
 どちらかに問題がある。と,いうことだ。

 記事の都合,後者から考える(w
 『遅延料金は,遅延日数に1日当たりの遅延料金(新作と旧作で異なる)を乗じた額である。』
 から,脊髄反射的に思いつくのは,
 『貸出(遅延)期間中に新旧区分が変わった場合どうなるのか。』
 と,いうことである。
 問題文中では,この処理は明記されていないが,新作で精算しようが,按分しようが,「貸出年月日」と「返却年月日」及び「旧作指定日付」で解決できそうだ。

 前者の場合,
 バーコードで貸出返却の返却年月日を記録する。ということだが,
 バーコードの情報(タイトル番号,タイトル内通番)(図1より)では,貸出返却の行が一意に特定できない。これがC氏が指摘した問題である。
 ここらへんの内容をうまく文字数内で表現できれば問題ないと思う。

 余談だが,会員カードがあれば一意に特定できるのか?ということだが,貸出期間中に同一会員に同一タイトルを複数本貸出をしていなければ可能である。


設問2(2)
 タイトル内通番
 ※問題文中の用語を使うこと。
 貸出年月日~返却年月日の間に1本のビデオ{タイトル番号,タイトル内通番}は1人の会員{店番号,会員番号}にしか貸し出すことはできない。(物理的に)
 また,{タイトル番号,タイトル内通番}毎に貸出回数がカウントできるため,③の問題点にも対応できる。


設問3
 タイトル貸出推移(タイトル番号年月日,貸出残本数) もしくは
 タイトル貸出推移(タイトル番号年月日,全本数,貸出残本数)
 ※表現の都合,関係スキーマで表したがテーブル構造で示すこと。

 図3,図5からボトムアップしてみると
 タイトル情報(タイトル番号,初期本数,貸出開始)
 タイトル貸出状況推移(タイトル番号,年月日,貸出残本数,全本数,貸出済本数)

 タイトル情報の「初期本数」は全店の「タイトル.初期本数」の合計であり,時間経過で変更される情報でないため,わざわざテーブルを追加する必要はないと思われる。

 タイトル貸出状況推移の方は,
 貸出残本数 = 全本数 - 貸出済本数
 で,求められるため,冗長のように見える。

 ここで考慮すべき点は,時系列性の保持である。
 『新作の期間は,各店のビデオテープの保有本数を変更しない』
 『図3 新作ビデオタイトル貸出状況推移の表示例』
 から,新作だけを対象としていて,新作期間は「全本数」=全店の「タイトル.初期本数」の合計であることが伺える。
 このことから,「全本数」は保持しなくて良いと判断もできる。

 が,実際は事故は付き物で,会員による紛失(トンズラ)などによる全本数の減も考慮すべきではないか。 と思う。(A社内でコントロールできない問題,つまりは不可抗力で各店のビデオテープの保有本数に変更が発生する場合を考えなければならない。)
 と,いうことで別解として良いと判断した。

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