6 JSONスキーマ
JSON文書の構造と型情報を検証するために、JSONスキーマを作成できます。データは、スキーマ妥当なデータのみがJSON列に挿入されるように、その場で検証することも、チェック制約を使用して検証することもできます。
ほとんどのJSONデータの使用は、スキーマレスです。JSONデータを使用するアプリケーションは、変更の要件にすばやく対応できます。アプリケーションは、それが使用している記憶域スキーマを変更することなく変更および再デプロイできます。
ただし、JSONデータの一部をスキーマに準拠させることが必要になる場合があります。特定の列に格納されるすべてのデータがスキーマで定義された構造になっていることを確認することも、このような構造が特定のJSON文書にあるかどうかを確認してから処理することもできます。
JSONスキーマは、Request For Comments (RFC)ドラフトであるJSONスキーマ標準を尊重するJSON文書です。
JSONスキーマを使用して、他のJSON文書を記述または検証できます。json-schema.orgを参照してください。JSONスキーマでは、妥当とみなされるJSONデータの構造と許可される値の型を指定します。「妥当性」は、常に特定のスキーマに関するものです。(その一方で、「整形式の性質」は単に構文的に正しいことを意味します)。
Oracle DatabaseでサポートされているJSONスキーマは、自己完結型です。別のJSONスキーマを含めることもインポートすることもできません。(そうしようとすると、そのために使用するスキーマ・キーワードは、ユーザー定義のキーワードであるかのように単に無視されます。)ただし、適切に定義されたアプリケーション使用方法ドメインをJSONスキーマとして使用できます。また、ドメインは別のドメインのエクスポートおよびインポートが可能です。(依存関係の追跡と進化も可能になります)。
これは、標準フィールド(キーワード)のみを使用する単純なJSONスキーマの例です。
{"type" : "object",
"properties" : {"firstName" : {"type" : "string",
"minLength" : 1},
"salary" : {"type" : "number",
"minimum" : 10000}},
"required" : ["firstName"]}
妥当な文書が、フィールドfirstName
およびオプションのフィールドsalary
を持つJSONオブジェクトであることを指定します。このオブジェクトには、1文字以上の文字列であることが必要な必須のfirstName
フィールドと、オプションであるが存在する場合は10,000以上の数値であることが必要なsalary
フィールドとは別に、追加のフィールドを含めることができます。
- JSONスキーマを使用したJSON文書の検証
JSONスキーマでは通常、他のJSON文書の許可された構造およびデータ型(そのスキーマに関する妥当性)を指定しますそのため、JSONスキーマの通常の用途は、JSONデータを検証することになります。 - 拡張スカラー値への型キャストを使用したJSONスキーマ検証
JSON
型の列のIS JSON
チェック制約でVALIDATE
CAST
を使用すると、JSONスキーマに対応するために、挿入するデータをOracle固有のJSON言語スカラー値に自動的に型キャストできます。たとえば、ISO 8601日付文字列をJSON日付値に変換できます。 - JSONスキーマの生成
JSONスキーマは、既存の一連のJSON文書から、または他のデータベース・オブジェクト/データから生成(作成)できます。 - DBMS_JSON_SCHEMA.DESCRIBEで生成されたJSONスキーマ
このマッピングは、PL/SQLファンクションDBMS_JSON_SCHEMA.describe
が、データベース表、ビュー、JSONリレーショナル二面性ビュー、オブジェクト型インスタンス、コレクション型インスタンス(VARRAYまたはネストした表)またはドメインからJSONスキーマを生成するために使用するものとして記述されています。 - 列チェック制約が事前チェック可能かどうかの明示的な宣言
表を作成または変更するときに、個々の列チェック制約を明示的に宣言して、データベースの外部で事前チェック可能(または不可)にできます。事前チェック可能と宣言した制約が実際には事前チェック可能でない場合は、エラーが発生します。
関連項目:
-
『Oracle Database概要』のアプリケーション使用方法ドメイン
-
『Oracle Database開発ガイド』のSQLドメインを使用したJSONデータの検証
親トピック: JSONデータの格納および管理
6.1 JSONスキーマを使用したJSON文書の検証
JSONスキーマでは通常、他のJSON文書の許可された構造およびデータ型(そのスキーマに関する妥当性)を指定しますそのため、JSONスキーマの通常の用途は、JSONデータを検証することになります。
JSONデータは、JSONスキーマに対して次のいずれかの方法で検証できます。
-
条件
is JSON
(またはis not JSON
)を使用し、キーワードVALIDATE
とJSONスキーマの名前を指定して、対象となるデータがそのスキーマに対して有効(または無効)であるかどうかをテストします。スキーマは、リテラル文字列またはアプリケーション使用方法ドメインとして指定できます。キーワードVALIDATE
の後にはオプションでキーワードUSING
を指定することもできます。条件
is json
のVALIDATE
は、その条件が使用可能な任意の場所で使用できます。これには、WHERE
句での使用やチェック制約としての使用が含まれ、それにより有効なデータのみが列に挿入されるようにします。例6-1に、WHERE
句でのその使用方法を示します。JSON
型の列のチェック制約として使用する場合は、is json
を省略して、キーワードVALIDATE
のみを直接使用することもできます。JSON
型の列の場合、次の2つの表作成は同等です。CREATE TABLE tab (jcol JSON VALIDATE '{"type" : "object"}');
CREATE TABLE tab (jcol JSON CONSTRAINT jchk CHECK (jcol IS JSON VALIDATE '{"type" : "object"}'));
VALIDATE
を条件is JSON
とともに使用する場合、JSONスキーマで、挿入するデータ内のフィールドが日付などのOracle固有のJSON言語スカラー型のextendedType
要件を満たす必要があると指定されている場合、デフォルトでは、その型ではないスカラー値によって、必要な型に対して値が型キャストできる場合でも挿入が失敗します。ただし、
VALIDATE
をキーワードCAST
と一緒に使用すると、可能であればそのような型キャストが実行されます。たとえば、サポートされているISO 8601日時形式の入力文字列は、JSON言語の日付スカラー値に自動的にキャストできます。拡張スカラー値への型キャストを使用したJSONスキーマ検証を参照してください。 -
JSON
型データのチェック制約としてドメインを使用します。次に例を示します。CREATE DOMAIN jd AS JSON CONSTRAINT jchkd CHECK (jd IS JSON VALIDATE '{"type" : "object"}');
CREATE TABLE jtab(jcol JSON DOMAIN jd);
スキーマからドメインを作成するときには、制約と
is json
を省略して、キーワードVALIDATE
のみを使用することもできます。このドメイン作成は、前のものと同等です。CREATE DOMAIN jd AS JSON VALIDATE '{"type" : "object"}';
-
パッケージ
DBMS_JSON_SCHEMA
に含まれているPL/SQLファンクションまたはプロシージャis_valid
を使用します。このファンクションは、SQL問合せで使用できます。データが有効な場合は1
、無効な場合は0
が返されます。プロシージャは、有効か無効かを示すOUT
パラメータと、妥当性(true
またはfalse
)および不当性の理由についての完全な情報を提供するJSONオブジェクトを返す別のOUT
パラメータを返します。たとえば、このプロシージャを使用すると、スキーマ
myschema
(JSON
)に対してデータmyjson
(JSON
)がチェックされ、パラメータvalidity
(BOOLEAN
)およびerrors
(JSON
)に出力されます。DBMS_JSON_SCHEMA.is_valid(myjson, myschema, validity, errors);
-
プロシージャ(関数ではない)
is_valid
を使用する場合、OUT
パラメータとして検証エラー・レポートにアクセスできます。関数is_valid
を使用する場合、このようなレポートにアクセスできません。関数is_valid
を使用するかわりにSQL問合せでPL/SQLファンクションDBMS_JSON_SCHEMA.validate_report
を使用して、プロシージャis_valid
のOUT
パラメータで提供されるものと同じ完全な検証情報を検証して、JSON
型のインスタンスとして返すことができます。この関数が入力として受け入れるJSONデータは、データ型JSON
またはVARCHAR2
(CLOB
またはBLOB
ではない)のいずれかになります。たとえば、この問合せは、2番目の引数であるJSONスキーマに対して最初の引数であるテキストJSON文書の検証を試み、検証レポートを
myreport
として返します。SELECT DBMS_JSON_SCHEMA.validate_report('{"name" : "scott", "role" : "developer"}', '{"type" : "array"}') AS myreport;
-
PL/SQL
JSON_ELEMENT_T
のブール・メソッドschema_validate()
を使用します。これは、JSON
、VARCHAR2
またはJSON_ELEMENT_T
型の引数としてJSONスキーマを受け入れます。たとえば、
d
がJSON_ELEMENT_T
型のPL/SQLインスタンスの場合、このコードは、引数として渡されたJSONスキーマに対してJSONデータd
が有効(TRUE
)か無効(FALSE
)かを示すBOOLEAN
値を返します。つまり、データがJSONオブジェクトかどうかをチェックします。isvalid := d.schema_validate('{"type" : "object"}');
JSONスキーマ自体がJSONスキーマとして定義されます。このスキーマは、JSONスキーマ標準で許可されたものを妥当なJSONスキーマとして定義します。つまり、どのような形式のJSON文書がJSONスキーマであるかを定義することになります。PL/SQLファンクションDBMS_JSON_SCHEMA.is_schema_valid
を使用すると、JSONスキーマを検証できます。つまり、JSONスキーマ定義スキーマに対して検証するということです。
静的ディクショナリ・ビューDBA_JSON_SCHEMA_COLUMNS
、ALL_JSON_SCHEMA_COLUMNS
およびUSER_JSON_SCHEMA_COLUMNS
では、チェック制約として使用できるJSONスキーマが示されます。
これらのビューの各行には、表の名前、JSON列、JSONスキーマによって定義された制約、JSONスキーマ自体、およびJSONスキーマに対してキャスト・モードが指定されているかどうかが示されます。ビューDBA_JSON_SCHEMA_COLUMNS
およびALL_JSON_SCHEMA_COLUMNS
には、表所有者の名前も含まれています。
例6-1 条件IS JSONでのJSONスキーマに対するJSONデータの検証
この問合せでは、示されているリテラルJSONスキーマに対して検証するデータのみが選択されています。ここでは、フィールドPONumber
の数値が0
以上である必要があります。
これは、列j_purchaseorder
がスキーマ検証チェック制約なしで作成された場合でも機能します。
SELECT po_document
FROM j_purchaseorder
WHERE po_document IS JSON VALIDATE
'{"type" : "object",
"properties" : {"PONumber": {"type" : "number",
"minimum" : 0}}}'
関連項目:
-
『Oracle Databaseリファレンス』のALL_JSON_SCHEMA_COLUMNS
-
JSONスキーマを使用して二面性ビューの基礎となる格納
JSON
型データを制約する方法については、JSONリレーショナル二面性開発者ガイドのJSONリレーショナル二面性ビューに格納されているJSONデータ -
『Oracle Database概要』のアプリケーション使用方法ドメイン
-
『Oracle Database開発ガイド』のSQLドメインを使用したJSONデータの検証
親トピック: JSONスキーマ
6.2 拡張スカラー値への型キャストを使用したJSONスキーマ検証
JSON
型列のIS JSON
チェック制約でVALIDATE
CAST
を使用する場合、JSONスキーマに対応するために、挿入するデータをOracle固有のJSON言語スカラー値に自動的に型キャストできます。たとえば、ISO 8601日付文字列をJSON日付値に変換できます。
JSONスキーマで、挿入するデータ内のフィールドが特定のOracle固有スカラー型のextendedType
要件を満たす必要があると指定されている場合、デフォルトでは、その型ではないスカラー値によって、必要な型に対して値が型キャストされる場合でも挿入が失敗します。ただし、VALIDATE
をキーワードCAST
と一緒に使用すると、可能であればそのようなスカラー型キャストが実行されます。
例6-2 IS JSONチェック制約で型キャストを使用したJSONスキーマ検証
-- Constrain dataOfBirth to be of scalar type date.
CREATE TABLE mytable (
jcol JSON VALIDATE
'{"type" : "object",
"properties" : {"dateOfBirth" : {"extendedType" : "date"}}}');
-- Try to insert dataOfBirth field with ISO date string.
INSERT INTO mytable VALUES ('{"dateOfBirth" : "2018-04-11"}');
ERROR at line 1:
ORA-40875: JSON schema validation error
CREATE OR REPLACE TABLE mytable (
jcol JSON VALIDATE CAST
'{"type" : "object",
"properties" : {"dateOfBirth" : {"extendedType" : "date"}}}');
INSERT INTO mytable VALUES ('{"dateOfBirth" : "2018-04-11"}');
1 row created.
-- Query with item-method type() shows the value is a DATE.
SELECT d.jcol.dateOfBirth.type() FROM mytable d;
D.JCOL.DATEOFBIRTH.TYPE()
-------------------------
date
6.3 JSONスキーマの生成
JSONスキーマは、既存の一連のJSON文書から、または他のデータベース・オブジェクト/データから生成(作成)できます。
JSON文書からJSONスキーマを生成する場合、スキーマは階層JSONデータ・ガイド(文書内のよくあるフィールドが説明されているフィールド(JSONスキーマおよびOracle固有)を含むJSON文書)になります。
通常、データ・ガイドは、既存の一連のJSON文書について構造を理解する手掛かりとなります。通常、生成されたままでは検証目的には適していませんが、検証に使用するために手作業で定義したスキーマの基準として利用できます。
「データ・ガイドの形式およびデータ・ガイドの作成方法」と表23-2を参照してください。
JSONスキーマを一連のJSON文書から生成するかわりに、他のデータベース・データから生成できます。これを行うには、PL/SQLファンクションDBMS_JSON_SCHEMA.describe
を使用し、次のいずれかを渡してスキーマを定義します。
-
既存のリレーショナル表、ビューまたはJSONリレーショナル二面性ビュー。JSONスキーマ内のオブジェクトに対応します。データベース表、ビューまたは二面性ビューからJSONスキーマへのマッピングは、表6-1を参照してください。
生成されたスキーマは、表、ビューまたは二面性ビューに依存しません。そのデータベース・オブジェクトの定義は、スキーマが生成される場合にのみ使用されます。後でオブジェクト定義を変更しても、スキーマには影響しません。
-
既存のSQLユーザー定義オブジェクト型インスタンスまたはコレクション型インスタンス(VARRAYまたはネストした表)。オブジェクト型インスタンスは、JSONスキーマ内のオブジェクトに対応します。コレクション型インスタンスは、JSON配列に対応します。オブジェクト型またはコレクション型のデータベース・インスタンスからJSONスキーマへのマッピングは、表6-1を参照してください。
生成されたスキーマは、オブジェクトまたはコレクションの型に依存しません。型の定義は、スキーマの生成時にのみ使用されます。その後で型の定義を変更しても、スキーマには影響しません。
記述するオブジェクト型インスタンスのタイプが別のオブジェクト型のサブタイプである場合、生成されたスキーマ(記述)には、スーパータイプから継承された属性に対応するフィールドがすべて含まれます。
-
アプリケーション使用方法ドメイン。
ドメインを使用すると、特定の型のデータの用途を示すことができます。ドメインの仕様には、データ型、デフォルト値、照合仕様、チェック制約、表示形式、目的の順序付けおよびドメイン記述のメタデータをJSON形式で含めることができます。ドメインはサブタイプを定義しません。ドメイン自体は、それが知らせるデータ型に対して実行できる操作を制限しません。
たとえば、ドメインでは、特定の
VARCHAR2
列に電子メール・アドレスを格納するように指定できます。チェック制約として、関連する使用制約と検証ルールを強制適用できます。 -
SQL表、ビュー、オブジェクト型、コレクション型、ドメインまたは二面性ビュー用のSQLシノニム。
結果のJSONスキーマは、表、ビュー、オブジェクト型、コレクション型、ドメインまたは二面性ビューから生成されたものと同じです。
データベース表、ビュー、オブジェクト型またはコレクション型からJSONスキーマへのマッピングについては、「DBMS_JSON_SCHEMA.DESCRIBEで生成されたJSONスキーマ」を参照してください。
関連項目:
-
『Oracle Database概要』の表の概要に関する項およびビューの概要に関する項
-
『JSONリレーショナル二面性開発者ガイド』の「JSONリレーショナル二面性ビューの概要」
-
コレクション型およびユーザー定義のオブジェクト型の詳細は、それぞれ『Oracle Database PL/SQL言語リファレンス』の「PL/SQLのコレクションとレコード」およびCREATE TYPE文に関する項を参照してください
-
『Oracle Database概要』のアプリケーション使用方法ドメイン
-
『Oracle Database SQL言語リファレンス』のCREATE DOMAINに関する項
親トピック: JSONスキーマ
6.4 DBMS_JSON_SCHEMA.DESCRIBEで生成されたJSONスキーマ
このマッピングは、PL/SQLファンクションDBMS_JSON_SCHEMA.describe
が、データベース表、ビュー、JSONリレーショナル二面性ビュー、オブジェクト型インスタンス、コレクション型インスタンス(VARRAYまたはネストした表)またはドメインからJSONスキーマを生成するために使用するものとして記述されています。
データベース・シノニムからのスキーマの生成は、同義のデータベース・オブジェクトからのスキーマの生成と同じです。たとえば、表のシノニムから生成されたJSONスキーマは、その表から直接生成されたスキーマと同じです。
表6-1では、データベース・オブジェクト(表、ビュー、JSONリレーショナル二面性ビュー、オブジェクト型インスタンスまたはコレクション型インスタンス)の一般プロパティから・JSONスキーマ・フィールドへのマッピングを指定します。
Oracle固有のJSONスキーマ・フィールドは、dbColumn
、dbConstraintExpression
、dbConstraintName
、dbDomain
、dbFieldProperties
、dbForeignKey
、dbNoPrecheck
、dbObject
、dbObjectProperties
、dbObjectType
、dbPrimaryKey
、dbUnique
、extendedType
、sqlPrecision
、sqlScale
およびtitle
です。
表、通常のビューまたはJSONリレーショナル二面性ビューの場合、スキーマ・フィールドdbObjectType
の値は"table"
、"view"
または"dualityView"
であり、これはそれぞれ、そのスキーマが表、通常のビューまたは二面性ビューから導出(生成)されたことを示しています。フィールドtype
の値"object"
は、スキーマは妥当なJSONデータがJSONオブジェクトであると想定していることを意味します。
オブジェクト型またはコレクション型のインスタンスの場合、スキーマ・フィールドdbObjectType
の値は"type"
であり、スキーマがユーザー定義のデータベース・データ型インスタンスから導出されたことを意味します。フィールドtype
の値は"object"
または"array"
であり、スキーマがそれぞれオブジェクト型インスタンスまたはコレクション型インスタンスから導出されたことを意味し、スキーマでは妥当なJSONデータがそれぞれJSONオブジェクトまたは配列であると想定していることを意味します。
アプリケーション使用方法ドメインの場合、スキーマ・フィールドdbObjectType
の値は"domain"
であり、これは、そのスキーマがドメインから導出されたということです。
表、ビューまたは二面性ビューの列、およびオブジェクト型インスタンスの属性の場合は、スキーマ・フィールドproperties
の値は、列名または属性名に対応するフィールド名があるJSONオブジェクトになります。このような各スキーマ・フィールドの値は、JSONオブジェクトであり、有効として許可されるJSON値(列または属性の値に対応する値)をまとめて指定するフィールドを持つJSONオブジェクトです。オブジェクト型インスタンスの場合: オブジェクトのタイプが別のオブジェクト型のサブタイプである場合、properties
の値には、スーパータイプから継承された属性に対応するフィールドがすべて含まれます。
NOT NULL
制約のある列は、生成されたJSONスキーマに従って有効であるデータの必須フィールドに対応します。これらの列名は、スキーマ・フィールドrequired
の配列値の要素です。主キー列と一意列の名前はそれぞれ、スキーマ・フィールドdbPrimaryKey
とスキーマ・フィールドdbUnique
の配列値の要素です。
表を記述するスキーマには、表定義で制約がNOPRECHECK
と宣言されていない場合に、対応するJSONスキーマとして既知のチェック制約がある各列のサブスキーマが含まれます。含まれるサブスキーマは、対応するJSONスキーマで、列で許可されるデータを記述します
アプリケーションでは、この列記述スキーマを使用して、列に格納されるデータを、データベースに送信する前に検証できます。そのアプリケーション・データがすでにJSONの形式の場合は、JSONスキーマを直接使用してこの事前チェックを実行できます。それ以外の場合は、チェックする必要がある内容の宣言的な仕様(説明)として使用できます。
データベースが事前チェックできない(つまり、対応するJSONスキーマがない)と判断した列チェック制約、または表定義でNOPRECHECK
と宣言されている列チェック制約は、かわりにスキーマ・フィールドdbNoPrecheck
の(配列)値にリストされます。
CREATE TABLE
またはALTER TABLE
を使用すると、データベースは、列チェック制約が事前チェック可能であることがわかっているかどうかを自動的に判断します。Oracle Database 23cより前に作成または最後に変更された制約の場合、事前チェック可能性は不明であるため、関数describe
の出力には、このような制約のJSONスキーマは含まれず、配列dbNoPrecheck
の制約もリストされません。
列チェック制約の既知の事前チェック可能性も、静的ディクショナリ・ビューALL_CONSTRAINTS
、DBA_CONSTRAINTS
およびUSER_CONSTRAINTS
の列PRECHECK
に記録されます。列値は、制約が事前チェック可能であると判断された場合はPRECHECK
、事前チェック不可と判断された場合はNOPRECHECK
、決定または宣言がまだ実行されていない場合はNULL
です。デフォルトでは、Oracle Databaseリリース23cより前に作成されたチェック制約の値はNULL
です。
コレクション型インスタンスの要素の場合、スキーマ・フィールドitems
の値は、JSON配列の要素ごとに許可されるJSON値(コレクション要素に許可される値に対応する値)をまとめて指定するフィールドを持つJSONオブジェクトです。スキーマ・フィールドmaxItems
は、JSON配列要素の最大数を指定します。
表6-1 データベース・オブジェクトのプロパティから導出されるJSONスキーマ・フィールド
フィールド(キーワード) | 値の説明 |
---|---|
Oracle固有。 |
参照されている列の名前。 |
Oracle固有。 |
同等のJSONスキーマがないか、表定義で |
Oracle固有。 |
同等のJSONスキーマがないか、表定義でNOPRECHECK と宣言されているチェック制約の名前。dbNoPrecheck を参照してください。
|
Oracle固有。検証ではなく、注釈のためにのみ使用されます。 |
関連するドメインの完全修飾名。ドメインに関連付けられている列にのみ表示されます。 |
Oracle固有。 |
JSONリレーショナル二重ビューの列またはビューでサポートされているJSON文書のフィールドで許可される操作に関する情報。 値は配列であり、 |
Oracle固有。検証ではなく、注釈のためにのみ使用されます。 |
表またはビューの外部キー列に対応する検証対象のJSON値のオブジェクトを指定する要素を持つJSON配列。 |
Oracle固有。 |
同等のJSONスキーマがないか、表定義で 指定されたチェック制約が事前チェック可能かどうかも、静的ディクショナリ・ビュー |
Oracle固有。 |
データベース・オブジェクトの完全修飾名。 |
Oracle固有。 |
JSONリレーショナル二面性ビュー全体でどの操作が許可されているかの情報。値は配列であり、次の要素を含むことができます:
|
Oracle固有。検証ではなく、注釈のためにのみ使用されます。 |
スキーマ導出元のデータベース・オブジェクトの型: |
Oracle固有。検証ではなく、注釈のためにのみ使用されます。 |
表またはビューの外部キー列に対応する検証対象のJSON値のフィールド名を示す要素を持つJSON配列。 |
Oracle固有。検証ではなく、注釈のためにのみ使用されます。 |
表またはビューの一意列に対応する検証対象のJSON値のフィールド名を示す要素を持つJSON配列。 |
検証ではなく、注釈のためにのみ使用されます。 |
スキーマによって検証されるJSON値について説明するコメント(通常は、目的または意味です)。 |
Oracle固有。 |
スキーマによって検証されるJSON値に指定されたJSON言語型。この値は文字列または文字列の配列です。 文字列で指定された型には、標準のJSONスキーマ・キーワード キーワード Oracle Databaseによって提供される検証では、JSON言語型の互換性は、Oracle SQLファンクション |
|
JSON配列の各要素を指定するJSONオブジェクト。 コレクション型から導出されたスキーマの場合、そのフィールドはまとめてコレクション型のインスタンスの要素に対応するJSON値を指定します。 |
|
JSON配列に許可される要素の最大数を指定するJSON数値。 コレクション型から導出されたスキーマの場合は、コレクション型のインスタンスに許可される要素の最大数です。 |
|
検証対象のJSON文字列の最大長(文字数)。 |
|
検証対象のJSON文字列の最小長(文字数)。 |
|
検証対象のJSONオブジェクト内の同じフィールドの値を指定するフィールドを持つJSONオブジェクト。 フィールドでは、表またはビューの列データまたはオブジェクト型の属性データに対応するデータを指定します。 |
|
検証対象のJSON値に必要なフィールドの名前を示す要素を持つJSON配列。 表またはビューから導出されたスキーマの場合は、表またはビューの |
Oracle固有。検証ではなく、注釈のためにのみ使用されます。 |
JSON言語数値型( |
Oracle固有。検証ではなく、注釈のためにのみ使用されます。 |
JSON言語数値型のインスタンスのスケール。 |
検証ではなく、注釈のためにのみ使用されます。 |
Oracle固有の使用: スキーマが導出されるデータベース・オブジェクト(表、ビュー、JSONリレーショナル二面性ビュー、オブジェクト型、コレクション型またはドメイン)の名前。 |
|
スキーマによって検証されるJSON値に指定されたJSON言語型。この値は文字列または文字列の配列です。 この文字列によって名付けられる型は、標準の型(Oracle固有ではない型)、 |
関連項目:
-
『Oracle Database概要』のアプリケーション使用方法ドメイン
-
JSONリレーショナル二面性開発者ガイドの更新可能なJSONリレーショナル二面性ビュー
-
JSONリレーショナル二面性開発者ガイドのJSONリレーショナル二面性ビューに格納されているJSONデータ
-
Oracle DatabaseリファレンスのALL_CONSTRAINTS
親トピック: JSONスキーマ
6.5 列チェック制約が事前チェック可能かどうかの明示的な宣言
表を作成または変更するときに、個々の列チェック制約を明示的に宣言して、データベースの外部で事前チェック可能(または不可)にできます。事前チェック可能と宣言した制約が実際には事前チェック可能でない場合は、エラーが発生します。
事前チェック可能なチェック制約は、(1)同等のJSONスキーマを持ち、(2)事前チェック不可として明示的に宣言されていない制約です。
列制約が事前チェック可能な場合、アプリケーションはデータベースにデータを送信する前に事前検証できます。このクライアント側での無効なデータの検出によって、アプリケーションの回復性が向上し、潜在的なシステム停止時間が短縮される可能性があります。
アプリケーションがJSONデータを使用する場合、同等のJSONスキーマを直接使用して事前チェックを実行できます。そうでない場合、スキーマは必要な検証の種類の説明として使用できます。
表を作成または変更すると、その列チェック制約が自動的に検査され、事前チェック可能かどうかが確認されます。既知の事前チェック可能性に関するこの情報は、2つの場所で利用できるようになります。
-
既存の表のPL/SQLファンクション
DBMS_JSON_SCHEMA.describe
によって生成されるJSONスキーマ。チェック制約と同等のJSONスキーマが、表を説明するスキーマに含まれています。事前チェックできないチェック制約は、表スキーマ・プロパティ
dbNoPrecheck
にリストされます。 -
静的ディクショナリ・ビュー
ALL_CONSTRAINTS
、DBA_CONSTRAINTS
およびUSER_CONSTRAINTS
の列PRECHECK
。ビュー行にはチェック制約がリストされます。列
PRECHECK
の値は、制約が事前チェック可能であることがわかっている場合はPRECHECK
、事前チェック可能でないことがわかっている場合はNOPRECHECK
、そうでない場合はNULL
です。NULL
は、制約の事前チェック可能性がまだ決定(設定)されていないことを示します。これは、Oracle Database 23cより前に作成された制約のデフォルトの場合です。
事前チェック不可能なチェック制約がある表の作成または変更を明示的に禁止できます。このためには、CREATE
文またはALTER TABLE
文の制約にキーワードPRECHECK
を追加します。制約が事前チェック可能でない場合、エラーが発生します。
特に、事前チェック可能性の自動決定が導入されたOracle Databaseリリース23cより前に作成された列チェック制約に対して、キーワードPRECHECK
をALTER TABLE
とともに使用できます。キーワードPRECHECK
を適用する制約に対してエラーが発生しない場合、制約は事前チェック可能であることがわかります。この場合、PL/SQLファンクションDBMS_JSON_SCHEMA.describe
およびディクショナリ・ビューALL_CONSTRAINTS
、DBA_CONSTRAINTS
およびUSER_CONSTRAINTS
は、事前チェック可能な制約について前述のように処理されます。
キーワードNOPRECHECK
を使用すると、事実上、制約が事前チェック可能でないことを宣言することになります。これは通常、データがデータベースの外部で事前チェックされないことを意味します。NOPRECHECK
を使用しても、制約に相当するJSONスキーマが存在しないことを意味するものではなく、アプリケーションの事前チェックが妨げられることもありません。ただ、データが事前チェック可能であることを期待しないように言っているにすぎません。
デフォルトでは、列制約が事前チェック可能であり、列に挿入されるデータがアプリケーションによって実際に事前チェックされている場合でも、データベースでは引き続きチェック制約を使用してデータを検証します。つまり、データはアプリケーションによって事前検証され、データベースによって検証されます。
キーワードPRECHECK
とともにキーワードDISABLE RELY
を制約に追加した場合、データベースは制約を使用して列データを検証しないため、制約が満たされることは保証されません。問合せオプティマイザは、制約が満たされていることを想定するため、データが無効な場合に失敗する可能性がある実行計画を生成します。アプリケーションのみで列データの検証を行う場合は、DISABLE RELY
を使用します。
例6-3 列制約の事前チェック
サンプル・スキーマhr
の表employees
には、(describe hr.employees
から)列salary
およびcommission_pct
が含まれています。
Name Null? Type
-------------- -------- -----------
SALARY NOT NULL NUMBER(8,2)
COMMISSION_PCT NOT NULL NUMBER(2,2)
アプリケーションがこれら2つの列を事前チェックできると想定していることをデータベースに通知するために、開発者はキーワードPRECHECK
を使用して列制約を追加します。給与は2000以上で、歩合の割合を6000未満にする必要があります。
ALTER TABLE employees
ADD CONSTRAINT min_salary CHECK (salary >= 2000) PRECHECK;
ALTER TABLE employees
ADD CONSTRAINT max_bonus CHECK ((salary * commission_pct) < 6000) PRECHECK;
チェック制約max_bonus
には同等のJSONスキーマがないため、事前チェックできません。その結果、制約の作成でエラーが発生します。
ORA-40544: CHECK expression of 'MAX_BONUS' constraint not possible to use as PRECHECK condition
制約max_bonus
には対応するJSONスキーマがありません。これは定義上、事前チェック可能ではないことを意味します。アプリケーションでは、制約が満たされるように、挿入または更新する行の給与とコミッションの割合を事前検証できます。これは、SQL式(salary * commission_pct) < 6000
と同等のJSONスキーマを使用して行うことはできません。
PRECHECK
を受け入れるには、制約の作成から削除する必要があります(エラーは発生しません)。
ALTER TABLE employees
ADD CONSTRAINT max_bonus CHECK ((salary * commission_pct) < 6000);
チェック制約を定義した後、表hr.employees
のDBMS_JSON_SCHEMA.describe
の出力には制約min_salary
と同等のJSONスキーマが含まれ、フィールドdbNoPrecheck
の配列値には制約max_bonus
のエントリが含まれます。
SELECT DBMS_JSON_SCHEMA.describe('EMPLOYEES');
{"title" : "EMPLOYEES",
"dbObject" : "HR.EMPLOYEES",
"dbObjectType" : "table",
...
"dbNoPrecheck" : [ {"dbConstraintName" : "MAX_BONUS",
"dbConstraintExpression" :
"(salary * commission_pct) < 6000"} ],
...
"properties" : {...
"SALARY" : {"extendedType" : "number",
"allOf" : [ {"exclusiveMinimum" : 2000} ]}
...
}}
関連項目:
-
Oracle DatabaseリファレンスのALL_CONSTRAINTS
-
サンプル・スキーマ
HR
の表EMPLOYEES
に関する、Oracle Databaseサンプル・スキーマのHRサンプル・スキーマ表の説明およびhttps://github.com/oracle-samples/db-sample-schemas
親トピック: JSONスキーマ