データ連携を効率化するER図とは？3つのモデルの書き方について

データ連携の際には、効率よく連携計画を進めていくことが大きな鍵となります。全体的にどのようなデータを統合してまとめるのか理解していなければ、連携の計画はなかなかスムーズに進まないでしょう。そんなときER図という設計イメージの存在は大事な役割を果たしてくれます。

そこで今回は、連携を滞りなく進めるためのポイントとして、ER図を書いて設計イメージをまとめる方法について解説していきます。モデルによって書き方のポイントや詳細レベルは異なるため、それぞれを書いてまとめる方法の基本についてはぜひ理解を深めておきましょう。

データ連携を効率化するER図のデータモデル

データベースの設計図として解釈できるイメージを漏れなく作成し、わかりやすい道筋を立てることは、滞りなく連携を実行するというミッションをこなすうえでは欠かせません。

連携の際にはいろいろな種類で、かつ、あふれそうなほどの膨大なデータを扱うことになるため、作業プロセスを最適化して効率を上げるには、わかりやすく把握しやすい全体イメージの図が必要になります。

ER図のなかで見られる種類をここで見ていきましょう。

• 概念モデル…全体をモデル化→四角や線を使って事象をおおよそで分類
• 論理モデル…必要な属性を付与して全体図を掘り下げていく図。上の概念モデルの詳細
• 物理モデル…データベースの情報と一対一の関係をなす。上の論理モデルの詳細

簡単に要点として解釈しておくべき点を整理すると以上のようになり、データベース構築の際の道しるべとして知られています。

種類は以上のように3つに分かれますが、まとめる際には四角形を使ってひとまとまりになったデータをわかりやすく書きます。これはモデルの種類にかかわらず共通するポイントで、このひとまとまりになったデータをエンティティと呼びます。

そしてそのまとまりのデータ（＝四角形）については、関連するもの同士を線で結ぶことで図を書いてつながりを定義づけていきますが、この線は関係するという意味のリレーションという名前になります。

ER図とは、Entity（エンティティ）、そしてRelation（リレーション）から来ています。

概念モデルの記載方法

モデルによって具体的な書き方やアプローチなどは3つとも異なるため、この章からはER図を書いてまとめる方法をモデル別に整理していきます。

最初にチェックしておきたいのは、基本形ともいえる概念モデルの書き方です。概念モデルは前項でも軽く触れてきましたが、全体をモデル化するかたちで書かれるER図です。

設計したいシステムにはどのような事象があるのかを把握して整理することが重要な目的です。概念モデルでは事象をおおよそのレベルでカテゴライズするため、エンティティとリレーションシップだけを図の構成に必要とします。

エンティティ

最初にシステムの完成形を簡単にイメージして概要をつかみ、どのようなモノがそのシステム内に存在するのかを一つひとつ整理していきます。エンティティはこの流れで明らかにしていきます。定義する際には四角形の図を用意し、そこにモノを一つひとつ配置していきましょう。

また、エンティティには2種類のものがあり、最終的にマスターテーブルに該当し基本データをまとめるのがリソースエンティティです。もう一つは最終形態としてトランザクションテーブルに該当し、業務データを管理してまとめるイベントエンティティになります。

このように種類をカテゴライズして、必須となるエンティティをピックアップしていきます。

リレーションシップ

つながりを表記する際に用いる線を指します。エンティティ同士を線で結んだときは、具体的な関係性について内容を書いていきますが、例えば「売る」「置く」「担当する」などの表記の場合は動詞句というのが特徴です。

また、線の引き方には決まりがあることも覚えておきましょう。ポイントは向きです。主語から目的語に向けて線を引き、その向きは誰が見てもわかるように明確にしておきます。具体的には、線が向いている方向の端に黒丸を書いてわかりやすくするのが基本のルールです。

さらにポイントを記載すると、主語は親、目的語は子と呼んで分類するという点もチェックしておきましょう。

そしてリレーションシップには3パターンの種類があります。

依存リレーションシップ

通常の一方通行だけでなく、黒丸のあるリレーションシップが両方向で成立するのが主な特徴です。親エンティティなしでは子エンティティのデータは存在できません。この場合、線は実線を引きます。

非依存リレーションシップ

前項の依存関係に該当しないリレーションシップのことで、今度は実線ではなく点線で表記していきます。親エンティティがなくても成り立つ関係が非依存に該当します。

多対多リレーションシップ

依存の関係が成り立たないのが特徴のリレーションシップです。それでいて多対多の関係であることがポイントになります。

論理モデルの書き方

ER図のなかでも論理モデルは、概念モデルをより詳しく掘り下げて書いたものとしてとらえられます。実際に、論理モデルでは概念モデルを骨組みとしてチェックし、肉付けしていくことになります。

アトリビュート

属性を示す言葉です。エンティティ内にはさまざまなタイプの情報が存在するため、例えば顧客情報のエンティティの場合は名前や住所、割り振られた顧客コードといったように、具体的な項目を表しています。

アトリビュートを追加していく際には、アンデンティファイアという識別子の定義も必要です。顧客コードがこれに該当します。アイデンティファイアを設定する際には、水平線を引いたときの上に書いていくのがポイントです。

また、対象のエンティティにリレーションシップが定義されているときは、子エンティティに対しても親エンティティのアトリビュートを付与していきます。これは外部キーといいます。

カーディナリティ

リレーションシップで結ばれているエンティティ同士の数のことをいいます。一方のエンティティが持つレコードの数が1の場合、相手は何レコードなのかという考え方になるため、多重度といわれることもあります。

カーディナリティの表記にはあらゆる取り決めがあり、詳細は割愛しますが、リレーションの両端に各種記号を書いておくのが特徴です。

物理モデルの書き方

以上の論理モデルをさらに詳細化したものを物理モデルといい、これが連携の設計イメージとしては最終形になります。

具体的に行うのは変換作業で、主にはサービスとして提供されている特定の物理データベースで使用する目的で、論理モデルを必要に応じて変換し、物理モデルに仕上げていきます。

仲介エンティティの追加

多対多におけるリレーションシップのエンティティ同士はテーブル変換が不可能なため、仲介エンティティというものを追加して定義します。これにより1対多のかたちに変換可能になるのがポイントです。

データ型の追加

変換したいデータベースのかたちに合わせて、属性一つひとつに適切なデータ型を決めていきます。わかりやすいものでいえば、日付ならDATE、数値ならNUMBERといった型がありますが、これはOracle社のデータベース向きのものです。

エンティティ名、アトリビュートをアルファベットに変換

従来の常識でいえば、エンティティやアトリビュートの名前をアルファベットに変換し、正常に動作するようにします。基本的に物理データベースでは、日本語のままではなくアルファベットで書いておくのが通常でした。

しかし昨今のデータベースでは、日本語のままでも正常に動作するケースがほとんどになってきています。そのため必要であればこの工程は外せませんが、近年のデータベースではほぼ必要ないことも覚えておくと良いでしょう。

まとめ

データ連携の際にはこのように膨大なデータを扱ってデータベースの設計をするため、効率的な作業を行うためには、ER図の作成が欠かせません。ER図には概念、論理、物理といったモデルの種類があり、詳細レベルによって分類分けできることを覚えておきましょう。

Microsoft社のAzureでは、セキュリティ性に優れたクラウドサービスでの迅速なデータ連携を実現します。シームレスなデータ共有にはクラウドサービスの活用がおすすめです。データ連携にお困りの際には、Azureの導入をぜひご検討ください。