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

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

新規登録して質問してみよう
ただいま回答率
85.50%
データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

Q&A

解決済

2回答

5734閲覧

論理設計と物理設計

退会済みユーザー

退会済みユーザー

総合スコア0

データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

2グッド

0クリップ

投稿2016/10/18 07:29

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

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

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

iwamoto_takaaki, kopio👍を押しています

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

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

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

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

maisumakun

2016/10/18 08:09

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

2016/10/18 09:39

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

回答2

0

ベストアンサー

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

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

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

#論理設計優先のデメリット
デメリットとしてはパッと思いついたのが以下となります。

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

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

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

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

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

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

#ファイルが顔をのぞかせるとは
一種の比喩表現となるのかなと思ってます。

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

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

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

投稿2016/10/18 12:48

Panzer_vor

総合スコア1636

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/10/18 14:27

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

2016/10/18 20:16

> billさん 概ね認識通りかと思います。 それぞれのテーブルが別々のディスクに保存してある場合はもちろん、同一ディスクでも表領域が異なれば物理的に保存されるファイルが異なるので、 どちらもIOの面でパフォーマンス上不利となります。 またそれ以外にパフォーマンスが悪化する要素として、 そもそも結合するということは結合アルゴリズムでレコード同士を紐付ける処理は必ず発生するので、 その意味でもパフォーマンス上は不利と言えそうです。 それに対して1テーブルだと、 適切に設計されていれば1行のレコード情報は必ず同一ブロック(DBMSの入出力単位)内に格納されているので、 その意味でもパフォーマンス上有利なのかと思われます。 (そこまで詳しくないのでブロック云々の話は認識間違いがあるかもしれませんが・・・)
退会済みユーザー

退会済みユーザー

2016/10/19 00:14

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

0

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

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

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

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

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

投稿2016/10/18 12:24

編集2016/10/19 00:27
iwamoto_takaaki

総合スコア2883

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/10/18 14:21

なるほど、そういったことがあるのですね。 初歩的な質問かもしれないですが、テーブルというのはどのような形でストレージに格納されるのでしょうか? 概念スキーマ内に、テーブルAとテーブルBの二つのテーブルがあったとして、実際のファイルとしてはどのような感じで格納されているのでしょうか? 何となく物理設計に詳しいような印象を受けたので、もしお分かりでしたら、教えてください。 そこが分かれば、「論理での設計が物理レベルの構成にまで影響してしまっています」がクリアにわかると思います。
iwamoto_takaaki

2016/10/18 15:01

クラウド環境では、ストレージは仮想的なものなので、並列化した複数の物理ストレージに保管され、容量の追加かんたんなので、複数の大きなテーブルも1つのファイルに保存出来るかもしれませんし、DBMSの機能で複数の論理ファイルをDB上では1つの領域として扱えるかもしれません。 ただ、私はクラウドや複数のサーバでDBを構成したことはないので、詳しい話は出来ません。それだけに、今とは違う切実な経験だといえるかもしれないので、書いてみます。 私が担当していたシステムは法的にデータの保存が必要だったものの、参照されることは無いデータが大量にありました。 ところが、毎日のInsert件数が1万件を超え、ストレージをどんどん圧迫してきました。 そこで、別ドライブがたまたま空いたのでそこに保存することになりました。 当時のOracleは7だったと思いますが、テーブル作成時に保存先のファイルを選択するようになっていました。つまり、テーブルを水平分割するしか保存方法がなかったのです。論理的には1つになるべきテーブルを稼働データと削除可能データとして分けて保存することになったのです。 削除可能データは稼働データとほぼおなじスキーマでなりたっていました。(今の私が設計したなら、削除可能データはテキストデータとして書き出します。) 余談ですが、当時はクラウドがなかったので、サーバを入れ替える際には物理的なサーバのコストに加えて、設置やOSミドルウェア・ネットワークなどの設定作業が大量にあり、移行作業のコストが今よりもずっと高かったためハードウェアの増強をする選択の優先順位は低かったのです。
退会済みユーザー

退会済みユーザー

2016/10/19 00:11

お返事ありがとうございます。 ちょっと掴めなかったのですが、テーブルを水平分割したのはシステムを稼働させてからの話ですか? はじめに稼働データと削除可能データが混ざった(論理的にはこれで正しい)テーブルがあって、ストレージが圧迫され始めたので、これを水平分割したということでしょうか? システムを稼働させた後に、テーブルの変更など可能なのでしょうか?
iwamoto_takaaki

2016/10/19 00:29

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

2016/10/19 08:41

bill さん> 私が担当になった時点では、すでに水平分割されていたのでたしかなことは解りません。 ただ、同じスキーマのテーブルを1セット容易して、そちらにインサートして、元のテーブルから削除するバッチ処理がありました。 途中でテーブルの変更はあります。システムの更新に合わせ、主に項目追加やテーブルの追加があります。項目の削除は変更負荷が大きいため、いわゆる技術的負債になるとしても、正規化が行われないことも多いです。
退会済みユーザー

退会済みユーザー

2016/10/19 14:30

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

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問