ER図（Entity Relationship Diagram）とはデータベース設計における代表的な設計図のことです。
システムを設計する手法としては他にもUMLなどの技法がありますが、ER図はDOA(データ中心アプローチ）の技法であり、作成したER図がそのまま物理データベース上に変換できることから、データベース設計手法におけるデファクトスタンダードとなっています。
大規模なシステム開発においてはER図は必要不可欠です。そこで、これからはじめてER図を書くという方向けに、ER図の概要や書き方、テクニックなどについてご紹介します。
ER図とは
ER図のEはエンティティ（Entity）の略で、Rはリレーションシップ（Relationship）の略です。つまりER図は「エンティティ＝モノ」と「リレーションシップ＝関係」の組み合わせでシステムのデータやデータ間の処理構造を設計します。例として「顧客が商品を注文する」という処理をER図で表すと以下のようになります。
図１． ER図の例
「顧客」や「商品」がエンティティ、「注文する」がリレーションシップとなります。どのような大規模システムであっても、ER図ではエンティティとリレーションシップの組み合わせでシンプルにシステムが表現できることが特長となっています。
ER図を書くメリット
エンジニアの中には、「データベース設計においてはテーブル設計書だけ作る」、「設計を行わずデータベースを構築する」という方もいると思いますが、ER図を作ると以下のようなメリットがあります。
後戻りのコストを防ぐことができる
テーブル数が多くなればなるほど、設計ミスや、プログラマが仕様を理解できないリスクが増大し、後戻りによるコストが発生してしまいます。そのような大規模なシステムの場合は、ER図で整理することでシステム全体の構成が俯瞰でき、品質の高いデータベースおよびプログラム製造につなげることがでます。基幹業務システムのリプレイスなどの大規模案件においては、ER図の作成は必須と言えるでしょう。
運用・保守フェーズで役立つ
また、システムは一度構築すれば終わりではなく、長年稼働しながら改修を繰り返していきます。ER図は、そのようなシステムの運用・保守フェーズにおいても活用できます。稼働直後は当初の設計者が残っているので、設計ドキュメントがなくても何とかなるかもしれませんが、いつまでも設計者が残っているという保証はありません。ER図を残しておくことで、設計者以外の方でも設計内容を把握し、仕様変更などの改修に素早く対応できるようになります。
ER図のデータモデル
また、ER図はシステムの上流工程の中で段階的に設計します。各工程で作成するER図の状態のことを「データモデル」と呼びます。データモデルには「概念モデル」「論理モデル」「物理モデル」があります。各データモデルの違いは以下の通りです。
概念モデル
要件定義工程で作成するデータモデルです。最初にシステム全体における「もの」や「できごと」をエンティティ、リレーションシップとして洗い出し、概要を表したものとなります。
図２．概念モデル
論理モデル
基本設計工程で作成するデータモデルです。論理モデルでは概念モデルに対してさまざまな肉付けを行います。具体的には属性（アトリビュート）、アイデンティファイア（主キー）、外部キーの定義や、リレーションシップにカーディナリティといった要素を追加します。ただし、論理モデルではデータ型の定義などの物理データベース向けの設計は行いません。つまり、論理モデルは「特定のデータベースに依存しないレベルで具体化した状態」となります。
図３．論理モデル
物理モデル
詳細設計工程で作成するデータモデルです。Oracle Database等の特定の物理データベース向けに論理モデルの変換を行います。例えばデータ型を追加したり、物理データベースに即したアルファベットに変換します。ER図の最終形態がこの物理モデルとなります。物理モデル完成後は、その情報をもとに物理データベースを作成することができます。
図４．物理モデル
このようにER図では、段階的に考えながらデータベース設計ができることが特長となっています。
ER図の表記法
また、ER図にはいくつかの書き方（表記法）があります。代表的なのはIDEF1X（アイデフワンエックス、Integreation Definition 1Xの略）表記とIE（アイイー、Information Engineering）表記です。図５の左がIDEF1X、右がIE表記の例です。
図５．IDEF1XとIE表記の例
この２つの違いはリレーションシップの書き方です。IDEF1Xはリレーションシップの向き先を黒丸（●）で書くのに比べ、IE表記ではリレーションの子エンティティ側が鳥の３本足のように書きます。（そのため、IE表記は別名「鳥の足表記法」とも呼ばれます。）また、論理モデル作成時に設定する「カーディナリティ」の書き方が異なりますが、こちらについては後述します。
概念モデルの書き方
ここからは各データモデルの作成方法を解説します。まず、概念モデルでは、システム全体をモデル化し、設計するシステムに求められる事象を大まかに分類します。概念モデルで定義するものはエンティティとリレーションシップとなります。
エンティティ
まずはじめにシステムに登場する「モノ」を洗い出し、エンティティとして定義しましょう。Ｅコマースサイトの場合ですと「ショップ」「商品」「商品カテゴリ」「顧客」などがエンティティとなります。エンティティは四角い箱を描き、その中に名前を書きます。
図６．エンティティの例
エンティティには以下の２種類に分離されます。
リソースエンティティ
システム基本データを管理するエンティティとなります。Eコマースシステムの例では「ショップ」「顧客」「商品」などがリソースエンティティとなります。最終的にマスタテーブルとなるエンティティです。
イベントエンティティ
システムの業務データを管理するエンティティになります。Eコマースシステムの例では「受注」「出荷」「入金」などがイベントエンティティとなります。イベントエンティティには最終的にはトランザクションテーブルとなります。
リレーションシップ
エンティティの洗い出し後は、エンティティ間の関係を考え、関係あるエンティティ間にリレーションシップ（関連線）を引いていきます。例えば、ショップエンティティと商品エンティティの関係を考えると「ショップでは商品を置く（販売する）」という関係が成り立ちますので、これらのエンティティの間に線を引きます。リレーションを引いた場合はその関係の内容も記載します。これを動詞句と言います。今回はショップの中に商品を置くので「置く」と記述しています。
図７．エンティティにリレーションシップを追加したER図
リレーションシップには向きがあります。関連の「主語」から「目的語」に向かって線を引きます。上記例では「ショップは商品を置く」という関係となりますので、ショップ（主語）から商品（目的語）に向かって線を引きます。また、向きがわかるように向き先側には黒丸を描きます (IDEF1X表記の場合）。主語となるエンティティを「親エンティティ」、目的語となるエンティティを「子エンティティ」と呼びます。
また、リレーションシップには以下の種類があります。
依存リレーションシップ
リレーションシップを引いた両エンティティ間で依存関係が成立する場合のリレーションシップとなります。依存とは、「親エンティティのデータが存在しない場合、子エンティティのデータも存在できない」という意味です。図７の「ショップ」と「商品」を結ぶリレーションは依存関係が成立します。ショップが１つも登録されていない場合は商品を置くことはできないからです。（構築するシステムの仕様にもよりますが、一般的にはそのような仕様になることが多いです。）このような場合はが依存リレーションシップとなります。依存リレーションシップの場合は実線を引きます。また、子エンティティの枠を角丸の四角に変更します。
非依存リレーションシップ
上記のような依存関係にあたらないリレーションシップです。図７の「顧客」と「商品」を結ぶリレーションシップが非依存となっています。注文した顧客が１人もいないときでも商品自体は販売している（存在できる）ためです。非依存リレーションシップの場合は点線で引きます。
多対多リレーションシップ
依存関係が成立せず、かつカーディナリティが多対多の関係となるリレーションシップとなります。詳しくは後述の「カーディナリティ」でご説明します。
論理モデルの書き方
論理モデルは概念モデルで作成したエンティティ、リレーションに肉付けを行う作業となります。具体的には以下の項目を追加します。
アトリビュート（属性）
アトリビュート（属性）とは、エンティティ内で管理する具体的なデータ項目のことです。顧客エンティティであれば、「顧客名」「顧客コード」「顧客住所」「性別」などがアトリビュートとなります。図１にアトリビュートを追加した例が図８です。
図８．アトリビュート追加後のER図
また、アトリビュートを追加する上では以下についても定義する必要があります。
アイデンティファイア
エンティティのレコードを識別子となるアトリビュートを「アイデンティファイア（identifier）」と呼びます。顧客エンティティの例では「顧客コード」がアイデンティファイアとなります。顧客コードがわかれば、顧客を特定することができるためです。アイデンティファイアを設定する場合は、エンティティの中に水平線を引き、水平線の上に記載します。アイデンティファイアとならないアトリビュートは水平線の下に記載します。
外部キー
もし、リレーションシップが設定されている場合は、親エンティティのアイデンティファイアとなるアトリビュートを子エンティティにも追加する必要があります。これを「外部キー」と呼びます。外部キーの属性は属性名の後に（ＦＫ）と付けます。図８の例では商品エンティティにある「顧客コード」が外部キーとなります。依存リレーションシップで結ばれた子エンティティの場合は、外部キーもアイデンティファイアにし、水平線の上に追加します。非依存リレーションシップの場合は外部キーはアイデンティファイアとせず、水平線の下に追加します。
カーディナリティ（多重度）
カーディナリティとは、リレーションシップで結ばれた両エンティティの数（レコード）の関係のことで、別名「多重度」とも呼ばれます。カーディナリティにおいては「片方のエンティティ１レコードに対し、もう一方エンティティが何レコードになるのか」で考えます。図９の例では、1人の顧客は複数の商品を買うことがありますが、反対に、１つの商品が複数の顧客に買われることもあります。この場合のカーディナリティは「多対多」となります。他にも「1対多」、「1対多」などの関係があります。
図９．カーディナリティを設定したER図
カーディナリティは、リレーションの線の始点と終点に次のルールで記号を追加します。
IDEF1X表記の場合
| 記号 | 意味 |
| なし | "1"を表します。 |
| P | 1以上を表します。 |
| Z | 0または1を表します。 |
| n | 定数nを表します。 |
| n-m | 範囲指定をした定数を表しています。（例：1-10） |
IE表記の場合
| 記号 | 意味 |
| ○ | "0"を表します。 |
| l | "1"を表しいます。 |
 |
"鳥の足"で"多"を表します。 |
なお、カーディナリティの結果が「多対多」だった場合は、リレーションシップも多対多リレーションシップに変更します。図９も多対多となるため、多対多リレーションシップに変更しています。（また、動詞句もわかりやすく書き換えています。）多対多リレーションシップでは、両端を黒丸にします（IDEF1Xの場合）。
物理モデルの書き方
ER図の最終的なモデルが物理モデルとなります。物理モデルは、論理モデルをOracle Databaseなどの特定の物理データベース向けに変換したものとなります。具体的には以下の変更を行います。
仲介エンティティの追加
エンティティは、最終的には物理データベース（RDBMS)上のテーブルになりますが、多対多リレーションシップで結ばれたエンティティは、テーブルに変換することができません。２次元表となるテーブルでは「親であり子である」という関係のテーブルデータを表現できないためです。この場合は、「仲介エンティティ」というエンティティを設け、１対多の関係に変換します。図９に仲介エンティティを設けたER図が図１０になります。
図１０．仲介エンティティを追加したER図
「注文」というエンティティが仲介エンティティとなっています。顧客、商品の間に追加し、さらに顧客、商品エンティティの子エンティティとして依存リレーションシップで結びなおしています。これにより、カーディナリティは１対多となり、顧客と商品が親、注文が子となるので、テーブルとして問題なく構築可能になります。
データ型の追加
また、属性ごとに適切なデータ型を設定します。Oracle Databaseの場合、一般的なデータ型は以下の通りとなります。
| 記号 | 意味 | 長さ指定 |
| 数値 | NUMBER | 任意 |
| 文字 | CHAR VARCHAR2 |
必須 |
| 日付 | DATE TIMESTAMP |
なし |
データ型は大きく「数値、文字、日付」の３種類に分かれます。数値の場合はデータ型は「NUMBER」となります。文字の場合は各レコードの値の長さが固定であれば「CHAR」、可変となる場合は「VARCHAR2」となります。また、日付の場合は「DATE」ですが、時刻まで記録したい場合は「TIMESTAMP」となります。ただし、長文データに関しては「CLOB」にするなど上記に当てはまらない場合もありますのでご注意ください。
エンティティ名、アトリビュートをアルファベットに変換
エンティティ名やアトリビュート名は論理モデルまではわかりやすい日本語にしていましたが、Oracle Database等の物理データベース上はアルファベットにするのが慣例です。そこで「顧客」を「EMP」、「顧客コード」を「EMP_CODE」など、アルファベットに変更します。
昔のバージョンのデータベースではマルチバイトのキャラクタでは誤動作を起こすことがあったことからアルファベットにするのが慣例となっていますが、今時はデータベースは日本語のマルチバイトで作成しても問題なく動作するため、この作業は必須ではありません。
正規化
その他、必要に応じて冗長となるデータを省く「正規化」という作業を行いますが、詳しくは「ER図の正規化とは」でご説明します。
図１０のエンティティ名、アトリビュート名をアルファベットに変換し、データ型を追加したER図は図１１の通りです。
図１１．物理名に変換およびデータ型を追加したER図
ER図から物理データベースを構築する方法
ER図の完成後は、物理データベースのスクリプト（DDL)を構築することができます。構築にあたってはER図と物理データベース項目の対応関係をおさえておく必要があります。代表的なER図の要素と物理データベース項目の関係は以下になります。
| ER設計 | 物理データベース |
|---|---|
| エンティティ名 | テーブル名 |
| アトリビュート（物理名） | カラム名 |
| アイデンティファイア | 主キー制約 |
| リレーションシップ | 外部キー制約 |
表2．ER図と物理データベースの関係
例として、図１２のER図をもとに書いたスクリプトは図１３の通りです。
図１２．ER図（物理モデル）
| CREATE TABLE EMP ( EMP_CODE VARCHAR2(10), EMP_NAME VARCHAR2(50) ) / ALTER TABLE EMP ADD(CONSTRAINT PK_EMP PRIMARY KEY (EMP_CODE) USING INDEX) / CREATE TABLE COMMODITY ( COMMODITY_CODE VARCHAR2(10), COMMODITY_NAME VARCHAR2(100), PRICE NUMBER(8,0) ) / ALTER TABLE COMMODITY ADD(CONSTRAINT PK_COMMODITY PRIMARY KEY (COMMODITY_CODE) USING INDEX) / CREATE TABLE PURCHACE ( EMP_CODE VARCHAR2(10), COMMODITY_CODE VARCHAR2(10) PURCHACE_NUM NUMBER(3,0), PURCHACE_DATE DATE, ) / |
図１３．ER図をもとに生成したスクリプト
また、同様の変換ルールでER図から「テーブル定義書」などのドキュメントを作成することも可能です。
ER図の正規化とは
また、ER図設計においては、各エンティティおよび属性をどのように持たせるかが非常に重要です。ここをきちんと考えないとデータ量が増えたり、プログラムからのデータ更新がやりづらくなってしまいます。データを重複なく設計するテクニックとして「正規化」という手法があります。正規化には第一正規化から第三正規化まであり、段階的に行うものとなっています。
第一正規化
第一正規化では繰り返しが発生している属性をなくす作業を行います。例えば、図１４の社員エンティティでは「担当顧客」「担当顧客名」「最終訪問日」という列が繰り返し登場しています。このような列は１種類にし、別行（別レコード）として管理するようにします。
図１４．第一正規化の例
第二正規化
第二正規化は、ある主キーとみなせる属性に従属する属性を探し、別エンティティに分割する作業です。「従属」とはある属性の値により、一意に値が定まる属性のことです。以下の例では、「氏名」～「部署名」の列は「社員番号」に従属しており、「担当顧客名」は「担当顧客コード」に従属しています。そこで、前者は社員エンティティに残しておき、後者は顧客エンティティとして新たに作成し、こちらに移動します。また、複数の属性に従属する属性もあります。「最終訪問日」は「社員番号」と「顧客コード」の2つの属性によって定まる属性です。このような場合は社員番号と顧客コードを主キーとしたエンティティを新たに作成し、「最終訪問日」をそのエンティティに移動します。
図１５．第二正規化の例
第三正規化
第三正規化では、主キーでない属性の中から新たに主キー属性となるべきものがないか探し、新たな主キーに従属する項目を別エンティティに分割する作業です。さきほどの第二正規化では「部署名」「部署コード」は社員番号に従属するということから社員エンティティに残していましたが、「部署名」の属性をみると「部署コード」の属性に依存することがわかります。そのため、部署エンティティに分離し、移動します。
図１６．第三正規化の例
以上が正規化の方法でした。実は正規化には第五正規化まであり、さらにエンティティを分割することもできますが、あまりエンティティを分割してしまうと更新箇所が多く反対に扱いづらくなります。一般的には、第三正規化まで行えば問題ないとされていますので、ぜひこの第三正規化までのテクニックを身に着けておきましょう。
ER図の作成例
ER図の作成に必要な知識をご紹介しましたが、なかなかイメージがつきにくいかもしれませんので、プロジェクト管理システムを設計する例で実際の作成方法をご紹介します。
図１７．ユースケース図
このシステムの利用者は「管理者」と「社員」に分かれています。管理者は部門およびメンバーが登録できます。その後、社員はプロジェクトを作成し、そのプロジェクトに他の部門も含めた社員をアサインできるようにします。また、部門や社員、プロジェクトでは「名前」だけ登録できれば良いものとします。ただし、同名の名前を複数登録ができるものとします。
実際のプロジェクト管理システムでは進捗や工数管理などの機能も必要ですが、今回はプロトタイプ版ということで上記のみ可能なシステムにします。
概念モデルの作成
それでは、このシステムの概念モデルから設計しましょう。初めは「このシステムを実現するために、どれだけデータを入れる”箱”を用意すればよいのか」を考えればよいです。図１７のユースケース図では「部門」「社員」「プロジェクト」の３つがキーワードとして登場していますので、これをリソースエンティティとして登録しましょう。（その他、イベントエンティティが必要になるケースもありますが、後で必要とわかった段階で追加すればよいです。）リソースエンティティを追加したER図は以下の通りです。
図１８．概念モデル（リソースエンティティを追加）
次に、これらのエンティティ間で関連があるものに対してリレーションシップを引きましょう。今回の例では以下の関連があります。
① 部門と社員…社員は部門に所属する
② 社員とプロジェクト…社員はプロジェクトを担当する
部門とプロジェクト間にも関連があると考える方もいるかも知れませんが、今回のシステムではプロジェクトは社員とだけ紐づけされますので関連はありません。本格的なプロジェクト管理システムでは各プロジェクトに担当部門を持たせることで関連するケースもあります。このように要件によって関連は変わりますので、要件を確認しながらリレーションシップを設定していきましょう。
また、リレーションシップを引く際はあわせて「依存」「非依存」「多対多」のどの種類になるかも考える必要があります。一般的には「親子関係があるか？」で考えるとわかりやすいです。①はある部門の中に社員が所属するかたちになりますので、親子関係が成立します。つまり、依存リレーションシップとなります。一方、②は親子関係ではありません。メンバーが複数プロジェクトを担当することもあれば、プロジェクトを複数の社員に担当されることもあるためです。従って、多対多リレーションシップとなります。リレーションシップを追加した状態は以下になります。これで概念モデルは完成です。
図１９．概念モデル（リレーションシップと動詞句を追加）
論理モデルの作成
続けて論理モデルを設計しましょう。論理モデルでは各エンティティにアトリビュート（属性）を追加します。今回の例では部門、社員、プロジェクトの名前のみ管理できればよいため、各エンティティに名前用のアトリビュートを１つずつ登録します。ただし、「同じ名前があっても登録可能にする」という要件があることからアイデンティファイアとしてコード用の列も追加します。名前の値が同じであってもコードの値が別であれば区別が可能となるためです。これらのアトリビュートを登録したER図は以下になります。
図２０．論理モデル（アトリビュートを追加）
アイデンティファイアとその他の属性を区別するために、各エンティティに水平線を引きアイデンティファイアは水平線より上に記述します。また、アイデンティファイアの追加時は、子エンティティにも外部キーとしてアトリビュートの追加が必要です。そのため、社員エンティティにも部門コードを追加しています。
また、リレーションシップの両端にカーディナリティ（多重度）も記述しています。今回のリレーションシップは「1対多」「多対多」ですが、IDEF1X表記の場合は「多」の個所にPと記載します。
その他、このシステムでは「プロジェクトにメンバーをアサインする」という要件がありますが、この段階ではメンバーとプロジェクトの関連が「多対多」であることからアトリビュートをうまく持たせることができません。これは物理モデルで調整しますので、次へ進みましょう。
物理モデルの作成
最後に物理データベース向けにER図を調整した物理モデルを設計します。今回はOracle Databaseの前提として物理モデルを作成します。
①仲介エンティティの追加
「多対多」のリレーションシップの個所がある場合、物理データベース上にテーブルを作成することはできませんので、仲介エンティティを設けます。仲介エンティティ追加後のER図は以下の通りです。
図２１．物理モデル（仲介エンティティを追加）
青色が仲介エンティティとなります。（名前は「プロジェクトメンバー」としましたが別の名前でも構いません。）仲介エンティティでは、お互いのアイデンティファイアを外部キーとして持たせます。これで「1対多」の関係にすることができます。
②名前の変換・データ型の追加
エンティティ名、アトリビュート名を物理データベース向けにアルファベットに変換およびデータ型を設定します。今回はOracle Databaseとなりますので、コードをNUMBER、名前を50桁のVARCHAR2としました。設定後のER図は以下の通りです。
図２２．物理モデル（名前の変換・データ型を追加）
その他、冗長な列があれば正規化を行いますが、今回の例では必要ありませんので、これでER図完成となります。実務の世界では、概念モデルを省略して論理モデルから設計するケースや、論理モデルの設計時に仲介エンティティを定義する場合もありますが、初めてER図を作る場合は今回のように段階的に詳細化しながら設計するのがおすすめです。
ER図を見やすくするテクニック
大規模なシステムなER図では、エンティティやリレーションシップの数が多くなりER図が見づらいという問題が出てきます。そのようなときに、ER図を見やすくする３つのテクニックをご紹介します。
親エンティティは左上から書く
すべてのエンティティと一番親となるエンティティを左に書き、子エンティティを右、孫エンティティをさらに右…というように書きます。同じ親をもつエンティティは上下に並べるようにすると、以下のようなツリー構造になり、親子関係が明確にわかり、リレーションシップも重ならなくなります。
図２３．親エンティティを左から書いた例
ER図をサブシステムごとに分割する
大規模なシステムの場合はすべてのエンティティが一画面に入りきらなくなり、把握がしづらくなります。そのような場合はER図の分割を行います。分割する際は「商品系」「取引系」といった業務分類で分割する、ERPのシステムであれば「売掛」「買掛」などのサブシステム単位で分割するなどのルールを決めてグループ分けすると後で探しやすくなります。また、ExcelやVisioであれば1ファイルの中で別シートにして分割することができます。
図２４．ER図をサブ機能ごとに分割した例
リソースエンティティとイベントエンティティで色分けする
エンティティには最終的にマスタ系のテーブルとなる「リソースエンティティ」とトランザクションを管理するテーブルとなる「イベントエンティティ」の２種類に分かれますが、これらを色分けしておくとデータと業務の関連がわかりやすくなります。リソースエンティティを緑、イベントエンティティを黄色で色分けした例は以下の通りです。「顧客には請求と入金という業務がある」「入金口座マスタは入金業務でのみ使う」などの内容がすぐに把握できるようになります。
図２５．ER図をリソースエンティティとイベントエンティティで色分けした例
ER図の作成ツール
ER図についてはExcelやVisioなどのアプリケーションで作成することも可能ですが、罫線や図形オブジェクトを使って作図するのは時間がかかります。昨今ではER図を作成する専用ツールが出ており、これらのツールを活用することで効率良くER図が作成できます。
当社でもER図作成ツール「SI Object Browser ER（以下、OBER)」というER図作成ツールを販売しています。OBERは以下の２つの特長によりER図を効率良く作成できるツールです。
ER図を効率よく作成できる
簡単なマウス操作でエンティティやリレーションシップの配置が作図できます。概念モデル用のエンティティや、論理モデル、物理モデル用のアトリビュートをそれぞれ定義し、データモデルの表示切り替えが可能です。また、ER図を見やすくシート分割し、かつ分割後の整合性も保てる「サブモデル」機能や、複数のエンティティで共通的に使うアトリビュートに対してテンプレート化ができる「ドメイン」機能などを備えており、ER図作成の効率、品質の両方を高めることができます。
画面．OBERの設計画面
データベースと直接連携できる
さきほどもER図から物理データベースの構築する方法をご紹介しましたが、手動でスクリプトを作成するのはやはり手間です。そこでOBERでは、ER図情報を元に自動でスクリプトを生成し、物理データベースを構築できる「フォワードエンジニアリング」機能を備えています。この機能により、ER図作成後はスムーズに物理データベース構築が可能となっています。
図２６．OBERのデータベース連携機能
さらに、データベースからER図を逆生成する「リバースエンジニアリング」機能や、ER図とデータベースの相違点を比較し自動で同期する「データベース同期」機能も備えており、新規案件だけでなく既存システムの改修案件や、保守運用フェーズでの仕様変更対応が楽にできるようになっています。Oracle Database、SQL Server、DB2等の主要商用DBからPostgreSQLやMySQLなどのオープンソースDBまで幅広く対応しています。その他、テーブル定義書（Excel)の出力やテーブル定義書からのER図逆生成も可能です。
OBERは、ER図作成ツールの中ではめずらしい国産ツールとなっており、国内で5,000社以上の導入実績があります。30日機能制限なしで試用できるトライアル版もご用意していますので、本格的なER図を作成したい方はぜひご利用いただきたいと思います。
以上でER図の概要や書き方やテクニックをひととおり解説いたしました。ここまで読んでいただいた方はきっとER図の基本がマスターできているはずです。ぜひ今後のデータベース設計で実践いただけたらと思います。
