「達人に学ぶDB設計徹底指南書」(2012、ミック著)という本を読んでいたのですが、論理設計と物理設計の関係がよくわかっていません。
本に次のような記述があります。
「(中略)論理設計を物理設計に優先すべき、もう一つの理由があります。それは、パフォーマンスをはじめとする物理層に起因する問題は、いずれハードウェアによる解決が可能になっていくことが予想されるからです。先ほど、データベースに保持するデータ量は爆発的に増えるであろうという予測を述べました。この予測は、ほとんど外れようがありません。したがって、データベースに求められる性能要件もどんどんシビアになっていくこと自体は間違いありません。
著者が言いたいのは、その要件に対して、論理設計を犠牲にして応える必要はなくなるはずだ、ということです。現在のリレーショナルデータベースとハードウェアは、論理と物理のレベルを綺麗に分離できていません。そのため、論理での設計が物理レベルの構成にまで影響してしまっています。これは本来あってはならないことで、3層スキーマによる独立性も何もあったものではありません。
そして同時に、現在のDBMSは概念スキーマと内部スキーマの分離を完全には実現できていない、ということでもあります。見た目上、利用者からは内部スキーマを隠蔽したとしても、パフォーマンス悪化という形で、物理層の「ファイル」という無骨な岩肌が顔をのぞかせる。理想を言えば、そうした問題は物理層において解決すべき問題であって、論理層を汚すべきではないのです。」
上の文章において、「論理での設計が物理レベルの構成にまで影響してしまっている」という記述があるのですが、これは一体どういう意味なのでしょうか?
http://gihyo.jp/dev/feature/01/database/0001
こちらのサイトには
「物理設計の段階になって初めてデータベースとしての性能について考慮します。具体的には,論理設計において正規化したテーブルの定義を崩したり,インデックスを定義したりして性能が向上するようにモデルを修正していきます。また,物理設計では使用するデータベースに依存する機能を使用することもあります。」
とあるのですが、本で学んだ内容はまさにこのパフォーマンスを考慮した非正規化とデータの整合性のトレードオフに関してでした。
あるシステムがあって、そのシステムの論理設計が異なる場合、物理レベルの構成(おそらくファイルの場所等でしょうか?)は異なるのでしょうか?
またほとんど同じ内容だと思うのですが、「パフォーマンス悪化という形で、物理層の「ファイル」という無骨な岩肌が顔をのぞかせる。」という文章についてですが、「パフォーマンス悪化」というのは正規化を進めすぎて、テーブルの数が多いと多くの結合が必要となって、パフォーマンスを悪化させることを表現していると思います。
テーブルの結合が原因でパフォーマンスが悪化するときには、ファイルが顔をのぞかせるのでしょうか?
あくまで、予想なのですが、テーブルが異なればデータストレージ内では、違うファイルに格納されることになるから、この意味でファイルが顔をのぞかせる、と言っているのでしょうか?
はじめにあげた文章を受けて、皆さんがどのように思われるかお聞かせください。
回答お願いします。
回答2件
あなたの回答
tips
プレビュー