Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Generación automática de esquemas JDBC

Amazon DocumentDB es una base de datos de documentos y, por lo tanto, no tiene el concepto de tablas y esquema. Sin embargo, las herramientas de inteligencia empresarial, como Tableau, esperan que la base de datos a la que se conecta presente un esquema. En concreto, cuando la conexión del controlador JDBC necesite obtener el esquema de la colección en la base de datos, consultará todas las colecciones de la base de datos. El controlador determinará si ya existe una versión en caché del esquema para esa colección. Si no existe una versión en caché, tomará muestras de la colección de documentos y creará un esquema basado en el siguiente comportamiento.

Limitaciones de generación de esquemas

El controlador JDBC de DocumentDB impone un límite de 128 caracteres a la longitud de los identificadores. El generador de esquemas puede truncar la longitud de los identificadores generados (nombres de tablas y nombres de columnas) para garantizar que se ajusten a ese límite.

Opciones del método de análisis

El comportamiento del muestreo se puede modificar mediante la cadena de conexión o las opciones de origen de datos.

Tipos de datos de Amazon DocumentDB

El servidor de Amazon DocumentDB admite varios tipos de datos de MongoDB. A continuación se enumeran los tipos de datos compatibles y sus tipos de datos JDBC asociados.

Asignación de campos de documentos escalares

Al escanear una muestra de documentos de una colección, el controlador JDBC creará uno o más esquemas para representar las muestras de la colección. En general, un campo escalar del documento se asigna a una columna del esquema de la tabla. Por ejemplo, en una colección denominada team y en un solo documento { "_id" : "112233", "name" : "Alastair", "age": 25 }, esto se asignaría al esquema:

Promoción de conflictos de tipos de datos

Al digitalizar los documentos de muestra, es posible que los tipos de datos de un campo no sean coherentes de un documento a otro. En este caso, el controlador JDBC convertirá el tipo de datos JDBC en un tipo de datos común que se adapte a todos los tipos de datos de los documentos muestreados.

Por ejemplo:

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

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

El campo age (edad) es de tipo entero de 32 bits en el primer documento, pero de tipo cadena en el segundo documento. En este caso, el controlador JDBC promoverá el tipo de datos JDBC a VARCHAR para gestionar cualquier tipo de datos cuando los encuentre.

Promoción de conflictos escalares-escalares

El siguiente diagrama muestra la forma en que se resuelven los conflictos entre tipos de datos escalares-escalares.

Promoción de conflictos de tipo escalar complejo

Al igual que ocurre con los conflictos entre tipos escalares-escalares, un mismo campo en diferentes documentos puede tener tipos de datos conflictivos entre complejos (matriz y objeto) y escalares (enteros, booleanos, etc.). Todos estos conflictos se resuelven (se transfieren) a VARCHAR para esos campos. En este caso, los datos de matriz y objeto se devuelven como representación JSON.

Ejemplo de conflicto entre matriz incrustada y campo de cadena:

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

El ejemplo anterior se asigna al esquema de la tabla customer2:

y la tabla virtual customer1_subscriptions:

Manejo de tipos de datos de objetos y matrices

Hasta ahora, solo hemos descrito cómo se asignan los tipos de datos escalares. Los tipos de datos Object (objeto) y Array (matriz) están (actualmente) asignados a tablas virtuales. El controlador JDBC creará una tabla virtual para representar los campos de objeto o matriz de un documento. El nombre de la tabla virtual asignada concatenará el nombre de la colección original seguido del nombre del campo separado por un carácter de subrayado (“_”).

La clave principal de la tabla base (“_id”) adopta un nuevo nombre en la nueva tabla virtual y se proporciona como clave externa a la tabla base asociada.

En el caso de los campos de tipo matriz incrustados, las columnas de índice se generan para representar el índice de la matriz en cada nivel de la matriz.

Ejemplo de campo de objeto incrustado

En el caso de los campos de objetos de un documento, el controlador JDBC crea una asignación a una tabla virtual.

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

El ejemplo anterior se asigna al esquema de la tabla customer (cliente):

y la tabla virtual custome_address:

Ejemplo de campo de matriz incrustado

En el caso de los campos de objetos de un documento, el controlador JDBC crea una asignación a una tabla virtual.

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

El ejemplo anterior se asigna al esquema de la tabla customer1:

y la tabla virtual customer1_subscriptions: