Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Génération automatique de schémas JDBC

Amazon DocumentDB est une base de données de documents et ne possède donc pas le concept de tables et de schémas. Cependant, les outils de BI tels que Tableau s'attendent à ce que la base de données qu'ils connectent présente un schéma. Plus précisément, lorsque la connexion au pilote JDBC doit obtenir le schéma de la collection dans la base de données, elle interroge toutes les collections de la base de données. Le pilote déterminera s'il existe déjà une version mise en cache du schéma pour cette collection. S'il n'existe pas de version mise en cache, elle échantillonnera la collection de documents et créera un schéma basé sur le comportement suivant.

Limites de génération de schémas

Le pilote JDBC DocumentDB impose une limite de 128 caractères à la longueur des identificateurs. Le générateur de schéma peut tronquer la longueur des identifiants générés (noms de tables et noms de colonnes) pour s'assurer qu'ils correspondent à cette limite.

Options de méthode de numérisation

Le comportement d'échantillonnage peut être modifié à l'aide des options de chaîne de connexion ou de source de données.

Types de données Amazon DocumentDB

Le serveur Amazon DocumentDB prend en charge un certain nombre de types de données MongoDB. Les types de données pris en charge et les types de données JDBC associés sont répertoriés ci-dessous.

Mappage de champs de documents scalaires

Lors de la numérisation d'un échantillon de documents d'une collection, le pilote JDBC crée un ou plusieurs schémas pour représenter les échantillons de la collection. En général, un champ scalaire du document correspond à une colonne du schéma de la table. Par exemple, dans une collection nommée team et dans un seul document{ "_id" : "112233", "name" : "Alastair", "age": 25 }, cela correspondrait au schéma :

Promotion des conflits liés aux types de données

Lors de la numérisation des échantillons de documents, il est possible que les types de données d'un champ ne soient pas cohérents d'un document à l'autre. Dans ce cas, le pilote JDBC fera passer le type de données JDBC à un type de données commun qui conviendra à tous les types de données des documents échantillonnés.

Par exemple :

{
"_id" : "112233",
"name" : "Alastair", "age" : 25
}

{
"_id" : "112244",
"name" : "Benjamin",
"age" : "32"
}

Le champ d'âge est de type entier 32 bits dans le premier document mais chaîne dans le second document. Ici, le pilote JDBC va promouvoir le type de données JDBC en VARCHAR pour gérer l'un ou l'autre type de données lorsqu'il est rencontré.

Scalar-scalar promotion des conflits

Le schéma suivant montre la manière dont les conflits de types de données scalaires-scalaires sont résolus.

Scalar-complex type de promotion des conflits

À l'instar des conflits de type scalaire-scalaire, le même champ dans différents documents peut contenir des types de données contradictoires entre complexe (tableau et objet) et scalaire (entier, booléen, etc.). Tous ces conflits sont résolus (promus) à VARCHAR pour ces domaines. Dans ce cas, les données des tableaux et des objets sont renvoyées sous forme de représentation JSON.

Exemple de conflit entre tableau intégré et champ de chaîne :

{
   "_id":"112233",
   "name":"George Jackson",
   "subscriptions":[
      "Vogue",
      "People",
      "USA Today"
   ]
}
{
   "_id":"112244",
   "name":"Joan Starr",
   "subscriptions":1
}

L'exemple précédent correspond au schéma de la table customer2 :

et la table virtuelle customer1_subscriptions :

Gestion des types de données d'objets et de tableaux

Jusqu'à présent, nous n'avons décrit que la façon dont les types de données scalaires sont mappés. Les types de données Object et Array sont (actuellement) mappés sur des tables virtuelles. Le pilote JDBC créera une table virtuelle pour représenter les champs d'objet ou de tableau d'un document. Le nom de la table virtuelle mappée concaténera le nom de la collection d'origine suivi du nom du champ séparé par un caractère de soulignement (« _ »).

La clé primaire de la table de base (« _id ») prend un nouveau nom dans la nouvelle table virtuelle et est fournie en tant que clé étrangère à la table de base associée.

Pour les champs de type tableau intégré, des colonnes d'index sont générées pour représenter l'indice dans le tableau à chaque niveau du tableau.

Exemple de champ d'objet intégré

Pour les champs d'objet d'un document, un mappage vers une table virtuelle est créé par le pilote JDBC.

{
   "Collection: customer",
   "_id":"112233",
   "name":"George Jackson",
   "address":{
      "address1":"123 Avenue Way",
      "address2":"Apt. 5",
      "city":"Hollywood",
      "region":"California",
      "country":"USA",
      "code":"90210"
   }
}

L'exemple précédent correspond au schéma de la table des clients :

et la table virtuelle customer_address :

Exemple de champ de tableau intégré

Pour les champs de tableau d'un document, un mappage vers une table virtuelle est également créé par le pilote JDBC.

{
   "Collection: customer1",
   "_id":"112233",
   "name":"George Jackson",
   "subscriptions":[
      "Vogue",
      "People",
      "USA Today"
   ]
}

L'exemple précédent correspond au schéma de la table customer1 :

et la table virtuelle customer1_subscriptions :