概念モデル→論理モデルで気をつけていること

概念モデル→論理モデルで気をつけていること @_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

概念モデル→論理モデルで気をつけていること

概念モデル→論理モデルで気をつけていること

sunnyone

More Decks by sunnyone

Other Decks in Programming

Featured

Transcript