WINDOWS7 64bitマシンにリモートデスクトップ接続したい。
WINDOWS7はガードが堅くて、設定がなかなかやっかいである。
【接続を受け入れ可能にするための設定】
この設定により、WINODWS7マシンのログイン画面に到達可能となる。
1）コントロールパネル＞Windowsファイアウォール
2）左側のウィンドウ＞詳細設定
3）ファイアウォールの規則の表示と作成＞受信の規則
4）リモートデスクトップ（TCP受信）をダブルクリック
5）全般タブで＞操作＞◎接続を許可するを選択
6）OK
7）スタートボタン＞コンピューターを右クリック＞プロパティ
8）左側ウィンドウ「リモートの設定」
9）リモートタブ＞リモート デスクトップを実行しているコンピューターからの接続を許可するを選択＞OK
10）スリープおよび休止状態の設定＞なし
【ログインを受け入れ可能にするための設定】
WINDOWS7マシンのログイン画面に到達しているものの、ログインできない、という場合には下記の設定が有効である。
1）スタートボタン＞プログラムとファイルの検索に「mmc」と入力
2）いちばん上にmmc.exeが表示されるので、右クリックし、管理者として実行
3）コンソール画面の、ファイルメニューから、スナップインの追加と削除を選択
4）利用できるスナップインから、ローカルユーザーとグループを選択し、追加、完了、OK
5）ローカルユーザーとグループの中の「グループ」フォルダをダブルクリック
6）Remote Desktop Usersをダブルクリック
7）追加をクリックし、ユーザー名を入力
8）OK
2010年12月27日月曜日
2010年12月20日月曜日
Windows7 64bitマシンのCapsLockキーとCtrlキーを入れ替える
Windows7 64bitマシンのCapsLockキーとCtrlキーを入れ替えたい。
【Ctrl2Cap v2.0のインストール】
1）Ctrl2Cap v2.0 をダウンロードする
http://technet.microsoft.com/ja-jp/sysinternals/bb897578%28en-us%29.aspx
2）Ctrl2Capフォルダを解凍する
3）解凍したCtrl2Capフォルダを、Ｃドライブの直下に置く
4）すべてのプログラム＞アクセサリ＞コマンドプロンプト（右クリックで管理者として実行）
5）cd￥（半角）Ctrl2Cap と入力し実行
6）ctrl2cap /install と入力し実行
7）再起動する
8）CapsLockキーとCtrlキーが入れ替わっていることを確認する
【Ctrl2Cap v2.0のアンインストール】
1）すべてのプログラム＞アクセサリ＞コマンドプロンプト（右クリックで管理者として実行）
2）cd￥（半角）Ctrl2Cap と入力し実行
3）ctrl2cap /uninstall と入力し実行
4）再起動する
5）CapsLockキーとCtrlキーが元に戻っていることを確認する
【Ctrl2Cap v2.0のインストール】
1）Ctrl2Cap v2.0 をダウンロードする
http://technet.microsoft.com/ja-jp/sysinternals/bb897578%28en-us%29.aspx
2）Ctrl2Capフォルダを解凍する
3）解凍したCtrl2Capフォルダを、Ｃドライブの直下に置く
4）すべてのプログラム＞アクセサリ＞コマンドプロンプト（右クリックで管理者として実行）
5）cd￥（半角）Ctrl2Cap と入力し実行
6）ctrl2cap /install と入力し実行
7）再起動する
8）CapsLockキーとCtrlキーが入れ替わっていることを確認する
【Ctrl2Cap v2.0のアンインストール】
1）すべてのプログラム＞アクセサリ＞コマンドプロンプト（右クリックで管理者として実行）
2）cd￥（半角）Ctrl2Cap と入力し実行
3）ctrl2cap /uninstall と入力し実行
4）再起動する
5）CapsLockキーとCtrlキーが元に戻っていることを確認する
2010年11月8日月曜日
老人の生甲斐 ～可能になった「生産と供用」
老人はよくテレビを見る。一日中テレビをつけっ放しという人もいる。テレビを見ているだけで一日が終わってしまい、翌日もまたテレビを見ているだけ、なんていうのはよくあることだろう。そんな生活を想像したことが、老人の生甲斐を考えてみるきっかけになった。
私自身はどんなとき、自分に存在価値を認めるだろう。私は「人のために役に立てた」ときに自分の存在価値を感じる。では、私はどんなときに人の役に立てるだろう。キーワードは「生産と供用」である。モノやサービスを生産し、これを供用したときに、人の役に立てる。私たちは生きている以上、少なくとも何かを生産し、さらに供用して、人のために役立たなければならない。生産しただけではダメである。供用しなければ、少なくとも供用を試みなければ、人の役に立つことはできないからだ。
モノやサービスを生産して供用し、人のために役立つことで、自分の存在価値を感じられることが分かった。では、何を生産すればよいのか。それが最初の現実的な問題である。定年退職し「さて野菜でも作ろうか」と思っても土地がなければ作れない。鍬を作ろうにも道具がない。作ってもどうやって供用すればよいのだろう。従来もこれからも、老人（特に都会の老人）が有形のプロダクトを生産し供用することは困難である。ではどうすればよいのか。
従来と現在が異なるのは、デジタル技術の飛躍的な発達と、インターネットの普及である。われわれは土地を持たないが、パソコンとインターネットは手に入れた。無形プロダクト・無形サービスであれば土地や設備がなくても、パソコンで生産し、インターネットでいとも簡単に供用できる。無形プロダクトとは、例えば論文、写真、日記、ノウハウ、コンピュータプログラム、音楽といったものである。老人にとってこれらは従来も生産可能であったが、パソコンによって生産が容易になり、かつインターネットによって全世界を相手にタダ同然で供用できるようになった。
従来の老人は、生産と供用の手段を持たなかった。いまは違う。いまの老人は「生産と供用」の手段を持つ。これは大変な社会変革である。
老人は「野菜を作ろうにも土地がない」といういい訳を失った。老人は無形プロダクトを次々に生産して、インターネット上に供用しなければならない。これによって人の役に立たなければならない。もはや一日中テレビを見ている暇はないのである。
私自身はどんなとき、自分に存在価値を認めるだろう。私は「人のために役に立てた」ときに自分の存在価値を感じる。では、私はどんなときに人の役に立てるだろう。キーワードは「生産と供用」である。モノやサービスを生産し、これを供用したときに、人の役に立てる。私たちは生きている以上、少なくとも何かを生産し、さらに供用して、人のために役立たなければならない。生産しただけではダメである。供用しなければ、少なくとも供用を試みなければ、人の役に立つことはできないからだ。
モノやサービスを生産して供用し、人のために役立つことで、自分の存在価値を感じられることが分かった。では、何を生産すればよいのか。それが最初の現実的な問題である。定年退職し「さて野菜でも作ろうか」と思っても土地がなければ作れない。鍬を作ろうにも道具がない。作ってもどうやって供用すればよいのだろう。従来もこれからも、老人（特に都会の老人）が有形のプロダクトを生産し供用することは困難である。ではどうすればよいのか。
従来と現在が異なるのは、デジタル技術の飛躍的な発達と、インターネットの普及である。われわれは土地を持たないが、パソコンとインターネットは手に入れた。無形プロダクト・無形サービスであれば土地や設備がなくても、パソコンで生産し、インターネットでいとも簡単に供用できる。無形プロダクトとは、例えば論文、写真、日記、ノウハウ、コンピュータプログラム、音楽といったものである。老人にとってこれらは従来も生産可能であったが、パソコンによって生産が容易になり、かつインターネットによって全世界を相手にタダ同然で供用できるようになった。
従来の老人は、生産と供用の手段を持たなかった。いまは違う。いまの老人は「生産と供用」の手段を持つ。これは大変な社会変革である。
老人は「野菜を作ろうにも土地がない」といういい訳を失った。老人は無形プロダクトを次々に生産して、インターネット上に供用しなければならない。これによって人の役に立たなければならない。もはや一日中テレビを見ている暇はないのである。
2010年10月30日土曜日
2010年10月6日水曜日
Gmailのショートカット
＜ショートカット・キー＞
- 下の（古い）スレッドに移動： j
- 上の（新しい）スレッドに移動： k
- スレッドを開く： o
- スレッドリストに戻る（更新）： u
- スレッドを選択： x
- スレッドをすべて選択： *a
- スレッド選択をすべて解除： *n
- 既読にする： Shift i
- ショートカット一覧： Shift ?
- 未読メールを検索： is:unread in:inbox
- 自分が送信したメールからキーワードで検索： from:me <キーワード>
- mikeからの添付ファイル付きのメールだけ検索： from:mike has:attachment
- 2010/09/01以前に送信されたメールを検索： before:2010/09/01
2010年10月5日火曜日
License Free Original Music
- STORM by masanorimitake [MP3] [CD Quality]
- YOUNG by masanorimitake [MP3] [CD Quality]
- TRAVEL by masanorimitake [MP3] [CD Quality]
- ZURE by masanorimitake [MP3] [CD Quality]
- SOBER by masanorimitake [MP3] [CD Quality]
- FRIEND by masanorimitake [MP3] [CD Quality]
- IZUMO by masanorimitake [MP3] [CD Quality]
- DANCE7 by masanorimitake [MP3] [CD Quality]
*License Free Original Music
2010年7月7日水曜日
読書
2011/ パンセ（パスカル）
2011/ 織田信長3（山岡荘八）
2011/ 意識と本質（井筒俊彦）
2011/10 音楽の感動を科学する（福井一）
2011/09 文士の哲学（夏目漱石）
2011/09 織田信長2（山岡荘八）
2011/09 織田信長1（山岡荘八）
2011/08 プリズンホテル1夏（浅田次郎）
2011/08 こゝろ（夏目漱石）
2011/0８ ジャズ喫茶のオヤジはなぜ威張ってイいるのか（後藤雅洋）
2011/07 てくてく歩き琵琶湖・近江路
2011/07 ことりっぷ滋賀･琵琶湖
2011/05 赤穂浪士 上巻（大沸次郎）
2011/05 要件定義マニュアル（神崎善司）
2011/03 スベらない話し方（夏川立也）
2011/03 ミック・ジャガーの成功哲学（アラン・クレイソン）
2011/02 コーヒーとサンドイッチの法則（竹内正浩）
2011/01 モーツァルトを聴けば病気にならない! （和合治久）
2010/12 五年の梅（乙川優三郎）
2010/12 100歳までボケない101の方法（白澤卓二）
2010/12 プロフェッショナルCIOの教科書（甲斐莊正晃／桐谷恵介）
2010/11 三屋清左衛門残日録（藤沢周平）
2010/11 知恵の樹（ウンベルト・マトゥラーナ／フランシスコ・バレーラ）
2010/11 知的余生の方法（渡部昇一）
2010/10 官僚のレトリック（原 英史）
2010/10 実践データモデリング（真野 正）
2010/09 吉田松陰（2）（山岡荘八）
2010/09 吉田松陰（1）（山岡荘八）
2010/08 一生モノのジャズ名盤500（後藤雅洋）
2010/08 高杉晋作（3）（山岡荘八）
2010/08 高杉晋作（2）（山岡荘八）
2010/08 高杉晋作（1）（山岡荘八）
2010/08 眠狂四郎無頼控 一（柴田 錬三郎）
2010/07 ビジネスリーダーにITがマネジメントできるか（淀川高喜）
2010/07 アキラ（大友克洋）
2010/06 サービスで小さな奇跡を起こす方法（林田正光）
2010/06 風の谷のナウシカ（宮崎 駿）
（年月は読了時）
2011/ 織田信長3（山岡荘八）
2011/ 意識と本質（井筒俊彦）
2011/10 音楽の感動を科学する（福井一）
2011/09 文士の哲学（夏目漱石）
2011/09 織田信長2（山岡荘八）
2011/09 織田信長1（山岡荘八）
2011/08 プリズンホテル1夏（浅田次郎）
2011/08 こゝろ（夏目漱石）
2011/0８ ジャズ喫茶のオヤジはなぜ威張ってイいるのか（後藤雅洋）
2011/07 てくてく歩き琵琶湖・近江路
2011/07 ことりっぷ滋賀･琵琶湖
2011/07 ジャズ耳の鍛え方（後藤雅洋）
2011/07 ソース（マイク・マクナマス）
2011/06 「ほめる」技術（鈴木義幸）
2011/06 「やる気」のある自分に出会える本（笹氣健治）
2011/06 赤穂浪士 下巻（大沸次郎）
2011/05 赤穂浪士 上巻（大沸次郎）
2011/05 要件定義マニュアル（神崎善司）
2011/03 スベらない話し方（夏川立也）
2011/03 ミック・ジャガーの成功哲学（アラン・クレイソン）
2011/02 コーヒーとサンドイッチの法則（竹内正浩）
2011/01 モーツァルトを聴けば病気にならない! （和合治久）
2010/12 五年の梅（乙川優三郎）
2010/12 100歳までボケない101の方法（白澤卓二）
2010/12 プロフェッショナルCIOの教科書（甲斐莊正晃／桐谷恵介）
2010/11 三屋清左衛門残日録（藤沢周平）
2010/11 知恵の樹（ウンベルト・マトゥラーナ／フランシスコ・バレーラ）
2010/11 知的余生の方法（渡部昇一）
2010/10 官僚のレトリック（原 英史）
2010/10 実践データモデリング（真野 正）
2010/09 吉田松陰（2）（山岡荘八）
2010/09 吉田松陰（1）（山岡荘八）
2010/08 一生モノのジャズ名盤500（後藤雅洋）
2010/08 高杉晋作（3）（山岡荘八）
2010/08 高杉晋作（2）（山岡荘八）
2010/08 高杉晋作（1）（山岡荘八）
2010/08 眠狂四郎無頼控 一（柴田 錬三郎）
2010/07 ビジネスリーダーにITがマネジメントできるか（淀川高喜）
2010/07 アキラ（大友克洋）
2010/06 サービスで小さな奇跡を起こす方法（林田正光）
2010/06 風の谷のナウシカ（宮崎 駿）
（年月は読了時）
2010年5月25日火曜日
UNIXサーバー
①HP （Itanium9300番台）
②IBM （Power）
③Oracle・富士通（UltraSPARC/ SPARC64）
インテル（Itanium7300番台 → Xeon7500番台）
②IBM （Power）
③Oracle・富士通（UltraSPARC/ SPARC64）
インテル（Itanium7300番台 → Xeon7500番台）
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）
2010年2月19日金曜日
登録:
投稿 (Atom)