<< March 2024 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 >>

テクニカルエンジニア(データベース) H19 PM2-2

テクニカルエンジニア(データベース)午後2問2を解いてみた。
所要時間 2時間

設問(1)
[自社組織及び得意先関連のマスタ領域]

  • 得意先−●−○→シリーズ値引率

[商品関連のマスタ領域]

  • シリーズ−●−●→商品
  • シリーズ−●−○→キャンペーン値引率
  • セット商品−●−●→セット商品構成
  • セット商品構成−●−○→入替商品
  • 単品商品−●−○→セット構成商品
  • 単品商品−●−○→入替商品

[案件及び見積関連のトランザクション領域]

  • 案件−●−○→見積
  • 見積明細−△−見積商品明細見積施工明細 (見積商品明細・見積施工明細は見積明細のサブタイプ。以下、同様に表記する)
  • 見積商品明細−△−見積セット商品明細見積単品商品明細見積入替商品明細
  • 見積セット商品明細−●−●→見積セット商品基本構成明細
  • 見積セット商品基本構成明細−●−●−見積入替商品明細

[出荷関連及び施工指示関連のトランザクション領域]

  • 出荷指示−●−●→出荷指示明細
  • 施工指示


設問(2)

  • 営業所課(支店コード, 所課コード, 営業所課名称)
  • 得意先(得意先コード, 名称, 住所, TEL, 基本値引率, 取引開始年月日, 取引中止年月日, 更新年月日)
  • シリーズ値引率(得意先コード, シリーズコード, 値引率)
  • シリーズ(シリーズコード)
  • キャンペーン値引率(シリーズコード, キャンペーン番号, 期間, 値引率)
  • セット構成商品(商品コード, セット構成商品番号, 単品商品コード, 数量, 入替可能マーク)
  • 入替商品(商品コード, セット構成商品番号, 入替商品番号, 入替商品コード, 単価差額)
  • 案件(案件番号, 案件名称, 案件住所, 案件納期, 状態, 見積番号, 得意先コード, 見積金額, 社員番号)
  • 見積商品明細(案件番号, 見積番号, 明細番号, 適用値引率, 見積商品明細区分)
  • 見積施工明細(案件番号, 見積番号, 明細番号, 金額)
  • 見積セット商品明細(案件番号, 見積番号, 明細番号, 商品コード, 見積数量)
  • 見積入替商品明細(案件番号, 見積番号, 明細番号, 見積数量, 単価差額, 入替対象明細番号, 入替対象構成番号)
  • 見積セット商品基本構成明細(案件番号, 見積番号, 明細番号, 構成番号, 商品コード, 数量, 入替可能マーク)
  • 出荷指示(出荷指示番号, 案件番号, 出荷指示年月日, 出荷状態区分, 出荷予定年月日, 出荷年月日, 納入予定年月日, 納入年月日, 社員番号)
  • 出荷指示明細(出荷指示番号, 明細番号, 構成番号)
  • 施工指示(施工指示番号, 案件番号, 施工指示年月日, 施工指示状態区分, 施工納期年月日, 施工完了年月日, 社員番号, サービス会社所属コード)


設問(3)
関連元
エンティティ
タイプ名



0




0

関連先
エンティティ
タイプ名







0

関連先0条件
得意先シリーズ値引率n得意先にシリーズ値引率が設定されていない場合
得意先案件n 
営業担当者案件n営業担当者が1件も案件を担当していない場合
シリーズシリーズ値引率nシリーズにシリーズ値引率が設定されていない場合
シリーズ商品n 
セット商品セット構成商品n 
単品商品セット構成商品n単品商品がどのセットにも含まれていない場合
セット構成商品入替商品nセット構成商品に入替可能である商品がない場合
単品商品入替商品n単品商品が入替商品となることがない場合
案件見積n案件を入手してまだ見積を行っていない場合
見積セット商品明細見積セット商品基本構成明細n 
出荷指示出荷指示明細n 
営業担当者見積n営業担当者が1件も見積を行っていない場合
単品商品見積単品商品明細n商品が1件も見積されていない場合
セット商品見積セット商品明細n商品が1件も見積されていない場合
見積セット商品基本構成明細見積入替商品明細1明細中に入替がない場合
営業担当者出荷指示n担当者が1件も出荷指示をしていない場合
営業担当者施工指示n担当者が1件も施工指示をしていない場合
サービス会社営業所施工指示n営業所が1件も施工指示を受けていない場合


【感想】分量が多い。〔マスタ情報のメンテナンスとトランザクションとの関係〕を吟味している時間がなかった。完璧な解答を求めるのは無理として、「見積セット商品明細」と「見積単品商品明細」のサブタイプで、どちらにも「商品コード」が存在するが、参照先が異なるということが分かれば、とりあえず及第点と言えるだろうか。
ss2004 * テクニカルエンジニア(データベース) * 20:24 * comments(0) * trackbacks(0)

テクニカルエンジニア(データベース) H19 PM2-1

テクニカルエンジニア(データベース)午後2問1を解いてみた。
所要時間 2時間

設問1
(1)

  • プロジェクト担当部(プロジェクト番号, 担当部コード, PL社員番号, 割当見積工数, 割当契約金額)
  • プロジェクト別人件費予算(プロジェクト番号, 年度, 年月, 職務ランクコード, 要員数)
  • 職務ランク別人件費(職務ランクコード, 年度, 予算単価)
  • 人件費以外コスト予算(プロジェクト番号, 部コード, 年度, 年月, 費目コード, 予算金額)
  • 売上予算(プロジェクト番号, 部コード, 年度, 売上予算金額)


(2) 社員の職務ランクの変更後に、変更前の稼働実績が訂正された場合
(テーブル) 月別勤務実績
(列) 適用職務ランクコード

設問2
(1)
 稼働実績訂正入力月間稼働実績承認月間勤務実績承認
社員RRR
所属R R
プロジェクトRR 
月別勤務実績 URU
日別勤務実績  R
稼働実績明細RURU 

(2)
a 勤務実績/稼働実績入力機能を分割せず、稼働実績訂正入力機能と統合する方がよい。
b プロジェクト登録が間に合わなかった時を除き、勤務実績と稼働実績の合計が合致することをチェックすることができ、入力者の負担軽減となる。また、訂正入力時もインタフェースが統一された方が入力が容易である。

設問3
(1) 勤務実績エントリはレコード数が少ないことから入力時のレスポンスが改善される。また、勤務実績履歴の嗅覚文頭にインデックスを追加しても影響が出ない。
(2)
【月別勤務状況推移表出力について】
(対策) (c)
(対策内容) テーブル「部別月別勤務状況」を追加し、列「総超過勤務時間」「総深夜勤務時間」「総休日勤務時間」「総休日出勤日数」「所属社員数」を格納する。
(理由) 集計時に、社員別・日別に導出項目を計算する必要がなくなり、テーブル「所属」との結合も不要となるため。
(影響) なし
(処理の内容) 月締め処理の際に集計を行い、部別月別勤務状況にレコードを追加する。
【プロジェクト予算/実績管理表出力について】
(対策) (a)
(対策内容) テーブル「稼働実績明細」に、列「勤務ランクレコード」を追加する。
(理由) 月別の人件費の実績工数の集計に当たり、「稼働実績明細」と他のテーブルとの結合が不要になる。
(影響) なし
(処理の内容) なし

【感想】午後1の傾向も併せると、「出題分野の広い範囲を勉強して欲しい」と出題者が考えているのではないかと感じる。データベーススペシャリスト時代の出題に近いような気がする。
ss2004 * テクニカルエンジニア(データベース) * 14:16 * comments(15) * trackbacks(0)

テクニカルエンジニア(データベース) H19 PM1-1 設問3

「モデルで分割する方が適切」という解で自分としては納得しているが、一応整理してみたい。

  1. 関係「査定車」の候補キーは、{車台番号, 査定日}である。
  2. 関係「査定車」は、候補キー{車台番号, 査定日}の一部である「車台番号」に非キー属性{モデル, 年式}が関数従属するという部分関数従属があるため、第1正規形である。
  3. また、関係「査定車」中には、車台番号 → モデル → {車名, 製造元, 新車価格, 排気量}という推移的関数従属も存在する。
  4. 前者の部分関数従属に由来する更新異状としては、

    • (事前)主キーの非ナル制約により、査定日が決まるまでは、車台情報(モデル、年式)を登録することができない。
    • (重複1)査定日ごとに(査定を行うごとに)、車台情報(モデル、年式)を登録する必要があり、冗長である。
    • (重複2)車台情報(モデル、年式)に変更が生じた場合、複数のレコードを修正する必要があり、修正漏れが生じるおそれがある。
    • (喪失)査定車のレコードを削除した場合に、車台情報が失われることがある。
    が考えられるが、業務ルール等から(事前)と(重複2)の問題は生じない(査定後、商談が終わってからデータベースに登録する業務ルールのため。車台情報は変更が生じないため)。
  5. また、(喪失)は、問題で問われていない。
  6. (重複1)の問題は、同一車台が複数回査定に出された場合に生じ得る。ただし、頻度は低い。
  7. 後者の推移的関数従属に由来する更新異状としては、

    • (事前)主キーの非ナル制約により、{車台番号, 査定日}が決まるまで(査定・商談成立の時まで)は、モデル情報(車名、製造元、新車価格、排気量)を登録することができない。
    • (重複1)査定・商談成立ごとに、モデル情報モデル情報(車名、製造元、新車価格、排気量)を登録する必要があり、冗長である。
    • (重複2)モデル情報モデル情報(車名、製造元、新車価格、排気量)に変更が生じた場合、複数のレコードを修正する必要があり、修正漏れが生じるおそれがある。
    • (喪失)査定車のレコードを削除した場合に、モデル情報が失われることがある。
    が考えられるが、業務ルール等から(事前)と(重複2)の問題は生じない(査定後、商談が終わってからデータベースに登録する業務ルールのため。モデル情報は変更が生じないため)。
  8. また、(喪失)は、問題で問われていない。
  9. (重複1)の問題は同一モデルに属する車台の数にもよるが、かなり頻繁に生じる。人気モデルなら台数も多いだろう。
  10. 本来なら、3つに分割して第3正規形とすべきだが、設問では2つに分割するとあるため、上記の部分関数従属、推移的関数従属のうち、どちらかしか解決できない。
  11. 部分関数従属に由来する更新異状は、同一車台が再び査定に出されたとき(成立した商談がいったん解消したか、別人が買って再度査定に出されたとき)しか生じないレアケースであるため、推移関数従属に由来する更新異状を解消すべきである。
  12. したがって、モデルで分割し、

    • 査定車(車台番号, 査定日, モデル, 年式, 販売店番号, 走行距離, 主要装備, 車検, 登録番号, 車体色)
    • モデル(モデル, 車名, 製造元, 新車価格, 排気量)
    とすべきである。
ss2004 * テクニカルエンジニア(データベース) * 22:03 * comments(3) * trackbacks(0)

テクニカルエンジニア(データベース) H19 PM1-1 設問1(1)訂正

前に解いてみたが、改めて問題を見てみたら、問1の関数従属図が全然違っていたので修正する。
販売開始日,販売終了日は1査定(1買取り)に対し複数存在するという要件を見落としていた。お恥ずかしい。

修正済みの関数従属図

関数従属性で示すと、

  • {車台番号, 査定日} → {{走行距離, 主要装備, 車検, 登録番号, 車体色}, 販売店番号}
  • 車台番号 → {年式, モデル}
  • モデル → {車名, 製造元, 新車価格, 排気量}
  • {車台番号, 販売開始日} → {{販売種別, 車両本体価格}, 査定日, 販売終了日}
  • {車台番号, 販売終了日} → {査定日, 販売開始日}

(注) {車台番号, 販売終了日} → {販売種別, 車両本体価格} は冗長なため、図示しない。
ss2004 * テクニカルエンジニア(データベース) * 21:21 * comments(10) * trackbacks(0)

テクニカルエンジニア(データベース) H19 PM1-4 解いてみた

テクニカルエンジニア(データベース)午後1問4を解いてみた。
所要時間 20分。

設問1
(列名) {メーカ番号, 型番} (目的) メーカごとの一意性の保証
(列名) JANコード (目的) 全商品を通じての一意性の保証

設問2
(述語) 商品大分類コード='DT'
(理由) 商品中分類コードが決まれば、商品大分類コードは一意に定まるから。

設問3
(1) COUNT(DISTINCT 仕入担当者番号)
(2)
a 2,000
b 10,000
c 1,000
d 500
(3) 10,000行
(4)
e 400
f 10,000
g 1,000
h 10,000

設問4
(実行時間が短いSELECT文) A
(理由) 索引キーの値だけで結果行を得られるから。

【感想】
非常に簡単だし、時間もかからない。
今回、午後1では問4は選ばないという「完全教本」型試験対策は完全に裏目に出たと思う。
ss2004 * テクニカルエンジニア(データベース) * 22:57 * comments(2) * trackbacks(0)

テクニカルエンジニア(データベース) H19 PM1-3 解いてみた

テクニカルエンジニア(データベース)午後1問3を解いてみた。
所要時間 15分。

設問1
(1) アクセスユーザのレコードを選択するビューを作成し、アクセス権限を与える。
(2) 各ユーザごとにビューを作成せずに、ビューを共通化できる。

設問2
(1)
a CREATE ROLE
b TO 営業1課長ロール
c TO B111
d TO B110
(2) "REVOKE 営業部長ロール FROM B110"と"GRANT 営業部長ロール TO B130"を実行する。

設問3
(ア) 否 従業員基本データは全従業員が参照できるため、監査証跡から特定できない。
(イ) 可 従業員人事データの更新は特定者しかできないため、監査証跡と照合して特定できる。
(ウ) 可 給与テーブルのUPDATEに失敗したユーザIDを検索すればよい。

【感想】
テクニカルエンジニア(情報セキュリティ)で、まさにこの手の問題が出るのではないかと想像していた。DBでこれがでるとなると、SVの立場がさらに不明確になる。
ss2004 * テクニカルエンジニア(データベース) * 18:22 * comments(5) * trackbacks(0)

テクニカルエンジニア(データベース) H19 PM1-2 解いてみた

テクニカルエンジニア(データベース)午後1問2を解いてみた。
所要時間 25分。

設問1
(1) 配達地域(郵便番号, 配達地域)
(2) 店舗販売・ネット販売識別子

設問2
列名取り得る値の意味値が設定される条件
商品区分1一般商品、引取サービスすべての商品
商品区分2ネット販売あり、ネット販売なし商品区分1が一般商品の場合


設問3
(1)

  • 顧客−●−○−会員
  • 親会員−●−○→子会員
  • 会員−△−親会員子会員

(2)
b ×
c 同一顧客が、別の会員番号で親会員の登録をすることができるから。
d ○
e 親会員番号を設定する列は一つしかなく、自ずから親会員は一つとなる。
f ○
g 自らを親会員として登録することで、階層が2階層を超えたり循環することはない。
h ○
i 親会員として登録する会員の親会員番号が当該親会員の会員番号であること。
(3)

  • ポイント統合の開始
  • その会員や子会員への商品の販売


【感想】
表3の穴埋めがピンとこない。
ss2004 * テクニカルエンジニア(データベース) * 22:25 * comments(2) * trackbacks(0)

テクニカルエンジニア(データベース) H19 PM1-1 解いてみた

テクニカルエンジニア(データベース) 午後1問1を解いてみた。
所要時間 40分。

設問1
(1) 関数従属図
2007年4月21日11:00 修正。関数従属が既約でなかったので、冗長な関数従属を削除。
・{車台番号, 査定日} → {販売開始日, 販売終了日}
・{車台番号, 販売開始日} → {販売終了日, 査定日}
・{車台番号, 販売終了日} → {査定日, 販売開始日}
の関数従属は維持。
(2)
(誤っている関数従属性) 〔2〕
(理由) 担当者は、別の販売店の担当を兼務することがあるから。

設問2
(1) {車台番号, 販売開始日}
(2) 第3正規形

  • 関係「販売車」には、繰り返し属性がなく、全属性がスカラ属性である。
  • 関係「販売車」には、候補キーから非キー属性への部分関数従属がない。
  • 関係「販売車」には、候補キーから非キー属性への推移関数従属がない。

設問3
(1) 査定を行うごとに、年式、モデル等の情報を重複して登録する必要があり、冗長である。
(2)

  • 査定車(車台番号, 査定日, 販売店番号, 走行距離, 主要装備, 登録番号, 車検, 車体色)
  • 車台(車台番号, モデル, 年式, 車名, 新車価格, 製造元, 排気量)

設問4
(1) {車台番号, 販売日}, {車台番号, 査定日}, {車台番号, 買取日}
(2)
a 分割されている
b タプルが現れる
c {車台番号, 販売日} → {買取日, 査定日}
(3) 買取日, 査定日

【感想】
めちゃくちゃ難しいとは思わないが、時間はかかる。
設問1は、図3から取り組むのでなく、図1の「査定車」「販売車」を見て取り組む方が攻略しやすいと思われる。
ss2004 * テクニカルエンジニア(データベース) * 19:53 * comments(11) * trackbacks(0)

部分関数従属と正規形

某巨大掲示板の書き込みから
=======================================================
914 Name: 名無し検定1級さん [] Date: 2007/03/13(火) 23:49:21 ID: Be:
質問です。
アイテック模試 問1 設問1(3)のセット料理の部分関数従属の例を挙げる問題ですが。

解答は、「なし」となっています。
しかし、

{料理番号、構成料理番号}は候補キーで、
{構成料理名、構成料理単価}は、{料理番号、構成料理番号}の一部である構成料理番号に
関数従属するので、部分関数従属が存在することになると思うのですが。

勘違いでしたらごめんなさい。

916 Name: 914 [] Date: 2007/03/14(水) 00:18:59 ID: Be:
>>915
やっぱりおかしいよね。上と重複しますがもう少し詳しく、
関係スキーマと関数従属関係だけを示すと、

セット料理(セット料理番号、通番、構成料理番号、構成料理名、構成料理単価)

{セット料理番号、通番}→構成料理番号→{構成料理名、構成料理単価}という関数従属図があり
また、問題文から、{セット料理番号、構成料理番号}も候補キーであることが分かる。

です。何故だろう???
=======================================================
問題文を見ていないの何とも言えないが、914氏の書き込みが正しいとすると、
構成料理番号→{構成料理名, 構成料理単価}
という部分関数従属が存在する。

ちなみに、そもそも、部分関数従属の定義には候補キーは関係ないので、問題文中に「候補キーからの部分関数従属」という限定がなければ候補キーが関連しない部分関数従属を答えても良いはずであるが、それだとほとんど意味がない。(たとえば、上の例で言えば、{セット料理番号, 通番}→構成料理番号も部分関数従属である。)
したがって、試験では、候補キーからの部分関数従属を答えるべきである。
JITECの試験では、その辺も考えたようで、H18の午後1問1では、「候補キーからの部分関数従属」と記述している。
ss2004 * テクニカルエンジニア(データベース) * 21:39 * comments(10) * trackbacks(0)

データベース実践講義

データベース実践講義―エンジニアのためのリレーショナル理論
本屋で見かけた。C.J.Dateの本にしてはお手頃な価格である。
ss2004 * テクニカルエンジニア(データベース) * 20:06 * comments(0) * trackbacks(0)
このページの先頭へ