Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Generazione automatica di schemi JDBC

Amazon DocumentDB è un database di documenti e pertanto non ha il concetto di tabelle e schema. Tuttavia, gli strumenti di BI come Tableau si aspettano che il database a cui si connette presenti uno schema. In particolare, quando la connessione al driver JDBC deve ottenere lo schema per la raccolta nel database, eseguirà il polling di tutte le raccolte nel database. Il driver determinerà se esiste già una versione memorizzata nella cache dello schema per quella raccolta. Se non esiste una versione memorizzata nella cache, campionerà la raccolta per i documenti e creerà uno schema basato sul seguente comportamento.

Limitazioni alla generazione dello schema

Il driver JDBC DocumentDB impone un limite alla lunghezza degli identificatori a 128 caratteri. Il generatore di schemi può troncare la lunghezza degli identificatori generati (nomi di tabelle e nomi di colonne) per garantire che soddisfino tale limite.

Opzioni del metodo di scansione

Il comportamento di campionamento può essere modificato utilizzando le opzioni della stringa di connessione o dell'origine dati.

Tipi di dati Amazon DocumentDB

Il server Amazon DocumentDB supporta diversi tipi di dati MongoDB. Di seguito sono elencati i tipi di dati supportati e i tipi di dati JDBC associati.

Mappatura dei campi scalari del documento

Durante la scansione di un campione di documenti da una raccolta, il driver JDBC creerà uno o più schemi per rappresentare gli esempi della raccolta. In generale, un campo scalare nel documento è mappato su una colonna dello schema della tabella. Ad esempio, in una raccolta denominata team e in un singolo documento{ "_id" : "112233", "name" : "Alastair", "age": 25 }, questo dovrebbe corrispondere allo schema:

Promozione dei conflitti tra tipi di dati

Durante la scansione dei documenti campione, è possibile che i tipi di dati per un campo non siano coerenti da un documento all'altro. In questo caso, il driver JDBC promuoverà il tipo di dati JDBC a un tipo di dati comune adatto a tutti i tipi di dati dei documenti campionati.

Ad esempio:

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

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

Il campo dell'età è di tipo intero a 32 bit nel primo documento ma stringa nel secondo documento. Qui il driver JDBC promuoverà il tipo di dati JDBC a VARCHAR per gestire entrambi i tipi di dati quando vengono rilevati.

Scalar-scalar promozione dei conflitti

Il diagramma seguente mostra il modo in cui vengono risolti i conflitti tra tipi di dati scalari.

Scalar-complex promozione dei conflitti di tipo

Analogamente ai conflitti di tipo scalare-scalare, lo stesso campo in documenti diversi può avere tipi di dati in conflitto tra complessi (array e oggetto) e scalari (intero, booleano, ecc.). Tutti questi conflitti vengono risolti (promossi) a VARCHAR per quei campi. In questo caso, i dati dell'array e dell'oggetto vengono restituiti come rappresentazione JSON.

Embedded Array - Esempio di conflitto tra campi di stringhe:

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

L'esempio precedente è mappato allo schema della tabella customer2:

e la tabella virtuale customer1_subscriptions:

Gestione dei tipi di dati di oggetti e array

Finora, abbiamo solo descritto come vengono mappati i tipi di dati scalari. I tipi di dati Object e Array sono (attualmente) mappati su tabelle virtuali. Il driver JDBC creerà una tabella virtuale per rappresentare i campi oggetto o array in un documento. Il nome della tabella virtuale mappata concatenerà il nome della raccolta originale seguito dal nome del campo separato da un carattere di sottolineatura («_»).

La chiave primaria della tabella base («_id») assume un nuovo nome nella nuova tabella virtuale e viene fornita come chiave esterna alla tabella base associata.

Per i campi di tipo array incorporato, vengono generate colonne di indice per rappresentare l'indice nell'array a ogni livello dell'array.

Esempio di campo oggetto incorporato

Per i campi oggetto in un documento, il driver JDBC crea una mappatura a una tabella virtuale.

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

L'esempio precedente è mappato allo schema per la tabella dei clienti:

e la tabella virtuale customer_address:

Esempio di campo di matrice incorporato

Per i campi di matrice in un documento, il driver JDBC crea anche una mappatura a una tabella virtuale.

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

L'esempio precedente è mappato allo schema della tabella customer1:

e la tabella virtuale customer1_subscriptions: