Data Centric Art Gallery Banner
一つ前のページへ次のコラムへ

【誰でも描けるERD】-エンティティと関連
DOA Evangelist:小見山 昌雄


 エンティティ・リレーションシップ・ダイアグラム(以下、ER図)をトップダウンアプローチで描くには、先ず、描こうとするビジネスルールが明らかになっていなければなりません。
 例えば、「このビジネスには『顧客』と言うビジネス要素が存在する」と言う具合です。
 このビジネスには、わが社の商品を買ってくれる存在があるらしいけど、それは一体何と言う存在だったっけ、取引先だっけなあ、お客っていったっけなどと言う不明確な状況では、もちろんER図は描けません。
 そのような状態であれば、先ずは分析的アプローチによる状況把握が必要となりますが、ここでは、既にビジネスルールは明確で、それを如何にER図に表現するかについて説明を進めて行きます。
 と、言う訳で、前述のビジネスルールは「顧客」と言うビジネス要素が存在する事を説明しているので、ER図では以下の表現になります。
 この四角で囲ってあるものをER図では「エンティティ」と呼び、何らかの認識を表わします。
 広辞苑(第4版)・1991年11月15日発行・株式会社岩波書店発行・新村出編で引くと、【認識】とは、
(1)〔哲〕〔cognitionイギリス・Erkenntnisドイツ〕知識とほぼ同じ意味。知識が主として知り得た成果を指すのに対して、認識は知る作用及び成果の両者を指すことが多い。
(2)物事を見定め、その意味を理解すること。
 とあります。
 つまり、ER図上に「顧客」エンティティを描くと言うことは「このビジネスには『顧客』と言うビジネス要素が存在する」と私は認めましたよと言う事を表わします。
 つまり、ビジネスルールを文章で表現するか、図で表現するかと言う、表現のしかたに違いこそあれ、ビジネスルールとER図は同じことを表現しています。
 重要なことなので、念を押しておきますが、ER図はビジネスルールをそのまま表現するもので、ビジネスルールの概要や概略や感じや周辺や似たものを描いているわけではありません。
 この調子で、ER図で表現しようとするビジネスの中からエンティティを挙げていきます。
 「顧客」・「商品」・「社員」・「取引先」・「支店」・「工場」・「会員」・「部品」など、ビジネスの中には幾つかのエンティティが有りますが、同じ表記で図に表わすことで、それぞれ「このビジネスには〜と言うビジネス要素が存在する」と私は認識していますと言うことを表現することが出来ます。
 なお、エンティティを四角形で表現する描き方が一般的なので、このコラムでもエンティティを四角形で描いていますが、技法やツールの制限などがあれば、四角形に固執する必要もないと思います。


 さて、ビジネスを構成する要素をエンティティとして認識し、ER図上に表現する方法は説明しましたが、それらのエンティティが単に存在しているだけではビジネスは成り立ちません。
 商品を倉庫に積んで眺めているだけでは、単なる収集家です。
 商品を、お客さんに売らなければ話になりません。
 と言う訳で、エンティティが関連付けられ、ビジネス活動が起こります。
 例えば「顧客」と「商品」が関連付いて、「顧客から商品の注文を受注する」と言うビジネスルールを想定するとER図では以下の表現となります。
 この「顧客」と「商品」の間を結ぶ直線(ER図では線で結べば関連を表わすので、曲線でも折れ線でも問題ありません)が関連で「顧客」と「商品」の間に関係があることを表わします。
 また直線の上に書かれている「受注する」は関連名と言い、線が表わしている関連を説明しています。
 では、他にも幾つか例を挙げておきましょう。
 「部署」こ[従業員]が「所属する」・「顧客」が「銀行」に「入金する」・「商品」を「倉庫」い「入庫する」などのビジネスルールを表現するER図を描いて見ました。
 なかなかもっともらしいでしょう。 エンティティ間の関連と関連名がしっくり来ていると思います。
 当たり前です。
 もっともらしく差しさわりの無いビジネスルールを選んで描いたので、もっともらしいのは当然です。
 実は、この関連名は、上の例ではもっともらしいのですが、ある状況では意味がなくなります。
 


 ここで、一休みしてER図に関わる、呼称を整理しておきます。
 今回のコラムのタイトルからして不自然だと思われた方がいらしゃるかと思います。
 確かに、エンティティと言ったら、リレーションシップと受けるのが自然の様な気もします。
 エンティティについては、辞書で引くと『(実在する)物・(他から独立した)存在(物)・独立体とか、(属性に対して)本質, 実体』(『』内はgoo辞書より引用し要約)となっていますが、エンティティ以外の呼称を使う人は居ない(と思う)ので、安心して「エンティティ」と言って下さい。
 関連の方は、「リレーションシップ」・「リレーション」・「関連」・「関係」などと様々な呼称が使われます。
 上で関連名と説明しているものは、それぞれ「リレーションシップ名」・「リレーション名」・「関連名」・「関係名」と対応付けて呼ばれることになります。
 このように、同じ概念に複数の名称を割り当てることは、理解を阻み、議論を混乱させる効果的手段の一つです。
 データの一元管理が重要な所以です。
 私自身は「関連」と表現することが一番多いので、コラムのタイトルを「エンティティと関連」としていますが、表現による意味の違いは聞いたことが無いので、好きな呼び方をして頂いて構わないと思います。
 「君、それはリレーションシップと呼びたまえ」と言う先生が居らっしゃる場合、少なくともその御前では、ご指示に従う様にしましょう。
 また、ER図も「ERD」・「データモデル」・「ビジネスモデル」などと様々呼ばれますが、エンティティとリレーションシップで表現しているので「ERD」、データの構造や関連を表現しているので「データモデル」、ビジネスを表現しているので「ビジネスモデル」など、描き方や対象を見る視点の違いで呼称が変化しているだけで、呼称の違いで使い方や描き方の本質的な違いはないので好きな呼び方を使いましょう。
 但し、呼称を選んだら、一連の話や文章の中では、同じ表現で通さないと、何か意味があって使い分けているのかと、無用な誤解が生じます。
 また、企業やプロジェクトなどでも、表現を統一しておいた方が良いでしょう。
 それでは、続いて関連名の限界を見てみましょう。


 さて、前々章では、関連と関連名がしっくりくる例だけを挙げたので、ここではしっくり来ない例を挙げます。
 「部署」こ従業員を「配属する」・「顧客」が「銀行」に「入金する」・「商品」を「倉庫」い「入庫する」などのビジネスルールの関連部分をエンティティとして表現すると、たちまち関連名が間抜けな感じになってしまいます。
 これは、前図で関連として表現していたものをエンティティとして表現したので、新しく設定したエンティティと前からあるエンティティを結ぶ関連に、前図のように関連名を付ける意味が無くなったためです。
 それに無理やり関連名を付けると「する」とか「ある」とか、間の抜けた表現になってしまいます。
 このように、関連名として表現されていた行為や役割をエンティティで表現すると、関連自体には意味が無くなるので、名前も無くなるのです。
 意味の無いものを書く必要は無いので、このようなケースでは、無理に関連名を書く必要はありません。
 しかし、関連名に意味が無くなっても、関連自体は存在します。
 それは、「配属と言う行為は従業員(誰-Who)を部署(何処-Where)に配置すること」と言うビジネスルール、つまり行為と、それを発生させる元になるエンティティの関連を表わします。
 同様に「顧客(誰-Who)が銀行(何処-Where)にお金を預けることを入金と言う」・「商品(何-What)を倉庫(何処-Whereに納めることを入庫と言う」となります。
 つまり、関連部分を行為・出来事を表わすエンティティとしてER図を描くと、関連は、その行為・出来事に関与する4W、即ち5W(Who-誰が・What−何を・When-いつ・Where-どこで・Why-どうして)からWhenを除いた(通常、Whenの情報は、配属日・入金日・入庫日などのデータとして、行為・出来事を表わすエンティティ自体がアトリビュートとして持ちます)残りのWの関連を表わしています。(とは言え、Wkyについても、キャンセル・返品に対する返品理由コードの関連付けなどがありますが、通常、行為・出来事に理由や動機を関連付けることは、極まれにしか行われません。)
 配属に対し、部署への関連は、どこへ配属するかを表わし、従業員への関連は誰を配属するかを表わしています。
 同様に、入金に対して、顧客への関連は、誰が入金するか、銀行への関連はどこへ入金するかを表わし、入庫に対しては、商品との関連は、何を入庫するか、倉庫への関連はどこへ入庫するかを表わすと言う調子です。
 この状況で、関連に「どこへ」・「だれが」などと関連名を付けても、やはり意味がないことに変わりはないので、関連部分を行為・出来事を表わすエンティティとしてER図を描く場合には、関連名を無理に書いても混乱するだけなので、無理に書く必要はありません。



 2節と4節で、行為・出来事を関連として表現する場合とエンティティとして表現する場合の違いを、主に関連名の妥当性で説明しましたが、表現の仕方が二通りあると言うことなら、この使い分けを明らかにしなければなりません。
 例えば、部署と従業員が関連すれば、そこで、いつ配属になった・どこに配属になった・どういう担当で配属になった・肩書は何になった、などと言う事を記録しなければなりません。
 その記録は、部署と従業員の関連の記録なので、部署や従業員の情報として記録することは、情報の単位が違うので出来ません。(部署の情報は部署単位、従業員の情報は従業員単位に記録しますが、部署と従業員の関連に関する情報は、当然、部署・従業員の単位で記録することになります⇒システム的に表現すると部署は部署コード別、従業員は従業員コード別だが、部署と従業員の関連に関する情報は部署コードと従業員コードの複合キー単位に記録すると言うことです)
 そのため、部署と従業員の関連を記録するための新しいエンティティが必ず必要になります。
 逆に言うと、書いて意味のある関連名を持つ関連があれば、それは検討途上の概要ER図で、詳細なビジネスモデルとして仕上がった段階では、書いて意味のある関連名を持つ関連は無くなっているはずです。
 もちろん、ザーと概要を把握するために、取りあえず概略をER図で描くこともあります。
 そのような場合に「顧客」と「銀行」に線が引かれていても、「入金」なのか「借金」なのか、「出金」なのか、「口座開設」なのか判断が付きません。
 そのような場合は「私は顧客と銀行の間に入金すると言う関連を認識して線を引きました」と言うことが分かるように、「入金する」と関連名を入れる必要があります。
 要は、必要に応じた使い分けなので、目的と表現レベルに応じて適切な対応をして下さい。
 ちなみに、通常、私たちが作るER図は、データベースの実装を目的に含み、ボトムアップでデータ分析をし、関連は全てエンティティとするので、関連名は一切書きません。
 ここで、エンティティには、エンティティの組み合わせで新しく作られるものと、その組み合わせの元になるものの二種類存在することがお分かりかと思います。


 元からあるエンティティは、先に例としてご紹介した「顧客」・「商品」・「社員」・「取引先」・「支店」・「工場」・「会員」・「部品」などですが、存在を表わすものです。
 新しく作られるエンティティは「配属」・「入金」・「入庫」・「受注」・「契約」・「組立」・「塗装」・「支払」など行為や出来事を表わすものです。
 前者をリソースエンティティ、後者をイベントエンティティと言い、エンティティにRとかEとかのシンボルマークを書くこともあります。
 ここでは、リソースを黄色、イベントを緑で描いていますが、エンティティの名前を見れば分かるので、あまり気にする必要はありません。
 しかし、何と何から何が起きたのかを、視覚的にはっきりさせるために、ER図は次のように上から下へ描いたほうが分かりやすいでしょう。
部署と従業員の関連で配属が発生
 せっかく文章のビジネスルールは分かり難く、微妙な解釈の違いが起こる可能性もあるので、解釈が一意に決まる図で表現しているにも関わらず、図が分かり難いのでは話になりません。
 このように、上に元のリソースエンティティ、下に新しい出来事のイベントエンティティを描くと、「部署と従業員の関連は配属と言う」または、「配属は部署と従業員の関連で発生する」ことを、分かり易く表現することが出来ます。
 図としての分かりやすさは、図の大きさや対象の多少で工夫のポイントが変わって来るので、作図センスで決まる部分が多いのは確かですが、一応の基本レイアウトについては、作図ルールに加えることを勧めます。


 これで一応の基本は説明したので、簡単なビジネスルールは描けると思います。
 次回からは、例を挙げながら少しずつ複雑な表現について説明します。
 それでは、今回のおさらいです。
・認識の主体としての自分が、「あ、何かある」と気付いたものをエンティティと言う。
・リソースエンティティが関連することでイベントエンティティが発生する。
・関連名はリソースエンティティだけを描く概要レベルのER図では意味があるが、全てのデータに、それを収容するエンティティを設定し、ビジネスを表現したり、ビジネスのデータ構造を表現するER図では、意味が無いので書く必要はない。
・リソースエンティティは上に、イベントエンティティは下に描いて何から何が生成されているか分かり易く描く。
以上です。
 では、次回は多重度についてご説明させて頂きます。

このページのトップへ