質問: 「達人に学ぶDB設計徹底指南書」(2012、ミック著)という本を読んでいたのですが、論理設計と物理設計の関係がよくわかっていません。 本に次のような記述があります。 「(中略)論理設計を物理設計に優先すべき、もう一つの理由があります。それは、パフォーマンスをはじめとする物理層に起因する問題は、いずれハードウェアによる解決が可能になっていくことが予想されるからです。先ほど、データベースに保持するデータ量は爆発的に増えるであろうという予測を述べました。この予測は、ほとんど外れようがありません。したがって、データベースに求められる性能要件もどんどんシビアになっていくこと自体は間違いありません。 著者が言いたいのは、その要件に対して、論理設計を犠牲にして応える必要はなくなるはずだ、ということです。現在のリレーショナルデータベースとハードウェアは、論理と物理のレベルを綺麗に分離できていません。そのため、論理での設計が物理レベルの構成にまで影響してしまっています。これは本来あってはならないことで、3層スキーマによる独立性も何もあったものではありません。 そして同時に、現在のDBMSは概念スキーマと内部スキーマの分離を完全には実現できていない、ということでもあります。見た目上、利用者からは内部スキーマを隠蔽したとしても、パフォーマンス悪化という形で、物理層の「ファイル」という無骨な岩肌が顔をのぞかせる。理想を言えば、そうした問題は物理層において解決すべき問題であって、論理層を汚すべきではないのです。」 上の文章において、「論理での設計が物理レベルの構成にまで影響してしまっている」という記述があるのですが、これは一体どういう意味なのでしょうか? http://gihyo.jp/dev/feature/01/database/0001 こちらのサイトには 「物理設計の段階になって初めてデータベースとしての性能について考慮します。具体的には,論理設計において正規化したテーブルの定義を崩したり,インデックスを定義したりして性能が向上するようにモデルを修正していきます。また,物理設計では使用するデータベースに依存する機能を使用することもあります。」 とあるのですが、本で学んだ内容はまさにこのパフォーマンスを考慮した非正規化とデータの整合性のトレードオフに関してでした。 あるシステムがあって、そのシステムの論理設計が異なる場合、物理レベルの構成(おそらくファイルの場所等でしょうか?)は異なるのでしょうか? またほとんど同じ内容だと思うのですが、「パフォーマンス悪化という形で、物理層の「ファイル」という無骨な岩肌が顔をのぞかせる。」という文章についてですが、「パフォーマンス悪化」というのは正規化を進めすぎて、テーブルの数が多いと多くの結合が必要となって、パフォーマンスを悪化させることを表現していると思います。 テーブルの結合が原因でパフォーマンスが悪化するときには、ファイルが顔をのぞかせるのでしょうか? あくまで、予想なのですが、テーブルが異なればデータストレージ内では、違うファイルに格納されることになるから、この意味でファイルが顔をのぞかせる、と言っているのでしょうか? はじめにあげた文章を受けて、皆さんがどのように思われるかお聞かせください。 回答お願いします。
回答: 考えを伺いたいとのことですので、当方の考えを述べたいと思います。 論理設計を優先のメリット ============ 個人的に論理設計を優先した場合のメリットは以下が大きいかなと思います。 * テーブルごとに分類することによる意図・用途の明確化(ただ下手すると逆に分かりにくくもなり得る・・・) * 正規化することによるデータ整合性の保証(ここは重要な所) * 比較的息の長いシステムを息の長いシステムを作れる(しっかり設計されデータ構造に歪みがなければ、保守・改善がしやすい面はある。テーブル構造が悪いとアプリケーション側からも扱い辛くなるという意味も。) 論理設計優先のデメリット ============ デメリットとしてはパッと思いついたのが以下となります。 * テーブル数の増加 * データ容量の増加 * 管理コストの増大(資料メンテや物理設計をとの兼ね合いなど) 正規化する = パフォーマンス悪化ではない ===================== 話が少し横道にそれますが正規化について、 「正規化する = パフォーマンス悪化」という構図は必ずしも成立しません。 更新頻度が高いデータとなると、 逆に非正規化の状態のままでいる方がパフォーマンスが悪化する恐れがあります。 (更新時の行ロックを考えてもらえればと) 更新対象を正規化により分割することで、更新時のパフォーマンスを得ることが可能な点は知っておくとのいかもしれません。 逆にほとんど参照しかしないテーブルであれば、構図に当てはまり非正規化のままの方が参照テーブルが減るのでパフォーマンス的には有利となります。 ただし正規化を進めたとしても、 適切なキーが張られているならば、 パフォーマンス悪化はある程度抑止できます。 ファイルが顔をのぞかせるとは ============== 一種の比喩表現となるのかなと思ってます。 正規化してテーブルを分けていった場合、嫌でも考慮しないといけないのが結合コストで、 データ数が少ない場合は問題にないのに、データが多くなってきたらある時を境にパフォーマンス酷く悪化する・・・この時はいやでも物理的な所を意識させられるよねってことかなと思います。 実際1つのテーブルのままだともっと早いのに、 同じ結果を得るのにどうしてこんなに時間がかかるんだという体験はDBをある程度触ってると嫌でも体感させられる時がやってきます^^; 蛇足 == 詳しい物理設計の説明については、 知識が乏しいため他の詳しい方からの説明待ちです・・・