第５回 モデリングを押さえておこう

もう去年の話になるが、ようやくデータベーススペシャリスト試験に合格することが出来た。それも、いつもギリギリの点で泣いていたのと違い、わりと余裕の点数で合格出来た。
まあ、サボらずに勉強を続けていたことが一番大きいとは思うけど、その原動力になったのは、モデリングの基礎を学んだことだと思う。午後試験対策はいつも過去問を解いて理解に勤めていたがいつもギリギリのところで駄目だった。これは基本をキチンと抑えた方がいいと思い、午後２でいつも苦戦しているモデリングをきっちり学ぶことにしたのだ。
そのおかげで午後２の、あのE-R図も何とかクリアできたのだった（答案用紙のあの空白の様は解く前には不安に陥れられたものだった）。
前置きが長くなった。ここでは、そのモデリングで学んだことをまとめておく。とりあえず、１０個の学んだ大切なこととと題してまとめてみた。・・・既に結構忘れていたりするのだが。

１．システムを理解するには、まずは概念モデルを押さえておく

• 概念モデルとはシステムの青写真・ラフスケッチ
• 開発対象だけなく、関連システムも含んだ概念モデルを押さえておく
• モデリング＝システムの対象（こんなシステムを作りたいといったイメージ）を定まった記法で図式表現したもの

２．モデル図はシステム理解のヒントの固まり

• エンティティを名詞、属性を形容詞、または修飾句、リレーションシップを動詞に置き換える　→　対象業務の実態を表す文章になる

３．リレーションシップはただの線じゃあないんだよ！

• リレーションシップの設定はビジネスルールの設定につながる→NULLオプションの設定、カーディナリティ等

４．エンティティ切り出しのポイント：エンティティは大きくわけて二種類ある

• リソース系（人、組織、物、設備、顧客、金など）：システムが扱う対象を把握
• イベント系（企業活動を構成するアクティビティ（活動））：システムの業務の種類を把握
• E-R図の配置は大抵、リソースデータは上面に、イベントデータは下面に、が基本

５．ネーミングは基本ルールで統一

• 修飾語＋主用語＋区分語で名前を定義　
  • 例）　店別（修飾語）売上（主用語）金額（区分語）
• 区分語は基本属性（数、文字列等）
• 辞書作ってシノニム・ホモニムを避ける
• 物理名に変換する時も辞書大事

６．分析するにはトップダウンとボトムアップ

• トップダウン分析→業務フローや業務記述書が元
• ボトムアップ分析→画面や帳票を元に、画面単位でまずはエンティティ化する

７．履歴管理モデル作成の基本指針

• 履歴エンティティに属性をコピーする
  • この場合、元エンティティへのリレーションはなくし、名称も変える
• リソースエンティティで履歴管理する
  • 適用開始日、適用終了日等

８．よいモデルとは何？

• モデルを見たら業務の概略がわかる
• 一度説明してもらえば業務内容が把握できる
• データの発生タイミングや発生場所の異なる属性はエンティティとして分けていた方が読みやすい

９．サイズの決定もエンティティの種類で異なる

• リソース系：現状の件数＋増分を考慮
• イベント系：一日あたりのトランザクション数とデータの蓄積期間

１０．要件に応じて適切にモデル変更

• 分類の追加が想定されるエンティティ　→　サブタイプの導入　→　変更を局所化出来る
• 日常業務要件からの変更→リソース系ではなく、イベント系のエンティティの変更で対処が大抵可能
• エンティティの役割が複数ある　→　役割を示すロールエンティティとの関連を定義しておく

参考文献

実践的データモデリング入門 (DB magazine selection)