データモデリング概要
RDBを利用してデータを管理する時や、アプリケーションとRDBを連動させるときに、適当なデータ設計をしてしまうと、データ管理が煩雑になったり、アプリ側の機能拡張が困難になる可能性があります。
そこで、データモデリングという手法を行うことで上記の問題を解決することができます。データモデリングの手法にはたくさんの種類があり、データモデルに合わせたデータモデリングの手法を使うことが多いです。
データモデルは、おおまかに「階層型」「ネットワーク型」「リレーショナル（関係）」に分けられます。
今回は、RDBを利用したデータ管理を行うので、リレーショナルデータモデルに合ったデータモデリングの手法を使います。
データモデリング実践
それでは、データモデリングをしていきます。
今回はSQLというRDBMSを操作する言語を使いますので、その知識がある前提で始めます。
今回は例として、ある社内プロジェクトをデータベースで管理するとします。
１. エンティティを定める。
エンティティとは、データベースを使って管理したい対象のことを指します。
社内プロジェクトをデータベースで管理したい時、どんなもの対象として管理したいでしょうか。
この場合、
「プロジェクト」
「プロジェクトの名前」
「プロジェクトの進行状況」
「プロジェクトの概要」
「担当社員」
「担当社員の名前」
「担当社員の年齢」
「担当社員の性別」
「担当社員の電話番号」
「担当社員の部署名」
などが管理したい対象となります。
ここで、これらの対象全てをエンティティに含めても良いのでしょうか。
先ほどは説明しませんでしたが、詳しくいうと、エンティティとは独立した一つの意味の対象物を指し示します。
そのため、別のエンティティに付属する情報はエンティティではありません。
ここで情報という言葉が重要です。
「プロジェクト」や「担当社員」は情報ではなく対象物です。
「名前」「性別」などが情報となります。
そのため、ここで独立した付属しないもの、つまりエンティティは、
「プロジェクト」
「担当社員」
となります。
２. エンティティ同士の関係を考える。
エンティティが決まったら、エンティティ同士の関係（リレーションシップ）を考えます。
今回はエンティティが2つなので、簡単に決まります。
担当社員はプロジェクトを担当する。
プロジェクトには担当社員がつく。
などの関係性があります。
これだけではとどまらず、さらに厳密に分析していきます。
カーディナリティ（多重度）
データの種類がどのくらいあるのか測る記号を「カーディナリティ」と言います。
「カーディナリティ」とは、「１対１」「１対多」「多対多」など、リレーションの詳細を表現する記号のことです。「0以上」や「0または1」といったことも表現することができます。
引用：５分で理解できるER図の書き方５ステップ
例えば、今回のプロジェクトでは、
1つのプロジェクトに1人の担当社員がつく、
プロジェクト1 対 1担当社員
多数のプロジェクトに1人の担当社員がつく、
プロジェクト多 対 1担当社員
多数のプロジェクトに多数の社員がつく、
プロジェクト多 対 多担当社員
1つのプロジェクトに多数の社員がつく、
プロジェクト1 対 多担当社員
のどれか、考える必要があります。
今回はプロジェクト1 対 多担当社員とします。
従属性の確認
エンティティ同士で、一方が存在していないと、もう一方も存在できないかどうかの依存関係を確認することを「従属性の確認」と言います。
例えば、今回のプロジェクトでは、
プロジェクトは担当社員がいないと存在できない。
担当社員はプロジェクトがないと存在できない。
などと考えて、どっちのエンティティが依存しているのかを考えます。
依存されているエンティティを「独立エンティティ（親エンティティ）」
依存しているエンティティを「従属エンティティ（子エンティティ）」
と呼ぶこともあります。
また、依存関係にないエンティティ同士もあることがあるので、必ずしもエンティティの従属性があるとは限りません。
今回は依存関係がないものとして扱います。
３. アトリビュート（属性）を考える。
最後に各エンティティに含まれる属性を考えます。
先ほど、エンティティを考える時に
「プロジェクトの名前」
「プロジェクトの進行状況」
「プロジェクトの概要」
「担当社員の名前」
「担当社員の年齢」
「担当社員の性別」
「担当社員の電話番号」
「担当社員の部署名」
が候補にあげられました。
しかし、これらの情報は別のエンティティに付属するのでエンティティではないと言いました。
これらの情報は属性として扱うことになります。
４. ER図にまとめる。
それでは、最後にこれまでのデータモデリングを元にER図を書いていきます。
ER図とは、データベースのエンティティ（Entity）とエンティティ同士の関連（Relationship）を図に表したものです。
正確な詳細などは省きましたが、このような感じになりました。
ちなみにプロジェクトエンティティに属する社員IDの(FK)は、外部キー（Foregin Key）を意味します。
外部キーはSQLでデータベースを操作する際、テーブル間を結合するために設定する列（カラム）のことです。
今回は基本なのでER図に書きませんでしたが、SQLでテーブル（エンティティのこと）を扱う際には主キー（Primary Key）を設定する必要があり、主キーをER図に書いたりします。
以上でデータモデリングの基本を終わりにします。
次は、このデータモデリングを元にSQL操作について書いていきます。