Guide Du Developpeur JSON

Machine Translated by Google
Base de données Oracle®
Guide du développeur
JSON 12c version 2 (12.2)
E5828717
avril 2017
Guide du développeur Oracle Database JSON, 12c version 2 (12.2)
E5828717
Copyright © 2015, 2017, Oracle et/ou ses filiales. Tous les droits sont réservés.
Auteur principal : Drew Adams
Contributeurs : équipes de développement Oracle JSON, de gestion de produits et d'assurance qualité.
Ce logiciel et la documentation associée sont fournis dans le cadre d'un contrat de licence contenant des restrictions d'utilisation
et de divulgation et sont protégés par les lois sur la propriété intellectuelle. Sauf dans les cas expressément autorisés dans votre
contrat de licence ou autorisés par la loi, vous ne pouvez pas utiliser, copier, reproduire, traduire, diffuser, modifier, concéder sous
licence, transmettre, distribuer, exposer, exécuter, publier ou afficher toute partie, sous quelque forme que ce soit, ou n'importe
comment. L'ingénierie inverse, le désassemblage ou la décompilation de ce logiciel, sauf si requis par la loi pour l'interopérabilité,
est interdit.
Les informations contenues dans ce document sont sujettes à modification sans préavis et ne sont pas garanties sans erreur. Si
vous trouvez des erreurs, veuillez nous les signaler par écrit.
S'il s'agit d'un logiciel ou d'une documentation connexe qui est livré au gouvernement des ÉtatsUnis ou à toute personne l'autorisant
au nom du gouvernement des ÉtatsUnis, l'avis suivant s'applique : UTILISATEURS FINAUX DU GOUVERNEMENT DES ÉTATS
UNIS : programmes Oracle, y compris tout système d'exploitation, logiciel intégré, tout programme installés sur le matériel et/ou la
documentation fournis aux utilisateurs finaux du gouvernement des ÉtatsUnis sont des « logiciels informatiques commerciaux »
conformément à la réglementation fédérale sur les acquisitions applicable et aux réglementations supplémentaires spécifiques à
l'agence. À ce titre, l'utilisation, la duplication, la divulgation, la modification et l'adaptation des programmes, y compris tout système
d'exploitation, logiciel intégré, tout programme installé sur le matériel et/ou la documentation, seront soumis aux conditions de licence
et aux restrictions de licence applicables aux programmes. .
Aucun autre droit n'est accordé au gouvernement américain.
Ce logiciel ou matériel est développé pour une utilisation générale dans une variété d'applications de gestion de l'information.
Il n'est pas développé ou destiné à être utilisé dans des applications intrinsèquement dangereuses, y compris des applications
pouvant créer un risque de blessure. Si vous utilisez ce logiciel ou ce matériel dans des applications dangereuses, vous serez
responsable de prendre toutes les mesures appropriées de sécurité, de sauvegarde, de redondance et autres pour garantir son
utilisation en toute sécurité. Oracle Corporation et ses filiales déclinent toute responsabilité pour tout dommage causé par l'utilisation
de ce logiciel ou matériel dans des applications dangereuses.
Oracle et Java sont des marques déposées d'Oracle et/ou de ses filiales. Les autres noms peuvent être des marques déposées de
leurs propriétaires respectifs.
Intel et Intel Xeon sont des marques ou des marques déposées d'Intel Corporation. Toutes les marques SPARC sont utilisées sous
licence et sont des marques ou des marques déposées de SPARC International, Inc. AMD, Opteron, le logo AMD et le logo AMD
Opteron sont des marques ou des marques déposées d'Advanced Micro Devices. UNIX est une marque déposée de The Open
Group.
Ce logiciel ou matériel et cette documentation peuvent fournir un accès ou des informations sur le contenu, les produits et les services
de tiers. Oracle Corporation et ses sociétés affiliées ne sont pas responsables et déclinent expressément toute garantie de quelque
nature que ce soit concernant le contenu, les produits et les services de tiers, sauf indication contraire dans un accord applicable
entre vous et Oracle. Oracle Corporation et ses sociétés affiliées ne seront pas responsables des pertes, coûts ou dommages
encourus en raison de votre accès ou de votre utilisation du contenu, des produits ou des services tiers, sauf tel qu'énoncé dans un
accord applicable entre vous et Oracle.
Contenu
Préface................................................. .................................................. .................................................. ...........xi
Public ................................................. .................................................. .................................................. .. xii
Accessibilité des documents .................................................. .................................................. ................... xii
Documents connexes................................................ .................................................. .................................... xii
Conventions................................................. .................................................. .................................................. xii
Exemples de codes .................................................. .................................................. .................................................. xiii
Jolie impression de données JSON .................................................. .................................................. ............ xiii Plans
d'exécution .................................. .................................................. .................................................. xiii
Rappel sur la sensibilité à la casse .................................................. .................................................. ... xiii
Modifications apportées à cette version du Guide du développeur JSON d'Oracle Database..xv
Modifications apportées à Oracle Database 12c Release 2 (12.2.0.1) pour Oracle Database ...................... ...... xv
Nouvelles fonctionnalités ................................................ .................................................. .................................... xv
Partie I Introduction aux données JSON et à la base de données Oracle
1 JSON dans la base de données Oracle
1.1 Présentation de JSON dans la base de données Oracle ...................................... ............................................... 12
1.2 Premiers pas avec JSON avec la base de données Oracle ...................................... ................................ 14
1.3 Prise en charge de la base de données Oracle pour JSON ...................................... .................................................. .. 15
2 Données JSON
2.1 Présentation de JSON .................................................. .................................................. ................................ 21
2.2 La syntaxe JSON et les données qu'elle représente.............................. ............................................. 22 2.3 JSON Par rapport à
XML .................................................. .................................................. ........... 24
Partie II Stocker et gérer les données JSON
3 Présentation du stockage et de la gestion des données JSON..................................... ........ 31
iii
4 Créer une table avec une colonne JSON
4.1 Déterminer si une colonne contient nécessairement des données JSON ...................................... 43
5 Conditions SQL/JSON EST JSON et N'EST PAS JSON
5.1 Champs uniques ou dupliqués dans les objets JSON.................................................. ............................... 51 5.2 À
propos de la syntaxe JSON stricte et laxiste .................. .................................................. ..................................... 52 5.3
Spécification d'une syntaxe JSON stricte ou laxiste ... .................................................. ....................................... 54
6 Jeux de caractères et codage de caractères pour les données JSON ...................... 61
7 Partitionnement des données JSON.............................................. .................................................. 71
8 Réplication des données JSON.................................................. ....................................... 81
Partie III Insérer, mettre à jour et charger des données JSON
9 Présentation de l'insertion, de la mise à jour et du chargement des données JSON.................. 91
10 Chargement de données JSON externes.............................................. ............................. 101
Partie IV Requête de données JSON
11 Accès simple par notation par points aux données JSON.................................. ........... 111
12 expressions de chemin SQL/JSON
12.1 Vue d'ensemble des expressions de chemin SQL/JSON.............................. ..................................... 121 12.2
Syntaxe d'expression de chemin SQL/JSON... .................................................. .................................. 122 12.2.1
Expression de chemin SQL/JSON de base Syntaxe ....................................................... ..................... 122
12.2.2 Assouplissement de la syntaxe de l'expression de chemin SQL/JSON.............................. ....................... 127
13 Clauses utilisées dans les fonctions et conditions de requête SQL/JSON
13.1 Clause RETURNING pour les fonctions de requête SQL/JSON ....................... ................ 131 13.2 Clause wrapper
pour les fonctions de requête SQL/JSON JSON_QUERY et JSON_TABLE ...... 133 13.3 Clause d'erreur pour les
fonctions de requête SQL/JSON et conditions .................................................. 134 13.4 Clause de champ vide pour les
fonctions de requête SQL/JSON ....................... ..................... 135
14 Condition SQL/JSON JSON_EXISTS
14.1 Utilisation de filtres avec JSON_EXISTS................................................ .................................................. 142 14.2
JSON_EXISTS en tant que JSON_TABLE.............................................. .................................................. ...... 143
15 Fonction SQL/JSON JSON_VALUE
15.1 Utilisation de la fonction SQL/JSON JSON_VALUE avec une valeur booléenne JSON.............. 152
iv
15.2 Fonction SQL/JSON JSON_VALUE appliquée à une valeur JSON nulle .................................. 15 3 15.3 JSON_VALUE
en tant que JSON_TABLE............................................ .................................................. .. 153
16 Fonction SQL/JSON JSON_QUERY
16.1 JSON_QUERY comme JSON_TABLE......................................................... .................................................. 162
17 Fonction SQL/JSON JSON_TABLE
17.1 JSON_TABLE généralise les fonctions et les conditions des requêtes SQL/JSON.............. 173 17.2 Utilisation de
JSON_TABLE avec des tableaux JSON.... .................................................. .............................. 175 17.3 Création d'une vue
sur les données JSON à l'aide de JSON_TABLE ........ .................................................. 17 6
18 Guide des données JSON
18.1 Présentation du guide de données JSON..................................... .................................................. ..... 182 18.2
Informations de guide de données persistantes : partie d'un index de recherche JSON .................. ........... 184 18.3 Formats
de guide de données et manières de créer un guide de données ...... .................................. 186 18.4 Champs du guide de
données JSON ...... .................................................. .................................................. 18 8 18.5 Spécification d'un nom
préféré pour une colonne de champ.............................. .................. 1811 18.6 Création d'une vue sur les données JSON
basée sur les informations du guide de données ........ .................. 1812 18.6.1 Création d'une vue sur les données JSON
basée sur un guide de données hiérarchiques......... .................. 1814 18.6.2 Création d'une vue sur les données
JSON basée sur une expression de chemin ...... ....... 1816
18.7 Ajout et suppression de colonnes virtuelles pour les champs JSON basés sur DataGuide
Renseignements ................................................. .................................................. .................................... 1819
18.7.1 Ajout de colonnes virtuelles pour les champs JSON en fonction d'un guide de données hiérarchique.
Indice .................................................. .................................................. ....................................... 1823
18.7.3 Suppression de colonnes virtuelles pour les champs JSON en fonction des informations du guide de données..
1825 .................................. 1826 18.8.1 Déclencheurs de changement de guide de données définis par
l'utilisateur.. .................................................. ................ 1827 18.9 Guides de données multiples par jeu de
documents .................. .................................................. .. 1829 18.10 Interrogation d'un guide de
données .................................. .................................................. ................ 1833
18.11 Un guide de données plates pour les documents de bon de commande.............................. ....................... 1835
18.12 Un guide de données hiérarchiques pour les documents de bon de commande.............. ..... 1840
Partie V Génération de données JSON
19 Génération de données JSON avec des fonctions SQL/JSON
19.1 Présentation des fonctions de génération SQL/JSON ....................................... ................................ 191 19.2 Fonction
JSON_OBJECT SQL/JSON ................ .................................................. .................. 194 19.3 Fonction JSON_ARRAY SQL/
JSON ............... .................................................. .................. 196 19.4 Fonction SQL/JSON
JSON_OBJECTAGG ................ .................................................. .............. 197 19.5 Fonction SQL/JSON
JSON_ARRAYAGG .................. .................................................. ... 198
v
Partie VI Types d'objets PL/SQL pour JSON
20 Présentation des types d'objets PL/SQL pour JSON ...................................... ......... 201
21 Utilisation des types d'objet PL/SQL pour JSON ...................................... ................ 211
Partie VII Données géographiques GeoJSON
22 Utilisation des données géographiques GeoJSON ............................................. ....................... 221
Partie VIII Réglage des performances pour JSON
23 Vue d'ensemble du réglage des performances pour JSON..................................... ......... 231
24 index pour les données JSON
24.1 Présentation de l'indexation des données JSON .................................. .................................................. 242
24.2 Comment savoir si un index basé sur une fonction pour les données JSON est sélectionné ................. 243
24.3 Création d'index bitmap pour la condition SQL/JSON JSON_EXISTS ..................................... 243 24.4
Création d'index basés sur la fonction JSON_VALUE .. .................................................. ................ 243 24.5
Utilisation d'un index basé sur la fonction JSON_VALUE avec des requêtes JSON_TABLE ................. ... 245 24.6
Utilisation d'un index basé sur la fonction JSON_VALUE avec des requêtes JSON_EXISTS ...... 245 24.7
Considérations sur les types de données pour l'indexation JSON_VALUE et interrogation................................. 247
24.8 Indexation de plusieurs champs JSON à l'aide d'un index composite BTree . ....................................... 248
24.9 Index de recherche JSON : requêtes ad hoc et recherche en texte intégral .................................................. ...... 249
25 Données JSON en mémoire
25.1 Vue d'ensemble des données JSON en mémoire.............................. .................................................. 25 1
25.2 Remplir les données JSON dans le magasin de colonnes en mémoire........................................ .............. 253
25.3 Mise à niveau des tables avec des données JSON à utiliser avec le magasin de colonnes en mémoire ...... 254
A Restrictions JSON de la base de données Oracle
Diagrammes B pour la syntaxe d'expression de chemin SQL/JSON de base
Indice
vi
Liste d'exemples
21 Un objet JSON (Représentation d'un littéral d'objet JavaScript) .................................. ........ 23 41 Utilisation de IS
JSON dans une
de contrainte
données de
JSON dvans
érification
pour sV
une colonne 'assurer que Jles
ARCHAR2 données JSON sont bien formées..........
SON.............................. .................. 4 1 42
42 Utilisation dIe
nsertion
IS JSON
dans une contrainte de vérification pour s'assurer que les données JSON sont strictement bien formées 51
(Standard)............................................... .................................................. ............................... 55 71 Création
d'une table
partitionnée
JSON à l'aide
dans une d'une
colonne colonne virtuelle JSON.... ..................................................
BLOB............................................ .................................... 91 711 91
01 Insertion
Création de odbjet
d'un onnées
de répertoire
de
ebxterne
table ase de
ed
t onnées pour àles
remplissage bons
partir de fcichier
d'un ommande. ...............................................
de vidage JSON ...... 10 2 103 Création 102 1d02
Ctréation
'une d'une
able avec
une
colonne BLOB JSON.......................................... ................................ 102 104 Copie de données JSON d'une table externe
vers une table de base de données .................................... 102 111 Requête en notation par points JSON comparée à
JSON_VALUE. ............................................. 113 11 2 Requête en notation par points JSON comparée à
JSON_QUERY........... .................................... 113 141 JSON_EXISTS : expression de chemin sans
filtre... .................................................. ............... 142 142 JSON_EXISTS : élément actuel et portée dans les filtres
d'expression de chemin d'accès................ ................ 142 143 JSON_EXISTS : les conditions de filtrage dépendent de
l'élément actuel .................. .................. 143 144 JSON_EXISTS : Réduction de la portée du
filtre .................. .................................................. .................... 143 145 JSON_EXISTS : expression de chemin utilisant
une expression de chemin existe ........ 143 146 JSON_EXISTS exprimé à l'aide de
JSON_TABLE .................................. .................................. 144 151 JSON_VALUE : deux manières de renvoyer un JSON
Valeur booléenne en SQL.............................. 152 152 Renvoi d' une valeur booléenne PL/SQL à partir de
VALEUR_JSON........................................ 152 153 JSON_VALUE exprimé à l'aide de
JSON_TABLE........................ .................................. 153 161 Sélection des valeurs JSON Utilisation de
JSON_QUERY................................................ .................. 162 162 JSON_QUERY exprimé à l'aide de
JSON_TABLE................ .................................................. 163 171 Accéder plusieurs fois aux données JSON pour extraire
les données.............. .....................
174 172 U1tilisation
analyses ........ .................................. 74 173 de JSON_TABLE
Projection pour extraire
JSON dees
d'un tableau données
en tant sqans
ntier ue dponnées
lusieurs
JSON ......... .................................................. ......... 175 174 Projection d'éléments d'un tableau
JSON ................................. .................................................. ...... 176 175 Projection d'éléments d'un tableau JSON plus
d'autres données.............. .......................... 176 176 JSON_TABLE : Projection d'éléments de tableau à l'aide de
NESTED........... ..................................... 176 177 Création ng une vue sur les données
JSON ................................................ ............................................... 177 178 Création d'une vue matérialisée sur des
données JSON..................................... ................................ 177 181 Activation de la prise en charge persistante pour un
guide de données JSON mais pas pour la recherche.... .................. 186 182 Désactivation de la prise en charge du guide
de données JSON pour un index de recherche JSON existant ...... ......... 186 183 Collecte de statistiques sur les données
JSON à l'aide d'un index de recherche JSON ...... ................ 186 184 Spécification des noms de colonne préférés pour
certains champs JSON ...... ...................... 1812 185 Création d'une vue à l'aide d'un guide de données obtenu avec
GET_INDEX_DATAGUIDE ..... 1815 186 Création une vue qui projette tous les champs
scalaires ......................................... .................. 1817 187 Création d'une vue qui projette des champs scalaires ciblés par
une expression de chemin ....... ....... 1817 188 Création d'une vue qui Projette des champs scalaires ayant une fréquence
donnée............ 1818 189 Ajout de colonnes virtuelles projetant des champs JSON à l'aide d'un guide de données obtenu
avec
GET_INDEX_DATAGUIDE......................................................... .................................................. 1821 1810
Ajout Colonnes virtuelles, masquées et visibles.................................................. ....................... 1822 1811 Projection de
tous les champs scalaires non sous un tableau sous forme de colonnes virtuelles.......... .................. 1824 1812 Projection
de champs scalaires avec une fréquence minimale sous forme de colonnes virtuelles ...... .... 1824 1813 Projection de
champs scalaires avec une fréquence minimale en tant que colonnes virtuelles masquées..... 1825 1814 Suppression de
colonnes virtuelles projetées à partir de champs JSON ........... .................................. 1826 1815 Ajout automatique de
colonnes virtuelles avec modification Déclencheur ADD_VC.............. 1826 1816 Traçage des mises à jour du guide de
données avec un déclencheur de modification défini par l'utilisateur.......... .................. 1828 1817 Ajout d'un bon de
commande 2015.............. .................................................. ...... 1830 1818 Ajout d'un Pur 2016 ChaseDocument de
commande .................................................. ....................... 1831
vii
1819 Création de guides de données multiples avec la fonction d'agrégation JSON_DATAGUIDE.......... 1831 1820
Interrogation d'un guide de données obtenu à l'aide de JSON_DATAGUIDE................. ....................... 1833 1821
Interrogation d'un guide de données avec des données d'index pour des trajets avec une fréquence d'au moins 80 % ......
1834 1822 Guide des données plates pour les bons de commande ...................... .................................................. 1835
1823 Hiérarchique Guide de données pour les bons de commande.............................................. .................. 1840 191
Déclaration d'une valeur d'entrée au format JSON ...... .................................................. .................. 194 192 Utilisation de
JSON_OBJECT pour construire des objets JSON ...... .................................................. 195 193 Utilisation de JSON_OBJECT
avec ABSENT ON NULL ................................................ ..................... 195 194 Utilisation de JSON_ARRAY pour construire
un tableau JSON ...... .................................... ............ 196 195 Utilisation de JSON_OBJECTAGG pour construire un objet
JSON .................. ................................ 197 196 Utilisation de JSON_ARRAYAGG pour construire un tableau
JSON ........ ............................................... 198 211 Construction et sérialisation d'un objet JSON en
mémoire.............................. ........... 211 212 Utilisation de la méthode GET_KEYS() pour obtenir une liste de champs
d'objets................. .................. 212 213 Utilisation de la méthode PUT() pour mettre à jour des parties de documents
JSON.......... ..................................... 212 221 Un tableau avec des données
GeoJSON.. .................................................. ............................................... 222 222 Sélection d'un objet géométrique à partir
d'une fonctionnalité GeoJSON en tant que SDO_GEOMETRY
Exemple................................................. .................................................. .................................. 223
223 Récupération de plusieurs objets de géométrie à partir d'une fonction GeoJSON en tant que SDO_GEOMETRY
.................................................. .................................................. .................................................. 223 224
Création d'un index spatial pour les données GeoJSON......................................... .............................. 224 225 Utilisation de
la géométrie GeoJSON avec des opérateurs spatiaux ........ .................................................. ... 224 241 Création d'un index
bitmap pour JSON_EXISTS............................... ....................................... 243 242 Création d'un index bitmap pour
JSON_VALUE......................................................... .................................. 243 243 Création d'un index basé sur une fonction
pour un champ JSON : Notation par points ...... ............................... 244 244 Création d'un index basé sur une fonction pour
un champ JSON : JSON_VALUE. ................................ 244 245 Spécification de NULL ON EMPTY pour un index basé sur
la fonction JSON_VALUE ..................... 244 246 Utilisation d'un index basé sur la fonction JSON_VALUE avec un Requête
JSON_TABLE............ 245 247 Champ de ciblage de la requête JSON_EXISTS par rapport au nombre
littéral.............. .................. 246 248 Champ de ciblage de requête JSON_EXISTS comparé à la valeur de la
variable................ .............. 246 249 Requête JSON_EXISTS ciblant un champ converti en nombre par rapport à une valeur
de variable.... 247 2410 Requête JSON_EXISTS ciblant une conjonction de comparaisons de champs. .............................
247 2411 Requête JSON_VALUE avec NUMÉRO DE RETOUR explicite ......... ................................... 248 2412 Requête
JSON_VALUE avec conversion numérique explicite... ................................................ 248 2413 Requête JSON_VALUE
avec conversion numérique implicite.............................. .. 248 2414 Création de colonnes virtuelles pour les champs d'objets
JSON.............. .................................. 249 2415 Création d'un index composite Btree pour les champs d'objet
JSON ...... .................................................. 249 2416 Deux manières d'interroger des données JSON indexées avec un
index composite.............. 24 9 2417 Création d'un index de recherche JSON..................................... .................................................. ....
2410 2418 Indication du plan d'exécution qu'un index de recherche JSON est utilisé.............. ............ 2410 2419 Requête
en texte intégral des données JSON ...................... .................................................. .................... 2410 2420 Requête en
texte intégral des données JSON, avec modèle de recherche échappée ................ .............................. 2410 2421 Quelques
requêtes JSON ad hoc ......... .................................................. .................................. 2411 251 Remplissage des données
JSON dans la messagerie instantanée Magasin de colonnes .................................................. ................ 254
viii
Liste des tableaux
51 Exemples de syntaxe de champ d'objet JSON..................................... ............................................... 53
131 Exemples de clauses d'encapsulation JSON_QUERY.............. ................................ 133 181 Fonctions
SQL et PL/SQL pour obtenir un guide de données .................................................. ........ 187 182 Champs
de schéma JSON (motsclés) ...................... .................................................. ............ 188 183 Champs du
guide de données spécifiques à Oracle ...... .................................................. ............... 189 184 Noms
préférés pour certaines colonnes de champ JSON ...................... .................................................. 1811 185
Paramètres d'un Procédure de déclenchement de changement de guide de données défini par
l'utilisateur ................. 1827 221 Objets de géométrie GeoJSON autres que les collections de géométrie. .............................
ix
X
Préface
Ce manuel décrit l'utilisation des données JSON stockées dans la base de données Oracle. Il explique comment
stocker, générer, afficher, manipuler, gérer, rechercher et interroger.
Les sujets
Public (page xi)
Le guide du développeur Oracle Database JSON est destiné aux développeurs qui
créent des applications JSON Oracle Database.
Accessibilité de la documentation (page xi)
Documents connexes (page xii)
Pour plus d'informations, consultez les ressources Oracle suivantes.
Conventions (page xii)
Les conventions utilisées dans ce document sont décrites.
Exemples de code (page xiii)
Les exemples de code de ce livre sont fournis à titre indicatif uniquement. Dans de nombreux
cas, cependant, vous pouvez copier et coller des parties d'exemples et les exécuter dans
votre environnement.
Public
Le guide du développeur Oracle Database JSON est destiné aux développeurs qui créent des applications
JSON Oracle Database.
Une compréhension de JSON est utile lors de l'utilisation de ce manuel. De nombreux exemples
fournis ici sont en SQL ou PL/SQL. Une connaissance pratique de l'une de ces langues est présumée.
Accessibilité des documents
Pour plus d'informations sur l'engagement d'Oracle en matière d'accessibilité, visitez le site Web
Oracle Accessibility Program à l' adresse http://www.oracle.com/pls/topic/lookup? ctx=acc&id=docacc.
Accès au support Oracle Les clients
Oracle qui ont souscrit au support ont accès au support électronique via My Oracle Support. Pour plus
d' informations , visitez http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info ou visitez http://
www.oracle.com/pls/topic/lookup? ctx=acc&id=trs si vous êtes malentendant.
xii
Documents connexes
Pour plus d'informations, consultez les ressources Oracle suivantes.
• Oracle Database New Features Guide pour plus d'informations sur les différences entre Oracle Database 12c et Oracle
Database 12c Enterprise Edition en ce qui concerne les fonctionnalités et options disponibles. Ce livre décrit également
les nouvelles fonctionnalités d'Oracle Database 12c Release 2 (12.2).
• Référence des messages d'erreur de la base de données Oracle. Message d'erreur de la base de données Oracle
la documentation n'est disponible qu'au format HTML. Si vous n'avez accès qu'à la documentation imprimée ou PDF
de la base de données Oracle, vous pouvez parcourir les messages d'erreur par plage. Une fois que vous avez trouvé
la plage spécifique, utilisez la fonction de recherche (trouver) de votre navigateur Web pour localiser le message spécifique.
Lorsque vous êtes connecté à Internet, vous pouvez rechercher un message d'erreur spécifique à l'aide de la fonction de
recherche de message d'erreur de la documentation en ligne d'Oracle Database.
• Oracle en tant que magasin de documents pour plus d'informations sur l'accès simple aux documents Oracle
(UN SODA)
• Concepts de base de données Oracle
• Guide en mémoire de la base de données Oracle
• Référence du langage SQL de la base de données Oracle
• Référence du langage PL/SQL de la base de données Oracle
• Référence des packages et des types Oracle Database PL/SQL
• Référence de texte Oracle
• Guide du développeur d'applications Oracle Text
• Guide de développement de base de données Oracle
Pour télécharger gratuitement des notes de version, de la documentation d'installation, des livres blancs ou d'autres
supports, veuillez visiter le Oracle Technology Network (OTN). Vous devez vous inscrire en ligne avant d'utiliser OTN;
l'inscription est gratuite et peut se faire sur
http://www.oracle.com/technetwork/community/join/overview/index.html
Si vous avez déjà un nom d'utilisateur et un mot de passe pour OTN, vous pouvez accéder directement à la section de
documentation du site Web OTN à l'adresse
http://www.oracle.com/technetwork/indexes/documentation/
Pour plus d'informations, consultez :
• ISO/IEC 132492:2000, Technologies de l'information Langages de base de données SQL
Ensembles multimédia et d'application Partie 2 : texte intégral, international
Organisation de normalisation, 2000
Conventions Les
conventions utilisées dans ce document sont décrites.
xii
Convention Sens
caractères gras Les caractères gras indiquent les éléments de l'interface utilisateur graphique
associés à une action ou les termes définis dans le texte ou le glossaire.
italique Le type italique indique les titres de livre, l'emphase ou les variables d'espace réservé pour
lesquelles vous fournissez des valeurs particulières.
monospace Le type à espacement fixe indique les commandes dans un paragraphe, les URL, le
code dans les exemples, le texte qui apparaît à l'écran ou le texte que vous saisissez.
Exemples de code Les
exemples de code de ce manuel sont fournis à titre indicatif uniquement. Dans de nombreux cas, cependant,
vous pouvez copier et coller des parties d'exemples et les exécuter dans votre environnement.
Les sujets
Jolie impression des données JSON (page xiii)
Pour favoriser la lisibilité, en particulier des données JSON longues ou complexes, la sortie est
parfois affichée joliment imprimée (formatée) dans les exemples de code.
Plans d'exécution (page xiii)
Certains des exemples de code de ce livre présentent des plans d'exécution. Ceuxci sont à titre
indicatif seulement. L'exécution des exemples présentés ici dans votre environnement entraînera
probablement des plans d'exécution différents de ceux présentés ici.
Rappel concernant la sensibilité à la casse (page xiii)
JSON est sensible à la casse. SQL est insensible à la casse, mais les noms dans le code SQL
sont implicitement en majuscules.
Jolie impression des données JSON
Pour favoriser la lisibilité, en particulier des données JSON longues ou complexes, la sortie est parfois
affichée joliment imprimée (formatée) dans les exemples de code.
Programmes d'exécution
Certains des exemples de code de ce livre présentent des plans d'exécution. Ceuxci sont à titre indicatif
seulement. L'exécution des exemples présentés ici dans votre environnement entraînera probablement des plans
d'exécution différents de ceux présentés ici.
Rappel concernant la sensibilité à la casse
JSON est sensible à la casse. SQL est insensible à la casse, mais les noms dans le code SQL sont implicitement en
majuscules.
Lorsque vous examinez les exemples de ce livre, gardez à l'esprit les points suivants :
• SQL ne respecte pas la casse, mais les noms dans le code SQL sont implicitement en majuscules, sauf si vous
les placez entre guillemets doubles (").
• JSON est sensible à la casse. Vous devez faire référence aux noms SQL dans le code JSON en respectant la
casse : les noms SQL en majuscules doivent être écrits en majuscules.
xiii
Par exemple, si vous créez une table nommée my_table dans SQL sans utiliser de guillemets
doubles, vous devez vous y référer dans le code JSON en tant que "MY_TABLE".
xiv
Changements dans cette version pour Oracle
Guide du développeur de base de données JSON
Oracle Database JSON Developer's Guide est un nouveau livre dans Oracle Database 12c Release 2 (12.2.0.1).
Des informations sur l'utilisation des données JSON dans Oracle Database 12c Release 1 (12.1.0.2) sont disponibles
dans Oracle XML DB Developer's Guide.
Les sujets
Modifications apportées à Oracle Database 12c Release 2 (12.2.0.1) pour Oracle Database (page xv)
Les modifications apportées à la prise en charge de JSON et dans Oracle Database JSON Developer's
Guide for Oracle Database 12c Release 2 (12.2.0.1) sont décrites.
Modifications apportées à Oracle Database 12c Release 2 (12.2.0.1) pour Oracle Database Les modifications apportées à la prise en charge de JSON
et au guide du développeur Oracle Database JSON pour Oracle Database 12c Release 2 (12.2.0.1) sont décrites.
Les sujets
Nouvelles fonctionnalités (page xv)
Les fonctionnalités suivantes sont nouvelles dans cette version.
Nouvelles fonctionnalités
Les fonctionnalités suivantes sont nouvelles dans cette version.
Stockage et gestion des données JSON (page xv)
Requêtes de données JSON (page xvi)
Performances (page xviii)
Autre (page xix)
Stockage et gestion des données JSON
Les sujets
Partitionnement des données JSON (page xvi)
Vous pouvez maintenant partitionner une table en utilisant une colonne virtuelle JSON comme
clé de partitionnement.
xv
Index de recherche JSON sur une table partitionnée (page xvi)
Vous pouvez désormais créer un index de recherche JSON sur une table de base partitionnée (avec
partitionnement par plage, liste, hachage ou intervalle).
Partitionnement de données
JSON Vous pouvez désormais partitionner une table en utilisant une colonne virtuelle JSON comme clé de partitionnement.
Voir également:
Partitionnement des données JSON (page 71)
Index de recherche JSON sur une table partitionnée
Vous pouvez désormais créer un index de recherche JSON sur une table de base partitionnée (avec partitionnement par
plage, liste, hachage ou intervalle).
Requêtes de données JSON
Les sujets
Améliorations de l'expression de chemin (page xvi)
Les expressions de chemin JSON peuvent désormais inclure des expressions de filtre qui doivent être
satisfaites par les données correspondantes et les méthodes de transformation qui peuvent les
transformer.
La syntaxe simple de la notation par points prend en charge l'accès aux tableaux (page xvii)
Vous pouvez désormais accéder aux tableaux et à leurs éléments à l'aide de la simple syntaxe de
notation par points.
Guide des données (page xvii)
Vous pouvez maintenant créer un guide de données JSON, qui capture les informations structurelles
d'un ensemble de documents JSON. Il agit comme un schéma dérivé et est conservé avec les données
JSON qu'il représente. Il peut également enregistrer des statistiques sur les valeurs scalaires utilisées
dans les documents.
Fonctions et conditions SQL/JSON ajoutées à PL/SQL (page xvii)
Les fonctions SQL/JSON json_value, json_query, json_object et json_array, ainsi que la condition SQL/
JSON json_exists, ont été ajoutées au langage PL/SQL en tant que fonctions intégrées (json_exists est une
fonction booléenne en PL/SQL).
Prise en charge de JSON_VALUE et JSON_TABLE pour les types de données supplémentaires (page xvii)
Vous pouvez désormais utiliser les types de données SQL SDO_GEOMETRY, DATE, TIMESTAMP et
TIMESTAMP WITH TIME ZONE avec les fonctions SQL/JSON json_value et json_table.
Améliorations des expressions de chemin
Les expressions de chemin JSON peuvent désormais inclure des expressions de filtre qui doivent être satisfaites par les
données correspondantes et les méthodes de transformation qui peuvent les transformer.
Voir également:
Syntaxe d'expression de chemin SQL/JSON de base (page 122)
xvi
La syntaxe simple de notation par points prend en charge l'accès aux
tableaux Vous pouvez désormais accéder aux tableaux et à leurs éléments à l'aide de la syntaxe simple de notation par points.
Guide des données
Vous pouvez maintenant créer un guide de données JSON, qui capture les informations structurelles d'un ensemble de
documents JSON. Il agit comme un schéma dérivé et est conservé avec les données JSON qu'il représente. Il peut
également enregistrer des statistiques sur les valeurs scalaires utilisées dans les documents.
Voir également:
Guide des données JSON (page 181)
Fonctions et conditions SQL/JSON ajoutées à PL/SQL
Les fonctions SQL/JSON json_value, json_query, json_object et json_array, ainsi que la condition SQL/JSON
json_exists, ont été ajoutées au langage PL/SQL en tant que fonctions intégrées (json_exists est une fonction booléenne
en PL/SQL).
Voir également:
Utiliser PL/SQL avec des données JSON (page 13)
Prise en charge de JSON_VALUE et JSON_TABLE pour des types de données
supplémentaires Vous pouvez désormais utiliser les types de données SQL SDO_GEOMETRY, DATE,
TIMESTAMP et TIMESTAMP WITH TIME ZONE avec les fonctions SQL/JSON json_value et json_table.
Vous pouvez spécifier n'importe lequel d'entre eux comme type de données de retour pour la fonction
SQL/JSON json_value, et vous pouvez spécifier n'importe lequel d'entre eux comme type de données de colonne
pour la fonction SQL/JSON json_table.
SDO_GEOMETRY est utilisé pour les données Oracle Spatial et Graph. Cela signifie notamment que vous pouvez
utiliser ces fonctions avec des données GeoJSON, qui est un format d'encodage de données géographiques en
JSON.
Voir également:
• Clause RETURNING pour les fonctions de requête SQL/JSON (page 131)
• Fonction SQL/JSON JSON_TABLE (page 171)
• http://geojson.org/
xvii
Performance
Les sujets
Améliorations de la recherche (page xviii)
Vous pouvez utiliser une syntaxe plus simple pour créer un index de recherche JSON. La recherche
par plage est désormais disponible pour les nombres et les chaînes JSON qui peuvent être convertis en
types de date et d'heure intégrés.
Fonctions et conditions de requête SQL/JSON réécrites dans JSON_TABLE (page xviii)
L'optimiseur réécrira désormais souvent plusieurs invocations de json_exists, json_value et
json_query (n'importe quelle combinaison) en moins d'invocations de json_table. Cela améliore
généralement les performances car les données ne sont analysées qu'une seule fois pour chaque invocation
de json_table.
Colonnes JSON dans le magasin de colonnes en mémoire (page xviii)
Vous pouvez désormais stocker des colonnes JSON dans le magasin de colonnes en mémoire pour
améliorer les performances des requêtes.
Vues matérialisées sur les données JSON (page xix)
Vous pouvez désormais créer une vue matérialisée sur les données JSON projetées sous forme de colonnes
VARCHAR2 ou NUMBER.
Améliorations de la recherche
Vous pouvez utiliser une syntaxe plus simple pour créer un index de recherche JSON. La recherche par plage est
désormais disponible pour les nombres et les chaînes JSON qui peuvent être convertis en types de date et d'heure
intégrés.
Voir également:
Index de recherche JSON : requêtes ad hoc et recherche en texte intégral (page 249)
Fonctions et conditions de requête SQL/JSON réécrites dans JSON_TABLE Désormais ,
l'optimiseur réécrit souvent plusieurs invocations de json_exists, json_value et json_query (toute combinaison) en
moins d'invocations de json_table. Cela améliore généralement les performances car les données ne sont analysées
qu'une seule fois pour chaque invocation de json_table.
Voir également:
JSON_TABLE généralise les fonctions et conditions de requête SQL/JSON (page 173)
Colonnes JSON dans le magasin de colonnes en mémoire
Vous pouvez désormais stocker des colonnes JSON dans le magasin de colonnes en mémoire pour améliorer les performances
des requêtes.
xviii
Voir également:
Données JSON en mémoire (page 251)
Vues matérialisées sur les données JSON
Vous pouvez désormais créer une vue matérialisée sur les données JSON projetées sous forme de colonnes VARCHAR2 ou
NUMBER.
La fonction SQL/JSON json_table projette des données JSON spécifiques sous forme de colonnes VARCHAR2 ou
NUMBER. Vous pouvez généralement augmenter les performances des requêtes en créant une vue matérialisée
sur ces colonnes. La vue doit être en lecture seule : une clause FOR UPDATE n'est pas autorisée lors de sa création.
L'actualisation complète et incrémentielle de la vue est prise en charge. Vous pouvez souvent augmenter davantage les
performances des requêtes en créant des index sur les colonnes de la vue.
Voir également:
Création d'une vue sur les données JSON à l'aide de JSON_TABLE (page 176)
Autre
Les sujets
Fonctions SQL/JSON pour la génération de données JSON (page xix)
Vous pouvez désormais construire des données JSON par programmation à l'aide des fonctions SQL/
JSON json_object, json_array, json_objectagg et json_arrayagg.
API PL/SQL pour les données JSON (page xix)
Les API PL/SQL sont désormais disponibles pour fournir (1) des opérations de guide de données et
(2) des opérations d'obtention et de définition sur des types d'objets JSON qui sont soutenus par une
représentation en mémoire, hiérarchique et programmatique.
Colonnes JSON dans une table partagée (page xx)
Vous pouvez maintenant créer une colonne JSON dans une table partitionnée et interroger ces
données JSON.
Fonctions SQL/JSON pour la génération de données JSON
Vous pouvez désormais créer des données JSON par programmation à l'aide des fonctions SQL/JSON json_object,
json_array, json_objectagg et json_arrayagg.
Voir également:
Génération de données JSON (page 1)
API PL/SQL pour les données JSON
Les API PL/SQL sont désormais disponibles pour fournir (1) des opérations de guide de données et (2) des opérations
d'obtention et de définition sur des types d'objets JSON qui sont soutenus par une représentation en mémoire, hiérarchique
et programmatique.
xix
Voir également:
• Guide des données JSON (page 181)
• Types d'objets PL/SQL pour JSON (page 1)
Colonnes JSON dans une table partagée
Vous pouvez maintenant créer une colonne JSON dans une table partitionnée et interroger ces données JSON.
Vous pouvez stocker des données JSON dans une colonne de type VARCHAR2 (jusqu'à 32 767 octets), CLOB ou BLOB
dans une table partitionnée. Vous ne pouvez pas interroger les données JSON sur plusieurs partitions à moins qu'elles ne
soient stockées en tant que VARCHAR2.
xx
Première partie
Introduction aux données JSON et à Oracle
Base de données
Commencez à comprendre les données JSON et comment vous pouvez utiliser SQL et PL/SQL avec les données
JSON stockées dans Oracle Database.
Le développement sans schéma basé sur des données d'application persistantes sous la forme de documents JSON
vous permet de réagir rapidement à l'évolution des exigences de l'application. Vous pouvez modifier et redéployer
votre application sans avoir à modifier les schémas de stockage qu'elle utilise.
Les bases de données SQL et relationnelles offrent une prise en charge flexible pour l'analyse et la création de rapports
de données complexes, ainsi qu'une protection des données et un contrôle d'accès à toute épreuve. Ce n'est généralement
pas le cas pour les bases de données NoSQL, qui ont souvent été associées au développement sans schéma avec
JSON dans le passé.
Oracle Database offre tous les avantages des bases de données SQL et relationnelles aux données JSON, que vous
stockez et manipulez de la même manière et avec la même confiance que tout autre type de données de base de données.
Chapitres
JSON dans la base de données Oracle (page 11)
Oracle Database prend en charge les données JSON (JavaScript Object Notation) de
manière native avec des fonctionnalités de base de données relationnelles, notamment les
transactions, l'indexation, les requêtes déclaratives et les vues.
Données JSON (page 21)
JavaScript Object Notation (JSON) est défini dans les normes ECMA404 (JSON Data Interchange
Format) et ECMA262 (ECMAScript Language Specification, troisième édition). Le dialecte
JavaScript d'ECMAScript est un langage de programmation général largement utilisé dans les
navigateurs Web et les serveurs Web.
1
JSON dans la base de données Oracle
Oracle Database prend en charge les données JSON (JavaScript Object Notation) de manière native avec
des fonctionnalités de base de données relationnelles, notamment les transactions, l'indexation, les requêtes
déclaratives et les vues.
Cette documentation couvre l'utilisation des langages et des fonctionnalités de base de données pour travailler avec
les données JSON stockées dans Oracle Database. En particulier, il explique comment utiliser SQL et PL/SQL avec
des données JSON.
Noter:
Oracle fournit également une famille de Simple Oracle Document Access (SODA)
API d'accès aux données JSON stockées dans la base de données. SODA est conçu pour le
développement d'applications sans schéma sans connaissance des fonctionnalités des bases de
données relationnelles ou des langages tels que SQL et PL/SQL. Il vous permet de créer et de stocker
des collections de documents dans Oracle Database, de les récupérer et de les interroger, sans avoir
besoin de savoir comment les documents sont stockés dans la base de données.
Il existe deux implémentations de SODA :
• SODA pour Java — Classes Java qui représentent la base de données, la collection et
document.
• SODA pour REST — Opérations SODA en tant que requêtes REST (Representational State Transfer),
utilisant n'importe quel langage capable d'effectuer des appels HTTP.
Pour plus d'informations sur SODA, voir Oracle en tant que magasin de documents.
Les sujets
Présentation de JSON dans Oracle Database (page 12)
Les données JSON et les données XML peuvent être utilisées dans Oracle Database de
manière similaire. Contrairement aux données relationnelles, les deux peuvent être stockées,
indexées et interrogées sans avoir besoin d'un schéma qui définit les données. Oracle Database
prend en charge nativement JSON avec des fonctionnalités de base de données relationnelles,
notamment les transactions, l'indexation, les requêtes déclaratives et les vues.
Premiers pas avec JSON avec Oracle Database (page 14)
En général, vous effectuerez les tâches suivantes lorsque vous travaillez avec des données
JSON dans Oracle Database : (1) créer une colonne JSON avec une contrainte de vérification
is json, (2) insérer des données JSON dans la colonne et (3) interroger les données JSON .
Prise en charge de la base de données Oracle pour JSON (page 15)
La prise en charge d'Oracle Database pour JavaScript Object Notation (JSON) est conçue
pour offrir la meilleure adéquation entre les mondes du stockage relationnel
JSON dans la base de données Oracle 11
Présentation de JSON dans Oracle Database
et interroger les données JSON, permettant aux requêtes relationnelles et JSON de bien fonctionner
ensemble. La prise en charge d'Oracle SQL/JSON est étroitement alignée sur la prise en charge de
JSON dans la norme SQL.
1.1 Présentation de JSON dans Oracle Database Les données JSON et les
données XML peuvent être utilisées dans Oracle Database de manière similaire. Contrairement aux données
relationnelles, les deux peuvent être stockées, indexées et interrogées sans avoir besoin d'un schéma qui définit les
données. Oracle Database prend en charge nativement JSON avec des fonctionnalités de base de données relationnelles,
notamment les transactions, l'indexation, les requêtes déclaratives et les vues.
Les données JSON ont souvent été stockées dans des bases de données NoSQL telles que Oracle NoSQL Database et
Oracle Berkeley DB. Cellesci permettent le stockage et la récupération de données qui ne sont basées sur aucun
schéma, mais elles n'offrent pas les modèles de cohérence rigoureux des bases de données relationnelles.
Pour pallier cette lacune, une base de données relationnelle est parfois utilisée en parallèle avec une base de
données NoSQL. Les applications utilisant des données JSON stockées dans la base de données NoSQL doivent
alors assurer ellesmêmes l'intégrité des données.
La prise en charge native de JSON par Oracle Database évite de telles solutions de contournement. Il offre tous les
avantages des fonctionnalités de base de données relationnelles à utiliser avec JSON, y compris les transactions,
l'indexation, les requêtes déclaratives et les vues.
Les requêtes SQL (Structured Query Language) sont déclaratives. Avec Oracle Database, vous pouvez utiliser SQL
pour joindre des données JSON à des données relationnelles. Et vous pouvez projeter les données JSON de manière
relationnelle, en les rendant disponibles pour les processus et outils relationnels. Vous pouvez également interroger, à
partir de la base de données, des données JSON stockées en dehors d'Oracle Database dans une table externe.
Vous pouvez accéder aux données JSON stockées dans la base de données de la même manière que vous
accédez à d'autres données de base de données, notamment à l'aide de l'interface d'appel Oracle (OCI), de
Microsoft .NET Framework et de Java Database Connectivity (JDBC).
Dans Oracle Database, les données JSON sont stockées à l'aide des types de données SQL courants VARCHAR2, CLOB
et BLOB (contrairement aux données XML, qui sont stockées à l'aide du type de données SQL abstrait XMLType). Oracle
vous recommande de toujours utiliser une contrainte de vérification is_json pour vous assurer que les valeurs de colonne
sont des instances JSON valides (voir Exemple 41 (page 41)).
Par définition, les données textuelles JSON sont encodées à l'aide d'un encodage Unicode, UTF8 ou UTF16. Vous
pouvez utiliser des données textuelles stockées dans un jeu de caractères non Unicode comme s'il s'agissait de données
JSON, mais dans ce cas, Oracle Database convertit automatiquement le jeu de caractères en UTF8 lors du traitement
des données.
Colonnes JSON dans les tables de base de données
Oracle Database n'impose aucune restriction sur les tables pouvant être utilisées pour stocker des documents
JSON. Une colonne contenant des documents JSON peut coexister avec tout autre type de données de base de
données. Une table peut également avoir plusieurs colonnes contenant des documents JSON.
Lorsque vous utilisez Oracle Database en tant que magasin de documents JSON, vos tables contenant des colonnes
JSON ont généralement également quelques colonnes de gestion interne non JSON. Ceuxci suivent généralement les
métadonnées sur les documents JSON.
Si vous utilisez JSON pour ajouter de la flexibilité à une application principalement relationnelle, certaines de vos tables
ont probablement également une colonne pour les documents JSON, que vous utilisez pour gérer les données
d'application qui ne correspondent pas directement à votre modèle relationnel.
12 Guide du développeur Oracle Database JSON
Présentation de JSON dans Oracle Database
Utiliser SQL avec des données JSON
Dans SQL, vous pouvez accéder aux données JSON stockées dans la base de données Oracle à l'aide de fonctions
et de conditions spécialisées ou d'une simple notation par points. La plupart des fonctions et conditions SQL sont
des fonctions standard SQL/JSON, mais quelquesunes sont spécifiques à Oracle.
• Fonctions de génération SQL/JSON json_object, json_array, json_objectagg et json_arrayagg. Ils collectent des
données SQL pour produire des données JSON (sous forme de valeur SQL).
• Il en va de même pour la fonction d'agrégation Oracle SQL json_dataguide, mais la
Les données JSON qu'il produit sont un guide de données, que vous pouvez utiliser pour découvrir des
informations sur la structure et le contenu d'autres données JSON dans la base de données.
• Fonctions de requête SQL/JSON json_value, json_query et json_table, et conditions de requête SQL/JSON
json_exists, is json, is not json et json_textcontains. Ceuxci évaluent les expressions de chemin SQL/JSON
par rapport aux données JSON pour produire des valeurs SQL.
• Une notation par points qui agit comme une combinaison de fonctions de requête json_value et json_query et
ressemble à une expression d'accès à un objet SQL, c'estàdire une notation par points d'attribut pour un type
de données abstrait (ADT). C'est le moyen le plus simple d'interroger les données JSON dans la base de
données.
À titre d'illustration simple de l'interrogation, voici une requête en notation par points des documents stockés dans
la colonne JSON po_document de la table j_purchaseorder (alias ici po). Il obtient tous les demandeurs de bons
de commande (champ JSON Requestor).
SELECT po.po_document.Requestor FROM j_purchaseorder po;
Utiliser PL/SQL avec des données JSON
Vous pouvez généralement utiliser du code SQL, y compris du code SQL qui accède aux données JSON, dans le
code PL/SQL. Vous ne pouvez pas utiliser un nom de champ JSON vide dans un code SQL que vous utilisez en PL/
SQL.
Les fonctions et conditions SQL/JSON suivantes sont également disponibles en tant que fonctions PL/SQL
intégrées : json_value, json_query, json_object, json_array et json_exists. (En PL/SQL, la condition SQL json_exists
est une fonction booléenne.)
Contrairement au cas d'Oracle SQL, qui n'a pas de type de données BOOLEAN, PL/SQL BOOLEAN est un type de
données de retour valide pour la fonction SQL/JSON json_value.
Il existe également des types d'objets PL/SQL pour JSON, que vous pouvez utiliser pour une construction et
une manipulation fines des données JSON en mémoire. Vous pouvez l'introspecter, le modifier et le sérialiser en
données textuelles JSON.
Premiers pas avec JSON avec Oracle Database
Voir également:
• Accès simple par notation par points aux données JSON (page 111)
• Présentation des expressions de chemin SQL/JSON (page 121)
• Guide des données JSON (page 181)
• Prise en charge de la base de données Oracle pour JSON (page 15)
• Jeux de caractères et codage de caractères pour les données JSON (page 61) pour plus d'informations
sur la conversion automatique des jeux de caractères
• Types d'objets PL/SQL pour JSON (page 1)
1.2 Premiers pas avec JSON avec Oracle Database
En général, vous effectuerez les tâches suivantes lorsque vous travaillez avec des données JSON dans Oracle
Database : (1) créer une colonne JSON avec une contrainte de vérification is json, (2) insérer des données JSON
dans la colonne et (3) interroger les données JSON .
1. Créez une table avec une colonne de clé primaire et une colonne JSON, puis ajoutez un is
json vérifie la contrainte pour s'assurer que la colonne JSON ne contient que des données JSON bien formées.
L'instruction suivante crée la table j_purchaseorder avec la clé primaire id et la colonne JSON po_document (voir
aussi l' exemple 41 (page 41)).
CRÉER TABLE j_purchaseorder
(identifiant VARCHAR2 (32) CLÉ PRIMAIRE NON NULL,
date_loaded TIMESTAMP (6) AVEC FUSEAU HORAIRE, po_document
VARCHAR2 (32767)
CONTRAINTE assurer_json VÉRIFIER (po_document EST JSON));
2. Insérez les données JSON dans la colonne JSON, en utilisant l'une des méthodes disponibles pour
Oracle Database.
L'instruction suivante utilise une instruction SQL INSERT pour insérer des données JSON simples dans la troisième
colonne de la table j_purchaseorder (qui est la colonne po_document — voir cidessus). Certaines des données JSON
sont élidées ici (...). Voir Exemple 42 (page 42) pour ces détails.
INSÉRER DANS j_purchaseorder
VALEURS (SYS_GUID(),
to_date('30DEC2014'),
'{"PONuméro" : 1600, :
"Référence" "ABULL20140421", : "Alexis
"Demandeur" Bull", : "ABULL", : "A50",
"Utilisateur" "ShippingInstructions" : {...},
"Centre de coûts" "Special Instructions" : null,
"AllowPartialShipment" : true, " Éléments de campagne"
: [...]}');
3. Interrogez les données JSON. La valeur de retour est toujours une instance VARCHAR2 qui
représente une valeur JSON. Voici quelques exemples simples.
Prise en charge de la base de données Oracle pour JSON
La requête suivante extrait, de chaque document de la colonne JSON po_document, une valeur scalaire , le
numéro JSON qui est la valeur du champ PONumber pour les objets de la colonne JSON po_document (voir
aussi Exemple 111 (page 113)) :
SELECT po.po_document.PONumber FROM j_purchaseorder bon de commande ;
La requête suivante extrait, de chaque document, un tableau d'objets phone JSON, qui est la valeur du
champ Phone de l'objet qui est la valeur du champ
ShippingInstructions (voir aussi Exemple 112 (page 113)) :
SELECT po.po_document.ShippingInstructions.Phone FROM j_purchaseorder bon de commande ;
La requête suivante extrait, de chaque document, plusieurs valeurs sous forme de tableau : la valeur du
type de champ pour chaque objet du tableau Phone. Le tableau renvoyé ne fait pas partie des données
stockées mais est construit automatiquement par la requête. (L'ordre des éléments du tableau n'est pas
spécifié.)
SELECT po.po_document.ShippingInstructions.Phone.type FROM j_purchaseorder po;
Voir également:
• Création d'une table avec une colonne JSON (page 41)
1.3 Prise en charge de la base de données Oracle pour JSON La prise
en charge de la base de données Oracle pour JavaScript Object Notation (JSON) est conçue pour fournir la
meilleure adéquation entre les mondes du stockage relationnel et de l'interrogation des données JSON,
permettant aux requêtes relationnelles et JSON de bien fonctionner ensemble. La prise en charge d'Oracle SQL/
JSON est étroitement alignée sur la prise en charge de JSON dans la norme SQL.
Voir également:
• ISO/IEC 90752:2016, Technologies de l'information—Langages de bases de données—SQL—
Partie 2 : Fondation (SQL/Foundation)
• http://www.json.org
• http://www.ecmainternational.org
Prise en charge de la base de données Oracle pour JSON
16 Guide du développeur JSON
2
Données JSON
JavaScript Object Notation (JSON) est défini dans les normes ECMA404 (JSON Data Interchange Format) et
ECMA262 (ECMAScript Language Specification, troisième édition). Le dialecte JavaScript d'ECMAScript est un
langage de programmation général largement utilisé dans les navigateurs Web et les serveurs Web.
Les sujets
Présentation de JSON (page 21)
JavaScript Object Notation (JSON) est défini dans les normes ECMA404 (JSON Data Interchange
Format) et ECMA262 (ECMAScript Language Specification, troisième édition). Le dialecte
JavaScript d'ECMAScript est un langage de programmation général largement utilisé dans les
navigateurs Web et les serveurs Web.
Syntaxe JSON et données qu'elle représente (page 22)
Les valeurs, les scalaires, les objets et les tableaux JSON (et JavaScript) sont décrits.
JSON comparé à XML (page 24)
JSON et XML (Extensible Markup Language) sont couramment utilisés comme langages d'échange
de données. Leurs principales différences sont listées ici.
2.1 Présentation de JSON
JavaScript Object Notation (JSON) est défini dans les normes ECMA404 (JSON Data Interchange Format) et
ECMA262 (ECMAScript Language Specification, troisième édition). Le dialecte JavaScript d'ECMAScript est un
langage de programmation général largement utilisé dans les navigateurs Web et les serveurs Web.
JSON est presque un sousensemble de la notation littérale d'objet de JavaScript.11 Parce qu'il peut être utilisé pour
représenter des littéraux d'objet JavaScript, JSON sert généralement de langage d'échange de données. En cela, il a
beaucoup en commun avec XML.
Parce qu'il s'agit (presque d'un sousensemble de) la notation JavaScript, JSON peut souvent être utilisé dans
les programmes JavaScript sans avoir besoin d'analyse ou de sérialisation. Il s'agit d'une manière textuelle de
représenter les littéraux d'objet JavaScript, les tableaux et les données scalaires.
Bien qu'il ait été défini dans le contexte de JavaScript, JSON est en fait un format de données indépendant
du langage. Une variété de langages de programmation peuvent analyser et générer des données JSON.
JSON est relativement facile à lire et à écrire pour les humains, et facile à analyser et à générer pour les logiciels. Il
est souvent utilisé pour sérialiser des données structurées et les échanger sur un réseau, généralement entre un
serveur et des applications Web.
1
JSON diffère de la notation JavaScript à cet égard : JSON autorise les caractères Unicode non échappés U+2028 (LINE SEPARATOR)
et U+2029 (PARAGRAPH SEPARATOR) dans les chaînes. La notation JavaScript nécessite que les caractères de contrôle tels que
ceuxci soient échappés dans les chaînes. Cette différence peut être importante lors de la génération de données JSONP (JSON avec
remplissage).
Données JSON 21
La syntaxe JSON et les données qu'elle représente
Voir également:
• http://www.ecmainternational.org/publications/
normes/Ecma404.htm et http://tools.ietf.org/html/rfc4627 _ pour la définition du format
d'échange de données JSON
• http://www.ecmainternational.org/publications/
normes/Ecma262.htm pour la spécification du langage ECMAScript
• http://www.json.org pour plus d'informations sur JSON
2.2 La syntaxe JSON et les données qu'elle représente
Les valeurs, les scalaires, les objets et les tableaux JSON (et JavaScript) sont décrits.
Une valeur JSON est l'une des valeurs suivantes : objet, tableau, nombre, chaîne, booléen (vrai ou faux)
ou null. Toutes les valeurs, à l'exception des objets et des tableaux, sont scalaires.
Noter:
Une valeur JSON de null est une valeur en ce qui concerne SQL. Ce n'est pas NULL, qui en
SQL représente l' absence de valeur (données manquantes, inconnues ou inapplicables).
En particulier, la condition SQL IS NULL renvoie false pour une valeur nulle JSON et la
condition SQL IS NOT NULL renvoie true.
Un objet JavaScript est un tableau associatif, ou dictionnaire, de zéro ou plusieurs paires de noms de
propriété et de valeurs JSON associées.22 Un objet JSON est un littéral d'objet JavaScript. 33 Il est écrit
comme une telle liste de propriétés entourée d'accolades ({, }), avec des paires nomvaleur séparées par
des virgules (,), et avec le nom et la valeur de chaque paire séparés par deuxpoints (:). (Les espaces avant
ou après la virgule ou les deuxpoints sont facultatifs et non significatifs.)
Dans JSON, chaque nom de propriété et chaque valeur de chaîne doivent être placés entre
guillemets doubles ("). En notation JavaScript, un nom de propriété utilisé dans un littéral d'objet peut être,
mais pas nécessairement, placé entre guillemets doubles. Il peut également être entre guillemets simples (').
En raison de cette différence, dans la pratique, les données représentées à l'aide de noms de propriété sans
guillemets ou entre guillemets simples sont parfois désignées de manière approximative comme étant représentées
dans JSON, et certaines implémentations de JSON, y compris l'implémentation de la base de données Oracle,
prennent en charge la syntaxe laxiste qui permet l'utilisation de noms de propriété sans guillemets et entre guillemets
simples.
Une chaîne dans JSON est composée de caractères Unicode, la barre oblique inverse (\) s'échappant.
Un nombre JSON (chiffre) est représenté en notation décimale, éventuellement signé et comprenant
éventuellement un exposant décimal.
Une propriété d'objet est généralement appelée un champ. On l'appelle parfois une clé, mais cette
documentation utilise généralement « champ » pour éviter toute confusion avec d'autres utilisations ici
du mot « clé ». Une paire nomvaleur de propriété d'objet est souvent appelée membre d'objet (mais parfois
membre peut signifier uniquement la propriété). L'ordre n'est pas significatif parmi les membres de l'objet.
2 Les objets JavaScript sont donc similaires aux tables de hachage en C et C++, aux HashMaps en Java, aux tableaux associatifs en
PHP, aux dictionnaires en Python et aux hachages en Perl et Ruby.
3 Un objet est créé en JavaScript en utilisant soit le constructeur Object , soit la syntaxe littérale d'objet : {...}.
La syntaxe JSON et les données qu'elle représente
Noter:
• Un nom de champ JSON peut être vide (écrit "").44
• Chaque nom de champ dans un objet JSON donné n'est pas nécessairement unique ; le même
nom de champ peut être répété. L' évaluation de chemin SQL/JSON qu'Oracle Database
utilise utilise toujours un seul des membres d'objet qui ont un nom de champ donné ; tous les
autres membres portant le même nom sont ignorés. Il n'est pas précisé lequel de ces multiples
membres est utilisé.
Voir aussi Champs uniques et champs en double dans les objets JSON (page 51).
Un tableau JavaScript contient zéro ou plusieurs éléments. Un tableau JSON est représenté par
des crochets ([, ]) entourant les représentations des éléments du tableau (également appelés éléments),
qui sont séparés par des virgules (,) et dont chacun est un objet, un tableau ou une valeur scalaire. L'ordre
des éléments du tableau est important. (Les espaces avant ou après un crochet ou une virgule sont facultatifs
et non significatifs.)
Exemple 21 Un objet JSON (représentation d'un littéral d'objet JavaScript)
Cet exemple montre un objet JSON qui représente un bon de commande, avec des noms de champ de
niveau supérieur PONumber, Reference, Requestor, User, Costcenter, ShippingInstruction, Special
Instructions, AllowPartialShipment et LineItems.
{ "PONuméro" : 1600,
"Référence" : "ABULL20140421",
"Demandeur" : "Alexis Taureau",
"Utilisateur" : "UN TAUREAU",
"Centre de coûts" : "A50",
"ShippingInstructions" : { "nom" : "Alexis Bull",
"Adresse": { "rue" : "200 Sporting Green", "ville"
: "South San Francisco", "state" :
"CA", "zipCode" : 99236, "country" : "United
States of America" }, [ { "type" : "Office",
"number" : "909 5557307" },
"Téléphone" :
{ "type" : "Mobile", "numéro" : "4155551234" } ] },
"Instructions Particulières" : null,
"AllowPartialShipment" : faux,
"Éléments de campagne" : [ { "NuméroArticle" : 1,
"Partie" : { "Description" : "Un Noël magique",
"PrixUnit" : 19.95, "CodeUPC" :
13131092899 },
"Quantité" : 9.0 },
{ "NuméroArticle" : 2,
"Partie" : { "Description" : "Arme fatale",
"PrixUnit" : 19.95, "CodeUPC" :
85391628927 },
"Quantité" : 5.0 } ] }
• La plupart des champs ici ont des valeurs de chaîne. Par exemple : le champ Utilisateur a une valeur
"UN TAUREAU".
• Les champs PONumber et zipCode ont des valeurs numériques : 1600 et 99236.
4
Dans certains contextes, un nom de champ vide ne peut pas être utilisé avec Oracle Database. Partout où il peut être utilisé, le nom doit
être entouré de guillemets doubles.
Données JSON 23
JSON comparé à XML
• Les instructions d'expédition sur le terrain ont un objet comme valeur. Cet objet a trois membres, avec des
champs nom, adresse et téléphone. Le nom du champ a une valeur de chaîne ("Alexis Bull").
• La valeur du champ Adresse est un objet avec les champs rue, ville, état,
code postal et pays. Le champ zipCode a une valeur numérique ; les autres ont des valeurs de
chaîne.
• Field Phone a un tableau comme valeur. Ce tableau a deux éléments, dont chacun est un objet. Chacun
de ces objets a deux membres : les champs type et nombre avec leurs valeurs.
• Les instructions spéciales de champ ont une valeur nulle.
• Le champ AllowPartialShipment a la valeur booléenne false.
• Le champ LineItems a un tableau comme valeur. Ce tableau a deux éléments, dont chacun est un
objet. Chacun de ces objets a trois membres, avec des champs ItemNumber, Part et Quantity.
• Les champs ItemNumber et Quantity ont des valeurs numériques. Field Part a un objet comme valeur,
avec les champs Description, UnitPrice et UPCCode. La description du champ a une valeur de
chaîne. Les champs UnitPrice et UPCCode ont des valeurs numériques.
Voir également:
• À propos de la syntaxe JSON stricte et laxiste (page 52)
• Exemple 42 (page 42)
2.3 JSON comparé à XML
JSON et XML (Extensible Markup Language) sont couramment utilisés comme langages d'échange de
données. Leurs principales différences sont listées ici.
JSON est plus utile avec des données simples et structurées. XML est utile pour les données structurées et
semistructurées. JSON est généralement centré sur les données et non sur les documents ; XML peut être
l'un ou l'autre. JSON n'est pas un langage de balisage ; il est conçu uniquement pour la représentation des
données. XML est à la fois un langage de balisage de document et un langage de représentation de données.
• Les types de données JSON sont peu nombreux et prédéfinis. Les données XML peuvent être sans
type ou basées sur un schéma XML ou une définition de type de document (DTD).
• JSON a des constructions simples de définition de structure et de combinaison de documents : il manque
d'attributs, d'espaces de noms, d'héritage et de substitution.
• L'ordre des membres d'un littéral d'objet JavaScript est insignifiant. En général,
l'ordre compte dans un document XML.
• Il manque à JSON un équivalent des nœuds de texte XML (XPath node test text()). Dans
particulier, cela signifie qu'il n'y a pas de contenu mixte (ce qui est une autre façon de dire que
JSON n'est pas un langage de balisage).
• JSON n'a pas de type de données de date (contrairement à XML et JavaScript). Une date est
représenté dans JSON à l'aide des types de données disponibles, tels que string. Il y a quelques
normes de facto pour la conversion entre les dates et les chaînes JSON. Mais les programmes
utilisant JSON doivent, d'une manière ou d'une autre, gérer la conversion de la représentation de la date.
En raison de leur définition et de leurs fonctionnalités simples, les données JSON sont généralement plus
faciles à générer, analyser et traiter que les données XML. Les cas d'utilisation impliquant la combinaison
de différentes sources de données se prêtent généralement bien à l'utilisation de XML, car il offre des
espaces de noms et d'autres constructions facilitant la modularité et l'héritage.
Données JSON 25
Partie II
Stocker et gérer les données JSON
Cette partie couvre la création de colonnes JSON dans une table de base de données, le partitionnement de ces
tables, leur réplication à l'aide d'Oracle GoldenGate et l'encodage du jeu de caractères des données JSON. Il couvre
l'utilisation de la condition SQL/JSON is json comme contrainte de vérification pour garantir que les données d'une
colonne sont des données JSON bien formées.
Chapitres
Présentation du stockage et de la gestion des données JSON (page 31)
Cette présentation décrit : (1) les types de données pour les colonnes JSON, (2) les
considérations de stockage LOB pour les données JSON et (3) la garantie que les colonnes
JSON contiennent des données JSON bien formées.
Création d'une table avec une colonne JSON (page 41)
Vous pouvez créer une table contenant des colonnes JSON. Vous utilisez la condition SQL est json
comme contrainte de vérification pour vous assurer que les données insérées dans une colonne sont
des données JSON (bien formées). Oracle recommande de toujours utiliser une contrainte de
vérification is_json lorsque vous créez une colonne destinée aux données JSON.
Conditions SQL/JSON EST JSON et N'EST PAS JSON (page 51)
Les conditions SQL/JSON est json et n'est pas json sont complémentaires.
Ils testent si leur argument est syntaxiquement correct, c'estàdire des données JSON bien
formées . Vous pouvez les utiliser dans une expression CASE ou dans la clause WHERE d'une
instruction SELECT.
Jeux de caractères et codage de caractères pour les données JSON (page 61)
Les données textuelles JSON utilisent toujours le jeu de caractères Unicode. À cet égard, les
données JSON sont plus simples à utiliser que les données XML. Il s'agit d'une partie importante du
format d'échange de données JSON (RFC 4627). Pour les données JSON traitées par Oracle
Database, toutes les conversions de jeu de caractères nécessaires sont effectuées automatiquement.
Partitionnement des données JSON (page 71)
Vous pouvez partitionner une table en utilisant une colonne virtuelle JSON comme clé de
partitionnement. La colonne virtuelle est extraite d'une colonne JSON à l'aide de la fonction SQL/
JSON json_value.
Réplication des données JSON (page 81)
Vous pouvez utiliser Oracle GoldenGate pour répliquer des tables qui ont des colonnes
contenant des données JSON.
3
Présentation du stockage et de la gestion de JSON
Données
Cette présentation décrit : (1) les types de données pour les colonnes JSON, (2) les considérations
de stockage LOB pour les données JSON et (3) la garantie que les colonnes JSON contiennent des données
JSON bien formées.
Types de données pour les colonnes JSON
Vous pouvez stocker des données JSON dans Oracle Database à l'aide de colonnes dont les types de données
sont VARCHAR2, CLOB ou BLOB. Le choix de celui à utiliser est généralement motivé par la taille des documents
JSON que vous devez gérer :
• Utilisez VARCHAR2(4000) si vous êtes sûr que vos plus gros documents JSON ne dépassent pas 4000 octets (ou
caractères)11 .
Si vous utilisez Oracle Exadata, le choix de VARCHAR2(4000) peut améliorer les performances en
permettant à l'exécution de certaines opérations JSON d'être poussée vers les cellules de stockage Exadata,
pour de meilleures performances.
• Utilisez VARCHAR2(32767) si vous savez que certains de vos documents JSON sont supérieurs à 4000
octets (ou caractères) et que vous êtes sûr qu'aucun des documents ne dépasse 32767 octets (ou
caractères)1 .
Avec VARCHAR2(32767), les premiers octets (ou caractères) d'environ 3,5 Ko d'un document sont
stockés en ligne, dans le cadre de la ligne du tableau. Cela signifie que le coût supplémentaire lié à l'utilisation
de VARCHAR2(32767) au lieu de VARCHAR2(4000) s'applique uniquement aux documents dont la taille est
supérieure à 3,5 Ko environ. Si la plupart de vos documents sont plus petits que cela, vous remarquerez
probablement peu de différence de performances par rapport à l'utilisation de VARCHAR2(4000).
Si vous utilisez Oracle Exadata, le refoulement est activé pour tous les documents stockés en ligne.
• Utilisez le stockage BLOB (binary large object) ou CLOB (character large object) si vous
sachez que certains de vos documents JSON font plus de 32767 octets (ou caractères)1 .
Le fait que vous stockiez des données JSON dans la base de données à l'aide de types de données SQL standard
signifie que vous pouvez manipuler des données JSON comme vous manipuleriez n'importe quelle autre donnée de
ces types. Le stockage de données JSON à l'aide de types de données standard permet à toutes les fonctionnalités
d'Oracle Database, telles que la réplication avancée, de fonctionner avec des tables contenant des documents JSON.
Considérations lors de l'utilisation du stockage LOB pour les données JSON Oracle
recommande d'utiliser le stockage BLOB et non CLOB.
1 Le fait que la limite soit exprimée en octets ou en caractères est déterminé par le paramètre de session
NLS_LENGTH_SEMANTICS.
Présentation du stockage et de la gestion des données JSON 31
Ceci est particulièrement pertinent si le jeu de caractères de la base de données est la valeur AL32UTF8
recommandée par Oracle. Dans les bases de données AL32UTF8, les instances CLOB sont stockées à l'aide
du jeu de caractères UCS2, ce qui signifie que chaque caractère nécessite deux octets. Cela double le stockage
nécessaire pour un document si la majeure partie de son contenu est constituée de caractères représentés à
l'aide d'un seul octet dans le jeu de caractères AL32UTF8.
Même dans les cas où le jeu de caractères de la base de données n'est pas AL32UTF8, choisir le stockage
BLOB plutôt que CLOB a l'avantage d'éviter d'avoir à convertir le jeu de caractères lors du stockage du document
JSON (voir Jeux de caractères et codage de caractères pour les données JSON (page 61 )).
Lorsque vous utilisez des objets volumineux (LOB), Oracle vous recommande de procéder comme suit :
• Utilisez la clause LOB (COLUMN_NAME) STORE AS (CACHE) dans votre instruction CREATE TABLE
pour vous assurer que les opérations de lecture sur les documents JSON sont optimisées à l'aide du
cache de tampon de la base de données.
• Utilisez les LOB SecureFiles. Envisagez également d'utiliser Oracle Advanced Compression pour
réduisez l'espace de stockage nécessaire pour vos données JSON. Si vous utilisez la compression, Oracle
recommande l'option Compression moyenne, qui offre un bon équilibre entre les économies d'espace et les
performances.
Les fonctions et conditions SQL/JSON fonctionnent avec les données JSON sans aucune considération
particulière, que les données soient stockées en tant que BLOB ou CLOB. Du point de vue du
développement d'applications, les appels d'API pour travailler avec du contenu BLOB sont presque
identiques à ceux pour travailler avec du contenu CLOB.
L'inconvénient de choisir le stockage BLOB plutôt que CLOB (pour JSON ou tout autre type de données) est qu'il
est parfois plus difficile de travailler avec du contenu BLOB à l'aide d'outils de ligne de commande tels que
SQL*Plus. Par exemple:
• Lorsque vous sélectionnez des données dans une colonne BLOB, si vous souhaitez les afficher sous forme de texte imprimable
alors vous devez utiliser la fonction SQL to_clob.
• Lorsque vous effectuez des opérations d'insertion ou de mise à jour sur une colonne BLOB, vous devez
explicitement convertir les chaînes de caractères au format BLOB à l'aide de la fonction SQL
22 rawtohex.
Assurezvous que les colonnes JSON contiennent des données JSON bien formées
Vous pouvez utiliser la condition SQL/JSON is json pour vérifier si certaines données JSON sont bien formées
ou non. Oracle recommande vivement d'appliquer une contrainte de vérification is json à toute colonne JSON,
sauf si vous vous attendez à ce que certaines lignes contiennent autre chose que des données JSON bien
formées.
La surcharge de l'analyse de JSON est telle que l'évaluation de la condition ne devrait pas avoir d'impact significatif
sur les performances d'insertion et de mise à jour, et l'omission de la contrainte signifie que vous ne pouvez pas
utiliser la simple syntaxe de notation par points pour interroger les données JSON.
Ce qui constitue des données JSON bien formées est une zone grise. En pratique, il est courant que les
données JSON aient des caractéristiques qui ne suivent pas strictement la définition standard. Vous pouvez
contrôler la syntaxe à laquelle vous souhaitez qu'une colonne donnée de données JSON se conforme : la
définition standard (syntaxe stricte) ou une syntaxe de type JavaScript que l'on trouve dans la pratique courante
(syntaxe laxiste). La syntaxe SQL/JSON par défaut pour Oracle Database est laxiste. Le type de syntaxe utilisé
est contrôlé par la condition est json. L'application d'une contrainte de vérification is json à une colonne JSON
permet ainsi d'utiliser la syntaxe JSON laxiste, par défaut.
2
La valeur de retour de la fonction SQL rawtohex est limitée à 32767 octets. La valeur est tronquée pour supprimer toutes les
données converties audelà de cette longueur.
Voir également:
• Jeux de caractères et codage de caractères pour les données JSON (page 61)
• Présentation de l'insertion, de la mise à jour et du chargement des données JSON (page 91)
• Oracle Database SQL Language Reference pour plus d'informations sur SQL
fonction rawtohex
Présentation du stockage et de la gestion des données JSON 33
4
Créer une table avec une colonne JSON
Vous pouvez créer une table contenant des colonnes JSON. Vous utilisez la condition SQL est json comme contrainte
de vérification pour vous assurer que les données insérées dans une colonne sont des données JSON (bien formées).
Oracle recommande de toujours utiliser une contrainte de vérification is_json lorsque vous créez une colonne destinée
aux données JSON.
L'exemple 41 (page 41) et l' exemple 42 (page 42) illustrent cela. Ils créent et remplissent un tableau qui
contient les données utilisées dans les exemples ailleurs dans cette documentation.
Par souci de concision, seules deux lignes de données (un document JSON) sont insérées dans l' exemple 42 (page
42).
Noter:
Les conditions SQL/JSON IS JSON et IS NOT JSON renvoient true ou false pour toute valeur SQL non
NULL. Mais ils renvoient tous les deux inconnu (ni vrai ni faux) pour SQL NULL. Lorsqu'ils sont utilisés
dans une contrainte de vérification, ils n'empêchent pas l'insertion d'une valeur SQL NULL dans la
colonne. (Mais lorsqu'il est utilisé dans une clause SQL WHERE, SQL NULL n'est jamais renvoyé.)
Il est vrai qu'une contrainte de vérification peut réduire les performances d'insertion des données. Si vous êtes sûr
que votre application insère uniquement des données JSON bien formées dans une colonne particulière, envisagez
de désactiver la contrainte de vérification, mais ne supprimez pas la contrainte.
Les sujets
Voir également:
• Chargement des données JSON externes (page 101) pour la création de la table complète
j_purchaseorder
• Oracle Database SQL Language Reference pour plus d'informations sur CREATE
TABLE
Exemple 41 Utilisation de IS JSON dans une contrainte de vérification pour s'assurer que les données JSON sont correctes
Formé
VARCHAR2 (23767)
CONTRAINTE assurer_json VÉRIFIER (po_document EST JSON));
Création d'une table avec une colonne JSON 41
Exemple 42 Insertion de données JSON dans une colonne VARCHAR2 JSON
VALEURS (
SYS_GUID(),
'{"PONuméro" : 1600,
"Référence" : "ABULL20140421",
"Demandeur" : "Alexis Taureau",
"Utilisateur" : "UN TAUREAU",
"Instructions d'expédition" : {"nom" : "Alexis Taureau",
"Adresse" : {"rue" : "200 Sporting Green", "ville"
"CA", "zipCode" : 99236, "country" : "ÉtatsUnis
d'Amérique"},
"Téléphone" : [{"type" : "Bureau", "numéro" : "9095557307"},
{"type" : "Mobile", "numéro" : "4155551234"}]},
"Instructions Particulières" : null,
"AllowPartialShipment" : vrai,
"Éléments de campagne" : [{"NuméroArticle" : 1,
"Partie" : {"Description" : "Un Noël magique",
"Prixunitaire" : 19.95, :
"CodeUPC" 13131092899},
"Quantité" : 9.0},
{"NuméroArticle" : 2,
"Partie" : {"Description" : "Arme fatale", "UnitPrice" : 19.95, :
85391628927}, "UPCCode"
"Quantité" : 5.0}]}');
VALEURS (
SYS_GUID(),
'{"PONuméro" : 672,
"Référence" : "SBELL20141017",
"Demandeur" : "Sarah Bell",
"Utilisateur" : "SBELLE",
"Instructions d'expédition" : {"nom" : "Sarah Bell",
"Adresse" : {"rue" : "200 Sporting Green", "ville"
"CA", "zipCode" : 99236, "country" : "ÉtatsUnis
d'Amérique"},
"Téléphone" : "9835556509"},
"Instructions spéciales" : "Courrier",
"Éléments de campagne" : [{"NuméroArticle" : 1,
"Partie" : {"Description" : "Passer la note",
"Prixunitaire" : 20,
"Code CUP" : 27616867759},
"Quantité" : 8.0},
"Partie" : {"Description" : "Nixon", "UnitPrice" :
19.95, "UPCCode" : 717951002396},
"Quantité" : 5},
"Partie" : {"Description" : "Eric Clapton : Best Of 19811999",
Déterminer si une colonne contient nécessairement des données JSON
"Prixunitaire" : 19.95, :
"CodeUPC" 75993851120},
"Quantité" : 5.0} ]}');
Déterminer si une colonne contient nécessairement des données JSON (page 43)
Comment savoir si une colonne donnée a une contrainte de vérification qui garantit que ses
données sont des données JSON bien formées ? Chaque fois que c'est le cas, la colonne
est répertoriée dans les vues de dictionnaire de données statiques suivantes :
DBA_JSON_COLUMNS, USER_JSON_COLUMNS et ALL_JSON_COLUMNS.
4.1 Déterminer si une colonne contient nécessairement des données JSON
Comment savoir si une colonne donnée a une contrainte de vérification qui garantit que ses données sont des
données JSON bien formées ? Chaque fois que c'est le cas, la colonne est répertoriée dans les vues de
dictionnaire de données statiques suivantes : DBA_JSON_COLUMNS, USER_JSON_COLUMNS et
ALL_JSON_COLUMNS.
Chaque vue répertorie les noms du propriétaire, de la table et de la colonne, ainsi que le type de données de la
colonne. Vous pouvez interroger ces données pour trouver des colonnes JSON.
Même si une contrainte de vérification qui garantit qu'une colonne contient des données JSON est désactivée, la
colonne reste répertoriée dans les vues. Si la contrainte de vérification est supprimée , la colonne est supprimée
des vues.
Noter:
Si une contrainte de vérification combine la condition est json avec une autre condition à l'aide de
la condition logique OR, la colonne n'est pas répertoriée dans les vues. Dans ce cas, il n'est pas
certain que les données de la colonne soient des données JSON. Par exemple, la contrainte jcol est
json OR length(jcol) < 1000 ne garantit pas que les données de la colonne jcol sont des données
JSON.
Création d'une table avec une colonne JSON 43
Déterminer si une colonne contient nécessairement des données JSON
5
Conditions SQL/JSON EST JSON et N'EST PAS
JSON
Les conditions SQL/JSON est json et n'est pas json sont complémentaires. Ils testent si leur argument est
syntaxiquement correct, c'est àdire des données JSON bien formées . Vous pouvez les utiliser dans une expression
CASE ou dans la clause WHERE d'une instruction SELECT.
Si l'argument est syntaxiquement correct, is json renvoie true et is not json renvoie false. Si l'argument ne peut pas être
évalué pour une raison quelconque (par exemple, si une erreur se produit lors de l'analyse), les données sont
considérées comme mal formées : is json renvoie false ; n'est pas json renvoie vrai. Des données bien formées
signifient des données syntaxiquement correctes. Les données JSON peuvent être bien formées dans deux sens,
appelés syntaxe stricte et laxiste.
Les sujets
Voir également:
• Oracle Database SQL Language Reference pour plus d'informations sur is json et is not json.
Champs uniques et champs en double dans les objets JSON (page 51)
Par défaut, les noms de champ n'ont pas besoin d'être uniques pour un objet JSON donné. Mais
vous pouvez spécifier que des données JSON particulières doivent être considérées comme bien
formées uniquement si aucun de ses objets n'a de noms de champ en double.
À propos de la syntaxe JSON stricte et laxiste (page 52)
La syntaxe par défaut d'Oracle pour JSON est laxiste. En particulier : il reflète la syntaxe
JavaScript pour les champs objet ; les valeurs booléennes et nulles ne sont pas sensibles à la
casse ; et il est plus permissif en ce qui concerne les chiffres, les espaces et l'échappement des
caractères Unicode.
Spécification de la syntaxe JSON stricte ou laxiste (page 54)
La syntaxe JSON par défaut pour Oracle Database est laxiste. Une syntaxe stricte ou laxiste n'a
d'importance que pour les conditions SQL/JSON est json et n'est pas json. Toutes les autres fonctions
et conditions SQL/JSON utilisent une syntaxe laxiste pour interpréter l'entrée et une syntaxe stricte
lors du retour de la sortie.
5.1 Champs uniques et champs en double dans les objets JSON
Par défaut, les noms de champ n'ont pas besoin d'être uniques pour un objet JSON donné. Mais vous pouvez
spécifier que des données JSON particulières doivent être considérées comme bien formées uniquement si aucun
de ses objets n'a de noms de champ en double.
Conditions SQL/JSON EST JSON et N'EST PAS JSON 51
À propos de la syntaxe JSON stricte et laxiste
La norme JSON ne précise pas si les noms de champ doivent être uniques pour un objet JSON donné. Cela
signifie qu'a priori, un objet JSON bien formé peut avoir plusieurs membres qui ont le même nom de champ. Il
s'agit du comportement par défaut pour la gestion des données JSON dans Oracle Database, car la vérification
des noms en double prend plus de temps.
Vous pouvez spécifier que des données JSON particulières doivent être considérées comme bien formées
uniquement si tous les objets qu'elles contiennent ont des noms de champ uniques, c'estàdire qu'aucun objet
n'a de noms de champ en double. Pour ce faire, utilisez les motsclés WITH UNIQUE KEYS avec SQL/JSON
11
la condition est json.
Si vous ne spécifiez pas UNIQUE KEYS ou si vous utilisez les motsclés SANS UNIQUE KEYS, les objets
peuvent avoir des noms de champ en double et être toujours considérés comme bien formés.
L'évaluation qu'Oracle Database utilise utilise toujours un seul des membres d'objet qui ont un nom de
champ donné ; tous les autres membres avec le même nom de champ sont ignorés. Il n'est pas précisé lequel
de ces multiples membres est utilisé.
Que les noms de champ en double soient autorisés dans des données JSON bien formées est orthogonal au
fait qu'Oracle utilise une syntaxe stricte ou laxiste pour déterminer la bonne formation.
5.2 À propos de la syntaxe JSON stricte et laxiste La syntaxe par
défaut d'Oracle pour JSON est laxiste. En particulier : il reflète la syntaxe JavaScript pour les champs objet ; les
valeurs booléennes et nulles ne sont pas sensibles à la casse ; et il est plus permissif en ce qui concerne les
chiffres, les espaces et l'échappement des caractères Unicode.
La norme ECMA404, le format d'échange de données JSON, et ECMA262, la spécification du
langage ECMAScript, définissent la syntaxe JSON.
Selon ces spécifications, chaque champ JSON et chaque valeur de chaîne doivent être placés entre
guillemets doubles ("). Oracle prend en charge cette syntaxe JSON stricte, mais ce n'est pas la syntaxe par
défaut.
Dans la notation JavaScript, un champ utilisé dans un littéral d'objet peut être, mais pas nécessairement, entouré
de guillemets doubles. Il peut également être entouré de guillemets simples (').
Oracle prend également en charge cette syntaxe JSON laxiste, et c'est la syntaxe par défaut .
De plus, dans la pratique, certaines implémentations JavaScript (mais pas la norme JavaScript) autorisent
une ou plusieurs des actions suivantes :
• Variations de casse pour les mots clés true, false et null (par exemple, TRUE, True,
VRAI, FAUX, NULL).
• Une virgule supplémentaire (,) après le dernier élément d'un tableau ou le dernier membre d'un objet (par
exemple, [a, b, c,], {a:b, c:d,}).
• Chiffres avec un ou plusieurs zéros non significatifs (par exemple, 0042.3).
• Chiffres fractionnaires sans 0 avant la virgule décimale (par exemple, 0,14 à la place
de 0,14).
• Chiffres sans partie décimale après la virgule (par exemple, 342. ou
1.e27).
• Un signe plus (+) précédant un chiffre, ce qui signifie que le nombre n'est pas négatif (par exemple, +1,3).
Cette syntaxe est également autorisée dans le cadre de la syntaxe JSON par défaut (laxiste) d'Oracle.
(Voir la norme JSON pour la syntaxe numérique stricte.)
1 Un champ d'objet est parfois appelé une « clé » d'objet.
À propos de la syntaxe JSON stricte et laxiste
En plus du caractère d'espace ASCII (U+0020), la norme JSON définit les caractères suivants comme des espaces
non significatifs (ignorés) lorsqu'ils sont utilisés en dehors d'un champ entre guillemets ou d'une valeur de chaîne :
• Tabulation, tabulation horizontale (HT, ^I, décimal 9, U+0009, \t)
• Saut de ligne, retour à la ligne (LF, ^J, décimal 10, U+000A, \n)
• Retour chariot (CR, ^M, décimal 13, U+000D, \r)
Cependant, la syntaxe JSON laxiste traite tous les caractères de contrôle ASCII (Control+0 à Control+31), ainsi que
le caractère d'espace ASCII (décimal 32, U+0020), comme des caractères d'espacement (insignifiants). Les suivants
font partie des caractères de contrôle :
• Nul (NUL, ^@, décimal 0, U+0000, \0)
• Cloche (NEL, ^G, décimal 7, U+0007, \a)
• Tabulation verticale (VT, ^K, décimal 11, U+000B)
• Échappement (ESC, ^[, décimal 27, U+001B, \e)
• Supprimer (DEL, ^?, décimal 127, U+007F)
Un caractère d'espacement ASCII (U+0020) est le seul caractère d'espacement autorisé, sans échappement,
dans un champ entre guillemets ou une valeur de chaîne. Cela est vrai pour les syntaxes JSON laxistes et strictes.
Pour les syntaxes JSON strictes et laxistes, les champs d'objet et les valeurs de chaîne entre guillemets peuvent
contenir n'importe quel caractère Unicode, mais certains d'entre eux doivent être échappés, comme suit :
• Les caractères de contrôle ASCII ne sont pas autorisés, à l'exception de ceux représentés par les séquences
d'échappement suivantes : \b (retour arrière), \f (saut de page), \n (nouvelle ligne, saut de ligne), \r (retour
chariot) et \t (onglet, onglet horizontal).
• Les guillemets doubles ("), les barres obliques ( /) et les barres obliques inverses (\) doivent également être
échappés (précédés d'une barre oblique inverse) : \", \/ et \\, respectivement.
Dans la syntaxe JSON laxiste, un champ d'objet qui n'est pas entre guillemets peut contenir n'importe quel
caractère Unicode à l'exception des espaces et des caractères structurels JSON crochets gauche et droit ([, ]) et
accolades ({, }), deuxpoints (:) et virgule (,), mais les séquences d'échappement ne sont pas autorisées.
Tout caractère Unicode peut également être inclus dans un nom ou une chaîne en utilisant la syntaxe d'échappement
ASCII \u suivie des quatre chiffres hexadécimaux ASCII qui représentent le point de code Unicode.
Notez que les autres caractères Unicode qui ne sont pas imprimables ou qui peuvent apparaître comme des
espaces, comme un espace insécable (U+00A0), ne sont pas considérés comme des espaces pour la syntaxe
JSON stricte ou laxiste.
Le Tableau 51 (page 53) montre quelques exemples de syntaxe JSON.
Tableau 51 Exemples de syntaxe de champ d'objet JSON
Exemple Bien formé ?
"part number": 1234 Laxiste et stricte : oui. Les espaces sont autorisés.
numéro de pièce: 1234 Laxiste (et strict) : non. Les caractères d'espacement, y compris les caractères d'espacement, ne sont pas
autorisés dans les noms sans guillemets.
Spécification d'une syntaxe JSON stricte ou laxiste
Tableau 51 (suite) Exemples de syntaxe de champ d'objet JSON
Exemple Bien formé ?
"part\tnumber": 1234 Laxiste et strict : oui. La séquence d'échappement pour le caractère de tabulation est autorisée.
"partie Numéro": Laxiste et strict : non. Le caractère de tabulation sans échappement n'est pas autorisé. L'espace est

1234 le seul caractère d'espacement non échappé autorisé.
"\"pièce\"numéro": 1234 Laxiste et strict : oui. Les guillemets doubles échappés sont autorisés, si le nom est cité.
\"part\"number : 1234 Laxiste et strict : non. Le nom doit être cité.
'\"Numéro d'article': Laxiste : oui, stricte : non. Les noms entre guillemets simples (champs d'objet et chaînes) ne sont autorisés
1234 que pour la syntaxe laxiste. Les guillemets doubles échappés sont autorisés dans un nom entre guillemets.
"pärt : number":1234 Laxiste et strict : oui. Tout caractère Unicode est autorisé dans un nom entre guillemets. Cette
inclut des caractères d'espacement et des caractères, tels que deuxpoints (:), qui sont structurels dans
JSON.
pièce:numéro:1234 Laxiste (et strict) : non. Les caractères structurels ne sont pas autorisés dans les noms sans guillemets.
Voir également:
• http://tools.ietf.org/html/rfc4627 et http://www.ecma international.org/publications/standards/
Ecma404.htm pour la syntaxe du format d'échange de données JSON
• http://www.ecmainternational.org et http://
www.json.org pour plus d'informations sur JSON et JavaScript
• Syntaxe JSON et données qu'elle représente (page 22)
5.3 Spécification d'une syntaxe JSON stricte ou laxiste
La syntaxe JSON par défaut pour Oracle Database est laxiste. Une syntaxe stricte ou laxiste n'a
d'importance que pour les conditions SQL/JSON est json et n'est pas json. Toutes les autres fonctions et
conditions SQL/JSON utilisent une syntaxe laxiste pour interpréter l'entrée et une syntaxe stricte lors du
retour de la sortie.
Si vous devez vous assurer que les données d'entrée JSON particulières ont une syntaxe strictement
correcte, vérifiezles d'abord en utilisant is json ou is not json.
Vous spécifiez que les données doivent être vérifiées comme étant strictement bien formées selon la
norme JSON en ajoutant (STRICT) (entre parenthèses incluses) à une expression is json ou an is not
json.
L'exemple 51 (page 55) illustre cela. Il est identique à l' exemple 41 (page 41) sauf qu'il utilise
(STRICT) pour s'assurer que toutes les données insérées dans la colonne sont bien formées selon la
norme JSON.
Voir également:
TABLE
Exemple 51 Utilisation de IS JSON dans une contrainte de vérification pour s'assurer que les données JSON sont strictement
Bien formé (standard)
VARCHAR2 (32767)
CONTRAINTE assurer_json VÉRIFIER (po_document EST JSON (STRICT)) );
6
Jeux de caractères et codage de caractères pour
Données JSON
Les données textuelles JSON utilisent toujours le jeu de caractères Unicode. À cet égard, les données JSON sont plus
simples à utiliser que les données XML. Il s'agit d'une partie importante du format d'échange de données JSON (RFC
4627). Pour les données JSON traitées par Oracle Database, toutes les conversions de jeu de caractères nécessaires sont
effectuées automatiquement.
Oracle Database utilise UTF8 en interne lorsqu'il traite des données JSON (analyse, requête). Si les données
qui sont entrées dans un tel traitement, ou les données qui en sont sorties, doivent être dans un jeu de caractères différent
de UTF8, alors la conversion du jeu de caractères est effectuée en conséquence.
La conversion du jeu de caractères peut affecter les performances. Et dans certains cas, cela peut entraîner des
pertes : la conversion des données d'entrée en UTF8 est une opération sans perte, mais la conversion en sortie peut
entraîner une perte d'informations dans le cas de caractères qui ne peuvent pas être représentés dans le jeu de caractères
de sortie.
Si vos données textuelles JSON sont stockées dans la base de données au format Unicode, aucune conversion de jeu
de caractères n'est nécessaire. C'est le cas si le jeu de caractères de la base de données est AL32UTF8 (Unicode
UTF8). Oracle le recommande si possible.
Les données JSON qui ne sont pas stockées textuellement, c'estàdire sous forme de caractères, ne
subissent jamais de conversion de jeu de caractères — il n'y a aucun caractère à convertir. Cela signifie que les données
JSON stockées à l'aide du type de données BLOB ne subissent aucune conversion de jeu de caractères.
Voir également:
• http://www.unicode.org pour plus d'informations sur Unicode
• http://tools.ietf.org/html/rfc4627 et http://www.ecma international.org/publications/standards/Ecma404.htm
pour le format d'échange de données JSON
• Oracle Database Migration Assistant for Unicode Guide pour plus d'informations sur l'utilisation de différents
jeux de caractères avec la base de données
• Oracle Database Globalization Support Guide pour plus d'informations sur la conversion des
jeux de caractères dans la base de données
Jeux de caractères et codage de caractères pour les données JSON 61
7
Partitionnement des données JSON
Vous pouvez partitionner une table en utilisant une colonne virtuelle JSON comme clé de
partitionnement. La colonne virtuelle est extraite d'une colonne JSON à l'aide de la fonction SQL/
JSON json_value.
Partitionner sur une colonne nonJSON lorsque cela est possible
Vous pouvez partitionner une table à l'aide d'une colonne virtuelle JSON, mais il est généralement
préférable d'utiliser une colonne non JSON. Une clé de partitionnement spécifie dans quelle partition une
nouvelle ligne est insérée. Une clé de partitionnement définie en tant que colonne virtuelle JSON utilise la
fonction SQL/JSON json_value, et l'expression json_value définissant la partition est exécutée chaque
fois qu'une ligne est insérée. Cela peut être coûteux, en particulier pour l'insertion de documents JSON
volumineux.
Règles de partitionnement d'une table à l'aide d'une colonne virtuelle JSON
• La colonne virtuelle qui sert de clé de partitionnement doit être définie à l'aide de la fonction SQL/
JSON json_value.
• Le type de données de la colonne virtuelle est défini par la clause RETURNING utilisée pour
l'expression json_value.
• Le chemin json_value utilisé pour extraire les données de la colonne virtuelle ne doit pas
contenir aucun prédicat. (Le chemin doit être streamable.)
• La colonne JSON référencée par l'expression qui définit la colonne virtuelle peut avoir une contrainte
is json check, mais elle n'a pas besoin d'avoir une telle contrainte.
Voir également:
Oracle Database SQL Language Reference pour plus d'informations sur CREATE TABLE
Exemple 71 Création d'une table partitionnée à l'aide d'une colonne virtuelle JSON
Cet exemple crée la table j_purchaseorder_partitioned, qui est partitionnée à l'aide de la colonne virtuelle
po_num_vc. Cette colonne virtuelle fait référence à la colonne JSON po_document (qui utilise le
stockage CLOB). L'expression json_value qui définit la colonne virtuelle extrait le champ JSON
PONumber de po_document sous forme de nombre.
La colonne po_document n'a pas de contrainte de vérification is json.
CREATE TABLE j_purchaseorder_partitioned (id
VARCHAR2 (32) NOT NULL PRIMARY KEY,
date_loaded TIMESTAMP (6) WITH TIME ZONE,
po_document CLOB, po_num_vc NUMBER
GENERATED ALWAYS AS (json_value
(po_document, '$.PONumber' RETURNING NUMBER)))
LOB (po_document) STOCK AS (CACHE)
Partitionnement des données JSON 71
PARTITION PAR PLAGE (po_num_vc)
(VALEURS DE PARTITION p1 INFÉRIEURES À (1000),
PARTITION p2 VALEURS INFÉRIEURES À (2000) );
8
Réplication des données JSON
Vous pouvez utiliser Oracle GoldenGate pour répliquer des tables qui ont des colonnes contenant des données
JSON.
Sachez qu'Oracle GoldenGate exige que les tables à répliquer aient une colonne de clé primaire non
virtuelle ; la colonne de clé primaire ne peut pas être virtuelle.
Tous les index sur les données JSON seront également répliqués. Cependant, vous devez exécuter,
sur la base de données répliquée, toutes les opérations Oracle Text que vous utilisez pour gérer un
index de recherche JSON. Voici des exemples de telles procédures :
• CTX_DDL.sync_index
• CTX_DDL.optimize_index
Voir également:
• Oracle GoldenGate pour plus d'informations sur Oracle GoldenGate
• Oracle Text Reference pour plus d'informations sur CTX_DDL.sync_index
• Oracle Text Reference pour plus d'informations sur CTX_DDL.optimize_index
Réplication des données JSON 81
Partie III
Insérer, mettre à jour et charger des données JSON
Les méthodes habituelles d'insertion, de mise à jour et de chargement de données dans Oracle Database fonctionnent avec
des données JSON. Vous pouvez également créer une table externe à partir du contenu d'un fichier de vidage JSON.
Chapitres
Présentation de l'insertion, de la mise à jour et du chargement des données JSON (page 91)
Vous pouvez utiliser des API de base de données standard pour insérer ou mettre à jour des données
JSON dans Oracle Database. Vous pouvez travailler directement avec les données JSON contenues
dans les fichiers du système de fichiers en créant une table externe qui les expose à la base de
données. Pour de meilleures performances, vous pouvez charger les données de la table externe dans
une table ordinaire.
Chargement de données JSON externes (page 101)
Vous pouvez créer une table de base de données de données JSON à partir du contenu d'un fichier de
vidage JSON.
9
Présentation de l'insertion, de la mise à jour et de
Chargement des données JSON
Vous pouvez utiliser des API de base de données standard pour insérer ou mettre à jour des données JSON dans Oracle Database.
Vous pouvez travailler directement avec les données JSON contenues dans les fichiers du système de fichiers en créant une
table externe qui les expose à la base de données. Pour de meilleures performances, vous pouvez charger les données de la table
externe dans une table ordinaire.
Utiliser des API de base de données standard pour insérer ou mettre à jour des données JSON
Étant donné que les données JSON sont stockées à l'aide de types de données SQL standard, toutes les API de base
de données standard utilisées pour insérer ou mettre à jour les colonnes VARCHAR2 et les grands objets (LOB) peuvent être
utilisées pour les colonnes contenant des documents JSON. Pour ces API, un document JSON stocké n'est rien de plus qu'une
chaîne de caractères.
Vous spécifiez qu'une colonne JSON doit contenir uniquement des données JSON bien formées en utilisant la condition SQL est
json comme contrainte de vérification. La base de données gère cette contrainte de vérification de la même manière que toute
autre contrainte de vérification — elle applique des règles sur le contenu de la colonne. Travailler avec une colonne de type
VARCHAR2, BLOB ou CLOB qui contient des documents JSON n'est donc pas différent de travailler avec n'importe quelle autre
colonne de ce type.
Les opérations de mise à jour sur un document dans une colonne JSON nécessitent le remplacement du document entier.
Vous pouvez apporter des modifications précises à un document JSON, mais lorsque vous devez enregistrer les modifications
sur le disque, l'intégralité du document mis à jour est écrite.
Du point de vue du développement d'applications, cela a du sens : si un document JSON est utilisé pour enregistrer l'état de
l'application, l'application le récupère généralement, le modifie, puis le réécrit sur le disque pour refléter l'état mis à jour. En règle
générale, vous ne souhaitez pas que votre application gère la complexité du suivi des mises à jour par morceaux des documents,
puis de leur réécriture dans la base de données.
L'insertion d'un document JSON dans une colonne JSON est simple si la colonne est de type de données VARCHAR2 ou CLOB
— voir Exemple 42 (page 42). Il en va de même pour la mise à jour d'une telle colonne.
Mais si vous utilisez un outil de ligne de commande tel que SQL*Plus pour insérer des données dans une colonne JSON
de type BLOB, ou pour mettre à jour ces données, vous devez convertir correctement les données JSON au format binaire.
L'exemple 91 (page 91) en est un exemple partiel. Il suppose que la table my_table a une colonne JSON, json_doc, qui
utilise le stockage BLOB.
Exemple 91 Insertion de données JSON dans une colonne BLOB
Les données textuelles JSON insérées (affichées sous forme de données littérales partiellement élidées, {...}) contiennent des
caractères dans le jeu de caractères de la base de données, qui est WE8MSWIN1252. Les données sont transmises à la fonction
PL/SQL UTL_RAW.cast_to_raw, qui convertit le type de données en RAW. Ce résultat est ensuite transmis à la fonction
UTL_RAW.convert, qui le convertit en jeu de caractères AL32UTF8.
Présentation de l'insertion, de la mise à jour et du chargement des données JSON 91
INSÉRER DANS ma_table (json_doc)
VALEURS (UTL_RAW.convert(UTL_RAW.cast_to_raw('{....}'), 'AL32UTF8',
'WE8MSWIN1252'));
Utilisation d'une table externe pour travailler avec des données JSON dans des fichiers de
système de fichiers Les tables externes facilitent l'accès aux documents JSON qui sont stockés sous forme de
fichiers séparés dans un système de fichiers. Chaque fichier peut être exposé à Oracle Database sous la forme
d'une ligne dans une table externe. Une table externe peut également donner accès au contenu d'un fichier de
vidage produit par une base de données NoSQL. Vous pouvez utiliser une table externe de documents JSON pour,
en fait, interroger directement les données dans les fichiers du système de fichiers. Cela peut être utile si vous
n'avez besoin de traiter que les données de tous les fichiers en une seule opération.
Mais si vous avez plutôt besoin de faire plusieurs requêtes sur les documents, et surtout si différentes requêtes
sélectionnent des données de différentes lignes de la table externe (différents documents), alors pour de
meilleures performances, envisagez de copier les données de la table externe dans une table de base de données
ordinaire, en utilisant une instruction INSERT comme SELECT — voir l' exemple 104 (page 102). Une fois que
les données JSON ont été chargées dans une colonne JSON d'une table ordinaire, vous pouvez indexer le
contenu, puis vous pouvez interroger efficacement les données de manière répétitive et sélective.
Noter:
Outre les méthodes habituelles d'insertion, de mise à jour et de chargement des données, vous
pouvez utiliser les API SODA ( Simple Oracle Document Access ). SODA est conçu pour le développement
d'applications sans schéma sans connaissance des fonctionnalités des bases de données relationnelles
ou des langages tels que SQL et PL/SQL. Il vous permet de créer et de stocker des collections de
documents de toute nature (pas seulement JSON), de les récupérer et de les interroger, sans avoir besoin
de savoir comment les documents sont stockés dans la base de données.
SODA fournit également des fonctionnalités de requête spécifiques aux documents JSON.
Il existe deux implémentations de SODA :
• SODA pour Java — Classes Java qui représentent la base de données, la collection et
document.
• SODA pour REST — Opérations SODA en tant que requêtes REST (Representational State
Transfer), utilisant n'importe quel langage capable d'effectuer des appels HTTP.
Pour plus d'informations sur SODA, voir Oracle en tant que magasin de documents.
Voir également:
• Chargement de données JSON externes (page 101)
• Présentation du stockage et de la gestion des données JSON (page 31)
• Oracle Database SQL Language Reference pour plus d'informations sur SQL
fonction rawtohex
dix
Chargement de données JSON externes
Vous pouvez créer une table de base de données de données JSON à partir du contenu d'un fichier de vidage JSON.
Cette rubrique montre comment vous pouvez charger une table complète de documents JSON à partir des données
d'un fichier de vidage JSON, $ORACLE_HOME/demo/schema/order_entry/ PurchaseOrders.dmp. Le format de ce
fichier est compatible avec le format d'exportation produit par les bases de données NoSQL courantes, y compris Oracle
NoSQL Database. Chaque ligne du fichier contient un seul document JSON représenté sous la forme d'un objet JSON.
Vous pouvez interroger directement une telle table externe ou, pour de meilleures performances si vous avez plusieurs
requêtes ciblant différentes lignes, vous pouvez charger une table de base de données ordinaire à partir des données
de la table externe.
L'exemple 101 (page 102) crée un répertoire de base de données qui correspond au répertoire du système de
fichiers $ORACLE_HOME/demo/schema/order_entry. L'exemple 102 (page 102) utilise ensuite ce répertoire de
base de données pour créer et remplir une table externe, json_dump_file_contents, avec les données du fichier de
vidage, PurchaseOrders.dmp. Il remplit complètement la table externe en bloc, en copiant tous les documents JSON
dans la colonne json_document.
L'exemple 104 (page 102) utilise ensuite une instruction INSERT comme SELECT pour copier les documents
JSON de la table externe dans la colonne JSON po_document de la table de base de données ordinaire j_purchaseorder.
Comme nous avons choisi le stockage BLOB pour la colonne JSON json_document de la table externe, la colonne
po_document de la table ordinaire doit également être de type BLOB.
L' exemple 103 (page 102) crée la table j_purchaseorder avec la colonne BLOB po_document.
Noter:
Vous avez besoin du privilège système CREATE ANY DIRECTORY pour créer un répertoire de base de
données.
Voir également:
• Oracle Database Concepts pour des informations générales sur les tables externes
• Oracle Database Utilities et Oracle Database Administrator's Guide pour des informations
détaillées sur les tables externes
• Guide d'entreposage de données de la base de données Oracle
TABLE
Chargement de données JSON externes 101
Exemple 101 Création d'un objet de répertoire de base de données pour les bons de commande
Vous devez remplacer ici $ORACLE_HOME par sa valeur.
CRÉER OU REMPLACER LE RÉPERTOIRE order_entry_dir
AS '$ORACLE_HOME/demo/schema/order_entry' ;
Exemple 102 Création d'une table externe et remplissage à partir d'un fichier de vidage JSON
CREATE TABLE json_dump_file_contents (json_document BLOB)
ORGANISATION EXTERNE (TYPE ORACLE_LOADER RÉPERTOIRE PAR DÉFAUT order_entry_dir
PARAMÈTRES D'ACCÈS
(ENREGISTREMENTS DÉLIMITÉS PAR 0x'0A'
DISABLE_DIRECTORY_LINK_CHECK
FIELDS (json_document CHAR(5000)))
EMPLACEMENT (order_entry_dir:'PurchaseOrders.dmp'))
PARALLÈLE
REJETER LA LIMITE ILLIMITÉE ;
Exemple 103 Création d'une table avec une colonne BLOB JSON
La table j_purchaseorder a un identifiant de clé primaire et une colonne JSON po_document, qui
est stockée à l'aide du type de données BLOB. L' option de cache LOB est activée pour cette
colonne.
SUPPRIMER TABLE j_purchaseorder ;
date_loaded TIMESTAMP (6) AVEC FUSEAU HORAIRE,
po_document BLOB
CONTRAINTE assurer_json VÉRIFIER (po_document EST JSON))
LOB (po_document) STOCK AS (CACHE);
Exemple 104 Copie de données JSON d'une table externe vers une table de base de données
INSERT INTO j_purchaseorder (id, date_loaded, po_document)
SELECT SYS_GUID(), SYSTIMESTAMP, json_document FROM json_dump_file_contents
OÙ json_document EST JSON ;
Partie IV
Interroger les données JSON
Vous pouvez interroger les données JSON à l'aide d'une simple notation par points ou, pour plus de fonctionnalités, à l'aide de
fonctions et de conditions SQL/JSON. Vous pouvez créer et interroger un guide de données qui résume la structure et les informations
de type d'un ensemble de documents JSON.
Étant donné que les données JSON sont stockées dans la base de données à l'aide de types de données standard (VARCHAR2,
BLOB et CLOB), les requêtes SQL fonctionnent avec les données JSON de la même manière qu'avec toute autre donnée de
base de données.
Pour interroger des champs JSON particuliers ou pour mapper des champs JSON particuliers à des colonnes SQL, vous pouvez
utiliser le langage de chemin SQL/JSON. Dans sa forme la plus simple, une expression de chemin consiste en un ou plusieurs noms
de champs séparés par des points (.). Des expressions de chemin plus complexes peuvent contenir des filtres et des index de tableau.
Oracle propose deux manières d'interroger le contenu JSON :
• Une syntaxe de notation par points, qui est essentiellement un alias de table, suivi d'un nom de colonne JSON, suivi d'un ou
plusieurs noms de champ — tous séparés par des points (.). Une étape de tableau peut suivre chacun des noms de champ.
Cette syntaxe est conçue pour être simple à utiliser et pour renvoyer des valeurs JSON dans la mesure du possible.
• Fonctions et conditions SQL/JSON, qui prennent entièrement en charge le langage de chemin et offrent plus de puissance et
de flexibilité que celles disponibles avec la syntaxe de notation par points. Vous pouvez les utiliser pour créer, interroger et
exploiter des données JSON stockées dans Oracle Database.
– Condition json_exists teste l'existence d'une valeur particulière dans certaines données JSON.
– Les conditions sont json et non json test si certaines données sont des données JSON bien formées. La première
est surtout utilisée comme contrainte de vérification.
– La fonction json_value sélectionne une valeur scalaire à partir de certaines données JSON, en tant que SQL
évaluer.
– La fonction json_query sélectionne une ou plusieurs valeurs à partir de certaines données JSON, sous la forme d'une chaîne
SQL représentant les valeurs JSON. Il est notamment utilisé pour récupérer des fragments d'un document JSON,
typiquement un objet ou un tableau JSON.
– La fonction json_table projette certaines données JSON sous forme de table virtuelle, que vous pouvez également considérer
comme une vue en ligne.
Étant donné que le langage de chemin fait partie du langage de requête, aucun schéma fixe n'est imposé aux données. Cette
conception prend en charge le développement sans schéma. Un "schéma", en effet, est défini à la volée au moment de la requête,
en spécifiant un chemin donné. Cela contraste avec l'approche plus habituelle avec SQL consistant à définir un schéma (un
ensemble de lignes et de colonnes de table) pour les données au moment du stockage.
Vous pouvez générer et interroger un guide de données JSON, pour vous aider à développer des expressions pour naviguer
dans votre contenu JSON. Un guide de données peut vous donner une compréhension approfondie de la
la structure et les informations de type de vos documents JSON. Les informations du guide de données peuvent être
mises à jour automatiquement, pour garder une trace des nouveaux documents que vous ajoutez.
Chapitres
Voir également:
Oracle Database SQL Language Reference pour des informations complètes sur la syntaxe et la
sémantique des fonctions SQL/JSON
Accès simple par notation par points aux données JSON (page 111)
La notation par points est conçue pour une utilisation simple et générale et des cas d'utilisation courants.
Les requêtes de données JSON qui utilisent la syntaxe de notation par points renvoient des valeurs JSON
dans la mesure du possible.
Expressions de chemin SQL/JSON (page 121)
Oracle Database fournit un accès SQL aux données JSON à l'aide d'expressions de chemin
SQL/JSON.
Clauses utilisées dans les fonctions et conditions de requête SQL/JSON (page 131)
Les clauses RETURNING, wrapper, error et emptyfield sont décrites.
Chacun est utilisé dans une ou plusieurs des fonctions et conditions SQL/JSON json_value,
json_query, json_table, is json, is not json et json_exists.
Condition SQL/JSON JSON_EXISTS (page 141)
La condition SQL/JSON json_exists vous permet d'utiliser une expression de chemin SQL/
JSON comme filtre de ligne, pour sélectionner des lignes en fonction du contenu des documents
JSON. Vous pouvez utiliser la condition json_exists dans une expression CASE ou la clause
WHERE d'une instruction SELECT.
Fonction SQL/JSON JSON_VALUE (page 151)
La fonction SQL/JSON json_value sélectionne une valeur scalaire à partir des données JSON et
la renvoie sous forme de valeur SQL.
Fonction SQL/JSON JSON_QUERY (page 161)
La fonction SQL/JSON json_query sélectionne une ou plusieurs valeurs à partir des données JSON
et renvoie une chaîne (VARCHAR2) qui représente les valeurs JSON.
(Contrairement à la fonction json_value, le type de données de retour ne peut pas être NUMBER).
Vous pouvez ainsi utiliser json_query pour récupérer des fragments d'un document
JSON.
Fonction SQL/JSON JSON_TABLE (page 171)
La fonction SQL/JSON json_table projette des données JSON spécifiques dans les
colonnes VARCHAR2, NUMBER, DATE, TIMESTAMP, TIMESTAMP WITH TIME ZONE et
SDO_GEOMETRY. Vous l'utilisez pour décomposer le résultat de l'évaluation de l'expression
JSON dans les lignes et les colonnes d'une nouvelle table virtuelle, que vous pouvez également
considérer comme une vue en ligne.
Guide des données JSON (page 181)
Un guide de données JSON vous permet de découvrir des informations sur la structure et le
contenu des documents JSON stockés dans Oracle Database.
11
Accès simple par notation par points aux données JSON
La notation par points est conçue pour une utilisation simple et générale et des cas d'utilisation courants. Les requêtes de données
JSON qui utilisent la syntaxe de notation par points renvoient des valeurs JSON dans la mesure du possible.
La valeur de retour d'une requête en notation par points est toujours une chaîne (type de données
VARCHAR2) représentant des données JSON. Le contenu de la chaîne dépend des données JSON
ciblées, comme suit :
•
Si une seule valeur JSON est ciblée, cette valeur est le contenu de la chaîne, qu'il s'agisse d'un
scalaire, d'un objet ou d'un tableau JSON.
•
Si plusieurs valeurs JSON sont ciblées, le contenu de la chaîne est un tableau JSON dont les éléments
sont ces valeurs.
Ce comportement contraste avec celui des fonctions SQL/JSON json_value et json_query,
que vous pouvez utiliser pour des requêtes plus complexes. Ils peuvent renvoyer NULL ou générer une
erreur si l'expression de chemin que vous leur fournissez ne correspond pas aux données JSON
interrogées. Ils acceptent des clauses facultatives pour spécifier le type de données de la valeur de retour
(clause RETURNING), s'il faut ou non encapsuler plusieurs valeurs dans un tableau (clause wrapper),
comment gérer les erreurs en général (clause ON ERROR) et comment gérer le JSON manquant. champs
(clause ON EMPTY).
Dans le premier cas cidessus, le comportement de la notation par points est similaire à celui
de la fonction json_value pour une valeur scalaire , et il est similaire à celui de json_query pour un objet ou
une valeur de tableau . Dans le second cas, le comportement est similaire à celui de json_query avec un
wrapper de tableau.
La syntaxe de notation par points est un alias de table (obligatoire) suivi d'un point, c'estàdire d'un point
(.), du nom d'une colonne JSON et d'une ou plusieurs paires de la forme . json_field ou . json_field suivi de
array_step, où json_field est un nom de champ JSON et array_step est une expression d'étape de tableau,
comme décrit dans Syntaxe d'expression de chemin SQL/JSON de base (page 122).
Chaque json_field doit être un identifiant SQL valide11 et la colonne doit avoir une contrainte is json
check, qui garantit qu'elle contient des données JSON bien formées. Si l'une de ces règles n'est pas
respectée, une erreur est générée au moment de la compilation de la requête. (La contrainte de vérification
doit être présente pour éviter de générer une erreur ; cependant, elle n'a pas besoin d'être active. Si vous
désactivez la contrainte, cette erreur n'est pas générée.)
Pour la notation par points pour les requêtes JSON, contrairement au cas généralement pour SQL,
les identifiants sans guillemets (après le nom de la colonne) sont traités de manière sensible à la
casse, c'estàdire comme s'ils étaient entre guillemets. C'est pratique : vous pouvez utiliser les noms
de champs JSON comme identifiants sans les citer. Par exemple, vous pouvez écrire jcolumn.friends
au lieu de jcolumn."friends". Cela signifie également que si un objet JSON est nommé en majuscules,
comme FRIENDS, vous devez alors écrire jcolumn.FRIENDS, et non jcolumn.friends.
1 En particulier, cela signifie que vous ne pouvez pas utiliser un nom de champ vide ("") avec une syntaxe de notation par points.
Accès simple par notation par points aux données JSON 111
Voici quelques exemples de syntaxe de notation par points. Tous font référence à la colonne JSON
po_document d'une table qui a l'alias po.
• po.po_document.PONumber – La valeur du champ PONumber.
• po.po_document.LineItems[1] – Le deuxième élément du tableau LineItems (les positions du tableau sont
basées sur zéro).
• po.po_document.LineItems[*] – Tous les éléments du tableau LineItems (*
est un joker).
• po.po_document.ShippingInstructions.name – La valeur du nom du champ, un
enfant de l'objet ShippingInstructions.
Noter:
• Chaque composant de la syntaxe de notation par points est limité à un maximum de
128 octets.
Reportezvous à Oracle Database SQL Language Reference pour plus d'informations sur la
syntaxe de notation par points SQL et les identificateurs SQL .
• Une simple requête JSON en notation pointée ne peut pas renvoyer une valeur supérieure à 4 Ko.
Si la valeur dépasse cette limite, SQL NULL est renvoyé à la place.
Pour obtenir la valeur réelle, utilisez la fonction SQL/JSON json_query ou json_value au
lieu de la notation par points, en spécifiant un type de retour approprié avec une clause
RETURNING.
Consultez Oracle Database SQL Language Reference pour plus d'informations sur la
syntaxe de notation par points JSON .
La correspondance d'une expression de notation par points JSON avec des données JSON est identique à la
correspondance d'une expression de chemin SQL/JSON, y compris l'assouplissement permettant l'itération de
tableau implicite (voir Assouplissement de la syntaxe de l'expression de chemin SQL/JSON (page 127)). La
colonne JSON d'une expression en notation par points correspond à l'élément de contexte d'une expression de
chemin, et chaque identifiant utilisé dans la notation par points correspond à un identifiant utilisé dans une
expression de chemin.
Par exemple, si la colonne JSON jcolumn correspond à l'élément de contexte pathexpression, l'expression
jcolumn.friends correspond à l'expression de chemin $.friends et jcolumn.friends.name correspond à
l'expression de chemin $.friends.name.
Pour ce dernier exemple, l'élément de contexte peut être un objet ou un tableau d'objets. S'il s'agit d'un tableau
d'objets, chacun des objets du tableau correspond à un champ friends.
La valeur de field friends peut ellemême être un objet ou un tableau d'objets. Dans ce dernier cas, le premier
objet du tableau est utilisé.
Noter:
Outre (1) l' utilisation implicite d'un caractère générique pour les éléments de tableau (voir Assouplissement
de la syntaxe des expressions de chemin SQL/JSON (page 127)) et (2) l'utilisation explicite d'un caractère
générique entre crochets de tableau ([*]), vous ne peut pas utiliser de caractères génériques dans une
expression de chemin lorsque vous utilisez la syntaxe de notation par points. En effet, un astérisque (*)
n'est pas un identificateur SQL valide.
Par exemple, cela génère une erreur de syntaxe :
mytable.mycolumn.object1.*.object2.
La syntaxe de notation par points est une alternative pratique à l'utilisation d'expressions de chemin
simples ; il ne remplace pas l'utilisation des expressions de chemin en général.
L'exemple 111 (page 113) montre des requêtes équivalentes en notation pointée et json_value.
Étant donné les données de l' exemple 42 (page 42), chacune des requêtes renvoie la chaîne « 1600 », une
valeur VARCHAR2 représentant le numéro JSON 1600.
L'exemple 112 (page 113) montre des requêtes équivalentes en notation pointée et json_query.
Chaque requête de la première paire renvoie (une valeur VARCHAR2 représentant) un tableau JSON d'objets
téléphoniques. Chaque requête de la deuxième paire renvoie (une valeur VARCHAR2 représentant) un tableau de
types de téléphones, comme dans l' exemple 161 (page 162).
Voir également:
• Oracle Database SQL Language Reference pour plus d'informations sur la notation par points utilisée
pour l'accès aux objets SQL et aux attributs d'objets (expressions d'accès aux objets)
• Présentation des expressions de chemin SQL/JSON (page 121)
Exemple 111 Requête JSON en notation par points comparée à JSON_VALUE
SELECT po.po_document.PONumber FROM j_purchaseorder bon de commande ;
SELECT json_value(po_document, '$.PONumber') FROM j_purchaseorder ;
Exemple 112 Requête JSON en notation par points comparée à JSON_QUERY
SELECT po.po_document.ShippingInstructions.Phone FROM j_purchaseorder bon de commande ;
SELECT json_query(po_document, '$.ShippingInstructions.Phone')
FROM j_bon de commande ;
SELECT po.po_document.ShippingInstructions.Phone.type FROM j_purchaseorder po;
SELECT json_query(po_document, '$.ShippingInstructions.Phone.type' WITH WRAPPER)
Accès simple par notation par points aux données JSON 113
12
Expressions de chemin SQL/JSON
Oracle Database fournit un accès SQL aux données JSON à l'aide d'expressions de chemin SQL/JSON.
Les sujets
Présentation des expressions de chemin SQL/JSON (page 121)
Oracle Database fournit un accès SQL aux données JSON à l'aide d'expressions de chemin
SQL/JSON.
Syntaxe d'expression de chemin SQL/JSON (page 122)
Les expressions de chemin SQL/JSON sont mises en correspondance avec les fonctions et les conditions SQL/
JSON par rapport aux données JSON, pour en sélectionner des parties. Les expressions de chemin peuvent
utiliser des caractères génériques et des plages de tableau. La correspondance est sensible à la casse.
12.1 Présentation des expressions de chemin SQL/JSON Oracle Database fournit un
accès SQL aux données JSON à l'aide d'expressions de chemin SQL/JSON.
JSON est une notation pour les valeurs JavaScript. Lorsque les données JSON sont stockées dans la base de
données, vous pouvez les interroger à l'aide d'expressions de chemin d'accès quelque peu analogues aux
expressions XQuery ou XPath pour les données XML. De la même manière que SQL/XML autorise l'accès SQL aux
données XML à l'aide d'expressions XQuery, Oracle Database fournit un accès SQL aux données JSON à l'aide
d'expressions de chemin SQL/JSON.
Les expressions de chemin SQL/JSON ont une syntaxe simple. Une expression de chemin sélectionne zéro ou
plusieurs valeurs JSON qui lui correspondent ou la satisfont.
La condition SQL/JSON json_exists renvoie true si au moins une valeur correspond, et false si aucune valeur ne
correspond. Si une seule valeur correspond, la fonction SQL/JSON json_value renvoie cette valeur si elle est
scalaire et génère une erreur si elle n'est pas scalaire. Si aucune valeur ne correspond à l'expression de chemin,
json_value renvoie SQL NULL.
La fonction SQL/JSON json_query renvoie toutes les valeurs correspondantes, c'estàdire qu'elle peut renvoyer
plusieurs valeurs. Vous pouvez considérer ce comportement comme renvoyant une séquence de valeurs, comme
dans XQuery, ou comme renvoyant plusieurs valeurs. (Aucune séquence visible par l'utilisateur ne se manifeste.)
Dans tous les cas, la correspondance d'expression de chemin tente de faire correspondre tour à tour chaque
étape de l'expression de chemin. Si la correspondance d'une étape échoue, aucune tentative n'est faite pour faire
correspondre les étapes suivantes et la correspondance de l'expression de chemin échoue. Si la correspondance
de chaque étape réussit, la correspondance de l'expression de chemin réussit.
Expressions de chemin SQL/JSON 121
Syntaxe d'expression de chemin SQL/JSON
Voir également:
Syntaxe d'expression de chemin SQL/JSON (page 122) pour plus d'informations sur les étapes d'expression de chemin
12.2 Syntaxe d'expression de chemin SQL/JSON
Les expressions de chemin SQL/JSON sont mises en correspondance avec les fonctions et les conditions SQL/JSON par rapport
aux données JSON, pour en sélectionner des parties. Les expressions de chemin peuvent utiliser des caractères génériques et
des plages de tableaux. La correspondance est sensible à la casse.
Les sujets
Vous transmettez une expression de chemin SQL/JSON et certaines données JSON à une fonction ou condition SQL/JSON. L'expression
de chemin est comparée aux données, et les données correspondantes sont traitées par la fonction ou la condition SQL/JSON
particulière. Vous pouvez penser à ce processus de correspondance en termes d'expression de chemin renvoyant les données
correspondantes à la fonction ou à la condition.
Voir également:
• Syntaxe d'expression de chemin SQL/JSON de base (page 122) et diagrammes pour
Syntaxe d'expression de chemin SQL/JSON de base (page B1)
• Assouplissement de la syntaxe des expressions de chemin SQL/JSON (page 127)
La syntaxe de base d'une expression de chemin SQL/JSON est présentée. Il est composé d'un élément
de contexte suivi de zéro ou plusieurs étapes d'objet ou de tableau, selon la nature de l'élément de contexte,
suivi éventuellement d'une étape de fonction. Des exemples sont fournis.
Assouplissement de la syntaxe des expressions de chemin SQL/JSON (page 127)
La syntaxe de base de l'expression de chemin SQL/JSON est assouplie pour permettre l'encapsulation et le
désencapsulage implicites du tableau. Cela signifie que vous n'avez pas besoin de modifier une expression de
chemin dans votre code si vos données évoluent pour remplacer une valeur JSON par un tableau de telles valeurs,
ou vice versa. Des exemples sont fournis.
12.2.1 Syntaxe d'expression de chemin SQL/JSON de base
La syntaxe de base d'une expression de chemin SQL/JSON est présentée. Il est composé d'un élément de contexte suivi de zéro
ou plusieurs étapes d'objet ou de tableau, selon la nature de l'élément de contexte, suivi éventuellement d'une étape de fonction. Des
exemples sont fournis.
Cependant, cette syntaxe de base est étendue en assouplissant la correspondance des tableaux et nontableaux avec les modèles
nontableau et tableau, respectivement — voir Assouplissement de la syntaxe d'expression de chemin SQL/JSON (page 127).
La correspondance des données avec les expressions de chemin SQL/JSON est sensible à la casse.
• Une expression de chemin de base SQL/JSON (également appelée simplement expression de chemin ici) est une expression de
chemin simple absolue, suivie d'une expression de filtre facultative.
L'expression de filtre facultative peut être présente uniquement lorsque l'expression de chemin
est utilisée dans la condition SQL json_exists. Aucune étape ne peut suivre l'expression de filtre.
(Ceci n'est pas autorisé, par exemple : $.a?(@.b == 2).c.)
• Une expression de chemin simple absolu commence par un signe dollar ($), qui
représente l' élément de contexte d' expression de chemin , c'estàdire les données JSON à mettre en correspondance.
Ces données sont le résultat de l'évaluation d'une expression SQL passée en argument à la fonction
SQL/JSON.
Le signe dollar est suivi de zéro ou plusieurs étapes de chemin. Chaque étape peut être une étape d'
objet ou une étape de tableau, selon que l'élément de contexte représente un objet JSON ou un
tableau JSON. La dernière étape d'une expression de chemin simple peut être une seule étape de
fonction facultative .
• Une étape d'objet est un point (.), parfois lu comme "point", suivi d'un nom de champ d'objet (nom de
propriété d'objet) ou d'un caractère générique astérisque (*) , qui représente (les valeurs de) tous les
champs. Un nom de champ peut être vide, auquel cas il doit s'écrire "". Un nom de champ non vide doit
commencer par une lettre majuscule ou minuscule A à Z et ne contenir que ces lettres ou chiffres
décimaux (09), ou bien il doit être entouré de guillemets doubles ("). Une étape d'objet renvoie la valeur
de le champ spécifié. Si un caractère générique est utilisé pour le champ, l'étape renvoie les valeurs de
tous les champs, sans ordre particulier.
• Une étape de tableau est un crochet gauche ([) suivi d' un astérisque (*) ,
qui représente tous les éléments du tableau, ou un ou plusieurs index de tableau spécifiques ou
spécifications de plage séparés par des virgules, suivis d'un crochet droit (]). Dans une expression de
chemin, l'indexation des tableaux est basée sur zéro (0, 1, 2,...), comme dans la convention JavaScript
pour les tableaux. Une spécification de plage a la forme N à M, où N et M sont des index de tableau et
N est strictement inférieur à M. (Une erreur est générée au moment de la compilation de la requête si N
n'est pas inférieur à M.) Une erreur est générée si vous utilisez à la fois un astérisque et un index de
tableau ou une spécification de plage.
Lorsque des index ou des spécifications de plage sont utilisés, les éléments de tableau
qu'ils spécifient collectivement doivent être spécifiés dans l'ordre croissant, sans répétitions, sinon
une erreur de compilation est déclenchée. Par exemple, une erreur est générée pour chacun des [3,
1 à 4], [4, 2], [2, 3 à 3] et [2, 3, 3]. Des erreurs sont levées sur les deux premiers car l'ordre n'est pas
croissant, des erreurs sont levées sur les deux derniers à cause de la répétition de l'élément numéro 3
(le quatrième élément, à cause de l'indexation à partir de zéro).
De même, les éléments de la valeur de tableau résultant de la correspondance sont dans
l'ordre croissant, sans répétitions. Si un astérisque est utilisé dans l'expression de chemin, tous les
éléments du tableau sont renvoyés, dans l'ordre du tableau.
• Une seule étape de fonction est facultative. S'il est présent, c'est la dernière étape du chemin
expression. Il s'agit d'un point (.), suivi d'une méthode d'élément SQL/JSON . Il est suivi d'une parenthèse
gauche (() puis d'une parenthèse droite ()). Les parenthèses peuvent être séparées par des espaces
(ces espaces sont insignifiants). La fonction est appliquée aux données ciblées par le reste de la même
expression de chemin, qui la précède. Il est utilisé pour transformer ces données. La fonction ou la
condition transmise à l'expression de chemin utilise les données transformées à la place des données
ciblées.
Noter:
– Si une méthode d'élément est appliquée à un tableau, elle est en fait appliquée à chacun des
les éléments du tableau. Par exemple, $.a.fun() applique la méthode item fun() à chaque
élément du tableau a, pour le convertir. Le tableau résultant de valeurs converties est ensuite
utilisé pour la correspondance, à la place de a.
– Si une conversion élémentméthode échoue pour une raison quelconque, par exemple si son
argument est du mauvais type, le chemin ne peut pas être mis en correspondance (il ne fait
référence à aucune donnée) et aucune erreur n'est générée. En particulier, cela signifie qu'une
telle erreur n'est pas gérée par une clause d'erreur dans la fonction ou la condition SQL/JSON
à laquelle l'expression de chemin est transmise.
Les méthodes d'élément disponibles sont les suivantes.
– abs() : La valeur absolue du numéro JSON ciblé. Correspond à la
utilisation de la fonction SQL ABS.
– ceiling() : Le nombre JSON ciblé, arrondi à l'entier supérieur le plus proche.
Correspond à l'utilisation de la fonction SQL CEIL.
– date() : La valeur SQL DATE qui correspond à la chaîne JSON ciblée.
Les données de chaîne doivent être dans l'un des formats de date ISO.
– double() : la valeur numérique SQL BINARY_DOUBLE qui correspond à la chaîne ou au numéro JSON
ciblé.
– floor() : le numéro JSON ciblé, arrondi à l'entier inférieur le plus proche.
Correspond à l'utilisation de la fonction SQL FLOOR.
– length() : Le nombre de caractères dans la chaîne JSON ciblée, en tant que SQL
NUMÉRO.
– lower() : la chaîne en minuscules qui correspond aux caractères de la chaîne JSON ciblée.
– number() : La valeur SQL NUMBER qui correspond au JSON ciblé
chaîne ou nombre.
– string() : représentation sous forme de chaîne de la valeur JSON ciblée. Le
La représentation est la même que celle utilisée pour la clause RETURNING d'une fonction SQL/
JSON avec le type de retour VARCHAR2. (Une valeur booléenne est représentée par la chaîne
"true" ou "false" ; une valeur nulle est représentée par la chaîne "null" ; et un nombre est représenté
sous une forme canonique.) Toute erreur qui se produit lors de la sérialisation dans la représentation
sous forme de chaîne est ignoré.
– timestamp() : La valeur SQL TIMESTAMP qui correspond à la chaîne JSON ciblée. Les données de
chaîne doivent être dans l'un des formats de date ISO.
– upper() : la chaîne en majuscules qui correspond aux caractères de la chaîne JSON ciblée.
Les méthodes d'élément date(), length(), lower(), number(), string(), timestamp() et upper()
sont des extensions Oracle du standard SQL/JSON.
Les autres méthodes d'item font partie de la norme.
• Une expression de filtre (filter, en abrégé) est un point d'interrogation (?) suivi d'une condition
de filtre entre parenthèses (()). Un filtre est satisfait si sa condition est satisfaite, c'està
dire qu'il renvoie vrai.
• Une condition de filtre applique un prédicat (fonction booléenne) à ses arguments et est l'une
des suivantes, où cond, cond1 et cond2 représentent chacun une condition de filtre.
– ( cond ): Les parenthèses sont utilisées pour regrouper, séparer la condition de filtre
cond en tant qu'unité des autres conditions de filtre qui peuvent la précéder ou la suivre.
– cond1 && cond2 : La conjonction (et) de cond1 et cond2, exigeant que les deux soient
satisfaites.
–cond1 || cond2 : La disjonction inclusive (ou) de cond1 et cond2,
exigeant que cond1, cond2, ou les deux, soient satisfaites.
– ! ( cond ): La négation de cond, signifiant que cond ne doit pas être satisfait.
– exists (, suivi d'une expression de chemin simple relatif, suivi de ) : les données ciblées
existent.
– Une comparaison, qui est l'une des suivantes :
* Une expression de chemin simple relative, suivie d'un prédicat de comparaison,
suivi soit d'une valeur scalaire JSON, soit d'une variable SQL/JSON.
* Soit une valeur scalaire JSON, soit une variable SQL/JSON, suivie d'un
prédicat de comparaison, suivi d'une expression de chemin simple relatif.
* Une valeur scalaire JSON, suivie d'un prédicat de comparaison, suivi d'une autre
valeur scalaire JSON.
Un prédicat de comparaison est ==, !=, <, <=, >= ou >.
Une variable SQL/JSON est un signe dollar ($) suivi du nom d'un identifiant SQL qui
est lié dans une clause PASSING pour json_exists.
Les prédicats que vous pouvez utiliser dans les conditions de filtre sont donc &&, ||, !, exists,
==, !=, <, <=, >= et >.
Par exemple, la condition de filtre (a || b) && (!(c) || d < 42) est satisfaite si les deux
critères suivants sont remplis :
– Au moins une des conditions de filtrage a et b est satisfaite : (a || b).
– La condition de filtre c n'est pas satisfaite ou le nombre d est inférieur ou égal à 42, ou les
deux sont vrais : (!(c) || d < 42).
Prédicat de comparaison ! a priorité sur &&, qui a priorité sur ||.
Vous pouvez toujours utiliser des parenthèses pour contrôler le regroupement.
Sans parenthèses pour le regroupement, l'exemple précédent serait un || b && !(c) || d <
42, qui serait satisfait si au moins un des critères suivants était rempli :
– La condition b && !(c) est satisfaite, ce qui signifie que chacune des conditions b et !(c) est
satisfaite (ce qui signifie à son tour que la condition c n'est pas satisfaite).
– La condition a est satisfaite.
– La condition d < 42 est satisfaite.
• Une expression de chemin simple relatif est un signe arobase (@) suivi de zéro ou plusieurs étapes de
chemin. Le signe arobase représente l' élément de filtre actuel de l'expression de chemin, c'estàdire
les données JSON qui correspondent à la partie de l'expression de chemin (entourante) qui précède le
filtre. L'expression de chemin simple est mise en correspondance avec l'élément de filtre actuel de la
même manière qu'une expression de chemin est mise en correspondance avec l'élément de contexte.
• Une expression de chemin simple est soit une expression de chemin simple absolu, soit une expression
de chemin simple relatif. (Le premier commence par $ ; le second commence par @.)
Voici quelques exemples d'expressions de chemin, avec leurs significations expliquées en détail.
• $ – L'élément de contexte.
• $.friends – La valeur des amis de champ d'un objet d'élément de contexte. Le point (.) immédiatement
après le signe dollar ($) indique que l'élément de contexte est un objet JSON.
• $.friends[0] – Un objet qui est le premier élément d'un tableau qui est la valeur des amis de champ d'un objet
d'élément de contexte. La notation entre parenthèses indique que la valeur de field friends est un tableau.
• $.friends[0].name – Valeur du nom de champ d'un objet qui est le premier élément d'un tableau qui est la
valeur des amis de champ d'un objet d'élément de contexte. Le deuxième point (.) indique que le premier
élément du tableau friends est un objet (avec un champ de nom).
• $.friends[*].name – Valeur du nom de champ de chaque objet dans un tableau qui est le
valeur des amis de champ d'un objet d'élément de contexte.
• $.*[*].name – Valeurs de nom de champ pour chaque objet dans une valeur de tableau d'un champ d'un
objet d'élément de contexte.
• $.friends[3, 8 à 10, 12] – Les quatrième, neuvième à onzième et treizième éléments d'un tableau
friends (champ d'un objet contextitem). Les éléments doivent être spécifiés dans l' ordre croissant,
et ils sont renvoyés dans cet ordre : quatrième, neuvième, dixième, onzième, treizième.
• $.friends[3].cars – La valeur des voitures de terrain d'un objet qui est le quatrième
élément d'un tableau amis. Le point (.) indique que le quatrième élément est un objet (avec un champ
voitures).
• $.friends[3].* – Les valeurs de tous les champs d'un objet qui est le quatrième élément d'un tableau
friends.
• $.friends[3].cars[0].year – La valeur du champ year d'un objet qui est le premier élément d'un tableau qui est
la valeur du champ cars d'un objet qui est le quatrième élément d'un tableau friends .
• $.friends[3].cars[0]?(@.year > 2014) – Le premier objet d'un tableau
cars (champ d'un objet qui est le quatrième élément d'un tableau friends), à condition que la valeur de
son champ year soit supérieure à 2014.
• $.friends[3]?(@.addresses.city == "San Francisco") – Un objet qui est le quatrième élément d'un tableau
friends, à condition qu'il ait un champ d'adresses dont la valeur est un objet avec un champ city dont
la valeur est la chaîne "San Francisco".
• $.amis[3] ?(@.adresses.ville == "San Francisco" &&
@.addresses.state == "Nevada") Objets qui sont le quatrième élément d'un tableau friends, à
condition qu'il y ait une correspondance pour une adresse avec une ville de "San Francisco" et qu'il
y ait une correspondance pour une adresse avec un état de
"Nevada".
Remarque : Les conditions de filtre dans la conjonction ne s'appliquent pas nécessairement au même
objet — le filtre teste l'existence d'un objet avec la ville San Francisco et l'existence d'un objet avec
l'état Nevada. Il ne teste pas l'existence d'un objet avec à la fois la ville de San Francisco et l'état du
Nevada. Voir Utilisation de filtres avec JSON_EXISTS (page 142).
• $.friends[3].addresses?(@.city == "San Francisco" && @.state == "Nevada") – Un objet qui est le
quatrième élément du tableau friends, à condition que cet objet corresponde à city de "San Francisco"
et un match pour l'état du "Nevada".
Contrairement à l'exemple précédent, dans ce cas les conditions de filtrage dans la conjonction, pour
les champs ville et état, s'appliquent au même objet adresses. Le filtre s'applique à un objet adresses
donné, qui est en dehors de celuici.
Voir également:
• Utilisation de filtres avec JSON_EXISTS (page 142) pour plus d'informations sur le filtre
expressions
• Diagrammes pour la syntaxe d'expression de chemin SQL/JSON de base (page B1) pour
des schémas de référence rapide qui récapitulent les informations fournies dans cette
rubrique
• https://en.wikipedia.org/wiki/ISO_8601 pour plus d'informations sur les formats de date ISO
12.2.2 Assouplissement de la syntaxe des expressions de chemin SQL/JSON
La syntaxe de base de l'expression de chemin SQL/JSON est assouplie pour permettre l'encapsulation
et le désencapsulage implicites du tableau. Cela signifie que vous n'avez pas besoin de modifier une expression
de chemin dans votre code si vos données évoluent pour remplacer une valeur JSON par un tableau de telles
valeurs, ou vice versa. Des exemples sont fournis.
Syntaxe d'expression de chemin SQL/JSON de base (page 122) définit la syntaxe d'expression de
chemin SQL/JSON de base. La syntaxe d'expression de chemin réelle prise en charge assouplit cette
définition comme suit :
•
Si une étape d'expression de chemin cible (attend) un tableau mais que les données réelles ne présentent
aucun tableau, les données sont implicitement enveloppées dans un tableau.
• Si une étape d'expression de chemin cible (attend) un nontableau mais que les données réelles
présentent un tableau, le tableau est implicitement déballé.
Cette assouplissement permet l'abréviation suivante : [*] peut être élidé chaque fois qu'il précède
l'accesseur d'objet, ., suivi d'un nom de champ d'objet, sans changement dans
effet. L'inverse est également vrai : [*] peut toujours être inséré devant l'objet sans effet de
accesseur, ., changement.
Cela signifie que l'étape d'objet [*].prop, qui représente la valeur du champ prop de chaque élément d'un
tableau d'objets donné, peut être abrégée en .prop, et l'étape d'objet .prop, qui semble être pour la valeur prop
d'un seul objet, représente également la valeur prop de chaque élément d'un tableau auquel l'accesseur
d'objet est appliqué.
Il s'agit d'une fonctionnalité importante, car cela signifie que vous n'avez pas besoin de modifier une
expression de chemin dans votre code si vos données évoluent pour remplacer une valeur JSON donnée
par un tableau de ces valeurs, ou vice versa.
Par exemple, si vos données contiennent à l'origine des objets qui ont un champ Téléphone dont la
valeur est un objet unique avec des champs type et numéro, l'expression de chemin $.Phone.number,
qui correspond à un seul numéro de téléphone, peut toujours être utilisée si les données évoluent vers
représentent un ensemble de téléphones. L'expression de chemin $.Phone.number correspond soit à un seul
objet téléphone, en sélectionnant son numéro, soit à un tableau d'objets téléphone, en sélectionnant le numéro
de chacun.
De même, si vos données mélangent les deux types de représentation (certaines entrées de données
utilisent un seul objet téléphone et d'autres utilisent un tableau d'objets téléphone, ou même certaines
entrées utilisent les deux), vous pouvez utiliser la même expression de chemin pour accéder au informations
téléphoniques à partir de ces différents types d'entrée.
Voici quelques exemples d'expressions de chemin de la section Syntaxe d'expression de chemin
SQL/JSON de base (page 122), ainsi qu'une explication des équivalences.
• $.friends – La valeur des amis sur le terrain de l'un ou l'autre :
– L'objet élément de contexte (unique).
– (équivalent à $[*].friends) Chaque objet du tableau d'éléments de contexte.
• $.friends[0].name – Valeur du nom du champ pour l'un de ces objets :
– Le premier élément du tableau qui est la valeur des champs amis du contexte
objet article.
– (équivalent à $.friends.name) La valeur du champ friends du contexte
objet article.
– (équivalent à $[*].friends.name) La valeur des amis de champ de chaque objet dans le tableau
d'éléments de contexte.
– (équivalent à $[*].friends[0].name) Le premier élément de chaque tableau qui est la valeur des amis de
champ de chaque objet dans le tableau d'éléments de contexte.
L'élément de contexte peut être un objet ou un tableau d'objets. Dans ce dernier cas, chaque objet
du tableau est mis en correspondance pour un champ amis.
La valeur de field friends peut être un objet ou un tableau d'objets. Dans ce dernier cas, le premier
objet du tableau est utilisé.
• $.*[*].name – Valeur du nom de champ pour l'un de ces objets :
– Un élément d'une valeur de tableau d'un champ de l'objet élément de contexte.
– (équivalent à $.*.name) La valeur d'un champ de l'objet contextitem.
– (équivalent à $[*].*.name) La valeur d'un champ d'un objet dans le contexte
tableau d'éléments.
– (équivalent à $[*].*[*].name) Chaque objet dans une valeur de tableau d'un champ d'un objet
dans le tableau d'éléments de contexte.
Voir également:
13
Clauses utilisées dans la requête SQL/JSON
Fonctions et conditions
Les clauses RETURNING, wrapper, error et emptyfield sont décrites. Chacun est utilisé dans une ou plusieurs des
fonctions et conditions SQL/JSON json_value, json_query, json_table, is json, is not json et json_exists.
Les sujets
Clause RETURNING pour les fonctions de requête SQL/JSON (page 131)
Les fonctions de requête SQL/JSON json_value et json_query acceptent une clause RETURNING
facultative , qui spécifie le type de données de la valeur renvoyée par la fonction. Cette clause et
le comportement par défaut (pas de clause RETURNING) sont décrits ici.
Clause wrapper pour les fonctions de requête SQL/JSON JSON_QUERY et JSON_TABLE
(page 133)
Les fonctions de requête SQL/JSON json_query et json_table acceptent une clause wrapper
facultative, qui spécifie la forme de la valeur renvoyée par json_query ou utilisée pour les données
dans une colonne json_table. Cette clause et le comportement par défaut (pas de clause wrapper)
sont décrits ici.
Des exemples sont fournis.
Clause d'erreur pour les fonctions et conditions de requête SQL/JSON (page 134)
Certaines fonctions et conditions de requête SQL/JSON acceptent une clause d'erreur
facultative, qui spécifie la gestion d'une erreur d'exécution déclenchée par la fonction ou la
condition. Cette clause et le comportement par défaut (pas de clause d'erreur) sont résumés ici.
Clause de champ vide pour les fonctions de requête SQL/JSON (page 135)
Les fonctions de requête SQL/JSON json_value, json_query et json_table acceptent
une clause facultative ON EMPTY , qui spécifie la gestion à utiliser lorsqu'un champ JSON ciblé
est absent des données interrogées. Cette clause et le comportement par défaut (pas de clause
ON EMPTY) sont décrits ici.
13.1 Clause RETURNING pour les fonctions de requête SQL/JSON
Les fonctions de requête SQL/JSON json_value et json_query acceptent une clause RETURNING facultative ,
qui spécifie le type de données de la valeur renvoyée par la fonction. Cette clause et le comportement par
défaut (pas de clause RETURNING) sont décrits ici.
Pour json_value, vous pouvez utiliser n'importe lequel de ces types de données SQL dans une clause RETURNING :
VARCHAR2, NUMBER, DATE, TIMESTAMP, TIMESTAMP WITH TIME ZONE et SDO_GEOMETRY. Pour
json_query, vous ne pouvez utiliser que VARCHAR2.
Vous pouvez éventuellement spécifier une longueur pour VARCHAR2 (par défaut : 4000) et une précision et une échelle
pour NUMBER.
Clauses utilisées dans les fonctions et conditions de requête SQL/JSON 131
Clause RETURNING pour les fonctions de requête SQL/JSON
Le comportement par défaut (pas de clause RETURNING) consiste à utiliser VARCHAR2(4000).
Le type de données SDO_GEOMETRY est destiné aux données Oracle Spatial et Graph. En particulier,
cela signifie que vous pouvez utiliser json_value avec les données GeoJSON, qui est un format d'encodage
des données géographiques en JSON.
La clause RETURNING accepte également deux mots clés facultatifs, PRETTY et ASCII. Si les deux sont
présents, PRETTY doit précéder ASCII. ASCII n'est autorisé que pour les fonctions SQL/JSON json_value
et json_query. PRETTY est autorisé uniquement pour json_query.
L'effet du motclé PRETTY est d'imprimer correctement les données renvoyées, en insérant des
caractères de saut de ligne et en indentant. Le comportement par défaut n'est pas de joliimprimer.
L'effet du motclé ASCII est d'échapper automatiquement tous les caractères Unicode nonASCII dans
les données renvoyées, en utilisant des séquences d'échappement Unicode ASCII standard. Le comportement
par défaut consiste à ne pas échapper les caractères Unicode nonASCII.
Pointe:
Vous pouvez imprimer l'intégralité de l'élément de contexte en utilisant uniquement $ comme
expression de chemin.
Si VARCHAR2 est spécifié dans une clause RETURNING, les scalaires de la valeur sont représentés
comme suit :
• Les valeurs booléennes sont représentées par les chaînes minuscules "true" et "false".
• La valeur nulle est représentée par une chaîne minuscule "null".
• Un numéro JSON est représenté sous une forme canonique. Il peut donc apparaître différemment dans la
chaîne de sortie de sa représentation dans les données d'entrée textuelles. Lorsqu'ils sont représentés
sous forme canonique :
– Il peut être soumis aux limites de précision et de plage d'un SQL NUMBER.
– Lorsqu'il n'est pas soumis aux limitations SQL NUMBER :
* La précision est limitée à quarante (40) chiffres.
* L'exposant facultatif est limité à neuf (9) chiffres plus un signe (+ ou ).
* Le texte entier, y compris les éventuels signes (, +), le point décimal (.) et l'indicateur
exponentiel (E), est limité à 48 caractères.
La forme canonique d'un numéro JSON :
– Est un numéro JSON. (Il peut être analysé dans les données JSON sous forme de nombre.)
– N'a pas de signe plus (+) au début.
– A un point décimal (.) uniquement lorsque cela est nécessaire.
– A un seul zéro (0) avant la virgule décimale si le nombre est une fraction
(entre zéro et un).
– Utilise la notation exponentielle (E) uniquement lorsque cela est nécessaire. En particulier, cela peut
être le cas si le nombre de caractères de sortie est trop limité (d'un petit N pour VARCHAR2(N)).
Clause wrapper pour les fonctions de requête SQL/JSON JSON_QUERY et JSON_TABLE
Voir également:
• Guide du développeur Oracle Spatial and Graph GeoRaster pour plus d'informations sur
à l'aide de données Oracle Spatial et Graph
13.2 Clause wrapper pour les fonctions de requête SQL/JSON JSON_QUERY
et JSON_TABLE
Les fonctions de requête SQL/JSON json_query et json_table acceptent une clause wrapper facultative, qui
spécifie la forme de la valeur renvoyée par json_query ou utilisée pour les données dans une colonne json_table.
Cette clause et le comportement par défaut (pas de clause wrapper) sont décrits ici. Des exemples sont fournis.
La clause wrapper prend l'une de ces formes :
• WITH WRAPPER – Utilisez une valeur de chaîne qui représente un tableau JSON contenant toutes les valeurs JSON
qui correspondent à l'expression de chemin. L'ordre des éléments du tableau n'est pas spécifié.
• SANS WRAPPER – Utilisez une valeur de chaîne qui représente l' objet ou le tableau JSON unique qui correspond
à l'expression de chemin. Génère une erreur si l'expression de chemin correspond à une valeur scalaire (pas
un objet ou un tableau) ou à plusieurs valeurs.
• WITH CONDITIONAL WRAPPER – Utilisez une valeur de chaîne qui représente tous les
Valeurs JSON qui correspondent à l'expression de chemin. Pour les valeurs nulles, une valeur scalaire unique ou
plusieurs valeurs, WITH CONDITIONAL WRAPPER est identique à WITH WRAPPER. Pour un seul objet JSON
ou une valeur de tableau, c'est la même chose que SANS
ENVELOPPEUR.
Le comportement par défaut est SANS WRAPPER.
Vous pouvez ajouter le motclé facultatif UNCONDITIONAL immédiatement après le motclé WITH, si vous le
trouvez plus clair : WITH WRAPPER et WITH UNCONDITIONAL WRAPPER signifient la même chose.
Vous pouvez ajouter le motclé facultatif ARRAY juste avant le motclé WRAPPER, si vous le trouvez plus clair :
WRAPPER et ARRAY WRAPPER signifient la même chose.
Le tableau 131 (page 133) illustre les possibilités de la clause wrapper. L'encapsuleur de tableau est affiché en gras.
Tableau 131 Exemples de clause d'encapsuleur JSON_QUERY
Valeurs JSON AVEC ENVELOPPE SANS ENVELOPPE AVEC CONDITIONNEL
Chemin correspondant ENVELOPPEUR
Expression
{"id": 38327} (objet [{"id": 38327}] {"id": 38327} {"id": 38327}

unique)
[42, "a", vrai] [[42, "a", vrai]] [42, "a", vrai] [42, "a", vrai]

(tableau unique)
Clause d'erreur pour les fonctions et conditions de requête SQL/JSON
Tableau 131 (suite) Exemples de clause d'encapsulation JSON_QUERY
Valeurs JSON AVEC ENVELOPPE SANS ENVELOPPE AVEC CONDITIONNEL
Chemin correspondant ENVELOPPEUR
Expression
42 [42] Erreur (scalaire) [42]
42, "a", vrai [42, "a", true] Erreur (valeurs multiples) [42, "a", true]
rien [] Erreur (aucune valeur) []
Considérez, par exemple, une requête json_query pour récupérer un objet JSON. Que se passetil si l'expression de
chemin correspond à une valeur scalaire JSON au lieu d'un objet, ou si elle correspond à plusieurs valeurs JSON (de
n'importe quel type) ? Vous souhaiterez peutêtre récupérer les valeurs correspondantes au lieu de générer une erreur.
Par exemple, vous pouvez choisir l'une des valeurs qui est un objet, pour un traitement ultérieur. L'utilisation d'un wrapper
de tableau vous permet de le faire.
Un wrapper conditionnel peut être pratique si la seule raison pour laquelle vous utilisez un wrapper est d'éviter de générer
une erreur et que vous n'avez pas besoin de distinguer ces cas d'erreur des cas sans erreur. Si votre application recherche
un objet ou un tableau unique et que les données correspondant à une expression de chemin ne sont que cela, il n'est
pas nécessaire d'envelopper cette valeur attendue dans un tableau singleton.
D'un autre côté, avec un wrapper inconditionnel, vous savez que le tableau résultant est toujours un wrapper votre
application peut compter làdessus. Si vous utilisez un wrapper conditionnel, votre application peut avoir besoin d'un
traitement supplémentaire pour interpréter un tableau renvoyé. Dans le Tableau 131 (page 133), par exemple, notez
que le même tableau ([42, "a", true]) est renvoyé pour les cas très différents d'une expression de chemin correspondant
à ce tableau et d'une expression de chemin correspondant à chacun de ses éléments.
13.3 Clause d'erreur pour les fonctions et conditions de requête SQL/JSON
Certaines fonctions et conditions de requête SQL/JSON acceptent une clause d'erreur facultative, qui spécifie la
gestion d'une erreur d'exécution déclenchée par la fonction ou la condition.
Cette clause et le comportement par défaut (pas de clause d'erreur) sont résumés ici.
Par défaut, les fonctions et conditions SQL/JSON évitent de générer des erreurs d'exécution. Par exemple, lorsque
les données JSON sont syntaxiquement invalides, json_exists renvoie false et json_value renvoie NULL. Mais vous
pouvez également spécifier une clause d'erreur, qui remplace le comportement par défaut. La gestion des erreurs que
vous pouvez spécifier varie, mais chaque fonction et condition SQL/JSON prend en charge au moins le comportement
ERROR ON ERROR consistant à déclencher un
Erreur.
La clause d'erreur facultative peut prendre ces formes :
• ERREUR SUR ERREUR – Remonte l'erreur (pas de traitement particulier).
• NULL ON ERROR – Renvoie NULL au lieu de déclencher l'erreur.
Non disponible pour json_exists.
• FALSE ON ERROR – Renvoie false au lieu de générer l'erreur.
Disponible uniquement pour json_exists, pour lequel il s'agit de la valeur par défaut.
• TRUE ON ERROR – Renvoie true au lieu de générer l'erreur.
Disponible uniquement pour json_exists.
Clause de champ vide pour les fonctions de requête SQL/JSON
• EMPTY OBJECT ON ERROR – Renvoie un objet vide ({}) au lieu de
Erreur.
Disponible uniquement pour json_query.
• EMPTY ARRAY ON ERROR – Renvoie un tableau vide ([]) au lieu d'augmenter le
Erreur.
Disponible uniquement pour json_query.
• EMPTY ON ERROR – Identique à EMPTY ARRAY ON ERROR.
• DEFAULT 'literal_return_value' ON ERROR – Renvoie la valeur spécifiée au lieu de générer l'erreur. La valeur doit
être une constante au moment de la compilation de la requête.
Non disponible pour json_query, et non disponible lorsque SDO_GEOMETRY est spécifié comme
type de données de clause RETURNING pour json_value ou comme type de données de colonne
json_table.
Le comportement par défaut est NULL ON ERROR, sauf pour la condition JSON_EXISTS.
Noter:
La clause ON ERROR prend effet uniquement pour les erreurs d'exécution qui surviennent lorsqu'une
expression de chemin SQL/JSON syntaxiquement correcte est mise en correspondance avec des
données JSON. Une expression de chemin dont la syntaxe est incorrecte entraîne une erreur de syntaxe
au moment de la compilation ; il n'est pas géré par la clause ON ERROR.
Noter:
Il existe deux niveaux de gestion des erreurs pour json_table, correspondant à ses deux niveaux
d'expressions de chemin : ligne et colonne. Lorsqu'il est présent, un gestionnaire d'erreurs de colonne
remplace la gestion des erreurs au niveau de la ligne. Le gestionnaire d'erreurs par défaut pour les deux
niveaux est NULL ON ERROR.
Noter:
Une clause ON EMPTY remplace le comportement spécifié par ON ERROR pour l'erreur de tentative de
correspondance d'un champ manquant.
Voir également:
• Clause de champ vide pour les fonctions de requête SQL/JSON (page 135)
• Fonction SQL/JSON JSON_TABLE (page 171)
• Référence du langage SQL de la base de données Oracle et langage SQL de la base de données Oracle
Référence pour des informations détaillées sur la clause d'erreur pour les fonctions et conditions
SQL/JSON, respectivement
13.4 Clause de champ vide pour les fonctions de requête SQL/JSON Les fonctions de requête SQL/JSON
json_value, json_query et json_table acceptent une clause facultative ON EMPTY , qui spécifie la gestion à utiliser
lorsqu'un JSON ciblé
Clause de champ vide pour les fonctions de requête SQL/JSON
champ est absent des données interrogées. Cette clause et le comportement par défaut (pas de
clause ON EMPTY) sont décrits ici.
Vous gérez généralement les erreurs des fonctions et conditions SQL/JSON à l'aide d'une clause d'erreur
(ON ERROR). Cependant, il existe un cas particulier où vous pouvez souhaiter une gestion différente de
cette gestion d'erreur générale : lors de la requête pour faire correspondre des champs JSON donnés qui
manquent dans les données. Parfois, vous ne souhaitez pas générer d'erreur simplement parce qu'un champ
à mettre en correspondance est absent. (Un champ manquant est normalement traité comme une erreur.)
Vous utilisez généralement une clause NULL ON EMPTY conjointement avec une clause ON ERROR
associée. Cette combinaison spécifie que les autres erreurs sont gérées conformément à la clause ON
ERROR, mais l'erreur consistant à essayer de faire correspondre un champ manquant est gérée en
renvoyant simplement NULL. Si aucune clause ON EMPTY n'est présente, une clause ON ERROR gère
également le cas du champ manquant.
En plus de NULL ON EMPTY, il existe ERROR ON EMPTY et DEFAULT ... ON EMPTY, qui sont
analogues aux clauses ON ERROR portant le même nom.
Si seule une clause ON EMPTY est présente (pas de clause ON ERROR), le comportement des
champs manquants est spécifié par la clause ON EMPTY et les autres erreurs sont traitées de la même
manière que si NULL ON ERROR était présent (il s'agit de la valeur par défaut ON ERROR). Si les deux
clauses sont absentes, seule NULL ON ERROR est utilisée.
Utiliser NULL ON EMPTY pour un index créé sur JSON_VALUE NULL ON EMPTY
est particulièrement utile dans le cas d'un index fonctionnel créé sur une expression json_value. La
clause n'a aucun effet sur l'opportunité ou le moment où l'index est récupéré, mais elle est efficace pour
permettre l'indexation de certaines données qui ne le seraient pas autrement parce qu'il manque un champ
ciblé par l'expression json_value.
Vous souhaitez généralement utiliser ERROR ON ERROR pour les requêtes qui remplissent l'index, de
sorte qu'une expression de chemin de requête qui aboutit à plusieurs valeurs ou à des valeurs complexes
génère une erreur. Mais parfois, vous ne voulez pas générer d'erreur simplement parce que le champ ciblé
par une expression de chemin est manquant — vous voulez que ces données soient indexées.
L' exemple 245 (page 244) illustre cette utilisation de NULL ON EMPTY lors de la création d'un index
sur une expression json_value.
Voir également:
• Création d'index basés sur la fonction JSON_VALUE (page 243)
• Clause d'erreur pour les fonctions et conditions de requête SQL/JSON (page 134)
14
Condition SQL/JSON JSON_EXISTS
La condition SQL/JSON json_exists vous permet d'utiliser une expression de chemin SQL/JSON comme filtre de
ligne, pour sélectionner des lignes en fonction du contenu des documents JSON. Vous pouvez utiliser la condition
json_exists dans une expression CASE ou la clause WHERE d'un SELECT
déclaration.
La condition json_exists vérifie l'existence d'une valeur particulière dans les données JSON : elle renvoie true si la
valeur est présente et false si elle est absente. Plus précisément, json_exists renvoie true si les données qu'il cible
correspondent à une ou plusieurs valeurs JSON. Si aucune valeur JSON ne correspond, elle renvoie false.
Vous pouvez également utiliser json_exists pour créer des index bitmap à utiliser avec des données JSON — voir l'
Exemple 241 (page 243).
Les gestionnaires d'erreurs ERROR ON ERROR, FALSE ON ERROR et TRUE ON ERROR s'appliquent.
La valeur par défaut est FAUX EN CAS D'ERREUR. Le gestionnaire prend effet lorsqu'une erreur se produit, mais
généralement une erreur se produit lorsque les données JSON données ne sont pas bien formées (en utilisant une
syntaxe laxiste). Contrairement au cas où les conditions sont json et non json, la condition json_exists s'attend à ce
que les données qu'elle examine soient des données JSON bien formées.
Le deuxième argument de json_exists est une expression de chemin SQL/JSON suivie d'une clause facultative
PASSING et d'une clause facultative error. L'expression de chemin doit cibler une seule valeur scalaire, sinon une
erreur de compilation est générée.
L'expression de filtre facultative d'une expression de chemin SQL/JSON utilisée avec json_exists
peut faire référence à des variables SQL/JSON, dont les valeurs sont transmises depuis SQL en les liant avec la
clause PASSING. Les types de données SQL suivants sont pris en charge pour ces variables : VARCHAR2,
NUMBER, BINARY_DOUBLE, DATE, TIMESTAMP et TIMESTAMP WITH TIMEZONE.
Noter:
La condition SQL/JSON json_exists appliquée à la valeur JSON null renvoie la chaîne SQL 'true'.
Les sujets
Voir également:
• Oracle Database SQL Language Reference pour plus d'informations sur json_exists
Condition SQL/JSON JSON_EXISTS 141
Utilisation de filtres avec JSON_EXISTS
Utilisation de filtres avec JSON_EXISTS (page 142)
Vous pouvez utiliser la condition SQL/JSON json_exists avec une expression de chemin comportant
une ou plusieurs expressions de filtre pour sélectionner des documents contenant des données
correspondantes. Les filtres vous permettent de tester l'existence de documents contenant des
champs particuliers remplissant diverses conditions.
JSON_EXISTS en tant que JSON_TABLE (page 143)
La condition SQL/JSON json_exists peut être considérée comme un cas particulier de la fonction
SQL/JSON json_table.
14.1 Utilisation de filtres avec JSON_EXISTS
Vous pouvez utiliser la condition SQL/JSON json_exists avec une expression de chemin comportant une ou plusieurs
expressions de filtre pour sélectionner des documents contenant des données correspondantes. Les filtres vous
permettent de tester l'existence de documents contenant des champs particuliers remplissant diverses conditions.
La condition SQL/JSON json_exists renvoie true pour les documents contenant des données qui correspondent à une
expression de chemin SQL/JSON. Si l'expression de chemin contient un filtre, les données qui correspondent au
chemin auquel ce filtre est appliqué doivent également satisfaire le filtre, afin que json_exists renvoie true pour le
document contenant les données.
Un filtre s'applique au chemin qui le précède immédiatement, et le test consiste à déterminer si (a) le document
donné contient des données qui correspondent à ce chemin et (b) si les données correspondantes satisfont le filtre.
Si ces deux conditions sont remplies, json_exists renvoie true pour le document.
L'expression de chemin précédant immédiatement un filtre définit la portée des modèles utilisés dans celuici. Un
arobase (@) dans un filtre fait référence aux données ciblées par ce chemin, qui sont appelées l' élément actuel pour
le filtre. Par exemple, dans l'expression de chemin $.LineItems?(@.Part.UPCCode == 85391628927), @ fait référence
à une occurrence du tableau LineItems.
Voir aussi : Syntaxe d'expression de chemin SQL/JSON de base (page 122)
Exemple 141 JSON_EXISTS : expression de chemin sans filtre
Cet exemple sélectionne des documents de bon de commande qui ont un élément de ligne dont la description
de pièce contient une entrée de code UPC.
SELECT po.po_document FROM j_purchaseorder po
WHERE json_exists(po.po_document, '$.LineItems.Part.UPCCode');
Exemple 142 JSON_EXISTS : élément actuel et portée dans les filtres d'expression de chemin
Cet exemple montre trois manières équivalentes de sélectionner des documents qui ont un élément de ligne dont
la partie contient un code UPC avec une valeur de 85391628927.
WHERE json_exists(po.po_document, '$?(@.LineItems.Part.UPCCode == 85391628927)');
WHERE json_exists(po.po_document, '$.LineItems?(@.Part.UPCCode == 85391628927)');
WHERE json_exists(po.po_document, '$.LineItems.Part?(@.UPCCode == 85391628927)');
• Dans la première requête, la portée du filtre est l'élément de contexte, c'estàdire un
bon de commande. @ fait référence à l'élément de contexte.
JSON_EXISTS en tant que JSON_TABLE
• Dans la deuxième requête, la portée du filtre est un tableau LineItems (et chacun de ses
éléments, implicitement). @ fait référence à un élément de ce tableau.
• Dans la troisième requête, la portée du filtre est un champ Part d'un élément dans un LineItems
déployer. @ fait référence à un champ Part.
Exemple 143 JSON_EXISTS : les conditions de filtrage dépendent de l'élément actuel
Cet exemple sélectionne des documents de bon de commande qui ont à la fois un élément de ligne
avec une pièce qui a le code UPC 85391628927 et un élément de ligne avec une quantité de commande
supérieure à 3. La portée de chaque filtre, c'estàdire l'élément actuel, est dans ce cas l'élément de
contexte. Chaque condition de filtre s'applique indépendamment (au même document) ; les deux
conditions ne s'appliquent pas nécessairement au même poste.
SELECT po.po_document FROM j_purchaseorder po WHERE
json_exists(po.po_document, '$?(@.LineItems.Part.UPCCode == 85391628927 && @.LineItems.Quantity >
3)');
Exemple 144 JSON_EXISTS : Réduction de la portée du filtre
Cet exemple ressemble à l' exemple 143 (page 143), mais il agit tout à fait différemment. Il sélectionne
les documents de bon de commande qui ont un article avec une pièce qui a un code UPC et avec une
quantité de commande supérieure à 3. La portée de l'article actuel dans le filtre est à un niveau inférieur ;
ce n'est pas l'élément de contexte mais un élément de tableau LineItems. Autrement dit, le même
élément de ligne doit satisfaire aux deux conditions, pour que json_exists renvoie true.
json_exists(po.po_document, '$.LineItems?(@.Part.UPCCode == 85391628927 && @.Quantity > 3)');
Exemple 145 JSON_EXISTS : expression de chemin utilisant PathExpression existe
État
Cet exemple montre comment réduire la portée d'une partie d'un filtre tout en laissant une autre partie
au niveau du document (élément de contexte). Il sélectionne les documents de bon de commande qui
ont un champ Utilisateur dont la valeur est "ABULL" et les documents qui ont un article avec une pièce
qui a un code UPC et avec une quantité de commande supérieure à 3. C'estàdire qu'il sélectionne les
mêmes documents sélectionnés par Exemple 144 (page 143), ainsi que tous les documents dont
l'utilisateur est "ABULL". L'argument du prédicat d'expression de chemin existe est une expression de
chemin qui spécifie des éléments de ligne particuliers ; le prédicat renvoie true si une correspondance est
trouvée, c'estàdire si de tels éléments de ligne existent.
(Si vous utilisez cet exemple ou similaire avec SQL*Plus, vous devez d'abord utiliser SET DEFINE
OFF, afin que SQL*Plus n'interprète pas && existe comme une variable de substitution et vous invite
à la définir.)
json_exists(po.po_document, '$.(@.User == "ABULL"
&& existe(@.LineItems?(@.Part.UPCCode == 85391628927
&& @.Quantité > 3)))');
14.2 JSON_EXISTS comme JSON_TABLE Condition SQL/
JSON json_exists peut être considéré comme un cas particulier de la fonction SQL/JSON json_table.
L'exemple 146 (page 144) illustre l'équivalence : les deux instructions SELECT ont le même
effet.
En plus de vous aider peutêtre à mieux comprendre json_exists, cette équivalence est importante en
pratique, car cela signifie que vous pouvez utiliser l'un ou l'autre pour obtenir le même effet.
Condition SQL/JSON JSON_EXISTS 143
JSON_EXISTS en tant que JSON_TABLE
En particulier, si vous utilisez json_exists plus d'une fois, ou que vous l'utilisez en combinaison
avec json_value ou json_query (qui peut également être exprimé en utilisant json_table), pour
accéder aux mêmes données, alors une seule invocation de json_table présente l'avantage que
les données sont analysé une seule fois.
Pour cette raison, l'optimiseur réécrit souvent automatiquement plusieurs invocations de
json_exists, json_value et json_query (toute combinaison) en moins d'invocations de
json_table.
Voir également:
JSON_TABLE généralise les fonctions et conditions de requête SQL/JSON
(page 173)
Exemple 146 JSON_EXISTS exprimé à l'aide de JSON_TABLE
SELECT select_list
FROM table WHERE json_exists(column, json_path error_handler ON ERROR);
SELECT select_list
FROM table,
json_table(column, '$' error_handler ON ERROR
COLUMNS ("COLUMN_ALIAS" NUMBER EXISTS PATH json_path)) AS "JT"
WHERE jt.column_alias = 1 ;
15
Fonction SQL/JSON JSON_VALUE
La fonction SQL/JSON json_value sélectionne une valeur scalaire à partir des données JSON et la renvoie sous forme
de valeur SQL.
Vous pouvez également utiliser json_value pour créer des index Btree basés sur des fonctions à utiliser avec les
données JSON — voir Index pour les données JSON (page 241).
La fonction json_value a deux arguments obligatoires et accepte les clauses de retour et d'erreur facultatives.
Le premier argument de json_value est une expression SQL qui renvoie une instance d'un type de données SQL
scalaire (c'estàdire, pas un objet ou un type de données de collection). Il peut s'agir de données de type
VARCHAR2, BLOB ou CLOB. Il peut s'agir d'une valeur de colonne de table ou de vue, d'une variable PL/SQL ou
d'une variable de liaison avec un casting approprié. Le résultat de l'évaluation de l'expression SQL est utilisé comme
élément de contexte pour évaluer l'expression de chemin.
Le deuxième argument de json_value est une expression de chemin SQL/JSON suivie des clauses facultatives
RETURNING, ON ERROR et ON EMPTY. L'expression de chemin doit cibler une seule valeur scalaire, sinon une
erreur se produit.
Le comportement de gestion des erreurs par défaut est NULL ON ERROR, ce qui signifie qu'aucune valeur n'est
renvoyée si une erreur se produit — une erreur n'est pas déclenchée. En particulier, si l'expression de chemin cible une
valeur non scalaire, telle qu'un tableau, aucune erreur n'est générée, par défaut. Pour vous assurer qu'une erreur est
générée, utilisez ERROR ON ERROR.
Noter:
Chaque nom de champ dans un objet JSON donné n'est pas nécessairement unique ; le même nom
de champ peut être répété. L'évaluation de flux qu'Oracle Database utilise utilise toujours un seul des
membres d'objet qui ont un nom de champ donné ; tous les autres membres avec le même nom de
champ sont ignorés. Il n'est pas précisé lequel de ces multiples membres est utilisé.
Voir aussi Champs uniques et champs en double dans les objets JSON (page 51).
Les sujets
Voir également:
• Oracle Database SQL Language Reference pour plus d'informations sur json_value
Fonction SQL/JSON JSON_VALUE 151
Utilisation de la fonction SQL/JSON JSON_VALUE avec une valeur booléenne JSON
Utilisation de la fonction SQL/JSON JSON_VALUE avec une valeur booléenne JSON (page
152)
JSON a les valeurs booléennes true et false. Oracle SQL n'a pas de type de données
booléen. Lorsque la fonction SQL/JSON json_value évalue une expression de chemin SQL/
JSON et que le résultat est vrai ou faux, il existe deux façons de gérer le résultat en SQL :
sous forme de chaîne ou sous forme de nombre.
Fonction SQL/JSON JSON_VALUE appliquée à une valeur JSON nulle (page 153)
La fonction SQL/JSON json_value appliquée à la valeur JSON null renvoie SQL NULL, et
non la chaîne SQL 'null'. Cela signifie, en particulier, que vous ne pouvez pas utiliser
json_value pour distinguer la valeur JSON null de l'absence de valeur ; SQL NULL indique
les deux cas.
JSON_VALUE en tant que JSON_TABLE (page 153)
La fonction SQL/JSON json_value peut être considérée comme un cas particulier de la
fonction json_table.
15.1 Utilisation de la fonction SQL/JSON JSON_VALUE avec une valeur booléenne
JSON
JSON a les valeurs booléennes true et false. Oracle SQL n'a pas de type de données booléen.
Lorsque la fonction SQL/JSON json_value évalue une expression de chemin SQL/JSON et que le résultat est
vrai ou faux, il existe deux façons de gérer le résultat en SQL : sous forme de chaîne ou sous forme de nombre.
Par défaut, le type de données renvoyé est une chaîne SQL (VARCHAR2), ce qui signifie que le résultat est la
chaîne 'true' ou 'false'. Vous pouvez également renvoyer le résultat sous la forme d'un nombre SQL, auquel cas
la valeur JSON true est renvoyée sous la forme du nombre 1 et false est renvoyé sous la forme de 0.
L'exemple 151 (page 152) illustre cela. La première requête renvoie la chaîne 'true' ; la deuxième requête
renvoie le nombre 1.
Vous pouvez également utiliser json_value dans le code PL/SQL. Dans ce cas, BOOLEAN est un type
de retour PL/SQL valide pour la fonction PL/SQL intégrée json_value. L'exemple 152 (page 152)
illustre cela.
Exemple 151 JSON_VALUE : deux manières de renvoyer une valeur booléenne JSON en SQL
SELECT json_value(po_document, '$.AllowPartialShipment')
SELECT json_value(po_document, '$.AllowPartialShipment' NUMÉRO DE RETOUR)
Exemple 152 Renvoi d'une valeur BOOLEAN PL/SQL à partir de JSON_VALUE
Contrairement à Oracle SQL, PL/SQL a un type de données BOOLEAN, que vous pouvez utiliser pour
la valeur de retour de la fonction intégrée PL/SQL json_value.
PL/SQL dispose également d'une gestion des exceptions. Cet exemple utilise la clause ERROR ON ERROR,
pour déclencher une erreur (qui peut être gérée par le code utilisateur) en cas d'erreur.
DÉCLARER
b BOOLÉEN ;
CLOB jsonData ;
COMMENCER
SELECT po_document INTO jsonData FROM j_purchaseorder WHERE rownum = 1 ; b := json_value(jsonData,
'$.AllowPartialShipment'
BOOLÉEN DE RETOUR
ERREUR SUR ERREUR);
Fonction SQL/JSON JSON_VALUE appliquée à une valeur JSON nulle
FIN; /
15.2 Fonction SQL/JSON JSON_VALUE appliquée à une valeur JSON nulle
La fonction SQL/JSON json_value appliquée à la valeur JSON null renvoie SQL NULL, et non la
chaîne SQL 'null'. Cela signifie, en particulier, que vous ne pouvez pas utiliser json_value pour
distinguer la valeur JSON null de l'absence de valeur ; SQL NULL indique les deux cas.
15.3 JSON_VALUE en tant que JSON_TABLE La
fonction SQL/JSON json_value peut être considérée comme un cas particulier de la
L'exemple 153 (page 153) illustre l'équivalence : les deux instructions SELECT ont le
même effet.
En plus de vous aider peutêtre à mieux comprendre json_value, cette équivalence est
importante en pratique, car cela signifie que vous pouvez utiliser l'une ou l'autre fonction pour
obtenir le même effet.
En particulier, si vous utilisez json_value plus d'une fois, ou que vous l'utilisez en combinaison
avec json_exists ou json_query (qui peut également être exprimé en utilisant json_table),
pour accéder aux mêmes données, alors une seule invocation de json_table présente
l'avantage que les données sont analysé une seule fois.
json_exists, json_value et json_query (toute combinaison) en moins d'invocations de
json_table.
Voir également:
(page 173)
Exemple 153 JSON_VALUE exprimé à l'aide de JSON_TABLE
SELECT json_value(column, json_path RETURNING data_type error_hander ON ERROR)
table DEPUIS ;
SELECT jt.column_alias FROM
table, json_table(column, '$'
error_handler ON ERROR COLUMNS ("COLUMN_ALIAS"
data_type PATH json_path)) AS "JT" ;
Fonction SQL/JSON JSON_VALUE 153
JSON_VALUE en tant que JSON_TABLE
16
Fonction SQL/JSON JSON_QUERY
La fonction SQL/JSON json_query sélectionne une ou plusieurs valeurs à partir des données JSON et renvoie
une chaîne (VARCHAR2) qui représente les valeurs JSON. (Contrairement à la fonction json_value, le type de
données de retour ne peut pas être NUMBER). Vous pouvez ainsi utiliser json_query pour récupérer des fragments d'un
document JSON.
Le premier argument de json_query est une expression SQL qui renvoie une instance d'un type de données SQL
scalaire (c'estàdire, pas un objet ou un type de données de collection). Il peut s'agir de données de type
VARCHAR2, BLOB ou CLOB. Il peut s'agir d'une valeur de colonne de table ou de vue, d'une variable PL/SQL ou
d'une variable de liaison avec un casting approprié. Le résultat de l'évaluation de l'expression SQL est utilisé comme
élément de contexte pour évaluer l'expression de chemin.
Le deuxième argument de json_query est une expression de chemin SQL/JSON suivie des clauses facultatives
RETURNING, WRAPPER, ON ERROR et ON EMPTY. L'expression de chemin peut cibler n'importe quel nombre
de valeurs JSON.
Dans la clause RETURNING, vous ne pouvez spécifier que le type de données VARCHAR2 ; vous ne pouvez
pas spécifier NUMBER.
La clause wrapper détermine la forme de la valeur de chaîne renvoyée.
La clause d'erreur pour json_query peut spécifier EMPTY ON ERROR, ce qui signifie qu'un tableau vide ([]) est renvoyé
en cas d'erreur (aucune erreur n'est générée).
L'exemple 161 (page 162) montre un exemple d'utilisation de la fonction SQL/JSON json_query avec un
wrapper de tableau. Pour chaque document, il renvoie une valeur VARCHAR2 dont le contenu représente un tableau
JSON avec des éléments les types de téléphone, dans un ordre non spécifié. Pour le document de l' exemple 42 (page
42), les types de téléphone sont "Office" et "Mobile", et le tableau renvoyé est soit ["Mobile", "Office"] soit ["Office",
"Mobile" ].
Notez que si l'expression de chemin $.ShippingInstructions.Phone.type était utilisée dans l' exemple 161 (page 162),
elle donnerait le même résultat. En raison de la relaxation de la syntaxe de l'expression de chemin SQL/JSON, [*].type
est équivalent à .type.
Fonction SQL/JSON JSON_QUERY 161
JSON_QUERY en tant que JSON_TABLE
Les sujets
Voir également:
• Oracle Database SQL Language Reference pour plus d'informations sur
json_query
• Clause wrapper pour les fonctions de requête SQL/JSON JSON_QUERY et
JSON_TABLE (page 133)
Exemple 161 Sélection de valeurs JSON à l'aide de JSON_QUERY
SELECT json_query(po_document, '$.ShippingInstructions.Phone[*].type'
AVEC ENVELOPPE)
JSON_QUERY en tant que JSON_TABLE (page 162)
La fonction SQL/JSON json_query peut être considérée comme un cas particulier de la
16.1 JSON_QUERY en tant que JSON_TABLE La fonction SQL/
JSON json_query peut être considérée comme un cas particulier de la fonction json_table.
L'exemple 162 (page 163) illustre l'équivalence : les deux instructions SELECT ont le même effet.
En plus de vous aider peutêtre à mieux comprendre json_query, cette équivalence est importante en pratique, car
cela signifie que vous pouvez utiliser l'une ou l'autre fonction pour obtenir le même effet.
En particulier, si vous utilisez json_query plus d'une fois, ou que vous l'utilisez en combinaison avec json_exists
ou json_value (qui peut également être exprimé en utilisant json_table), pour accéder aux mêmes données,
alors une seule invocation de json_table présente l'avantage que les données sont analysé une seule fois.
Pour cette raison, l'optimiseur réécrit souvent automatiquement plusieurs invocations de json_exists, json_value
et json_query (toute combinaison) en moins d'invocations de json_table.
Voir également:
Exemple 162 JSON_QUERY exprimé à l'aide de JSON_TABLE
SELECT json_query(colonne, json_path
RETOUR data_type array_wrapper error_hander ON ERROR)
table DEPUIS ;
SELECT jt.column_alias FROM
table, json_table(column, '$'
error_handler ON ERROR
COLONNES ("COLUMN_ALIAS" data_type FORMAT JSON array_wrapper
PATH json_path)) AS "JT" ;
Fonction SQL/JSON JSON_QUERY 163
17
Fonction SQL/JSON JSON_TABLE
La fonction SQL/JSON json_table projette des données JSON spécifiques dans les colonnes VARCHAR2,
NUMBER, DATE, TIMESTAMP, TIMESTAMP WITH TIME ZONE et SDO_GEOMETRY. Vous l'utilisez pour
décomposer le résultat de l'évaluation de l'expression JSON dans les lignes et les colonnes d'une nouvelle table
virtuelle, que vous pouvez également considérer comme une vue en ligne.
Vous pouvez ensuite insérer cette table virtuelle dans une table de base de données préexistante, ou vous pouvez
l'interroger à l'aide de SQL — dans une expression de jointure, par exemple.
Une utilisation courante de json_table consiste à créer une vue des données JSON. Vous pouvez utiliser une telle vue
comme vous utiliseriez n'importe quelle table ou vue. Cela permet aux applications, aux outils et aux programmeurs
d'opérer sur des données JSON sans tenir compte de la syntaxe des expressions de chemin JSON ou JSON.
La définition d'une vue sur les données JSON mappe en effet une sorte de schéma sur ces données. Ce mappage a
lieu après coup : les données JSON sousjacentes peuvent être définies et créées sans tenir compte d'un schéma ou
d'un modèle d'utilisation particulier. Les données d'abord, le schéma ensuite.
Un tel schéma (mappage) n'impose aucune restriction sur le type de documents JSON pouvant être stockés dans la
table sousjacente (autre que des données JSON bien formées). La vue expose uniquement les données conformes au
mappage (schéma) qui définit la vue.
Pour modifier le schéma, redéfinissez simplement la vue — pas besoin de réorganiser les données JSON sousjacentes.
Vous utilisez json_table dans une clause SQL FROM. Il s'agit d'une source de ligne : elle génère une ligne de données
pour chaque valeur JSON sélectionnée par une expression de chemin de ligne (modèle de ligne).
Les lignes créées par une invocation json_table sont jointes latéralement, implicitement, à la ligne qui les a générées.
Autrement dit, vous n'avez pas besoin de joindre explicitement la table virtuelle produite par json_table avec la table
qui contient les données JSON.
Le premier argument de json_table est une expression SQL qui renvoie une instance d'un type de données SQL
scalaire (c'estàdire, pas un objet ou un type de données de collection). Il peut s'agir de données de type VARCHAR2,
BLOB ou CLOB. Il peut s'agir d'une valeur de colonne de table ou de vue, d'une variable PL/SQL ou d'une variable
de liaison avec un casting approprié. Le résultat de l'évaluation de l'expression SQL est utilisé comme élément de
contexte pour évaluer l'expression de chemin de ligne.
Le deuxième argument de json_table est une expression de chemin de ligne SQL/JSON suivie d'une clause d'erreur
facultative pour gérer la ligne et d'une clause COLUMNS (obligatoire).
(Il n'y a pas de clause RETURNING.) L'expression de chemin peut cibler n'importe quel nombre de valeurs JSON.
L'expression de chemin de ligne agit comme un modèle pour les lignes de la table virtuelle générée. Il est mis en
correspondance avec l'élément de contexte fourni par la clause SQL FROM, produisant des lignes de données SQL
organisées en colonnes, que vous spécifiez dans la clause COLUMNS. Chacune de ces lignes est comparée à zéro ou
plusieurs expressions de chemin de colonne pour générer les colonnes de la table virtuelle.
Fonction SQL/JSON JSON_TABLE 171
Il existe deux niveaux de gestion des erreurs pour json_table, correspondant aux deux niveaux
d'expressions de chemin : ligne et colonne. Lorsqu'il est présent, un gestionnaire d'erreurs de colonne
remplace la gestion des erreurs au niveau de la ligne. Le gestionnaire d'erreurs par défaut pour les deux niveaux est NULL
EN ERREUR.
La clause obligatoire COLUMNS définit les colonnes de la table virtuelle à créer par json_table. Il se compose
du motclé COLUMNS suivi des entrées suivantes entre parenthèses :
• Au plus une entrée de la clause COLUMNS peut être un nom de colonne suivi des motsclés FOR
ORDINALITY, qui spécifient une colonne de numéros de ligne générés (type de données SQL
NUMBER). Ces chiffres commencent par un.
• À l'exception de l'entrée facultative POUR ORDINALITE, chaque entrée de la colonne COLUMNS
La clause est soit une spécification de colonne régulière, soit une spécification de colonnes imbriquées.
• Une spécification de colonne standard se compose d'un nom de colonne suivi d'un type de données scalaire
facultatif pour la colonne, qui peut être le type de données SQL VARCHAR2, NUMBER, DATE,
TIMESTAMP, TIMESTAMP WITH TIME ZONE ou SDO_GEOMETRY (le même que pour la clause
RETURNING de json_value), suivi d'une clause de valeur facultative et d'une clause PATH obligatoire.
Le type de données par défaut est VARCHAR2(4000).
Le type de données SDO_GEOMETRY est utilisé pour les données Oracle Spatial et Graph.
En particulier, cela signifie que vous pouvez utiliser json_table avec les données GeoJSON, qui est un
format d'encodage des données géographiques en JSON.
• Une spécification de colonnes imbriquées se compose du motclé NESTED suivi d'un
mot clé facultatif PATH, une expression de chemin de ligne SQL/JSON, puis une clause COLUMNS.
Cette clause COLUMNS spécifie les colonnes qui représentent des données imbriquées. L'expression
de chemin de ligne utilisée ici fournit un contexte raffiné pour les colonnes imbriquées spécifiées : chaque
expression de chemin de colonne imbriquée est relative à l'expression de chemin de ligne.
Une clause COLUMNS à n'importe quel niveau (imbriquée ou non) a les mêmes caractéristiques.
En d'autres termes, la clause COLUMNS est définie de manière récursive. Pour chaque niveau d'imbrication
(c'estàdire pour chaque utilisation du motclé NESTED), la clause COLUMNS imbriquée est dite enfant
de la clause COLUMNS dans laquelle elle est imbriquée, qui est son parent. Deux ou plusieurs clauses
COLUMNS qui ont la même clause parent sont des frères et sœurs.
Les tables virtuelles définies par les clauses parent et enfant COLUMNS sont jointes à l'aide d'une
jointure externe , le parent étant la table externe. Les colonnes virtuelles définies par les clauses sœurs
COLUMNS sont jointes à l'aide d'une jointure d'union.
L'exemple 176 (page 176) illustre l'utilisation d'une clause de colonnes imbriquées.
• La clause de valeur facultative spécifie comment gérer les données projetées dans la colonne : s'il
faut les gérer comme le ferait json_value, json_exists ou json_query. Cette gestion des valeurs
inclut le type de données de retour, le format de retour (pretty ou ascii), le wrapper et le traitement des
erreurs.
Par défaut, les données projetées sont gérées comme si json_value. Si vous utilisez le motclé
EXISTS , il est géré comme par json_exists. Si vous utilisez des motsclés FORMAT JSON , il est géré
comme par json_query.
Pour FORMAT JSON, vous pouvez remplacer le comportement d'encapsulation par défaut en ajoutant
une clause wrapper explicite.
Vous pouvez remplacer la gestion des erreurs par défaut pour le gestionnaire donné (json_value, json_exists ou
json_query) en ajoutant une clause ERROR explicite appropriée pour celuici.
• La clause PATH obligatoire spécifie la partie de la ligne qui doit être utilisée comme contenu de la colonne.
L'expression de chemin de colonne suivant le motclé PATH est mise en correspondance avec l'élément de
contexte fourni par la ligne virtuelle. L'expression de chemin de colonne doit représenter un chemin relatif ; il
est relatif au chemin spécifié par l'expression de chemin de ligne.
Les sujets
Voir également:
• Clause wrapper pour les fonctions de requête SQL/JSON JSON_QUERY et
JSON_TABLE (page 133)
• Guide du développeur Oracle Spatial and Graph GeoRaster pour plus d'informations sur
à l'aide de données Oracle Spatial et Graph
La fonction SQL/JSON json_table généralise la condition SQL/JSON json_exists et les fonctions
SQL/JSON json_value et json_query. Tout ce que vous pouvez faire en utilisant ces fonctions,
vous pouvez le faire en utilisant json_table. Pour les tâches qu'elles accomplissent, la syntaxe de
ces fonctions est plus simple à utiliser que la syntaxe de json_table.
Utilisation de JSON_TABLE avec des tableaux JSON (page 175)
Une valeur JSON peut être un tableau ou peut inclure un ou plusieurs tableaux, imbriqués à
n'importe quel nombre de niveaux à l'intérieur d'autres tableaux ou objets JSON. Vous pouvez utiliser
une clause de chemin NESTED json_table pour projeter des éléments spécifiques d'un tableau.
Création d'une vue sur les données JSON à l'aide de JSON_TABLE (page 176)
Pour améliorer les performances des requêtes, vous pouvez créer une vue sur les données
JSON que vous projetez sur des colonnes à l'aide de la fonction SQL/JSON json_table. Pour
améliorer encore les performances des requêtes, vous pouvez créer une vue matérialisée en lecture
seule et placer les données JSON en mémoire.
17.1 JSON_TABLE généralise les fonctions et conditions de requête
SQL/JSON
La fonction SQL/JSON json_table généralise la condition SQL/JSON json_exists et les fonctions SQL/JSON
json_value et json_query. Tout ce que tu peux faire
en utilisant ces fonctions, vous pouvez utiliser json_table. Pour les tâches qu'elles accomplissent, la
syntaxe de ces fonctions est plus simple à utiliser que la syntaxe de json_table.
Si vous utilisez l'un des json_exists, json_value ou json_query plus d'une fois, ou en combinaison, pour
accéder aux mêmes données, une seule invocation de json_table présente l'avantage que les données
ne sont analysées qu'une seule fois.
json_exists, json_value et json_query (n'importe quelle combinaison) en moins d'invocations de
json_table à la place, de sorte que les données ne sont analysées qu'une seule fois.
L'exemple 171 (page 174) et l'exemple 172 (page 174) illustrent cela. Ils sélectionnent chacun
le demandeur et l'ensemble des téléphones utilisés par chaque objet dans la colonne
j_purchaseorder.po_document. Mais l'exemple 172 (page 174) analyse cette colonne une
seule fois, et non quatre fois.
Notez ce qui suit en rapport avec l' exemple 172 (page 174) :
• Une valeur JSON de null est une valeur en ce qui concerne SQL ; ce n'est pas NULL, qui en SQL
représente l'absence de valeur (données manquantes, inconnues ou inapplicables). Dans l'
exemple 172 (page 174), si la valeur JSON de l'attribut d'objet zipCode est nulle, la chaîne
SQL 'true' est renvoyée.
• Bien que json_exists renvoie une valeur booléenne, en tant que valeur SQL,
représenté par la chaîne SQL 'true' ou 'false'. Si json_exists est utilisé directement comme
condition dans une clause SQL WHERE ou une instruction CASE, vous n'avez pas besoin de
tester explicitement cette valeur de retour ; vous pouvez simplement écrire json_exists(...).
Mais si json_exists est utilisé ailleurs, pour obtenir une valeur, alors la seule façon de tester cette
valeur est en tant que chaîne explicite. C'est le cas dans l' exemple 172 (page 174) : la valeur est
stockée dans la colonne jt.has_zip, et elle est ensuite testée explicitement pour l'égalité avec la
chaîne SQL 'true'.
• L'attribut d'objet JSON AllowPartialShipment a une valeur booléenne JSON.
Lorsque json_value est appliqué à cette valeur, il peut être renvoyé sous forme de chaîne ou de
nombre. Dans l' exemple 172 (page 174), le type de données NUMBER est utilisé comme type
de données de colonne. La fonction json_table utilise implicitement json_value pour cette colonne,
renvoyant la valeur sous forme de nombre, dont l'égalité est ensuite testée par rapport au nombre
1.
Exemple 171 Accès aux données JSON plusieurs fois pour extraire des données
SELECT json_value(po_document, '$.Requestor' RETURNING VARCHAR2(32)),
json_query(po_document, '$.ShippingInstructions.Phone'
RETOUR VARCHAR2(100))
FROM j_purchaseorder
WHERE json_exists(po_document, '$.ShippingInstructions.Address.zipCode')
ET json_value(po_document, '$.AllowPartialShipment' NUMÉRO DE RETOUR(1))
= 1 ;
Exemple 172 Utilisation de JSON_TABLE pour extraire des données sans plusieurs analyses
SELECT jt.requestor, jt.phones FROM
j_purchaseorder, json_table(po_document,
'$'
COLONNES (demandeur VARCHAR2(32 CHAR) PATH '$.Requestor',
téléphones VARCHAR2(100
'$.ShippingInstructions.Phone',
CHAR) FORMAT NJUMBER
SON PATH
partiel(1)
PATH '$.AllowPartialShipment', has_zip
VARCHAR2(5 CHAR) EXISTE
CHEMIN '$.ShippingInstructions.Address.zipCode')) jt
WHERE jt.partial = 1 AND has_zip = 'true';
Utilisation de JSON_TABLE avec des tableaux JSON
17.2 Utilisation de JSON_TABLE avec des tableaux JSON
Une valeur JSON peut être un tableau ou peut inclure un ou plusieurs tableaux, imbriqués à n'importe
quel nombre de niveaux à l'intérieur d'autres tableaux ou objets JSON. Vous pouvez utiliser une clause de
chemin NESTED json_table pour projeter des éléments spécifiques d'un tableau.
L'exemple 173 (page 175) projette le demandeur et les numéros de téléphone associés à partir des données
JSON dans la colonne po_document. L'ensemble du tableau JSON Phone est projeté sous la forme d'une
colonne de données JSON, ph_arr. Pour formater ces données JSON en tant que colonne VARCHAR2, les mots
clés FORMAT JSON sont nécessaires.
Et si vous vouliez projeter les éléments individuels du tableau JSON Phone et non le tableau dans son
ensemble ? L'exemple 174 (page 176) montre une manière de procéder, que vous pouvez utiliser si les
éléments du tableau sont les seules données que vous devez projeter.
Si vous souhaitez projeter à la fois le demandeur et les données téléphoniques correspondantes, l'expression
de chemin de ligne de l' exemple 174 (page 176) ($.Phone[*]) n'est pas appropriée : elle ne cible que les
éléments (objet téléphone) de tableau Téléphone.
L'exemple 175 (page 176) montre une manière de cibler les deux : utilisez une expression de chemin de
ligne qui cible à la fois le nom et le tableau entier de téléphones, et utilisez des expressions de chemin de colonne
qui ciblent le type de champ et le nombre d'objets téléphone individuels.
Dans l' exemple 175 (page 176) comme dans l' exemple 173 (page 175), les mots clés FORMAT
JSON sont nécessaires car les colonnes VARCHAR2 résultantes contiennent des données JSON, à savoir des
tableaux de types de téléphone ou de numéros de téléphone, avec un tableau élément pour chaque téléphone. De
plus, contrairement au cas de l' exemple 173 (page 175), une clause wrapper est nécessaire pour la colonne
phone_type et la colonne phone_num, car le tableau Phone contient plusieurs objets avec des champs type et
number.
Parfois, vous ne souhaitez pas l'effet de l' exemple 175 (page 176). Par exemple, vous pouvez souhaiter une
colonne contenant un seul numéro de téléphone (une ligne par numéro), plutôt qu'une colonne contenant un
tableau JSON de numéros de téléphone (une ligne pour tous les numéros d'un bon de commande donné).
Pour obtenir ce résultat, vous devez indiquer à json_table de projeter les éléments du tableau, en utilisant une
clause de chemin NESTED json_table pour le tableau. Une clause de chemin NESTED agit, en fait, comme une
source de ligne supplémentaire (modèle de ligne). L'exemple 176 (page 176) illustre cela.
Vous pouvez utiliser n'importe quel nombre de mots clés NESTED dans un appel json_table donné.
Dans l' exemple 176 (page 176), la clause COLUMNS externe est le parent de la clause COLUMNS
imbriquée (interne). Les tables virtuelles définies sont jointes à l'aide d'une jointure externe, la table définie par la
clause parent étant la table externe dans la jointure.
(S'il y avait une seconde clause de colonnes imbriquée directement sous le même parent, les deux clauses
imbriquées seraient des clauses sœurs COLUMNS.)
Voir aussi : Création d'une vue sur les données JSON à l'aide de JSON_TABLE (page
176)
Exemple 173 Projection d'un tableau JSON entier en tant que données JSON
SELECT jt.*
FROM j_purchaseorder,
json_table(po_document, '$'
COLUMNS (requestor VARCHAR2(32 CHAR) PATH '$.Requestor',
Création d'une vue sur les données JSON à l'aide de JSON_TABLE
ph_arr VARCHAR2(100 CHAR) FORMAT JSON
PATH '$.ShippingInstructions.Phone')) AS "JT" ;
Exemple 174 Projection des éléments d'un tableau JSON
SELECT jt.*
json_table(po_document, '$.ShippingInstructions.Phone[*]'
COLUMNS (phone_type VARCHAR2(10) PATH '$.type',
phone_num VARCHAR2(20) PATH '$.number')) AS "JT" ;
TYPE DE TÉLÉPHONE PHONE_NUM

Bureau 9095557307
Portable 4155551234
Exemple 175 Projection d'éléments d'un tableau JSON plus d'autres données
SELECT jt.*
COLUMNS
( requestor VARCHAR2(32 CHAR) PATH '$.Requestor',
phone_type VARCHAR2(50 CHAR) FORMAT JSON WITH WRAPPER
CHEMIN '$.ShippingInstructions.Téléphone[*].type',
phone_num VARCHAR2(50 CHAR) FORMAT JSON AVEC CHEMIN
WRAPPER '$.ShippingInstructions.Phone[*].number')) AS "JT" ;
DEMANDEUR TYPE DE TÉLÉPHONE PHONE_NUM

Alexis Bull ["Bureau", "Mobile"] ["9095557307", "4155551234"]
Exemple 176 JSON_TABLE : Projection d'éléments de tableau à l'aide de NESTED
SELECT jt.*
COLUMNS
( demandeur VARCHAR2(32 CHAR) PATH '$.Requestor', PATH
IMBRANCHE '$.ShippingInstructions.Phone[*]'
COLUMNS (phone_type VARCHAR2(32 CHAR) PATH '$.type',
phone_num VARCHAR2(20 CHAR) PATH '$.number'))) AS "JT" ;
17.3 Création d'une vue sur les données JSON à l'aide de JSON_TABLE Pour améliorer les
performances des requêtes, vous pouvez créer une vue sur les données JSON que vous projetez sur
des colonnes à l'aide de la fonction SQL/JSON json_table. Pour améliorer encore les performances
des requêtes, vous pouvez créer une vue matérialisée en lecture seule et placer les données JSON
en mémoire.
L'exemple 177 (page 177) définit une vue sur les données JSON. Il utilise une clause de chemin
NESTED pour projeter les éléments du tableau LineItems.
L'exemple 178 (page 177) définit une vue matérialisée qui a les mêmes données et la même structure
que l' exemple 177 (page 177). Vous ne pouvez pas utiliser une telle vue matérialisée pour la mise à
jour ; vous devez la traiter comme une vue en lecture seule. Une erreur est levée si vous essayez de le modifier.
Les seules différences entre l' exemple 177 (page 177) et l'exemple 178 (page 177) sont :
• L'utilisation du mot clé MATERIALIZED.
• L'utilisation de BUILD IMMEDIATE.
• L'utilisation de REFRESH FAST ON COMMIT WITH PRIMARY KEY.
L'utilisation de REFRESH FAST signifie que la vue matérialisée sera actualisée de manière
incrémentielle. Pour cela, vous devez utiliser soit WITH PRIMARY KEY, soit WITH ROWID (s'il n'y a
pas de clé primaire). Oracle recommande de spécifier une clé primaire pour une table comportant une
colonne JSON et d'utiliser WITH PRIMARY KEY lors de la création d'une vue matérialisée basée sur celle
ci.
Voir également:
• Utilisation de JSON_TABLE avec des tableaux JSON (page 175)
• Guide d'entreposage de données de la base de données Oracle
Exemple 177 Création d'une vue sur des données JSON
CRÉER OU REMPLACER LA VUE j_purchaseorder_detail_view
AS SELECT d.*
FROM j_purchaseorder po,
json_table(po.po_document, '$'
COLONNES
( numéro_po NUMBER(10) CHEMIN '$.PONumber',
référence VARCHAR2(30 CHAR) PATH '$.Reference',
ID utilisateur du VARCHAR2(128 CHAR) PATH '$.Requestor',
demandeur VARCHAR2(10 CHAR) PATH '$.User', VARCHAR2(16)
centre de coûts CHEMIN '$.CostCenter',
ship_to_name VARCHAR2(20 CHAR)
PATH '$.ShippingInstructions.name', ship_to_street
VARCHAR2(32 CHAR)
PATH '$.ShippingInstructions.Address.street', VARCHAR2(32
ship_to_city CHAR)
PATH '$.ShippingInstructions.Address.city', ship_to_county
VARCHAR2(32 CHAR)
PATH '$.ShippingInstructions.Address.county', ship_to_postcode
VARCHAR2(10 CHAR)
PATH '$.ShippingInstructions.Address.postcode', VARCHAR2(2
ship_to_state CHAR)
PATH '$.ShippingInstructions.Address.state', VARCHAR2(8
ship_to_zip CHAR)
PATH '$.ShippingInstructions.Address.zipCode', ship_to_country
VARCHAR2(32 CHAR)
PATH '$.ShippingInstructions.Address.country', VARCHAR2(24
ship_to_phone CHAR)
CHEMIN '$.ShippingInstructions.Phone[0].number', CHEMIN NICHÉ
'$.LineItems[*]'
COLUMNS
( articleno NUMBER(38) CHEMIN '$.ItemNumber',
description VARCHAR2(256 CHAR) PATH '$.Part.Description', VARCHAR2(14
CHAR) PATH '$.Part.UPCCode', upc_code quantité NUMBER(12,4)
prix unitaire NUMBER(14,2 )
PATH '$.Quantity', PATH
'$.Part.UnitPrice'))) d ;
Exemple 178 Création d'une vue matérialisée sur des données JSON
CRÉER OU REMPLACER UNE VUE MATÉRIALISÉE j_purchaseorder_materialized_view
CONSTRUIRE IMMÉDIATEMENT
REFRESH FAST ON COMMIT AVEC LA CLÉ PRIMAIRE
AS SELECT d.*
COLONNES
( numéro_po NUMBER(10) CHEMIN '$.PONumber',
référence VARCHAR2(30 CHAR) PATH '$.Reference',
ID utilisateur du VARCHAR2(128 CHAR) PATH '$.Requestor',
demandeur VARCHAR2(10 CHAR) PATH '$.User', VARCHAR2(16)
centre de coûts CHEMIN '$.CostCenter',
ship_to_name VARCHAR2(20 CHAR)
PATH '$.ShippingInstructions.name', ship_to_street
VARCHAR2(32 CHAR)
PATH '$.ShippingInstructions.Address.street', VARCHAR2(32
ship_to_city CHAR)
PATH '$.ShippingInstructions.Address.city', ship_to_county
VARCHAR2(32 CHAR)
PATH '$.ShippingInstructions.Address.county', ship_to_postcode
VARCHAR2(10 CHAR)
PATH '$.ShippingInstructions.Address.postcode', VARCHAR2(2
ship_to_state CHAR)
PATH '$.ShippingInstructions.Address.state', VARCHAR2(8
ship_to_zip CHAR)
PATH '$.ShippingInstructions.Address.zipCode', ship_to_country
VARCHAR2(32 CHAR)
PATH '$.ShippingInstructions.Address.country', VARCHAR2(24
ship_to_phone CHAR)
CHEMIN '$.ShippingInstructions.Phone[0].number', CHEMIN NICHÉ
'$.LineItems[*]'
COLUMNS
( articleno NUMBER(38) CHEMIN '$.ItemNumber',
description VARCHAR2(256 CHAR) PATH '$.Part.Description', VARCHAR2(14
CHAR) PATH '$.Part.UPCCode', upc_code quantité NUMBER(12,4)
prix unitaire NUMBER(14,2 )
PATH '$.Quantity', PATH
'$.Part.UnitPrice'))) d ;
18
Guide des données JSON
Un guide de données JSON vous permet de découvrir des informations sur la structure et le contenu des documents
JSON stockés dans Oracle Database.
Voici quelques façons d'utiliser ces informations :
• Génération d'un document JSON Schema qui décrit l'ensemble des documents JSON.
• Créer des vues que vous pouvez utiliser pour effectuer des opérations SQL sur les données du
documents.
• Ajout ou mise à jour automatique des colonnes virtuelles correspondant aux champs ajoutés ou modifiés dans les
documents.
Les sujets
Voir également:
• Schéma JSON : définitions et terminologie de base jsonschemacore
• Schéma JSON : validation interactive et non interactive
Présentation du guide de données JSON (page 182)
Un guide de données est un résumé des informations structurelles et de type contenues
dans un ensemble de documents JSON. Il enregistre des métadonnées sur les champs utilisés
dans ces documents.
Informations de guide de données persistantes : partie d'un index de recherche JSON (page 184)
Les informations du guide de données JSON peuvent être enregistrées de manière persistante
dans le cadre de l'infrastructure d'index de recherche JSON, et ces informations sont mises à
jour automatiquement à mesure que du nouveau contenu JSON est ajouté. C'est le cas par défaut,
lorsque vous créez un index de recherche JSON : les informations du guide de données font partie
de l'infrastructure de l'index.
Formats de guide de données et méthodes de création d'un guide de données (page 186)
Il existe deux formats pour un guide de données : plat et hiérarchique. Les deux sont mis à la
disposition de SQL et PL/SQL en tant que données CLOB. Vous pouvez créer un guide de
données à partir des informations de guide de données stockées dans un index de recherche
JSON ou en numérisant des documents JSON.
Champs du guide de données JSON (page 188)
Les champs prédéfinis d'un guide de données JSON sont décrits. Ils incluent des champs de
schéma JSON (mots clés) et des champs spécifiques à Oracle.
Guide des données JSON 181
Présentation du guide de données JSON
Spécification d'un nom préféré pour une colonne de champ (page 1811)
Vous pouvez projeter des champs JSON à partir de vos données sous forme de colonnes dans une
vue de base de données ou sous forme de colonnes virtuelles ajoutées à la même table qui contient
la colonne JSON. Vous pouvez spécifier un nom préféré pour une telle colonne.
Création d'une vue sur les données JSON basée sur les informations du guide de données (page
1812)
Sur la base des informations du guide de données, vous pouvez créer une vue de base de données dont
les colonnes projettent des champs scalaires particuliers présents dans un ensemble de documents
JSON. Vous pouvez choisir les champs à projeter en éditant un guide de données hiérarchique ou en
spécifiant une expression de chemin SQL/JSON et une fréquence minimale d'occurrence de champ.
Ajout et suppression de colonnes virtuelles pour les champs JSON en fonction des informations du guide de
données (page 1819)
En fonction des informations du guide de données pour une colonne JSON, vous pouvez projeter
des champs scalaires à partir de ces données JSON en tant que colonnes virtuelles dans la même table.
Les champs scalaires projetés sont ceux qui ne sont pas sous un tableau.
Modifier les déclencheurs pour l'index de recherche activé par le guide de données (page 1826)
Lorsque les données JSON changent, certaines informations d'un index de recherche JSON
compatible avec le guide de données sont automatiquement mises à jour. Vous pouvez spécifier
une procédure dont l'invocation est déclenchée chaque fois que cela se produit. Vous pouvez définir
votre propre procédure PL/SQL pour cela, ou vous pouvez utiliser la procédure de déclenchement de
modification prédéfinie add_vc.
Plusieurs guides de données par jeu de documents (page 1829)
Un guide de données reflète la forme d'un ensemble donné de documents JSON. Si une colonne
JSON contient différents types de documents, avec des informations de structure ou de type
différentes, vous pouvez créer et utiliser différents guides de données pour les différents types de
documents.
Interrogation d'un guide de données (page 1833)
Un guide de données est une information sur un ensemble de documents JSON. Vous pouvez
l'interroger à partir d'un guide de données plat que vous obtenez à l'aide de la fonction Oracle SQL
json_dataguide ou de la fonction PL/SQL DBMS_JSON.get_index_dataguide. Dans ce dernier cas, un
index de recherche JSON activé pour le guide de données doit être défini sur les données JSON.
Un guide de données plates pour les documents de bon de commande (page 1835)
Les champs d'un exemple de guide de données plates sont décrits. Il correspond à un ensemble de
documents de bon de commande.
Un guide de données hiérarchiques pour les documents de bon de commande (page 1840)
Les champs d'un exemple de guide de données hiérarchiques sont décrits. Il correspond
à un ensemble de documents de bon de commande.
18.1 Présentation du guide de données JSON
Un guide de données est un résumé des informations structurelles et de type contenues dans un ensemble de documents
JSON. Il enregistre des métadonnées sur les champs utilisés dans ces documents.
Par exemple, pour l'objet JSON présenté dans l' exemple 21 (page 23), un guide de données précise que le document
possède, entre autres, un objet ShippingInstructions avec les champs name, Address et Phone, de types string, object ,
et tableau, respectivement. La structure de l'objet Address est enregistrée de la même manière, tout comme les types
des éléments du tableau Phone.
Présentation du guide de données JSON
Les informations du guide de données JSON peuvent être enregistrées de manière persistante dans le cadre de
l'infrastructure d'index de recherche JSON, et ces informations sont mises à jour automatiquement à mesure que du
nouveau contenu JSON est ajouté. C'est le cas par défaut, lorsque vous créez un index de recherche JSON : les
informations du guide de données font partie de l'infrastructure de l'index.
Vous pouvez utiliser un guide de données :
• Comme base pour le développement d'applications qui impliquent l'exploration de données,
renseignement ou autre analyse de documents JSON.
• Comme base pour fournir une assistance à l'utilisateur concernant les informations JSON demandées, y compris la
recherche.
• Pour vérifier ou manipuler de nouveaux documents JSON avant de les ajouter à un ensemble de documents (par exemple :
valider, vérifier le type ou exclure certains champs).
À ces fins, vous pouvez :
• Interrogez directement un guide de données pour obtenir des informations sur l'ensemble de documents, telles que le champ
longueurs ou quels champs apparaissent avec au moins une certaine fréquence.
• Créez des vues ou ajoutez des colonnes virtuelles qui projettent des champs JSON d'intérêt particuliers, en fonction
de leur importance selon un guide de données.
Noter:
• Les avantages des colonnes virtuelles par rapport à une vue sont que vous pouvez créer un index sur une
colonne virtuelle et obtenir des statistiques sur celleci pour l'optimiseur.
• Les colonnes virtuelles, comme les colonnes en général, sont soumises à la limite de 1000 colonnes pour une
table donnée.
Les vues du dictionnaire de données enregistrent les colonnes qui ont un guide de données persistant
Renseignements
Les vues de dictionnaire de données statiques suivantes sont définies. Vous pouvez les interroger pour voir quelles
tables ont des colonnes JSON qui ont des index de recherche JSON activés par le guide de données.
Les points de vue diffèrent selon l'inclusion de ces tableaux. Les tables qui n'ont pas de colonnes JSON avec des index activés
par le guide de données ne sont pas présentes dans les vues.
• USER_JSON_DATAGUIDES : tables appartenant à l'utilisateur actuel
• ALL_JSON_DATAGUIDES – tables accessibles par l'utilisateur actuel
• DBA_JSON_DATAGUIDES : toutes les tables
Chaque vue comporte des colonnes TABLE_NAME (le nom de la table), COLUMN_NAME (le nom de la colonne JSON)
et DATAGUIDE (un guide de données). Les vues ALL_JSON_DATAGUIDE et DBA_JSON_DATAGUIDES ont également
la colonne OWNER, dont la valeur est le propriétaire de la table.
Si la colonne JSON a un index de recherche JSON activé par le guide de données, la valeur de la colonne DATAGUIDE
est le guide de données pour la colonne JSON, au format plat en tant qu'instance CLOB. S'il n'a pas d'index activé par le
guide de données, il n'y a pas de ligne pour cette colonne dans la vue.
Informations de guide de données persistantes : partie d'un index de recherche JSON
Voir également:
• Index de recherche JSON : requêtes ad hoc et recherche de texte intégral (page 249)
• Interrogation d'un guide de données (page 1833)
• Création d'une vue sur les données JSON basée sur un guide de données hiérarchiques
(pages 1814)
• Ajout et suppression de colonnes virtuelles pour les champs JSON basés sur des données
Informations sur le guide (pages 1819)
• Oracle Database Reference et les vues de dictionnaire de données associées
• Oracle Database PL/SQL Packages and Types Reference pour plus d'informations sur
DBMS_JSON.get_index_dataguide
• Oracle Database SQL Language Reference pour plus d'informations sur la fonction SQL json_dataguide
18.2 Informations de guide de données persistantes : partie d'un index de recherche JSON
Les informations du guide de données JSON peuvent être enregistrées de manière persistante dans le cadre de
l'infrastructure d'index de recherche JSON, et ces informations sont mises à jour automatiquement à mesure que du nouveau
contenu JSON est ajouté. C'est le cas par défaut, lorsque vous créez un index de recherche JSON : les informations du
guide de données font partie de l'infrastructure de l'index.
Vous pouvez utiliser CREATE SEARCH INDEX avec les mots clés FOR JSON pour créer un index de recherche, un guide de
données ou les deux en même temps. Le comportement par défaut consiste à créer les deux.
Pour créer des informations de guide de données persistantes dans le cadre d'un index de recherche JSON sans activer la
prise en charge de la recherche dans l'index, vous spécifiez SEARCH_ON NONE dans la clause PARAMETERS pour
CREATE SEARCH INDEX, mais vous laissez la valeur de DATAGUIDE sur ON (la valeur par défaut) . L'exemple 181
(page 186) illustre cela.
Vous pouvez utiliser ALTER INDEX ... REBUILD pour activer ou désactiver la prise en charge du guide de données pour un index
de recherche JSON existant . L'exemple 182 (page 186) illustre cela — il désactive la prise en charge du guide de données qui
est ajoutée par défaut dans l' exemple 2417 (page 2410).
Noter:
Pour créer un index de recherche JSON compatible avec le guide de données ou pour activer le guide de données
d'un index de recherche JSON existant, vous avez besoin du privilège de base de données CTXAPP.
Étant donné que les informations persistantes du guide de données font partie de l'infrastructure de l'index de recherche, elles
sont toujours actives : leur contenu est automatiquement mis à jour chaque fois que l'index est synchronisé. Les modifications
des données indexées sont reflétées dans l'index de recherche, y compris dans ses informations de guide de données, uniquement
après la synchronisation de l'index.
De plus, la mise à jour des informations du guide de données dans un index de recherche est toujours additive : rien n'est
jamais supprimé. C'est une autre raison pour laquelle l'index ne reflète souvent pas avec précision les données de son
ensemble de documents : les suppressions dans les documents auxquels il s'applique ne sont pas reflétées dans les
informations de son guide de données. Si vous devez vous assurer que ces informations reflètent fidèlement les données
actuelles, vous devez supprimer l'index de recherche JSON et le recréer.
Informations de guide de données persistantes : partie d'un index de recherche JSON
Les informations persistantes du guide de données dans un index de recherche peuvent également inclure des
statistiques, telles que la fréquence d'utilisation de chaque champ JSON dans l'ensemble de documents. Les
statistiques ne sont présentes que si vous les collectez explicitement sur l'ensemble de documents (regroupezles
sur l'index de recherche JSON, par exemple). Ils ne sont pas mis à jour automatiquement. Recueillez de nouvelles
statistiques si vous voulez vous assurer qu'elles sont à jour. L'exemple 183 (page 186) collecte des statistiques sur
les données JSON indexées par l'index de recherche JSON po_search_idx, qui est créé dans l' exemple 2417 (page
2410).
Noter:
Lorsqu'un index de recherche JSON compatible avec le guide de données local est créé dans un
environnement de partitionnement , chaque partition individuelle contient les informations de guide de
données pour les documents JSON stockés dans cette partition. Pour cette raison, si vous appelez des
opérations liées au guide de données sur la base de données du catalogue de partitions , elles n'auront
aucun effet.
Considérations relatives à un index de recherche activé par Data Guide sur une table partitionnée
Les informations de guide de données dans un index de recherche JSON activé par guide de données qui est local
à une table partitionnée ne sont pas partitionnées. Il est partagé entre toutes les partitions.
Étant donné que les informations du guide de données dans l'index sont uniquement additives, la suppression, la
fusion, le fractionnement ou la troncation des partitions n'a aucun impact sur l'index.
L'échange d'une table partitionnée avec une table qui n'est pas partitionnée met à jour les informations du guide
de données dans un index sur la table partitionnée, mais tout index activé par le guide de données sur la table
non partitionnée doit être reconstruit.
Évitez les informations de guide de données persistantes si vous sérialisez des données de table de
hachage Si vous sérialisez des tables de hachage Java ou des tableaux associatifs (tels que ceux trouvés dans
JavaScript) en tant qu'objets JSON, évitez d'utiliser des informations de guide de données persistantes.
La sérialisation de table de hachage par défaut fournie par les bibliothèques populaires telles que GSON et Jackson
produit des documents textuels JSON avec des noms de champ d'objet tirés des entrées de clé de table de hachage
et avec des valeurs de champ tirées des valeurs de table de hachage Java correspondantes. La sérialisation d'une
seule entrée de table de hachage Java produit un nouveau (unique)
Champ et valeur JSON.
Les informations persistantes du guide de données reflètent la forme de vos données et sont mises à jour
automatiquement lorsque de nouveaux documents JSON sont insérés. Chaque paire clévaleur de table de
hachage génère une entrée distincte dans l'index de recherche JSON. Une telle sérialisation peut ainsi augmenter
considérablement la taille des informations conservées dans l'index. En plus de la grande taille, les nombreuses
mises à jour d'index affectent négativement les performances, ralentissant DML.
Si vous sérialisez une table de hachage ou un tableau associatif à la place en tant que tableau JSON d'objets, dont
chacun inclut un champ dérivé d'une entrée de clé de table de hachage, alors il n'y a pas de tels problèmes.
La sérialisation par défaut d'une table de hachage ou d'un tableau associatif en tant qu'objet JSON est
indiscernable d'un objet dont les noms de champ sont attribués par un développeur. Un guide de données JSON ne
peut pas dire quels noms de champ (de type métadonnées) ont été attribués par un développeur et quels noms (de
type données) pourraient avoir été dérivés d'une table de hachage ou d'un tableau associatif. Il traite tous les noms
de champs comme essentiellement des métadonnées, comme s'ils étaient spécifiés par un développeur.
Par exemple:
Formats de guide de données et façons de créer un guide de données
•
Si vous construisez un objet d'application à l'aide d'une table de hachage qui a animalName comme clé de
hachage et des ensembles de propriétés animales comme valeurs, la sérialisation par défaut résultante est
un seul objet JSON qui a un champ séparé ("cat", "mouse", .. .) pour chaque entrée de table de hachage,
la valeur du champ étant un objet avec les propriétés animales correspondantes. Cela peut être
problématique en termes de taille et de performances du guide de données en raison du nombre
généralement élevé de champs ("cat", "mouse",...) dérivés de la clé de hachage.
• Si vous construisez plutôt un tableau d'application de structures animales, chacune ayant un champ
animalName (avec la valeur "cat" ou "mouse"...), la sérialisation résultante est un tableau JSON d'objets,
chacun ayant le même champ , nomanimal. Le guide de données correspondant n'a aucun problème de
taille ou de performance.
Exemple 181 Activation de la prise en charge persistante pour un guide de données JSON mais pas pour
Chercher
CRÉER UN INDEX DE RECHERCHE po_dg_only_idx SUR j_purchaseorder (po_document) POUR JSON
PARAMÈTRES ('SEARCH_ON AUCUN');
Exemple 182 Désactivation de la prise en charge du guide de données JSON pour une recherche JSON existante
Indice
ALTER INDEX po_search_idx RECONSTRUIRE LES PARAMETRES ('DATAGUIDE OFF');
Exemple 183 Collecte de statistiques sur des données JSON à l'aide d'un index de recherche JSON
EXEC DBMS_STATS.gather_index_stats(docuser, po_search_idx, NULL, 99);
Voir également:
• Index de recherche JSON : requêtes ad hoc et recherche de texte intégral (page 249)
• Oracle Text Reference pour plus d'informations sur la clause PARAMETERS pour
CRÉER UN INDEX DE RECHERCHE
• Oracle Text Reference pour d'autres exemples d'utilisation de CREATE SEARCH
INDEX pour créer un index de recherche compatible avec le guide de données
MODIFIER L'INDEX... RECONSTRUIRE
• XML/Jackson plus rapide pour plus d'informations sur le processeur Jackson JSON
• google/gson pour plus d'informations sur la bibliothèque Java GSON
18.3 Formats de guide de données et façons de créer un guide de données
Il existe deux formats pour un guide de données : plat et hiérarchique. Les deux sont mis à la disposition de SQL
et PL/SQL en tant que données CLOB. Vous pouvez créer un guide de données à partir des informations de guide
de données stockées dans un index de recherche JSON ou en numérisant des documents JSON.
• Vous pouvez utiliser un guide de données plat pour interroger les informations du guide de données telles que les
fréquences et les types de champs.
Un guide de données plat est représenté dans JSON sous la forme d'un tableau d'objets, chacun
représentant les données JSON d'un chemin spécifique dans l'ensemble de documents. Un guide de
données plates pour les documents de bon de commande (page 1835) décrit un guide de données plates
pour les données de bon de commande de l' exemple 21 (page 23).
Formats de guide de données et façons de créer un guide de données
• Vous pouvez utiliser un guide de données hiérarchique pour créer une vue, ou pour ajouter des colonnes virtuelles,
en utilisant des champs particuliers que vous choisissez sur la base des informations du guide de données.
Un guide de données hiérarchique est représenté en JSON sous la forme d'un objet avec des données JSON
imbriquées, au même format que celui défini par JSON Schema (version 4, jsonschema core). Un guide de
données hiérarchiques pour les documents de bon de commande (page 1840) décrit un guide de données
hiérarchique pour les données de bon de commande de l' exemple 21 (page 23).
Vous utilisez la fonction PL/SQL DBMS_JSON.get_index_dataguide pour obtenir un guide de données à partir
des informations de guide de données stockées dans un index de recherche JSON.
Vous pouvez également utiliser la fonction d'agrégation SQL json_dataguide pour analyser votre ensemble de
documents et créer un guide de données pour celuici, qu'il ait ou non un index de recherche activé par le guide de
données. Le guide de données reflète avec précision l'ensemble de documents au moment de l'invocation de la fonction.
Tableau 181 Fonctions SQL et PL/SQL pour obtenir un guide de données
Utilise les données Guide des données plates Guide des données hiérarchiques

Guide
Index de
recherche
activé ?
Oui Fonction PL/SQL Fonction PL/SQL

get_index_dataguide au format get_index_dataguide au format
DBMS_JSON.FORMAT_FLAT DBMS_JSON.FORMAT_HIERARCHICAL
Non Fonction SQL json_dataguide N'est pas applicable
Les avantages d'obtenir un guide de données basé sur un index de recherche JSON compatible avec le guide de
données incluent :
• Les mises à jour supplémentaires du jeu de documents sont automatiquement répercutées dans le fichier persistant.
informations du guide de données chaque fois que l'index est synchronisé.
• Étant donné que ces informations de guide de données sont persistantes, l'obtention d'un guide de données basé
sur cellesci (à l'aide de la fonction PL/SQL get_index_dataguide) est plus rapide que l'obtention d'un guide de
données en analysant l'ensemble de documents (à l'aide de la fonction SQL json_dataguide).
•
Si vous avez rassemblé des statistiques sur l'ensemble de documents, cellesci sont incluses dans les
informations stockées et dans un guide de données obtenu à partir de celuici.
• Les conflits de nom de colonne rencontrés lors de la création d'une vue ou de colonnes virtuelles sont automatiquement
résolus.
Les avantages d'obtenir un guide de données sans utiliser un index de recherche JSON compatible avec le
guide de données incluent l'assurance que le guide de données est précis et l'absence de surcharge de maintenance
de l'index. De plus, un guide de données qui n'est pas dérivé d'un index est approprié dans certains cas d'utilisation
particuliers :
• Les données JSON se trouvent dans une table externe. Vous ne pouvez pas créer d'index dessus.
• La colonne JSON pourrait être indexée, mais l'index ne serait pas très utile. Cela peut être le cas, par exemple, si la
colonne contient différents types de documents.
Dans ce cas, il peut parfois être utile d'ajouter une colonne au tableau qui identifie le type de document stocké
dans la colonne JSON. Vous pouvez ensuite utiliser le guide des données
Champs du guide de données JSON
avec les fonctions d'agrégation SQL et GROUP BY. Voir Guides de données multiples par jeu de
documents (page 1829).
Voir également:
• Un guide de données plates pour les documents de bon de commande (page 1835)
• Un guide de données hiérarchiques pour les documents de bon de commande (page 1840)
• Informations de guide de données persistantes : partie d'un index de recherche JSON
(pages 184)
• Oracle Database SQL Language Reference pour plus d'informations sur la fonction SQL
json_dataguide
• Oracle Database SQL Language Reference pour plus d'informations sur les constantes PL/
SQL DBMS_JSON.FORMAT_FLAT et DBMS_JSON.FORMAT_HIERARCHICAL
18.4 Champs du guide de données JSON
Les champs prédéfinis d'un guide de données JSON sont décrits. Ils incluent des champs de schéma JSON
(mots clés) et des champs spécifiques à Oracle.
Une occurrence donnée d'un champ dans un guide de données correspond à un champ présent dans un
ou plusieurs documents JSON de l'ensemble de documents.
Champs de schéma JSON (mots clés)
Un schéma JSON est un document JSON qui contient un objet JSON, qui peut luimême contenir des
objets enfants (sousschémas). Les champs définis par JSON Schema sont appelés motsclés JSON Schema.
Tableau 182 (page 188) décrit les motsclés pouvant être utilisés dans un guide de données Oracle JSON.
Les propriétés des motsclés, les éléments et oneOf sont utilisés uniquement dans un guide de données
JSON hiérarchique (qui est un schéma JSON). Le type de motclé est utilisé dans les guides de données plats
et hiérarchiques.
Tableau 182 Champs de schéma JSON (mots clés)
Champ (mot clé) Description de la valeur
Propriétés Objet dont les membres représentent les propriétés d'un objet JSON utilisé dans les
données JSON représentées par le guide de données hiérarchique (schéma JSON).
éléments Objet dont les membres représentent les éléments (items) d'un tableau utilisé dans
les données JSON représentées par le guide de données hiérarchique (schéma
JSON).
un des Un tableau dont chacun des éléments représente une ou plusieurs occurrences d'un
champ JSON dans les données JSON représentées par le guide de données
hiérarchique (schéma JSON).
Tableau 182 (suite) Champs de schéma JSON (mots clés)
Champ (mot clé) Description de la valeur
taper Une chaîne nommant le type de certaines données JSON représentées par le guide de
données (plat ou hiérarchique).
Les valeurs possibles sont : "number", "string", "boolean", "null", "object" et "array".
Champs du guide de données JSON spécifiques à Oracle
Outre les mots clés du schéma JSON, un guide de données JSON peut contenir des champs spécifiques au
guide de données Oracle. Les noms de champs ont tous le préfixe o:. Ils sont décrits dans le Tableau 183
(page 189).
Tableau 183 Champs du guide de données spécifiques à Oracle
Domaine Description de la valeur
o :chemin Chemin à travers les documents JSON jusqu'au champ JSON. Utilisé
uniquement dans un guide de données plat . La valeur est une simple
expression de chemin SQL/JSON (pas d'expression de filtre), éventuellement
avec assouplissement (encapsulation et désencapsulation de tableau
implicites), mais sans étapes de tableau ni étape de fonction. Voir Syntaxe
d'expression de chemin SQL/JSON (page 122).
o : longueur Longueur maximale de la valeur du champ JSON, en octets. La valeur
est toujours une puissance de deux. Par exemple, si la longueur
maximale de toutes les valeurs de champ réelles est 5, la valeur de
o:length est 8, la plus petite puissance de deux supérieure ou égale à 5.
o:preferred_column_name Un identifiant, sensible à la casse et unique à une donnée donnée
guide, que vous préférez comme nom à utiliser pour une colonne
de vue ou une colonne virtuelle créée à l'aide du guide de données.
Ce champ est absent si le guide de données a été obtenu à l'aide de la
fonction SQL json_dataguide.
o : fréquence Pourcentage de documents JSON contenant le champ donné.
Les occurrences en double d'un champ sous le même tableau sont
ignorées. (Disponible uniquement si des statistiques ont été recueillies sur
l'ensemble de documents.)
o:num_nulls Nombre de documents dont la valeur pour le champ scalaire ciblé est JSON
null. (Disponible uniquement si des statistiques ont été recueillies sur
l'ensemble de documents.)
Tableau 183 (suite) Champs du guide de données spécifiques à Oracle
Domaine Description de la valeur
o : valeur_élevée Valeur la plus élevée pour le champ scalaire ciblé, parmi tous les
documents. (Disponible uniquement si des statistiques ont été recueillies
sur l'ensemble de documents.)
o : valeur_faible Valeur la plus basse pour le champ scalaire ciblé, parmi tous les
documents. (Disponible uniquement si des statistiques ont été recueillies
o : dernier_analyse Date et heure auxquelles les statistiques ont été recueillies pour la dernière fois sur
l'ensemble de documents. (Disponible uniquement si des statistiques ont été recueillies
Lorsqu'elle est présente, la valeur par défaut du champ o:preferred_column_name est la même que
le nom de champ JSON correspondant, précédée du nom de colonne JSON suivi de $, et avec tous
les caractères non ASCII supprimés. Si le nom de champ résultant existe déjà dans le même guide
de données, il est suffixé d'un nouveau numéro de séquence pour le rendre unique.
Le nom de la colonne est en majuscule sauf si la colonne a été définie à l'aide de lettres
minuscules échappées (par exemple, 'PO_Column' au lieu de po_column). Par exemple, la valeur
par défaut du champ Utilisateur pour les données de la colonne JSON po_document est
PO_DOCUMENT$User.
Vous pouvez utiliser la procédure PL/SQL DBMS_JSON.rename_column pour définir la valeur
de o:preferred_column_name pour un champ et un type donnés.
Le champ o:preferred_column_name est utilisé pour nommer une nouvelle colonne virtuelle
dans la table qui contient la colonne JSON, ou il est utilisé pour nommer une colonne dans une
nouvelle vue qui contient également les autres colonnes de la table. Dans les deux cas, le nom
spécifié par o:preferred_column_name doit être unique par rapport aux autres noms de colonne de
la table. De plus, le nom doit être unique dans tous les champs JSON de tout type dans l'ensemble
de documents. DBMS_JSON.get_index_dataguide garantit que le nom par défaut est unique de ces
manières.
Si le nom que vous spécifiez avec DBMS_JSON.rename_column provoque un conflit de nom, le
nom spécifié est ignoré et un nom généré par le système est utilisé à la place.
Spécification d'un nom préféré pour une colonne de champ
Voir également:
• Spécification d'un nom préféré pour une colonne de champ (page 1811)
• Un guide de données plates pour les documents de bon de commande (page 1835)
• Un guide de données hiérarchiques pour les documents de bon de commande (page 1840)
DBMS_JSON.rename_column
• Oracle Database SQL Language Reference pour plus d'informations sur la fonction SQL
json_dataguide
18.5 Spécification d'un nom préféré pour une colonne de champ
Vous pouvez projeter des champs JSON à partir de vos données sous forme de colonnes dans une vue de
base de données ou sous forme de colonnes virtuelles ajoutées à la même table qui contient la colonne JSON.
Vous pouvez spécifier un nom préféré pour une telle colonne.
Un guide de données obtenu à partir du même jeu de documents est utilisé pour définir cette projection.
Le nom de chaque colonne projetée est extrait du champ de guide de données
o:preferred_column_name pour le champ de données JSON à projeter. La spécification de votre nom préféré
modifie la valeur de ce champ de guide de données.
Si vos données JSON ont un index de recherche activé par le guide de données, vous pouvez utiliser la procédure
DBMS_JSON.rename_column pour spécifier votre nom préféré pour la colonne projetée à partir d'un champ donné.
L'exemple 184 (page 1812) illustre cela. Il spécifie les noms préférés des colonnes à projeter à partir de divers
champs, comme décrit dans le Tableau 184 (page 1811). (Les champs sont projetés sous forme de colonnes
lorsque vous utilisez la procédure DBMS_JSON.create_view, DBMS_JSON.create_view_on_path ou
DBMS_JSON.add_virtual_columns.)
Tableau 184 Noms préférés pour certaines colonnes de champ JSON
Domaine Colonne préférée de type JSON
Nom
POnuméro Numéro POnuméro
Téléphone (téléphone sous forme de chaîne, pas d'objet juste le numéro) chaîne de caractères Téléphone
type (type de téléphone) chaîne de caractères Type de téléphone
numéro (numéro de téléphone) chaîne de caractères Numéro de téléphone
ItemNumber (numéro d'article) Numéro Numéro d'article
Description (description de la pièce) chaîne de caractères DescriptionPartie
Création d'une vue sur les données JSON basée sur les informations du guide de données
Voir également:
• Champs du guide de données JSON (page 188) pour plus d'informations sur les
valeur du champ o:preferred_column_name et la possibilité de conflits de noms lorsque vous
utilisez DBMS_JSON.rename_column
• Création d'une vue sur les données JSON basée sur les informations du guide de données
(pages 1812)
• Création d'une table avec une colonne JSON (page 41) pour plus d'informations sur les données
JSON référencées ici
DBMS_JSON.create_view
DBMS_JSON.create_view_on_path
• Oracle Database PL/SQL Packages and Types Referencepour plus d'informations sur
DBMS_JSON.add_virtual_columns
Exemple 184 Spécification des noms de colonne préférés pour certains champs JSON
COMMENCER
DBMS_JSON.rename_column(
'J_PURCHASEORDER', 'PO_DOCUMENT', '$.PONumber',
DBMS_JSON.TYPE_NUMBER, 'PONumber');
DBMS_JSON.rename_column( 'J_PURCHASEORDER', 'PO_DOCUMENT',
'$.ShippingInstructions.Phone', DBMS_JSON.TYPE_STRING, 'Phone');
DBMS_JSON.rename_column(
'J_PURCHASEORDER', 'PO_DOCUMENT', '$.ShippingInstructions.Phone.type',
DBMS_JSON.TYPE_STRING, 'PhoneType'); DBMS_JSON.rename_column(
'J_PURCHASEORDER', 'PO_DOCUMENT', '$.ShippingInstructions.Phone.number',
DBMS_JSON.TYPE_STRING, 'PhoneNumber'); DBMS_JSON.rename_column( 'J_PURCHASEORDER',
'PO_DOCUMENT', '$.LineItems.ItemNumber', DBMS_JSON.TYPE_NUMBER, 'ItemNumber');
DBMS_JSON.rename_column( 'J_PURCHASEORDER', 'PO_DOCUMENT',
'$.LineItems.Part.Description', DBMS_JSON.TYPE_STRING, 'PartDescription'); FIN; /
18.6 Création d'une vue sur les données JSON basée sur les informations du guide de données
Sur la base des informations du guide de données, vous pouvez créer une vue de base de données dont
les colonnes projettent des champs scalaires particuliers présents dans un ensemble de documents JSON. Vous
pouvez choisir les champs à projeter en éditant un guide de données hiérarchique ou en spécifiant une expression
de chemin SQL/JSON et une fréquence minimale d'occurrence de champ.
(Vous pouvez créer plusieurs vues basées sur le même ensemble de documents JSON, projetant différents
champs. Voir Guides de données multiples par ensemble de documents (page 1829).)
Vous pouvez créer une vue en projetant des champs JSON à l'aide de la fonction SQL/JSON json_table
— voir Création d'une vue sur des données JSON à l'aide de JSON_TABLE (page 176). Une alternative
consiste à utiliser la procédure PL/SQL DBMS_JSON.create_view ou DBMS_JSON.create_view_on_path pour
créer une vue en projetant les champs que vous choisissez en fonction des informations disponibles du guide de
données.
Ces informations peuvent provenir soit d'un guide de données hiérarchique qui inclut uniquement les champs à projeter,
soit d'un index de recherche JSON compatible avec le guide de données avec une expression de chemin SQL/JSON
et une fréquence de champ minimale.
Dans le premier cas, utilisez la procédure create_view. Vous pouvez modifier un guide de données (hiérarchique)
pour spécifier les champs souhaités. Dans ce cas, vous n'avez pas besoin d'un index de recherche compatible avec le
guide de données.
Dans ce dernier cas, utilisez la procédure create_view_on_path. Dans ce cas, vous avez besoin d'un index de recherche
compatible avec le guide de données, mais vous n'avez pas besoin d'un guide de données. Vous fournissez une
expression de chemin SQL/JSON et éventuellement une fréquence d'occurrence minimale. Les champs de l'ensemble
de documents qui sont projetés incluent à la fois :
• Tous les champs scalaires qui ne sont pas sous un tableau.
• Tous les champs scalaires présents, à n'importe quel niveau, dans les données ciblées par une expression de
chemin SQL/JSON donnée.
Quelle que soit la manière dont vous créez la vue, en plus des champs JSON qui sont projetés sous forme de
colonnes, les colonnes non JSON de la table sont également des colonnes de la vue.
Si vous utilisez la procédure create_view_on_path, l'argument PATH que vous fournissez doit être une simple
expression de chemin SQL/JSON (pas d'expression de filtre), éventuellement avec assouplissement (encapsulation
et désencapsulation implicites du tableau), mais sans étapes de tableau ni étape de fonction. Voir Syntaxe d'expression
de chemin SQL/JSON (page 122).
Quelle que soit la manière dont il est créé, le guide de données qui sert de base à une définition de vue
donnée est statique et ne reflète pas nécessairement fidèlement les données actuelles de l'ensemble de
documents. Les champs projetés pour la vue sont déterminés lors de la création de la vue.
En particulier, si vous utilisez create_view_on_path (qui nécessite un index de recherche activé par le guide
de données), ce qui compte, ce sont les champs spécifiés par l'expression de chemin donnée et qui ont au
moins la fréquence donnée, en fonction des données d'index au moment de la création de la vue .
Les sujets
Voir également:
• Création d'une vue sur les données JSON basée sur un guide de données hiérarchiques
(pages 1814)
• Création d'une vue sur les données JSON basée sur une expression de chemin (page
1816)
• Création d'une vue sur les données JSON à l'aide de JSON_TABLE (page 176)
Création d'une vue sur les données JSON basée sur un guide de données hiérarchiques (page
1814)
Vous pouvez utiliser un guide de données hiérarchique pour créer une vue de base de données
dont les colonnes projettent des champs JSON spécifiés à partir de vos documents. Les champs
projetés sont ceux du guide de données. Vous pouvez modifier le guide de données pour inclure
uniquement les champs que vous souhaitez projeter.
Création d'une vue sur les données JSON basée sur une expression de chemin (page 1816)
Vous pouvez utiliser les informations d'un index de recherche JSON compatible avec le guide de
données pour créer une vue de base de données dont les colonnes projettent des champs JSON à
partir de vos documents. Les champs projetés sont les champs scalaires qui ne sont pas sous un
tableau plus les champs scalaires dans les données ciblées par une expression de chemin SQL/
JSON spécifiée.
18.6.1 Création d'une vue sur les données JSON basée sur un guide de données hiérarchiques
Vous pouvez utiliser un guide de données hiérarchique pour créer une vue de base de données dont les colonnes
projettent des champs JSON spécifiés à partir de vos documents. Les champs projetés sont ceux du guide de données.
Vous pouvez modifier le guide de données pour inclure uniquement les champs que vous souhaitez projeter.
Vous pouvez obtenir un guide de données hiérarchique à l'aide de la fonction PL/SQL
DBMS_JSON.get_index_dataguide. Pour cela, vous devez définir un index de recherche JSON activé pour
le guide de données sur la colonne de données JSON.
Vous pouvez modifier le guide de données obtenu pour n'inclure que des champs spécifiques, modifier la longueur de
types donnés ou renommer des champs. Le guide de données résultant spécifie les champs des données JSON à
projeter en tant que colonnes de la vue.
Vous utilisez la procédure PL/SQL DBMS_JSON.create_view pour créer la vue.
L'exemple 185 (page 1815) illustre cela.
Voir également:
• Oracle Database SQL Language Reference pour plus d'informations sur PL/SQL
constante DBMS_JSON.FORMAT_HIERARCHICAL
Exemple 185 Création d'une vue à l'aide d'un guide de données obtenu avec
GET_INDEX_DATAGUIDE
Cet exemple crée une vue qui projette tous les champs présents dans le guide de données
hiérarchique obtenu à partir de l'index de recherche JSON activé pour le guide de données sur
la colonne JSON po_document de la table j_purchaseorder. (Les colonnes dont les noms sont
en italique dans la sortie de la commande describe sont celles qui ont été renommées à l'aide
de la procédure PL/SQL DBMS_JSON.rename_column.)
EXEC DBMS_JSON.create_view( 'VIEW1',
'J_PURCHASEORDER',
'PO_DOCUMENT',
DBMS_JSON.get_index_dataguide('J_PURCHASEORDER',
'PO_DOCUMENT',
DBMS_JSON.FORMAT_HIERARCHICAL) );
DÉCRIRE vue1
Nom Nul? Taper

DATE_LOADED HORODATAGE(6) AVEC FUSEAU HORAIRE
IDENTIFIANT
NON NULL RAW(16)
PO_DOCUMENT$Utilisateur VARCHAR2(8)
POnuméro NUMÉRO
PO_DOCUMENT$Référence VARCHAR2(16)
PO_DOCUMENT$Demandeur VARCHAR2(16)
PO_DOCUMENT$Centre de coût VARCHAR2(4)
PO_DOCUMENT$AllowPartialShipment VARCHAR2(4)
PO_DOCUMENT$nom VARCHAR2(16)
Téléphone VARCHAR2(16)
PO_DOCUMENT$ville VARCHAR2(32)
PO_DOCUMENT$état VARCHAR2(2)
PO_DOCUMENT$rue VARCHAR2(32)
PO_DOCUMENT$pays VARCHAR2(32)
PO_DOCUMENT$code postal NUMÉRO
PO_DOCUMENT$Instructionsspéciales VARCHAR2(8)
PO_DOCUMENT$UPCCode NUMÉRO
PO_DOCUMENT$Prix unitaire NUMÉRO
DescriptionPartie VARCHAR2(32)
PO_DOCUMENT$Quantité NUMÉRO
Numéro d'article NUMÉRO
Type de téléphone VARCHAR2(8)
Numéro de téléphone VARCHAR2(16)
18.6.2 Création d'une vue sur les données JSON basée sur une expression de chemin
Vous pouvez utiliser les informations d'un index de recherche JSON compatible avec le guide de données pour créer
une vue de base de données dont les colonnes projettent des champs JSON à partir de vos documents. Les champs
projetés sont les champs scalaires qui ne sont pas sous un tableau plus les champs scalaires dans les données ciblées
par une expression de chemin SQL/JSON spécifiée.
Par exemple, si l'expression de chemin est $, tous les champs scalaires sont projetés, car la racine (haut) du document est
ciblée. L'exemple 186 (page 1817) illustre cela. Si le chemin est $.LineItems.Part, seuls les champs scalaires qui sont
présents (à n'importe quel niveau) dans les données ciblées par $.LineItems.Part sont projetés (en plus des champs
scalaires ailleurs qui ne sont pas sous un tableau). L'exemple 187 (page 1817) illustre cela.
Si vous collectez des statistiques sur votre ensemble de documents JSON, les informations du guide de données dans un
index de recherche JSON compatible avec le guide de données enregistrent la fréquence d'occurrence, dans l'ensemble
de documents, de chaque chemin d'accès à un champ présent dans un document. Lorsque vous créez la vue, vous pouvez
spécifier que seuls les champs (scalaires) avec une fréquence d'occurrence minimale donnée (en pourcentage) doivent
être projetés en tant que colonnes de vue. Pour ce faire, spécifiez une valeur différente de zéro pour le paramètre
FREQUENCY de la procédure DBMS_JSON.create_view_on_path.
Par exemple, si vous spécifiez le chemin comme $ et la fréquence minimale comme 50, tous les champs scalaires (sur
n'importe quel chemin, puisque $ cible l'ensemble du document) qui apparaissent dans au moins la moitié (50 %) des
documents sont projetés. L'exemple 188 (page 1818) illustre cela.
La valeur de l'argument PATH est une simple expression de chemin SQL/JSON (pas d'expression de filtre),
éventuellement avec assouplissement (encapsulation et désencapsulation implicites du tableau), mais sans étapes de
tableau ni étape de fonction. Voir Syntaxe d'expression de chemin SQL/JSON (page 122).
Aucun filtrage de fréquence n'est effectué dans l'un ou l' autre des cas suivants — les champs ciblés sont projetés
quelle que soit leur fréquence d'apparition dans les documents :
• Vous ne collectez jamais d'informations statistiques sur votre ensemble de documents JSON. (Non
les informations de fréquence sont incluses dans l'index de recherche JSON compatible avec le guide de données.)
• L'argument FREQUENCY de DBMS_JSON.create_view_on_path est zéro (0).
Noter:
Lorsque l'argument FREQUENCY est différent de zéro, même si vous avez collecté des informations
statistiques sur votre ensemble de documents, l'index ne contient aucune information statistique pour les
documents ajoutés après la dernière collecte de statistiques. Cela signifie que tous les champs ajoutés
après cette collecte de statistiques sont ignorés (non projetés).
Voir également:
• Expressions de chemin SQL/JSON (page 121)
Exemple 186 Création d'une vue qui projette tous les champs scalaires
Tous les champs scalaires sont représentés dans la vue, car le chemin spécifié est $.
(Les colonnes dont les noms sont en italique dans la sortie de la commande describe sont celles qui
ont été renommées à l'aide de la procédure PL/SQL DBMS_JSON.rename_column.
Les lignes soulignées manquent dans l' exemple 188 (page 1818).)
EXEC DBMS_JSON.create_view_on_path('VIEW2',
'J_PURCHASEORDER',
'PO_DOCUMENT', '$');
DECRIRE vue2 ;
Nom Nul? Taper

IDENTIFIANT
NON NULL RAW(16)
POnuméro NUMÉRO
Type de téléphone VARCHAR2(8)
Numéro de téléphone VARCHAR2(16)
Exemple 187 Création d'une vue qui projette des champs scalaires ciblés par un chemin
Expression
Les champs Itemnumber, PhoneType et PhoneNumber ne sont pas représentés dans la vue.
Les seuls champs qui sont projetés sont les champs scalaires qui ne sont pas sous un tableau
plus ceux qui sont présents (à n'importe quel niveau) dans les données ciblées par $.LineItems.Part
(c'estàdire les champs scalaires dont les chemins commencent par
$.LineItems.Part). (Les colonnes dont les noms sont en italique dans la sortie de la
commande describe sont celles qui ont été renommées à l'aide de la procédure PL/SQL
DBMS_JSON.rename_column.)
SQL> EXEC DBMS_JSON.create_view_on_path('VIEW4',
'J_PURCHASEORDER',
'PO_DOCUMENT',
'$.LineItems.Part');
SQL> DESCRIBE vue4 ;
Nom Nul? Taper

IDENTIFIANT
NON NULL RAW(16)
POnuméro NUMÉRO
Exemple 188 Création d'une vue qui projette des champs scalaires ayant une donnée
Fréquence
Tous les champs scalaires présents dans tous (100 %) des documents sont représentés dans la vue.
Le champ AllowPartialShipment n'apparaît pas dans tous les documents, il n'y a donc pas de colonne
PO_DOCUMENT$AllowPartialShipment dans la vue. De même pour les champs Phone, PhoneType
et PhoneNumber.
ont été renommées à l'aide de la procédure PL/SQL DBMS_JSON.rename_column.)
SQL> EXEC DBMS_JSON.create_view_on_path('VIEW3',
'J_PURCHASEORDER',
'PO_DOCUMENT', '$',
100);
SQL> DESCRIBE vue3 ;
Nom Nul? Taper

IDENTIFIANT
NON NULL RAW(16)
POnuméro NUMÉRO
Ajout et suppression de colonnes virtuelles pour les champs JSON en fonction des informations du guide de données
18.7 Ajout et suppression de colonnes virtuelles pour les champs JSON en fonction des informations du guide des
données En fonction des informations du guide des données pour une colonne JSON, vous pouvez projeter des champs
scalaires à partir de ces données JSON sous forme de colonnes virtuelles dans la même table. Les
champs scalaires projetés sont ceux qui ne sont pas sous un tableau.
Vous pouvez faire tout ce qui suit avec une colonne virtuelle, dans le but d'améliorer les performances :
• Construire un index dessus.
• Recueillez des statistiques à ce sujet pour l'optimiseur.
• Chargezle dans le magasin de colonnes en mémoire (magasin de colonnes IM).
Noter:
Les colonnes virtuelles, comme les colonnes en général, sont soumises à la limite de 1000 colonnes
pour une table donnée.
Vous utilisez la procédure PL/SQL DBMS_JSON.add_virtual_columns pour ajouter des colonnes virtuelles en
fonction des informations du guide de données pour une colonne JSON. Avant d'ajouter des colonnes virtuelles,
la procédure add_virtual_columns supprime d'abord toutes les colonnes virtuelles existantes qui ont été projetées à
partir de champs dans la même colonne JSON par une invocation précédente de add_virtual_columns ou par la
procédure add_vc de déclencheur de changement de guide de données (en effet, elle fait ce que la procédure
DBMS_JSON. drop_virtual_columns le fait).
Il existe deux sources alternatives d'informations de guide de données que vous fournissez à la procédure
add_virtual_columns :
•
Il peut provenir d'un guide de données hiérarchique que vous passez en argument. Tous les champs
scalaires du guide de données qui ne se trouvent pas sous un tableau sont projetés sous forme de colonnes
virtuelles. Tous les autres champs du guide de données sont ignorés (non projetés).
Dans ce cas, vous pouvez modifier le guide de données avant de le transmettre, afin qu'il spécifie les
champs scalaires (pas sous un tableau) que vous souhaitez projeter. Vous n'avez pas besoin d'un index de
recherche compatible avec le guide de données dans ce cas.
• Il peut provenir d'un index de recherche JSON compatible avec le guide de données.
Dans ce cas, vous pouvez spécifier, comme valeur de l'argument FREQUENCE à la procédure
add_virtual_columns, une fréquence minimale d'occurrence pour les champs scalaires à projeter. Dans ce
cas, vous avez besoin d'un index de recherche compatible avec le guide de données, mais vous n'avez pas
besoin d'un guide de données.
Vous pouvez également spécifier que les colonnes virtuelles ajoutées doivent être masquées. La commande
SQL describe ne répertorie pas les colonnes masquées.
•
Si vous passez un guide de données (hiérarchique) à add_virtual_columns, vous pouvez spécifier la projection
de champs scalaires particuliers (pas sous un tableau) en tant que colonnes virtuelles masquées en ajoutant
"o:hidden": true à leurs descriptions dans le guide de données.
• Si vous utilisez un index de recherche JSON compatible avec le guide de données avec add_virtual_columns, vous
pouvez spécifier une valeur PL/SQL TRUE pour l'argument HIDDEN, afin de masquer toutes les colonnes virtuelles
ajoutées. (La valeur par défaut de HIDDEN est FALSE, ce qui signifie que les colonnes virtuelles ajoutées ne sont
pas masquées.)
Les sujets
Voir également:
• Données JSON en mémoire (page 251)
DBMS_JSON.drop_virtual_columns
Ajout de colonnes virtuelles pour les champs JSON basés sur un guide de données hiérarchiques (page
1820)
Vous pouvez utiliser un guide de données hiérarchique pour projeter des champs scalaires à partir de
données JSON sous forme de colonnes virtuelles dans la même table. Tous les champs scalaires du
guide de données qui ne se trouvent pas sous un tableau sont projetés sous forme de colonnes
virtuelles. Tous les autres champs du guide de données sont ignorés (non projetés).
Ajout de colonnes virtuelles pour les champs JSON basés sur un index de recherche compatible avec
le guide de données (page 1823)
Vous pouvez utiliser un index de recherche compatible avec le guide de données pour une
colonne JSON afin de projeter des champs scalaires à partir de ces données JSON en tant que
colonnes virtuelles dans la même table. Seuls les champs scalaires qui ne sont pas sous un tableau
sont projetés. Vous pouvez spécifier une fréquence d'occurrence minimale pour les champs à projeter.
Suppression de colonnes virtuelles pour les champs JSON en fonction des informations du guide de données
(page 1825)
Vous pouvez utiliser la procédure DBMS_JSON.drop_virtual_columns pour supprimer toutes les
colonnes virtuelles qui ont été ajoutées pour les champs JSON dans une colonne de données JSON.
18.7.1 Ajout de colonnes virtuelles pour les champs JSON basés sur un guide de données hiérarchiques
Vous pouvez utiliser un guide de données hiérarchique pour projeter des champs scalaires à partir de données JSON sous
forme de colonnes virtuelles dans la même table. Tous les champs scalaires du guide de données qui ne sont pas sous un
tableau sont projetés sous forme de colonnes virtuelles. Tous les autres champs du guide de données sont
ignorés (non projetés).
Vous pouvez obtenir un guide de données hiérarchique à l'aide de la fonction PL/SQL
DBMS_JSON.get_index_dataguide. Un index de recherche JSON compatible avec le guide de données
doit être défini sur la colonne de données JSON.
Vous pouvez modifier le guide de données obtenu, pour n'inclure que des champs scalaires spécifiques (qui ne
sont pas sous un tableau), renommer ces champs ou modifier la longueur de leurs types. Le guide de données
résultant spécifie les champs à projeter en tant que nouvelles colonnes virtuelles. Tous les champs du guide de
données qui ne sont pas des champs scalaires ne se trouvant pas sous un tableau sont ignorés (non projetés).
Vous utilisez la procédure PL/SQL DBMS_JSON.add_virtual_columns pour ajouter les colonnes virtuelles à la
table qui contient la colonne JSON contenant les champs projetés.
Cette procédure supprime d'abord toutes les colonnes virtuelles existantes qui ont été projetées à partir de champs
dans la même colonne JSON par une invocation précédente de add_virtual_columns ou par la procédure de
déclenchement de changement de guide de données add_vc (en effet, elle fait ce que fait la procédure
DBMS_JSON.drop_virtual_columns).
L'exemple 189 (page 1821) illustre cela. Il projette des champs scalaires qui ne sont pas sous un tableau, à
partir des données de la colonne JSON po_document de la table j_purchaseorder.
Les champs projetés sont ceux qui sont indiqués dans le guide des données hiérarchiques.
L'exemple 1810 (page 1822) illustre la transmission d'un argument de guide de données qui spécifie la
projection de deux champs sous forme de colonnes virtuelles. Le champ de guide de données o:hidden est
utilisé pour masquer l'une de ces colonnes.
Voir également:
constante DBMS_JSON.FORMAT_HIERARCHICAL
Exemple 189 Ajout de colonnes virtuelles qui projettent des champs JSON à l'aide d'un data
Guide obtenu avec GET_INDEX_DATAGUIDE
Dans cet exemple, le guide de données hiérarchique est obtenu à partir d'un index de recherche JSON
compatible avec le guide de données sur la colonne JSON po_document.
Les colonnes virtuelles ajoutées sont toutes les colonnes de la table j_purchaseorder à l'exception de ID,
DATE_LOADED et PODOCUMENT.
(Les colonnes dont les noms sont en italique dans la sortie de la commande describe sont celles qui ont été
renommées à l'aide de la procédure PL/SQL DBMS_JSON.rename_column.)
EXEC DBMS_JSON.add_virtual_columns(
'J_PURCHASEORDER',
'PO_DOCUMENT',
DBMS_JSON.get_index_dataguide('J_PURCHASEORDER',
'PO_DOCUMENT',
DBMS_JSON.FORMAT_HIERARCHICAL) );
DESCRIBE j_purchaseorder ;
Nom Nul? Taper

IDENTIFIANT
NON NULL RAW(16)
PO_DOCUMENT CLOB
POnuméro NUMÉRO
Exemple 1810 Ajout de colonnes virtuelles, masquées et visibles
Dans cet exemple, seuls deux champs sont projetés en tant que colonnes virtuelles : PO_Number
et PO_Reference. Le guide de données est défini localement comme une chaîne littérale. Le champ
de guide de données o:hidden est utilisé ici pour masquer la colonne virtuelle pour PO_Reference.
(Pour PO_Number, l'entrée o:hidden: false n'est pas nécessaire, car false est la valeur par défaut.)
DÉCLARER
dg CLOB ;
COMMENCER
dg := '{"type" : "objet",
"Propriétés" :
{"PO_Number" : {"type" : "number", "o:length" : 4,
"o:preferred_column_name" :
"PO_Number", "o:hidden" : false}, "PO_Reference" : {"type" :
"string", "o:length" : 16, "o:preferred_column_name" :
"PO_Reference", "o:hidden" : true}}}' ; DBMS_JSON.add_virtual_columns('J_PURCHASEORDER',
'PO_DOCUMENT', dg); FIN; /
Nom Nul? Taper

IDENTIFIANT
NON NULL RAW(16)
PO_DOCUMENT CLOB
PO_Numéro NUMÉRO
SELECT nom_colonne FROM user_tab_columns
WHERE nom_table = 'J_PURCHASEORDER' ORDER BY 1 ;
NOM DE COLONNE

DATE_LOADED
IDENTIFIANT
PO_DOCUMENT
PO_Numéro
PO_Reference
5 lignes sélectionnées.
18.7.2 Ajout de colonnes virtuelles pour les champs JSON basés sur un index de recherche activé par le guide de
données
Vous pouvez utiliser un index de recherche compatible avec le guide de données pour une colonne JSON afin de
projeter des champs scalaires à partir de ces données JSON en tant que colonnes virtuelles dans la même table. Seuls
les champs scalaires qui ne sont pas sous un tableau sont projetés. Vous pouvez spécifier une fréquence d'occurrence
minimale pour les champs à projeter.
Vous utilisez la procédure DBMS_JSON.add_virtual_columns pour ajouter les colonnes virtuelles.
L'exemple 1811 (page 1824) illustre cela. Il projette tous les champs scalaires qui ne sont pas sous un tableau
dans la table j_purchaseorder en tant que colonnes virtuelles.
Si vous collectez des statistiques sur les documents dans la colonne JSON où vous souhaitez projeter des
champs, les informations du guide de données dans l'index de recherche JSON activé pour le guide de données
enregistrent la fréquence d'occurrence, dans cet ensemble de documents, de chaque champ d'un document.
Lorsque vous ajoutez des colonnes virtuelles, vous pouvez spécifier que seuls les champs avec une fréquence
d'occurrence minimale donnée doivent être projetés.
Pour ce faire, spécifiez une valeur différente de zéro pour le paramètre FREQUENCY de la procédure
add_virtual_columns. Zéro est la valeur par défaut, donc si vous n'incluez pas l'argument FREQUENCY, tous les champs
scalaires (pas sous un tableau) sont projetés. La fréquence d'un champ donné est le nombre de documents contenant ce
champ divisé par le nombre total de documents dans la colonne JSON, exprimé en pourcentage.
L'exemple 1812 (page 1824) projette tous les scalaires (pas sous un tableau) qui apparaissent dans tous (100 %)
les documents sous forme de colonnes virtuelles.
Si vous souhaitez masquer toutes les colonnes virtuelles ajoutées, spécifiez une valeur TRUE pour l'argument
HIDDEN. (La valeur par défaut du paramètre HIDDEN est FALSE, ce qui signifie que les colonnes virtuelles ajoutées
ne sont pas masquées.)
L'exemple 1813 (page 1825) projette, sous forme de colonnes virtuelles cachées, les champs scalaires (pas sous un
tableau) qui apparaissent dans tous (100 %) les documents.
Voir également:
Exemple 1811 Projection de tous les champs scalaires non sous un tableau sous forme de colonnes virtuelles
Les colonnes virtuelles ajoutées sont toutes les colonnes de la table j_purchaseorder à l'exception
de ID, DATE_LOADED et PODOCUMENT. C'est parce qu'aucun argument FREQUENCY n'est
passé à add_virtual_columns, donc tous les champs scalaires (qui ne sont pas sous un tableau) sont
projetés.
EXEC DBMS_JSON.add_virtual_columns('J_PURCHASEORDER', 'PO_DOCUMENT');
Nom Nul? Taper

IDENTIFIANT
NON NULL RAW(16)
PO_DOCUMENT CLOB
POnuméro NUMÉRO
Exemple 1812 Projection de champs scalaires avec une fréquence minimale en tant que virtuel
Colonnes
Tous les champs scalaires qui se produisent dans tous (100 %) des documents sont projetés
sous forme de colonnes virtuelles. Le résultat est le même que celui de l' exemple 1811 (page
1824), sauf que les champs AllowPartialShipment et Phone ne sont pas projetés, car ils
n'apparaissent pas dans 100 % des documents.
EXEC DBMS_JSON.add_virtual_columns('J_PURCHASEORDER', 'PO_DOCUMENT', 100);
Nom Nul? Taper

IDENTIFIANT
NON NULL RAW(16)
PO_DOCUMENT CLOB
POnuméro NUMÉRO
Exemple 1813 Projection de champs scalaires avec une fréquence minimale comme masqué
Colonnes virtuelles
Le résultat est le même que celui de l' exemple 1812 (page 1824), sauf que toutes les colonnes virtuelles
ajoutées sont masquées. (La requête de la vue USER_TAB_COLUMNS montre que les colonnes virtuelles
ont bien été ajoutées.)
EXEC DBMS_JSON.add_virtual_columns('J_PURCHASEORDER', 'PO_DOCUMENT', 100, TRUE);
Nom Nul? Taper

IDENTIFIANT
NON NULL RAW(16)
PO_DOCUMENT CLOB
SELECT nom_colonne FROM colonnes_onglet_utilisateur WHERE nom_table = 'J_PURCHASEORDER' ORDER
PAR 1 ;
NOM DE COLONNE

DATE_LOADED
IDENTIFIANT
POnuméro
PO_DOCUMENT
PO_DOCUMENT$Centre de coût
PO_DOCUMENT$Référence
PO_DOCUMENT$Demandeur
PO_DOCUMENT$Instructionsspéciales
PO_DOCUMENT$Utilisateur
PO_DOCUMENT$ville
PO_DOCUMENT$pays
PO_DOCUMENT$nom
PO_DOCUMENT$état
PO_DOCUMENT$rue
PO_DOCUMENT$code postal
18.7.3 Suppression de colonnes virtuelles pour les champs JSON en fonction des informations du guide de données
Vous pouvez utiliser la procédure DBMS_JSON.drop_virtual_columns pour supprimer toutes les colonnes
virtuelles qui ont été ajoutées pour les champs JSON dans une colonne de données JSON.
La procédure DBMS_JSON.drop_virtual_columns supprime toutes les colonnes virtuelles qui ont été
projetées à partir des champs d'une colonne JSON donnée par un appel de add_virtual_columns ou par la
procédure de déclenchement de changement de guide de données add_vc.
L'exemple 1814 (page 1826) illustre cela pour les champs projetés à partir de la colonne
po_document de la table j_purchaseorder.
Voir également:
Modifier les déclencheurs pour l'index de recherche activé par le guide de données
Exemple 1814 Suppression de colonnes virtuelles projetées à partir de champs JSON
EXEC DBMS_JSON.drop_virtual_columns('J_PURCHASEORDER', 'PO_DOCUMENT');
18.8 Modifier les déclencheurs pour l'index de recherche activé par le guide de données
Lorsque les données JSON changent, certaines informations d'un index de recherche JSON compatible avec le
guide de données sont automatiquement mises à jour. Vous pouvez spécifier une procédure dont l'invocation est
déclenchée chaque fois que cela se produit. Vous pouvez définir votre propre procédure PL/SQL pour cela, ou vous
pouvez utiliser la procédure de déclenchement de modification prédéfinie add_vc.
Les informations du guide de données dans un index de recherche JSON compatible avec le guide de données
enregistrent la structure, le type et éventuellement des informations statistiques sur un ensemble de documents JSON.
À l'exception des informations statistiques, qui ne sont mises à jour que lorsque vous collectez des statistiques,
les modifications pertinentes de l'ensemble de documents sont automatiquement reflétées dans les informations du guide
de données stockées dans l'index.
Vous pouvez définir une procédure PL/SQL dont l'invocation est automatiquement déclenchée par une telle mise à jour
d'index. L'appel se produit lorsque l'index est mis à jour. Toutes les erreurs qui se produisent lors de l'exécution de la
procédure sont ignorées.
Vous pouvez utiliser la procédure de déclenchement de modification prédéfinie add_vc pour ajouter automatiquement
des colonnes virtuelles qui projettent des champs JSON à partir de l'ensemble de documents ou pour modifier ces
colonnes existantes, si nécessaire. Les colonnes virtuelles ajoutées par add_vc suivent les mêmes règles de
dénomination que celles que vous ajoutez en appelant la procédure DBMS_JSON.add_virtual_columns pour une
colonne JSON qui a un index de recherche activé par le guide de données.
Dans les deux cas, toute erreur survenue lors de l'exécution de la procédure est ignorée.
Contrairement à DBMS_JSON.add_virtual_columns, add_vc ne supprime pas d'abord les colonnes virtuelles
existantes qui ont été projetées à partir des champs de la même colonne JSON. Pour supprimer des colonnes virtuelles
projetées à partir de champs dans la même colonne JSON par add_vc ou par add_virtual_columns, utilisez la procédure
DBMS_JSON.drop_virtual_columns.
Vous spécifiez l'utilisation d'un déclencheur pour les modifications de guide de données en utilisant les mots
clés DATAGUIDE ON CHANGE dans la clause PARAMETERS lorsque vous créez ou modifiez un index de recherche
JSON. Un seul déclencheur de modification est autorisé par index : la modification d'un index pour spécifier un déclencheur
remplace automatiquement tout déclencheur précédent pour celuici.
L'exemple 1815 (page 1826) modifie l'index de recherche JSON existant po_search_idx pour utiliser la procédure
add_vc.
Exemple 1815 Ajout automatique de colonnes virtuelles avec un déclencheur de modification
ADD_VC
Cet exemple ajoute le déclencheur de modification prédéfini add_vc à l'index de recherche JSON
po_search_idx.
Il supprime d'abord toutes les colonnes virtuelles existantes qui ont été projetées à partir des champs de la colonne
JSON po_document soit par la procédure DBMS_JSON.add_virtual_columns, soit par un déclencheur de modification
add_vc préexistant pour le même index de recherche JSON.
Ensuite, il modifie l'index de recherche pour ajouter le déclencheur de changement add_vc (s'il était déjà présent, cela n'a
aucun effet).
Enfin, il insère un nouveau document qui provoque un changement dans le guide des données. Deux colonnes
virtuelles sont ajoutées à la table, pour les deux champs scalaires non sous un tableau.
ALTER INDEX po_search_idx RECONSTRUIRE LES PARAMETRES ('DATAGUIDE ON CHANGE add_vc');
VALEURS
( SYS_GUID(),
to_date('30JUN2015'),
'{"PO_Number" : 4230, "PO_Reference" :
"JDEER20140421", "PO_LineItems" : [{"Part_Number" :
230912362345, "Quantity" : 3.0}]}');
Nom Nul? Taper

IDENTIFIANT
NON NULL RAW(16)
PO_DOCUMENT CLOB
PO_DOCUMENT$PO_Number NUMÉRO
PO_DOCUMENT$PO_Reference VARCHAR2(16)
Les sujets
Voir également:
• Ajout et suppression de colonnes virtuelles pour les champs JSON basés sur des données
Informations sur le guide (pages 1819)
Déclencheurs de changement de guide de données définis par l'utilisateur (page 1827)
Vous pouvez définir une procédure dont l'invocation est déclenchée automatiquement chaque fois
qu'un index de recherche JSON activé par le guide de données est mis à jour.
Toutes les erreurs qui se produisent lors de l'exécution de la procédure sont ignorées.
18.8.1 Déclencheurs de changement de guide de données définis par l'utilisateur
Vous pouvez définir une procédure dont l'invocation est déclenchée automatiquement chaque fois qu'un index de
recherche JSON activé par le guide de données est mis à jour. Toutes les erreurs qui se produisent lors de l'exécution
de la procédure sont ignorées.
Une procédure définie par l'utilisateur spécifiée avec les mots clés DATAGUIDE ON CHANGE dans une clause
PARAMETERS d'index de recherche JSON doit accepter les paramètres spécifiés dans le Tableau 185 (page
1827).
Tableau 185 Paramètres d'une procédure de déclenchement de changement de guide de données défini par l'utilisateur
Nom Taper Description
nom de la table VARCHAR2 Nom de la table contenant la colonne

nom_colonne.
nom de colonne VARCHAR2 Nom d'une colonne JSON qui possède un

index de recherche JSON compatible avec
le guide de données.
Tableau 185 (suite) Paramètres d'une procédure de déclenchement de changement de guide de données défini par l'utilisateur
Nom Taper Description
chemin VARCHAR2 Une expression de

chemin SQL/JSON qui cible un
champ particulier dans les données
de la colonne nom_colonne. Ce
chemin est affecté par le changement
d'index qui a déclenché l'invocation
de la procédure. Par exemple, le
changement d'index impliquait l'ajout
de ce chemin ou la modification de sa
valeur de type ou de sa valeur de
longueur de type.
nouveau genre NUMÉRO Un nouveau type pour le chemin

donné.
new_type_length NUMÉRO Une nouvelle longueur de type pour

le chemin donné.
Exemple 1816 Suivi des mises à jour du guide de données avec un déclencheur de modification défini par l'utilisateur
Cet exemple supprime d'abord toutes les colonnes virtuelles existantes projetées à partir des champs de
la colonne JSON po_document.
Il définit ensuite la procédure PL/SQL my_dataguide_trace, qui imprime les noms de la table et de la colonne
JSON, ainsi que les champs de chemin, de type et de longueur de la colonne virtuelle ajoutée. Il modifie ensuite
l'index de recherche JSON po_search_idx pour spécifier que cette procédure doit être appelée en tant que
déclencheur de modification pour les mises à jour des informations de guide de données dans l'index.
Il insère alors un nouveau document qui provoque un changement dans le guide de données, ce qui
déclenche la sortie des informations de trace.
Notez que l'argument TYPE de la procédure doit être un nombre qui est l'une des constantes DBMS_JSON
pour un type JSON. La procédure teste l'argument et génère une chaîne conviviale à la place du nombre.
CRÉER OU REMPLACER LA PROCÉDURE my_dataguide_trace(tableName VARCHAR2, jcolName
VARCHAR2, path
VARCHAR2,
tapez NOMBRE,
tlongueur NOMBRE)
EST
nom de type VARCHAR2(10);
COMMENCER
SI (type = SGBD_JSON.TYPE_NULL) ALORS nomtype := 'null';
ELSIF (type = DBMS_JSON.TYPE_BOOLEAN) THEN typename := 'boolean'; ELSIF (type =
DBMS_JSON.TYPE_NUMBER) THEN typename := 'number'; ELSIF (type =
DBMS_JSON.TYPE_STRING) THEN typename := 'string'; ELSIF (type = DBMS_JSON.TYPE_OBJECT)
THEN typename := 'object'; ELSIF (type = DBMS_JSON.TYPE_ARRAY) THEN typename := 'array';
AUTRE nomtype := 'inconnu';
FIN SI;
DBMS_OUTPUT.put_line('Updating ' || tableName || '(' || jcolName || '): Path =
' '
' || chemin || ', Taper = || taper || ', nom du type = || nom de type
Plusieurs guides de données par ensemble de documents
|| ', Tapez Longueur = ' || tlongueur );
FIN;
/
MODIFIER L'INDEX po_search_idx RECONSTRUIRE
PARAMÈTRES ('DATAGUIDE ON CHANGE my_dataguide_trace');
VALEURS (
SYS_GUID(),
to_date('30MAR2016'), : 4230,
'{"PO_ID"
"Réf_PO" : "JDEER20140421",
"PO_Items" : [{"Part_No" : 98981327234,
"Quantité_Article" : 13}]}');
S'ENGAGER;
Mise à jour de J_PURCHASEORDER(PO_DOCUMENT) :
Chemin = $.PO_ID, Type = 3, Nom du type = nombre, Longueur du type = 4
Mise à jour de J_PURCHASEORDER(PO_DOCUMENT) :
Path = $.PO_Ref, Type = 4, Type Name = string, Type Length = 16 Mise à jour de
J_PURCHASEORDER(PO_DOCUMENT) : Path = $.PO_Items, Type = 6, Type Name = array,
Type Length = 64 Mise à jour de J_PURCHASEORDER(PO_DOCUMENT) : Path =
$.PO_Items.Part_No, Type = 3, Type Name = number, Type Length = 16 Mise à jour de
J_PURCHASEORDER(PO_DOCUMENT) :
Chemin = $.PO_Items.Item_Quantity, Type = 3, Nom du type = nombre, Longueur du type = 2
Validation terminée.
Voir également:
constantes TYPE_NULL, TYPE_BOOLEAN, TYPE_NUMBER, TYPE_STRING, TYPE_OBJECT
et TYPE_ARRAY.
18.9 Plusieurs guides de données par ensemble de documents
Un guide de données reflète la forme d'un ensemble donné de documents JSON. Si une colonne JSON contient
différents types de documents, avec des informations de structure ou de type différentes, vous pouvez créer et
utiliser différents guides de données pour les différents types de documents.
Guides de données pour différents types de documents JSON
Les documents JSON n'ont pas besoin de suivre, et ne suivent généralement pas, un schéma prescrit. Cela est
vrai même pour les documents qui sont utilisés de manière similaire dans une application donnée ; ils peuvent
différer de manière structurelle (forme) et les types de champs peuvent différer.
Un guide de données JSON résume les informations structurelles et de type d'un ensemble de documents donné.
En général, plus la structure et les informations de type des documents d'un ensemble donné sont similaires, plus
le guide de données résultant est utile.
Un guide de données est créé pour une colonne donnée de données JSON. Si la colonne contient des types de
documents très différents (par exemple, des bons de commande et des dossiers médicaux), un guide de données
unique pour la colonne sera probablement d'une utilité limitée.
Une façon de résoudre ce problème consiste à placer différents types de documents JSON dans différentes
colonnes JSON. Mais parfois, d'autres considérations décident en faveur du mélange des types de documents dans la
même colonne.
De plus, les documents d'un même type général, que vous décidez de stocker dans la même colonne, peuvent
néanmoins différer de manière relativement systématique. Cela inclut le cas de l' évolution des informations de forme et
de type de document. Par exemple, la structure des documents d'information fiscale peut changer d'une année à l'autre.
Lorsque vous créez un guide de données, vous pouvez décider des informations à résumer. Et vous pouvez ainsi créer
différents guides de données pour la même colonne JSON, pour représenter différents sousensembles de l'ensemble
de documents.
Une aide supplémentaire à cet égard consiste à avoir une colonne distincte, non JSON, dans le même tableau, qui est
utilisée pour étiqueter ou catégoriser les documents dans une colonne JSON.
Dans le cas des documents de bons de commande utilisés dans nos exemples, supposons que leur structure puisse
évoluer significativement d'une année sur l'autre, de sorte que la colonne date_loaded de la table j_purchaseorder puisse
être utilisée pour les regrouper en sousensembles de forme raisonnablement similaire. L'exemple 1817 (page 1830)
ajoute un document de bon de commande pour 2015, et l' exemple 1818 (page 1831) ajoute un document de bon de
commande pour 2016. (Comparez avec les documents de 2014, qui sont ajoutés dans l'exemple 42 (page 42).)
Utilisation d'une fonction d'agrégation SQL pour créer plusieurs guides de données La fonction
Oracle SQL json_dataguide est en fait une fonction d' agrégation . Une fonction d'agrégation renvoie une ligne de résultat
unique basée sur des groupes de lignes, plutôt que sur une seule ligne. Il est généralement utilisé dans une liste SELECT
pour une requête contenant une clause GROUP BY, qui divise les lignes d'une table ou d'une vue interrogée en groupes.
La fonction d'agrégation s'applique à chaque groupe de lignes, renvoyant une seule ligne de résultat pour chaque groupe.
Par exemple, la fonction d'agrégation avg renvoie la moyenne d'un groupe de valeurs.
La fonction json_dataguide agrège les données JSON pour en produire un résumé, ou spécification, qui est
renvoyé sous la forme d'un document JSON. En d'autres termes, pour chaque groupe de documents JSON auxquels ils
s'appliquent, ils renvoient un guide de données.
Si vous omettez GROUP BY, cette fonction renvoie un guide de données unique qui résume toutes les données JSON
dans la colonne JSON sujet.
L' exemple 1819 (page 1831) interroge les documents de la colonne JSON po_document, en les regroupant pour
produire trois guides de données, un pour chaque année de la colonne date_loaded.
Exemple 1817 Ajout d'un bon de commande 2015
Le format de bon de commande 2015 utilise uniquement le numéro de pièce, la référence et les éléments de ligne comme
champs de niveau supérieur, et ces champs utilisent le préfixe PO_. Chaque élément de ligne contient uniquement un
numéro de pièce et une quantité.
VALEURS (
SYS_GUID(),
to_date('30JUN2015'),
'{"PO_Number" : 4230,
"PO_Reference" : "JDEER20140421",
"PO_LineItems" : [{"Part_Number" : 230912362345, "Quantity" : 3.0 }]}');
Exemple 1818 Ajout d'un bon de commande 2016
Le format 2016 utilise PO_ID au lieu de PO_Number, PO_Ref au lieu de
PO_Reference, PO_Items au lieu de PO_LineItems, Part_No au lieu de Part_Number et
Item_Quantity au lieu de Quantity.
VALEURS (
SYS_GUID(),
to_date('30MAR2016'),
'{"PO_ID" : 4230,
"Réf_PO" : "JDEER20140421",
"PO_Items" : [{"Part_No" : 98981327234,
"Quantité_Article" : 13}]}');
Exemple 1819 Création de plusieurs guides de données avec une fonction d'agrégation
JSON_DATAGUIDE
Cet exemple utilise la fonction SQL agrégée json_dataguide pour obtenir trois guides de données
plats, un pour chaque format spécifique à l'année. Le guide de données pour 2014 n'est affiché que
partiellement — il est identique au guide de données de A Flat Data Guide For Purchase Order
Documents (page 1835), sauf qu'aucun champ de statistiques n'est présent. (Les guides de données
renvoyés par les fonctions json_dataguide ne contiennent aucun champ de statistiques.
SELECT extrait (ANNÉE DE date_loaded), json_dataguide (po_document) DE j_purchaseorder
GROUP BY extrait(YEAR FROM date_loaded)
ORDER BY extrait(ANNÉE DE date_chargé) DESC ;
EXTRAIT(YEARFROMDATE_LOADED)

JSON_DATAGUIDE(PO_DOCUMENT)

2016
[
{
"o:chemin" : "$.PO_ID",
"type" : "nombre", "o:longueur" :
4 }, {
"o:path" : "$.PO_Ref", "type" :
"string", "o:length" : 16 }, {
"o:path" : "$.PO_Items", "type" :
"array", "o:length" : 64 }, {
"o:path" : "$.PO_Items.Part_No", "type" :
"nombre", "o:length" : 16 }, {
"o:path" : "$.PO_Items.Item_Quantity", "type" :
"nombre", "o:length" : 2
}
]
2015
[
{
"o:path" : "$.PO_Number", "type" :
"nombre", "o:length" : 4 }, {
"o:path" : "$.PO_LineItems", "type" :
"array", "o:length" : 64 }, {
"o:path" : "$.PO_LineItems.Quantity", "type" : "nombre",
"o:length" : 4 }, {
"o:path" : "$.PO_LineItems.Part_Number", "type" : "nombre",
"o:length" : 16 }, {
"o:chemin" : "$.PO_Reference", "type" :
"chaîne", "o:longueur" : 16
}
]
2014
[
{
"o:path" : "$.User", "type" :
"string", "o:length" : 8 }, {
"o:path" : "$.PONumber", "type" :
"nombre", "o:length" : 4 },
...
{
"o:chemin" : "$.\"Instructions spéciales\"", "type" : "chaîne",
"o:longueur" : 8
}
]
3 lignes sélectionnées.
Voir également:
Oracle Database SQL Language Reference pour plus d'informations sur la fonction
SQL json_dataguide
Interrogation d'un guide de données
18.10 Interrogation d'un guide de données
Un guide de données est une information sur un ensemble de documents JSON. Vous pouvez l'interroger
à partir d'un guide de données plat que vous obtenez à l'aide de la fonction Oracle SQL json_dataguide ou
de la fonction PL/SQL DBMS_JSON.get_index_dataguide. Dans ce dernier cas, un index de recherche
JSON compatible avec le guide de données doit être défini sur les données JSON.
Voir également:
• Champs du guide de données JSON (page 188)
• Oracle Database SQL Language Reference pour plus d'informations sur la fonction
SQL json_dataguide
• Oracle Database SQL Language Reference pour plus d'informations sur SQL/JSON
fonction json_table
constante DBMS_JSON.FORMAT_FLAT
Exemple 1820 Interrogation d'un guide de données obtenu à l'aide de JSON_DATAGUIDE
Cet exemple utilise la fonction SQL/JSON json_dataguide pour obtenir un guide de données plat.
Il interroge ensuite les colonnes relationnelles projetées à la volée par la fonction SQL/JSON
json_table à partir des champs o:path, type et o:length. Il renvoie les colonnes projetées classées
lexicographiquement par la colonne de chemin créée, jpath.
AVEC dg_t AS (SELECT json_dataguide(po_document) dg_doc FROM j_purchaseorder)
SELECT jt.*
FROM dg_t,
json_table(dg_doc, '$[*]'
COLONNES
jpath VARCHAR2(40) PATH '$."o:path"', VARCHAR2(10) PATH
'$."type"', type tlength NUMBER ORDER BY jt.jpath;
CHEMIN '$."o:longueur"') jt
JPATH TAPER LONGUEUR

$."Instructions spéciales" chaîne 8
$.AllowPartialShipment $.CostCenter booléenne 4
$.LineItems $.LineItems.ItemNumber chaîne de caractères
4
$.LineItems.Part numéro 512

$.LineItems.Part.Description de tableau 1
$.LineItems.Part.UPCCode numéro 128
$.LineItems.Part.UnitPrice $.LineItems.Quantity de chaîne 32
$.PONumber $. PO_LineItems $.Reference d'objet 16
$.Requestor $.ShippingInstructions Numéro 8
$.ShippingInstructions.Address Numéro 4
Numéro 4
tableau 64
chaîne 16
chaîne 16
objet objet 256
128
Interrogation d'un guide de données
$.ShippingInstructions.Address.city chaîne $.ShippingInstructions.Address.country 32
chaîne $.ShippingInstructions.Address.state chaîne 32
$.ShippingInstructions.Address.street chaîne 2
$.ShippingInstructions.Address.zipCode numéro $.ShippingInstructions.Phone 32
$.ShippingInstructions.Phone $.ShippingInstructions.Phone.number 8
$.ShippingInstructions.Phone.type $.ShippingInstructions.name $.User
tableau 128
chaîne 16
chaîne 16
chaîne 8
chaîne 16
chaîne 8
Exemple 1821 Interrogation d'un guide de données avec des données d'index pour des chemins avec une fréquence d'au moins 80 %
Cet exemple utilise la fonction PL/SQL DBMS_JSON.get_index_dataguide avec la valeur de
format DBMS_JSON.FORMAT_FLAT pour obtenir un guide de données plat à partir des
informations de guide de données stockées dans un index de recherche JSON compatible avec le
guide de données. Il interroge ensuite les colonnes relationnelles projetées à la volée à partir des
champs o:path, type, o:length et o:frequency par la fonction SQL/JSON json_table.
La valeur du champ o:frequency est une statistique qui enregistre la fréquence d'occurrence, dans
l'ensemble de documents, de chaque champ d'un document. Il n'est disponible que si vous avez
collecté des statistiques sur l'ensemble de documents. La fréquence d'un champ donné est le nombre
de documents contenant ce champ divisé par le nombre total de documents dans la colonne JSON,
exprimé en pourcentage.
AVEC dg_t AS (SELECT DBMS_JSON.get_index_dataguide('J_PURCHASEORDER', 'PO_DOCUMENT',
DBMS_JSON.FORMAT_FLAT)
dg_doc
DU DOUBLE)
SELECT jt.*
FROM dg_t,
json_table(dg_doc, '$[*]'
COLONNES
jpath VARCHAR2(40) CHEMIN '$."o:chemin"',
type VARCHAR2(10) CHEMIN '$."type"', CHEMIN
tlength NUMBER '$."o:longueur"', CHEMIN
fréquence NUMBER '$."o:fréquence"') jt
WHERE jt.frequency > 80 ;
JPATH TAPER LONGUEUR FRÉQUENCE

$.User numéro 8 100

$.PONumber de chaîne 4 100
$.LineItems numéro 512 100
$.LineItems.Part d'objet 128 100
$.LineItems.Part.UPCCode tableau 16 100
$.LineItems.Part.UnitPrice Numéro 8 100
$.LineItems.Part.Description numéro 32 100
$.LineItems.Quantity $.LineItems.ItemNumber de chaîne 4 100
$.Reference $. Demandeur $.CostCenter Numéro 1 100
$.ShippingInstructions chaîne 16 100
$.ShippingInstructions.name chaîne 16 100
$.ShippingInstructions.Address chaîne 4 100
$.ShippingInstructions.Address.city objet 256 100
$.ShippingInstructions.Address.state chaîne 16 100
$.ShippingInstructions.Address.street objet 128 100
chaîne 32 100
chaîne 2 100
chaîne 32 100
Un guide de données plates pour les documents de bon de commande
$.ShippingInstructions.Address.country chaîne 32 100
$.ShippingInstructions.Address.zipCode numéro $."Special Instructions" 8 100
chaîne 8 100
18.11 Un guide de données plates pour les documents de bon de commande
Les champs d'un exemple de guide de données plates sont décrits. Il correspond à un ensemble de
Le seul motclé JSON Schema utilisé dans un guide de données plat est type. Les autres champs sont tous des
champs du guide de données Oracle, qui ont le préfixe o :.
L'exemple 1822 (page 1835) montre un guide de données plat pour les documents de bon de
commande dans la table j_purchaseorder. À noter :
• Les valeurs de o:preferred_column_name utilisent le préfixe PO_DOCUMENT$. Ce préfixe provient de
l'utilisation de DBMS_JSON.get_index_dataguide pour obtenir ce guide de données.
• La valeur de o:length est 8 pour le chemin $.User, par exemple, malgré le fait que les longueurs réelles des
valeurs de champ sont 5. Cela est dû au fait que la valeur de o:length est toujours une puissance de deux.
• La valeur de o:path pour le champ Special Instructions est entourée de guillemets ("Special Instructions")
en raison du caractère d'espace incorporé.
Exemple 1822 Guide des données plates pour les bons de commande
Les chemins sont audacieux. Les mots clés du schéma JSON sont en italique. Les noms de colonne préférés
résultant de l'utilisation de DBMS_JSON.rename_column sont également en italique.
Notez que les champs o:frequency, o:low_value, o:high_value, o:num_nulls et o:last_analyzed sont présents.
Cela ne peut être dû qu'au fait que des statistiques ont été collectées sur l'ensemble de documents. Leurs
valeurs reflètent l'état de la dernière collecte de statistiques. Voir Exemple 183 (page 186) pour un exemple
de collecte de statistiques pour ces données.
[
{
"o:path": "$.User", "type":
"string", "o:length": 8,
"o:preferred_column_name":
"PO_DOCUMENT$User", "o:frequency": 100, "o :low_value": "ABULL",
"o:high_value": "SBELL", "o:num_nulls": 0, "o:last_analyzed":
"20160331T12:17:53" }, {
"o:path": "$.PONumber", "type":
"number", "o:length": 4,
"PONumber", "o:frequency": 100, "o:low_value" " : "672",
"o:high_value": "1600", "o:num_nulls": 0, "o:last_analyzed":
"20160331T12:17:53" }, {
"o:path": "$.LineItems",
"type": "array",
"o:length": 512,
"o:preferred_column_name": "PO_DOCUMENT$LineItems",
"o:frequency": 100, "o:last_analyzed": "20160331T12:17 :53" },
{
"o:path": "$.LineItems.Part", "type":
"object", "o:length": 128,
"PO_DOCUMENT$Part", "o:frequency": 100,
"o:last_analyzed": "20160331T12:17:53" }, {
"o:path": "$.LineItems.Part.UPCCode", "type":
"PO_DOCUMENT$UPCCode", "o:frequency": 100,
"o:low_value": "13131092899", "o:high_value": "717951002396",
"o:num_nulls": 0, "o:last_analyzed": "20160331T12:17:53" },
{
"o:path": "$.LineItems.Part.UnitPrice", "type":
"number", "o:length": 8, "o:preferred_column_name":
"PO_DOCUMENT$UnitPrice", "o:frequency":
100, "o:low_value": "20", "o:high_value": "19.95", "o:num_nulls":
0, "o:last_analyzed": "20160331T12:17:53" }, {
"o:path": "$.LineItems.Part.Description", "type":
"string", "o:length": 32, "o:preferred_column_name":
"PartDescription", "o:frequency": 100, "o:low_value":
"Nixon", "o:high_value": "Eric Clapton : le meilleur de
19811999", "o:num_nulls": 0, "o:last_analyzed":
"20160331T12:17 : 53" }, {
"o:path": "$.LineItems.Quantity", "type":
"PO_DOCUMENT$Quantity", "o:frequency": 100, "o:low_value":
"5", "o:high_value": "9.0", "o:num_nulls": 0, "o:last_analyzed":
"20160331T12:17:53" }, {
"o:path": "$.LineItems.ItemNumber", "type":
"nombre",
"o:length": 1,
"o:preferred_column_name": "ItemNumber",
"o:frequency": 100, "o:low_value": "1",
"o:high_value": "3", "o:num_nulls" " : 0,
"o:last_analyzed": "20160331T12:17:53" }, {
"o:path": "$.Reference",
"type": "string", "o:length":
16, "o:preferred_column_name":
"PO_DOCUMENT$Reference", "o:frequency": 100,
"o :low_value": "ABULL20140421", "o:high_value":
"SBELL20141017", "o:num_nulls": 0, "o:last_analyzed":
"20160331T12:17:53" }, {
"o:path": "$.Requestor",
16, "o:preferred_column_name":
"PO_DOCUMENT$Requestor", "o:frequency": 100,
"o :low_value": "Sarah Bell", "o:high_value": "Alexis Bull",
{
"o:path": "$.CostCenter",
"type": "string", "o:length": 4,
"PO_DOCUMENT$CostCenter", "o:frequency": 100,
"o :low_value": "A50", "o:high_value": "A50", "o:num_nulls": 0,
"o:last_analyzed": "20160331T12:17:53" }, {
"o:path": "$.AllowPartialShipment", "type":
"booléen", "o:length": 4,
"PO_DOCUMENT$AllowPartialShipment", "o:frequency": 50, "o :low_value":
"true", "o:high_value": "true", "o:num_nulls": 0, "o:last_analyzed":
"20160331T12:17:53" }, {
"o:path": "$.ShippingInstructions", "type":
"PO_DOCUMENT$ShippingInstructions", "o:frequency": 100,
"o :last_analyzed": "20160331T12:17:53" }, {
"o:path": "$.ShippingInstructions.name", "type":
"PO_DOCUMENT$name", "o:frequency": 100,
"o:low_value": "Sarah Bell", "o:high_value": "Alexis Bull",
{
"o:path": "$.ShippingInstructions.Phone", "type":
"Téléphone", "o:frequency": 50, "o :low_value":
"9835556509", "o:high_value": "9835556509",
"o:num_nulls": 0, "o:last_analyzed":
"20160331T12:17:53 " }, {
"o:path": "$.ShippingInstructions.Phone", "type":
"array", "o:length": 128, "o:preferred_column_name":
"PO_DOCUMENT$Phone_1", "o:frequency": 50,
"o:last_analyzed": "20160331T12:17:53" }, {
"o:path": "$.ShippingInstructions.Phone.type", "type":
"PhoneType", "o:frequency": 50, "o:low_value": "Mobile",
"o:high_value": "Bureau", "o:num_nulls": 0,
"o:last_analyzed": "20160331T12:17:53" }, {
"o:path": "$.ShippingInstructions.Phone.number", "type":
"PhoneNumber", "o:frequency": 50, "o:low_value":
"4155551234", "o:high_value": "9095557307",
"o:num_nulls": 0, "o:last_analyzed": "20160331T12:17
:53" }, {
"o:path": "$.ShippingInstructions.Address", "type":
"object", "o:length": 128, "o:preferred_column_name":
"PO_DOCUMENT$Address", "o:frequency": 100,
"o:last_analyzed": "20160331T12:17:53" }, {
"o:path": "$.ShippingInstructions.Address.ville",
"type": "string",
"o:length": 32,
"o:preferred_column_name": "PO_DOCUMENT$city",
"o:frequency": 100, "o:low_value": "South San Francisco",
"o :high_value": "Sud de San Francisco", "o:num_nulls": 0,
"o:last_analyzed": "20160331T12:17:53" }, {
"o:path": "$.ShippingInstructions.Address.state", "type": "string",
"o:length": 2, "o:preferred_column_name": "PO_DOCUMENT$state",
"o:frequency": 100, "o:low_value": "CA", "o:high_value": "CA",
"o:num_nulls": 0, "o:last_analyzed": "20160331T12:17:53" }, {
"o:path": "$.ShippingInstructions.Address.street", "type": "string",
"o:length": 32, "o:preferred_column_name": "PO_DOCUMENT$street",
"o:frequency": 100, "o:low_value": "200 Sporting Green",
"o:high_value": "200 Sporting Green", "o:num_nulls": 0,
"o:last_analyzed": "20160331T12:17:53 " }, {
"o:path": "$.ShippingInstructions.Address.country", "type": "string",
"o:length": 32, "o:preferred_column_name": "PO_DOCUMENT$country",
"o:frequency": 100, "o:low_value": "ÉtatsUnis d'Amérique",
"o:high_value": "ÉtatsUnis d'Amérique", "o:num_nulls": 0,
"o:last_analyzed": "20160331T12:17 :53" }, {
"o:path": "$.ShippingInstructions.Address.zipCode", "type": "number",
"o:length": 8, "o:preferred_column_name": "PO_DOCUMENT$zipCode",
"o:frequency": 100, "o:low_value": "99236", "o:high_value": "99236",
"o:num_nulls": 0, "o:last_analyzed": "20160331T12:17:53" }, {
"o:path": "$.\"Instructions spéciales\"", "type":
"PO_DOCUMENT$SpecialInstructions",
"o:frequency" : 100, "o:low_value": "Courrier", "o:high_value": "Courrier",
Un guide de données hiérarchiques pour les documents de bon de commande
"o:num_nulls": 1,
"o:last_analyzed": "20160331T12:17:53"
}
]
Voir également:
18.12 Un guide de données hiérarchiques pour les documents de bon de commande
Les champs d'un exemple de guide de données hiérarchiques sont décrits. Il correspond à un ensemble de
L'exemple 1823 (page 1840) montre un guide de données hiérarchique pour les documents de bon de
commande dans la table j_purchaseorder.
Exemple 1823 Guide des données hiérarchiques pour les bons de commande
Les noms de champs sont en gras. Les mots clés du schéma JSON sont en italique. Les noms de colonne
préférés résultant de l'utilisation de DBMS_JSON.rename_column sont également en italique.
Notez que les champs o:frequency, o:low_value, o:high_value, o:num_nulls et o:last_analyzed sont présents
dans cet exemple. Cela ne peut être dû qu'au fait que des statistiques ont été collectées sur l'ensemble de
documents. Leurs valeurs reflètent l'état de la dernière collecte de statistiques. Voir Exemple 183 (page 186)
pour un exemple de collecte de statistiques pour ces données.
"type": "objet",
"propriétés": {
"User":
{ "type": "string",
"o:length": 8,
"o:preferred_column_name": "PO_DOCUMENT$User",
"o:frequency": 100, "o:low_value": "ABULL" , "o:high_value":
"SBELL", "o:num_nulls": 0, "o:last_analyzed":
"20160331T12:17:53" },
"PONuméro": {
"type": "number",
"o:length": 4,
"o:preferred_column_name": "PONumber",
"o:high_value": "1600", "o:num_nulls": 0,
"o:last_analyzed": "20160331T12:17:53"
},
"LineItems":
{ "type": "array",
"o:length": 512,
"o:preferred_column_name": "PO_DOCUMENT$LineItems",
"o:frequency": 100, "o:last_analyzed": " 20160331T12:17:53",
"items": { "properties": { "Part": { "type": "object", "o:length": 128,
"o:preferred_column_name": "PO_DOCUMENT" $Part",
"o:frequency": 100, "o:last_analyzed": "20160331T12:17:53",
"properties": { "UPCCode": { "type": "number", "o :length": 16,
"o:preferred_column_name": "PO_DOCUMENT$UPCCode",
"o:high_value": "717951002396", "o:num_nulls" " : 0,
"o:last_analyzed": "20160331T12:17:53" }, "UnitPrice":
{ "type": "number", "o:length": 8, "o:preferred_column_name":
"PO_DOCUMENT$UnitPrice", "o:frequency": 100,
"o:low_value": "20", "o:high_value": "19.95", "o:num_nulls":
0, "o:last_analyzed": "2016 0331T12:17:53" },
"Description": {
"type": "string",
"o:length": 32,
"o:preferred_column_name": "PartDescription",
"o:frequency": 100, "o:low_value": "Nixon", "o:high_value":
"Eric Clapton : Le meilleur de 19811999", "o:num_nulls":
0, "o:last_analyzed": "20160331T12:17:53"
}
}
},
"Quantity":
{ "type": "number",
"o:length": 4,
"o:preferred_column_name": "PO_DOCUMENT$Quantity",
"o:frequency": 100, "o:low_value": " 5", "o:high_value": "9.0",
"ItemNumber": { "type": " nombre", "o:longueur": 1,
"o:preferred_column_name": "ItemNumber",
"o:high_value": "3", "o:num_nulls": 0,
"o:last_analyzed " : "20160331T12:17:53"
}
}
} },
"Reference":
{ "type": "string",
"o:length": 16,
"o:preferred_column_name": "PO_DOCUMENT$Reference",
"o:frequency": 100, "o:low_value": "ABULL 20140421",
"o:high_value": "SBELL20141017", "o:num_nulls": 0,
"o:last_analyzed": "20160331T12:17:53" },
"Requestor":
{ "type": "string",
"o:length": 16,
"o:preferred_column_name": "PO_DOCUMENT$Requestor",
"o:frequency": 100, "o:low_value": "Sarah Bell ", "o:high_value":
"Alexis Bull", "o:num_nulls": 0, "o:last_analyzed":
"20160331T12:17:53" },
"CostCenter":
{ "type": "string",
"o:length": 4,
"o:preferred_column_name": "PO_DOCUMENT$CostCenter",
"o:frequency": 100, "o:low_value": "A50" , "o:high_value": "A50",
"AllowPartialShipment": { "type":
"boolean", "o:length": 4,
"PO_DOCUMENT$AllowPartialShipment", "o:frequency": 50, "o:last_analyzed":
"2016 0331T12:17:53" },
"ShippingInstructions": { "type":
"PO_DOCUMENT$ShippingInstructions", "o:frequency": 100, "o:last_analyzed":
"2016 0331T12:17:53", "properties": { "name": { "type": "string", "o:length":
16, "o:preferred_column_name": "PO_DOCUMENT$name", "o: fréquence":
100, "o:low_value": "Sarah Bell", "o:high_value": "Alexis Bull",
"o:num_nulls": 0,
"o:last_analyzed": "20160331T12:17:53" },
"Téléphone":
{ "oneOf": [ {
16,
"o:preferred_column_name": "Téléphone",
"o :high_value": "9835556509", "o:num_nulls": 0,
"o:last_analyzed": "20160331T12:17:53" }, {
"type": "array", "o:length":
128,
"o:preferred_column_name": "PO_DOCUMENT$Phone_1", "o:frequency":
50, "o:last_analyzed": "20160331T12:17 :53", "items": { "properties":
{ "type": { "type": "string", "o:length": 8, "o:preferred_column_name":
"PhoneType", "o:frequency" : 50, "o:low_value": "Mobile", "o:high_value":
"Bureau", "o:num_nulls": 0, "o:last_analyzed": "20160331T12:17:53" },
"number": { "type": "string", "o:length": 16, "o:preferred_column_name":
"PhoneNumber", "o:frequency": 50, "o:low_value": "415555
1234", "o:high_value": "9095557307", "o:num_nulls": 0,
"o:last_analyzed": "20160331T12:17:53"
}
}
}
}
]
},
"Address": { "type":
"PO_DOCUMENT$Address", "o:frequency": 100, "o:last_analyzed": "2016
3103T12:17:53", "properties": { "city": { "type": "string", "o:length": 32,
"o:preferred_column_name": "PO_DOCUMENT$city", "o : fréquence": 100,
"o:low_value": "Sud de San Francisco",
"o:high_value": "South San Francisco", "o:num_nulls":
0, "o:last_analyzed": "20160331T12:17:53" }, "state":
{ "type": "chaîne ", "o:length": 2, "o:preferred_column_name":
"PO_DOCUMENT$state", "o:frequency": 100, "o:low_value":
"CA", "o:high_value": "CA", "o:num_nulls": 0, "o:last_analyzed":
"20160331T12:17:53" }, "street": { "type": "string",
"o:length": 32, "o :preferred_column_name":
"PO_DOCUMENT$street", "o:frequency": 100, "o:low_value": "200
Sporting Green", "o:high_value": "200 Sporting Green", "o:num_nulls":
0, "o:last_analyzed": "20160331T12:17:53" }, "country": { "type":
"chaîne", "o:length": 32, "o:preferred_column_name":
"PO_DOCUMENT$pays ", "o:frequency": 100, "o:low_value": "États
Unis d'Amérique", "o:high_value": "ÉtatsUnis d'Amérique",
"o:num_nulls": 0, "o:last_analyzed": "20160331T12:17:53" }, "zipCode":
{ "type": "number", "o:length": 8, "o:preferred_column_name":
"PO_DOCUMENT$zipCode", "o:frequency " : 100, "o:low_value":
"99236", "o:high_value": "99236", "o:num_nulls": 0, "o:last_analyzed":
"20160331T12:17:53"
}
}
}
}
},
"Instructions spéciales": { "type":
"string", "o:length": 8,
"PO_DOCUMENT$SpecialInstructions", "o:frequency": 100, "o:low_value": "Courrier ",
"o:high_value": "Courrier", "o:num_nulls": 1, "o:last_analyzed": "20160331T12:17:53"
}
}
}
Voir également:
Partie V
Génération de données JSON
Vous pouvez utiliser SQL pour générer par programmation des données JSON à partir
d'autres types de données de base de données, à l'aide des fonctions SQL/JSON
json_object, json_array, json_objectagg et json_arrayagg.
Chapitres
Génération de données JSON avec des fonctions SQL/JSON (page 191)
Les fonctions SQL/JSON json_object, json_array, json_objectagg et json_arrayagg
sont présentées.
19
Génération de données JSON avec SQL/JSON
Les fonctions
Les fonctions SQL/JSON json_object, json_array, json_objectagg et json_arrayagg sont présentées.
Les sujets
Présentation des fonctions de génération SQL/JSON (page 191)
Vous pouvez utiliser les fonctions SQL/JSON json_object, json_array, json_objectagg et
json_arrayagg pour construire des données JSON à partir de données non JSON dans la base de
données. Les données JSON sont renvoyées sous la forme d'une valeur SQL VARCHAR2.
Fonction JSON_OBJECT SQL/JSON (page 194)
La fonction SQL/JSON json_object construit des objets JSON à partir de paires nomvaleur. Chaque
paire est fournie comme argument explicite. Chaque nom d'une paire doit correspondre à un identifiant
SQL. Chaque valeur d'une paire peut être n'importe quelle expression SQL . Le nom et la valeur sont
séparés par le mot clé VALUE.
Fonction JSON_ARRAY SQL/JSON (page 196)
La fonction SQL/JSON json_array construit un tableau JSON à partir des résultats de
l'évaluation de ses expressions SQL en argument. Chaque argument peut être n'importe quelle
expression SQL. L'ordre des éléments du tableau est le même que l'ordre des arguments.
JSON_OBJECTAGG Fonction SQL/JSON (page 197)
La fonction SQL/JSON json_objectagg construit un objet JSON en agrégeant les informations
de plusieurs lignes d'une requête SQL groupée en tant que membres de l'objet.
Fonction JSON_ARRAYAGG SQL/JSON (page 198)
La fonction SQL/JSON json_arrayagg construit un tableau JSON en agrégeant les
informations de plusieurs lignes d'une requête SQL groupée en tant qu'éléments du tableau. L'ordre
des éléments du tableau reflète l'ordre des résultats de la requête, par défaut, mais vous pouvez
utiliser la clause ORDER BY pour imposer l'ordre des éléments du tableau.
19.1 Présentation des fonctions de génération SQL/JSON Vous pouvez utiliser les fonctions SQL/
JSON json_object, json_array, json_objectagg et json_arrayagg pour construire des données JSON à partir de
données non JSON dans la base de données.
Les données JSON sont renvoyées sous la forme d'une valeur SQL VARCHAR2.
Ces fonctions de génération permettent de construire facilement des données JSON directement à partir d'une
requête SQL. Ils permettent aux données non JSON d'être représentées sous forme d'objets JSON et de tableaux JSON.
Vous pouvez générer des documents JSON complexes et hiérarchiques en imbriquant des appels à ces
Génération de données JSON avec des fonctions SQL/JSON 191
Présentation des fonctions de génération SQL/JSON
les fonctions. Les sousrequêtes imbriquées peuvent générer des collections JSON qui représentent des
relations un à plusieurs.11 La meilleure façon de construire des données JSON à partir de données non
JSON Les alternatives à l'utilisation des fonctions de génération SQL/JSON sont généralement sujettes
aux erreurs ou inefficaces.
• L'utilisation de la concaténation de chaînes pour générer des documents JSON est sujette aux erreurs. Dans
En particulier, il existe un certain nombre de règles complexes qui doivent être respectées concernant le
moment et la manière d'échapper les caractères spéciaux, tels que les guillemets doubles ("). Il est facile
d'ignorer ou de mal comprendre ces règles, ce qui peut entraîner la génération de données JSON
incorrectes.
• La lecture d'ensembles de résultats non JSON à partir de la base de données et l'utilisation du code
d'application côté client pour générer des données JSON sont généralement assez inefficaces,
notamment en raison de la surcharge du réseau. Lors de la représentation de relations unàplusieurs
sous forme de données JSON, plusieurs opérations SELECT sont souvent nécessaires pour collecter
toutes les données non JSON nécessaires. Si les documents à générer représentent plusieurs niveaux de
relations un à plusieurs, cette technique peut être assez coûteuse.
Les fonctions de génération SQL/JSON ne souffrent pas de tels problèmes ; ils sont conçus pour
construire des données JSON à partir de données de base de données non JSON.
• Ils construisent toujours des documents JSON bien formés.
• En utilisant des sousrequêtes SQL avec ces fonctions, vous pouvez générer un ensemble complet de
documents JSON à l'aide d'une seule instruction SQL, ce qui permet d'optimiser l'opération de
génération.
• Étant donné que seuls les documents générés sont renvoyés à un client, la surcharge du réseau est
minimisée : il y a au plus un allerretour par document généré.
Les fonctions de génération SQL/JSON
• Les fonctions json_object et json_array construisent un objet ou un tableau JSON,
respectivement, donnés comme arguments des paires nomvaleur SQL et des valeurs, respectivement.
Le nombre d'arguments correspond au nombre de membres d'objet et d'éléments de tableau,
respectivement (sauf lorsqu'une expression d'argument est évaluée à SQL NULL et que la clause
ABSENT ON NULL s'applique).
Chaque nom doit avoir la syntaxe d'un identifiant SQL. Chaque valeur peut être n'importe quelle valeur
SQL, y compris une valeur calculée à l'aide d'une (sous)requête SQL scalaire qui renvoie au plus un
élément (une seule ligne avec une seule colonne — une erreur est générée si un tel argument de
requête renvoie plus d'une ligne. )
• Les fonctions json_objectagg et json_arrayagg sont des fonctions SQL agrégées .
Ils transforment les informations contenues dans les lignes d'une requête SQL groupée en objets et
tableaux JSON, respectivement. L'évaluation des arguments détermine le nombre de membres d'objet et
d'éléments de tableau, respectivement ; c'estàdire que la taille du résultat reflète les données
actuellement interrogées.
Pour json_objectagg, l'ordre des membres d'objet n'est pas spécifié. Pour json_arrayagg,
l'ordre des éléments du tableau reflète l'ordre des résultats de la requête. Vous pouvez utiliser SQL
ORDER BY dans la requête pour contrôler l'ordre des éléments du tableau.
1 Le comportement des fonctions de génération SQL/JSON pour les données JSON est similaire à celui de la génération SQL/XML
fonctions pour les données XML.
Présentation des fonctions de génération SQL/JSON
Formats des valeurs d'entrée pour JSON_OBJECT et JSON_ARRAY Pour la
fonction json_array, vous pouvez utiliser n'importe quelle valeur SQL comme argument. De même pour
les arguments de valeur des paires nomvaleur que vous transmettez à la fonction json_object. Dans
certains cas, vous savez ou pensez qu'une telle valeur est en fait une donnée JSON (représentée par
une chaîne ou un nombre SQL). Vous pouvez ajouter des mots clés FORMAT JSON après toute
expression de valeur d'entrée pour déclarer cette attente pour la valeur qui résulte de cette expression.
Si Oracle peut déterminer que la valeur est en fait une donnée JSON, elle est traitée comme si elle était
suivie d'une déclaration FORMAT JSON explicite. C'est le cas, par exemple, si l'expression de valeur
est une invocation d'une fonction de génération SQL/JSON.
Si vous ne spécifiez pas FORMAT JSON et si Oracle ne peut pas déterminer que la valeur est une
donnée JSON, il est supposé qu'il s'agit de données SQL ordinaires (non JSON). Dans ce cas, il est
sérialisé comme suit (toute autre valeur SQL génère une erreur) :
• Une valeur VARCHAR2 ou CLOB est entourée de guillemets doubles (").
• Une valeur numérique est convertie en nombre JSON. (Il n'est pas cité.)
• Une valeur DATE ou TIMESTAMP est convertie au format ISO 8601 et le résultat est
entre guillemets doubles (").
• Une valeur BOOLEAN PL/SQL est convertie en JSON true ou false. (Ce n'est pas
cité.)
• Une valeur NULL est convertie en JSON null, quel que soit le type de données NULL.
Noter:
Étant donné qu'Oracle SQL traite une chaîne vide comme NULL, il n'y a aucun
moyen de construire une chaîne JSON vide ("").
Le format d'un argument d'entrée peut affecter le format des données renvoyées par la fonction. En
particulier, si une entrée est déterminée comme étant au format JSON, elle est alors traitée comme
des données JSON lors du calcul de la valeur de retour. L' exemple 191 (page 194) illustre cela —
il utilise explicitement FORMAT JSON pour interpréter la chaîne SQL "true" comme la valeur
booléenne JSON true.
Comportement facultatif pour les fonctions de génération SQL/JSON
Vous pouvez éventuellement spécifier une clause de gestion SQL NULL, une clause RETURNING
et le mot clé STRICT.
• Clause de gestion NULL — Détermine comment une valeur SQL NULL résultant de l'évaluation de
l'entrée est gérée.
– NULL ON NULL — Une valeur SQL NULL en entrée est convertie en JSON null pour la sortie.
C'est le comportement par défaut pour json_array et json_arrayagg.
– ABSENT ON NULL — Une valeur SQL NULL en entrée n'entraîne aucune sortie correspondante.
C'est le comportement par défaut pour json_object et json_objectagg.
• Clause RETURNING — Le type de données SQL utilisé pour la valeur de retour de la fonction. Le
la valeur par défaut est VARCHAR2(4000).
JSON_OBJECT Fonction SQL/JSON
• Motclé STRICT — S'il est présent, les données JSON renvoyées sont vérifiées pour s'assurer qu'elles
sont bien formées. Si STRICT est présent et que les données renvoyées ne sont pas bien formées,
une erreur est générée.
Résultat renvoyé par les fonctions de génération SQL/JSON Les
données JSON générées sont renvoyées par la fonction sous la forme d'une valeur SQL VARCHAR2,
dont la taille peut être contrôlée par la clause facultative RETURNING. Pour les fonctions SQL
d'agrégation (json_objectagg et json_arrayagg), vous pouvez également spécifier CLOB comme type de
données SQL dans la clause RETURNING.
Les valeurs JSON dans les données renvoyées sont dérivées des valeurs SQL dans l'entrée comme
suit :
• Un numéro SQL est converti en un numéro JSON.
• Une valeur SQL non NULL et non numérique est convertie en chaîne JSON.
• Une valeur SQL NULL est gérée par la clause facultative de gestion NULL.
Voir également:
fonction json_array
fonction json_arrayagg
fonction json_object
• Oracle Database SQL Language Reference pour plus d'informations sur la fonction SQL/JSON
json_objectagg
Exemple 191 Déclaration d'une valeur d'entrée au format JSON
Cet exemple spécifie FORMAT JSON pour les valeurs de chaîne SQL 'true' et 'false', afin que les valeurs
booléennes JSON true et false soient utilisées.
'
SELECT json_object('nom' VALUE prénom || ' || nom de famille,
'aCommission' VALEUR
CASE WHEN commission_pct IS NULL THEN 'false' ELSE 'true'
FIN FORMAT JSON)
FROM employés WHERE prénom LIKE 'W%' ;
JSON_OBJECT('NAME'ISFIRST_NAME||''||LAST_NAME,'

{"name":"William Gietz","hasCommission":false}
{"name":"William Smith","hasCommission":true}
{"name":"Winston Taylor","hasCommission":false}
19.2 JSON_OBJECT Fonction SQL/JSON
La fonction SQL/JSON json_object construit des objets JSON à partir de paires nomvaleur.
Chaque paire est fournie comme argument explicite. Chaque nom d'une paire doit correspondre à un
identifiant SQL. Chaque valeur d'une paire peut être n'importe quelle expression SQL . Le nom et la valeur
sont séparés par le mot clé VALUE.
JSON_OBJECT Fonction SQL/JSON
Les arguments évalués que vous fournissez à json_object sont des noms de champ d'objet explicites
et des valeurs de champ. L'objet résultant a un membre pour chaque paire d'arguments nomvaleur
que vous fournissez (sauf lorsqu'une expression de valeur prend la valeur SQL NULL et que la clause
ABSENT ON NULL s'applique).
Exemple 192 Utilisation de JSON_OBJECT pour construire des objets JSON
Cet exemple construit un objet JSON pour chaque employé de la table hr.employees (du schéma
de base de données standard HR) dont le salaire est inférieur à 15000. L'objet inclut, comme
valeur de son champ contactInfo, un objet avec les champs mail et phone.
Étant donné que la valeur de retour de json_object est une donnée JSON, FORMAT JSON est
déduit pour le format d'entrée du champ contactInfo — le FORMAT JSON explicite ici n'est pas
nécessaire.
SELECT json_object('id' VALUE identifiant_employé,
'Nom' '
VALUE prénom || ' || nom de famille,
'Date d'embauche' VALUE date_embauche,
'payer' VALUE salaire,
'contactInfo' VALUE json_object('mail' VALUE email, 'phone' VALUE phone_number)
FORMAT JSON)
DES employés
OÙ salaire > 15000 ;
La requête renvoie des lignes telles que celleci (assez imprimées ici pour plus de clarté) :
{"id":101,
"name":"Neena Kochhar",
"hireDate":"21SEP05", "pay":17000,
"contactInfo":{"mail":"NKOCHHAR",
"téléphone" :"515.123.4568"}}
Exemple 193 Utilisation de JSON_OBJECT avec ABSENT ON NULL
Cet exemple interroge la table hr.locations du schéma de base de données standard HR pour
créer des objets JSON avec des champs city et province.
Le comportement de gestion NULL par défaut pour json_object est NULL ON NULL.
Afin d'empêcher la création d'un champ avec une valeur JSON nulle, l'exemple utilise ABSENT ON
NULL. La valeur SQL NULL pour la colonne state_province lorsque la colonne city a la valeur
'Singapore' signifie qu'aucun champ de province n'est créé pour cet emplacement.
SELECT JSON_OBJECT('ville' VALUE ville,
'province' VALUE état_province ABSENT ON NULL)
DE emplacements
WHERE ville LIKE 'S%' ;
JSON_OBJECT('CITY'ISCITY,'PROVINCE'ISSTATE_PROVINCEABSENTONNULL)

{"city":"Southlake","province":"Texas"} {"city":"South San
Francisco","province":"California"} {"city":"South Brunswick","province": "New Jersey"}
{"city":"Seattle","province":"Washington"} {"city":"Sydney","province":"NouvelleGalles
du Sud"} {"city":"Singapour"} {"city":"Stretford","province":"Manchester"} {"city":"São
Paulo","province":"São Paulo"}
JSON_ARRAY Fonction SQL/JSON
Voir également:
• Présentation des fonctions de génération SQL/JSON (page 191)
fonction json_object
• Oracle Database SQL Language Reference pour la syntaxe de l'identificateur SQL
19.3 JSON_ARRAY Fonction SQL/JSON La fonction SQL/JSON
json_array construit un tableau JSON à partir des résultats de l'évaluation de ses expressions SQL
en argument. Chaque argument peut être n'importe quelle expression SQL.
L'ordre des éléments du tableau est le même que l'ordre des arguments.
Les arguments évalués que vous fournissez à json_array sont des valeurs d'éléments de tableau
explicites. Le tableau résultant a un élément pour chaque argument que vous fournissez (sauf lorsqu'une
expression d'argument est évaluée à SQL NULL et que la clause ABSENT ON NULL s'applique).
Une expression d'argument qui prend la valeur d'un nombre SQL est convertie en un nombre JSON.
Une valeur d'argument non NULL et non numérique est convertie en chaîne JSON.
Exemple 194 Utilisation de JSON_ARRAY pour construire un tableau JSON
Cet exemple construit un objet JSON pour chaque tâche dans la table de base de données hr.jobs (à partir
du schéma de base de données standard HR). Les champs des objets sont l'intitulé du poste et l'échelle
salariale. La fourchette de salaires (champ salarialRange) est un tableau de deux valeurs numériques, les
salaires minimum et maximum pour le poste. Ces valeurs sont extraites des colonnes SQL min_salary et
max_salary.
SELECT json_object('titre' VALUE job_title,
'salaryRange' VALUE json_array(min_salary, max_salary))
D'emplois ;
JSON_OBJECT('TITLE'ISJOB_TITLE,'SALARYRANGE'ISJSON_ARRAY(MIN_SALARY,MAX_SALARY))

{"title":"Président","salaryRange":[20080,40000]} {"title":"Vice
président administratif","salaryRange":[15000,30000]} {"title":"Assistant administratif",
"salaryRange":[3000,6000]} {"title":"Finance Manager","salaryRange":[8200,16000]}
{"title":"Comptable","salaryRange":[4200,9000]} { "title":"Responsable comptable","salaryRange":
[8200,16000]} {"title":"Comptable public","salaryRange":[4200,9000]} {"title":"Responsable
commercial"," salaireRange":[10000,20080]} {"title":"Représentant des ventes","salaryRange":
[6000,12008]} {"title":"Responsable des achats","salaryRange":[8000,15000]} { "title":"Commis
aux achats","salaryRange":[2500,5500]} {"title":"Gestionnaire des stocks","salaryRange":
[5500,8500]} {"title":"Commis aux stocks"," salaireRange":[2008,5000]} {"title":"Commis aux
expéditions","salaryRange":[2500,5500]} {"title":"Programmeur","salaryRange":[4000,10000]} {"
title":"Responsable marketing","salaryRange":[9000,15000]} {"title":"Représentant
marketing","salaryRange":[4000,9000]} {"title":"Représentant des ressources humaines"," Sala
ryRange":[4000,9000]} {"title":"Représentant des relations publiques","salaryRange":[4500,10500]}
JSON_OBJECTAGG Fonction SQL/JSON
Voir également:
fonction json_array
• Fonction SQL/JSON JSON_OBJECT (page 194)
19.4 JSON_OBJECTAGG Fonction SQL/JSON
La fonction SQL/JSON json_objectagg construit un objet JSON en agrégeant les informations
de plusieurs lignes d'une requête SQL groupée en tant que membres de l'objet.
Contrairement au cas de la fonction SQL/JSON json_object, où le nombre de membres dans
l'objet résultant reflète directement le nombre d'arguments, pour json_objectagg, la taille de
l'objet résultant reflète les données actuellement interrogées. Il peut donc varier en fonction des
données interrogées.
Exemple 195 Utilisation de JSON_OBJECTAGG pour construire un objet JSON
Cet exemple construit un objet JSON unique à partir de la table hr.departments (à partir du
schéma de base de données standard HR) en utilisant les noms de champ extraits de la colonne
department_name et les valeurs de champ extraites de la colonne department_id.
SELECT json_objectagg(department_name VALUE department_id) FROM départements ;
L'objet renvoyé est joliment imprimé ici pour plus de clarté.
L'ordre des membres de l'objet est arbitraire.
JSON_OBJECTAGG(DEPARTMENT_NAMEISDEPARTMENT_ID)

{"Administration": 10,
"Commercialisation": 20,
"Achat": 30,
"Ressources humaines": 40,
"Expédition": 50,
"IL": 60,
"Relations publiques": 70,
"Ventes": 80,
"Exécutif": 90,
"Finance": 100,
"Comptabilité": 110, 120,
"Trésorerie":
« Impôt sur les sociétés » : 130,
"Contrôle et crédit": 140,
« Service Actionnaires » : 150,
"Avantages": 160, 170, 180, 190, 200,
"Fabrication": 210,
"Construction": 220,
« Contractualiser » : 230,
"Opérations": 240,
"Support Informatique": 250,
"CNO": 260,
"Service d'assistance informatique": 270}
"Ventes gouvernementales":
"Ventes au détail":
"Recrutement":
"Paie":
JSON_ARRAYAGG Fonction SQL/JSON
Voir également:
SQL/JSON json_objectagg
19.5 JSON_ARRAYAGG Fonction SQL/JSON
La fonction SQL/JSON json_arrayagg construit un tableau JSON en agrégeant les informations
de plusieurs lignes d'une requête SQL groupée en tant qu'éléments du tableau. L'ordre des éléments
du tableau reflète l'ordre des résultats de la requête, par défaut, mais vous pouvez utiliser la clause
ORDER BY pour imposer l'ordre des éléments du tableau.
Contrairement au cas de la fonction SQL/JSON json_array, où le nombre d'éléments dans le tableau
résultant reflète directement le nombre d'arguments, pour json_arrayagg, la taille du tableau résultant
reflète les données actuellement interrogées. Il peut donc varier en fonction des données interrogées.
Exemple 196 Utilisation de JSON_ARRAYAGG pour construire un tableau JSON
Cet exemple construit un objet JSON pour chaque employé de la table hr.employees (du schéma
de base de données standard HR) qui est un gestionnaire en charge d'au moins six employés.
Les objets ont des champs pour le numéro d'identification du responsable, le nom du responsable,
le nombre d'employés relevant du responsable et les numéros d'identification de ces employés.
L'ordre des numéros d'identification des employés dans le tableau est déterminé par la clause
ORDER BY pour json_arrayagg. La direction par défaut pour ORDER BY est ASC (croissant).
Les éléments du tableau, qui sont numériques, sont dans l'ordre numérique croissant.
SELECT json_object('id' VALUE mgr.employee_id,
'manager' VALUE (mgr.first_name || ' '|| mgr.nom_de_famille),
'numReports' VALUE count(rpt.employee_id), VALUE
json_arrayagg(rpt.employee_id 'rapports'
COMMANDER PAR rpt.employee_id))
FROM employés mgr, employés rpt WHERE
mgr.employee_id = rpt.manager_id GROUP BY
mgr.employee_id, mgr.last_name, mgr.first_name HAVING
count(rpt.employee_id) > 6 ;
L'objet renvoyé est joliment imprimé ici pour plus de clarté.
JSON_OBJECT('ID'ISMGR.EMPLOYEE_ID,'MANAGER'VALUE(MGR.FIRST_NAME||''||MGR.LAST_NAME)

{"id": 100,
"manager": "Steven King",
"numReports": 14,
"rapports": [101,102,114,120,121,122,123,124,145,146,147,148,149,201]}
{"id": 120,
"manager": "Matthieu Weiss",
"numReports": 8,
"rapports": [125,126,127,128,180,181,182,183]}
{"id": 121,
"manager": "Adam Fripp",
"numReports": 8,
"rapports": [129,130,131,132,184,185,186,187]}
{"id": 122,
"manager": "Payam Kaufling",
"numReports": 8,
"rapports": [133,134,135,136,188,189,190,191]}
{"id": 123,
"manager": "Shanta Vollman",
"numReports": 8,
"rapports": [137,138,139,140,192,193,194,195]}
{"id": 124,
"manager": "Kévin Mourgos",
"numReports": 8,
"rapports": [141,142,143,144,196,197,198,199]}
Voir également:
fonction json_arrayagg
Partie VI
Types d'objets PL/SQL pour JSON
Vous pouvez utiliser des types d'objet PL/SQL pour JSON afin de lire et d'écrire plusieurs champs d'un
document JSON. Cela peut augmenter les performances, notamment en évitant de multiples analyses et
sérialisations des données.
Chapitres
Présentation des types d'objets PL/SQL pour JSON (page 201)
Les types d'objets PL/SQL permettent une construction et une manipulation par
programmation fines des données JSON en mémoire. Vous pouvez l'introspecter, le
modifier et le sérialiser en données textuelles JSON.
Utilisation des types d'objet PL/SQL pour JSON (page 211)
Quelques exemples d'utilisation de types d'objets PL/SQL pour JSON sont présentés.
20
Présentation des types d'objets PL/SQL pour JSON
Les types d'objets PL/SQL permettent une construction et une manipulation par programmation fines des données
JSON en mémoire. Vous pouvez l'introspecter, le modifier et le sérialiser en données textuelles JSON.
Les principaux types d'objets PL/SQL JSON sont JSON_ELEMENT_T, JSON_OBJECT_T, JSON_ARRAY_T
et JSON_SCALAR_T. Un autre type d'objet moins utilisé est JSON_KEY_LIST, qui est un varray de
VARCHAR2(4000). Les types d'objets sont également appelés types de données abstraits (ADT).
Ces types d'objets JSON fournissent une représentation programmatique en mémoire, hiérarchique (semblable à
une arborescence) des données JSON qui sont stockées dans la base de données.11 Vous pouvez utiliser les
types d'objets pour manipuler par programme les données JSON en mémoire, Suivant:
• Vérifiez la structure, les types ou les valeurs des données JSON existantes. Par exemple, vérifiez si la valeur
d'un champ d'objet donné satisfait certaines conditions.
• Transformez les données JSON existantes. Par exemple, convertir une adresse ou un numéro de téléphone
formats pour suivre une convention particulière.
• Créez des données JSON à l'aide de règles de programmation qui correspondent aux caractéristiques
de tout ce que les données représentent. Par exemple, si un produit à représenter sous la forme d'un
objet JSON est inflammable, incluez des champs qui représentent des informations de sécurité.
Les instances de type objet PL/SQL sont transitoires. Pour stocker les informations qu'ils contiennent de
manière persistante, vous devez les sérialiser en données VARCHAR2 ou LOB, que vous pouvez ensuite
stocker dans une table de base de données ou marshaler vers un client de base de données tel que Java
Database Connectivity (JDBC).
Vous construisez une instance de type objet en mémoire soit en une seule fois, en analysant du texte JSON,
soit au coup par coup, en commençant par un objet ou une instance de tableau vide et en y ajoutant des
membres d'objet ou des éléments de tableau.
Une instance de type objet inutilisée est automatiquement récupérée ; vous ne pouvez pas et n'avez pas
besoin de libérer la mémoire utilisée par une instance dont vous n'avez plus besoin.
Généralement, après avoir construit une instance de type objet PL/SQL et peutêtre l'avoir utilisée par
programme de diverses manières, vous la sérialisez en une instance de type de données VARCHAR2, CLOB ou
BLOB. Autrement dit, vous convertissez la représentation transitoire des données JSON en mémoire en une
représentation persistante dans la base de données. (Vous pouvez également le sérialiser uniquement en tant
que texte à imprimer.)
1 Ceci est similaire à ce qui est disponible pour les données XML à l'aide du modèle d'objet de document (DOM), un modèle
d'objet et une API indépendants du langage et de la plateforme pour accéder à la structure des documents XML
recommandés par le World Wide Web Consortium (W3C ).
Présentation des types d'objets PL/SQL pour JSON 201
Relations entre les types d'objets JSON Le type
JSON_ELEMENT_T est le supertype des autres types d'objets JSON : chacun d'eux l'étend en tant que sous
type. Les soustypes JSON_OBJECT_T et JSON_ARRAY_T sont utilisés respectivement pour les objets
JSON et les tableaux. Le soustype JSON_SCALAR_T est utilisé pour les valeurs JSON scalaires : chaînes,
nombres, les valeurs booléennes true et false, et la valeur
nul.
Vous pouvez construire une instance de type JSON_ELEMENT_T uniquement en analysant le texte JSON.
L'analyse crée une instance JSON_ELEMENT_T, qui est une représentation en mémoire des données
JSON. Vous ne pouvez pas construire une instance vide de type JSON_ELEMENT_T ou de type
JSON_SCALAR_T.
Les types JSON_OBJECT_T et JSON_ARRAY_T ont chacun une fonction constructeur du même nom que
le type, que vous pouvez utiliser pour construire une instance du type : une représentation vide (en mémoire)
d'un objet ou d'un tableau JSON, respectivement. Vous pouvez ensuite remplir cet objet ou tableau selon
vos besoins, en ajoutant des membres d'objet ou des éléments de tableau, représentés par des instances
de type d'objet PL/SQL.
Vous pouvez convertir une instance de JSON_ELEMENT_T en une instance de soustype, à l'aide de la
fonction Treat PL/SQL. Par exemple, treat(elt as JSON_OBJECT_T) convertit l'instance elt en objet JSON
(instance de JSON_OBJECT_T).
Fonction d'analyse
L' analyse de fonction statique accepte une instance de type VARCHAR2, CLOB ou BLOB comme
argument, qu'elle analyse en tant que texte JSON pour renvoyer une instance de type
JSON_ELEMENT_T, JSON_OBJECT_T ou JSON_ARRAY_T. Pour BLOB, vous ne pouvez utiliser que des
données codées UTF8. Une erreur est générée si l'entrée d'analyse n'est pas une donnée JSON bien formée
ou si l'encodage n'est pas UTF8.
Méthodes de sérialisation
L'analyse accepte les données d'entrée JSON sous forme de texte et renvoie une instance d'un type
d'objet PL/SQL JSON. La sérialisation fait essentiellement le contraire : vous l'appliquez à une représentation
d'objet PL/SQL de données JSON et elle renvoie une représentation textuelle de cet objet. Les méthodes de
sérialisation ont des noms commençant par le préfixe to_. Par exemple, la méthode to_string() renvoie une
représentation sous forme de chaîne (VARCHAR2) de l'instance de type d'objet JSON à laquelle vous
l'appliquez.
La plupart des méthodes de sérialisation sont des fonctions membres. Pour la sérialisation en tant qu'instance
CLOB ou BLOB, cependant, il existe deux formes de méthodes : une fonction membre et une procédure
membre . La fonction membre n'accepte aucun argument. Il crée un LOB temporaire comme destination de
sérialisation. La procédure membre accepte un argument LOB IN OUT (instance CLOB pour la méthode
to_clob, BLOB pour la méthode to_blob). Vous pouvez ainsi lui passer le LOB (éventuellement vide) que vous
souhaitez utiliser pour la représentation sérialisée.
Méthodes getter et setter
Les types JSON_OBJECT_T et JSON_ARRAY_T ont des méthodes getter et setter, qui obtiennent et
mettent à jour, respectivement, les valeurs d'un champ d'objet donné ou d'une position d'élément de tableau
donnée.
Il existe deux types de méthode getter :
• La méthode get() renvoie une référence à l'objet d'origine auquel vous l'appliquez, en tant qu'instance de
type JSON_ELEMENT_T. Autrement dit, l'objet auquel vous l'appliquez est passé par référence : si
vous modifiez ensuite l'instance JSON_ELEMENT_T renvoyée, vos modifications s'appliquent à l'objet
d'origine auquel vous avez appliqué get().
• Les méthodes getter dont les noms ont le préfixe get_ renvoient une copie de toutes les données
ciblées dans l'objet ou le tableau auquel elles sont appliquées. Ces données sont transmises par
valeur et non par référence.
Par exemple, si vous appliquez la méthode get_string() à une instance JSON_OBJECT_T,
en passant un champ donné comme argument, elle renvoie une copie de la chaîne qui est la
valeur de ce champ. Si vous appliquez get_string() à une instance JSON_ARRAY_T, en passant une
position d'élément donnée comme argument, il renvoie une copie de la chaîne à cette position dans
le tableau.
Comme les méthodes de sérialisation, la plupart des méthodes getter sont des fonctions membres.
Mais les méthodes get_clob() et get_blob(), qui renvoient la valeur d'un champ d'objet donné ou
l'élément à une position de tableau donnée en tant qu'instance CLOB ou BLOB, ont deux formes
(comme les méthodes de sérialisation to_clob() et to_blob()) : une fonction membre et une procédure
membre. La fonction membre n'accepte aucun argument autre que le champ d'objet ciblé ou la position du
tableau. Il crée et renvoie une instance LOB temporaire.
La procédure membre accepte également un argument LOB IN OUT (CLOB pour get_clob, BLOB pour
get_blob). Vous pouvez ainsi lui passer l'instance LOB (éventuellement vide) à utiliser.
Les méthodes setter sont put(), put_null() et (pour JSON_ARRAY_T uniquement) append().
Ceuxci mettent à jour l'objet ou l'instance de tableau auquel ils sont appliqués, en définissant la
valeur du champ d'objet ou de l'élément de tableau ciblé. Remarque : Les méthodes de définition modifient
l'instance existante au lieu d'en renvoyer une copie modifiée.
La méthode append() ajoute un nouvel élément à la fin de l'instance du tableau. La méthode
put_null() définit un champ d'objet ou une valeur d'élément de tableau sur JSON null.
La méthode put() nécessite un deuxième argument (en plus du nom du champ objet ou de la position
de l'élément du tableau), qui est la nouvelle valeur à définir. Pour un tableau, put() accepte également
un troisième argument facultatif, OVERWRITE. Il s'agit d'une valeur booléenne (FALSE par défaut) qui
indique s'il faut remplacer une valeur existante à la position donnée.
•
Si l'objet a déjà un champ du même nom, alors put() remplace cette valeur par la nouvelle valeur.
• Si le tableau a déjà un élément à la position donnée, alors, par défaut, put() décale cet élément et
tous les éléments successifs vers l'avant (en incrémentant leurs positions de un) pour faire de la
place pour le nouvel élément, qui est placé à la position donnée. Mais si l'argument optionnel
OVERWRITE est présent et vaut TRUE, alors l'élément existant à la position donnée est simplement
remplacé par le nouvel élément.
Méthodes d'introspection
Le type JSON_ELEMENT_T a des méthodes d'introspection que vous pouvez utiliser pour déterminer
si une instance est un objet JSON, un tableau, un scalaire, une chaîne, un nombre ou un booléen,
ou si c'est la valeur JSON true, false ou null. Les noms de ces méthodes commencent par le préfixe
is_. Ce sont des prédicats renvoyant une valeur booléenne.
Il a également la méthode d'introspection get_size(), qui renvoie le nombre de membres d'une instance
JSON_OBJECT_T et le nombre d'éléments d'une instance JSON_ARRAY_T (elle renvoie 1 pour une
instance JSON_SCALAR_T).
Le type JSON_ELEMENT_T possède également des méthodes d'introspection is_date()
et is_timestamp(), qui testent si une instance représente une date ou un horodatage.
JSON n'a pas de types natifs pour les dates ou les horodatages ; ceuxci représentent généralement
l'utilisation de chaînes JSON. Mais si une instance JSON_ELEMENT_T est construite à l'aide de données
SQL de type de données SQL DATE ou TIMESTAMP, ces informations de type sont conservées pour la
représentation d'objet PL/SQL.
Présentation des types d'objets PL/SQL pour JSON 203
Les données de date et d'horodatage sont représentées à l'aide du type d'objet PL/SQL JSON_SCALAR_T,
dont vous ne pouvez pas construire directement les instances. Vous pouvez cependant ajouter une telle valeur
à un objet (en tant que valeur de champ) ou à un tableau (en tant qu'élément) à l'aide de la méthode put(). La
récupérer à l'aide de la méthode get() renvoie une instance JSON_SCALAR_T.
Les types JSON_OBJECT_T et JSON_ARRAY_T ont une méthode d'introspection get_type(),
qui renvoie le type JSON du champ d'objet ciblé ou de l'élément de tableau (en tant qu'instance
VARCHAR2). Le type JSON_OBJECT_T a également des méthodes d'introspection has(), qui renvoie
TRUE si l'objet a un champ du nom donné, et get_keys(), qui renvoie une instance du type d'objet PL/SQL
JSON_KEY_LIST, qui est un varray de type VARCHAR2(4000 ). Le varray contient les noms des champs2
2 présents dans l'instance JSON_OBJECT_T donnée.
Autres méthodes
Les types JSON_OBJECT_T et JSON_ARRAY_T ont les méthodes suivantes :
• remove() — Supprime le membre objet avec le champ donné ou l'élément de tableau
à la position donnée.
• clone() — Crée et renvoie une copie (profondie) de l'objet ou du tableau auquel la méthode est appliquée.
La modification d'une partie de cette copie n'a aucun effet sur l'objet ou le tableau d'origine.
Le type JSON_OBJECT_T a la méthode rename_key(), qui renomme un champ d'objet donné.2 Si le
nouveau nom fourni nomme déjà un champ existant, une erreur est générée.
Voir également:
• Utilisation des types d'objet PL/SQL pour JSON (page 211)
JSON_ARRAY_T
JSON_ELEMENT_T
JSON_OBJECT_T et JSON_KEY_LIST
JSON_SCALAR_T
2 Un champ d'objet est parfois appelé « clé » d'objet.
21
Utilisation des types d'objet PL/SQL pour JSON
Quelques exemples d'utilisation de types d'objets PL/SQL pour JSON sont présentés.
Voir également:
• Présentation des types d'objets PL/SQL pour JSON (page 201)
JSON_ARRAY_T
JSON_ELEMENT_T
JSON_OBJECT_T
JSON_KEY_LIST
Exemple 211 Construction et sérialisation d'un objet JSON en mémoire
Cet exemple utilise la fonction parse pour analyser une chaîne de données JSON qui représente un
objet JSON avec un champ, nom, créant une instance je du type d'objet JSON_ELEMENT_T. Cette
instance est testée pour voir si elle représente un objet, en utilisant la méthode d'introspection
(prédicat) is_object().
S'il représente un objet (le prédicat renvoie TRUE pour je), il est converti en une instance de
JSON_OBJECT_T et affecté à la variable jo. La méthode put() pour le type d'objet JSON_OBJECT_T
est ensuite utilisée pour ajouter le prix du champ d'objet avec la valeur 149,99.
Enfin, l'instance JSON_ELEMENT_T je (qui contient les mêmes données en mémoire que
l'instance JSON_OBJECT_T jo) est sérialisée en une chaîne à l'aide de la méthode to_string(), et cette
chaîne est imprimée à l'aide de la procédure DBMS_OUTPUT.put_line. Le résultat imprimé montre
l'objet mis à jour comme {"name":"Avion radiocommandé","price":149.99}.
L'objet transitoire mis à jour je est sérialisé ici uniquement pour être imprimé ; le texte résultant n'est pas
stocké dans la base de données. Quelque temps après l'exécution de l'exemple de code, la mémoire
allouée aux instances de type objet je et jo est récupérée par le ramassemiettes.
DÉCLARER
je JSON_ELEMENT_T ; jo
JSON_OBJECT_T ;
COMMENCER
je := JSON_ELEMENT_T.parse('{"name":" Avion radiocommandé"}'); IF (je.is_Object) THEN jo :=
treat(je AS JSON_OBJECT_T);
Utilisation des types d'objet PL/SQL pour JSON 211
jo.put('prix', 149.99); FIN SI;
DBMS_OUTPUT.put_line(je.to_string); FIN; /
Exemple 212 Utilisation de la méthode GET_KEYS() pour obtenir une liste de champs d'objet
La méthode PL/SQL get_keys() est définie pour le type d'objet PL/SQL JSON_OBJECT_T.
Il renvoie une instance du type d'objet PL/SQL JSON_KEY_LIST, qui est un varray de
VARCHAR2(4000). Le varray contient tous les noms de champ pour l'instance
JSON_OBJECT_T donnée.
Cet exemple parcourt les champs renvoyés par get_keys(), en les ajoutant à une instance
du type d'objet PL/SQL JSON_ARRAY_T. Il utilise ensuite la méthode to_string() pour
sérialiser ce tableau JSON, puis imprime la chaîne résultante.
DÉCLARER
Jo JSON_OBJECT_T ;
ja JSON_ARRAY_T ;
clés JSON_KEY_LIST ;
clés_chaîne VARCHAR2(100);
COMMENCER
ja := nouveau JSON_ARRAY_T ;
jo := JSON_OBJECT_T.parse('{"name":"Beda",
"jobTitle":"codmonki", "projects":
["json", "xml"]}');
keys := jo.get_keys; FOR i
IN 1..keys.COUNT LOOP
ja.append(keys(i)); FIN DE
BOUCLE ; keys_string := ja.to_string;
DBMS_OUTPUT.put_line(keys_string);
FIN; /
La sortie imprimée est ["name","jobTitle","projects"].
Exemple 213 Utilisation de la méthode PUT() pour mettre à jour des parties de documents JSON
Cet exemple met à jour chaque document de bon de commande dans la colonne JSON
po_document de la table j_purchaseorder. Il itère sur le tableau JSON LineItems dans
chaque document (variable li_arr), en calculant le prix total et la quantité pour chaque objet
d'élément de ligne (variable li_obj), et il utilise la méthode put() pour ajouter ces totaux à
li_obj comme valeurs de new champs totalQuantity et totalPrice. Ceci est fait par la fonction
définie par l'utilisateur add_totals.
L'instruction SELECT sélectionne ici l'un des documents qui a été mis à jour.
CRÉER OU REMPLACER LA FONCTION add_totals(purchaseOrder IN VARCHAR2) RETURN VARCHAR2 IS
po_obj JSON_OBJECT_T ;
li_arr JSON_ARRAY_T ;
li_item JSON_ELEMENT_T ;
li_obj JSON_OBJECT_T ;
unitPrice NUMÉRO;
quantité NUMÉRO;
totalPrix NOMBRE := 0;
totalQuantity NUMBER := 0;
COMMENCER
po_obj := JSON_OBJECT_T.parse(purchaseOrder); li_arr :=
po_obj.get_Array('LineItems'); POUR i EN 0 .. li_arr.get_size 1
BOUCLE
li_obj := JSON_OBJECT_T(li_arr.get(i)); quantité :=
li_obj.get_Number('Quantité'); unitPrice :=
li_obj.get_Object('Part').get_Number('UnitPrice'); prixtotal := prixtotal + (quantité * prixunitaire);
totalQuantity := totalQuantity + quantité ; FIN DE BOUCLE ;
po_obj.put('totalQuantity', totalQuantity); po_obj.put('prixtotal',
prixtotal); RETURN po_obj.to_string ; FIN; /
MISE À JOUR j_purchaseorder SET (po_document) = add_totals(po_document);
SELECT po_document FROM j_purchaseorder po WHERE po.po_document.PONumber = 1600;
Cela sélectionne ce document mis à jour :
{"PONuméro": 1600,
"Référence": "ABULL20140421",
"Demandeur": "Alexis Bull",
"Utilisateur": "ABULL",
"Centre de coûts": "A50",
"ShippingInstructions": {"name": "Alexis Bull",
"Address": {"street": "200 Sporting Green", "city": "South San
Francisco", "state": "CA", "zipCode": 99236,
"country": "ÉtatsUnis d'Amérique"} ,
"Téléphone": [{"type": "Bureau", "numéro": "9095557307"},
{"type": "Mobile", "number": "4155551234"}]},
"Instructions spéciales": null,
"AllowPartialShipment": vrai, "LineItems":
[{"ItemNumber": 1, "Part": {"Description": "Un
Noël magique", "UnitPrice": 19,95, "UPCCode": 13131092899},
"Quantité": 9.0},
{"ItemNumber": 2, "Part":
{"Description": "Lethal Weapon", "UnitPrice": 19.95,
"UPCCode": 85391628927}, "Quantity": 5.0}],
"totalQuantity": 14, "totalPrice " : 279.3}
Utilisation des types d'objet PL/SQL pour JSON 213
Partie VII
Données géographiques GeoJSON
Les données GeoJSON sont des données géographiques JSON. Oracle Spatial and Graph prend en charge
l'utilisation d'objets GeoJSON pour stocker, indexer et gérer les données GeoJSON.
Chapitres
Utilisation des données géographiques GeoJSON (page 221)
Les objets GeoJSON sont des objets JSON qui représentent des données géographiques.
Des exemples sont fournis pour créer des données GeoJSON, les indexer et les interroger.
22
Utilisation des données géographiques GeoJSON
Les objets GeoJSON sont des objets JSON qui représentent des données géographiques. Des
exemples sont fournis pour créer des données GeoJSON, les indexer et les interroger.
Objets GeoJSON : géométrie, entité, collection d'entités GeoJSON utilise des
objets JSON qui représentent diverses entités géométriques et des combinaisons de cellesci
avec des propriétés définies par l'utilisateur.
Une position est un tableau de deux coordonnées spatiales (numériques) ou plus, dont les trois premières
représentent généralement la longitude, la latitude et l'altitude.
Un objet géométrique a un champ de type et (à l'exception d'un objet de collection de géométrie) un
champ de coordonnées, comme indiqué dans le Tableau 221 (page 221).
Une collection de géométrie est un objet de géométrie avec le type GeometryCollection.
Au lieu d'un champ de coordonnées, il a un champ de géométries, dont la valeur est un tableau d'objets
géométriques autres que des objets GeometryCollection.
Tableau 221 Objets de géométrie GeoJSON autres que les collections de géométrie
saisir le champ Coordonnées Champ
Point Une position.
MultiPoint Une panoplie de postes.
ChaîneLigne Un tableau de deux positions ou plus.
MultiLineString Un tableau de tableaux LineString de positions.
Polygone Un MultiLineString, dont chacun des tableaux est un LineString dont les première et
dernière positions coïncident (sont équivalentes). Si le tableau d'un polygone contient
plus d'un tableau, le premier représente le polygone extérieur et les autres représentent
les trous à l'intérieur.
Multipolygone Un tableau de tableaux de polygones, c'estàdire un tableau multidimensionnel
de positions.
Un objet de fonctionnalité a un champ de type de valeur Feature, un champ de géométrie dont la valeur est
un objet géométrique et un champ de propriétés dont la valeur peut être n'importe quel objet JSON.
Un objet de collection de fonctionnalités a un champ de type de valeur FeatureCollection et un champ de
fonctionnalités dont la valeur est un tableau d'objets de fonctionnalité.
L'exemple 221 (page 222) présente un objet de collection de caractéristiques dont le tableau de
caractéristiques a trois caractéristiques. La géométrie de la première entité est de type Point ; celui du
second est de type LineString ; et celui du troisième est de type Polygon.
Utilisation des données géographiques GeoJSON 221
Interroger et indexer les données
GeoJSON Vous pouvez utiliser les fonctions et conditions de requête SQL/JSON pour examiner les
données GeoJSON ou pour en projeter des parties en tant que données non JSON, y compris en tant
qu'instances de type objet Oracle Spatial et Graph SDO_GEOMETRY. Ceci est illustré dans l' exemple
222 (page 223), l'exemple 223 (page 223) et l'exemple 225 (page 224).
Pour améliorer les performances des requêtes, vous pouvez créer un index Oracle Spatial and Graph
(type MDSYS.SPATIAL_INDEX) sur la fonction json_value appliquée aux données GeoJSON.
Ceci est illustré par l' exemple 224 (page 224).
Instances de type objet SDO_GEOMETRY et opérations spatiales Vous pouvez
convertir des instances de type objet Oracle Spatial et Graph SDO_GEOMETRY en objets GeoJSON
et des objets GeoJSON en instances SDO_GEOMETRY.
Vous pouvez utiliser des opérations Oracle Spatial et Graph sur des objets SDO_GEOMETRY que vous
obtenez à partir d'objets GeoJSON. Par exemple, vous pouvez utiliser l'opérateur sdo_distance dans le
package PL/SQL SDO_GEOM pour calculer la distance minimale entre deux objets géométriques. Il
s'agit de la distance entre les deux points ou deux segments les plus proches, un point ou un segment de
chaque objet. Ceci est illustré par l'exemple 225 (page 224).
Voir également:
• Guide du développeur Oracle Spatial and Graph pour plus d'informations sur l'utilisation
Données GeoJSON avec Oracle Spatial et Graph
• Guide du développeur Oracle Spatial and Graph pour plus d'informations sur Oracle
Type d'objet spatial et graphique et SDO_GEOMETRY
• http://geojson.org pour plus d'informations sur GeoJSON
• La spécification de format GeoJSON, http://geojson.org/geojsonspec.html pour plus de
détails sur les données GeoJSON
Exemple 221 Une table avec des données GeoJSON
Cet exemple crée la table j_geo, qui a une colonne, geo_doc de documents GeoJSON.
Un seul de ces documents est inséré ici. Il contient un objet GeoJSON de type FeatureCollection
et un tableau d'objets de type Feature. Ces objets ont respectivement une géométrie de type Point,
LineString et Polygon.
CRÉER TABLE j_geo
(id VARCHAR2 (32) NOT NULL,
geo_doc VARCHAR2 (4000) CHECK (geo_doc IS JSON));
INSERT INTO j_geo
VALUES (1, '{"type"
: "Collection de fonctionnalités",
"fonctionnalités" : [{"type" : "Entité",
"géométrie" : {"type" : "Point", "coordonnées" :
[122.236111, 37.482778]},
"propriétés" : {"Nom" : Redwood City"}},
{"type" : "Entité",
"géométrie" : {"type" : "LineString", "coordinates" :
[[102.0, 0.0],
[103.0, 1.0],
[104.0, 0.0],
[105.0, 1.0]]},
"propriétés" : {"prop0" : "valeur0",
"prop1" : 0.0}}, :
{"type" "Fonctionnalité",
"géométrie" : {"type" : "Polygone",
"coordonnées" : [[[100.0, 0.0], [101.0,
0.0], [101.0,
1.0], [100.0,
1.0], [100.0,
0.0]]]}, "propriétés" :
{"prop0" : "valeur0 ",
"prop1" : {"ceci" : "cela"}}}]}');
Exemple 222 Sélection d'un objet géométrique à partir d'une fonctionnalité GeoJSON en tant que
Instance SDO_GEOMETRY
Cet exemple utilise la fonction SQL/JSON json_value pour sélectionner la valeur de la géométrie du
champ à partir du premier élément des fonctionnalités du tableau. La valeur est renvoyée en tant que données
Oracle Spatial and Graph, et non en tant que données JSON, c'estàdire en tant qu'instance du type d'objet PL/
SQL SDO_GEOMETRY, et non en tant que chaîne SQL ou instance LOB.
SELECT json_value(geo_doc, '$.features[0].geometry'
RENVOYER SDO_GEOMETRY
ERREUR SUR ERREUR)
DE j_geo ;
La valeur renvoyée est this, qui représente un point avec la longitude et la latitude (coordonnées)
122,236111 et 37,482778, respectivement.
SDO_GEOMETRY(2001, 4326, SDO_POINT_TYPE(122.236111, 37.482778, NULL), NULL, NULL)
Voir également:
Oracle Database SQL Language Reference pour plus d'informations sur la fonction SQL/JSON
json_value
Exemple 223 Récupération de plusieurs objets de géométrie à partir d'une fonction GeoJSON comme
SDO_GEOMETRY
Cet exemple utilise la fonction SQL/JSON json_table pour projeter la valeur de la géométrie de champ à
partir de chaque élément des fonctionnalités du tableau, en tant que colonne sdo_val d'une table virtuelle.
Les données récupérées sont renvoyées en tant que SDO_GEOMETRY.
SELECT jt.*
FROM j_geo,
json_table(geo_doc, '$.features[*]'
COLONNES ("sdo_val" SDO_GEOMETRY PATH '$.geometry')) jt ;
Voir également:
Oracle Database SQL Language Reference pour plus d'informations sur la fonction SQL/JSON
json_table
Les trois lignes suivantes sont renvoyées pour la requête. Le premier représente le même
point que dans l' exemple 222 (page 223). Le second représente le tableau LineString.
Le troisième représente le polygone.
SDO_GEOMETRY(2001, 4326, SDO_POINT_TYPE(122.236111, 37.482778, NULL), NULL, NULL)
SDO_GEOMETRY(2002, 4326, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(102, 0, 103,
1, 104, 0, 105, 1))
SDO_GEOMETRY(2003, 4326, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1),
SDO_ORDINATE_ARRAY(100, 0, 101, 0, 101, 1, 100, 1, 100, 0))
Les deuxième et troisième éléments de l'attribut SDO_ELEM_INFO_ARRAY spécifient comment
interpréter les coordonnées fournies par l'attribut SDO_ORDINATE_ARRAY. Ils montrent que la
première ligne retournée représente une ligne brisée (2) avec des segments droits (1), et la
deuxième ligne représente un polygone (2003) de segments droits (1).
Exemple 224 Création d'un index spatial pour les données GeoJSON
Cet exemple crée un index basé sur la fonction json_value de type
MDSYS.SPATIAL_INDEX sur la géométrie de champ du premier élément des entités de tableau.
Cela peut améliorer les performances des requêtes qui utilisent json_value pour récupérer cette
valeur.
CRÉER UN INDEX json_geo_index
ON j_geo (json_value(geo_doc, '$.features[0].geometry'
RETOUR SDO_GEOMETRY))
INDEXTYPE EST MDSYS.SPATIAL_INDEX ;
Exemple 225 Utilisation de la géométrie GeoJSON avec des opérateurs spatiaux
Cet exemple sélectionne les documents (il n'y en a qu'un dans cette table) pour lesquels le
champ géométrique du premier élément d'entités se trouve à moins de 100 kilomètres d'un
point donné. Le point est fourni littéralement ici (ses coordonnées sont la longitude et la latitude
de San Francisco, Californie). La distance est calculée à partir de ce point jusqu'à chaque objet
géométrique.
La requête classe les documents sélectionnés en fonction de la distance calculée. La tolérance
en mètres pour le calcul de la distance est fournie dans cette requête en tant qu'argument littéral
100.
SELECT id,
json_value(geo_doc, '$features[0].properties.Name') "Name",
SDO_GEOM.sdo_distance(
json_value(geo_doc, '$features[0].geometry') RETURNING SDO_GEOMETRY,
SDO_GEOMETRY(2001, 4326, SDO_POINT_TYPE(122.416667, 37.783333, NULL), NULL,
NULL), 100, Tolérance en mètres 'unit=KM' ) "Distance en kilomètres"
FROM j_geo
WHERE
sdo_within_distance( json_value(geo_doc, '$.features[0].geometry' RETURNING
SDO_GEOMETRY), SDO_GEOMETRY(2001, 4326, SDO_POINT_TYPE(122.416667,
37.783333, NULL), NULL, NULL), 'distance=100 unit= KM')
= 'VRAI' ;
Voir également:
SQL/JSON json_value
La requête renvoie une seule ligne :
IDENTIFIANT Nom Distance en kilomètres

1 Ville de séquoia 26.9443035
Partie VIII
Réglage des performances pour JSON
Pour ajuster les performances des requêtes, vous pouvez indexer les champs JSON de plusieurs manières, stocker
leurs valeurs dans le magasin de colonnes en mémoire (magasin de colonnes IM) ou les exposer en tant que données
non JSON à l'aide de vues matérialisées.
Chapitres
Présentation du réglage des performances pour JSON (page 231)
Les approches de réglage des performances que vous adoptez dépendent des besoins de votre
application. Certains cas d'utilisation et solutions recommandées sont décrits ici.
Index pour les données JSON (page 241)
Vous pouvez indexer les données JSON comme vous le feriez pour n'importe quelle donnée du type
que vous utilisez pour les stocker. De plus, vous pouvez définir un index de recherche JSON, qui est
utile à la fois pour les requêtes structurelles ad hoc et les requêtes de texte intégral.
Données JSON en mémoire (page 251)
Une colonne de données JSON peut être stockée dans le magasin de colonnes en mémoire (magasin
de colonnes IM) pour améliorer les performances des requêtes.
23
Présentation du réglage des performances pour JSON
Les approches de réglage des performances que vous adoptez dépendent des besoins de votre
application. Certains cas d'utilisation et solutions recommandées sont décrits ici.
Les cas d'utilisation peuvent être divisés en deux classes : rechercher ou accéder à des données en fonction
des valeurs des champs JSON qui apparaissent (1) au plus une fois dans un document donné ou (2)
éventuellement plus d'une fois.
Requêtes accédant aux valeurs des champs apparaissant au plus une fois dans une donnée
Document
Vous pouvez régler les performances de ces requêtes de la même manière que pour les données non JSON.
Les choix des champs JSON pour lesquels définir des colonnes virtuelles ou indexer, s'il faut placer la
table contenant vos données JSON dans le magasin de colonnes en mémoire (magasin de colonnes IM) et s'il
faut créer des vues matérialisées qui projettent certains de ses champs sont analogues au cas nonJSON.
Cependant, dans le cas des données JSON, il est généralement plus important d'appliquer au moins un tel
réglage des performances que dans le cas des données non JSON. Sans une telle aide à la performance, il
est généralement plus coûteux d'accéder à un champ JSON que d'accéder aux données de colonne (non
JSON), car un document JSON doit être parcouru pour localiser les données que vous recherchez.
Créez des colonnes virtuelles à partir de champs JSON ou indexez des champs JSON :
•
Si vos requêtes utilisent des critères de recherche simples et très sélectifs, pour un seul champ JSON :
– Définir une colonne virtuelle sur le terrain.
Vous pouvez souvent améliorer davantage les performances en plaçant la table dans le
magasin de colonnes IM ou en créant un index sur la colonne virtuelle.
– Créez un index basé sur une fonction sur le champ à l'aide de la fonction SQL/JSON
json_value.
•
Si vos requêtes impliquent plus d'un champ :
– Définissez une colonne virtuelle sur chacun des champs.
Vous pouvez souvent améliorer davantage les performances en plaçant la table dans le
magasin de colonnes IM ou en créant un index composite sur les colonnes virtuelles.
– Créez un index composite basé sur une fonction sur les champs à l'aide de plusieurs
invocations de la fonction SQL/JSON json_value, une pour chaque champ.
Requêtes qui accèdent aux valeurs des champs qui peuvent se produire plusieurs fois dans un
Document donné
C'est notamment le cas lorsque vous accédez à des champs contenus dans un tableau.
Il existe trois techniques que vous pouvez utiliser pour optimiser les performances de ces requêtes :
Présentation du réglage des performances pour JSON 231
• Placez la table qui contient les données JSON dans le magasin de colonnes IM.
• Utilisez un index de recherche JSON.
Cela indexe tous les champs d'un document JSON avec leurs valeurs, y compris les champs qui
se produisent à l'intérieur des tableaux. L'index peut optimiser toute recherche basée sur le chemin, y
compris celles utilisant des expressions de chemin qui incluent des filtres et des opérateurs de texte
intégral. L'index prend également en charge les recherches basées sur des plages de valeurs numériques.
• Utilisez une vue matérialisée des colonnes nonJSON qui sont projetées à partir des valeurs de champ JSON
à l'aide de la fonction SQL/JSON json_table.
Vous pouvez générer une ligne distincte à partir de chaque membre d'un tableau JSON, en utilisant la
clause NESTED PATH avec json_table.
Une vue matérialisée est généralement utilisée pour optimiser les rapports et les analyses basés sur
SQL pour le contenu JSON.
24
Index pour les données JSON
Vous pouvez indexer les données JSON comme vous le feriez pour n'importe quelle donnée du type que vous utilisez
pour les stocker. De plus, vous pouvez définir un index de recherche JSON, qui est utile à la fois pour les requêtes
structurelles ad hoc et les requêtes de texte intégral.
Les sujets
Présentation de l'indexation des données JSON (page 242)
Il n'y a pas de type de données SQL dédié pour les données JSON, vous pouvez donc l'indexer de la
manière habituelle. De plus, vous pouvez l'indexer de manière générale, avec un index de recherche
JSON, pour les requêtes structurelles ad hoc et les requêtes en texte intégral.
Comment savoir si un index basé sur les fonctions pour les données JSON est extrait (page 243)
Pour déterminer si une requête donnée récupère un index basé sur une fonction donnée, recherchez
le nom de l'index dans le plan d'exécution de la requête.
Création d'index bitmap pour la condition SQL/JSON JSON_EXISTS (page 243)
Vous pouvez créer un index bitmap pour la valeur renvoyée par json_exists.
C'est le bon type d'index à utiliser pour json_exists, car il n'y a que deux valeurs de retour possibles
pour une condition (true et false).
Création d'index basés sur la fonction JSON_VALUE (page 243)
Vous pouvez créer un index basé sur une fonction pour la fonction SQL/JSON json_value.
Vous pouvez utiliser la syntaxe standard pour cela, en spécifiant explicitement la fonction
json_value, ou vous pouvez utiliser la syntaxe de notation simple par points. Les index créés
de l'une ou l'autre de ces manières peuvent être utilisés avec des requêtes en notation par points et des
requêtes json_value.
Utilisation d'un index basé sur la fonction JSON_VALUE avec des requêtes JSON_TABLE (page 245)
Un index créé à l'aide de json_value avec ERROR ON ERROR peut être utilisé pour une requête
impliquant json_table, si la clause WHERE fait référence à une colonne projetée par json_table et que
le chemin SQL/JSON effectif qui cible cette colonne correspond à l'expression de chemin indexé.
Utilisation d'un index basé sur la fonction JSON_VALUE avec des requêtes JSON_EXISTS (page 245)
Un index créé à l'aide de la fonction SQL/JSON json_value avec ERROR ON ERROR peut être utilisé
pour une requête impliquant la condition SQL/JSON json_exists, à condition que l'expression de
chemin de requête ait une expression de filtre qui ne contient qu'une comparaison d'expression de
chemin ou plusieurs comparaisons de ce type séparées par && .
Index pour les données JSON 241
Présentation de l'indexation des données JSON
Considérations sur les types de données pour l'indexation et l'interrogation de JSON_VALUE
(page 247)
Par défaut, la fonction SQL/JSON json_value renvoie une valeur VARCHAR2. Lorsque
vous créez un index basé sur une fonction à l'aide de json_value, à moins que vous
n'utilisiez une clause RETURNING pour spécifier un type de données de retour différent,
l'index n'est pas récupéré pour une requête qui attend une valeur non VARCHAR2.
Indexation de plusieurs champs JSON à l'aide d'un index composite BTree (page 248)
Pour indexer plusieurs champs d'un objet JSON, vous devez d'abord créer des
colonnes virtuelles pour eux. Ensuite, vous créez un index composite Btree sur les
colonnes virtuelles.
Index de recherche JSON : requêtes ad hoc et recherche en texte intégral (page 249)
Un index de recherche JSON est un index général . Il peut améliorer les performances à la fois
(1) des requêtes structurelles ad hoc, c'estàdire des requêtes que vous pourriez ne pas
anticiper ou utiliser régulièrement, et (2) de la recherche en texte intégral. Il s'agit d'un index
Oracle Text spécialement conçu pour être utilisé avec des données JSON.
24.1 Présentation de l'indexation des données JSON
Il n'y a pas de type de données SQL dédié pour les données JSON, vous pouvez donc l'indexer de la manière
habituelle. De plus, vous pouvez l'indexer de manière générale, avec un index de recherche JSON, pour les
requêtes structurelles ad hoc et les requêtes en texte intégral.
Vous pouvez indexer les données JSON comme vous le feriez pour n'importe quelle donnée du type que vous
utilisez pour les stocker. En particulier, vous pouvez utiliser un index Btree ou un index bitmap pour la fonction SQL/
JSON json_value, et vous pouvez utiliser un index bitmap pour les conditions SQL/JSON is json, is not json et
json_exists.
(Plus généralement, un index bitmap peut être approprié lorsque le nombre de valeurs possibles pour la fonction
est petit. Par exemple, vous pouvez utiliser un index bitmap pour la fonction json_value si la valeur doit être
booléenne ou sinon l'une d'un petit nombre de valeurs de chaîne.)
Comme toujours, une telle indexation basée sur les fonctions est appropriée pour les requêtes qui ciblent
des fonctions particulières, ce qui, dans le contexte des fonctions SQL/JSON, signifie des expressions de
chemin SQL/JSON particulières. Il n'est pas très utile pour les requêtes ad hoc, c'estàdire arbitraires. Définissez
un index basé sur une fonction si vous savez que vous interrogerez souvent une expression de chemin
particulière.
Si vous effectuez une requête de manière ad hoc, définissez un index de recherche JSON. Il s'agit d'un index
général, non ciblé sur une expression de chemin spécifique. Il convient aux requêtes structurelles , telles que la
recherche d'un champ JSON avec une valeur particulière, et aux requêtes de texte intégral utilisant la condition
SQL/JSON json_textcontains, telles que la recherche d'un mot particulier parmi diverses valeurs de chaîne.
Vous pouvez bien sûr définir à la fois des index basés sur des fonctions et un index de recherche JSON pour la
même colonne JSON.
Un index de recherche JSON est un index Oracle Text (texte intégral) conçu spécifiquement pour être utilisé
avec des données JSON.
Comment savoir si un index basé sur les fonctions pour les données JSON est récupéré
Noter:
Oracle recommande d'utiliser AL32UTF8 comme jeu de caractères de base de données.
La conversion automatique du jeu de caractères peut avoir lieu lors de la création ou de l'application
d'un index. Une telle conversion peut entraîner des pertes, ce qui peut signifier que certaines
données susceptibles d'être renvoyées par une requête ne sont pas renvoyées. Voir Jeux de
caractères et codage de caractères pour les données JSON (page 61).
Voir également:
Index de recherche JSON : requêtes ad hoc et recherche en texte intégral (page 249) pour
plus d'informations sur la création et l'utilisation d'un index de recherche JSON
24.2 Comment savoir si un index basé sur les fonctions pour les données JSON
est récupéré
Pour déterminer si une requête donnée récupère un index basé sur une fonction donnée, recherchez le nom
de l'index dans le plan d'exécution de la requête.
Par exemple, étant donné l'index défini dans l' exemple 244 (page 244), un plan d'exécution pour la requête
json_value de l' exemple 111 (page 113) référence un parcours d'index avec l'index po_num_id1.
24.3 Création d'index Bitmap pour la condition SQL/JSON JSON_EXISTS
Vous pouvez créer un index bitmap pour la valeur renvoyée par json_exists. C'est le bon type d'index à
utiliser pour json_exists, car il n'y a que deux valeurs de retour possibles pour une condition (true et false).
Ceci est illustré par l' exemple 241 (page 243).
L'exemple 242 (page 243) crée un index bitmap pour une valeur renvoyée par json_value.
Il s'agit d'un index approprié à utiliser s'il n'y a que peu de valeurs possibles pour le champ CostCenter dans
vos données.
Exemple 241 Création d'un index Bitmap pour JSON_EXISTS
CRÉER UN INDEX BITMAP has_zipcode_idx
ON j_purchaseorder (json_exists(po_document,
'$.ShippingInstructions.Address.zipCode'));
Exemple 242 Création d'un index Bitmap pour JSON_VALUE
CRÉER UN INDEX BITMAP cost_ctr_idx
ON j_purchaseorder (json_value(po_document, '$.CostCenter'));
24.4 Création d'index basés sur la fonction JSON_VALUE Vous pouvez créer un index basé sur
la fonction pour la fonction SQL/JSON json_value. Vous pouvez utiliser la syntaxe standard pour cela, en
spécifiant explicitement la fonction json_value, ou vous pouvez utiliser la simple syntaxe de notation par points.
Les index créés de l'une ou l'autre de ces manières peuvent être utilisés avec des requêtes en notation par
points et des requêtes json_value.
L'exemple 244 (page 244) crée un index basé sur une fonction pour json_value sur le champ PONumber
de l'objet qui se trouve dans la colonne po_document de la table j_purchaseorder.
L'objet est passé en tant qu'élément de contexte d'expression de chemin.
Création d'index basés sur la fonction JSON_VALUE
L'utilisation de ERROR ON ERROR ici signifie que si les données contiennent un enregistrement qui n'a pas de
champ PONumber, a plus d'un champ PONumber ou a un champ PONumber avec une valeur non numérique ,
la création d'index échoue. Et si l'index existe, la tentative d'insertion d'un tel enregistrement échoue.
Une alternative consiste à créer un index à l'aide de la syntaxe simplifiée décrite dans Accès simple par
notation par points aux données JSON (page 111). L' exemple 243 (page 244) illustre cela ; il indexe à la
fois les résultats scalaires et non scalaires, correspondant à ce qu'une requête en notation par points peut
renvoyer.
Les index créés dans l' Exemple 244 (page 244) et l' Exemple 243 (page 244) peuvent être
récupérés soit pour une requête qui utilise la syntaxe de notation par points, soit pour une requête qui
utilise json_value.
Si l'index de l' Exemple 243 (page 244) est sélectionné pour une requête json_value, le filtrage est appliqué
après la sélection de l'index, pour tester la valeur de champ correcte. Les valeurs non scalaires peuvent être
stockées dans cet index, car les requêtes en notation par points peuvent renvoyer de telles valeurs, mais pas
une requête json_value, de sorte que ces valeurs sont filtrées après la récupération de l'index.
Si vous souhaitez autoriser l'indexation des données susceptibles de manquer le champ ciblé par une
expression json_value, utilisez une clause NULL ON EMPTY, ainsi qu'une clause ERROR ON ERROR. L'
exemple 245 (page 244) illustre cela.
Oracle vous recommande de créer un index basé sur une fonction pour json_value à l'aide de l'un de ces
formulaires :
• Syntaxe de notation par points
Les valeurs indexées correspondent au comportement flexible des requêtes en notation par points, qui
renvoient des valeurs JSON dans la mesure du possible. Ils peuvent inclure des valeurs JSON non
scalaires (objets et tableaux JSON). Ils peuvent correspondre à des requêtes en notation par points en plus
des requêtes json_value. L'index est utilisé pour trouver un ensemble initial de correspondances, qui sont
ensuite filtrées en fonction des spécificités de la requête. Par exemple, toutes les valeurs indexées qui ne
sont pas des scalaires JSON sont filtrées.
• Une expression json_value qui spécifie un type de données RETURNING , utilise ERROR ON
ERROR (et utilise éventuellement NULL ON EMPTY).
Les valeurs indexées sont uniquement des valeurs scalaires (non nulles) du type de données spécifié.
L'index peut néanmoins être utilisé dans des requêtes en notation pointée qui conduisent à un tel
résultat scalaire.
Les index créés de l'une ou l'autre de ces manières peuvent donc être utilisés avec les requêtes en
notation par points et les requêtes json_value.
Exemple 243 Création d'un index basé sur une fonction pour un champ JSON : notation par points
CRÉER UN INDEX UNIQUE po_num_idx2 ON j_purchaseorder po (po.po_document.PONumber);
Exemple 244 Création d'un index basé sur une fonction pour un champ JSON : JSON_VALUE
CRÉER UN INDEX UNIQUE po_num_idx1 ON
j_purchaseorder (json_value(po_document, '$.PONumber'
ERREUR DE NUMERO DE RETOUR SUR ERREUR) );
Exemple 245 Spécification de NULL ON EMPTY pour une valeur basée sur la fonction JSON_VALUE
Indice
En raison de la clause NULL ON EMPTY, l'index po_ref_idx1 peut indexer les documents JSON qui n'ont pas de
champ de référence.
Utilisation d'un index basé sur la fonction JSON_VALUE avec des requêtes JSON_TABLE
CRÉER UN INDEX UNIQUE po_ref_idx1
ON j_purchaseorder (json_value(po_document, '$.Reference'
RETOUR VARCHAR2(200) ERREUR SUR ERREUR
NULL si vide) );
24.5 Utilisation d'un index basé sur la fonction JSON_VALUE avec des requêtes
JSON_TABLE
Un index créé à l'aide de json_value avec ERROR ON ERROR peut être utilisé pour une requête impliquant
json_table, si la clause WHERE fait référence à une colonne projetée par json_table et que le chemin SQL/JSON
effectif qui cible cette colonne correspond à l'expression de chemin indexé.
L'index agit comme une contrainte sur le chemin indexé, pour garantir qu'une seule valeur JSON scalaire (non nulle)
est projetée pour chaque élément de la collection JSON.
La requête de l' exemple 246 (page 245) utilise donc l'index créé dans l' exemple 244 (page 244).
Noter:
Un index basé sur une fonction créé à l'aide d'une expression json_value ou d'une notation par
points peut être sélectionné pour une occurrence correspondante dans une clause WHERE de requête
uniquement si l'occurrence est utilisée dans une condition de comparaison SQL , telle que >=.
En particulier, il n'est pas récupéré pour une occurrence utilisée dans la condition IS NULL
ou N'EST PAS NULL.
Reportezvous à Oracle Database SQL Language Reference pour plus d'informations sur les
conditions de comparaison SQL.
Exemple 246 Utilisation d'un index basé sur la fonction JSON_VALUE avec un JSON_TABLE
Requete
SELECT jt.*
COLONNES po_number NUMBER(5) CHEMIN '$.PONumber',
référence VARCHAR2(30 CHAR) PATH '$.Reference', demandeur
VARCHAR2(32 CHAR) PATH '$.Requestor', ID utilisateur
VARCHAR2(10 CHAR) PATH '$.User',
centre de coûts VARCHAR2(16 CHAR) PATH '$.CostCenter') jt
OÙ numéro_po = 1600 ;
24.6 Utilisation d'un index basé sur la fonction JSON_VALUE avec des requêtes
JSON_EXISTS
Un index créé à l'aide de la fonction SQL/JSON json_value avec ERROR ON ERROR peut être utilisé pour une
requête impliquant la condition SQL/JSON json_exists, à condition que l'expression de chemin de requête ait une
expression de filtre qui ne contient qu'une comparaison d'expression de chemin ou plusieurs comparaisons de ce
type séparées par && .
Pour qu'un index basé sur la fonction json_value soit sélectionné pour l'une des comparaisons de la
requête, le type de cette comparaison doit être le même que le type de données SQL renvoyé pour l'index.
Les types de données SQL utilisés sont ceux mentionnés pour les méthodes d'élément double(), number(),
timestamp(), date() et string() — voir Syntaxe d'expression de chemin SQL/JSON de base (page 122).
Utilisation d'un index basé sur la fonction JSON_VALUE avec des requêtes JSON_EXISTS
Par exemple, si l'index renvoie un nombre, le type de comparaison doit également être un nombre. Si
l'expression de filtre de requête contient plusieurs comparaisons correspondant à un index json_value,
l'optimiseur choisit l'un des index.
Le type d'une comparaison est déterminé comme suit :
1. Si les types de données SQL des deux termes de comparaison (côtés de la comparaison) sont différents,
le type de comparaison est inconnu et l'index n'est pas sélectionné. Sinon, les types sont les mêmes,
et ce type est le type de la comparaison.
2. Si un terme de comparaison est une chaîne de type de données SQL (un littéral de texte), alors le type
de la comparaison est le type de l'autre terme de comparaison.
3. Si un terme de comparaison est une expression de chemin avec une étape de fonction dont la méthode
d'élément impose un type de correspondance SQL, alors c'est aussi le type de ce terme de
comparaison. Les méthodes d'élément qui imposent un type de correspondance SQL sont double(),
number(), timestamp(), date() et string().
4. Si un terme de comparaison est une expression de chemin sans une telle étape de fonction, son type est
une chaîne SQL (texte littéral).
L'exemple 244 (page 244) crée un index basé sur une fonction pour json_value sur le champ PONumber.
Le type de retour d'index est NUMBER.
Chacune des requêtes Exemple 247 (page 246), Exemple 248 (page 246) et Exemple 249
(page 247) peut utiliser cet index lors de l'évaluation de sa condition json_exists. Chacune de
ces requêtes utilise une comparaison qui implique une expression de chemin simple relative à
l'expression de chemin absolu $.PONumber.
L'expression de chemin simple relatif dans chaque cas cible l'élément de filtre actuel, @, mais dans le cas de
l' exemple 249 (page 247), elle transforme (convertit) les données correspondantes en type de données SQL
NUMBER.
Voir également:
• Création d'index basés sur la fonction JSON_VALUE (page 243)
• Expressions de chemin SQL/JSON (page 121)
Exemple 247 Champ de ciblage de requête JSON_EXISTS comparé au nombre littéral
Cette requête utilise l'index car :
1. Un terme de comparaison est une expression de chemin sans étape de fonction, donc son type est une
chaîne SQL (texte littéral).
2. Étant donné qu'un terme de comparaison est de type chaîne, la comparaison a le type du
autre terme, qui est un nombre (l'autre terme est un chiffre).
3. Le type de la (seule) comparaison est le même que le type renvoyé par l'index :
Numéro.
SELECT count(*) FROM j_purchaseorder
WHERE json_exists(po_document, '$.PONumber?(@ > 1500)');
Exemple 248 Champ de ciblage de requête JSON_EXISTS comparé à la valeur de la variable
Cette requête peut utiliser l'index car :
246 Oracle Database JSON Developer's Guide
Considérations sur les types de données pour l'indexation et l'interrogation de JSON_VALUE
1. Un terme de comparaison est une expression de chemin sans étape de fonction, donc son type est une chaîne
SQL (texte littéral).
2. Étant donné qu'un terme de comparaison est de type chaîne, la comparaison a le type de l'autre terme, qui est
nombre (l'autre terme est une variable liée à un nombre).
Numéro.
SELECT count(*) FROM j_purchaseorder WHERE
json_exists(po_document, '$.PONumber?(@ > $d)'
PASSER 1500 AS "d");
Exemple 249 Champ de ciblage de requête JSON_EXISTS converti en nombre par rapport à
Valeur variable
Cette requête peut utiliser l'index car :
1. Un terme de comparaison est une expression de chemin avec une étape de fonction dont l'élément
La méthode (number()) transforme les données correspondantes en un nombre, de sorte que le type de ce
terme de comparaison est le nombre SQL.
2. L'autre terme de comparaison est un chiffre, qui a un numéro de type SQL. Les types des termes de
comparaison correspondent, donc la comparaison a le même type, numéro.
Numéro.
json_exists(po_document, '$.PONumber?(@.number() > $d)'
PASSER 1500 AS "d");
Exemple 2410 Requête JSON_EXISTS ciblant une conjonction de comparaisons de champs
Tout comme pour l' exemple 247 (page 246), cette requête peut utiliser l'index sur le champ PONumber.
Si un index json_value est également défini pour le champ Reference, l'optimiseur choisit l'index à utiliser
pour cette requête.
json_exists(po_document, '$?(@.PONumber > 1500
&& @.Reference == "ABULL20140421")');
24.7 Considérations sur les types de données pour l'indexation et l'interrogation de JSON_VALUE Par défaut, la fonction SQL/JSON
json_value renvoie une valeur VARCHAR2. Lorsque vous créez un index basé sur une fonction à l'aide de
json_value, à moins que vous n'utilisiez une clause RETURNING pour spécifier un type de données de retour
différent, l'index n'est pas récupéré pour une requête qui attend une valeur autre que VARCHAR2.
Par exemple, dans la requête de l' exemple 2411 (page 248), json_value utilise RETURNING
NUMBER. L'index créé dans l'exemple 244 (page 244) peut être récupéré pour cette requête, car l'expression
json_value indexée spécifie un type de retour de
NUMÉRO.
Mais l'index créé dans l' exemple 243 (page 244) n'utilise pas RETURNING NUMBER (le type de retour est
VARCHAR2(4000), par défaut), il ne peut donc pas être récupéré pour une telle requête.
Indexation de plusieurs champs JSON à l'aide d'un index composite BTree
Considérons maintenant les requêtes de l' exemple 2412 (page 248) et de l' exemple 2413
(page 248), qui utilisent json_value sans clause RETURNING, de sorte que la valeur renvoyée est de type
VARCHAR2.
Dans l' exemple 2412 (page 248), la fonction SQL to_number convertit explicitement la valeur
VARCHAR2 renvoyée par json_value en nombre. De même, dans l' exemple 2413 (page 248), la condition
de comparaison > (supérieur à) convertit implicitement la valeur en nombre.
Aucun des index de l' exemple 244 (page 244) et de l' exemple 243 (page 244) n'est sélectionné pour
l'une ou l'autre de ces requêtes. Les requêtes peuvent renvoyer les bons résultats dans chaque cas, en raison
de la conversion de type, mais les index ne peuvent pas être utilisés pour évaluer les requêtes.
Considérez également ce qui se passe si certaines des données ne peuvent pas être converties en un type
de données particulier. Par exemple, étant donné les requêtes de l' exemple 2411 (page 248), de l'
exemple 2412 (page 248) et de l' exemple 2413 (page 248), qu'advientil d'une valeur PONumber telle
que " alpha"?
Pour l' exemple 2412 (page 248) et l' exemple 2413 (page 248), la requête s'arrête par erreur en
raison de la tentative de conversion de la valeur en nombre. Cependant, dans l' exemple 2411 ( page
248), étant donné que le comportement de gestion des erreurs par défaut est NULL ON ERROR, la
valeur non numérique « alpha » est simplement filtrée. La valeur est indexée, mais elle est ignorée pour la
requête.
De même, si la requête utilisait, par exemple, DEFAULT '1000' ON ERROR, c'estàdire si elle spécifiait une
valeur numérique par défaut, aucune erreur ne serait générée pour la valeur "alpha": la valeur par défaut de
1000 serait utilisée.
Exemple 2411 Requête JSON_VALUE avec NUMÉRO DE RETOUR explicite
SELECT count(*) FROM j_purchaseorder po
WHERE json_value(po_document, '$.PONumber' RETURNING NUMBER) > 1500 ;
Exemple 2412 Requête JSON_VALUE avec conversion numérique explicite
WHERE to_number(json_value(po_document, '$.PONumber')) > 1500 ;
Exemple 2413 Requête JSON_VALUE avec conversion numérique implicite
WHERE json_value(po_document, '$.PONumber') > 1500 ;
24.8 Indexation de plusieurs champs JSON à l'aide d'un index composite BTree
Pour indexer plusieurs champs d'un objet JSON, vous devez d'abord créer des colonnes virtuelles pour eux.
Ensuite, vous créez un index composite Btree sur les colonnes virtuelles.
L'exemple 2414 (page 249) et l'exemple 2415 (page 249) illustrent cela.
L'exemple 2414 (page 249) crée des colonnes virtuelles userid et costcenter pour les champs d'objet
JSON User et CostCenter, respectivement.
L'exemple 2415 (page 249) crée un index composite Btree sur les colonnes virtuelles de l' exemple
2414 (page 249).
Une requête SQL qui fait référence aux colonnes virtuelles ou aux données JSON correspondantes (champs
d'objet) récupère l'index composite. C'est le cas pour les deux requêtes de l' exemple 2416 (page 249).
Ces deux requêtes ont le même effet, y compris les mêmes performances. Cependant, le premier formulaire
de requête ne cible pas les données JSON ellesmêmes ; il cible les colonnes virtuelles utilisées pour indexer
ces données.
248 Oracle Database JSON Developer's Guide
Index de recherche JSON : requêtes ad hoc et recherche en texte intégral
Les données ne dépendent logiquement d'aucun index mis en œuvre pour améliorer les performances des
requêtes. Si vous souhaitez que cette indépendance par rapport à l'implémentation se reflète dans votre code,
utilisez le deuxième formulaire de requête. Cela garantit que la requête se comporte de la même manière avec ou
sans l'index l'index ne sert qu'à améliorer les performances.
Exemple 2414 Création de colonnes virtuelles pour les champs d'objet JSON
ALTER TABLE j_purchaseorder ADD (ID utilisateur VARCHAR2(20)
GÉNÉRÉ TOUJOURS AS (json_value(po_document, '$.User' RETURNING VARCHAR2(20))));
ALTER TABLE j_purchaseorder AJOUTER (centre de coûts VARCHAR2(6)
GÉNÉRÉ TOUJOURS COMME (json_value(po_document, '$.CostCenter'
RETOUR VARCHAR2(6))));
Exemple 2415 Création d'un index composite Btree pour les champs d'objet JSON
CREATE INDEX user_cost_ctr_idx sur j_purchaseorder(userid, costcenter);
Exemple 2416 Deux manières d'interroger des données JSON indexées avec un index composite
SELECT po_document FROM j_purchaseorder WHERE ID utilisateur = 'ABULL'
ET centre de coût = 'A50' ;
SELECT po_document
FROM j_purchaseorder WHERE json_value(po_document, '$.User') = 'ABULL'
AND json_value(po_document, '$.CostCenter') = 'A50';
24.9 Index de recherche JSON : requêtes ad hoc et recherche en texte intégral
Un index de recherche JSON est un index général . Il peut améliorer les performances à la fois (1) des requêtes
structurelles ad hoc, c'estàdire des requêtes que vous pourriez ne pas anticiper ou utiliser régulièrement, et (2) de
la recherche en texte intégral. Il s'agit d'un index Oracle Text spécialement conçu pour être utilisé avec des données
JSON.
Noter:
Si vous avez créé un index de recherche JSON à l'aide d'Oracle Database 12c Release 1
(12.1.0.2), Oracle vous recommande de supprimer cet index et de créer un nouvel index de recherche
à utiliser avec les versions ultérieures, à l'aide de CREATE SEARCH INDEX comme indiqué ici. Voir
aussi Oracle Database Upgrade Guide.
Introduction aux index de recherche JSON
Vous créez un index de recherche JSON à l'aide de CREATE SEARCH INDEX avec les mots clés FOR JSON.
Si le nom de votre index de recherche JSON est présent dans le plan d'exécution de votre requête, vous savez que
l'index a en fait été sélectionné pour cette requête. Vous verrez une ligne similaire à celle illustrée dans l' exemple
2418 (page 2410).
Vous pouvez spécifier une clause PARAMETERS pour remplacer les paramètres par défaut de certaines
options configurables. Par défaut (pas de clause PARAMETERS), l'index est synchronisé lors de la validation et
les plages textuelles et numériques sont indexées.
Un index de recherche JSON est maintenu de manière asynchrone, à la demande. Vous pouvez ainsi différer le
coût de la maintenance de l'index, en l'exécutant uniquement au moment de la validation ou à un moment où la
charge de la base de données est réduite. Cela peut améliorer les performances DML. Il peut également améliorer
les performances de maintenance de l'index en permettant le chargement en bloc de fichiers non synchronisés.
indexer les lignes lorsqu'un index est synchronisé. D'autre part, la maintenance asynchrone
d'un index signifie que tant qu'il n'est pas synchronisé, l'index n'est pas utilisé pour les données qui
ont été modifiées ou nouvellement insérées.
Si vos requêtes qui utilisent un index de recherche JSON n'impliquent jamais de plages numériques,
vous pouvez économiser du temps de maintenance de l'index et de l'espace disque en spécifiant
TEXT pour le paramètre SEARCH_ON. La valeur par défaut de SEARCH_ON est TEXT_VALUE, ce
qui signifie des plages numériques d'index ainsi que du texte.
Noter:
Pour modifier un index de recherche JSON j_s_idx, vous utilisez ALTER INDEX j_s_idx
REBUILD ... (pas ALTER SEARCH INDEX j_s_idx ...).
Exemple 2417 Création d'un index de recherche JSON
CRÉER UN INDEX DE RECHERCHE po_search_idx SUR j_purchaseorder (po_document) POUR JSON ;
Exemple 2418 Indication du plan d'exécution qu'un index de recherche JSON est utilisé
|* 2| INDEX DE DOMAINE | PO_SEARCH_IDX | | | 4 (0)
Recherche en texte intégral des données JSON
Vous pouvez utiliser la condition SQL/JSON json_textcontains dans une expression CASE ou la clause
WHERE d'une instruction SELECT pour effectuer une recherche en texte intégral des données JSON
stockées dans une colonne VARCHAR2, BLOB ou CLOB.
Pour pouvoir utiliser la condition json_textcontains, vous devez d'abord créer un index de
recherche JSON. Si vous ne le faites pas, une erreur est générée lorsque json_textcontains est
utilisé.
L'exemple 2419 (page 2410) montre une requête en texte intégral qui trouve des documents
de bon de commande contenant le motclé Magic dans l'une des descriptions de pièces d'article.
Exemple 2419 Requête en texte intégral de données JSON
SELECT po_document FROM j_purchaseorder
WHERE json_textcontains(po_document, '$.LineItems.Part.Description', 'Magic');
Exemple 2420 Requête en texte intégral de données JSON, avec modèle de recherche échappé
Si le troisième argument de la condition json_textcontains contient un caractère ou un mot réservé
par rapport à la recherche Oracle Text, vous devez échapper ce caractère ou ce mot.
Les requêtes ici recherchent des documents où la description de la pièce contient à la fois Magic
et Christmas. Ils utilisent les opérateurs de requête Oracle Text & et et, qui sont réservés à la recherche
Oracle Text.
La première requête échappe le caractère unique &, en utilisant une barre oblique inverse (\). Le second
échappe à tout le modèle de recherche, en utilisant des accolades ({, }), car il contient le mot réservé
and. (Il pourrait également utiliser {et} pour échapper uniquement les caractères de l'opérateur et).
WHERE json_textcontains(po_document, '$.LineItems.Part.Description', '{Magic and
Noël}');
WHERE json_textcontains(po_document, '$.LineItems.Part.Description', 'Magic \& Christmas');
Requêtes ad hoc de données JSON
L'exemple 2421 (page 2411) illustre certaines requêtes non intégrales de données JSON qui utilisent
également l'index de recherche JSON créé dans l' exemple 2417 (page 2410).
Exemple 2421 Quelques requêtes JSON ad hoc
Cette requête sélectionne les documents contenant une adresse d'instructions d'expédition incluant un
pays.
WHERE json_exists(po_document, '$.ShippingInstructions.Address.country');
Cette requête sélectionne les documents qui contiennent l'utilisateur AKHOO où il y a plus de 8 articles
commandés. Il tire parti de l'indexation par plage numérique.
WHERE json_exists(po_document, '$?(@.User == "AKHOO"
&& @.LineItems.Quantity > 8)');
Cette requête sélectionne les documents dont l'utilisateur est AKHOO. Il utilise json_value au lieu de json_exists
dans la clause WHERE.
WHERE json_value(po_document, '$.User') = 'ABULL';
Voir également:
• Index pour les données JSON (page 241) pour plus d'informations sur les autres
indexer les données JSON
• Oracle Database SQL Language Reference pour plus d'informations sur la condition
json_textcontains
CRÉER UN INDEX DE RECHERCHE
• Oracle Text Reference pour d'autres exemples d'utilisation de CREATE SEARCH
INDICE
MODIFIER L'INDEX... RECONSTRUIRE
• Oracle Text Reference pour plus d'informations sur la synchronisation d'une recherche JSON
indice
• Guide du développeur d'Oracle Text Application pour obtenir des conseils sur l'optimisation et le
réglage des performances d'un index de recherche JSON
• Oracle Text Reference pour plus d'informations sur les mots et les caractères réservés pour la
recherche Oracle Text et Oracle Text Reference pour plus d'informations sur la façon de les
échapper.
• Guide des données JSON (page 181) pour plus d'informations sur l'utilisation d'une recherche JSON
index pour stocker des informations de guide de données
25
Données JSON en mémoire
Une colonne de données JSON peut être stockée dans le magasin de colonnes en mémoire (magasin de colonnes
IM) pour améliorer les performances des requêtes.
Les sujets
Voir aussi : Guide en mémoire de la base de données Oracle
Présentation des données JSON en mémoire (page 251)
Vous pouvez déplacer une table avec une colonne de données JSON vers le magasin de
colonnes en mémoire (magasin de colonnes IM) pour améliorer les performances des requêtes qui
partagent des expressions coûteuses en mettant en cache les résultats des expressions. Ceci est
particulièrement utile pour les requêtes analytiques qui analysent un grand nombre de petits documents
JSON.
Remplissage des données JSON dans le magasin de colonnes en mémoire (page 253)
Vous utilisez ALTER TABLE INMEMORY pour remplir une table avec une colonne de données JSON
dans le magasin de colonnes en mémoire (magasin de colonnes IM), afin d'améliorer les performances
des requêtes qui partagent des expressions coûteuses en mettant en cache les résultats de l'évaluation
de ces expressions.
Mise à niveau des tables avec des données JSON à utiliser avec le magasin de colonnes en mémoire (page
254)
Une table avec des colonnes JSON créées à l'aide d'une base de données qui n'avait pas un
paramètre de compatibilité d'au moins 12.2 ou n'avait pas max_string_size = extended doit d'abord
être mise à niveau, avant de pouvoir être remplie dans le magasin de colonnes en mémoire (magasin
de colonnes IM). Pour ce faire, exécutez le script rdbms/admin/utlimcjson.sql.
25.1 Présentation des données JSON en mémoire
Vous pouvez déplacer une table avec une colonne de données JSON vers le magasin de colonnes en mémoire
(magasin de colonnes IM) pour améliorer les performances des requêtes qui partagent des expressions coûteuses en
mettant en cache les résultats des expressions. Ceci est particulièrement utile pour les requêtes analytiques qui analysent
un grand nombre de petits documents JSON.
Le magasin de colonnes IM est pris en charge uniquement pour les documents JSON inférieurs à 32 767 octets.
Si vous avez un mélange de tailles de documents, les documents dont la taille est supérieure à 32 767 octets sont
traités sans l'optimisation en mémoire. Pour de meilleures performances, envisagez de diviser les documents de plus
de 32 767 octets en documents plus petits.
Le magasin de colonnes IM est un pool SGA facultatif qui stocke des copies de tables et de partitions dans un format de
colonne spécial optimisé pour les analyses rapides. Le magasin de colonnes IM complète le stockage basé sur les lignes
dans le cache de tampon de la base de données. Vous n'avez pas besoin de charger le même objet à la fois dans le
magasin de colonnes IM et dans le cache de tampon. Les deux caches sont maintenus cohérents sur le plan transactionnel.
La base de données envoie en ligne de manière transparente
Données JSON en mémoire 251
Présentation des données JSON en mémoire
les requêtes de traitement des transactions (OLTP) (telles que les recherches de clé primaire) dans le cache de
tampon et les requêtes analytiques et de création de rapports dans le magasin de colonnes IM.
Vous pouvez considérer l'utilisation des données JSON en mémoire comme une amélioration des performances de
l'accès au chemin SQL/JSON. Les fonctions SQL/JSON json_table, json_query et json_value, et la condition SQL
json_exists acceptent toutes un argument de chemin SQL/JSON, et elles peuvent toutes bénéficier du chargement
de données JSON dans le magasin de colonnes IM.
(La recherche en texte intégral à l'aide de la fonction SQL/JSON json_textcontains ne bénéficie pas du magasin de
colonnes IM.) Une fois les documents JSON chargés en mémoire, toutes les opérations ultérieures basées sur le
chemin d'accès utilisent la représentation en mémoire, ce qui évite la surcharge associée avec lecture et analyse du
format sur disque.
Si les données JSON interrogées sont remplies dans le magasin de colonnes IM et s'il existe des index basés sur des
fonctions qui peuvent s'appliquer à ces données, l'optimiseur choisit d'utiliser un index ou d'analyser les données en
mémoire. En général, si le sondage d'index aboutit à peu de documents, un index fonctionnel peut être préféré par
l'optimiseur. En pratique, cela signifie que l'optimiseur peut préférer un index fonctionnel pour des requêtes très
sélectives ou des instructions DML.
D'un autre côté, si la détection d'index aboutit à de nombreux documents, l'optimiseur peut choisir d'analyser les
données en mémoire, en analysant l'expression d'index basée sur la fonction en tant qu'expression de colonne
virtuelle.
Les requêtes ad hoc, c'estàdire les requêtes qui ne sont pas utilisées fréquemment pour cibler une expression de
chemin SQL/JSON donnée, bénéficient de manière générale du remplissage des données JSON dans le magasin de
colonnes IM, en analysant rapidement les données. Mais si vous avez des requêtes fréquemment utilisées, vous pouvez
souvent améliorer encore leurs performances de ces manières :
• Création de colonnes virtuelles qui projettent des valeurs scalaires (pas sous un tableau) à partir d'un
colonne de données JSON et chargement de ces colonnes virtuelles dans le magasin de colonnes IM.
• Création d'une vue matérialisée sur une expression json_table fréquemment interrogée et
chargement de la vue dans le magasin de colonnes IM.
Cependant, si vous avez un index basé sur une fonction qui projette une valeur scalaire à l'aide de la fonction
json_value, vous n'avez pas besoin de créer explicitement une colonne virtuelle pour la projeter. Comme mentionné ci
dessus, dans ce cas, l'expression d'index basée sur la fonction est automatiquement chargée dans le magasin de
colonnes IM en tant que colonne virtuelle. L'optimiseur peut choisir, en fonction du coût estimé, d'analyser l'index basé
sur la fonction de la manière habituelle ou d'analyser l'expression d'index en tant qu'expression de colonne virtuelle.
Noter:
• Les avantages d'une colonne virtuelle par rapport à une vue matérialisée sont que vous pouvez créer un
index dessus et obtenir des statistiques dessus pour l'optimiseur.
• Les colonnes virtuelles, comme les colonnes en général, sont soumises à la limite de 1000 colonnes pour
une table donnée.
Voir également:
Remplissage des données JSON dans le magasin de colonnes en mémoire (page 253)
Remplir les données JSON dans le magasin de colonnes en mémoire
Prérequis pour l'utilisation de données JSON en mémoire
Pour pouvoir tirer parti du magasin de colonnes IM pour les données JSON, les éléments suivants doivent tous être vrais :
• La compatibilité de la base de données est 12.2.0.0 ou supérieure.
• Les valeurs définies pour max_string_size dans le démarrage de l'instance Oracle
le fichier de configuration doit être 'étendu'.
• Une mémoire SGA suffisante doit être configurée pour le magasin de colonnes IM.
• Un administrateur de base de données a spécifié que l'espace de table, la table ou la vue matérialisée contenant les
colonnes JSON peut être rempli dans le magasin de colonnes IM, à l'aide du motclé INMEMORY dans une
instruction CREATE ou ALTER.
• Les paramètres d'initialisation sont définis comme suit :
– IMMEMORY_EXPRESSIONS_USAGE est STATIC_ONLY ou ENABLE.
ENABLE permet la matérialisation en mémoire des expressions dynamiques, si elle est utilisée conjointement
avec la procédure PL/SQL DBMS_INMEMORY.ime_capture_expressions.
– IMMEMORY_VIRTUAL_COLUMNS est ENABLE, ce qui signifie que le magasin de colonnes IM remplit
toutes les colonnes virtuelles. (La valeur par défaut est MANUEL.)
• Les colonnes stockant les données JSON doivent chacune avoir des contraintes de vérification json.
(C'estàdire que les données doivent être connues comme étant des données JSON.)
Vous pouvez vérifier la valeur de chaque paramètre d'initialisation à l'aide de la commande SHOW PARAMETER.
(Vous devez être connecté en tant qu'utilisateur de base de données SYS ou équivalent pour cela.) Par exemple :
AFFICHER LE PARAMÈTRE DANSMEMORY_VIRTUAL_COLUMNS
25.2 Remplir les données JSON dans le magasin de colonnes en mémoire
Vous utilisez ALTER TABLE INMEMORY pour remplir une table avec une colonne de données JSON dans le magasin
de colonnes en mémoire (magasin de colonnes IM), afin d'améliorer les performances des requêtes qui partagent des
expressions coûteuses en mettant en cache les résultats de l'évaluation de ces expressions.
Le magasin de colonnes IM est un pool SGA facultatif qui stocke des copies de tables et de partitions dans un format de
colonne spécial optimisé pour les analyses rapides. Le magasin de colonnes IM complète le stockage basé sur les lignes
dans le cache de tampon de la base de données. (Il ne remplace pas le cache de tampon, mais vous n'avez pas besoin de
charger le même objet à la fois dans le magasin de colonnes IM et dans le cache de tampon. Les deux caches sont
maintenus cohérents sur le plan transactionnel.)
Vous spécifiez qu'une table avec une colonne JSON donnée (c'estàdire une colonne qui a une contrainte is json
check) doit être remplie dans le magasin de colonnes IM en marquant la table comme INMEMORY. L' exemple 251
(page 254) illustre cela.
Le magasin de colonnes IM est utilisé pour les requêtes de documents dont la taille est inférieure à 32 767 octets.
Les requêtes de documents plus volumineux ne bénéficient pas du magasin de colonnes IM.
Mise à niveau des tables avec des données JSON à utiliser avec le magasin de colonnes en mémoire
Noter:
Si une colonne JSON dans une table qui doit être remplie dans le magasin de colonnes IM a été
créée à l'aide d'une base de données qui n'avait pas un paramètre de compatibilité d'au moins
12.2 ou n'avait pas max_string_size défini sur étendu (c'est le cas avant Oracle Database 12c
Release 2 (12.2.0.1), par exemple), vous devez d'abord exécuter le script rdbms/admin/utlimcjson.sql.
Il prépare toutes les tables existantes qui ont des colonnes JSON pour tirer parti du traitement JSON
en mémoire qui a été ajouté dans la version 12.2.0.1. Voir Mise à niveau des tables avec des
données JSON à utiliser avec le magasin de colonnes en mémoire (page 254).
Une fois que vous avez marqué une table contenant des colonnes JSON comme INMEMORY, une
colonne virtuelle en mémoire lui est ajoutée pour chaque colonne JSON. La colonne virtuelle correspondante
est utilisée pour les requêtes d'une colonne JSON donnée. La colonne virtuelle contient les mêmes données
JSON que la colonne JSON correspondante, mais dans un format binaire Oracle, OSON.
Exemple 251 Remplissage de données JSON dans le magasin de colonnes IM
SELECT COUNT(1) FROM j_purchaseorder
WHERE json_exists(po_document,
'$.ShippingInstructions?(@.Address.zipCode == 99236)');
Le plan d'exécution affiche : TABLE ACCESS FULL
Spécifiez la table comme INMEMORY, avec le paramètre PRIORITY par défaut de NONE,
afin qu'elle ne soit remplie que lorsqu'une analyse complète est déclenchée.
ALTER TABLE j_purchaseorder INMEMORY ;
Interrogez à nouveau la table pour la remplir dans le magasin de colonnes IM.
SELECT COUNT(1) FROM j_purchaseorder
WHERE json_exists(po_document,
'$.ShippingInstructions?(@.Address.zipCode == 99236)');
Le plan d'exécution de la requête affiche désormais : TABLE ACCESS INMEMORY FULL
Voir également:
Guide en mémoire de la base de données Oracle
25.3 Mise à niveau des tables avec des données JSON à utiliser avec le magasin de
colonnes en mémoire
Une table avec des colonnes JSON créées à l'aide d'une base de données qui n'avait pas un paramètre de
compatibilité d'au moins 12.2 ou n'avait pas max_string_size = extended doit d'abord être mise à niveau, avant
de pouvoir être remplie dans le magasin de colonnes en mémoire (magasin de colonnes IM). Pour ce faire,
exécutez le script rdbms/admin/utlimcjson.sql.
Le script rdbms/admin/utlimcjson.sql met à niveau toutes les tables existantes qui ont des colonnes JSON afin
qu'elles soient remplies dans le magasin de colonnes IM. Pour l'utiliser, toutes les conditions suivantes doivent
être remplies :
• Le paramètre de base de données compatible doit être défini sur 12.2.0.0 ou supérieur.
• Le paramètre de base de données max_string_size doit être défini sur étendu.
• Les colonnes JSON en cours de mise à niveau doivent avoir une contrainte de vérification is
json définie sur elles.
Voir aussi : Présentation des données JSON en mémoire (page 251)
UNE
Restrictions JSON de la base de données Oracle
Les restrictions associées à la prise en charge par Oracle des données JSON dans Oracle Database sont
répertoriées ici.
Sauf indication contraire, une erreur est levée si une limitation spécifiée n'est pas respectée.
• Général
– Nombre de niveaux d'imbrication pour un objet ou un tableau JSON : 1 000, maximum.
– Longueur du nom de champ JSON : 32 767 octets, maximum.
• Fonctions SQL/JSON
– Longueur de la valeur de retour : 32 767 octets, maximum.
– Longueur du chemin : 4K octets, maximum.
– Nombre d'étapes de chemin : 65535, maximum.
• Syntaxe JSON simplifiée
– Longueur du chemin : 4K octets, maximum.
– Longueur du composant de chemin : 128 octets, maximum.
• Index de recherche JSON
– Longueur du nom de champ : 64 octets, maximum. Si un document a un nom de champ de plus de 64
octets, il se peut qu'il ne soit pas complètement indexé et, dans ce cas, une erreur est enregistrée dans
la vue de base de données CTX_USER_INDEX_ERRORS.
• Guide de données JSON
– Longueur du chemin : 4000 octets, maximum. Un chemin de plus de 4000 octets est ignoré par
un guide des données.
– Nombre d'enfants sous un nœud parent : 65 535, maximum. Un nœud qui a plus
supérieur à 65535 enfants est ignoré par un guide de données.
– Longueur de la valeur de champ : 32 767 octets. Si un champ JSON a une valeur supérieure à 32767
octets, le guide de données signale la longueur comme 32767.
– Nom de champ de longueur nulle : un nom de champ d'objet de longueur nulle (vide) ("") n'est pas
pris en charge pour une utilisation avec le guide de données JSON. Le comportement du guide de données n'est
pas défini pour les données JSON qui contiennent un tel nom.
• OSON
– Longueur du nom de champ : 255 octets, maximum.
Restrictions JSON de la base de données Oracle A1
– Aucun champ en double : si un objet JSON avec des noms de champ en double est représenté à l'aide
d'OSON, alors un seul de ces champs est présent (conservé).
• Aucun déchargement des données LOB de la table externe HDFS vers Oracle Big Data SQL
– Données JSON stockées dans une table externe basée sur Hadoop
Le système de fichiers distribués (HDFS) n'est pas déchargé vers Oracle Big Data SQL lorsque le
stockage LOB est utilisé. Voir le Guide de l'utilisateur du logiciel Oracle Big Data Appliance
• Vous ne pouvez pas interroger les données JSON sur plusieurs partitions à moins qu'elles ne soient stockées en tant que
VARCHAR2.
A2 Guide du développeur Oracle Database JSON
B
Diagrammes pour le chemin SQL/JSON de base
Syntaxe des expressions
Les diagrammes de syntaxe et les descriptions de syntaxe de la forme BackusNaur (BNF) correspondantes
sont présentés pour la syntaxe d'expression de chemin SQL/JSON de base.
La syntaxe de base de l'expression de chemin SQL/JSON est expliquée dans Syntaxe de base de l'expression
de chemin SQL/JSON (page 122). Cette rubrique récapitule ces informations sous la forme de diagrammes
de syntaxe et de descriptions BNF.
Figure B1 json_basic_path_expression
json_filter_expr
json_absolute_simple_path_expr
Noter:
L'expression de filtre facultative, json_filter_expr, peut être présente uniquement lorsque l'expression
de chemin est utilisée dans la condition SQL json_exists. Sinon, une erreur de compilation est
générée.
Figure B2 json_absolute_simple_path_expression
$ json_path_steps
Figure B3 json_path_steps
json_object_step
json_array_step json_function_step
Figure B4 json_object_step
*
.
json_field_name
Figure B5 json_field_name
caractère_unicode
'' ''
lettre
chiffre
lettre
Diagrammes pour la syntaxe d'expression de chemin SQL/JSON de base B1
Figure B6 json_array_step
*
,
[ ]
à entier
entier
Noter:
• L'indexation des tableaux est basée sur zéro, donc entier est un entier non négatif (0, 1,
2, 3,...).
• Le premier entier d'une plage (entier à entier) doit être inférieur à
la deuxième.
• Les éléments du tableau doivent être spécifiés par des index dans l'ordre croissant,
sans répétitions.
Une erreur de compilation est générée si l'une de ces règles de syntaxe est violée.
Figure B7 json_function_step
. json_item_method ( )
Figure B8 json_item_method
abdos
plafond
Date
double
étage
longueur
plus bas
Numéro
chaîne de caractères
horodatage
plus haut
Figure B9 json_filter_expr
? ( json_cond )
Illustration B10 json_cond
json_cond ||
json_conjonction
B2 Guide du développeur Oracle Database JSON
Figure B11 json_conjonction
json_conjonction &&
json_cond_other
Illustration B12 json_cond_other
( ! ( json_cond ) )
( json_cond )
json_filter_expr
existe ( json_relative_simple_path_expr )
json_comparison
Figure B13 json_comparison
json_var
json_relative_simple_path_expr json_compare_pred
json_scalaire
json_var
json_compare_pred json_relative_simple_path_expr
json_scalaire
json_scalaire json_compare_pred json_scalaire
Figure B14 json_relative_simple_pathexpr
@ json_path_steps
Illustration B15 json_compare_pred
==
!=
<
<=
>=
>
Illustration B16 json_var
$ identifiant
Figure B17 json_scalaire
numéro_json
vrai
faux
nul
'' ''
caractère_unicode
Diagrammes pour la syntaxe d'expression de chemin SQL/JSON de base B3
Noter:
json_number est un nombre JSON : un chiffre décimal, éventuellement signé et
comprenant éventuellement un exposant décimal.
B4 Guide du développeur Oracle Database JSON
Indice
Symboles B
! prédicat de filtre, expressions de chemin SQL/JSON, 122 != expression de chemin SQL/JSON de base
prédicat de filtre de comparaison, expressions de chemin SQL/ Descriptif BNF, schémas
JSON, 122 && prédicat de filtre, expressions de B1, B 1
chemin SQL/JSON, 122 < prédicat de filtre de comparaison, Descriptions de la syntaxe BNF, expression de chemin SQL/
expressions de chemin SQL/JSON , 122 <= prédicat de filtre de JSON de base, B1
comparaison, expressions de chemin SQL/JSON, 122 ==
prédicat de filtre de comparaison, expressions de chemin SQL/JSON,
C
122 > prédicat de filtre de comparaison, expressions de
chemin SQL/JSON, 122 >= prédicat de filtre de comparaison, forme canonique d'un numéro JSON, 131 méthode
expressions de chemin SQL/JSON, 122 || prédicat de d'élément de plafond (), expressions de chemin SQL/JSON, 122
filtre, expressions de chemin SQL/JSON, 122 $, expressions de déclencheur de changement, guide de données défini
chemin SQL/JSON par l'utilisateur, 1827 contrainte de vérification utilisée pour garantir
des données JSON bien formées, 4 1 clause enfant
COLUMNS, fonction json_table SQL/JSON, 171
pour une variable SQL/JSON, 122 pour
l'élément de contexte, 122 Clause COLUMNS, fonction json_table SQL/JSON, prédicats de
filtre de comparaison 171 , expressions de chemin
SQL/JSON, condition 122 ,
UNE
méthode d'élément abs(), expressions de chemin SQL/JSON, 122
ABSENT ON NULL, fonctions de génération SQL/JSON, 191 Voir condition de filtre, conditions d'expressions de chemin
expression de chemin simple absolu, SQL/JSON, 122 SQL/JSON, SQL/JSON est json et JSON nul, 22 n'est pas json et
JSON nul, 22 indexation json_exists, 243 json_textcontains,
recherche ad hoc de données JSON, 249 procédure de
249
déclenchement add_vc, 1826 add_virtual_columns, procédure
DBMS_JSON PL/SQL, 1819, 1820, 1823 ajout de colonnes
virtuelles pour les champs JSON sur la base d'un index de
recherche compatible avec le guide de données, 1823
sur la base d'un guide de données hiérarchique, 1820
élément de contexte, expressions de chemin SQL/JSON,
122 create_view_on_path, procédure DBMS_JSON PL/
SQL, 1812, 1816 create_view, procédure
Vue ALL_JSON_COLUMNS, 43
DBMS_JSON PL/SQL, 1812, 1814
Vue ALL_JSON_DATAGUIDES, élément de
tableau 182 , JSON, étape de tableau 22 ,
expressions de chemin SQL/JSON, tableau 122 , JSON,
22 ré
Motclé ASCII, fonctions de requête SQL/JSON, 131
déclencheur de
changement de guide de
données défini par l'utilisateur, 1827
Index1
champs du guide de fonctions, SQL (suite)
données (suite) , 188 json_dataguide (suite) en tant que
plats, 1835 fonction d'agrégation, 1829 fonctions,
hiérarchiques, 1840 SQL/JSON json_array, 196 json_arrayagg, 198
multiples pour la même colonne JSON, 1829 méthode json_object, 194 json_objectagg, 197
d'élément date(), expressions de chemin SQL/JSON, 122 vue json_query, 161 json_table, 171 json_value
DBA_JSON_COLUMNS, 4 3 Vue DBA_JSON_DATAGUIDES, 182 function indexation basée, 243 indexation pour
Procédure PL/SQL DBMS_JSON.add_virtual_columns, 1819, 1820, les données géographiques, 221 valeur JSON
1823 Procédure PL/SQL DBMS_JSON.create_view, 1812, 1814 nulle, 153
Procédure PL/SQL DBMS_JSON.create_view_on_path, 18
12, 1816 DBMS_JSON.drop_virtual_columns Procédure PL/SQL,
1819, 1825 DBMS_JSON.get_index_dataguide Fonction
PL/SQL, 186, 188, 1814, 1820
g
génération de données JSON à l'aide de SQL, xix, 191
DBMS_JSON.rename_column Procédure PL/SQL, 188 données géographiques JSON, 221
diagrammes, syntaxe d'expression de chemin SQL/ GeoJSON, 221
JSON de base, B1 Document Object Model (DOM), 201 caractéristiques géométriques dans JSON,
manipulation de type DOM des données JSON, 201
221 get_index_dataguide, DBMS_JSON fonction PL/SQL, 186, 188,
méthode d'élément double() , Expressions de chemin SQL/JSON, 1814, 1820 méthode get(), types d'objets PL/SQL, 201
122 drop_virtual_columns, Procédure DBMS_JSON PL/SQL,
1819, 1825
H
colonnes virtuelles masquées projetées à partir de données JSON,
suppression de colonnes virtuelles pour les champs JSON, 1819
1819, 1825 noms de champ en double dans les
objets JSON, 51
je
E Magasin de colonnes IM, 251
Stockage de colonnes en mémoire
élément d'un tableau JSON, 22 clause remplissant JSON dans, 253 mise à
d'erreur, fonctions et conditions de requête SQL/JSON, 134 niveau des tables avec des données JSON pour, 254
prédicat de filtre existe, expressions de chemin indexation des données JSON index Btree composite pour
SQL/JSON, 122 plusieurs champs, 248 pour les requêtes json_exists, 245 pour
les requêtes json_table, 24 5 pour la recherche, 249 texte
Mot clé EXISTS, fonction json_table SQL/JSON, 171 intégral et plage numérique, 249
F
basé sur la fonction
champ, objet JSON, condition pour les données géographiques, 221
de filtre 22 , expressions de chemin SQL/JSON, expression de GeoJSON, 221 is
filtre 122 , expressions de chemin SQL/JSON, 122 méthode (not) json Condition SQL/JSON, 242 json_exists
d'élément floor(), expressions de chemin SQL/JSON, 122 Condition SQL/JSON, 243 json_value Fonction SQL/
JSON
Motsclés FOR ORDINALITY, fonction SQL/JSON json_table, 171 considérations sur les types de données,
247 pour les données géographiques,
Motsclés FORMAT JSON
221 pour les requêtes json_exists, 245
json_table Fonction SQL/JSON, 171
pour les requêtes json_table, 245
Fonctions de génération SQL/JSON, recherche en
spatial, 221 insertion de données JSON dans
texte intégral 191 des données JSON, étape de fonction
une colonne, 91 introspection des types d'objets PL/
249 , expressions de chemin SQL/JSON, fonctions 122 , SQL
SQL , 201 est la condition json SQL/JSON et JSON null,
json_dataguide
22
Index2
est json Condition SQL/JSON (suite) indexation, json_table Fonction SQL/JSON (suite)
242 généralise d'autres fonctions et conditions SQL/JSON,
Mot clé STRICT, 54 n'est 173 indexation pour les requêtes, 245
pas une condition JSON SQL/JSON et
JSON null, 22 indexation, 242 Clause CHEMIN EMBARQUÉ, 175
Clause PATH, 171
Mot clé STRICT, 54 condition json_textcontains SQL/JSON, 249 json_value
méthode d'élément, expressions de chemin SQL/JSON, champ Fonction SQL/JSON en tant que json_table, 153
de guide de données d'éléments 122 (mot clé de schéma JSON), 188 considérations sur le type de données pour l'indexation,
247 indexation basée sur la fonction pour les données
géographiques, 221 indexation pour les requêtes
J json_exists , 245 indexation pour les requêtes
Tableau JavaScript, 22 json_table, 245 valeur JSON nulle, 153
Notation JavaScript comparée à JSON, 21
Objet JavaScript, 22
Littéral d'objet JavaScript, 22
Notation d'objet JavaScript (JSON), 21 K
Encodage de caractères JSON, clé, objet JSON
conversion de jeu de caractères Voir le champ, les motsclés
de l'objet JSON
61, 61 par rapport à la notation JavaScript,
Schéma JSON, 188
21 par rapport à XML, présentation 24 , 11,
prise en charge 21 par Oracle Database,
restrictions, syntaxe A1 expression de chemin de L
base, 122, B1 strict et laxiste, 52
spécification de
syntaxe JSON
laxiste , méthode d'élément 54 length(), expressions de chemin SQL/
Guide des données JSON, 181
JSON, limitations 122 , prise en charge de la base de
Fonctions de génération JSON, xix, 191
données Oracle pour JSON, A1 chargement des données JSON dans
Types d'objets JSON, présentation
la base de données, méthode d'élément 91 lower(), Expressions de
PL/SQL, 201
chemin SQL/JSON, 122
Mots clés du
schéma JSON, 188
Index de recherche JSON, 249
json_array Fonction SQL/JSON, 196 M
JSON_ARRAY_T Type d'objet PL/SQL, 201 json_arrayagg
vue matérialisée des données JSON, 176
Fonction SQL/JSON, 198 json_dataguide Fonction SQL
plusieurs guides de données pour la même colonne JSON, 1829
en tant que fonction d'agrégation, 1829
JSON_ELEMENT_T Type d'objet PL/SQL, 201 N
json_exists Condition SQL/JSON en tant que
json_table, 143 indexation, 242, 243, 245 Clause NESTED PATH, json_table, 175 gestion des
valeurs nulles, fonctions de génération SQL/JSON, 191
Clause NULL ON EMPTY, Fonctions de requête SQL/JSON, 135
JSON_KEY_LIST Type d'objet PL/SQL, 201 Fonction
json_object SQL/JSON, 194
NULL ON NULL, Fonctions de génération SQL/JSON, 191
JSON_OBJECT_T Type d'objet PL/SQL, 201
json_objectagg Fonction SQL/JSON, 197 json_query
Clause de gestion NULL, fonctions de génération SQL/JSON,
Fonction SQL/JSON en tant que json_table, 162
191 méthode d'élément number(), expressions
de chemin SQL/JSON, 122
Mot clé JOLIE, 131
JSON_SCALAR_T Type d'objet PL/SQL, 201 json_table
indexation numérique, 249
Fonction SQL/JSON
Mot clé EXISTS, 171
POUR les motsclés d'ORDINALITE, 171 O
Motsclés FORMAT JSON, 171
o : champ de guide de données de fréquence, 188
o : champ de guide de données masqué, 1819
Index3
o : champ de guide de données high_value, restrictions, prise en charge de la base de données Oracle pour JSON, A1
188 o : champ de guide de données Clause de retour
last_analyzed, 188 o : champ de guide de Fonctions de génération SQL/JSON, 191
données length, 188 o : champ de guide de Fonctions de requête SQL/JSON, source
données low_value, 188 o : num_nulls data de ligne 131 , définition JSON, 171
guide champ, 188 o:path champ de guide de
données, 188 o:preferred_column_name champ de guide de
données, 188 littéral d'objet, Javascript, membre d'objet 22 , S
JSON, étape d'objet 22 , chemin SQL/JSON expressions,
122 objet, Javascript et JSON, 22 valeur scalaire, JSON,
schéma 22 , JSON, 181
SDO_GEOMETRY, 221
Clause ON EMPTY, Fonctions de requête SQL/JSON, 135 Champ
de guide de données oneOf (mot clé JSON Schema), 188 recherche de données JSON,
249 sérialisation de données
Fonctions Oracle SQL
json_dataguide en JSON à partir de requêtes, 131 de
tant que fonction d'agrégation, 1829 données JSON dans des types d'objet PL/SQL, 201
Prise en charge d'Oracle pour JSON dans la base de données, A1 définition de valeurs dans les types d'objets PL/SQL,
partitionnement 201 , informations de guide de données
dans l'index, 184 clauses COLUMNS sœurs, fonction
P json_table SQL/JSON, 171
clause parent COLUMNS, json_table fonction SQL/JSON, Accès simple aux documents Oracle (SODA), expression
171 analyse des données JSON vers les types de chemin simple 11 , SQL/JSON, 122
d'objet PL/SQL, 201 clause PATH, json_table, 171 expression SODA, 11
de chemin, syntaxe SQL/JSON, 122 réglage des performances, données spatiales JSON, 221
23 1 Fonctions PL/SQL DBMS_JSON.get_index_dataguide, Fonctions SQL
186, 188, 1814, 1820 Présentation des types d'objets json_dataguide en
PL/SQL, 201 Procédures PL/SQL DBMS_JSON.add_virtual_columns, tant que fonction d'agrégation, 1829
1819, 1820 , 1823 DBMS_JSON.create_view, 1812, 1814 Les conditions SQL/JSON
DBMS_JSON.create_view_on_path, 1812, 1816 sont (pas) json, 51
DBMS_JSON.drop_virtual_columns, 1819, est json et JSON null,
1825 DBMS_JSON.rename_column, 188 22 indexation, 242
n'est pas json et JSON
null, 22 indexation, 242
json_exists as
json_table, 143
indexation , 242, 243
json_textcontains, 249
Fonctions SQL/JSON pour
Motclé PRETTY, json_query, 131 joli
générer JSON, xix, 191 pour
impression dans les exemples de livre, xiii
interroger, 12 json_array, 196
projection de colonnes virtuelles à partir
json_arrayagg, 198 json_object, 194
de champs JSON, 1819 propriétés champ de guide de données
(motclé JSON Schema), 188 propriété, objet JSON json_objectagg, 197 json_query as
json_table, 162 json_table, 17 1
json_value as json_table, 153
Voir champ, méthode put() indexation basée sur la fonction, 221,
de l'objet JSON, types d'objet PL/SQL, 201 243 valeur JSON nulle, 153
R
fonction SQL rawtohex, pour insertion ou mise à jour avec
Colonne BLOB JSON, 31
expression de chemin simple relatif, SQL/JSON, 122 Fonctions de génération SQL/JSON, 191
rename_column, DBMS_JSON procédure PL/SQL, 188 Syntaxe d'expression de chemin
SQL/JSON de base, 122, B1
rendu des données JSON, 131
Index4
Expression de chemin SQL/JSON (suite) syntaxe V
(suite) assoupli, 127
valeur, JSON, variable
Fonctions de requête SQL/JSON 22 , expressions de chemin SQL/JSON, vue 122
AVEC motsclés WRAPPER, 133
Variable SQL/JSON, étape 122 , création basée sur un guide de données, 1814
expressions de chemin SQL/JSON, 122 stockage et création basée sur un index activé par un guide de données et
gestion des données JSON, présentation, 31 spécification de la un chemin, 1816 création à l'aide de la fonction
syntaxe JSON stricte, 54 SQL/JSON json_table, 176 vues
Le motclé STRICT ALL_JSON_COLUMNS, 43
n'est (pas) json Condition SQL/JSON, 54 TOUS_JSON_DATAGUIDES, 182
Fonctions de génération SQL/JSON, méthode DBA_JSON_COLUMNS, 43
d'élément 191 string(), expressions de chemin SQL/JSON, prise en DBA_JSON_DATAGUIDES, 182
charge 122 de JSON, base de données Oracle, USER_JSON_COLUMNS, 43
diagrammes de syntaxe A1 , expression de chemin SQL/JSON de USER_JSON_DATAGUIDES, 182 colonnes
base, virtuelles pour les champs JSON, ajoutant
B1 basé sur un index de recherche activé par guide de données,
1823 basé sur un guide de données
hiérarchique, 1820
J
méthode d'élément timestamp(), expressions de chemin
O
SQL/JSON, 122 représentation arborescente
des données JSON, 201 déclencheur pour les données JSON bien formées, 51
modifications du guide de données, 1826 champ de guide AVEC les motsclés UNIQUE KEYS, la condition JSON est json, 51
de données de type (mot clé JSON Schema), 188
Motsclés WITH WRAPPER, fonctions de requête SQL/JSON,
133
tu SANS motsclés UNIQUE KEYS, la condition JSON est json, clause
Motclé UNCONDITIONAL, fonctions de requête SQL/JSON, 133 wrapper 51 , fonctions de requête SQL/JSON, 133
noms de champ uniques dans les objets JSON, 51
mise à jour d'une colonne JSON, 91 méthode d'élément upper(), Motclé WRAPPER, fonctions de requête SQL/JSON, 133
expressions de chemin SQL/JSON, 122
X
Vue USER_JSON_COLUMNS, 43
XML
Vue USER_JSON_DATAGUIDES, 182 déclencheur
de changement de guide de données défini par l'utilisateur, 1827 par rapport à JSON, 24
DOM, 201
Index5
Index6

Guide Du Developpeur JSON

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Guide Du Developpeur JSON

Transféré par

Droits d'auteur :

Formats disponibles

Machine Translated by Google

"partie Numéro": Laxiste et strict : non. Le caractère de tabulation sans échappement n'est pas autorisé. L'espace est

{"id": 38327} (objet [{"id": 38327}] {"id": 38327} {"id": 38327}

[42, "a", vrai] [[42, "a", vrai]] [42, "a", vrai] [42, "a", vrai]

42 [42] Erreur (scalaire) [42]

DEMANDEUR TYPE DE TÉLÉPHONE PHONE_NUM

Utilise les données Guide des données plates Guide des données hiérarchiques

Oui Fonction PL/SQL Fonction PL/SQL

Non Fonction SQL json_dataguide N'est pas applicable

POnuméro Numéro POnuméro

Téléphone (téléphone sous forme de chaîne, pas d'objet ­ juste le numéro) chaîne de caractères Téléphone

type (type de téléphone) chaîne de caractères Type de téléphone

numéro (numéro de téléphone) chaîne de caractères Numéro de téléphone

ItemNumber (numéro d'article) Numéro Numéro d'article

Description (description de la pièce) chaîne de caractères DescriptionPartie

Nom Taper Description

nom de la table VARCHAR2 Nom de la table contenant la colonne

nom de colonne VARCHAR2 Nom d'une colonne JSON qui possède un

Nom Taper Description

chemin VARCHAR2 Une expression de

nouveau genre NUMÉRO Un nouveau type pour le chemin

new_type_length NUMÉRO Une nouvelle longueur de type pour

JPATH TAPER LONGUEUR

$.LineItems.Part numéro 512

JPATH TAPER LONGUEUR FRÉQUENCE

$.User numéro 8 100

IDENTIFIANT Nom Distance en kilomètres

|* 2| INDEX DE DOMAINE | PO_SEARCH_IDX | | | 4 (0)

json_scalaire json_compare_pred json_scalaire

Vous aimerez peut-être aussi

Téléphone (téléphone sous forme de chaîne, pas d'objet juste le numéro) chaîne de caractères Téléphone