9.13 設計上の考慮点のヒントおよび技法
Oracleのオブジェクト型を使用した作業の様々な側面において多種多様なヒントがあります。
内容は次のとおりです。
9.13.1 型進化かサブタイプの作成かの決定
アプリケーションがライフ・サイクルを終了するまでには、既存のオブジェクト型を変更するか、それとも、新しい要件を満たす特化されたサブタイプを作成するか、という問題が頻繁に発生します。その答えは、新しい要件の性質およびアプリケーションのセマンティクス全体でのコンテキストによって異なります。次に2つの例をあげて説明します。
広範囲に使用されているベース型の変更
属性Street
、State
、ZIP
を持つオブジェクト型address
があるとします。
CREATE TYPE address AS OBJECT ( Street VARCHAR2(80), State VARCHAR2(20), ZIP VARCHAR2(10)); /
後になって、世界各地の住所をサポートするためには、Country
属性を追加してaddress
型を拡張する必要性に気がつきます。address
のサブタイプの作成とaddress
型自体の進化とでは、どちらが得策でしょうか。
アプリケーション全体にわたって広範囲に使用されている一般的なベース型の場合は、型進化を通じて変更を実行することをお薦めします。
特化の追加
図形型(たとえば、曲線、円、正方形、テキスト)の既存の型階層に、追加のバリエーション、具体的にはベジエ曲線を格納する必要があるとします。ベース型の不足を反映しないこのような新しい特化をサポートするために、継承を使用して、Curve
型の下に、新しいサブタイプBezierCurve
を作成する必要があります。
つまり、必要とされる変更のセマンティクスによって、型進化を使用すべきか、それとも継承を使用すべきかが決まります。より全般的な変更で、ベース型に影響が及ぶ場合は、型進化を使用してください。より特化された変更に対しては、継承を使用して変更を実行してください。
9.13.2 ANYDATAとユーザー定義型の相違点
ANYDATA
はOracleによって提供される型で、任意のOracleデータ型のインスタンスを、組込み型かユーザー定義かにかかわらず保持できます。ANYDATA
は自己記述的な型で、インスタンスの形式を決定するために使用できるリフレクションに類似したAPIです。
代入性機能を通して、継承およびANYDATA
は、ともにプレースホルダ内に考えられるインスタンスの任意の集合を格納するポリモフィックな能力を備えていますが、この2つのモデルがその機能を提供する形式は異なります。
継承モデルの場合は、考えられるインスタンスのポリモフィックな集合は、単一の型の階層の一構成部分である必要があります。変数には、定義された型またはそのサブタイプのインスタンスのみを保持する潜在的な能力があります。スーパータイプの属性にアクセスして、そのサブタイプで定義されている(またサブタイプによってオーバーライドされる可能性のある)メソッドをコールできます。IS OF演算子およびTREAT演算子を使用して、あるインスタンスの具体的な型をテストすることもできます。
ただし、ANYDATA
変数は、異質なインスタンスを格納する可能性があります。インスタンスを抽出してしまわないかぎり、ANYDATA
変数に格納されている実際のインスタンスの属性にアクセスすることも、メソッドをコールすることもできません。該当するインスタンスの型を抽出するには、ANYDATA
メソッドを使用します。ANYDATA
は、ファンクション/プロシージャがパラメータの具体的な型には関心がない場合にパラメータの受渡しを行う場合に便利です。
継承は優れたモデリング、厳密な型指定、特化などを提供します。共通するものがあるとはかぎらない、任意の数の考えられるインスタンスのうちの1つを保持するのみの場合は、ANYDATA
を使用してください。
9.13.3 ポリモフィック・ビュー: オブジェクト・ビュー階層の代入
「オブジェクト・モデルのリレーショナル・データへの適用」では、それぞれが単一の型のオブジェクトを含んでいるオブジェクト・ビューの集合からビュー階層を構築する方法について説明しています。このようなビュー階層では、その階層内のビューに対する問合せによる、ビューまたはそのサブビューによって格納されたオブジェクトのポリモフィックな集合の参照が可能です。
このようなポリモフィックな問合せをサポートする代入の方法として、オブジェクトのポリモフィックな集合を戻す問合せに基づいてオブジェクト・ビューを定義できます。このアプローチは、あるビューを既存の表またはビューの集合にまたがって定義するときに特に便利です。
たとえば、Person_t
のオブジェクト・ビューを、Employee_t
インスタンスも含めたPerson_t
インスタンスを戻す問合せに対して定義できます。次の文からは、persons
表から個人を、employees
表から従業員を選択する問合せに基づいてビューが作成されます。
CREATE VIEW Persons_view OF Person_t AS
SELECT Person_t(...) FROM persons
UNION ALL
SELECT TREAT(Employee_t(...) AS Person_t) FROM employees;
このビューに対して定義されているINSTEAD OF
トリガーのかわりに、VALUE
ファンクションを使用して、現在のオブジェクトにアクセスでき、また、オブジェクトの最も具体的な型に基づいて適切なアクションをとることができます。
ポリモフィック・ビューとオブジェクト・ビュー階層には、次のような重要な相違点があります。
-
アドレス指定可能度: ビュー階層では、各サブビューは、問合せおよびDML文の中で別々に参照できます。したがって、特定の型のオブジェクトの各集合には、論理名があります。一方、ポリモフィック・ビューは単一のビューなので、特定の型のオブジェクトの集合を取得するには、述語を使用する必要があります。
-
進化: 新しいサブタイプを追加する場合は、既存のビュー定義を変更することなくビュー階層にサブビューを追加できます。ポリモフィック・ビューの場合は、別の
UNION
ブランチを追加することによって、単一のビュー定義を変更する必要があります。 -
DML文: ビュー階層では、各サブビューは、本質的に更新可能であるか、
INSTEAD OF
トリガーを持っているかのいずれかです。ポリモフィック・ビューの場合は、ビュー上の与えられた操作に対してINSTEAD OF
トリガーを1つのみ定義できます。
9.13.4 SQLJオブジェクト型
この項では、SQLJオブジェクト型について説明します。
内容は次のとおりです。
9.13.4.1 SQLJオブジェクト型の使用目的
『Information Technology - SQLJ - Part 2』ドキュメント(SQLJ規格)によると、SQLJオブジェクト型は、Java用に設計されたデータベース・オブジェクト型です。SQLJオブジェクト型はJavaクラスにマップされます。マッピングが拡張SQLのCREATE TYPE
コマンド(DDL文)によって登録されると、JavaアプリケーションでOracle JDBCドライバを通じて、Javaオブジェクトを直接またはデータベースから、挿入または選択できるようになります。したがって、ユーザーは、同じクラスを、クライアントではJDBCを使用して、サーバーではSQLメソッドのディスパッチによって、デプロイできます。
9.13.4.2 SQLJオブジェクト型作成時に実行されるアクション
拡張SQLのCREATE TYPE
コマンドは、次のことを行います。
-
データベース・カタログに属性、ファンクションおよびJavaクラスの外部名を移入します。また、Javaクラスとそれに対応するSQLJオブジェクト型間の依存関係は維持されます。
-
Javaクラスが存在することを検証し、また、それによって
USING
句の値に対応するインタフェースが実装されることも検証します。 -
Javaフィールドが(
EXTERNAL NAME
句で指定されているとおりに)存在すること、また、これらのフィールドが対応するSQL属性に対する互換性を検証します。 -
コンストラクタ、外部変数名、結果として
self
を返す外部ファンクションをサポートする内部クラスを生成します。
9.13.4.3 SQLJオブジェクト型の用途
SQLJオブジェクト型は、SQLオブジェクト型の特殊なケースで、すべてのメソッドがJavaクラスで実装されています。
Javaクラスと対応するSQL型間のマッピングは、SQLJオブジェクト型仕様によって管理されます。つまり、SQLJオブジェクト型仕様には、対応する型本体の仕様はありません。
また、SQLJオブジェクト型間の継承ルールによって、Javaクラス階層と対応するSQLJオブジェクト型階層の正しいマッピングが指定されます。これらのルールによって、SQLJ型階層に有効なマッピングが含まれていることが保証されます。したがって、SQLJオブジェクト型のスーパータイプまたはサブタイプは別のSQLJオブジェクト型である必要があります。
9.13.4.4 カスタム・オブジェクト型の用途
カスタム・オブジェクト型は、SQLオブジェクト型にアクセスするためのJavaインタフェースです。SQLオブジェクト型には、PL/SQL、Java、Cなどの言語で実装されたメソッドが含まれている場合があります。与えられたSQLオブジェクト型内のJavaで実装されたメソッドは、関連のない様々なクラスに属することができます。つまり、SQLオブジェクト型は特定のJavaクラスにマップされるわけではありません。
クライアントがこれらのオブジェクトにアクセスするには、Oracle JVM Webサービス・コールアウト・ユーティリティを使用して、対応するJavaクラスを生成します。さらに、ユーザーは、生成されたクラスを、対応するメソッドのコードで補強する必要があります。別の方法として、SQLオブジェクト型に対応するクラスを作成する方法もあります。
JDBCユーザーは、マップ内のSQL型名とそれに対応するJavaクラス間の対応関係を実行時に登録する必要があります。
9.13.4.5 SQLJオブジェクト型とJDBCを使用したカスタム・オブジェクト型の相違点
次の表は、SQLJオブジェクト型とカスタム・オブジェクト型の相違点の要約です。
表9-1 SQLJオブジェクト型とカスタム・オブジェクト型の相違点
特性 | SQLJオブジェクト型の動作 | カスタム・オブジェクト型の動作 |
---|---|---|
型コード |
|
|
作成 |
まず、 |
カスタム・オブジェクト型に対して拡張SQLの |
メソッド・サポート |
外部名、コンストラクタ・コール、副作用のあるメンバー・ファンクションへのコールをサポートします。 |
型メソッドをJavaメソッドとして実装するデフォルト・クラスはありません。一部のメソッドはSQLでも実装できます。 |
型マッピング |
型マッピングは、拡張SQLの |
型マップでのSQLとJavaの対応関係を登録します。対応関係にない場合、その型は |
継承 |
SQL階層をJavaクラス階層にマップするためのルールがあります。これらのルールの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
マッピング・ルールはありません。 |
9.13.5 その他の設計ヒント
Oracleオブジェクトの設計に関するその他のヒントを認識しておく必要があります。
9.13.5.1 階層内の列の置換え可能性と属性の数
列または表が型T
である場合は型T
の各属性に対して、列または表が代入可能な場合はT
の各サブタイプの各属性に対して、属性データを格納するために非表示列が追加されます。同様に、行の中のオブジェクト・インスタンスの型を追跡するため、非表示のtypeid
列も追加されます。
1つの表内の列の数は、1,000に制限されています。属性の合計数が1,000に迫っている型階層では、その階層内の型の置換え可能な列を使用しているときにこの制限を超えてしまうというリスクがあります。この結果発生する問題を回避するため、属性の合計数が大きい階層については、次のオプションのいずれかを検討してください。
-
ビューの使用
-
REF
の使用 -
階層の分割