①HP （Itanium9300番台）
②IBM （Power）
③Oracle・富士通（UltraSPARC/ SPARC64）
インテル（Itanium7300番台 → Xeon7500番台）
2010年5月25日火曜日
2010年5月12日水曜日
データモデリング
【データモデリング】
「モデリング」
現実の業務の世界を抽象化すること＝こんなシステムを作りたいといったイメージを定まった表記で図式表現したもの
「モデル」
①概念モデル
②論理モデル
③物理モデル
データモデル → プロセスモデル → ワークフローモデル
「ER図」Entity Relation Diagram
トップダウン分析に基づくデータモデル図
「データモデル3要素」
①エンティティ（モデルの管理対象） → 名詞（例：開発プロジェクト）
②属性 → 形容詞（例：構成メンバーの特徴）
③リレーションシップ → 動詞（例：参加する）
「メタデータ」
データに関するデータ
「エンティティ」
①独立エンティティ
②依存エンティティ
③特性エンティティ
④関連エンティティ
⑤分類エンティティ
「独立エンティティ」
他のエンティティに依存せず、それ自身で存在し得るエンティティ。
「依存エンティティ」
他のエンティティがなければ存在し得ないエンティティ。エンティティ枠の角がない。
「抽象度」
モデリングは事実を抽象化していく作業なので、できるだけ汎化したほうがよさそうだが、あまり汎化しすぎると「地球」とか「人間」「物体」というなエンティティばかりになってしまい、何が何だか分からなくなる。どこで止めるかが勘所である。
「主キー」
エンティティ内でデータ（インスタンス）を一意に識別できる属性のこと
「複合キー」
複数の属性の組み合わせではじめて一意に識別できるキー
「外部キー」（FK=Foreign Key）
親にあたる他のエンティティから借りてきた属性。親のエンティティを参照するためのキー
「依存」
例えば「教室」から「生徒」に対して依存関係を引くと、教室なしに生徒は存在しない
「1対多、多対多」
教室と生徒（1対多＝1:n）教室が分かっても、生徒は一意に定まらない
生徒が分かれば、教室は一意に定まる
生徒と趣味（多対多＝m:n）生徒が分かっても趣味は一意に定まらない
趣味が分かっても、生徒は一意に定まらない
「データモデル表記法」
①IDEF1X（アイデフワンエックス：Integration DEFinition 1st edition extended）RDBにマッピングできるように開発されたモデル言語。RDBと親和性が高く、データモデルで表現したものを、ほぼ1対1でRDBに実装できる
②IE記法
③Peter Chen記法
④CASE*Method記法
⑤UMLのクラス図
データモデリングを学べば、ビジネスの本質を見抜く素養が確実に身に付く。UMLモデリングのためには、データモデリングで訓練を積むことが必要。
「データモデルとクラス図」
物理設計フェーズ、実装フェーズでは、データモデルはデータの格納先であるテーブルを意識し、クラス図はクラス（プラグラム）を対象にしている。
「ODA」（Data Oriented Approach）
データ指向。意味を持つデータは1箇所で管理することを最重要視する。
「OOA」（Object Oriented Approach）
オブジェクト指向。ODAではデータの最適化だけを考えて、どのように処理するかは考えないが、OOAではデータと処理を見て、モデル化（クラス図）していく。
「プロセスモデル」
データモデルは、ある業務の静止した状態を描いたもの、このため業務プロセスを突き合わせた場合、必要なエンティティは変わり、参照・更新されるデータ項目（属性）も異なる。すなわち、プロセスモデルからは、データモデルを場面に応じたビューで見る必要がある。このようにデータモデルだけではカバーしきれないところを表現してくれるのがプロセスモデルである。
「プロセスモデルの種類」
①IDEF0（Icam DEFinition 0）
②DFD（Data Flow Diagram）
「データモデリングの手順」
①プロセスモデル（IDEF0）を描く
②IDEF0モデルからエンティティを抽出する
③IDEF1Xデータモデルで、エンティティ間の関連付けを行う
④エンティティ／属性の追加を行い、データモデルに反映させる
⑤データの発注／更新のタイミングをDFDでとらえる
「データモデルとルール」
データモデルで表現できるルールは、データベース内に表現できるが（テーブル、テーブル間の関連、参照制約、トリガーなど）、それ以外の内在するルールは、プログラム内のロジックとして、コードを書かざるを得ない。
「エンティティの抽出」
①リソース系
・人（社員、顧客）、組織（部署、工場、物流センター）
・物（商品、製品、部品、仕掛品）、設備（工場、製造ライン、配送トラック）
・顧客（取引先、得意先、調達先）
・金（勘定科目）
②イベント系
・注文
・発注
・購買
・出荷
＊イベント系のエンティティは、発生から消滅までのライフサイクルを追いかける必要がある。
「リソース系エンティティの抽出」
①人と組織
・顧客、配送センター、届け先
②取引先
・クレジットカード会社、銀行、取次、出版社、コンビニ、SS
③物と設備
・商品、配送便、ショッピングカート
＊破線は非依存関係。親が存在しない場合があり得ることを示す。
「リソース系エンティティの定義」
（出版社） 書籍・雑誌の出版を行う会社
（銀行） クレジットの引き落とし口座に指定された銀行
（顧客） ネットショップを訪問し、1回でも注文を行った個人、または法人
（クレジットカード会社） 顧客が加入しているクレジットカード会社
（商品） ネットショップで扱う商品
（ショッピングカート） ネットショップで買い物をするときに、一時的に商品を入れておくレジ通過前の買い物かご
（届け先） 商品の届け先。請求先と異なる場合がある
（配送便） 配送用トラック
（コンビニ） ネットショップと契約しているコンビニエンスストア
（SS） ネットショップと契約しているサービスステーション
（取次） 出版社から書籍・雑誌を仕入れて小売店に納入する業者
（配送センター） 顧客への配送設備と若干の在庫を持つ。取次から書籍・雑誌が納入される場所
「イベント系エンティティの抽出」
「イベント系エンティティの定義」
（注文） 顧客からの書籍・雑誌の購入注文
（入荷） 出版社から取次を通して配送センターに雑誌・書籍を入荷すること
（支払請求） クレジットカード会社への売上請求を行う
（売上） 売上計上する
（出荷） 配送センターから、顧客向け、店頭渡し先へ向けて雑誌・書籍を配送すること
（商品在庫） 配送センター内で特定の雑誌・書籍についてのみ保持している在庫
（収納） 商品代金の代行受け取り行う
（出荷指示） 顧客からの注文に応じて、配送センターに出荷を依頼すること
（発注） 顧客からの注文のうち、在庫のないものについて、出版社にオーダーすること
「データモデルの基本型」
①依存関係
プロジェクトには、複数のプロジェクトメンバーがいる。
プロジェクトメンバーは、プロジェクトなしでは存在しない。
②非依存関係
組織は、複数の社員から構成される。
どの組織にも所属しない社員がいる。
③多対応関係
ひとつの商品は、複数個所に配送される。
一回の配送で、複数の商品を取り扱う。
④分類関係
商品調達先は、メーカー、商社、量販店に分類される。
エンティティをより具体的に分類することをサブタイプ化（特化）するという。サブタイプ化を進めることにより、データモデル上での業務の姿が分かりやすくなる。
「エンティティの配置ルール」
例① リソース系データを上に、イベント系データを下に配置する
例② リソース系データを、イベント系データの周りに配置する
例③ イベントを発生順に並べ、付帯するリソースを周りに配置する
例④ リソースの中は、人、物、顧客、金銭など、タイプごとに分けて配置する
いったん目にしたモデル図はイメージとして頭の中に焼きつけられるので、不要な混乱を防ぐため、モデルの配置はできるだけ変えないようにする
「主キー」
最も重要なデータ項目。エンティティ内のデータ（インスタンス）を一意に識別するために使う。SQLのCREAT TABLE文などで使われる”PRIAMRY KEY”と同じ。
「主キーの選定基準」
①値の変わらないもの
②できるだけ桁数の短いもの
③複合キーでの連結が多くならないもの（5つを超えない）
④必ず存在するもの（NULLを許さない）
「ボトムアップ・アプローチ」
画面や帳票、現行データベースから属性を見つけ出す。
「シノニム」
異音同義語。
「ホノニム」
同音異義語。
「データ管理者」（Data Administrator）
会社全体のデータ項目を理解し、整合性を保つ。
「ネーミングルール例」
①主要語（Prime）
売上
営業
銀行
契約
在庫
仕入
配送
商品
製品
組織
電話
②修飾語（qualifier）
日別
週間
期間
通常
店別
③区分語（class）
コード
番号
NO
名
区分
種別
識別
日時
日数
数
金額
比率
回
高
「ドメイン」
データの標準化を見かけ倒しに終わらせないための強力な武器。「データの型やデータの取り得る値／範囲などの規定」で、その属性（データ項目）の素性を表す。年月日、名称、コード、番号、金額など、同じ単位や長さでグルーピングされており、これらをうまく利用することで、データが標準化され分かりやすいモデルができる。区分がドメインに近い。論理ドメイン、物理ドメインがある。
「共通ドメイン」
基本コード、住所、名称、日付といった、業務にあまり依存しないもの。共通マスタのドメインがシステムごとに異なっていては、エンタープライズモデリングはおぼつかない。
「業務固有ドメイン」
販売、物流、購買、会計といった、業務固有で発生するもの。
「データ項目標準化のプロセス」
①現状データ項目分析（意味解析／同義語調査）
↓
②ドメイン定義（ドメイン名／データタイプ／長さ／有効値）
↓
③正式データ項目名付与（用語集）
エンティティ名
データ項目名
意味
ドメイン
主要語
修飾語
分類区分語
新データ項目名
「データ項目の要素」
①名称
・属性名： モデル上の論理名称（日本語名）
・カラム名： DBMS実装上の名前。モデルとしての名前である日本語名をそのまま用いることも可能（ほとんどのDBMSでダブルバイトでの定義が可能となっている）
②意味定義
③ドメイン（定義域）
④データタイプ（文字型、数値型、日付型）
⑤桁数（長さ）
⑥デフォルト
⑦ルール制約： ドメインで定義する有効値（バリデーション）
「正規化」
同じ主キーにのみ依存するデータ項目を、ひとつのエンティティにまとめ上げる作業。正規化を行わないと、データ不整合の可能性が高まる。主キーが同じでも、発生タイミングやコンテンツの違いにより、別のエンティティにすることもある。
①繰り返し項目を取り除く（明細エンティティを追加）
②複合キーの一部に従属する属性は、別のエンティティにする
③主キー以外の項目に依存する項目は、別なエンティティにする
「導出項目」
算式によって求められる項目。正規化の観点からは排除すべきたが、エンティティを説明する役割も果たすので一概に排除すればよいというものでもない。
「業務モデル」
企業内の業務と、業務で扱っている情報のやり取りをモデル化したもの。企業のあるべき姿に基づく情報システムの姿を描き出す。
「DFD」
DFDを描くことで、データモデルからは理解しづらい業務ルールが見えてきたり、エンティティの分割や、項目の過不足といったモデルの検証が可能になる。
①データストア： エンティティ、現行テーブル、出力帳票
②データフロー： 主要参照データ、更新データ、入出力画面
③プロセス（アクティビティ）： 業務（システム）機能。実装DFDでは最下位レベルでプログラムと対応。階層化して順次詳細化する
④エクスターナル： 組織、外部部門、データ発生源と出力先
「業務ルール」
業務処理手順や、データ発生のトリガーイベントの把握などをさす。どの部門のどこでデータが発生し、次にどの部門の誰に回付されるかのワークフローや、そこでどんなイベントによってデータが更新されるか、などである。
「DFD作成者」
①上流フェーズ（要求分析段階）でアナリストが描く
②データのライフサイクルを捉える手段としてデータモデラーが補足的に描く
③プロセス（最終的にはプログラム）設計者が、各アクティビティで何が入力・加工・出力されるかを整理するために描く
④データモデラーがモデルの検証用に記述する
「CRUD分析」
データのライフサイクルを分析する。あまりにもプロセスのことを考慮してしまうと、せっかく作った正規型モデルが崩れ、モデリングの価値が半減する。Createのタイミングを捉えると、実施部門を知ることができ、エンティティの主幹部署を見つけ出すことができる。
①Create(生成・発生）
②Refer（参照）
③Update（更新）
④Delete（削除・消滅）
「IRUN分析」
属性単位の更新タイミングの把握を行う。エンティティレベルのCRUD分析では、InsertやUpdateといっても、どの項目を対象とするのか分からない。そこでもう一段下位の属性レベルでIRUN分析を行う。
①Import（挿入）
②Refer（参照）
③Update（更新）
④Null（空値セット）
「オーナーの決定」
①サブシステム化
②エンティティオーナーの決定
③エンティティ主管部署の決定
「エンティティ定義書」
①意味定義
②目的： なぜこのエンティティが必要なのか
③発生タイミング（イベント）
④更新タイミング（イベント）
⑤消滅タイミング（イベント）
⑥発生頻度： ○○件／日
⑦当初予測件数： ○○件
（現行システムからの移行）
⑧管理部署
エンティティの発生・更新、および格納されているデータ内容について責任を負う部署。エンティティオーナー部署
「トップダウンモデルとボトムアップモデル」
トップダウンで作成した概念モデルを用いて、ボトムアップモデルに漏れがないかをチェックする。トップダウンモデルはより広範囲を対象としており、鳥瞰図の役割を果たす。トップダウンモデルでは、新たなコードデータを作らず、できるだけ実在するデータをエンティティ用の識別キーとして設定する。その方が業務を捉えやすく「意味モデル」としての効果があるからである。
「トップダウンモデルの明示」
既存システムのリプレイスにおいても、システム全体を見渡すトップダウンモデルは必要である。リプレイスとはいっても、まったく同じ機能のままということは考えられない。何らかの新しい概念が加わったのであれば、エンティティの追加は必要である。ボトムアップモデルしかない状態では、どこに新エンティティを挿入すればよいか分かりづらくなる。たとえモデル上に現れていない概念でも、トップダウンモデルがあれば全体が見渡せるため、関連するエンティティを見ながら適正な配置が可能となる。プロジェクトメンバーの中で情報を共有していくためにも概念モデルを明示化することは重要である。ただし、トップダウンモデルの概念モデルを作成するのに膨大な時間をかける必要はない。
「サブジェクト（システム）分割」
サブジェクトごとに切り分けてモデルを検証することで、全体から見たサブジェクトの位置づけや、隣接サブジェクトに所属するエンティティとの関係などを把握できる。
①ネット販売（受注）
②顧客管理
③収納決済
④商品管理
⑤発注・仕入
「物理モデルと論理モデル」
①物理モデル
・テーブル名
・カラム名
②論理モデル
・エンティティ名
・属性名
「RDB」
RDBは単にデータを格納するだけの器ではなく、登録や変更の際に、ルールに従ってデータの整合性をチェックする機能も持っている。
「RDBにおける制約」
①NOT NULL制約
②一意性制約（UNIQUE KEY）
③主キー制約（PRIMARY KEY）
④参照制約（参照整合性制約）
「RDBにおけるビジネスルールのアクションルール表現」
①SET NULLルール
②RESTRICTルール
③CASCADEルール
「RDBにおける多対多」
多対多関係のままではRDBに実装できない。エンティティの中間に交差エンティティを追加することで、1対多へ収束させることができる。
「再帰的」
あるものについて記述する際に、記述しているものそれ自身への参照が、その記述中にあらわれることをいう。
「データモデリングの目的」
モデルの依存／非依存関係、もしくはカーディナリティの違いといった小さな違いが、まったく異なったビジネス関係を示すことがある。ビジネス上の事実関係を明確に定義することが、データモデリングの目的といえる。
「ビジネスルール」
ビジネスルールは、プログラムコードで実装する場合と、RDBの制約として実装する場合がある。
①導出タイプ
1.1 商品購入合計＝SUM（商品購入数量＊商品購入単価）
SQLのSUM関数を使ってビュー上に定義することで、RDBとのマッピングが可能になる。
1.2 商品購入合計＋支払残＜与信限度額 のときに「注文を受け付ける」
異なるエンティティに所属する属性間の関係をデータモデルから読み取ることは困難。通常プログラムコードとして実装する。
②有効値タイプ
2.1 商品注文年月日＜商品届け年月日
2.2 商品購入合計＜20万円
CHECK関数を用いてRDBに実装できる。
③参照制約タイプ
3.1 1回の注文には必ずひとつ以上の注文明細が存在する
3.2 顧客のいない注文はあり得ない
顧客と注文内容の必須の非依存関係から定義できる
---
「主要ドキュメント」
①機能一覧
②データモデル図
③業務プロセス図
「データモデルを中心のレビュー方法」
①ドキュメントのクロスチェック
単一のドキュメントを日本語で記述した場合、解釈に多少の揺れがあっても見過ごされやすいが、データモデルとクロスチェックすることで、ごまかしを排除できる。
「このデータは、どの機能で登録されますか？」
「この機能では、どのデータを登録しますか？」
「このデータはどの業務プロセスで生成されますか？」
「このデータは誰が参照しますか？」
②データモデルの業務ルールを日本語で説明させる
業務ルールとは「1件の受注には複数の明細がある」、「受注には事前の見積りが存在する場合と、存在しない場合のふたつがある。見積りが存在する場合、必ずひとつの受注はひとつの見積りと対応する」、「受注には必ず見積りが存在する」といった類の内容である。エンティティ間の多重度については、特に念入りな検証が必要である。複数部門が関わる場合は、用語を統一するのとともに、早い段階で業務ルールの検証を進めたほうがよい。
③他システムとの連携を確認する
連携先システムのオーナーとの間で作業の分担や責任の方針を決めた上で、連携方法やタイミングを検討する。
「データモデル作成のタイミング」
データモデルは、基本設計で作成することが多いが、要件定義工程から作成したほうが良い。開発契約締結時に「要件定義工程でデータモデルを成果物に含め、承認の対象とすること」と「業務部門と情報システム部門とIT企業担当者が一堂に集まってレビューを実施し、レビューではIT企業が成果物を説明すること」を合意しておく。この時点でのデータモデルは粒度を細かくしないこと。詳細まで踏み込みすぎない骨格レベルの「概念モデル」で十分である。モデルの詳細度を粗めに設定して、システム化する業務全体のデータモデルを作成するように調整する。
「データモデルを効率的に理解するコツ」
①エンティティを「マスタ」と「トランザクション」に区別する
②トランザクションの流れから業務の流れ全体を把握する
③主要なトランザクション（契約や発注など）を起点に理解を深める
④主要なトランザクションと他のエンティティとの関係を把握する
（参考文献）
「実践的データモデリング入門」真野正（翔泳社）
「日経コンピュータ20100120」吉村泰正（日経BP）
「モデリング」
現実の業務の世界を抽象化すること＝こんなシステムを作りたいといったイメージを定まった表記で図式表現したもの
「モデル」
①概念モデル
②論理モデル
③物理モデル
データモデル → プロセスモデル → ワークフローモデル
「ER図」Entity Relation Diagram
トップダウン分析に基づくデータモデル図
「データモデル3要素」
①エンティティ（モデルの管理対象） → 名詞（例：開発プロジェクト）
②属性 → 形容詞（例：構成メンバーの特徴）
③リレーションシップ → 動詞（例：参加する）
「メタデータ」
データに関するデータ
「エンティティ」
①独立エンティティ
②依存エンティティ
③特性エンティティ
④関連エンティティ
⑤分類エンティティ
「独立エンティティ」
他のエンティティに依存せず、それ自身で存在し得るエンティティ。
「依存エンティティ」
他のエンティティがなければ存在し得ないエンティティ。エンティティ枠の角がない。
「抽象度」
モデリングは事実を抽象化していく作業なので、できるだけ汎化したほうがよさそうだが、あまり汎化しすぎると「地球」とか「人間」「物体」というなエンティティばかりになってしまい、何が何だか分からなくなる。どこで止めるかが勘所である。
「主キー」
エンティティ内でデータ（インスタンス）を一意に識別できる属性のこと
「複合キー」
複数の属性の組み合わせではじめて一意に識別できるキー
「外部キー」（FK=Foreign Key）
親にあたる他のエンティティから借りてきた属性。親のエンティティを参照するためのキー
「依存」
例えば「教室」から「生徒」に対して依存関係を引くと、教室なしに生徒は存在しない
「1対多、多対多」
教室と生徒（1対多＝1:n）教室が分かっても、生徒は一意に定まらない
生徒が分かれば、教室は一意に定まる
生徒と趣味（多対多＝m:n）生徒が分かっても趣味は一意に定まらない
趣味が分かっても、生徒は一意に定まらない
「データモデル表記法」
①IDEF1X（アイデフワンエックス：Integration DEFinition 1st edition extended）RDBにマッピングできるように開発されたモデル言語。RDBと親和性が高く、データモデルで表現したものを、ほぼ1対1でRDBに実装できる
②IE記法
③Peter Chen記法
④CASE*Method記法
⑤UMLのクラス図
データモデリングを学べば、ビジネスの本質を見抜く素養が確実に身に付く。UMLモデリングのためには、データモデリングで訓練を積むことが必要。
「データモデルとクラス図」
物理設計フェーズ、実装フェーズでは、データモデルはデータの格納先であるテーブルを意識し、クラス図はクラス（プラグラム）を対象にしている。
「ODA」（Data Oriented Approach）
データ指向。意味を持つデータは1箇所で管理することを最重要視する。
「OOA」（Object Oriented Approach）
オブジェクト指向。ODAではデータの最適化だけを考えて、どのように処理するかは考えないが、OOAではデータと処理を見て、モデル化（クラス図）していく。
「プロセスモデル」
データモデルは、ある業務の静止した状態を描いたもの、このため業務プロセスを突き合わせた場合、必要なエンティティは変わり、参照・更新されるデータ項目（属性）も異なる。すなわち、プロセスモデルからは、データモデルを場面に応じたビューで見る必要がある。このようにデータモデルだけではカバーしきれないところを表現してくれるのがプロセスモデルである。
「プロセスモデルの種類」
①IDEF0（Icam DEFinition 0）
②DFD（Data Flow Diagram）
「データモデリングの手順」
①プロセスモデル（IDEF0）を描く
②IDEF0モデルからエンティティを抽出する
③IDEF1Xデータモデルで、エンティティ間の関連付けを行う
④エンティティ／属性の追加を行い、データモデルに反映させる
⑤データの発注／更新のタイミングをDFDでとらえる
「データモデルとルール」
データモデルで表現できるルールは、データベース内に表現できるが（テーブル、テーブル間の関連、参照制約、トリガーなど）、それ以外の内在するルールは、プログラム内のロジックとして、コードを書かざるを得ない。
「エンティティの抽出」
①リソース系
・人（社員、顧客）、組織（部署、工場、物流センター）
・物（商品、製品、部品、仕掛品）、設備（工場、製造ライン、配送トラック）
・顧客（取引先、得意先、調達先）
・金（勘定科目）
②イベント系
・注文
・発注
・購買
・出荷
＊イベント系のエンティティは、発生から消滅までのライフサイクルを追いかける必要がある。
「リソース系エンティティの抽出」
①人と組織
・顧客、配送センター、届け先
②取引先
・クレジットカード会社、銀行、取次、出版社、コンビニ、SS
③物と設備
・商品、配送便、ショッピングカート
「リソース系エンティティの定義」
（出版社） 書籍・雑誌の出版を行う会社
（銀行） クレジットの引き落とし口座に指定された銀行
（顧客） ネットショップを訪問し、1回でも注文を行った個人、または法人
（クレジットカード会社） 顧客が加入しているクレジットカード会社
（商品） ネットショップで扱う商品
（ショッピングカート） ネットショップで買い物をするときに、一時的に商品を入れておくレジ通過前の買い物かご
（届け先） 商品の届け先。請求先と異なる場合がある
（配送便） 配送用トラック
（コンビニ） ネットショップと契約しているコンビニエンスストア
（SS） ネットショップと契約しているサービスステーション
（取次） 出版社から書籍・雑誌を仕入れて小売店に納入する業者
（配送センター） 顧客への配送設備と若干の在庫を持つ。取次から書籍・雑誌が納入される場所
「イベント系エンティティの抽出」
「イベント系エンティティの定義」
（注文） 顧客からの書籍・雑誌の購入注文
（入荷） 出版社から取次を通して配送センターに雑誌・書籍を入荷すること
（支払請求） クレジットカード会社への売上請求を行う
（売上） 売上計上する
（出荷） 配送センターから、顧客向け、店頭渡し先へ向けて雑誌・書籍を配送すること
（商品在庫） 配送センター内で特定の雑誌・書籍についてのみ保持している在庫
（収納） 商品代金の代行受け取り行う
（出荷指示） 顧客からの注文に応じて、配送センターに出荷を依頼すること
（発注） 顧客からの注文のうち、在庫のないものについて、出版社にオーダーすること
「データモデルの基本型」
①依存関係
プロジェクトには、複数のプロジェクトメンバーがいる。
プロジェクトメンバーは、プロジェクトなしでは存在しない。
組織は、複数の社員から構成される。
どの組織にも所属しない社員がいる。
③多対応関係
ひとつの商品は、複数個所に配送される。
一回の配送で、複数の商品を取り扱う。
商品調達先は、メーカー、商社、量販店に分類される。
エンティティをより具体的に分類することをサブタイプ化（特化）するという。サブタイプ化を進めることにより、データモデル上での業務の姿が分かりやすくなる。
「エンティティの配置ルール」
例① リソース系データを上に、イベント系データを下に配置する
例② リソース系データを、イベント系データの周りに配置する
例③ イベントを発生順に並べ、付帯するリソースを周りに配置する
例④ リソースの中は、人、物、顧客、金銭など、タイプごとに分けて配置する
いったん目にしたモデル図はイメージとして頭の中に焼きつけられるので、不要な混乱を防ぐため、モデルの配置はできるだけ変えないようにする
「主キー」
最も重要なデータ項目。エンティティ内のデータ（インスタンス）を一意に識別するために使う。SQLのCREAT TABLE文などで使われる”PRIAMRY KEY”と同じ。
「主キーの選定基準」
①値の変わらないもの
②できるだけ桁数の短いもの
③複合キーでの連結が多くならないもの（5つを超えない）
④必ず存在するもの（NULLを許さない）
「ボトムアップ・アプローチ」
画面や帳票、現行データベースから属性を見つけ出す。
「シノニム」
異音同義語。
「ホノニム」
同音異義語。
「データ管理者」（Data Administrator）
会社全体のデータ項目を理解し、整合性を保つ。
「ネーミングルール例」
①主要語（Prime）
売上
営業
銀行
契約
在庫
仕入
配送
商品
製品
組織
電話
②修飾語（qualifier）
日別
週間
期間
通常
店別
③区分語（class）
コード
番号
NO
名
区分
種別
識別
日時
日数
数
金額
比率
回
高
「ドメイン」
データの標準化を見かけ倒しに終わらせないための強力な武器。「データの型やデータの取り得る値／範囲などの規定」で、その属性（データ項目）の素性を表す。年月日、名称、コード、番号、金額など、同じ単位や長さでグルーピングされており、これらをうまく利用することで、データが標準化され分かりやすいモデルができる。区分がドメインに近い。論理ドメイン、物理ドメインがある。
「共通ドメイン」
基本コード、住所、名称、日付といった、業務にあまり依存しないもの。共通マスタのドメインがシステムごとに異なっていては、エンタープライズモデリングはおぼつかない。
「業務固有ドメイン」
販売、物流、購買、会計といった、業務固有で発生するもの。
「データ項目標準化のプロセス」
①現状データ項目分析（意味解析／同義語調査）
↓
②ドメイン定義（ドメイン名／データタイプ／長さ／有効値）
↓
③正式データ項目名付与（用語集）
エンティティ名
データ項目名
意味
ドメイン
主要語
修飾語
分類区分語
新データ項目名
「データ項目の要素」
①名称
・属性名： モデル上の論理名称（日本語名）
・カラム名： DBMS実装上の名前。モデルとしての名前である日本語名をそのまま用いることも可能（ほとんどのDBMSでダブルバイトでの定義が可能となっている）
②意味定義
③ドメイン（定義域）
④データタイプ（文字型、数値型、日付型）
⑤桁数（長さ）
⑥デフォルト
⑦ルール制約： ドメインで定義する有効値（バリデーション）
「正規化」
同じ主キーにのみ依存するデータ項目を、ひとつのエンティティにまとめ上げる作業。正規化を行わないと、データ不整合の可能性が高まる。主キーが同じでも、発生タイミングやコンテンツの違いにより、別のエンティティにすることもある。
①繰り返し項目を取り除く（明細エンティティを追加）
②複合キーの一部に従属する属性は、別のエンティティにする
③主キー以外の項目に依存する項目は、別なエンティティにする
「導出項目」
算式によって求められる項目。正規化の観点からは排除すべきたが、エンティティを説明する役割も果たすので一概に排除すればよいというものでもない。
「業務モデル」
企業内の業務と、業務で扱っている情報のやり取りをモデル化したもの。企業のあるべき姿に基づく情報システムの姿を描き出す。
「DFD」
DFDを描くことで、データモデルからは理解しづらい業務ルールが見えてきたり、エンティティの分割や、項目の過不足といったモデルの検証が可能になる。
①データストア： エンティティ、現行テーブル、出力帳票
②データフロー： 主要参照データ、更新データ、入出力画面
③プロセス（アクティビティ）： 業務（システム）機能。実装DFDでは最下位レベルでプログラムと対応。階層化して順次詳細化する
④エクスターナル： 組織、外部部門、データ発生源と出力先
「業務ルール」
業務処理手順や、データ発生のトリガーイベントの把握などをさす。どの部門のどこでデータが発生し、次にどの部門の誰に回付されるかのワークフローや、そこでどんなイベントによってデータが更新されるか、などである。
「DFD作成者」
①上流フェーズ（要求分析段階）でアナリストが描く
②データのライフサイクルを捉える手段としてデータモデラーが補足的に描く
③プロセス（最終的にはプログラム）設計者が、各アクティビティで何が入力・加工・出力されるかを整理するために描く
④データモデラーがモデルの検証用に記述する
「CRUD分析」
データのライフサイクルを分析する。あまりにもプロセスのことを考慮してしまうと、せっかく作った正規型モデルが崩れ、モデリングの価値が半減する。Createのタイミングを捉えると、実施部門を知ることができ、エンティティの主幹部署を見つけ出すことができる。
①Create(生成・発生）
②Refer（参照）
③Update（更新）
④Delete（削除・消滅）
「IRUN分析」
属性単位の更新タイミングの把握を行う。エンティティレベルのCRUD分析では、InsertやUpdateといっても、どの項目を対象とするのか分からない。そこでもう一段下位の属性レベルでIRUN分析を行う。
①Import（挿入）
②Refer（参照）
③Update（更新）
④Null（空値セット）
「オーナーの決定」
①サブシステム化
②エンティティオーナーの決定
③エンティティ主管部署の決定
「エンティティ定義書」
①意味定義
②目的： なぜこのエンティティが必要なのか
③発生タイミング（イベント）
④更新タイミング（イベント）
⑤消滅タイミング（イベント）
⑥発生頻度： ○○件／日
⑦当初予測件数： ○○件
（現行システムからの移行）
⑧管理部署
エンティティの発生・更新、および格納されているデータ内容について責任を負う部署。エンティティオーナー部署
「トップダウンモデルとボトムアップモデル」
トップダウンで作成した概念モデルを用いて、ボトムアップモデルに漏れがないかをチェックする。トップダウンモデルはより広範囲を対象としており、鳥瞰図の役割を果たす。トップダウンモデルでは、新たなコードデータを作らず、できるだけ実在するデータをエンティティ用の識別キーとして設定する。その方が業務を捉えやすく「意味モデル」としての効果があるからである。
「トップダウンモデルの明示」
既存システムのリプレイスにおいても、システム全体を見渡すトップダウンモデルは必要である。リプレイスとはいっても、まったく同じ機能のままということは考えられない。何らかの新しい概念が加わったのであれば、エンティティの追加は必要である。ボトムアップモデルしかない状態では、どこに新エンティティを挿入すればよいか分かりづらくなる。たとえモデル上に現れていない概念でも、トップダウンモデルがあれば全体が見渡せるため、関連するエンティティを見ながら適正な配置が可能となる。プロジェクトメンバーの中で情報を共有していくためにも概念モデルを明示化することは重要である。ただし、トップダウンモデルの概念モデルを作成するのに膨大な時間をかける必要はない。
「サブジェクト（システム）分割」
サブジェクトごとに切り分けてモデルを検証することで、全体から見たサブジェクトの位置づけや、隣接サブジェクトに所属するエンティティとの関係などを把握できる。
①ネット販売（受注）
②顧客管理
③収納決済
④商品管理
⑤発注・仕入
「物理モデルと論理モデル」
①物理モデル
・テーブル名
・カラム名
②論理モデル
・エンティティ名
・属性名
「RDB」
RDBは単にデータを格納するだけの器ではなく、登録や変更の際に、ルールに従ってデータの整合性をチェックする機能も持っている。
「RDBにおける制約」
①NOT NULL制約
②一意性制約（UNIQUE KEY）
③主キー制約（PRIMARY KEY）
④参照制約（参照整合性制約）
「RDBにおけるビジネスルールのアクションルール表現」
①SET NULLルール
②RESTRICTルール
③CASCADEルール
「RDBにおける多対多」
多対多関係のままではRDBに実装できない。エンティティの中間に交差エンティティを追加することで、1対多へ収束させることができる。
「再帰的」
あるものについて記述する際に、記述しているものそれ自身への参照が、その記述中にあらわれることをいう。
「データモデリングの目的」
モデルの依存／非依存関係、もしくはカーディナリティの違いといった小さな違いが、まったく異なったビジネス関係を示すことがある。ビジネス上の事実関係を明確に定義することが、データモデリングの目的といえる。
「ビジネスルール」
ビジネスルールは、プログラムコードで実装する場合と、RDBの制約として実装する場合がある。
①導出タイプ
1.1 商品購入合計＝SUM（商品購入数量＊商品購入単価）
SQLのSUM関数を使ってビュー上に定義することで、RDBとのマッピングが可能になる。
1.2 商品購入合計＋支払残＜与信限度額 のときに「注文を受け付ける」
異なるエンティティに所属する属性間の関係をデータモデルから読み取ることは困難。通常プログラムコードとして実装する。
②有効値タイプ
2.1 商品注文年月日＜商品届け年月日
2.2 商品購入合計＜20万円
CHECK関数を用いてRDBに実装できる。
③参照制約タイプ
3.1 1回の注文には必ずひとつ以上の注文明細が存在する
3.2 顧客のいない注文はあり得ない
顧客と注文内容の必須の非依存関係から定義できる
---
「主要ドキュメント」
①機能一覧
②データモデル図
③業務プロセス図
「データモデルを中心のレビュー方法」
①ドキュメントのクロスチェック
単一のドキュメントを日本語で記述した場合、解釈に多少の揺れがあっても見過ごされやすいが、データモデルとクロスチェックすることで、ごまかしを排除できる。
「このデータは、どの機能で登録されますか？」
「この機能では、どのデータを登録しますか？」
「このデータはどの業務プロセスで生成されますか？」
「このデータは誰が参照しますか？」
②データモデルの業務ルールを日本語で説明させる
業務ルールとは「1件の受注には複数の明細がある」、「受注には事前の見積りが存在する場合と、存在しない場合のふたつがある。見積りが存在する場合、必ずひとつの受注はひとつの見積りと対応する」、「受注には必ず見積りが存在する」といった類の内容である。エンティティ間の多重度については、特に念入りな検証が必要である。複数部門が関わる場合は、用語を統一するのとともに、早い段階で業務ルールの検証を進めたほうがよい。
③他システムとの連携を確認する
連携先システムのオーナーとの間で作業の分担や責任の方針を決めた上で、連携方法やタイミングを検討する。
「データモデル作成のタイミング」
データモデルは、基本設計で作成することが多いが、要件定義工程から作成したほうが良い。開発契約締結時に「要件定義工程でデータモデルを成果物に含め、承認の対象とすること」と「業務部門と情報システム部門とIT企業担当者が一堂に集まってレビューを実施し、レビューではIT企業が成果物を説明すること」を合意しておく。この時点でのデータモデルは粒度を細かくしないこと。詳細まで踏み込みすぎない骨格レベルの「概念モデル」で十分である。モデルの詳細度を粗めに設定して、システム化する業務全体のデータモデルを作成するように調整する。
「データモデルを効率的に理解するコツ」
①エンティティを「マスタ」と「トランザクション」に区別する
②トランザクションの流れから業務の流れ全体を把握する
③主要なトランザクション（契約や発注など）を起点に理解を深める
④主要なトランザクションと他のエンティティとの関係を把握する
（参考文献）
「実践的データモデリング入門」真野正（翔泳社）
「日経コンピュータ20100120」吉村泰正（日経BP）
登録:
投稿 (Atom)