データベースアプリケーションのパフォーマンスにおける7つの大罪（続き）～ 第一の大罪 ( SAP SQL Anywhere )

この記事のオリジナルは、Glenn Paulley が sybase.com に2011年4月に掲載したものです。Glenn はこの中で、データベース設計における重要なコンポーネントについて、それらがどうアプリケーションのパフォーマンスに影響を与えるのか語っています。

以前の記事でデータベースアプリケーションのパフォーマンスにおける7つの大罪を紹介しました。

第一の大罪は”データベースの物理設計”に関するもので、たとえばスキーマ設計の問題、テーブルの列の順序、インデックス付け、データベースページサイズの選択など、パフォーマンスに悪影響を及ぼしかねない重要な要因はいくつも考えられます。

今回の記事では、SQL Anywhere のデータベース設計にまつわる具体的な問題と、ドメイン（定義域）の概念に関する内容を取り上げていきます。

ドメイン（定義域）とは

ドメインの概念は、E. F. Coddが発案した最初のリレーショナルデータモデルに含まれています。Chris Dateは、彼の重要な著書 [1, pp. 81] の中でドメインを次のように定義しています。

  　次に、ドメインという言葉を、すべて同じ型の、スカラー値の名前付きの集合と定めることにする。たとえば、サプライヤー番号のドメインは、サプライヤー番号として取り得るすべての番号の集合になり、出荷数量のドメインは、ゼロより大きく（たとえば）10,000より小さいすべての整数の集合になる。このように、ドメインとは値のプールであり、その中から実際の属性値が抽出される。

簡単に言うと、Coddが定義したリレーショナルモデルのドメインとは、プログラミング言語の”強い型付け”の定義のようなものです。

プログラミング言語の場合と同様、ドメインを使用する1つの目的は、アプリケーション開発者が、たとえば納品伝票番号と顧客番号を比較するような間違いを犯さないようにすることです。

どちらの集合の値も（おそらくは）整数ですが、納品伝票番号と顧客番号を比較しても、普通はほとんど意味がありません。

理屈はともあれ、商用のリレーショナルデータベース製品では、ドメインの機能は過去40年間ほとんど注目を集めてきませんでした。

たしかに、SQL Anywhereを含むほぼすべての商用データベースシステムではDOMAINの定義（ユーザー定義データ型と呼ばれることもあります）がサポートされていますが、これらのDOMAINの実装と、リレーショナルモデルのドメインが意図するところでは大きな違いがあります。

ほとんどすべての商用RDBMSシステムでは、柔軟な型指定が許されています。

たとえばSQL Anywhereでは、数値列と文字列の比較を含むSQLステートメントが問題なく実行されます。

Ivan Bowmanが書いたホワイトペーパー（PDF）では、整合性のない比較を評価しなければならないときにSQL Anywhereで行われる暗黙的な型変換のセマンティクスの概要が示されています
（余談： 商用の製品には、それぞれ独自の暗黙的な変換規則があり、そうした比較のセマンティクスは実装依存です）。

このような柔軟性は、アプリケーション開発者からすると利点に見えるかもしれませんが、実際は罪なのです。その理由を説明しましょう。

SQL はプログラミング言語ではない

アプリケーション開発者は、SQLが「タプル関係計算」に基づくデータ特殊言語であることを肝に銘じておくことがきわめて重要です。
簡単に言うと、SQLは一階述語論理に基づいており、クエリでは演算の”対象”を指定するだけで、”方法”は指定しないということです。

（続きは、翔泳社　CodeZine に掲載されていますので、そちらをご覧ください。）

データベースアプリケーションのパフォーマンスにおける7つの大罪（続き）～ 第一の大罪 ( SAP SQL Anywhere )

SAPの SAP SQLAnywhere製品ページはこちら