ER図とテーブル関連図 ～第５章～

↓前回の内容はこちらから↓

はじめに

データベースをテーマとして徒然なるままに記述しています。何となく『そうなのね～』と解釈していただければそれで結構です．逆に言うと多少（大いに？）厳密性に関しては怪しいところを含むかもしれません．基本的には一般論として述べるつもりですが，所々筆者の独断と偏見に基づく表現も含まれることと思いますので，それを前提にお読みください．

コラムの連載予定

１　DB（データベース：Data Base）とは
２　DBシステムとファイルシステムとの違い
３　DBの歴史
４　何故正規化するのか
５　ER図とテーブル関連図　←現在地
６　トランザクションとリカバリ
７　同時実行制御
８　データの活用
９　おわりに

---

ER図とテーブル関連図(RDBを例に)

DB設計の場に必ずER図が登場する．これは何のためか？
DBのテーブル定義を生成するためか？

確かに世の中に流布している各種ツールにおいて，テーブル構造とER図をセットにしたものが存在しているらしい事は筆者も認識している．

テーブルの定義情報を，とある作法に則って作成していくと，テーブル定義(CREATE TABLE xxx )を自動生成しER図もお絵描きしてくれる．
確かにこれは便利なツールである事に間違いはない．

但し，これはコンピュータシステムに実装されるテーブル関連図と言うべきモノである．

この類のツールで，これらをER図と呼称している場合もあるので，DB初心者を紛らわせている一因となっていると感じている．

ER図はEntity Relation Diagramの事であり，Entityとは先に述べた用語を用いれば管理対象の事である．

実ビジネスの世界をデータの側面から読み取り整理したものであり，データ概念図と表現される場合もある．

ここに，前記した正規化の手法を用いて整理している訳である．

私の理解するところのER図の意味は以下と考えている．

実ビジネスで扱われているデータの塊(管理対象)の単位(Entity)およびその塊と塊の関係(Relation)が２次元的に表現されたものであり，設計者や開発者のみならずユーザ側も含めた関係者が共通認識に立つための情報(ツール)である．

そこで，業務の対象範囲が変化(拡大/縮小等)したりビジネスルールが変化したりした場合，このER図に立ち戻りこれをメンテナンスすることから始める位置づけのモノである．

．．．．ただ実際の開発場面ではなかなかこれが難しいのが実態である．

慣れてくるとこのER図から業務ルールがそれなりに読み取れてくる．但し全ての業務ルールがこれだけで読み取れる訳では無い．

話を元に戻す．このモデリングを経て，コンピュータシステムに実装するためのテーブル設計(書)に変化していくモノと捉えている．

実装の段階で，Entity＝Tableとなる場合もあり得るが，ER図とテーブル関連図(実装)は別物として考えるのが好ましい，と筆者は考えている．

．．．．．．別にツールサプライアに文句言っている訳では無いのであしからず．

またER図の記法には各種流派が存在する．

Entityの属性(主キー，外部キー等)の表記の仕方やRelationの表記の仕方(矢印，カラスの足等)や多重度の表現方法等に独特な記法が存在するが，表現できる範囲(制約等)が多少異なるが，基本はほぼ同じである．

標準化という側面からはUMLは抑えておきたいところである．

ちょっとばかりDBから離れるが，このER図的整理手法はいろいろな事に応用できると感じている．

筆者自身も実践してきたが，自分のやること(to do)の整理とか課題の整理にもこの手法が有効であると感じている．

ただこれは筆者のちょっと偏った意見かもしれないので，変に真似る必要は無い．

---

最後までご覧いただきありがとうございました。

次回第６章は、「トランザクションとリカバリ 」についてです！

ぜひご覧ください！