2009年11月16日 「実践編-12 実装形の作りかた」 を読む >> 目次にもどる

 

 文法 (生成規則・指示規則) に従って構成した モデル を できるかぎり そのままに実装するのが基本ですが、モデル を実装する際に、いくつかの調整点があります。その 「典型的な」 例として、以下の 3つを示していますが、それらのほかにも考慮したほうがいい点があります。

  (1) 対照表
  (2) サブセット
  (3) みなし entity

 以上の調整点については、「赤本」 の説明を読んでもらうとして、ほかの考慮点を以下に述べてみます。
 なお、サブセット の実装形は、「赤本」 で説明した やりかた 以外にも やりかた があるので、本 ホームページ の 「データ 設計に関する FAQ」 を参照してください (本 ホームページ の 213 ページ)。

 実装形を いったん作成したあとでも、多量 データ を ストア している テーブル に対して高 パフォーマンス を もとめられている場合には、その テーブル を分割する場合があります──ただし、「INDEX-only」 を使っている、という前提です。モデル を作成したときに、構文論的・意味論的に完全である テーブル は、その状態が 「最小の意味単位」 なのですが、高 パフォーマンス を実現するために、意図的に いっそう分割する、ということです──したがって、「(完結した) 意味」 を崩した状態を作る、ということです。

 たとえば、以下の テーブル を使って、意図的な テーブル 分割を説明してみます。

 TABLE
  ( a, b, c, e, f ).

 「INDEX-only」 を前提にします。この テーブル に対して、index-key が すでに 5つ定義されている、とします。
 たとえば、以下のような index-key が定義されている、とします。

  ( a, b, c, e, f ).

  ( b, e ).

  ( c, f ).

  ( a, c ).

  ( f ).

 ちなみに、(使っている コンピュータ の CPU や メモリー 量にも依りますが、) ORACLE や DB2 では、高 パフォーマンス を実現するのであれば、UPDATE の対象になっている ひとつの テーブル に対して index-key は 5つ以内にしたほうが良いでしょう──なお、SQL/Server や PostgreSQL では、3つに止めたほうがいいでしょう。この テーブル に対して、以下の view を もとめられた、とします。

  ( c, a, f ).

 勿論、「INDEX-only」 で対応します。しかし、この テーブル に対して、index-key は、すでに 5つ定義されているので、それ以上の index-key を定義すれば、パフォーマンス に影響するかもしれないので、テーブル を以下のように分割したほうがいいでしょう。

 TABLE-1
  ( a, c, f ).

 TABLE-2
  ( a, b, e ).

 これらの テーブル では、以下のような index-key が定義されます。

 TABLE-1 に対して、

  ( c, a, f ).

  ( c, f ).

  ( a, c ).

  ( f ).

 TABLE-2 に対して、

  ( b, e ).

 そして、TABLE-1 と TABLE-2 を a で join して、TABLE を 構成します。
 そうすれば、TABLE-1 と TABLE-2 は、それぞれ、index-key を 5つずつ定義できるので、さらに、それぞれの テーブル に対して view をもとめられても 「INDEX-only」 で対応できます──index-key を定義できます。

 上述した例は、説明を簡単にするために view を使って説明したのですが、UPDATE も 当然 考慮して テーブル を分割します── commit を考慮しなければならないので。実地の設計では、それぞれの データ 項目を見極めて テーブル を分割してください。本文で私が謂いたかった点は、高 パフォーマンス を実現するために、時として、「最小の意味単位」 を さらに分割することもある、ということです。現場では、それを標語にして以下のように云っています。

 「(高 パフォーマンス を実現するには、テーブル を) ちぎって、ちぎって、ちぎる」 □

 



  << もどる HOME すすむ >>
  目次にもどる