アプリケーション・データ使用量

この章では、データ・ユース・ケース・ドメインおよびスキーマ注釈について説明します。

データ・ユース・ケース・ドメイン

データ・ユースケース・ドメインは、スキーマに属している高レベルのディクショナリ・オブジェクトであり、一連のオプションのプロパティおよび制約をカプセル化します。

通常データベース側では、アプリケーションが実際にデータをどのような用途で使用しているかを理解していませんでした。データベースはVARCHAR2、NUMBER、DATEなどのプリミティブ型を使用してデータを格納しますが、格納された値が何を表しているかについての知識(クレジット・カード番号や生年月日など)はアプリケーション・レベルのメタ・データまたはコンテキストにしかありませんでした。このアプローチでは、個々のアプリケーションの複雑性が増し、ツールおよびアプリケーション全域で使用用途に関する認識が断片的になるほか、セマンティクスの相違が発生する可能性があります。

この相違に対処するための方法は、使用用途固有の組込みのデータ型をデータベースに追加し、ユーザー定義型に対して拡張のためのサポートを提供することでした。アプリケーション言語タイプとの不一致の増加や移植性のないアプリケーション・コードの作成、開発が複雑になる(様々な型にまたがる操作が制限されるため)といった理由から、より詳細なデータベース・タイプ・システムの採用は制限される傾向にありました。

このようなデータ使用目的の表現に対する制約は、SQL Standardの定義に従ってOracle AI Databaseの拡張ドメイン概念を使用することで回避できます。このアプローチを使用すると、NUMBERなどのプリミティブ・データ型と、「気温」や「信用スコア」といったデータ使用用途を表すドメインの両方から列を宣言できます。このようなユース・ケース・ドメインにはオプションで、チェック制約、表示プロパティ、順序付けルールなどの様々な使用目的プロパティを関連付けることができます。特筆すべきは、一元管理されるドメイン情報をアプリケーションで使用し、アプリケーション・レベルのメタ・データを必要とすることなく操作を標準化できるという点です。たとえば、クレジット・カード番号のマスク処理、電話番号や通貨値の書式設定、列内のパーセント値を円グラフとして表示するといったことが可能になります。

ユースケース・ドメインは基礎となるデータ型を変更しないため、既存のデータに追加してもアプリケーションを破壊したり移植性の問題を起こすことはありません。ユースケース・ドメインは表の1つ以上の列に対して宣言できるほか、データの実際の使用用途が他の列のデータによって決まる様々な使用用途シナリオを表現する際にも使用できます。ユースケース・ドメインは、アプリケーションを意図するデータ使用目的を一元的に文書化する軽量タイプの修飾子であると考えることができます。また、ユースケース・ドメインを使用して注釈を共有することもできます。

ユースケース・ドメインが関連付けられている表を削除すると、PL/SQLタイプが関連付けられている表を削除する場合と異なる結果になる場合があります。ユースケース・ドメインまたはPL/SQLタイプが関連付けられている表を削除する場合、次のルールが適用されます。

ユースケース・ドメインの特徴:

ユースケース・ドメインのタイプ:

厳密対非厳密:

列挙ドメインはOracle SQLを使用して作成できます。正規表現ドメインとは異なり、列挙ドメインにはデフォルトのCHECK制約と表示式があります。列挙ドメイン内の名前は、スカラーSQL式でリテラルが許可されている場所であればどこでも使用でき、SELECT文のFROM句でドメイン自体を表であるかのように使用できます。列挙ドメインは特殊なタイプの使用用途ドメインであり、任意の単一列ドメインと同様に使用できます。

列挙ドメインは、一連の名前と、オプションとして名前に対応する値で構成されます。名前は有効なSQL識別子である必要があり、指定される値はすべてリテラルであるか、複数列の列挙の場合はリテラルのリストである必要があります。値は、データ・ユース・ケース・ドメインでサポートされている任意のデータ型にできますが、すべての値が同じデータ型ある必要があります。

たとえば、あらかじめCREATE DOMAIN権限を付与されているユーザーSCOTTが、ジョブ・タイトルの単一列の列挙ドメインを作成します。

CREATE DOMAIN Job_Title AS
  ENUM (
    Clerk                  = 'CLERK',
    Salesman = SalesPerson = 'SALESMAN',
    Manager                = 'MANAGER',
    Analyst                = 'ANALYST',
    President              = 'PRESIDENT'
  );

EMP表の作成時に、ドメインJob_Titleをデータ型として使用できるようになりました。たとえば:

CREATE TABLE emp
( empno     NUMBER(4)     CONSTRAINT emp_pk PRIMARY KEY,
  ename     VARCHAR2(10),
  job       Job_Title,
  mgr       NUMBER(4)     CONSTRAINT emp_mgr_fk REFERENCES emp(empno),
  hiredate  DATE,
  sal       NUMBER(7,2)
);

新しいデータ行を挿入する場合、列挙されたドメインを使用してJOB列の値を指定できます。次の3つのINSERT文は同等です。

INSERT INTO emp VALUES (8000, 'PATEL', Job_Title.Salesman, 7698, TO_DATE('11-MAR-2024', 'DD-MON-YYYY'), 3500);
INSERT INTO emp VALUES (8000, 'PATEL', Job_Title.SalesPerson, 7698, TO_DATE('11-MAR-2024', 'DD-MON-YYYY'), 3500);
INSERT INTO emp VALUES (8000, 'PATEL', 'SALESMAN', 7698, TO_DATE('11-MAR-2024', 'DD-MON-YYYY'), 3500);

関連項目

スキーマ注釈

多くのアプリケーションでは、表、ビュー、表の列、索引、ドメインなどのデータベース・オブジェクトに関する追加のプロパティ・メタデータを保持することが重要です。

ドメインにはチェック制約、照合、カスタム・ソート順序などの組込みの使用用途プロパティが含まれていますが、拡張性の目的で、Oracleデータベースにはカスタム・プロパティを追加する機能も用意されています。カスタム・プロパティの追加にはデータベース・メタデータ(表の列、表、索引など)向けのANNOTATIONSメカニズムが使用されます。多くの場合、アプリケーションでは追加のプロパティ・メタデータを保持する必要があり、これによってユーザー・インタフェースのレンダリングやアプリケーション・ロジックのカスタマイズを行います。

列レベルの使用用途プロパティの例を次に示します:

同様に表レベルの使用用途プロパティも使用でき、表に機密情報を含めるかどうかや、どの表示名を使用するか、アプリケーション内のどのモジュールが所有または管理されるかといった情報をアプリケーション側で記録する際に役立ちます。

多くのアプリケーションはこのタイプの使用用途メタデータ用に独自のリポジトリを用意するため、開発者に複雑性をもたらし、アプリケーション、モジュールおよびマイクロサービス間の相違の可能性を生じさせます。

Oracle AI Databaseスキーマ注釈は、データベース・スキーマ・オブジェクトの使用状況プロパティを一元的に登録するための開発者向けの軽量な宣言機能です。注釈はデータベース内のディクショナリ表にデータ・モデル定義およびデータ自体とともに直接格納されます。アプリケーションはこれを使用して、共通データにわたる動作でありながらデータベースによって解釈されない動作を標準化できます。これは、カスタムの拡張使用用途プロパティを登録して処理するためにアプリケーションが使用する軽量のデータベース・メタデータ向け標準マークアップであると考えられます。

関連項目