業務システム構築におけるデータモデリング

業務システム構築における
データモデリング
2018年4月12日
タワーズ・クエスト（株）和田省二

View Slide

目次
1.  データモデリングとは
2.  業務システム構築の考え方（従来の方法）
3.  業務システム構築の考え方（データモデリング）
4.  データモデリングの手順
5.  演習課題

View Slide

１．データモデリングとは
•  データ
•  データと情報の違い
•  データ格納方法（リレーショナルデータベースとファイルの違い）
•  モデリング
•  データを集合（En,ty）として捉える。
•  En,ty間を関連（Rela,onship）で結び付ける。
•  ＥＲ図（En,ty Rela,onship Diagram）にモデルとして表現する。

View Slide

　　１．１　「データ」と「情報」
「データ」
•  いつ、誰が、どの店で、何を、いくら、購入したという【事実】を表す。７W２H
　（ex. ある会員が、どの店で、ある商品を、何年月日時分、いくら、現金で買物した）
•  〇〇したという事実は一過性で二度と再現しない。（捉え損ねたら、捨ててしまったら、永遠
に事実【データ】を失う）
•  事実【データ】はそれ自体に意味はなく、記録として残しておくもの。

「情報」
•  「データ」を選択・加工して、当事者が必要とする知識（新たな価値）を取り出したもの。
　（ex. ここ数年の各月ごとの、ある商品の店別売上の推移）
•  情報の必要性と価値は、当事者によって、時期によって様々に変化する。
　（10年前には誰も思ってもいなかった情報を、今私は欲しい。
今誰も思い付いていない情報が、10年後には誰かが必要になるかもしれない。）
私達が欲しいのは役に立つ「情報」、そのために「データ」が必要！
「データ」は、貴重な「情報」を生み出す可能性を秘めた宝の山である！

View Slide

　　１．２　「データベース」と「ファイル」
リレーショナルデータベースファイル

データベース管理システム
個別のプログラムのアクセスを前提に（隷属して）存在する。
データベース管理システムによって統合管理され、多数のユー
ザから同時アクセス可能。ユーザにとって唯一無二の共有資源。

データベース

個別のプログラムのアクセスとは無関係に（独立して）存在する。

View Slide

　　１．３　システム構築の流れ
プロセス中心アプローチ（従来方法）

ある特定の問題解決（ソリューション）を最適
化する仕組としてシステムを設計する。
①外部設計
　問題解決のための出力、そのための入力を決める。

②内部設計
　①を基にその入出力に最適なデータベース（ファイル）　
設計を行う。

②モジュール設計
　入出力情報とファイル情報を結び付ける。
データモデリングアプローチ
システム化対象領域の実世界をデータの視点
からモデル化し、実世界の物事を表現する。
①論理データモデリング
　・実世界の物事を、モノ（Resource）とコト（Event）に
　分けてEn,tyとして抽出する。
　・ERD（En,ty Rela,onship Diagram）ツールにより
　En,tyを登録し、En,ty間をRela,onshipで関連付ける。
　・En,tyの正規化を図り、Rela,onshipを見直す。
　・これを繰り返す。

②物理ERD設計
　論理ERDにEn,tyの更新履歴を保持する仕組等、
　実世界とは関係ない項目とかEn,tyを追加する。
　

View Slide

　　１．４　システム構築の流れ（データモデリングアプローチ）
①　システム化対象領域の実世界をデータの視点からモデル化（見える化）する。【論理ERD作成】
②　それを基に実装向けの属性（カラム）とかEn,tyを加える。【物理ERD作成】
③　そこからDDLを出力してRDBを生成する。

システムをデータ貯蔵器（RDB）とし情報生成機（SQL）とする。
システム化
対象領域の
実世界
情
　
　
報
　

① 論理データモデリング
② 物理設計
ーー
論理
ERD
物理
ERD
ー
SQL
③
En,ty
Rela,onship
Diagram
システム
RDB

View Slide

　　１．５　ＥＲ図（En$ty Rela$onship Diagram）の一例

View Slide

　　１．６　論理ERD（En$ty Rela$onship Diagram）の役割・メリット
•  システムの全体を一望できる。（木も森も見られる）
•  表記法が定義されている図解なので見る者に依って解釈が分かれることがなく、
共通の正しい認識が得られる。
　（従来方法では、設計者の主観的意図が正しいかの判断が難しい。）
•  現実世界の物事をモデリングして（en,ty とRela,onship）に定着させるので、ERDの上で
現実世界をシミュレーションできる。
（モデルが現実世界を正しく表現できていれば、En,tyに蓄えられるデータは正しい。
　　そこから生成される情報はどれも正しい。）
　
•  ERDに定着させると、複数のEn,tyが関連とともに一度に見られるので、En,tyの正規化
が図り易くなる。

•  論理ERDの成果は、物理設計を経て、RDBの定義に洩れなく反映できる。

View Slide

２．業務システム構築の考え方（従来の方法）
　　２．１　システム化対象領域の様々な属性を集める
属性
異音同義
同音異義
異音同義

入力画面

入力帳票

出力画面

出力帳票

管理資料

異音同義
　　発注日付／注文日付
同音異義
　　同じ納品日付でも
　　（納入先への）／（仕入元からの）

View Slide

　　２．２　属性を処理単位にまとめる
〇〇〇
〇〇〇
〇〇〇〇
〇〇
〇〇
〇〇〇
〇〇
〇
〇
属性１
属性２
属性３
属性４
属性５
属性６
属性７
属性８
属性９

処理に使う属性を集めたファイルを設
計してしまう。
例）
●入力画面項目をそのままファイル属性として
持つ。
●出力項目の全てを１つのファイルにまとめて
持つ。
●このため一つの同じ属性（の値）が複数個所
に散在してしまう。

ある属性の値が更新されたら、その属
性を持つ全てのファイルを更新しなけ
ればならない。
●一部の更新を忘れるとシステムに不整合を
起こしてしまう。

View Slide

　　２．３　従来方法の問題点

•  問題解決の課題・仕様が、
正しく伝わらない。（間違って理解される）
開発途中で変わってくる。（初期に固まりきれない）
と、手戻りが発生する。
•  問題解決の課題のみを追求するあまり、課題外に潜む本質的に重要な考慮点を見落とす危
険がある。
•  データ構造の冗長性のために、更新不具合が発生するとシステムの信頼性を損ねる。
•  新たな問題解決が起きると、対応済みの問題解決部分にも修繕が必要になる場合があり、
後ろ向きな保守作業が続く。
•  保守のたびにデータベース、プログラムとも煩雑の度を加え、ますます保守作業を増やしてし
まう。

View Slide

３．業務システム構築の考え方（データモデリング）
　　３．１　システム化対象領域の様々な属性を集める
ドメイン
異音同義
同音異義
異音同義

入力画面

入力帳票

出力画面

出力帳票

管理資料

●異音同義ドメインをまとめる。
●同音異義ドメインを分解独立させる。
（名前というドメインでなく、教師氏名・学生氏
名・店舗名称・商品名称等に分けるべき。）

集合論・RDBでは属性のことをドメインと呼ぶ。

View Slide

３．業務システム構築の考え方（データモデリング）
　　３．２　ドメインをまとめてリレーション（集合）を定義する
〇
〇〇〇
〇
〇〇
〇
〇
〇
〇
〇
ドメイン１
ドメイン２
ドメイン３
ドメイン４
ドメイン５
ドメイン６
ドメイン７
ドメイン８
ドメイン９
ー
ー
ー
ー
ドメインの中には互いに密接な関係がある
もの同士がある。
（それらドメインを集めた集合のことをリレーション
と呼ぶ。）

データベースはリレーションの集まりとなる。
リレーション間には関連（rela,onship）があ
る。

ドメインはいずれか一つのリレーションに収
まり、複数のリレーションに収まることはな
い。
（リレーション間の関連のためのドメインを除く。）

この状態を
One Fact in One Place　と呼ぶ。

View Slide

４．データモデリングの手順
　　４．１　En$tyを抽出する（１）
システム化対象領域での現実世界の物事（モノとコト）（En,ty）とは

コトシステム化対象領域で本業（生業）として繰り返し為される行為（Event）
・6W2Hを属性に持つ。（特にWHEN【時点】は必須。）
・How much（数量、金額等）をもつことが多く、【期間】で集合演算される。
・システムはコト（Event）をデータとして逐一『記録』していく。

モノある【期間】存在し、コトに直接・間接に投入される資源（Resource）
・システムには発生【時点】に『登録』し、消滅【時点】まで存在する。
・モノは、ある【期間】一定の属性値を持ちながら状態遷移していく。
・【時点】を指定することにより、その時のモノの属性値を得る。

View Slide

４．１　En$tyを抽出する（２）
Event En,tyの抽出

•  現実世界のコトを表す。
•  キーは単一の伝票番号とかが通常。
•  En,ty数はそんなに多くないはず。
•  非キー属性には 6W2H の内のいくつかを持つ。
（起きたコトの事実を明確にするため。）
•  When（発生時点が必ずある）
（発生と計上を分けることもある）
•  What
•  Who（主体者）
•  Whom（主体者以外の関係者
to Whom, by Whom, with Whom等）
•  Where
•  Why
•  How to
•  How much（数量、単価、金額等）
Resource En,tyの抽出

•  現実世界のモノを表す。
•  キーは複合とか複雑な場合もある。
•  En,ty数はシステム化対象領域によって千差万
別。（システムの特徴を表す。）
•  非キー属性も多種多様。
•  モノを識別するための名称が必ずある。
•  発生時点と消滅時点を属性に持てば、モノの存
在期間を示しているのでResourceと言える。

•  Eventの When, How much 以外の6W2H属性に
外部参照先としてResourceのPK（またはAK）を
関連付けることが多い。
•  Resourceの二律背反性
（一過性vs反復性、概念的vs実体的等）

View Slide

　　４．２　En$tyのキー属性を見つける（１）
主キー（primary key　PKと略す）
行を一意にするためのキー。
主キーがないことは無い。（唯一無二を明示できなければそのEn,tyは集合ではない。）
主キーを宣言すると、それには一意制約とnot NULL制約が自動的に付される。
•  行を識別する属性を見つけて、主キーを付与する。
•  一つの属性だけでは一意にならない場合、複数の属性を組み合せて主キーにする。
　（複合キー：composite key）
•  主キー候補が複数見つかる場合、それらを候補キー（candidate　key）と呼び、その内の一つを
主キーとし、残りは代替キー（alternate key）となる。

代替キー（alternate key　AKと略すことが多い）
行を一意にするためのキー。（主キーと同等）
ボイスコッド正規形違反を免れるためには代替キーを付すのが便利。
代替キーには一意制約とnot NULL制約を付す。
（一意性を担保するだけで、代替キーにしないなら、not NULL 制約は無くても可。）

View Slide

　　４．２　En,tyのキー属性を見つける（２）
主キー（または代替キー）の持ち方に２つの方法がある。

•  自然キー（natural key）
集合を構成する属性の中から行を識別する属性を見つけて、キーとする。

•  代理キー（surrogate key）
システムに絶対にダブらない連続番号を発生させ、それを代わりにキーとする。
（En,tyが本来持っていない属性をシステムに追加することになる。） 
（アクセスログデータ等キーとすべき属性が無い場合に使う。）
•  互いを代替キーにすることは可能である。（代理キーをPK、自然キーをAKとする。または逆）

《注意》
•  論理データモデリングのフェーズでは、代理キーを許さないか無視する！！
（自然キーでないと、集合の正規化違反（特に高次正規化）は検証できない。）

View Slide

　　４．３　En,ty間に関連（Rela,onship）を付ける（１）
•  Rela,onshipは、参照する相手のPKまたはAKを取り込むこと。この取り込んだ相手側のキーを
FK（foreign key）と称する。
•  En,ty間にRela,onshipを付すことにより、外部参照制約を付すことになる。
相手側に存在しないPKまたはAKを取り込もうとすると外部参照制約の違反となる。
•  もし、外部参照制約を付さないで相手側に存在しないPKまたはAKを持つと、それを結合の
キーとしている場合、結合できなくて結合結果から漏れてしまう。
（気が付かないままだと、その行が迷子データとなる。）
•  それに気付くと、以後、疑心暗鬼に陥って外部結合しか使わないという本末転倒なことになる。
•  システムの信頼性を確保するために、外部参照制約を担保として利用すべき。
ERDでRela,onshipを示す線には意味がある。
•  向き（どちらが出発点か。親エンティティ・子エンティティを表す）
•  種類（実線は親のPKが子のPKに入るため子の存在は親に依存する。点線は非依存を表す。）
•  始点側のマーク、終点側に付く z とか p とかの記号（cardinality：多重度と言う）

View Slide

　　４．３　En,ty間に関連（Rela,onship）を付ける（２）
特殊な関連

•  親子関連
・子は親のPKを自分のPKに含める。子の存在は親に依存する。（子がない親もない。）
・第１正規形（繰り返し属性の排除）のため、その部分を独立させることにより生まれる。
•  交差関連
・複数（主に２つ）の他En,tyのPKを組み合せた複合キーをPKとする。
・組合せの制約を表す。（それぞれ一方から見れば、他方は重複を許さない子を表す。）
・３つ以上の組合せの複合キーは、第４正規形違反および第５正規形違反に注意する。

•  スーパー/サブ関連
・親（スーパー）が複数のそれぞれ属性構成が異なる子（サブ）を持つ。
・子（サブ）の間は、排他か共存可能かのどちらかである。

View Slide

　　４．４　En,tyの正規化違反チェック
•  繰り返し属性の排除
En,tyが持つ属性は全て異ならなければならない。（第１正規形違反）

•  関数従属性に関する正規化違反
非キー属性の中に、複合キーの一部にだけ従属する属性がある。（第２正規形違反）
非キー属性の中に、他の非キー属性に従属する属性がある。（第３正規形違反）
複合キー属性の中に、非キー属性に従属する属性がある。（ボイスコッド正規形違反）

これ以上高次は、複合キーのみ（非キー属性が一つもない）の属性のEn,tyだけに起こり得る。
•  結合従属性（多値従属性）に関する正規化違反
複合キーで、１つのキーとそれ以外の組合せもキーになる。（第４正規形違反）
複合キーで、任意の複数の組合せもキーになる。（第５正規形違反）
第６正規形違反もあるが、違反があっても実害はない。

第１から第３正規形違反は、違反部分をEn,tyから分離独立させないと解決しない。
ボイスコッド正規形違反以上は、分離独立させるか代替キーを付す。

View Slide

第１正規形

View Slide

第２正規形

View Slide

第３正規形

View Slide

ボイスコッド正規形

View Slide

５．演習課題
　　５．１　居酒屋の売上管理
　 step1　単品料理（酒も含む）の売上管理のみ
（コース料理なし、個室なし、予約受付不可）
step2　step1＋コース料理あり。コース料理と単品料理の
売上を別管理
（個室なし、予約受付不可）
step3　step2＋個室あり＋コース料理と個室の予約が可能
（単品料理と座席の予約は不可）
（個室は予約でない場合も、その利用を把握する。）

View Slide

５．演習課題
　　５．２　ハウスクリーニング業の売上管理 

•  複数の業者スタッフが顧客の自宅を訪問する。
•  サービスを受けたい者は事前に顧客登録しておかなければならない。
•  サービス内容はサービスメニューに登録されている。
•  サービスメニューには時間単価が登録されており、派遣されたスタッフがそ
のサービスに要した時間にその単価を掛け合わせて売上明細金額となる。
•  訪問時には、複数のスタッフが複数のサービスをこなすので、それらの合計
金額が売上合計金額となる。
•  売上金額は、業者が毎月末に顧客ごとの売上金額を集計し、明細付の請
求書を顧客に送付して、顧客指定のクレジットカードで決済する。
•  予約機能を追加したい。（スタッフの指名はできない。）

View Slide

業務システム構築におけるデータモデリング

業務システム構築におけるデータモデリング

Recruit Technologies

More Decks by Recruit Technologies

Other Decks in Technology

Featured

Transcript