付録 D: SQL99 を提案する理由

• Java プログラムは、SQL 型の値を Java 言語の単一のデータ要素として取得します。たとえば、SQL の構造化された型のインスタンスは、1 回のメソッド呼び出し (getObject() メソッドなど) で単一のオブジェクトとして具体化できます。
  
  
• Java プログラムは、SQL の値を Java の「強く型付けされた」オブジェクトとして取得します。たとえば、構造化型のインスタンスは、フィールドまたはメソッドを持つクラスのオブジェクトとして具体化されます。 このオブジェクトのフィールドやメソッドは、基になっている特定の構造化型の属性に対応しており、プログラムでは、このフィールドやメソッドを使って、構造化型の属性にアクセスできます。
  
  
• クライアント側の Java プログラムは、Java 技術に「対応していない」データベースから、ユーザ定義の SQL 型の値を取得できます。そのデータベースは Java 言語をサポートしていなくてもかまいません。たとえば、Java のプログラムから構造化型のデータを取得するために、データベースで特別な定義は必要はありません。
  
  
• 特に構造化型の値は、SELECT 文を使って Java プログラムに取り出し、INSERT 文または UPDATE 文を使ってデータベースに送信します。 ほかの処理についても同様です。
  
  
• 構造化型の SQL メソッドはサーバで実行されて、構造化型のデータを SQL から Java プログラムに取り出す際の問題にメソッドは関係しません。
  
  
• ユーザ定義の SQL 型の定義は、SQL のカタログテーブルで見ることができます。同様に、Java クラスの定義は、そのクラスに対応した API をプログラムから呼び出して入手できます。したがって、データベースツールのベンダーは、特定のリレーショナルデータベースベンダーとは関係なく、SQL データのための Java クラス定義を生成するツール、またはその逆の定義を生成するツールを作成できます。SQL の型と Java クラスのマッピングは、サードパーティがそのようなツールを作成できるものでなければなりません。
  
  
• SQL のユーザ定義型と Java のクラスの間のマッピングは、普通、ツールを使って生成されるものと考えます。プログラマが「手動で」簡単に記述できることを考慮してマッピングを設計する必要はありません。
  
  
• 唯一の「正しい」マッピングとして、SQL の型と Java のクラスのマッピングを 1 つだけ定義することには、何の根拠もありません。特定の SQL ユーザ定義型に対して、マッピングツールで別の Java クラスを定義し、異なるアプリケーション領域または実行環境に応じることができます。このような異なるクラスは、プリミティブ属性に対する別の型マッピングや、特定のアプリケーションに関係する補助フィールドを持つことができます。SQL のユーザ定義型と Java クラスのマッピングでは、このような自由が認められていなければなりません。
  
  
• SQL のユーザ定義型のデータが、その属性の数と種類がわからない状態でも、Java のプログラムから「動的 SQL」のスタイルで取得できるようにします。
  
  
• SQL の構造化型は、別の構造化型のインスタンスを含む行を参照する REF(structured-type) 型の属性を含むことができます。この SQL REF は別の軽量 Java オブジェクトを含むフィールドと似てはいますが、同型ではありません。SQL REF はテーブルの行を示すキー値であり、一時メモリのオブジェクトを示すものではありません。
  
  
• SQL 型と Java クラスの 1 対 1 のマッピングを求める声が多くあります。Java クラスと SQL の間のマッピングツールが、弁別型、構造化型、REF 型 (構造化型)、配列型、Locator 型などに対して個別にクラスを生成するようになります。
  
  
• SQL 型と Java クラスのマッピングに柔軟性を持たせて、ツールを開発したり、ドメイン固有の「アプリケーションサービス層」を実装したりする場合に、SQL 型を実装する Java クラスをカスタマイズして値を追加できるようにする必要があります。特に、SQL の葉の属性および要素と、フィールドおよび値のマッピングにより、JDBC API で現在認められているすべての変換が可能になります。SQL の名前は、Java 言語の名前に自由にマッピングできます。SQL の値は、1 つの Java オブジェクト、またはオブジェクトのグラフで表現できます。