Oracle Database 12c Release 2を使用したJSONの …新しいAPIについては、別のホワイト・ペーパーで扱っています。本書は、SQLは理解しているが、JSONやJSONパス式については知識がないオラクル開発者の

Oracle Database 12c Release 2を使用した JSONの問合せ Oracle ホワイト・ペーパー | 2017 年 5 月

Oracle Database 12c Release 2を使用したJSONの問合せ

免責事項

下記事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。マテリアルやコード、機能の提供をコミットメント（確約）するものではなく、購買を決定する際の判断材料になさらないで下さい。オラクルの製品に関して記載されている機能の開発、リリース、および時期については、弊社の裁量により決定されます

目次免責事項 ........................................................................................................................................................... 0

はじめに ........................................................................................................................................................... 2

JSON ベースの永続性がもたらす課題 ...................................................................................................... 3

ポリグロット永続化の課題 .......................................................................................................................... 3

Oracle Database 12c Release 2 での JSON データの保存、索引付け、問合せ ............................... 4

JSON の問合せに SQL を使用する利点 ..................................................................................................... 4

JSON（JavaScript Object Notation）および JSON パス式の紹介 ..................................................... 5

JSON ......................................................................................................................................................... 5

JSON パス式 ........................................................................................................................................... 6

Oracle Database 12c Release 2 での JSON ドキュメントの保存と問合せ ....................................... 9

Oracle Database 12c Release 2 での JSON ドキュメントの保存 ............................................... 9

JSON ドキュメントのデータベースへのロード ........................................................................... 10

オラクルの簡素化された JSON 向け構文を使用した、JSON コンテンツの簡易な問合せ 11

SQL/JSON を使用した JSON コンテンツの複雑な問合せ .......................................................... 11

JSON コンテンツへのリレーショナル・アクセス ....................................................................... 12

JSON コンテンツのリレーショナル・ビュー ............................................................................... 14

JSON_EXISTS を使用した JSON コンテンツの検索 ..................................................................... 18

JSON_VALUE を使用した、複雑な JSON パス式の評価............................................................. 19

JSON_QUERY を使用したオブジェクトと配列へのアクセス ................................................... 21

Oracle Database 12c Release 2 に保存されたオラクルのドキュメントにおける

JSON の索引付け .......................................................................................................................................... 24


ファンクション索引を使用した JSON コンテンツの索引付け ................................................. 24

JSON 検索索引を使用した JSON コンテンツの索引付け ........................................................... 26


はじめに

JSON ドキュメントを使用したアプリケーション・データの保持は、現代のアプリケーション開発者の間で広く普及しました。ドキュメントベースの永続化の急増は、スキーマレス開発技術の採用によって後押しされています。この技術を使用すると、開発者はスキーマの柔軟性を手にし、急速に変化する要件に迅速に対応できると考えられています。アプリケーション・データをドキュメントとして表すと、アプリケーション・データ・モデルの複雑性がドキュメントによってカプセル化されるという利点があります。アプリケーション・データ・モデルがストレージ・スキーマから分離されるため、アプリケーションを変更する際に、同時にストレージ・スキーマに該当の変更を加える必要がなくなり、アプリケーションの最新バージョンのデプロイが容易になります。

しかしながら、従来型のリレーショナル・ストレージを JSON ドキュメント・ストレージに切り替えた場合、アプリケーション開発者は極めて大きな利点を享受できるかもしれませんが、このデータを使用する他のユーザーは、非常に大きな課題を突き付けられる可能性があります。レポート作成や分析など、NoSQL ドキュメント・ストアで十分にサポートされていない他の目的のためにデータを再利用しなければならないユーザーが、特に影響を受けるでしょう。

SQL データベースと SQL 言語は、レポート作成や分析のサポートに必要な柔軟性を提供するように設計されました。企業が求めているのは、アプリケーション開発者には NoSQL ドキュメント・ストアの柔軟性を、データを使用する他のユーザーには SQL ベースのレポート作成機能と分析機能を提供するソリューションです。Oracle Database 12c Release 2 は、JSON コンテンツの索引付けと問合せを可能にする有用な SQL 拡張機能と、アプリケーション開発者に真の NoSQL 開発体験を提供する新たな API を導入することで、これを実現しています。これら 2 つの機能を併せ持つ Oracle Database は、JSON ドキュメントの保存に理想的なプラットフォームであり、NoSQL ドキュメント・ストアのすべての利点、および SQL のレポート作成機能と分析機能をすべて実現します。

このホワイト・ペーパーでは、JSON ドキュメントの保存、索引付け、問合せを容易に実行できるSQL の新機能について説明します。新しい API については、別のホワイト・ペーパーで扱っています。本書は、SQL は理解しているが、JSON や JSON パス式については知識がないオラクル開発者のニーズに焦点を当てています。JSON のサポートは、Oracle Database Realease 12.1.0.2.0 以降のOracle Database 12c に追加されました。


JSONベースの永続性がもたらす課題

JSON および XML ベースの永続性の急速な普及は、企業が管理しなければならない半構造化データの増大を招きました。同時に、ドキュメントベースの永続性を使用するアプリケーションの性質が変わったことから、価値の低い資産向けに設計されたシステムから、ミッション・クリティカルな情報を管理するシステムへの移行も進みました。ドキュメントの永続性を使用して保存された情報の量と価値が増すにつれ、このデータに対してクロスドキュメントのレポート作成や分析を実行する機能の必要性も急激に高まっています。

残念ながら、JSON ドキュメントと JSON ドキュメント・ストアを理解しているレポート作成ツールと分析ツールはほとんどありません。これは驚くべきことではありません。ドキュメント・ストアには、管理されているデータを正確に表す、適切に定義されたデータ・ディクショナリがない傾向にあるからです。また、ドキュメント・ストアでは、SQL のような標準化された厳格な問合せ言語をサポートしていません。この 2 つの機能が欠けていると、アプリケーション・データに含まれる情報の力を引き出すために必要な、パワフルで柔軟なレポート作成ツールと分析ツールを作成することは非常に困難です。

JSON ドキュメントや XML 文書に保存されたデータ上でこれらの機能をサポートすることは容易なことではありません。スキーマレス開発を使用すると、各ドキュメントのコンテンツはいかなる方法においても制約されません。したがって、効果的なレポート作成と分析には、各ドキュメントの内容を見て、必要な情報が含まれているかどうかを確認することが必要です。一般的な NoSQL ドキュメント・ストアでは、この種の操作はほとんど（あるいは全く）サポートされていません。NoSQL ドキュメント・ストアによって管理される JSON から有用な洞察を得るには、コンテンツを抽出し、複雑でエラーが発生しやすい ETL プロセスに委ね、その後レポート作成操作と分析操作をサポートするデータ・ストアにアップロードする必要があります。また、NoSQL ドキュメント・ストアには標準化された正式な問合せ言語がないため、数行の SQL 文で宣言できるようなことにも、通常は複雑なアプリケーション・コードを大量に構築しなければなりません。

NoSQL ドキュメント・ストアのもう 1 つの課題はセキュリティです。一般的な NoSQL ドキュメント・ストアには、非常に限られたアクセス制御機能しかないため、一旦アプリケーションがデータベースに接続されると、そのデータベースによって管理されるすべてのコンテンツに自由にアクセスできます。重要なレポート作成や分析操作を実行するために、NoSQL ドキュメント・ストアからデータをエクスポートするニーズが増せば、データに不正アクセスされる可能性も増します。

ポリグロット永続化の課題

一部の企業は、管理するデータの種類ごとに、異なるデータ管理ソリューションを採用する戦略を選択しています。その場合、リレーショナル・データの管理には（Oracle）RDBMS を、JSON データの管理には専用の NoSQL ドキュメント・ストアを使用し、場合によっては専用の空間データベースや XML データベースを所有することになるでしょう。そのような企業は、“ポリグロット永続化”とよく呼ばれるこのアプローチで、‘最先端’の機能が提供されるのではないかと考えています。しかしながら、このアプローチには、データがサイロ化されるという問題があります。遅かれ早かれ、異なるストアからのデータを結合することを求める問合せに応答することが不可欠となります。そのような状況になった場合、もっとも基本的なタスクにさえも、複雑なアプリケーション・コードが必要となります。ほとんどの JSON ドキュメント・ストアは、JSON を他の種類のデータと結合できないことはもちろんのこと、JSON ドキュメント間や JSON ドキュメント内においても結合を実行できないことに留意してください。


異なるデータ・ストアにまたがる結合操作を実行するために必要なコードは、開発とメンテナンスが高額であり、また、非常に非効率的です。ポリグロット永続化では、ある問合せに応えるために必要なデータは、それぞれのデータ・ストアからフェッチされ、アプリケーション・コードによって結合される必要があります。統計と索引に基づき結合操作を最適化するデータベース・システムとは異なり、アプリケーション・コードは通常、結合操作のインテリジェントな最適化を実行するために必要な情報にアクセスできません。つまり、アプリケーションでは、大量の不必要なデータをアプリケーションにフェッチした後に、操作を完了するためにはどの情報が実際に必要であるかをようやく判断できる、強引なアプローチを使用する必要があるのです。その結果、データ・ストレージ、ネットワーク・リソース、メモリ、および CPU への過剰な負荷を引き起こします。

Oracle Database 12c Release 2でのJSONデータの保存、索引付け、問合せ

JSON は、標準的な VARCHAR2、CLOB、または BLOB データ型を使用してデータベースに保存されます。既存のデータ型を使用すると、高可用性、レプリケーション、圧縮、暗号化など、すべてのデータベース機能が JSON データと連携します。Oracle Database 12c Release 2 を使用して JSON コンテンツを管理すれば、企業は、スケーラビリティ、可用性、パフォーマンスの実現におけるオラクルの豊富な実績をすぐに利用できます。さらに、オラクルのエンタープライズ・クラスのバックアップおよびリカバリ・ソリューションも活用できます。

Oracle Database 12c では、新たな制約“IS JSON”が導入されました。この制約を列に適用すると、データベースは列が JSON ドキュメントのコンテナであることを理解でき、有効な JSON ドキュメントのみが列に保存されるようになります。制約は、VARCHAR2、CLOB、または BLOB タイプのあらゆる列に適用できます。

標準的なデータ型を使用して JSON データを保存するもう 1 つの利点は、企業が管理するすべてのミッション・クリティカルなデータに適用されるセキュリティ・ポリシーが、JSON にも同様に適用されようになる点です。企業がリレーショナル・コンテンツの保護に用いるアクセス制御の仕組みと同じものを、JSON コンテンツに適用できます。必要に応じて、暗号化も JSON ドキュメントに適用できます。IT マネージャは、JSON コンテンツが他の企業データと同様に安全に保護されていることを確信できるため、夜も安心して休めるようになります。

すべてのデータに対して単一のデータ管理ソリューションを採用することで、企業はポリグロット永続化の世界で問合せを最適化する際に発生する多くの問題を回避できます。Oracle Database では、リレーショナル・データ、JSON ドキュメント、XML コンテンツ、空間データ、およびフリー・テキストを同じように適切に管理できます。SQL によって、このような種類のデータをすべて問合せすることができる単一の、形式化された問合せ言語が提供され、Oracle オプティマイザによって、それぞれの種類のデータに対して操作が最適化されます。

JSONの問合せにSQLを使用する利点

多くの開発チームは、データ固有の複雑なプログラム・コードに適応することで、進化し続ける新しい分析要件に対応しようと苦心しています。分析範囲が広がり、さらなるデータ・セットを取り込む上で、開発者は相も変わらず、異なる問合せ言語を組み込み、結果セットをプログラムで結合しなければなりません。データを使用する一般的なユーザーにとって、カスタムのコードを構築してデータ・セット全体で問合せを行うこのアプローチは、あまりにも複雑すぎます。必要なのは、単一の高度な問合せ言語です。


開発者とデータの使用者が求めているものは、すべての種類のデータに対して均一のアクセス方法を提供し、濃密で高度な分析ができる、堅牢で、生産的で、機能が豊富な標準志向の単一言語です。

過去 40 年にわたり、Structured Query Language（SQL）という 1 つの問合せ言語が存続し、発展してきました。多くのテクノロジーが生まれては消えましたが、SQL は不変でした。実際、SQL は不変であっただけではなく、時間とともに大きく改善されました。Oracle Database 12c では、JSON コンテンツの索引付けと問合せを可能にする SQL の拡張機能が導入されました。

もっとも実用的かつ戦略的で、検出によって導かれる問合せは、詳細なレベルのデータ要約に依存しています。業界アナリストは、全レポートの最大 90%には、ある程度の集計情報が含まれていると頻繁に述べています。SQL を使用することで、開発者とデータ使用者は、他の言語を使用した場合と比較して、必要なプログラム・コードが非常に少なく、簡便かつ効率的なデータ集計技法を活用できます。SQL によって実現されるこの簡素化により、アプリケーション・コードの構築、管理、メンテナンス、および新たなビジネス要件の組み込みを素早く容易に行うことができます。

オラクルの SQL では、JSON ドキュメントを含む広範なデータソースで、もっとも複雑なデータ検出とビジネス・インテリジェンス・レポート作成の要件をサポートする簡素な方法が開発者とデータ使用者に提供されます。ANSI 2011 を含む最新の業界標準をサポートし、継続的な改善に取り組んでいる SQL は、JSON コンテンツを含むあらゆる種類のデータ分析におけるデフォルト言語となりました。

JSON（JavaScript Object Notation）およびJSONパス式の紹介

JSON

Web サイト、http://www.json.org では、JSON を次のように説明しています。

JSON は、軽量のデータ交換形式です。人間にとってコードの理解および記述が容易で、マシンにとっても解析と生成が容易です。JavaScript プログラミング言語（ECMA-262 標準第 3 版 - 1999 年12 月）のサブセットを基盤としています。JSON は、言語から完全に独立したテキスト形式ですが、C、C++、C#、Java、JavaScript、Perl、Python をはじめとする C 言語ファミリーのプログラマーにとって、馴染み深い表記規則が使用されています。このような性質から、JSON は理想的なデータ交換言語となっています。

JSON は次の 2 つの構造に基づいています。

» 名前/値のペアの集合：さまざまな言語において、これはオブジェクト、レコード、構造体、ディクショナリ、ハッシュ表、鍵のあるリスト、連想配列として実現されています。

» 値の順序付きリスト：ほとんどの言語において、これは配列、ベクター、リスト、シーケンスとして実現されています。

これらは、汎用的なデータ構造です。つまり、現代のすべてのプログラミング言語が、実質的に何らかの形式でこれらをサポートしています。プログラミング言語の間で交換可能なデータ形式も当然、これらの構造に基づいています。

http://www.json.org/

http://javascript.crockford.com/

http://www.ecma-international.org/publications/files/ecma-st/ECMA-262.pdf

http://www.ecma-international.org/publications/files/ecma-st/ECMA-262.pdf


シリアライズされた、すなわちテキストで表現された簡単な JSON ドキュメントを以下に示します。

JSON ドキュメントは、スカラー値、配列、およびオブジェクトを含む可能性があります。スカラー値は、文字列、数値、またはブールの可能性があります。オブジェクトは、1 つまたは複数のキーと値のペアで構成されています。値は、スカラー、配列、オブジェクト、または NULL の可能性があります。JSON には日付、時刻、および他のスカラー・データ型はありません。配列は順序の付いた値の集合です。配列は同じ種類である必要はありません。たとえば、配列の各項目は異なるタイプでも構いません。

シリアライズされると、鍵の名前は文字列値のように、二重引用符で囲まれます。鍵の名前では、大文字と小文字が区別されます。鍵とその鍵に対応する値は、コロン（‘:’）で区切られます。鍵と値のペアは、カンマ（‘,’）を使用して相互に区切られます。オブジェクトは、波括弧（‘{}’）で囲まれます。配列要素は、カンマを使用して相互に区切られます。配列は、角括弧（‘[]’）で囲まれます。

上記の例では、JSON で発注書オブジェクトを表しています。鍵“PONumber”には数値が含まれています。鍵“Reference”には文字列値が、鍵“ShippingInstructions”にはオブジェクトが、鍵“LineItems”には配列が、鍵“AllowPartialShipment”にはブールが、鍵“ShippingInstructions"には NULL 値が含まれています。

JSONパス式

JSON パス式は、JSON ドキュメントのコンテンツを移動するために使用されます。JSON パスのJSON に対する役割は、XPath の XML に対する役割と同様です。JSON パス式は、最上位の鍵から開始して必要な項目に到達するために横断が必要な鍵セットを特定することで、ドキュメントを移動

{ "PONumber":1600, "Reference":"SVOLLMAN-20140525", "Requestor":"Shanta Vollman", "User":"SVOLLMAN", "CostCenter":"A50", "ShippingInstructions": {

"name":"Shanta Vollman", "Address": {

"street":"200 Sporting Green", "city":"South San Francisco", "state":"CA", "zipCode":99236, "country":"United States of America"

}, "Phone": [{"type":"Office","number":"823-555-9969"},

{"type":"Cell","number":"976-555-1234"}] }, "SpecialInstructions": null, "AllowPartialShipment": false, "LineItems": [{

"ItemNumber": 1, "Part": {

"Description":"One Magic Christmas", "UnitPrice":19.95, "UPCCode":13131092899

}, "Quantity":9.0

},{ "ItemNumber": 2, "Part": {

"Description":"Lethal Weapon", "UnitPrice":19.95, "UPCCode":85391628927

}, "Quantity":5.0

}] }


します。パスの各コンポーネントは 1 つの鍵に対応します。鍵の名前はピリオドで区切られます。JSON パスを使用すると、以下を参照できます。

» ドキュメント全体

» スカラー値

» 配列

» オブジェクト

ドキュメント全体は、シンボル$を使用して参照します。そのため、すべての JSON パス式はシンボル‘$’で始まります。

以下の表では、上記のサンプル・ドキュメントに対する簡単な JSON パス式の評価結果をいくつか示しています。

JSON パス式は配列で使用できます。JSON パス式には、配列の特定のメンバーで使用する必要があることを指定する索引条件を含めることができます。条件を指定する際は、その配列を含む鍵の名前の後に、角括弧（‘[]’）で囲まれた索引値を入力します。配列の最初のメンバーの索引は 0 です。条件は、明示的な数値、数値のリスト、または数値の範囲という形式で指定できます。配列のすべてのメンバーが必要な場合は、‘*’を使用します。入力した条件が配列の複数のメンバーと一致した場合、パス式はその条件を満たすすべての配列のメンバーに対して評価されます。JSON パス式が条件を指定せずに配列を参照する場合、“*”を使用した場合と同様になります。

式結果コメント

$.PONumber 1600 数値最上位の鍵、PONumber に対応付

けられた値

$.Reference SVOLLMAN-20140525 文字列最上位の鍵、Reference に対応付け

られた値

$.ShippingInstructions.Address { "street":"200 Sporting Green", "city":"South San Francisco", "state":"CA", "zipCode":99236, "country":"United States of America"

}

オブジェクト最上位の鍵、ShippingInstructionsの子である Address 鍵に対応付け

られた値

$.ShippingInstructions.Address.zipCode 99236 数値最上位の鍵、ShippingInstructionsの子である Address 鍵の子である

zipCode 鍵に対応付けられた値

$.ShippingInstructions.Phone [ {"type":"Office","number":"823-555-9969"}, {"type":"Cell","number":"976-555-1234"}

]

配列最上位の鍵、ShippingInstructionsに含まれる Phone 鍵に対応付けら

れた値

http://download.oracle.com/otndocs/java/javadocs/soda/soda6r/oracle/soda/OracleClient.html

http://download.oracle.com/otndocs/java/javadocs/soda/soda6r/oracle/soda/OracleDatabase.html




以下の表では、上記のサンプル・ドキュメントに含まれる配列に対する JSON パス式の評価結果をいくつか示しています。

式結果コメント

$.LineItems[1] { "ItemNumber": 2, " Part": {

"Description":"Lethal Weapon", "UnitPrice":19.95, "UPCCode":85391628927

}, "Quantity":5.0

}

オブジェクト最上位の鍵、LineItems に対応付けられ

た配列の 2 番目のメンバーの値

$.LineItems[1].Part { "Description":"Lethal Weapon", "UnitPrice":19.95, "UPCCode":85391628927

}

オブジェクト最上位の鍵、LineItems に対応付けられ

た配列の 2 番目のメンバーの Part 鍵の

値

$.LineItems[1].Part.UPCCode 85391628927 数値最上位の鍵、LineItems に対応付けられ

た配列の 2 番目のメンバーの Part 鍵の

値に含まれる、UPCCode 鍵に対応付け

られた値

$.LineItems[*].Part.UPCCode [13131092899, 85391628927] 配列最上位の鍵、LineItems に対応付けられ

た配列のすべてのメンバーの Part 鍵に

含まれる、UPCCode 鍵に対応付けられ

た値を含む配列 UPCCode 鍵を持つ Part 鍵が含まれる配

列のメンバーは 2 つ存在するため、配列

には 2 つのメンバーがあります

$.LineItems.Part.UPCCode [13131092899, 85391628927] 配列上記と同様です。条件が指定されていな

いため、JSON 式は、最上位の鍵、

LineItems に対応付けられた配列のすべ

てのメンバーに対して評価されます。


Oracle Database 12c Release 2でのJSONドキュメントの保存と問合せ

Oracle Database 12c Release 2でのJSONドキュメントの保存

オラクルでは、明示的な JSONデータ型はありません。JSONドキュメントは、VARCHAR2、CLOB、BLOB など、オラクルの標準的なデータ型を使用してデータベースに保存されます。VARCHAR2 は、JSON ドキュメントのサイズが 4K（LONG VARCHAR のサポートが有効な環境では 32K）を超えない場合に使用できます。それよりもサイズの大きいドキュメントは、CLOB または BLOB データ型を使用して保存する必要があります。

列のコンテンツが確実に有効な JSON となるようにするためには、列に適用できる新しい制約、IS JSON を使用します。この制約は、列のコンテンツが適切な形式の JSON である場合は TRUE を返し、そうでない場合は FALSE を返します。

以下の例では、JSON ドキュメントを保存できる表を作成するために必要な DDL を示しています。

この文では、PURCHASEORDER という名前の表を作成します。表には、RAW(16)タイプの列 ID、TIMESTAMP WITH TIME ZONE タイプの列 DATE_LOADED、CLOB タイプの列 PO_DOCUMENT があります。IS JSON 制約は、列 PO_DOCUMENT に適用されます。IS JSON 制約を追加することで、データベースは列に JSON データが含まれていることを把握でき、列には有効な JSON ドキュメントのみが含まれるようになります。

Oracle Database 12c Release 2 では、データベースの外部に保存された JSON ドキュメントの操作も可能です。外部表を使用することで、外部のファイル・システムに保存された JSON ドキュメントにアクセスできます。以下の例では、一般的な NoSQL JSON ドキュメント・ストアのエクスポート形式で保存された JSON ドキュメントへのアクセスを提供する外部表の作成に必要な DDL を示しています。

この例では、ドキュメントはファイル、PurchaseOrders.dmp に含まれます。処理されるファイルが存在するフォルダを指す SQL ディレクトリ・オブジェクト、ORDER_ENTRY が作成されています。

create table J_PURCHASEORDER ( ID RAW(16) NOT NULL, DATE_LOADED TIMESTAMP(6) WITH TIME ZONE, PO_DOCUMENT CLOB CHECK (PO_DOCUMENT IS JSON)

) /

CREATE TABLE DUMP_FILE_CONTENTS( PO_DOCUMENT CLOB

) ORGANIZATION EXTERNAL(

TYPE ORACLE_LOADER DEFAULT DIRECTORY ORDER_ENTRY ACCESS PARAMETERS (

RECORDS DELIMITED BY 0x'0A' BADFILE JSON_LOADER_OUTPUT:'JSON_DUMPFILE_CONTENTS.bad' LOGFILE JSON_LOADER_OUTPUT:'JSON_DUMPFILE_CONTENTS.log' FIELDS(

JSON_DOCUMENT CHAR(5000) )

) LOCATION (

ORDER_ENTRY:'PurchaseOrders.dmp' )

) PARALLEL REJECT LIMIT UNLIMITED /


JSONドキュメントのデータベースへのロード

JSON ドキュメントを Oracle Database にロードする方法は多数あります。Oracle Database 12c Release 2 には、この目的のために設計された新しい API が含まれています。Simple Oracle Document Access（SODA）仕様に基づくこれらの API を使用することで、アプリケーション開発者は、アプリケーション開発に一般的な NoSQL スタイルのアプローチを適用できます。これらの APIに関しては、別のホワイト・ペーパーで取り上げるため、ここでは説明しません。

JSON データは標準的なデータ型に保存されるため、SQL ベースの既存の API もすべて、JSON ドキュメントをデータベースに挿入するために使用できます。つまり、JSON データは、他の文字データやバイナリ・データと全く同じ方法で挿入することで、ロードできます。

たとえば、JSON_CONTENT という名前の SQL ディレクトリ・オブジェクトがあるとします。以下の無名 PL/SQL ブロックを使用すれば、そのディレクトリにある“PurchaseOrder.json”という名前のファイルから JSON をロードできます。

ご存知のように、JSON は従来型の SQL 挿入文を使用して表に挿入されます。JSON のデータベースへのロードがいかに容易であるかを表す別の例を以下に示します。先のセクションで作成された 2つの表では、以下の簡単な SQL 文により、NoSQL データベースのダンプ・ファイルのコンテンツが、Oracle Database によって管理される表にコピーされます。

declare V_FILE BFILE;

V_CONTENT CLOB; V_DOFFSET NUMBER := 1; V_SOFFSET NUMBER := 1; V_LANG_CTX NUMBER := 0; V_WARNING NUMBER := 0;

begin V_FILE := BFILENAME('JSON_DIRECTORY','PurchaseOrder.json'); DBMS_LOB.createTemporary(V_CONTENT,TRUE,DBMS_LOB.SESSION); DBMS_LOB.fileopen(V_FILE, DBMS_LOB.file_readonly); DBMS_LOB.loadClobfromFile(

V_CONTENT, V_FILE, DBMS_LOB.getLength(V_FILE), V_DOFFSET, V_SOFFSET, NLS_CHARSET_ID('AL32UTF'), V_LANG_CTX, V_WARNING

); DBMS_LOB.fileclose(V_FILE); insert into J_PURCHASEORDER values (SYS_GUID(), SYSTIMESTAMP, V_CONTENT); commit; DBMS_LOB.freeTemporary(V_CONTENT); | end;

/

insert into J_PURCHASEORDER select SYS_GUID(), SYSTIMESTAMP, JSON_DOCUMENT

from DUMP_FILE_CONTENTS where PO_DOCUMENT IS JSON

/


適切な形式の JSON ドキュメントに対してのみ、挿入操作が行われるようにするために、IS JSON 条件を where 句で条件として使用しています。 where 句で条件を適用することで、DUMP_FILE_CONTENTS 表の下層に不適切な形式のソース・ファイルの JSON ドキュメントが 1 つまたは複数存在するという理由によって、挿入操作全体がエラーになるという状況を避けることができます。挿入された各ドキュメントでは、関数 SYS_GUID()および SYSTIMESTAMP を使用して、ID 列と DATE_LOADED 列に値が入力されます。

オラクルの簡素化されたJSON向け構文を使用した、JSONコンテンツの簡易な問合せ

Oracle Database 12c Release 2 では、簡易な‘点付き’表記法を使用して、JSON を含む列に簡単な操作を実行できます。点付き表記法は、データベースに保存された JSON に基本的なナビゲーション操作を実行するために使用できます。この表記法を使用して、JSON ドキュメントに含まれるあらゆる鍵の値にアクセスできます。すべてのデータは、VARCHAR2(4000)として返されます。

以下の例では、オラクルの簡素化された構文を使用して JSON ドキュメントから値を抽出する方法、および JSON のコンテンツに基づき結果セットをフィルタリングする方法を示します。

この例では、問合せは、PONumber 鍵の値が 1600 であるすべてのドキュメントの鍵、Reference、Requestor、CostCenter の値、および ShippingInstructions オブジェクトの子である Address オブジェクトに含まれる city 鍵の値を返します。

点付き表記法を使用するには、以下の条件を満たす必要があります。

» 第一に、対象となる列に JSON 制約が適用される必要があります。

» 第二に、表に FROM 句で割り当てられた表の別名がなければなりません。

» 第三に、JSON の列の参照にはすべて、割り当てられた表の別名が接頭辞として付けられている必要があります。

Oracle Database 12c Release 2 では、Oracle Database 12c Release 1 で簡素化された構文を実装する際に適用されていた多くの制約が削除されています。たとえば、配列を含む JSON ドキュメントを移動する場合に、条件を指定できるようになりました。

SQL/JSONを使用したJSONコンテンツの複雑な問合せ

Oracle Database 12c では、簡素化された構文に加えて、SQL を拡張した標準である SQL/JSON のサポートが追加されたため、JSON ドキュメントのコンテンツを SQL 操作の一部として問い合わせることができるようになりました。この機能により、リレーショナル・パラダイムしか理解していない開発者やツールも、リレーショナル・データを扱うように、データベースに保存された JSON ドキュメントを扱うことができます。

select j.PO_DOCUMENT.Reference, j.PO_DOCUMENT.Requestor, j.PO_DOCUMENT.CostCenter, j.PO_DOCUMENT.ShippingInstructions.Address.city

from J_PURCHASEORDER j where j.PO_DOCUMENT.PONumber = 1600

/

REFEREN

REQUEST

COSTCENT

SHIPPINGINSTRUCTIONS ---------------- ------------- ------------ -------------------- ABULL-20140421 Alexis Bull A50 South San Francisco


SQL/JSON 標準では、5 つの新しい SQL 演算子と、データベース内に保存された JSON ドキュメントに複雑な問合せ操作を実行できる JSON パス言語が定義されています。この 5 つの演算子、JSON_VALUE、JSON_QUERY、JSON_TABLE、JSON_EXISTS、および JSON_TEXTCONTAINS を使用すると、JSON データを含む列で JSON パス式を評価でき、宣言的な SQL のすべての機能を JSONデータに適用できます。これらの演算子を使用することで、リレーショナル・データと同じように、Oracle Database に保存された JSON の問合せや分析が可能になります。さらに、Schema-on-Queryセマンティックが提供されるため、JSON コンテンツをリレーショナル・コンテンツに結合する問合せや、XML データや空間データなど、Oracle Database に保存できる他の種類のデータに結合する問合せを生成できるようになります。SQL/JSON によって提供される機能は、XMLDB の SQL/XML機能によって提供される機能と非常に類似しています。SQL/XML 機能では、XQuery を使用して、データベースに保存された XML 文書のコンテンツにアクセスできます。

このホワイト・ペーパーの次のセクションでは、簡素化された構文、および各演算子の使用方法について紹介します。

JSONコンテンツへのリレーショナル・アクセス

JSON コンテンツへのリレーショナル・アクセスを取得するためのもっとも有用な演算子はJSON_TABLE です。JSON_TABLE は、JSON コンテンツからインライン・リレーショナル・ビューを作成します。このビューには、1 つまたは複数の列を含めることができます。列のコンテンツは、一連の JSON パス式によって定義されます。JSON パス式により、JSON ドキュメントの値がビューの列にマッピングされます。JSON_TABLE 表を使用することで、SQL 言語のすべての機能を一連のJSON ドキュメントに含まれるデータに適用できます。JSON_TABLE は、常に SQL 文の FROM 句に記述されます。

JSON_TABLE 演算子における最低限の入力項目は、JSON ドキュメントと行パターンです。JSON ドキュメントは列または PL/SQL 変数から取得できます。行パターンは JSON パス式です。行パターンは、JSON_TABLE 演算子によって生成される行数を決定します。行パターンのすべての鍵がスカラー値またはオブジェクトにマッピングされた場合、JSON_TABLE 演算子は 1 行生成します。行パターンの任意の鍵が配列にマッピングされた場合、JSON_TABLE 演算子は配列のメンバーごとに 1行生成します。行パターンに“$”を指定すると、すべてのドキュメントが一致します。行パターンの最後のコンポーネントが、配列の値を持つ鍵の場合、行パターンが、配列そのものではなく、配列のすべてのメンバーを対象としていることを表すために、鍵の名前に[*]を付加します。

列は、COLUMNS キーワードの後に記述される列記述子によって定義されます。列記述子は、名前、データ型、列パターンで構成されます。名前は列の SQL 名を定義し、データ型は列の SQL データ型を指定します。列パターンは、どの鍵が列に値を提供するかを定義する JSON パス式です。列パターンの JSON パス式は、行パターンと関連しています。列パターンは、最大で 1 つの値としか一致しないようにする必要があります。列パターンは、配列である鍵に対するすべての参照が、配列の特定のメンバーを一意に特定する条件を満たす必要があるという条件を使用して、ネストされた鍵を参照できます。

COLUMNS キーワードが省略された場合、JSON_TABLE 演算子は、行パターンと一致する鍵に対応付けられた値を出力します。

JSON_TABLE 演算子によって出力される行は、それらの行を生成した行と実質的に結合されます。JSON_TABLE 演算子の出力と JSON ドキュメントを含む表を結合する WHERE 句を記述する必要はありません。


以下の文では、JSON_TABLE 演算子を使用して、JSON ドキュメントのコンテンツからインライン・リレーショナル・ビューを作成する方法を示しています。

この例では、各ドキュメントで最大で 1 度しか現れない鍵から列を生成しています。提供された行パターンは“$”であり、すべてのドキュメントが一致するため、この JSON_TABLE 式によって 1 行が返されます。行パターンに“$”を使用すると、すべての列パターンが最上位オブジェクトの直属の子孫であることも表します。結果から分かるように、この JSON_TABLE 演算子によって、5 つの列（REFERENCE、REQUESTOR、USERID、COSTCENTER、TELEPHONE）のインライン・ビューが生成されます。

ネストされた配列をサポートするために、JSON_TABLE に NESTED 句が導入されています。NESTED句では、独自の一連の列記述子に加えて、さらなる行パターンを指定できます。NESTED 句の行パターンは、親の行パターンと関連します。NESTED 句が使用される場合、JSON_TABLE 演算子は、参照されるもっとも深い配列のメンバーごとに 1 行出力します。そのため、ネストされた句の出力は、NESTED 句によって生成された行を持つ、親の行の右側外部結合と見なすことができます。

複数の NESTED 句を、単一の JSON_TABLE 式で指定できます。並行して使用して兄弟関係の配列を処理することも、内部に相互に組み込んでネストされた配列を処理することもできます。

以下の例では、NESTED 句を使用して、LineItems 鍵に対応付けられた配列のコンテンツを処理する方法を示します。

select M.* from J_PURCHASEORDER p,

JSON_TABLE( p.PO_DOCUMENT , '$' columns

PO_NUMBER NUMBER(10) path '$.PONumber', REFERENCE VARCHAR2(30 CHAR) path '$.Reference', REQUESTOR VARCHAR2(32 CHAR) path '$.Requestor', USERID VARCHAR2(10 CHAR) path '$.User', COSTCENTER VARCHAR2(16 CHAR) path '$.CostCenter', TELEPHONE VARCHAR2(16 CHAR) path '$.ShippingInstructions.Phone[0].number’

) M where PO_NUMBER > 1599 and PO_NUMBER < 1602

/ PO_NUMBER REFERENCE REQUESTOR USERID COSTCENTER TELEPHONE ---------- --------------- ------------ ------ ---------- ----------

1600 ABULL-20140421 Alexis Bull ABULL A50 909-555-7307 1601 ABULL-20140423 Alexis Bull ABULL A50 909-555-9119

2 rows selected.


JSON_TABLE 演算子の行パターンは“$”であり、すべてのドキュメントが一致します。最初の列句では、各ドキュメントで最大で 1 度しか現れない鍵を指定します。NESTED 句では、“$.LineItems[*]”の行パターンを指定しているため、LineItems 鍵に対応付けられた配列の各メンバーと一致します。NESTED 句に対応付けられた列句では、行パターンによって参照される配列の項目の列ベースのコンテンツを生成する列記述子を指定します。この例では、2 つのドキュメントが指定された条件と一致しました。最初のドキュメントから 2 行生成され、2 つ目のドキュメントから 5 行生成されました。

JSONコンテンツのリレーショナル・ビュー

JSON_TABLE の 1 つの一般的な使用例として、標準 SQL 構文を使用して問合せを実行できる JSONコンテンツのリレーショナル・ビューを作成する場合が挙げられます。JSON データや JSON パス式を全く把握していないプログラマーやツールが、Oracle Database に保存された JSON ドキュメントを扱うことができるという利点があります。

Oracle 12.1.0.2.0 では、このようなビュー間の結合を避けるのがベスト・プラクティスです。以下に示すような完全に展開された詳細ビューを使用すれば、マスター・ビューと詳細ビューを定義し、次にマスター・ビューと詳細ビューの結合を基に結果を返す問合せを記述しようとするよりも、はるかに優れたパフォーマンスが実現します。

select D.* from J_PURCHASEORDER p,

JSON_TABLE( p.PO_DOCUMENT , '$' columns( PO_NUMBER REFERENCE

NUMBER(10) VARCHAR2(30

path '$.PONumber', path '$.Reference',

NESTED PATH '$.LineItems[*]' columns(

ITEMNO NUMBER(16) path '$.ItemNumber', DESCRIPTION VARCHAR2(32 CHAR) path '$.Part.Description', UPCCODE VARCHAR2(14 CHAR) path '$.Part.UPCCode', QUANTITY NUMBER(5,4) path '$.Quantity', UNITPRICE NUMBER(5,2) path '$.Part.UnitPrice'

) )

) D where PO_NUMBER > 1599 and PO_NUMBER < 1602

/ PO_NUMBER REFERENCE ITEMNO DESCRIPTION UPCCODE QUANTITY UNITPRICE ---------- ------------- ----- ------------------------ ----------- -------- ---------

1600 ABULL-20140421 1 One Magic Christmas 13131092899 9 19.95 1600 ABULL-20140421 2 Lethal Weapon 85391628927 5 19.95 1601 ABULL-20140423 1 Star Trek 34:Plato's St 97366003448 1 19.95 1601 ABULL-20140423 2 New Blood 43396050839 8 19.95 1601 ABULL-20140423 3 The Bat 13131119695 3 19.95 1601 ABULL-20140423 4 Standard Deviants:Frenc 63186500442 7 27.95 1601 ABULL-20140423 5 Darkman 2: the Return of 25192032325 7 19.95

7 rows


以下の例では、PURCHASEORDER_MASTER_VIEW という名前のリレーショナル・ビューを作成しています。

このビューは、各ドキュメントで最大で 1 度しか現れない値を公開します。下層の表の行ごとに、ビューに 1 行存在します。describe 操作の出力から分かるように、このビューは他のリレーショナル・ビューと類似しています。JSON 演算子と JSON パス式は、ビューを作成した DDL 文に隠れています。

create or replace view PURCHASEORDER_MASTER_VIEW as select m.* from J_PURCHASEORDER p,

JSON_TABLE( p.PO_DOCUMENT , '$' columns

PO_NUMBER REFERENCE REQUESTOR USERID COSTCENTER SHIP_TO_NAME SHIP_TO_STREET SHIP_TO_CITY SHIP_TO_COUNTY

NUMBER(10) path '$.PONumber', VARCHAR2(30 CHAR) path '$.Reference', VARCHAR2(128 CHAR ) path '$.Requestor', VARCHAR2(10 CHAR) VARCHAR2(16) VARCHAR2(20 CHAR) VARCHAR2(32 CHAR) VARCHAR2(32 CHAR) VARCHAR2(32 CHAR)

SHIP_TO_POSTCODE VARCHAR2(32 CHAR) SHIP_TO_STATE VARCHAR2(2 CHAR) SHIP_TO_PROVINCE VARCHAR2(2 CHAR) SHIP_TO_ZIP VARCHAR2(8 CHAR) SHIP_TO_COUNTRY VARCHAR2(32 CHAR) SHIP_TO_PHONE VARCHAR2(24 CHAR)

path '$.User', path '$.CostCenter', path '$.ShippingInstructions.name', path '$.ShippingInstructions.Address.street', path '$.ShippingInstructions.Address.city', path '$.ShippingInstructions.Address.county', path '$.ShippingInstructions.Address.postcode', path '$.ShippingInstructions.Address.state', path '$.ShippingInstructions.Address.province', path '$.ShippingInstructions.Address.zipCode', path '$.ShippingInstructions.Address.country', path '$.ShippingInstructions.Phone[0].number’,

INSTRUCTIONS VARCHAR2(2048 CHAR) path '$.SpecialInstructions'

) m /

View created.

desc PURCHASEORDER_MASTER_VIEW -- Name Null

Typ ----------------------------------------- -------- -----------

PO_NUMBER REFERENCE REQUESTOR USERID COSTCENTER SHIP_TO_NAME … SHIP_TO_PHONE INSTRUCTIONS

NUMBER(10) VARCHAR2(30) VARCHAR2(128) VARCHAR2(10) VARCHAR2(16) VARCHAR2(20)

VARCHAR2(24) VARCHAR2(2048)


2 つ目の例では、PURCHASEORDER_DETAIL_VIEW という名前のリレーショナル・ビューを作成しています。

この例では、NESTED 句を使用して、LineItems 鍵に対応付けられた配列のコンテンツを処理しています。LineItems 鍵に対応付けられた配列の項目ごとに、表に 1 行存在します。

create or replace view PURCHASEORDER_DETAIL_VIEW as select D.*

from J_PURCHASEORDER p, JSON_TABLE(

p.PO_DOCUMENT , '$' columns ( PO_NUMBER NUMBER(10)

REFERENCE VARCHAR2(30 CHAR) REQUESTOR VARCHAR2(128 CHAR) USERID VARCHAR2(10 CHAR) COSTCENTER VARCHAR2(16) SHIP_TO_NAME VARCHAR2(20 CHAR) SHIP_TO_STREET VARCHAR2(32 CHAR) SHIP_TO_CITY VARCHAR2(32 CHAR) SHIP_TO_COUNTY VARCHAR2(32 CHAR) SHIP_TO_POSTCODE VARCHAR2(10 CHAR) SHIP_TO_STATE VARCHAR2(2 CHAR) SHIP_TO_PROVINCE VARCHAR2(2 CHAR) SHIP_TO_ZIP VARCHAR2(8 CHAR) SHIP_TO_COUNTRY VARCHAR2(32 CHAR) SHIP_TO_PHONE VARCHAR2(24 CHAR)

path '$.PONumber', path '$.Reference', path '$.Requestor', path '$.User', path '$.CostCenter', path '$.ShippingInstructions.name', path '$.ShippingInstructions.Address.street', path '$.ShippingInstructions.Address.city', path '$.ShippingInstructions.Address.county', path '$.ShippingInstructions.Address.postcode', path '$.ShippingInstructions.Address.state', path '$.ShippingInstructions.Address.province', path '$.ShippingInstructions.Address.zipCode', path '$.ShippingInstructions.Address.country', path '$.ShippingInstructions.Phone[0].number’,

INSTRUCTIONS VARCHAR2(2048 CHAR) path '$.SpecialInstructions', NESTED PATH '$.LineItems[*]' columns (

ITEMNO NUMBER(38) path '$.ItemNumber', DESCRIPTION VARCHAR2(256 CHAR) path '$.Part.Description', UPCCODE VARCHAR2(14 CHAR) path '$.Part.UPCCode', QUANTITY NUMBER(12,4) path '$.Quantity', UNITPRICE NUMBER(14,2) path '$.Part.UnitPrice'

) )

) D /

View created.


この技術を使用する最大の利点は、一旦ビューが作成されると、問合せを生成している管理者やツールに、JSON の構造体や、SQL を使用して JSON を操作する方法に関する知識がなくても、SQLのすべての機能を JSON コンテンツに適用できる点です。

リレーショナル・ビューを利用すると、JSON コンテンツを扱う際に、分析機能をはじめとする SQLの拡張機能を容易に使用することもできます。

select COSTCENTER, sum (QUANTITY * UNITPRICE) TOTAL_VALUE from PURCHASEORDER_DETAIL_VIEW

group by COSTCENTER /

COSTCENTER TOTAL_VALUE ---------------------------------------- ----------- A60 225478.7 A70 47635.85 A110 72195.3 A50 2057990.4 A20 83031.7 A90 128929.25 A80 1536779.8 A30 273025.85 A10 46066.45 A40 43230.1 A0 47807.4 A100

12 rows selected.

256465.35

select SHIP_TO_STREET, SHIP_TO_CITY, SHIP_TO_STATE, SHIP_TO_ZIP from PURCHASEORDER_MASTER_VIEW

where PO_NUMBER = 1600 /

SHIP_TO_STREET ----------------- 200 Sporting Green

SHIP_TO_CITY SH SHIP_TO_ -------------------------- -- -------- South San Francisco CA 99236

select PO_NUMBER, REFERENCE, QUANTITY, QUANTITY - LAG(QUANTITY,1,QUANTITY) over (ORDER BY PO_NUMBER) as DIFF

from PURCHASEORDER_DETAIL_VIEW where UPCCODE = '43396713994' order by PO_NUMBER DESC

/

PO_NUMBER REFERENCE QUANTITY DIFFERENCE --------- ---------------------------------------- ---------- ----------

9877 AWALSH-20141110 9 0 7873 SKING-20140309 9 7 7807 KMOURGOS-20140315 2 0 6168 KCHUNG-20140725 2 -5 5996 HBLOOM-20140715 7 2 5824 EABEL-20140706 5 -2 4768 SMARKLE-20140205 7 -1 2530 JAMRLOW-20140813 8 0

8 rows


これらのビューを使用することで、リレーショナル・パラダイムしか理解していない開発者や、とりわけツールが、JSON コンテンツを扱うことができるようになります。リレーショナル・ビューでは、Schema-on-Query セマンティックが効果的に提供されます。アプリケーション開発者は引き続き、必要に応じて JSON のコンテンツを自由に発展させることができるほか、既存のビューに依存するアプリケーションに影響を及ぼすことなく、JSON の新しいバリアントをデータベースに保存できます。

JSON_EXISTSを使用したJSONコンテンツの検索

JSON_EXISTS 演算子は、JSON ドキュメントに、提供された JSON パス式と一致する鍵と値のペアが含まれているかどうかをテストします。含まれている場合は TRUE を返し、含まれていない場合はFALSE を返します。JSON ドキュメントと JSON パス式という 2 つの引数を使用します。通常は SQL文の WHERE 句で使用され、JSON ドキュメントのコンテンツに基づき select 文で行をフィルタリングできるようにします。

以下の文では、JSON_EXISTS を使用して、JSON パス式に基づきドキュメントを検索する方法を示します。

この文では、ShippingInstructions 鍵に、state 鍵を含む Address 鍵がある場合の JSON ドキュメントの数を返します。

JSON_EXISTS を使用すると、鍵がない場合のドキュメントと、鍵が NULL または空である場合のドキュメントを区別できます。以下の例で説明します。

結果では、鍵が存在するものの空であるドキュメントが 91 あることが示されています。JSON_EXISTS を使用しなければ、結果セットを、鍵が存在するものの NULL である場合に限定することは不可能でした。

select count(*) from J_PURCHASEORDER

where JSON_EXISTS(PO_DOCUMENT ,'$.ShippingInstructions.Address.state') / COUNT(*) --------- 6369

select JSON_VALUE(PO_DOCUMENT ,'$.ShippingInstructions.Address.county') COUNTY, count(*)

from J_PURCHASEORDER where JSON_EXISTS(PO_DOCUMENT ,'$.ShippingInstructions.Address.county') group by JSON_VALUE(PO_DOCUMENT ,'$.ShippingInstructions.Address.county')

/

COUN

COUNT(*) ---------- --------

91 Oxon. 3173


以下の例では、case 句を使用して選択リストに JSON_EXISTS 操作の結果を含める方法を示します。

JSON_VALUEを使用した、複雑なJSONパス式の評価

JSON_VALUE 演算子を使用すると、JSON パス式を使用して、JSON ドキュメントから単一のスカラー値を返すことができます。JSON ドキュメントと JSON パス式という 2 つの引数を使用します。JSON_VALUE は、選択リストで列として使用することも、WHERE 句で条件の一部として使用することもできます。

簡素化された構文と比較した場合の、JSON_VALUE を使用する主な利点は、高度な JSON パス式の使用をサポートしている点です。加えて、値を返すために使用される SQL データ型を制御できる修飾子や、JSON パス式を評価する際に発生するエラーを制御できる修飾子も提供されます。

以下の文では、JSON_VALUE を使用して JSON ドキュメントからスカラー値を抽出する方法と、JSON コンテンツに基づき結果セットをフィルタリングする方法を示します。

この例では、CostCenter 鍵の値によってグループ分けされたドキュメントの数を取得する方法を示しています。JSON_VALUE 演算子を使用して、各ドキュメントから CostCenter 鍵の値にアクセスし、次に SQL の“Count”および“Group By”演算子を使用して、JSON_VALUE の出力に基づき必要な結果を生成しています。

2 つ目の例では、JSON_VALUE および JSON パス式を使用して、配列内から値にアクセスする方法を示します。さらに、WHERE 句で JSON_VALUE をフィルタとして使用して、JSON_VALUE によって返された値を SQL データ型に明示的に変換する方法も紹介します

SQL> select case when JSON_EXISTS(PO_DOCUMENT then 'TRUE'

else 'FALSE' end "County", case when JSON_EXISTS(PO_DOCUMENT ,'$.ShippingInstructions.Address.state')

then 'TRUE' else 'FALSE'

end "State" from J_PURCHASEORDER

where JSON_VALUE(PO_DOCUMENT ,'$.PONumber' returning NUMBER(10)) = 1600 /

County State ------- ----- FALSE TRUE

select JSON_VALUE(PO_DOCUMENT ,'$.CostCenter') CC, count(*) from J_PURCHASEORDER

group by JSON_VALUE(PO_DOCUMENT ,'$.CostCenter') /

CC COUNT(*) ---------- -----

A60 A30 A0 … A40

474 566 101

9

12 rows selected.


この例では、入力された索引条件が 0 であるため、JSON_VALUE は、LineItems 配列の最初のメンバーの Part 鍵に対応付けられたオブジェクトの、UnitPrice 鍵に対応付けられた値を返します。値は、SQL データ型の NUMBER(5,3)を使用して返されます。選択リストの JSON_VALUE 演算子のみが、WHERE 句の JSON_VALUE に基づく条件を満たした行に対して評価されます。WHERE 句のJSON_VALUE 演算子には RETURNING 句も含まれるため、SQL NUMBER データ型のセマンティックを使用して条件が評価されます。

JSON_VALUE では、JSON パス式を JSON ドキュメントに適用する際に発生する可能性のあるエラーを管理するオプションも提供されます。スキーマレス開発につきものの可変性により、SQL 操作の実行時にランタイム・エラーが発生しやすくなるため、柔軟なエラー処理は重要です。このエラー処理では、開発者は、すべての SQL 問合せが失敗に終わり、有用な結果が全く生成されないといったエラーをどのように処理するかを自由に決定できます。

JSON_VALUE のエラー処理オプションは以下のとおりです。

» NULL on ERROR：これがデフォルトです。JSON パス式を JSON ドキュメントに適用する際にエラーに遭遇した場合、結果は NULL と見なされ、エラーは発生しません。

» ERROR on ERROR：JSON パス式を JSON ドキュメントに適用する際にエラーに遭遇した場合、エラーが発生します。

» DEFAULT on ERROR：開発者が、JSON パス式を JSON ドキュメントに適用する際にエラーに遭遇した場合に返されるリテラルを指定します。

JSON_VALUE でエラーが発生するもっとも一般的な原因は、JSON パス式が、希望する SQL データ型のスカラー値ではなく、別の値に変換することです。“NULL on ERROR”の動作は、1 つの外れ値が引き起こす単一のエラーによって、操作全体が中断されないようにするものです。

4 つ目の例では、DEFAULT ON ERROR 句を使用して、JSON パス式を評価する際に遭遇するエラーを管理する方法を示します。

select JSON_VALUE(PO_DOCUMENT ,'$.LineItems[0].Part.UnitPrice' returning NUMBER(5,3)) UNIT_PRICE from J_PURCHASEORDER p

where JSON_VALUE(PO_DOCUMENT ,'$.PONumber' returning NUMBER(10)) = 1600 / UPC --------------- 13131092899

select JSON_VALUE( PO_DOCUMENT , '$.ShippingInstruction.Address' DEFAULT 'N/A' ON ERROR

) ADDRESS from J_PURCHASEORDER

where JSON_VALUE(PO_DOCUMENT ,’$.PONumber’ returning NUMBER(10)) = 1600 / ADDRESS ----------------------------- N/A


この例では、JSON パス式の最初の鍵でタイプミスがあったためにエラーとなりました。最初の鍵は ShippingInstruction ではなく、ShippingInstructions でなければなりません。提供された JSON パス式がスカラー値と一致しないため、“DEFAULT on ERROR”の動作が始動し、JSON_VALUE 演算子は“N/A”を返します。

JSON_QUERYを使用したオブジェクトと配列へのアクセス

JSON_QUERY は、JSON_VALUE とは正反対に機能します。JSON_VALUE が返すことができるのはスカラー値のみですが、JSON_QUERY 演算子は、JSON パス式を使用して JSON ドキュメントからオブジェクトまたは配列を返すことができます。JSON ドキュメントと JSON パス式という 2 つの引数を渡し、通常は選択リストで列として使用されます。

オブジェクトまたは配列は、JSON のテキスト表現を含む VARCHAR2(4000)データ型として返されます。配列は角括弧（‘[]’）によって区切られ、オブジェクトは波括弧（‘{}’）によって区切られます。JSON_QUERY では、オブジェクトや配列のフォーマット方法や、JSON パス式を評価する際に遭遇するエラーの処理方法を制御する修飾子も提供されます。

以下の文では、JSON_QUERY を使用して、JSON ドキュメントからオブジェクトと配列を抽出する方法を示します。最初の例では、ShippingInstructions 鍵に対応付けられたオブジェクトが返されます。

2 つ目の例では、LineItems 鍵に対応付けられた配列を返す方法を示します。

デフォルトでは、効率を最大限に高めるために、オブジェクトと配列は最小限の空白に表示されます。値を表示するために必要なバイト数を最小限に抑えることができるため、オブジェクトがコンピュータによって処理される場合に最適です。JSON_QUERY 操作の出力を人間が判読できるようにする必要がある場合は、JSON_QUERY で PRETTY キーワードを使用します。

select JSON_QUERY(PO_DOCUMENT ,'$.ShippingInstructions') SHIPPING_INSTRUCTIONS from J_PURCHASEORDER p

where JSON_VALUE(PO_DOCUMENT ,’$.PONumber’ returning NUMBER(10)) = 1600 / SHIPPING_INSTRUCTIONS ------------------------------------------------------------------------------- {"name":"Alexis Bull","Address":{"street":"200 Sporting Green","city":"South San Francisco","state":"CA","zipCode":99236,"country":"United States of America"},"Phone":[{"type":"Office","number":"909-555-7307"},{"type":"Mobile","number":"415-555-1234"}]}

select JSON_QUERY(PO_DOCUMENT ,'$.LineItems') LINEITEMS from J_PURCHASEORDER p

where JSON_VALUE(PO_DOCUMENT ,’$.PONumber’ returning NUMBER(10)) = 1600 / LINEITEMS ------------------------------------------------------------------------------- [{"ItemNumber":1,"Part":{"Description":"One Magic Christmas","UnitPrice":19.95, "UPCCode":13131092899},"Quantity":9.0},{"ItemNumber":2,"Part":{"Description":"Lethal Weapon","UnitPrice":19.95,"UPCCode":85391628927},"Quantity":5.0}]


3 つ目の例では、PRETTY キーワードを使用して、JSON_QUERY 演算子の出力をフォーマットする方法を示します。

PRETTY キーワードを使用すると、配列はきれいに字下げされた JSON として出力されるため、人間が理解しやすくなります。ただし、配列のコンテンツを表示するために必要なバイト数が大幅に増加するという代償が伴います。

JSON_QUERY では、JSON パス式を JSON ドキュメントに適用する際に遭遇する可能性のあるエラーを処理するためのオプションも提供されます。以下のオプションを使用できます。

» NULL on ERROR：これがデフォルトです。JSON パス式を JSON ドキュメントに適用する際にエラーに遭遇した場合、結果は NULL と見なされ、エラーの状態は発生しません。

» ERROR on ERROR：JSON パス式を JSON ドキュメントに適用する際にエラーに遭遇した場合、エラーが発生します。

» EMPTY on ERROR：JSON パス式を JSON ドキュメントに適用する際にエラーに遭遇した場合、空の配列“[]”が返されます。

» “WITH ARRAY WRAPPER”：結果が常に配列として返されるようにします。

» “WITH CONDITIONAL ARRAY WRAPPER”：スカラー値を 1 つの項目を持つ配列に変換します。

select JSON_QUERY(PO_DOCUMENT ,'$.LineItems' PRETTY) LINEITEMS from J_PURCHASEORDER p

where JSON_VALUE(PO_DOCUMENT ,’$.PONumber’ returning NUMBER(10)) = 1600 / LINEITEMS ------------------------------------------------------------ [

{ "ItemNumber" : 1, "Part" : {

"Description" :"One Magic Christmas", "UnitPrice" :19.95, "UPCCode" :13131092899

}, "Quantity" :9

}, {

"ItemNumber" : 2, "Part" : {

"Description" :"Lethal Weapon", "UnitPrice" :19.95, "UPCCode" :85391628927

}, "Quantity" :5

} ]


以下の例では、WITH CONDITIONAL ARRAY WRAPPER 句を使用して、JSON パス式で配列やオブジェクトではなく、スカラー値を評価する場合を管理する方法を示します。

JSON パス式の結果がスカラー値のため、JSON_QUERY は自動的に結果を 1 つの項目を持つ配列に変換し、その配列を返します。

最後の例では、WITH ARRAY WRAPPER 句を使用して、JSON_QUERY が常に結果を配列として返すようにします。

この例では、LineItems 鍵に対応付けられた索引はアスタリスク（*）です。つまり、LineItems 配列のすべてのメンバーを処理する必要があります。JSON パス式の最後のコンポーネントもアスタリスク（*）です。つまり、Part 鍵のすべての子を処理する必要があります。

LineItems 配列には 2 つの項目があり、Part 鍵に対応付けられたオブジェクトには 3 つの子があるため、この問合せの実行結果は、6 つの項目を持つ配列です。最初の 3 つの項目は、LineItems 配列の最初のメンバーの Part 鍵に対応付けられた鍵、Description、UnitPrice、および UPCCode から取得した項目です。残りの 3 つの項目は、LineItems 配列の 2 つ目のメンバーの Part 鍵に対応付けられた鍵、Description、UnitPrice、および UPCCode から取得した項目です。結果は、文字列と数値の両方を含む、異種の配列になります。

select JSON_QUERY( PO_DOCUMENT , '$.LineItems[0].Part.UPCCode' WITH CONDITIONAL ARRAY WRAPPER

) UPCCODE from J_PURCHASEORDER p

where JSON_VALUE(PO_DOCUMENT ,’$.PONumber’ returning NUMBER(10)) = 1600 / UPCCODE ------------------------ [13131092899]

select JSON_QUERY( PO_DOCUMENT , '$.LineItems[*].Part.*' WITH ARRAY WRAPPER

) ARRAY_VALUE from J_PURCHASEORDER p

where JSON_VALUE(PO_DOCUMENT ,’$.PONumber’ returning NUMBER(10)) = 1600 / ARRAY_VALUE ------------------------------------------------------------------------------- ["One Magic Christmas",19.95,13131092899,"Lethal Weapon",19.95,85391628927]


Oracle Database 12c Release 2に保存された

オラクルのドキュメントにおけるJSONの索引付け

Oracle Database 12c には、JSON ドキュメントを索引付けするための拡張機能が含まれています。JSON コンテンツを索引付けする方法は 2 つあります。

» 特定の鍵または鍵の組み合わせに基づき、ファンクション索引を作成する

» JSON ドキュメント全体で JSON 検索索引を作成する

これらの索引を使用すると、JSON コンテンツの問合せ操作が適切に最適化されるようになります。Oracle オプティマイザは、新しい SQL/JSON 演算子のいずれかを含む問合せを実行する場合に、これらの索引をどのように利用するかを理解しているためです。

ファンクションベースの索引は、JSON_VALUE 演算子を使用して定義します。そうすることで、JSON ドキュメント内の特定の鍵、または鍵の組み合わせに B ツリー索引を作成できるようになります。索引を作成するには、どの鍵を検索する必要があるかを把握しておく必要があります。

JSON 索引検索では、JSON ドキュメントの完全に逆引きのリスト・タイプ索引付けが可能です。これは、Oracle Text として知られる、オラクルの定評のある全文索引付けに基づきます。JSON 検索索引の利点は、索引付けされる JSON の構造や検索される鍵を事前に把握しておく必要がない点です。

ファンクション索引を使用したJSONコンテンツの索引付け

次の 2 つの条件が満たされていれば、JSON_VALUE を使用して JSON ドキュメントの任意の鍵に索引を作成できます。

» JSON パス式が、各ドキュメントで最大で 1 度しか現れない鍵に変換する必要がある

» JSON パス式が、スカラー値に変換する必要がある

JSON_VALUE を使用して作成される索引は、従来型の B ツリー索引、またはビットマップ索引のいずれかです。

以下の例では、Reference 鍵のコンテンツに一意の B ツリー索引を作成する方法を示します。

オラクルの簡素化された構文を使用して JSON ドキュメントを問い合わせる際に索引を使用する場合は、索引の作成時に“ERROR on ERROR”セマンティックを指定する必要があります。

create unique index PO_NUMBER_IDX on J_PURCHASEORDER(

JSON_VALUE( PO_DOCUMENT ,'$.PONumber'returning NUMBER(10) ERROR ON ERROR

) )

/ Index created.


次の例では、CostCenter 鍵のコンテンツにビットマップ索引を作成する方法を示します。

3 つ目の例では、zipCode 鍵のコンテンツに B ツリー索引を作成する方法を示します。

この例では、JSON_VALUE 演算子の RETURNING 句を使用することで、索引が確実に数値索引になるようにしています。

以下の例から分かるように、EXPLAIN PLAN を使用して、問合せの実行時に索引が使用されているかどうかを確認できます。

この SQL 文では、特定の発注書のすべての明細項目の合計コストを計算しています。WHERE 句でJSON_VALUE を使用し、処理するドキュメントを特定しています。EXPLAIN PLAN 出力には、一意の索引 PO_NUMBER_IDX を使用して必要なドキュメントを探し出していることが示されています。

create bitmap index COSTCENTER_IDX on J_PURCHASEORDER (JSON_VALUE(PO_DOCUMENT ,'$.CostCenter'))

/ Index created.

create index ZIPCODE_IDX on J_PURCHASEORDER(

JSON_VALUE( PO_DOCUMENT , '$.ShippingInstructions.Address.zipCode' returning NUMBER(5)

) )

/

select sum(QUANTITY * UNITPRICE) TOTAL_COST from J_PURCHASEORDER,

JSON_TABLE( PO_DOCUMENT , '$.LineItems[*]' columns(

QUANTITY NUMBER(12,4) path '$.Quantity', UNITPRICE NUMBER(14,2) path '$.Part.UnitPrice'

) )

where JSON_VALUE(PO_DOCUMENT ,’$.PONumber’ returning NUMBER(10)) = 1600 / TOTAL_COST ----------

279.3 Execution Plan ------------------------------------------------------------------------------ | Id | Operation | Name Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | SORT AGGREGATE | |

| | TABLE ACCESS BY INDEX ROWID | J_PURCHASEORDER |

INDEX UNIQUE SCAN | PO_NUMBER_IDX | JSONTABLE EVALUATION | |

| |

| 2 | | 3 | |* 4 | | 5 |

NESTED LOOPS

31 2 | |


JSON検索索引を使用したJSONコンテンツの索引付け

Oracle Database 12c では、JSON ドキュメント全体を索引付けすることもできるため、条件が実行時まで不明な場合でさえも、索引を使用した JSON コンテンツの検索が可能です。ドキュメントレベルの索引付けは、オラクルの全文索引付けテクノロジーに基づいています。現在、JSON ドキュメントの索引では、JSON_EXISTS 操作、および特定のクラスの JSON_VALUE 操作を最適化できます。

以下の文では、JSON ドキュメントのコレクションにドキュメントレベルの索引を作成しています。

索引は、事前定義された索引プリファレンスの CTXSYS.JSON_SECTION_GROUP を使用して作成されます。このプリファレンスは、JSON ドキュメントの索引付け向けに最適化されています。SYNC (ON COMMIT)により、挿入操作と更新操作がコミット時に確実に索引付けされます。

以下の例では、PONumber 鍵に問合せを実行しています。

EXPLAIN PLAN 出力には、ドキュメント索引に対するプリファレンスで既存の B ツリー索引が使用されていることが示されています。どちらの索引も問合せを最適化できるため、ドキュメント索引が作成された後も、PONumber の B ツリー索引が必要かどうかを検討する価値があります。

create index PO_DOCUMENT_INDEX on J_PURCHASEORDER(PO_DOCUMENT )

indextype is ctxsys.context parameters('section group CTXSYS.JSON_SECTION_GROUP SYNC (ON COMMIT)')

/ Index created.

select count(*), sum(QUANTITY * UNITPRICE) TOTAL_COST from J_PURCHASEORDER,



) )

where JSON_VALUE(PO_DOCUMENT ,'$.PONumber' returning NUMBER(10)) = 1600 / COUNT(*) TOTAL_COST ---------- ----------

2 279.3 Execution Plan ------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |

| | | | |*

0 | SELECT SORT

AGGREGATE

| | |

| | |

| |

1 | 1 |

8168 |

1983 |

1983 |

15M| 1979

3

(0)| 1

| 2 | 3

| |

TABLE ACCESS BY INDEX ROWID| INDEX UNIQUE

SCAN JSONTABLE

| PO_NUMBER_ID

31 2

(0)| 00:00:01 | (0)|

| |


2 つ目の例では、city 鍵に基づき問合せを実行しています。

EXPLAIN PLAN 出力には、ドキュメント索引を使用して問合せを解決していることが示されています。この例では、ドキュメント索引の大きな利点が立証されています。ドキュメント索引は、100%スキーマに依存せず、動的スキーマに基づく開発での使用に最適です。ドキュメント索引を使用すれば、JSON ドキュメントの問合せ時に使用される JSON パス式を事前に把握しておく必要はありません。ドキュメント索引が自動的にすべての可能な JSON パス式を索引付けします。




) )

where JSON_VALUE(PO_DOCUMENT ,'$.ShippingInstructions.Address.city') = 'Seattle'

/ COUNT(*) TOTAL_COST

---------- ---------- 7289 776682.2

Execution Plan --------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | | SELECT

STATEMENT

| | |

| | | |

3

(0)| | |

NESTED


最後の例では、city 鍵と CostCenter 鍵に対する条件が存在する問合せを示します。

EXPLAIN PLAN 出力には、CostCenter のドキュメント索引とビットマップ索引の両方を使用して問合せを解決していることが示されています。




) )

where JSON_VALUE(PO_DOCUMENT ,'$.ShippingInstructions.Address.city') = 'Seattle'

and JSON_VALUE(PO_DOCUMENT ,'$.CostCenter') = 'A90'

/ COUNT(*) TOTAL_COST

---------- ---------- 1194 128929.25

Execution Plan | SELECT STATEMENT

| | |

| | | |

3

(0)| | |

NESTED


結論 Oracle Database 12c Release 2 では、JSON ドキュメントを管理するための、NoSQL データベースの代替手段が提供されます。一般的な NoSQL データベースの全機能に加えて、ACID トランザクション、セキュリティ機能、SQL ベースの分析やレポート作成など、従来型のリレーショナル・データベースに求められる最低限の機能も提供されます。そのため企業は、現代のアプリケーション開発者が期待する使いやすさや柔軟性、および SQL のすべての機能とオラクルのデータ管理プラットフォームという双方の長所を手にすることができます。


Oracle Corporation, World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065, USA

海外からのお問い合わせ窓口

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

C O N N E C T W I T H U S

blogs.oracle.com/oracle

facebook.com/oracle

twitter.com/oracle

oracle.com

Copyright © 2014, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告

なく変更されることがあります。本文書は、その内容に誤りがないことを保証するものではなく、また、口頭による明示的保証や法律による黙

示的保証を含め、商品性ないし特定目的適合性に関する黙示的保証および条件などのいかなる保証および条件も提供するものではありません。

オラクルは本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとします。

本文書はオラクルの書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても

再作成または送信することはできません。

Oracle および Java は Oracle およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

Intel および Intel Xeon は Intel Corporation の商標または登録商標です。すべての SPARC 商標はライセンスに基づいて使用される SPARC

International, Inc.の商標または登録商標です。AMD、Opteron、AMD ロゴおよび AMD Opteron ロゴは、Advanced Micro Devices の商標または

登録商標です。UNIX は、The Open Group の登録商標です。0517

Documents

Oracle Database 12c Release 2を使用したJSONの …新しいAPIについては、別のホワイト・ペーパーで扱っていま す。本書は、SQLは理解しているが、JSONやJSONパス式については知識がないオラクル開発者の

Oracle Database 12c Release 2を使用したJSONの …新しいAPIについては、別のホワイト・ペーパーで扱っています。本書は、SQLは理解しているが、JSONやJSONパス式については知識がないオラクル開発者の