データベースで初めて触った部分がSQLだったので、設計についてはよく分からなかった。何冊か本も無理矢理流し読みした結果、分かった気になっていたが、もう１度ちゃんと勉強してみた。全部分かったわけでもないが、少しはましになったので、分かった範囲でまとめておく。もちろん、今後書き加えや書き直し、まとめ直すなどの作業は必須。
データベースの設計とは、最終的にデータベースの論理構造（テーブル構造や関係）をつくりあげること。その設計の上流工程をデータ・モデリングという。最終的にＥＲ図が書ければ良いのかな。
モデリングは、概念モデル作成（概念設計）、論理モデル作成（論理設計）、物理モデル作成（物理設計）の３つの手順でやる。リレーショナル・データベースの場合は物理設計はほとんど論理設計と同じ結果になるので省略されたりするらしい。
概念設計は業務概要に基づいてエンティティ（実体）などを抽出して，それらの間の関係を描いたモデル。実業務の中からトップダウン方式でエンティティをとらえたものです。
論理モデルは、概念モデルをシステム化の対象範囲に限定して詳細化したモデル。この項目を入力させようなどの画面や書類をなどをイメージしてつくる。
物理モデルは、パフォーマンスやプログラム処理などの観点から論理モデルの見直しを行ったモデル。パフォーマンスのためにフラグが多かったり、正規化したものをわざと前の状態に戻したりすることだと思われる。
僕の場合はどうも３つを行ったり来たりしながら設計していたような感じがする。実際のよく例に使われる図書館の貸し出しシステムなどを考えると全然わからなかった。エンティティの抜き出しすらできないのが現状。
概念設計のエンティティで抜き出すものは、名詞と動詞。名詞はリソースで人やモノが多い。しかし、図書館の例でもあったが、市民と利用者の区別など難しい。さらに市民は市に属しているという考え方だと、市が存在しないと市民としてありえないと考えたくなるが、実際はたまたまこの市に住んでいる人という考えたかをしないといけないようだ。だから、関係はあるが独立しているととらえないといけない。これは、通常の図書館と書籍の関係と同じになる。名詞的なエンティティ・リソース同士の、親子関係はあまりないのかもしれない。社員と扶養家族の関係なんかが例としてあげられる。社員がいないとその扶養家族（会社に申請している）はいないということになる。言葉だけの説明だと厳しいなぁ。分かりにくい説明になっていることが、ちゃんと理解しきっていないということを表している。ちなみに、名詞的エンティティと動詞的エンティティの親子関係はよく存在すると思う。図書館が存在しないと貸し出すことはありえないとなる。動詞的エンティティは、イベントエンティティと呼ばれる。図書館システムの場合、貸し出す、予約する、などとなる。
