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

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

• データ・ユースケース・ドメイン
  データ・ユースケース・ドメインは、スキーマに属し、一連のオプションのプロパティおよび制約をカプセル化する上位レベルのディクショナリ・オブジェクトです。
• スキーマ注釈
  多くのアプリケーションでは、表、ビュー、表の列、索引、ドメインなどのデータベース・オブジェクトに関する追加のプロパティ・メタデータを保持することが重要です。

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

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

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

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

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

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

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

• PURGE句を使用せずに表を削除した場合、潜在的な将来のリストアに備えて、その表は引き続きごみ箱に残されます(ごみ箱が有効な場合)。
• 表にPL/SQLタイプまたは抽象データ型を使用する列と、ユースケース・ドメインに関連付けられている別の列がある場合、次のようになります:
  • FORCE句を使用してユースケース・ドメインを削除しても、表はリストアできます。ユースケース・ドメインは単に列との関連付けが解除されます。
  • FORCE句の有無に関係なく、PL/SQLタイプを削除すると、完全にリストアできないため、表がごみ箱からパージされます。

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

• 制約 - ドメインを使用して、複数の表および列間で制約を共有できます。これらの制約は、遅延可能制約に対して無効にできます。ドメインでは、主キーおよび外部キー制約は許可されていません。
• データ型 - long、long raw、およびオブジェクト型を除いて、すべての組込みOracleデータ型が許可されます。
• デフォルト式 - デフォルト式を使用できますが、これは列のデフォルトと同じです。
• 大/小文字およびアクセントを区別しない検索 - ドメインでは、WHERE句およびORDER BY句で使用できる大/小文字を区別しない検索が可能です。
• 表示式 - 表示式ではカスタム表示ルールを使用できます。たとえば、通貨をローカル書式で表示します。
• 順序式 - 順序式では複雑な順序付けが可能です。たとえば、USドル金額などの正規化された標準ビジネス通貨による順序付けです。

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

• 単一列 - 単一データ列に適用されます。
• 複数列 - 通貨など、複数の列に適用されます。
• フレキシブル・ドメイン - 他のドメインに基づいており、サブドメインとの互換性のあるデータ型である必要があります。たとえば、様々な国の住所書式などです。
• 列挙 - 一連の名前と、オプションとして名前に対応する値で構成されます。

厳密対非厳密:

• 非厳密 - 非厳密ドメインは、指定されたデータ型と一致する必要がありますが、必ずしも数値データの長さやスケールとは限りません。
• 厳密 - データ型、長さおよびスケールが完全一致である必要があります。たとえば、厳密に2文字または3文字である必要がある通貨コードなどです。

列挙ドメインは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メカニズムが使用されます。多くの場合、アプリケーションでは追加のプロパティ・メタデータを保持する必要があり、これによってユーザー・インタフェースのレンダリングやアプリケーション・ロジックのカスタマイズを行います。

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

• 表示ラベル: 列名とは異なる場合があります(たとえば、Employee_Salaryという名前の列から「給与」というタイトルを表示する)。
• 列グループ: 多くの場合、「グループ」列はユーザー・インタフェースからの関心を引きます(たとえば、「通り番号」、「通り名」、「市区町村」および「郵便番号」列を「住所」グループにグループ化するための手段として)
• 書式マスク: たとえば、$99,999.99の表示マスクをユーザー・インタフェース・ツールで使用し、56434を$56,434.00としてレンダリングします
• 非表示: ユーザー・インタフェース上でエンド・ユーザーに列を表示するかどうか(たとえば、機密情報を含む列やシステムによって追加された列を特定の区分のエンド・ユーザーに表示しないなど)
• 強調表示: 列を特別な強調表示で表示するかどうか
• 許可される操作: ソート、グループ化、値リストの表示などを列でサポートするかどうかをインタフェース側で決定します。

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

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

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