質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.03%

論理設計と物理設計

解決済

回答 2

投稿

  • 評価
  • クリップ 0
  • VIEW 1,997
退会済みユーザー

退会済みユーザー

「達人に学ぶDB設計徹底指南書」(2012、ミック著)という本を読んでいたのですが、論理設計と物理設計の関係がよくわかっていません。
本に次のような記述があります。
「(中略)論理設計を物理設計に優先すべき、もう一つの理由があります。それは、パフォーマンスをはじめとする物理層に起因する問題は、いずれハードウェアによる解決が可能になっていくことが予想されるからです。先ほど、データベースに保持するデータ量は爆発的に増えるであろうという予測を述べました。この予測は、ほとんど外れようがありません。したがって、データベースに求められる性能要件もどんどんシビアになっていくこと自体は間違いありません。
著者が言いたいのは、その要件に対して、論理設計を犠牲にして応える必要はなくなるはずだ、ということです。現在のリレーショナルデータベースとハードウェアは、論理と物理のレベルを綺麗に分離できていません。そのため、論理での設計が物理レベルの構成にまで影響してしまっています。これは本来あってはならないことで、3層スキーマによる独立性も何もあったものではありません。
そして同時に、現在のDBMSは概念スキーマと内部スキーマの分離を完全には実現できていない、ということでもあります。見た目上、利用者からは内部スキーマを隠蔽したとしても、パフォーマンス悪化という形で、物理層の「ファイル」という無骨な岩肌が顔をのぞかせる。理想を言えば、そうした問題は物理層において解決すべき問題であって、論理層を汚すべきではないのです。」

上の文章において、「論理での設計が物理レベルの構成にまで影響してしまっている」という記述があるのですが、これは一体どういう意味なのでしょうか?
http://gihyo.jp/dev/feature/01/database/0001
こちらのサイトには
「物理設計の段階になって初めてデータベースとしての性能について考慮します。具体的には,論理設計において正規化したテーブルの定義を崩したり,インデックスを定義したりして性能が向上するようにモデルを修正していきます。また,物理設計では使用するデータベースに依存する機能を使用することもあります。」
とあるのですが、本で学んだ内容はまさにこのパフォーマンスを考慮した非正規化とデータの整合性のトレードオフに関してでした。
あるシステムがあって、そのシステムの論理設計が異なる場合、物理レベルの構成(おそらくファイルの場所等でしょうか?)は異なるのでしょうか?

またほとんど同じ内容だと思うのですが、「パフォーマンス悪化という形で、物理層の「ファイル」という無骨な岩肌が顔をのぞかせる。」という文章についてですが、「パフォーマンス悪化」というのは正規化を進めすぎて、テーブルの数が多いと多くの結合が必要となって、パフォーマンスを悪化させることを表現していると思います。
テーブルの結合が原因でパフォーマンスが悪化するときには、ファイルが顔をのぞかせるのでしょうか?
あくまで、予想なのですが、テーブルが異なればデータストレージ内では、違うファイルに格納されることになるから、この意味でファイルが顔をのぞかせる、と言っているのでしょうか?
はじめにあげた文章を受けて、皆さんがどのように思われるかお聞かせください。
回答お願いします。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • maisumakun

    2016/10/18 17:09

    「広告」という指摘は意味不明だと思うのですが…

    キャンセル

  • 退会済みユーザー

    2016/10/18 17:17

    こちらの質問が他のユーザから広告だという指摘を受けました
    個人のサービスやプロダクトなどの広告を目的とした投稿は、質問ではないため禁止しています。
    投稿した意図に反し広告と受け取られている場合は、「質問を編集する」ボタンから編集を行い、質問内容と解決したいことを明確に記述しなおしてください。

  • ikedas

    2016/10/18 18:39

    質問者の引用のしかたは公正な慣行の範囲内だと思いますし、引用した内容に対する考えや疑問をきちんと提示しておられます。仮に質問者がこの本の著者なのであれば、広告の意図があると言われても仕方ないでしょうが、質問内容からそれは考えにくいです。公刊された書物に書かれたことを公開の場で論じること自体には、問題はないと思います。

    キャンセル

回答 2

checkベストアンサー

0

考えを伺いたいとのことですので、当方の考えを述べたいと思います。

論理設計を優先のメリット

個人的に論理設計を優先した場合のメリットは以下が大きいかなと思います。

  • テーブルごとに分類することによる意図・用途の明確化(ただ下手すると逆に分かりにくくもなり得る・・・)
  • 正規化することによるデータ整合性の保証(ここは重要な所)
  • 比較的息の長いシステムを息の長いシステムを作れる(しっかり設計されデータ構造に歪みがなければ、保守・改善がしやすい面はある。テーブル構造が悪いとアプリケーション側からも扱い辛くなるという意味も。)

論理設計優先のデメリット

デメリットとしてはパッと思いついたのが以下となります。

  • テーブル数の増加
  • データ容量の増加
  • 管理コストの増大(資料メンテや物理設計をとの兼ね合いなど)

正規化する = パフォーマンス悪化ではない

話が少し横道にそれますが正規化について、
「正規化する = パフォーマンス悪化」という構図は必ずしも成立しません。

更新頻度が高いデータとなると、
逆に非正規化の状態のままでいる方がパフォーマンスが悪化する恐れがあります。
(更新時の行ロックを考えてもらえればと)

更新対象を正規化により分割することで、更新時のパフォーマンスを得ることが可能な点は知っておくとのいかもしれません。

逆にほとんど参照しかしないテーブルであれば、構図に当てはまり非正規化のままの方が参照テーブルが減るのでパフォーマンス的には有利となります。

ただし正規化を進めたとしても、
適切なキーが張られているならば、
パフォーマンス悪化はある程度抑止できます。

ファイルが顔をのぞかせるとは

一種の比喩表現となるのかなと思ってます。

正規化してテーブルを分けていった場合、嫌でも考慮しないといけないのが結合コストで、
データ数が少ない場合は問題にないのに、データが多くなってきたらある時を境にパフォーマンス酷く悪化する・・・この時はいやでも物理的な所を意識させられるよねってことかなと思います。

実際1つのテーブルのままだともっと早いのに、
同じ結果を得るのにどうしてこんなに時間がかかるんだという体験はDBをある程度触ってると嫌でも体感させられる時がやってきます^^;

蛇足

詳しい物理設計の説明については、
知識が乏しいため他の詳しい方からの説明待ちです・・・

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/10/18 23:27

    回答ありがとうございます。
    「ファイルが顔を覗かせる」という表現について言及なさっていますが、これは私が質問文であげたように、「(正規化したのちに、結合が必要になった時)それぞれのテーブルが別々のファイルに配置されてしまったがために、そのファイルにアクセスするためのディスクI/Oが生じるから、遅くなった(仮に正規化せずに一つにまとめていたら、一回のディスクI/Oで済むため正規化した場合に比べて高速)」ということなのでしょうか?

    キャンセル

  • 2016/10/19 05:16

    > billさん
    概ね認識通りかと思います。

    それぞれのテーブルが別々のディスクに保存してある場合はもちろん、同一ディスクでも表領域が異なれば物理的に保存されるファイルが異なるので、
    どちらもIOの面でパフォーマンス上不利となります。

    またそれ以外にパフォーマンスが悪化する要素として、
    そもそも結合するということは結合アルゴリズムでレコード同士を紐付ける処理は必ず発生するので、
    その意味でもパフォーマンス上は不利と言えそうです。

    それに対して1テーブルだと、
    適切に設計されていれば1行のレコード情報は必ず同一ブロック(DBMSの入出力単位)内に格納されているので、
    その意味でもパフォーマンス上有利なのかと思われます。
    (そこまで詳しくないのでブロック云々の話は認識間違いがあるかもしれませんが・・・)

    キャンセル

  • 2016/10/19 09:14

    回答ありがとうございました。

    キャンセル

0

他の資料でも言っていないかぐぐってみたらこの資料が見つかりました。

http://www.geocities.jp/mickindex/database/pdf/ClubDB2_20120713_mick.pdf
特に21ベージに書いてある内容が該当の箇所だと思われます。

ここらか論理設計の結果、テーブルがでか過ぎてレスポンスが悪くなったり、インデックスが効かなくなったり、スケールしなかったりすることがあるのを指摘しているのだろうな思います。

正規化してもでかいテーブルと言うが存在するのです。

実際に私も10年ほど前に日に1万件ずつ増えるテーブルを登録年ごとに水平分割したことがあります。今ではサーバのメモリに乗るサイズで、問題ないはずです。ハードウェアによる解決と言うやつですね。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/10/19 09:29

    kopioさん>
    やっばい!
    さらしていましたね。
    指摘ありがとうございます!

    キャンセル

  • 2016/10/19 17:41

    bill さん> 私が担当になった時点では、すでに水平分割されていたのでたしかなことは解りません。
    ただ、同じスキーマのテーブルを1セット容易して、そちらにインサートして、元のテーブルから削除するバッチ処理がありました。

    途中でテーブルの変更はあります。システムの更新に合わせ、主に項目追加やテーブルの追加があります。項目の削除は変更負荷が大きいため、いわゆる技術的負債になるとしても、正規化が行われないことも多いです。

    キャンセル

  • 2016/10/19 23:30

    回答ありがとうございました。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.03%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる