■ 2/3 10:00-11:00 【DB】データモデルは作るだけでいいのか？
●[プレゼンター]株式会社メタジトリー 取締役 JEMUG(Japan Enterprise
Modeling ユーザー会) 会長 松本聰
●[説明] DBマガジン誌などでは、データモデルの作り方に焦点が当たっています
が、作ることと同時に、そのモデルを管理し、拡張していく必要があります。本
セッションでは作りのイロハから管理、拡張のイロハについて説明します。
●[話を聞いてみて]
プレゼンターの松本さんは石油化学会社の情報システム部門で長年環境構築や標準化などされていた方です。
著書「IDEF1X」日経BP社など。うーん、誰かに似ているとずっと考えていましたが思い出せません（笑）
Zachmanのフレームワーク、EA(エンタープライズアーキテクチャー)、要求工
学、IDEF1Xなど、普段聞きなれていない用語で頭が活性化されただけでもかなり
有意義なセッションでした。しかし、論理モデルから物理モデルへどのように落
とし込むのか？あるいは、資源の再利用のために物理システムを論理モデルにど
のように再変換していくのか？こういったことは実務で自分が実際その立場に
なった時に手足を使って覚えていくものだと思う。そんなときにまたこのメモを
読んで思い出せたら随分と違うだろう。
●[セッション記録]
「企業内SEの人は論理モデルの所まで考えられないと、うまくいかないですよ。
それが企業内SEの役割である」
データモデルのエンティティ名は業務の用語で付ける。
「○○マスター」「○○トラン」というように、意味もよく分からずにマスターとか
トランとか付けるのは止めようね。
（注：しかし一般的にはマスターは日常の商取引では変更の無い、得意先の名称や勤
務地などを格納する。トラン（トランザクションの略）には、例えば酒屋なら
「ビールが3ケース」といったように頻繁に発生するデータを格納するのでもう
常識になっている部分もある)
「マスター」「トラン」という名前を付けただけで安心していないだろうか？
モデリングはビジネスがあって初めてできるものだ。基本は業務を理解すること。
モデルを図示する際、エンティティ間の関係を動詞句を使って正確に記述すること。
属性とはエンティティ個々が持つ特性である。
属性をただ単に「ID」「住所」「氏名」などと付けるのは止めよう。具体的に
「顧客_ID」「顧客住所」「顧客名」というように書くこと。
概念データモデルとは情報のあり方を自然に表したモデルである。
論理データモデルとはビジネスのあり方を適切に表したモデルである。ビジネス
ルールを正確に表現したもの。実装は念頭に置いていない。
物理データモデルとはコンピュータの制約を加えたモデルである。（SQL文とか
考える部分）コンピュータへの実装を前提にしたもの。
「物理モデルで論理モデルを壊してはいけない。そのかわりプロシージャで実装
してください。」
「実装とは物理モデルを考え、システム構築をすることだ。
構築担当者は物理モデルしか意識していない。
多くの教科書は論理モデルと物理モデルの定義が曖昧であり、
これが大きな問題となってしまうのだ。
技術は常に変遷する。
その変遷する技術と不可分な設計も技術と一心同体となってしまい、
結果として短命なシステムとなってしまうのだ。
維持管理の基本は論理モデルである。
論理モデルは再利用できるが物理モデルは再利用できない。
再構築をやめて維持構築をするべきである。
例えば石油化学工場のプラントも社内システムも資産である。
プラントは長期にわたって維持管理され使われ続けるのに対して、
情報システムが「再構築」という名の元に使い捨てられるのはおかしいのではな
いだろうか。
この問いに対するソリューションとして、
Zachmanのフレームワークを基礎としたEA(エンタープライズアーキテクチャー)
があるといえる。
ちなみにZachmanのフレームワークにはノーマル版と簡易版がある。
情報システムに関する費用がどの部門に対してどのように使用されているかと
いったポートフォリオ分析も重要である。」
国内でなぜ維持・管理が根付かないか？
作りっぱなしのSIerのせいだろうか、円投げのユーザー企業のせいだろうか？
そんなことよりも対策として、
ユーザーは論理に特化し、物理に手を出さないなどの基本ポリシーが必要である。
概念、論理、物理それぞれを考える担当者が同一人物であるというケースをよく
見るがそもそもこれもおかしな話なのだ。
せめて、「概念・論理」（社内SE）と「物理」（SIベンダー）の担当者を別に置
くべきである。
●[参考資料]
用語「IDEF1X」とは
http://www.jmac.co.jp/tch/mng_f_k.html
ＩＤＥＦ１Ｘは、データモデルとも呼ばれ、あらゆる情報の構造を、実体（物
体・人・場所・概念・事象などを含む）と実体が本来的に持つ属性（材質・性
別・住所・役割・時間等）、および実体と実体の関連として捉え、ボックスと線
を用いて記述する方法である。
情報の構造を概念的なレベルから、データベースアプリケーションの詳細設計
に必要なレベルまで、連続的、段階的に分析、記述できるところが特徴である。
用語「EA」とは
http://www.atmarkit.co.jp/aig/04biz/ea.html
「企業や政府機関・自治体などの組織（enterprise）の構造と機能をある一定の
考え方・方法で包括的に体系化・記述し、
全体と構成要素の相互関係を明らかにし、
その構造の背景にある基本理念・設計思想を含めて企業活動の全体最適を実現す
るアーキテクチャモデルを設定し、
そのあるべきモデル（To Be）を目指して、長期的かつ体系的に行われる企業活
動のこと。」
「データモデルとは」その１
http://www.jsys-products.com/iwaken/data_model_patterns.html
データモデルとは、
企業において重要となる「モノ」と、
それらの「関連」をモデル化したものです。
一般に、
ERモデルと呼ばれるものがこれに当たります。
データモデルを構築することで
複雑な企業構造は単純化され、
理解しやすいものとなります。
（略）
データベース構築のおおまかな指針として用いることもできます。
「データモデルとは」その２
http://www.doaplus.com/html/s13_007.html
データモデルとは、
データ構造、
データ仕様を把握する
枠組み
型
パターン
と言う意味で用いられていますが、
２つの使われ方があります。
ひとつは「Ａ社の販売システムのデータモデル」、「Ｂ社の生産管理システムの
データモデル」
といったデータモデル個体に、
もうひとつは「ＥＲモデル」、「ＴＨモデル」
といったデータモデルの種別を表すものに、です。
ＥＲ図とは
ＥＲ図とは、エンティティ(システム化対象業務において管理すべき実体)とリ
レーションシップ(1:nなどエンティティ間の関連)を図示する図法である。
正確なＥＲ図ができると，データの正規化が容易にできる。
エンティティとは
http://www.kogures.com/hitoshi/webtext/db-ermodel/index.html
エンティティ(Entity)とは，
システム化対象業務において
管理すべき実体です。
データの正規化とは
http://www.kogures.com/hitoshi/webtext/db-seikika/index.html
データの正規化とは、
データの重複をなくすことにより、
データの管理を容易にしたり、
データを多様な目的に用いるのに有効な方法で、
データベースの構築の基本になる技法です。
第１正規化，第２正規化，第３正規化と3段階に分けて行います。
第１正規化とは
http://www.kogures.com/hitoshi/webtext/db-seikika/index.html
第１正規化とは
繰り返しの部分を複数のレコードにして，
繰り返しを排除する操作です。
第１正規化をした結果を
第１正規形といいます。
第２正規化とは
第２正規化とは，部分関数従属する(主キーの一部に従属する)項目を分離するこ
とです。
その結果のファイルを第２正規形といいます。
第３正規化とは
第３正規化とは，
主キー以外のキーに関数従属
(得意先コードが定まると得意先名が定まるというように，
ある項目が定まると他の項目が定まるという関係)
する項目を分離することです。
