実践的データモデリング入門/真野正
実践的データモデリング入門 (DB magazine selection)第１章 なぜモデリングを行うのか □ ひとつの事実を表すもの（エンティティと属性の両方）は１箇所で管理せよ。 □ トップダウンアプローチ、ボトムアップアプローチは、どちらかが一方を採用すると言うのではなく、最初にトップダウンでエンティティを切り出して、そこにボトムアップ分析で抽出した結果を付加していくのが最適です。 □ プロジェクト全体の鳥瞰図である概念モデルを作ってから、個別システムの論理モデルにとりかからないと不整合や重複が発生する。第２章 モデルの基本作法 □ データモデリングは、メタデータを対象とします。 □ エンティティを名詞、属性を形容詞、リレーションシップを動詞とすると業務の実態を文章で表現できる。第３章 データモデルを補完するモデル □ プロセスモデルとしては、IDEF0（Icam DEFinition）モデルやDFD（Data Flow Diagram）など用います。 □ プロセスモデルの利用 １）プロセスモデル（IDEFE0）を描く ２）IDEFE0モデルからエンティティを抽出する ３）IDEF1Xデータモデルでエンティティ間の関連付けを行う ４）エンティティ/属性（アトリビュート）の追加を行いデータモデルに反映させる ５）データの発生/更新のタイミングをDFDで捉える第４章 エンティティの切り出し方 □ エンティティはリソースとイベントを分けて考える。 □ 最初にリソースデータを抽出し、それらの関連付けを行った後、イベント系データ抽出を行う □ 全体ビジネスフローからリソース系エンティティを切り出す １）他と重複しないこと ２）あまり長くならないこと ３）xxマスターとかxx管理といった意味のない修飾は付加しないこと 第５章 トップダウンで主キーと主要属性の定義 □ 主キーの選定基準は以下のようになります １）値の変わらないもの ２）できるだけ桁数の短いもの ３）複合キーでの連結が多くならない（５つを超えない） ４）必ず存在するものであること（NULLを許さない） □ モデルは視覚的に捉えられるところに意義がある □ 主キー候補、主な属性を埋めながらモデルの矛盾や不足を発見し、エンティティ、リレーションシップの追加、変更を行う。 第６章 ネーミング標準とドメイン □ 基本コード、住所、名称、日付といった業務にあまり依存しないものを「共通ドメイン」とし、販売、物流、購買、会計といった業務固有で発生するものを「業務固有ドメイン」とするのが望ましいと思います第７章 ボトムアップ分析（１） □ 主キーの選定基準に従って定義していきます。 □ 複合キーの一部に従属する属性は別のエンティティとせよ □ 主キー以外の項目に依存する項目は、別なエンティティとせよ。 □ 正規化作業とは、同じキーにのみ依存するデータ項目を一つの１つのエンティティにまとめる作業といえます。第８章 ボトムアップ分析（２） □ DFDからはデータモデルだけではわからない業務ルールが読み取れる。第１３章 モデルレビューの観点 □ 誰にでも容易に説明できるモデルになっているか □ 業務の流れを含んだモデル構成が理解できれば完成度は高いと言えます □ 論理モデルのレビュー １）データモデルがユーザ要件（業務要件）を正しく反映しているか ２）定められた記法（IDEF1Xなど）に従い、データモデルとして論理矛盾がないか ３）プロジェクトで規定した標準が遵守されているか □ レビューチェックシートの分類 １）準拠性 ２）要件充足性 ３）正規化 ４）論理変換 ５）物理属性定義 ６）変更管理第１５章 物理実装のポイント □ 容量見積手順 １）各テーブルのレコード長を算出する ２）レコード長をもとに最適なブロックサイズを決める ３）レコードあるいはブロック単位で付加情報の長さを考慮して、１ブロックあたりの格納レコード数を算出する ４）最大格納数を算出する ５）必要サイズを算出する（初期分、増分） ６）追加/更新の頻度を考慮してブロック当たりのフリースペースサイズ（割合）を決める
出産・子育て
ファッション
美容・コスメ
健康・ダイエット
生活・インテリア
料理・食べ物
ドリンク・お酒
ペット
趣味・ゲーム
映画・ＴＶ
音楽
読書・コミック
旅行・海外情報
園芸
スポーツ
アウトドア・釣り
車・バイク
パソコン・家電
そのほか
すべてのジャンル
