【IT関連記事】概念データモデルのエンティティとカーディナリティを理解する

今回は、すこし趣向を変えて概念データモデルについて

記事を書いていきます。

かなりニッチな記事になるかもです・・・

今回の記事はあくまでも私の持論・やり方です。
意見はあるとは思いますが、我慢してください。笑



概念データモデルについて

仕事上、私は概念データモデルやER図、クラス図など、様々なモデルを描いています。それぞれ紹介したいのですが、今回は、私の一番好きな概念データモデルについてです。ちなみにTMモデルです。THモデルはかけません。。笑

概念データモデルとは

概念データモデルとは、業務に必要なデータとそれらの関連・関係を洗い出し、まとめたものであり、データの全体像を示し、システムの全容を見通す為に作成するデータモデルの事です。私は、システム全体像だけでなく、運用の全容も明らかにする開発における最大の成果物と考えています。

データベーススペシャリスト試験の午後Ⅱの問題としても有名ですよね。

概念データモデルを書いてみる

エンティティの種類は?

私はTMモデルをTER-MINE、astahかのどちらかで描いています。今回はTER-MINEで説明していきたいと思います。

まず、エンティティには、下記の図のように必ず2種類に別れます。

エンティティの種類
  • イベント
  • リソース

です。

エンティティを分ける判断

そして、分ける基準となる判断は、

エンティティに日付が帰属するものは、すべてイベント。そして、

イベント以外のすべてがリソースです。

この考え方はとても重要です。リソースなのに日付が帰属しているデータモデルをたまに見かけますが、それではエンティティ本質がぶれてしまいます。

下記の図をご覧ください。

リソース、イベント具体例

施設予約というイベントには日付が帰属しますよね。いつ施設を予約したかという事実が記録されるエンティティです。完全にイベントですよね。

そして、施設という日付の概念がないエンティティ、コレがリソースです。

○○するという言葉を当てはめてみるとわかりやすいですね。「施設予約する」という言葉は、しっくりきますが、「施設する」という言葉は通じません。

この判断でミスをすると後工程のERにも響いています。気をつけましょう。

エンティティ同士の関係

データモデルは必ず各エンティティ同士に関係を持っています。

下の図を見て頂くとわかりますが、先行イベントと後続イベントというエンティティがあり、線で繋がれていますね。コレが関係です。この線(関係)をカーディナリティといいます。

イベントの関係

そして、後続イベントのエンティティには、先行イベントの認知番号をもつことで、先行イベントの次は、後続イベントが発生するということがわかりますね。

もう少しイメージしやすくするために、下の図を作ってみました。

施設利用例モデル1

具体的なイベントです。施設予約と施設利用というイベントがあり、その間に関係があります。

「施設予約をしたあとは、施設利用がある」ということがこのモデルでは読み取れますね。そしてカーディナリティに注目です。施設利用エンティティ側カーディナリティに0が付いていますね。施設予約はあるが、施設利用がなかったという場合があるということです。

つまり、これは、キャンセルした場合を表現しています。

必ず後続イベントができるんだ!という場合は、完全な1:1にすればよいですね。

リソースを絡めるとこんな感じ

先ほど作ったモデルにリソースを加えてみましょう。

施設予約イベントだけでは、どこの施設で予約がされたかわかりません。ということで、施設エンティティ(リソース)を追加しました。

下図のような感じです。

施設利用例モデル2

施設予約エンティティには、施設エンティティより施設コードという属性が追加されました。これによって、どこの施設で施設予約があったかが記録されるようになりました。

ここで質問。施設利用エンティティには、施設エンティティとの関係いらないの?

予約した施設が、変更されずそのまま利用される場合は、先行イベントの施設を参照するので、施設利用側に施設利用エンティティとの関係はいらないですよね。

逆に予約した施設が、変更され、別の施設を利用する場合がある時は、施設利用側にどの施設を利用したかを記録しないといけないので、下記のようにどちらにも施設エンティティと関係をもたせます。下の図のような感じです。

両エンティティに関係を

モデルを描く上でこのカーディナリティは、とても重要です。このカーディナリティを間違えると後工程で大変な目に遇います。笑

最終的なデータでき方が全然違ってきますからね。

まとめ

このように箱と線(言い方わるいですが・・笑)で運用のすべてを語ることができます。そしてモデル描く側はしっかりとそれを理解して描く必要があります。
モデルは、言語です。そして、言語であれば、語り手と、聞き手の存在がいて成り立ちます。
最も重要なのはそれがしっかり伝わることです。

今回は、初めてデータモデルの記事を書きました。
次回はいつになるかわかりませんが、まだまだ書きたいことはあるので書いていきたいと思っています。次回は、バーチャルエンティティ(VE)、対照表、対応表辺りをを書きます。

著者プロフィール

pandaman
30歳の二人の子持ちで、職業はSEです。
1年間スマホ記事のゲームライターをしていました。
企業内システムエンジニアで、主にモデル設計を担当。
(TMモデル・ERモデル)当サイトについては、ネタ記事、本格ゲーム攻略、子供向けアニメ・・様々なジャンルの記事を書いています。
Pocket

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

ABOUTこの記事をかいた人

30歳の二人の子持ちで、職業はSEです。 1年間スマホ記事のゲームライターをしていました。 企業内システムエンジニアで、主にモデル設計を担当。 (TMモデル・ERモデル)当サイトについては、ネタ記事、本格ゲーム攻略、子供向けアニメ・・様々なジャンルの記事を書いています。