(０)目次＆概説
(１) 項目を洗い出す
(１-１) 現行システムが存在する場合
(１-２) 新規システムを開発する場合
(２) エンティティを定義する
(２-１) エンティティの作成
(２-２) エンティティの分類
(３) リレーションを定義する(その１)
(３-１) リレーションの”依存型”と”非依存型”
(３-２) リレーションの”カーディナリティ”
(４) リレーションを定義する(その２)
(４-１) 「リソース型」対「リソース型」
(４-２) 「リソース型」対「イベント型」
(４-３) 「イベント型」対「イベント型」
本記事ではシステム開発におけるデータモデリングの手法を解説します。データモデルを作成する事で、お客様の業務を把握する事が出来、その整合性が正しいか検証したり、不明瞭な点を明確に可視化出来る点が非常に有益です。今回は実際の例題を見ながら、モデリングの手順を確認していきます。
以下の(a)～(d)は例題の画面です。想定としてはネットショッピング等のシステムで、管理者がシステム上に商品を登録したり、顧客が商品に対してレビューや口コミのコメントを掲載する事が出来ると思いますが、そういった処理の画面をイメージしています。
(a)ログイン画面
(b)商品リスト画面
(c)商品登録画面
(d)”お客様の声”一覧画面
(１) 項目を洗い出す
(１-１) 現行システムが存在する場合
現行システムの画面や帳票の項目を一通り抽出し、”主キー候補”の項目と”それ以外”の項目とに分ける。例題の画面について行うと以下の様になります。
(１-２) 新規システムを開発する場合
実際のユーザにシステムの利用方法を確認し、そのインプットをベースに要件を定義する。
今回の例題では実際に現行システムの画面が閲覧できる想定でのモデリングになりますので、上記(１-１)のパターンになります。
＞目次にもどる
(２) エンティティを定義する
(２-１) エンティティの作成
上記(１-１)で項目を洗い出した結果について、”主キー候補”の項目をエンティティをして切り出します。例題の画面について行うと以下の様になります。
(２-２) エンティティの分類
エンティティを系統別に分類します(リソース系／イベント系／サマリー系)。
例題で掲載しているER図は”astah professional”を用いて描画されており、エンティティを系統別に色分け可能で”Resource”系のエンティティはピンク色に、”Event”系のエンティティは黄色に色付けされます。
・リソース系
マスターテーブルとして管理される類いの情報。
例えば「顧客・商品・部門」など。
基本的には参照(SELECT)される事が多く、更新(INSERT/UPDATE)される事は少ない。
・イベント系
定期的に発生するトランザクション等のテーブルとして管理される類いの情報。
例えば「受注・貸出・請求」など「～日」等の属性を持ち、日次や月次等で起こる業務処理。
基本的には更新(INSERT/UPDATE)が多く発生する。
上記(２-１)で作成したエンティティを色分けすると下記の様になります。「会員」と「商品」はリソース系で「コメント」はイベント系です。
＞目次にもどる
(３) リレーションを定義する
(３-１) リレーションの”依存型”と”非依存型”
“依存型”
親エンティティが存在しないと、子エンティティが存在出来ない場合は”依存型”のリレーションになります。”依存型”の場合は、親エンティティの「主キー」が子エンティティに於いても「主キー」となります。
“非依存型”
親エンティティが存在しなくても、独立して存在できる場合は”非依存型”のリレーションになります。”非依存型”の場合は、親エンティティの「主キー」は子エンティティに於けて「外部キー」となります。
例えば「受注」と「受注明細」はヘッダとボティ(ディティール)の関係にあり、「受注」が存在しないと「受注明細」は存在し得ない為、”依存型”の関係になります。
一方で「顧客」と「商品」は”非依存型”の関係です。「顧客」が存在しなくても「商品」は存在できますし、その逆も成り立つためです。
(３-２) リレーションの”カーディナリティ”
エンティティ間でリレーションを張る際に「何対何」で対応しているのか？を表す言葉。
具体的には「１対１」「１対多」「多対多」などがあります。
上記を踏まえ(２-１)で分類したエンティティにリレーションを定義すると、以下のようになります。
「会員」対「コメント」は「1対0以上」です。
会員でも1回もコメントした事がないメンバーも居ますし、複数回の発言をしているメンバーも居るためです。逆にコメントから見ると必ず会員が紐づくので、会員側は「1」(親は必須)になります。
加えて「会員」と「コメント」は「ヘッダーとボディの関係」では無いため、「非依存型」のリレーションを定義します。
「商品」対「コメント」も「1対0以上」です。
商品に対して1件もコメントが付かない事もありますし、商品に複数のコメントが付くこともあるためです。逆にコメントから見ると必ず商品が紐づくので、商品側は「1」(親は必須)になります。
加えて「商品」と「コメント」は「ヘッダーとボディの関係」では無いため、「非依存型」のリレーションを定義します。
(４) リレーションを定義する(その２)
上記(３)の内容に加えて、エンティティが「リソース型」なのか「イベント型」かによってもリレーションの定義の仕方が変わってくるため、(４) ではそのパターンについて確認します。
(４-１) 「リソース型」対「リソース型」
「リソース型」対「リソース型」に対してリレーションを定義する際は「対照表」を作成します。「対照表」とは両方のエンティティの主キーを複合キーとして持つエンティティの呼称です。
今回の例題の画面はこの(４-１)のパターンに該当するため、上記(３-１)(３-２)でリレーション定義した状態で、更に対照表を追加すると下図のようになります。
(４-２) 「リソース型」対「イベント型」
「リソース型」対「イベント型」に対してリレーションを定義する際は”非依存型”のリレーションを定義します。
これは例題の(３)で定義している「会員」対「コメント」や「商品」対「コメント」の間のリレーションと同じです。
(４-３) 「イベント型」対「イベント型」
(４-３-①)「1対1」や「1対N」の場合
“非依存型”のリレーションを定義します。
(４-３-②)「N対1」や「N対N」の場合
両エンティティの主キーを複合キーとして持つ新規エンティテ(「対応表」)を間に作成します。
下記の例では、部下の申請に対して上司が承認するシーンを表現しています。「申請」と「承認」(共に”イベント”エンティティ)は「1対N」の関係にあるため、対応表で結ぶことを考えます。
「申請」と「対応表」は「1対『0または1』」です。場合によっては申請中で承認が下りていない状態もあるため『0または1』となります。
「承認」と「対応表」は「1対1以上」です。複数の申請を纏めて承認する事もあれば、1つの申請のみを単体で承認するケースもあるためです。
