前回の振り返り

●エンティティの種類はリソース、イベント、サマリの３種類に大別される。

●リソースは共用性が高く、情報の増減頻度が低い。情報量は比較的少ない。

●イベントは共用性が低く、情報の増加頻度が高い。情報量は比較的多い。

はじめに

毎年「今年は特別に暑いな」と思うわけですが、2022年は本当に暑いですよね。

私は食欲が減退しまくりです。

そんな私は、“夏はカレーで乗り切る”がモットーです。

スパイスが胃を刺激してくれるからか、カレーだと不思議と食べられるんですよね。

みなさんも夏バテする前に、カレーを食べてみてはいかがでしょうか。

さて、今回はエンティティとエンティティのつながりについて書くことにします。

データマネジメントにおいて、エンティティ同士のつながりを正しく把握することはとても大切なことです。

基本的なことから学んでいきましょう。

エンティティとエンティティのつながり

まず“エンティティとエンティティがつながっている”とは、どういう状態を指すのか考えてみましょう。

前回のブログで新たに認識した“家族エンティティ”と、お馴染みの“買い物エンティティ”の２つのエンティティに限定して両者のつながりを確認することにします。

「家族」と「買い物」につながりがあるならば、それはどこで判断できるのでしょうか？

実は簡単に判断することが可能で、それぞれのデータ項目の値を比べれば良いのです。

値を比べると“家族”と同じ値を取るのは、“購入者”だけであることが一目瞭然です。

どうやらここに、つながりがありそうです。

「買い物」の文脈【WHO（誰が）、WHEN（いつ）、WHERE（どこで）、WHAT（何を）】で考えてみるとさらによく分かります。

“購入者”が妻、のように、家族が文脈の【WHO（誰が）】に当たることに、違和感はないはずです。

一方で“購入日”が夫とか、“購入場所”が妻とか、“商品名”が子供とか……、普通に考えて変ですよね。

家族が文脈の【WHEN（いつ）、WHERE（どこで）、WHAT（何を）】に当たることはあり得ません。

よって“家族”と“購入者”につながりがあるのは、間違いないと判断できます。

すなわち、“エンティティとエンティティがつながっている”とは、

２つのエンティティ間に同じ値を持つ項目が存在し、かつ文脈的に正しい状態を指すわけです。

……しかし。それだけでは十分ではありません。

もう少し深堀することにしましょう。

エンティティはキーでつながる

先ほどまでの例だと分かりづらいので、“家族エンティティ”に【氏名・区分・性別・年齢】というデータ項目を持たせることにします。

これに合わせて“買い物エンティティ”には、【購入者氏名・購入者性別・購入者年齢】を持たせることにします。

すると、“エンティティとエンティティがつながっている”状態を満たすデータ項目が３つ（氏名・性別・年齢）、存在することになります。

「つながっているならいいじゃないか！」という声も聞こえてきそうですが、そこはグッとおさえて１つずつ見ていきましょう。

まず“性別”からです。

値も同じですし、文脈的にもおかしくはありません。

ただ、この家族は男女２人ずつの４人家族です。

“性別”だけでは、家族の誰が購入者であるかを特定できません。

続いて“年齢”です。

こちらもおかしいところはありませんが、この家族は夫婦が同い年です。

“年齢”だけでも、購入者が夫か妻かを特定できません。

最後に“氏名”です……うん！

これなら家族の誰が購入者であるかを、特定できますね。

このように“エンティティとエンティティがつながっている”状態を満たすデータ項目の中にも、家族の誰が購入者であるかを特定できるデータ項目と、そうでない項目があることが分かります。

ちなみに“性別”と“年齢”の組合せでも特定できますが、１つで特定できるのに、わざわざ２つを組合せて特定する必要はありませんよね。 

あれ？　この話、どこかで出てきませんでしたか？

そうです！　第５回に出てきた『キー』です。（忘れた人は読み返してみてください。）

これではっきりしました。“エンティティとエンティティがつながっている”と言うためには、片方のエンティティの『キー』がもう片方のエンティティにも存在する、ということが重要なのです。

ちなみに私は、「同一家族で同一氏名は禁止」だと思っていたのですが、戸籍法には禁止とは明文化されていないそうです。

通例的には同じ漢字表記はNG、漢字表記が異なっていれば同じ読みはOKとのこと。

ただし、男性でも女性でも比較的ある名前、例えば「薫」さん同士の結婚だった場合は、結果として夫婦が同姓同名になり得ます。

この場合はもちろんOKみたいです。（※あくまでも筆者がインターネット検索で得た情報に基づいています）

こういう場合を考慮して、リソースエンティティの『キー』にも、番号やコードを用いることが一般的です。

同じ番号を付与しないようにすれば、一意性を担保できるためです。

『キー』が特定されれば、その他のデータ項目（氏名・性別・年齢）も分かるため、「買い物」側に持つのも『キー』だけでよくなります。

一般的に「買い物」側に持つ方を『外部キー』と呼びます。

そして『キー』と『外部キー』によるエンティティ間のつながりを『リレーションシップ』と呼ぶので覚えておきましょう。

おわりに

今回は、リレーションシップについて説明しました。いかがだったでしょうか？

正直なところ、長々と書いたことで余計に、分かりづらくなっていないか心配しています。

『キー』のことが分かってさえいれば、最後の絵を説明するだけで十分な気もするんですよね……。

ご意見・ご感想をお待ちしております。

次回予告

次回はリレーションシップの種類について触れます。

データを管理する人にも、データを活用する人にも役立つ内容になるはずです。お楽しみに！

※記載内容は執筆当時のものです。株式会社リアライズは2023年1月1日に株式会社NTTデータ バリュー・エンジニアに社名変更しました。

他の人気ブログ