マテリアライズド・ビュー †
要約 †
マテリアライズド・ビューがどういうものか知ってるかもしれないが、まだ見たことがない人のために簡単に説明しよう。通常のビュー(非マテリアライズド・ビュー、仮想ビューなど)を知っている前提とする。
リレーショナルデータベースではビューが一般的で、「CREATE VIEW view name ...」とビューを作成後、SELECTクエリが続く（図5-13）。
図5-13. 非マテリアライズド（仮想）ビューは、単なるクエリのエイリアスである。ビューから読み込むと、データベースはそれを元になるクエリーに変換する。
このビューをデータベースで見ると、テーブルのように見える。他のテーブルと同様に、読み取りクエリで使用できる。そして、このビューからSELECT *を実行すると、データベースのクエリプランナは、ビューの定義で使用した元のクエリに書き換える。
したがって、ビューは一種の便利なエイリアス、抽象化を作成するラッパー、複雑なクエリを隠すシンプルなインターフェイス、と考えることができるが、パフォーマンスやデータストレージには影響しない。
ほとんど同じ構文を使用して定義されたマテリアライズド・ビューとは対照的である（図5-14を参照）。
図5-14。マテリアライズド・ビュー：構文は非常に似ているが、実装は全然違う。
もう一度、SELECTの観点からマテリアライズド・ビューを定義してみる。 CREATE VIEWの代わりにCREATE MATERIALIZED VIEWと定義するだけだ。しかし、実装は全く異なる。
マテリアライズド・ビューを作成すると、データベースは元となるテーブル、つまりビューのSELECT文で問い合わせしているテーブル（この例では「bar」）で始まる。データベースはこれらのテーブルの全内容をスキャンし、全てのデータに対してそのSELECTクエリを実行し、そのクエリの結果をテンポラリテーブルのようなものにコピーする。
このクエリの結果は、実際には通常のテーブルと非常によく似た形式でディスクに書き込まれる。これが「マテリアライズド(実体化された)」を意味しているものだ。：ビューのクエリが実行され、結果がディスクに書き込まれる。
非マテリアライズド・ビューでは、データベースは問い合わせ時にビューを元となる問い合わせに展開する、ということを思い出してほしい。一方マテリアライズド・ビューは、問い合わせるとビューの元となる問い合わせが事前に実行されているため、マテリアライズド・クエリー結果から直接内容を読み取ることができる。これは、元になるクエリが高コストな場合に特に便利である。
「これってクエリ結果のキャッシュなのでは」と思うかもしれないが、それは正しい。まさにそれだ。ただし、マテリアライズド・ビューとアプリケーションで管理されたキャッシュの大きな違いは、最新の状態に保っているかどうかである。
図5-15マテリアライズド・ビューは、キャッシュやセカンダリインデックスと同様に、元となるテーブルから派生した冗長データである。
マテリアライズド・ビューでは、マテリアライズド・ビューをどのように定義するかを一度宣言し、元となるテーブルの一貫したスナップショットからそのビューを構築する（図5-15のセカンダリインデックス作成と同様）。さらに元となるテーブルのデータが変更されると、データベースはマテリアライズド・ビューを更新する責任を負い、最新の状態に保つ。いくつかのデータベースでは、このマテリアライズド・ビュー・メンテナンスは継続的に行われ、ビューを定期的にリフレッシュして変更を有効にする必要があるものもあるが、アプリケーション・コードでキャッシュ無効化を行う必要はない。
アプリケーションで管理されたキャッシュの利点は、データをキャッシュに格納する前にデータに任意のビジネスロジックを適用して、クエリ時に作業を減らしたり、キャッシュする必要があるデータ量を削減できることである。マテリアライズド・ビューで同じ処理を実行するには、ストアドプロシージャとしてデータベース内のアプリケーションコードを実行する必要がある（図4-10）。第4章で議論したように、これは原理的には可能であるが、実際には動作上色々問題が起きることが多い。ただし、マテリアライズド・ビューは、キャッシュの並行性制御やブートストラップの問題に対処できる（図5-10）。
担当者のつぶやき †
みんなの突っ込み †
