2005年01月16日

[ テクニカルエンジニア(データベース)/試験対策本 ]

データベース設計/モデリング本

某掲示板で
グラス片手にデータベース設計~販売管理システム編が話題になっている。

amazonで「データベース設計」で検索した場合,売れている順番で1位に表示される本だ。
レビューでもなかなかの評判。
今度立ち読みしてみるか・・・

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

amazon@ウィッシュリストの盲点

驚いた。
プロフィールで
「名前を誰にも公開しません。ただし、ニックネームを公開し、Amazon.co.jp のIDとして使用します。」
に設定しているにもかかわらず,ウィッシュリストで名前が公開されているではないか!!

1.レビューやリストマニアから,プロフィールを見る。
2.プロフィールからウィッシュリストを見る。
3.ウィッシュリストに名前が表示される。

なんてこった。プロフィールの設定の意味がないじゃん!!!
ウィッシュリストは,ブラウザの「お気に入り」と同じ感覚で使ってたんだが・・・

名前を表示しないためには,
 ウィッシュリストを全て削除する。(ウィッシュリストを使わない)

もしくは,
 2の対策.ウィッシュリストを公開しない。
 3の対策.ウィッシュリストの「作成者の情報」にはデフォルトで届け先の「名前」が入っているので,ニックネームに修正する。

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

H11午後II 問1

H11午後II 問1(ITEC 2005予想問題集 午後II 問5)

赤字:アイタックをソースに修正

設問1(1)
解答例には,部品から出庫明細へのリレーションシップの記載がない。
入庫明細への記載はあるのに。
しかも,入庫明細への根拠は「{部品品目番号,部品枝番}を持つから」
・・・出庫明細にもあるんですけど・・・・
 他の出版社じゃ,H11の問題は載ってないだろうな。。。
 Webで探すか・・・

部品→出庫明細は必要
アイテックは,発送-出庫だが,アイタックは発送→出庫,
発送効率の記述から後者が正解と思われる。
と,いうことは発送伝票には“複数”の出庫番号が記入されることとなる。

設問2(2)②
 物流事象はすべての拠点の組み合せで発生するわけではなく,物流事象によって送り元の拠点と送り先の拠点の組み合せが限定されている。

解答例は
物流パターン(物流事象コード,送付元拠点コード,送付先拠点コード,物流可否)

となっているが,

表4の説明は拠点種類名毎の説明となっているんで
組み合せは拠点種類毎で十分と判断し,
物流パターン(物流事象コード,送付元拠点種類コード,送付先拠点種類コード,物流可否)

でもいいのかな。とも思ったんだが・・・ううむ。
アイタックの解答例は拠点種類毎(後者)ですね。


設問2(2)③
 出庫に外部キーとして,物流パターンの主キーで不足する属性(物流拠点コード,送付元(出庫元)拠点コード)を追加する。という解説になってるんだけど。。。
 出庫には既に出庫元拠点コードがあるんだけどな・・・
 入庫・出庫に物流事象コードを追加するだけでOKみたい


設問3(1)
 部品構成は「生産管理システム」への外部参照でいいんでは・・・1事実1箇所にしないと,更新漏れや矛盾が生じるよねぇ。
 でも,これ以外に何を追加するのか・・・思いつかん(苦
 アイタックも部品構成ですね。やっぱこれでいいんか


設問3(2)
 棚卸し中は出庫・入庫を停止するとは書いていないんで,入出庫も考慮すべきではないのかなと。(一般に停止するんだろうけど)
 そうすると,出庫は1日何回も行われるし,棚卸し日にトラックが到着し,輸送中在庫が入庫されることもあうだろう。
 実在庫を確認した後(同一日)に,入出庫があれば数字が合わなくなるはずだ。
 時点在庫や入庫,出庫の属性も見直す必要が出てくる。

 こんなことを考えると,在庫の自動補正処理も複雑になり,解答欄(文字数)が足りなくなるし,設問の趣旨「どんな処理内容か,必要となるエンティティタイプは何か」の範囲を超えてしまうような気もする。

 解答例のような都合の良い解釈でいいのかな・・・
 アイタックの趣旨もアイテックと同じ。
 アイテックは,在庫数に差異のあるものについて,差分を反映
 アイタックは,棚卸し(実)在庫数で“時点在庫”と全件更新

 設問3(2)については,vol.2を参照ください。

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

H16AM42: 示現塾 2005年01月16日(日) 本格版 252号 第4問

示現塾 2005年01月16日(日) 本格版 252号

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

 ハッシュインデックスの特徴に関する記述として,適切なものはどれか。

ア B木インデックスと比較して,不等号の条件検索が困難である。
イ B木インデックスと比較して,ワイルドカード式の検索が容易である。
ウ インデックスノードが木構造になっており,複数のノードを経由してレコードヘアクセスする。
エ レコードの追加や削除が多くなっても,インデックスの再構成の必要がない。

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

示現塾 2005年01月16日(日) 本格版 252号 第5問

示現塾 2005年01月16日(日) 本格版 252号

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

 クレジットカード決済のセキュリティ手順を定めたものはどれか。

ア CA(Certificate Authority)
イ KPS(Key Predistribution System)
ウ SET(Secure Electronic Transaction)
エ SHS(Secure Hash Standard)

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

示現塾 2005年01月16日(日) 本格版 252号 第2問

示現塾 2005年01月16日(日) 本格版 252号

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

 ソフトウェア開発におけるデザインレビューのポイントとして,最も適切なものはどれか。


ア 過去の不良事例を活用するには,その発生原因よりも技術的観点でまとめた方が活用しやすい。

イ 工程線表上に実施時期を明記しないで,設計者が必要な都度実施するのが望ましい。

ウ 使用されるドキュメントは,本来デザインレビュー用に用意するのではなく,設計作業時に作られるべきものである。

エ ドキュメントに記述された内容をレビューするのであって,記述されていない事柄を指摘するのは好ましくない。

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

示現塾 2005年01月16日(日) 本格版 252号 第1問

示現塾 2005年01月16日(日) 本格版 252号

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

 3 層クライアントサーバシステムの説明のうち,適切なものはどれか。

ア システムを機能的に,Web サーバ,ファイアウォール,クライアントの 3階層に分けたシステムである。

イ システムを機能的に,アプリケーション,通信,データベースの 3 階層に分けたシステムである。

ウ システムを物理的に,メインフレーム,サーバ,クライアントの 3 階層に分けたシステムである。

エ システムを論理的に,プレゼンテーション,ファンクション,データベースの 3 階層に分けたシステムである。

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