概念モデル→論理モデルで気をつけていること @_sunnyone / 2025-09-13 at 中国地方DB 勉強会 1 

自己紹介 Yoichi Imai (@_sunnyone) / Web アプリケーションエンジニア フロントエンド、DB 、インフラ DB ユーザー歴: PostgreSQL 7.4, 8 〜9.6 くらい、12 くらい、14 〜 MySQL 5.7 Oracle のことは忘れました 2 

宣伝 mcp-postgres-dump-schema を作りました。 https://zenn.dev/sunnyone/articles/7a138fc004731b 3 

今日話すこと 目次 データモデル（概念、論理、物理）について 概念モデルを論理モデルに落とすステップ Tips ActiveRecord パターンに親しんだアプリケーション開発者をターゲ ットにしたRDB の設計の話です 4 

データモデルの抽象度 階層 概要 概念データ モデル 業務の「ものごと」と関係の洗い出し、言葉合わせ。 論理データ モデル RDB に載せられる形への整理。主キー/ 外部キー、一意 性、正規化等、多重度の明確化等。 物理データ モデル 実装に配慮した構造の調整 5 

概念モデルを論理モデルに落とすステップ 6 

概念（しかも雑な状態）の例 例えば、日毎に読書本数を記録する例が概念モデルの中にあったとす る。 読書本数 ユーザーID: 整数 観測⽇: ⽇付 本数: 整数 7 

イベントを見出して分離する たいていリソースからイベントが見出されてないので、イベントを見 出す。イベントとリソースのイメージを作る。 8 

読書本数の例 読書本数の場合、何冊読んだかの情報を入力するというイベントが考 えられる。これが妥当な場合、以下のように分割できる。 読書本数 ユーザーID: 整数 観測⽇: ⽇付 本数: 整数 読書本数⼊⼒ 9 

ライフサイクルの違いを確認する 読書本数は今回の前提から日毎。一方で、読書本数の入力は日に1 回 と限らない（訂正したり、一気に入力したりする） 読書本数 ユーザーID: 整数 観測⽇: ⽇付 本数: 整数 読書本数⼊⼒ ユーザーID: 整数 ⼊⼒⽇時: ⽇時 10 

実際に必要な項目を埋める・分割する 論理構造まで考え始めると、記録する箇所が足りないことがある。今 回の例では、読書本数の入力が日の単位ではないので、読書本数とは 別のテーブルが必要になる。 読書本数 ユーザーID: 整数 観測⽇: ⽇付 本数: 整数 読書本数⼊⼒ ユーザーID: 整数 ⼊⼒⽇時: ⽇時 読書本数⼊⼒_本数 観測⽇: ⽇付 本数: 整数 足したものは、リソースの場合とイベントの場合がある。 11 

イベントとリソースの関連を検討する データ量やイベントの重要度によって、リソースとイベントの関連の させ方が異なる。 イベントの項目をID でポイントする ビューを作ってイベントを見る 重複保存する 12 

Tips 13 

単一責任に配慮して分割する 概念モデルの段階では複数の責務がひとつのクラスにある場合がある ので、このタイミングで分割する。 例えば、家庭の消耗品｛ティッシュ残量，洗剤残量｝のようなモデル が雑にあった場合、ティッシュの残量と洗剤の残量を同一テーブルと して記録するのが適切でない可能性がある。 14 

データのライフサイクルの違いを意識して分割 する ライフサイクルの違いも配慮して分割する。 例えば、ざっくり概念で睡眠記録｛入眠時刻，起床時刻｝があったと する。このままが適切な場合もあるが、寿命が異なる場合がある（例 えば入眠時刻のみ先に記録など）ので、適切に対処する。 15 

イベント→リソースの参照はおかしいことが多 い イベントは特性上消えないことが多いが、リソースは消えたり更新さ れたりするので、イベント→リソースの参照は不適切なことが多い。 16 

命名でリソース側かイベント側かわかるように する リソースかイベントかでざっくり違った配慮が出てくる。 例えば、イベントは追記で削除しない等。 配慮の違いを認識しやすいので、同一のリソースを扱うためのテーブ ルは、イベントのくくりなのかリソースのくくりなのか名前でわかる ようにしておくと便利。 例えば、 「本」と「本_ 売却」など。 17 

階層を混乱させる命名はしない リソースの名前に修飾されることが多くなるので、命名がどうしても 長くなりがち。 しかし、下手に省略すると階層が変わってしまうことがあり、後の解 読に影響を及ぼすので注意する。 木をたどるような命名、例えばa_b_c のようなつけかたをするケース で、a_c のように名付けると c がa の子のように誤認してしまう。 18 

Key やFK が変なときはテーブルに過不足がある 関連を考える際に、適切なリレーションが張れない場合、必要なテー ブルが足りなかったり、変な階層に存在していたりすることが多い。 過不足や階層の整理が不十分であることを疑う。 19