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.

• scanMethod=<option>

  • random - (predeterminado): los documentos de muestra se devuelven en orden aleatorio.

  • idForward: los documentos de muestra se devuelven por orden de identificación.

  • idReverse: los documentos de muestra se devuelven por orden inverso de identificación.

  • all (todos): muestra todos los documentos de la colección.

• scanLimit=<n>: el número de documentos que se van a muestrear. El valor debe ser un número entero positivo. El valor predeterminado es 1000. Si ScanMethod está establecido en todos, se omite esta opción.

Tipos de datos de Amazon DocumentDB

El servidor 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.

Tipos de datos de MongoDB	Compatible con DocumentDB	Tipo de datos JDBC
Datos Binary	Sí	VARBINARY
Booleano	Sí	BOOLEAN
Doble	Sí	DOBLE
Entero de 32 bits	Sí	INTEGER
Entero de 64 bits	Sí	BIGINT
Cadena	Sí	VARCHAR
ObjectId	Sí	VARCHAR
Date	Sí	MARCA DE TIEMPO
Nulo	Sí	VARCHAR
Expresión regular	Sí	VARCHAR
Timestamp	Sí	VARCHAR
MinKey	Sí	VARCHAR
MaxKey	Sí	VARCHAR
Objeto	Sí	tabla virtual
Matriz	Sí	tabla virtual
Decimal128	No	DECIMAL
JavaScript	No	VARCHAR
JavaScript (con alcance)	No	VARCHAR
Sin definir	No	VARCHAR
Símbolo	No	VARCHAR
dbPointer (4.0 y versiones posteriores)	No	VARCHAR

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:

Nombre de la tabla	Nombre de la columna	Tipo de datos	Clave
equipo	id de equipo	VARCHAR	PK
equipo	name	VARCHAR
equipo	edad	INTEGER

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.

Nombre de la tabla	Nombre de la columna	Tipo de datos	Clave
equipo	id de equipo	VARCHAR	PK
equipo	name	VARCHAR
equipo	edad	VARCHAR

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:

Nombre de la tabla	Nombre de la columna	Tipo de datos	Clave
customer2	Id customer2	VARCHAR	PK
customer2	name	VARCHAR
customer2	Suscripción	VARCHAR

y la tabla virtual customer1_subscriptions:

Nombre de la tabla	Nombre de la columna	Tipo de datos	Clave
customer1_subscriptions	Id customer1	VARCHAR	PK/FK
customer1_subscriptions	suscriptions_index_lvl0	BIGINT	PK
customer1_subscriptions	valor	VARCHAR
customer_address	ciudad	VARCHAR
customer_address	región	VARCHAR
customer_address	país	VARCHAR
customer_address	código	VARCHAR

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):

Nombre de la tabla	Nombre de la columna	Tipo de datos	Clave
cliente	Id del cliente	VARCHAR	PK
cliente	name	VARCHAR

y la tabla virtual custome_address:

Nombre de la tabla	Nombre de la columna	Tipo de datos	Clave
customer_address	Id del cliente	VARCHAR	PK/FK
customer_address	dirección1	VARCHAR
customer_address	dirección2	VARCHAR
customer_address	ciudad	VARCHAR
customer_address	región	VARCHAR
customer_address	país	VARCHAR
customer_address	código	VARCHAR

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:

Nombre de la tabla	Nombre de la columna	Tipo de datos	Clave
customer1	Id customer1	VARCHAR	PK
customer1	name	VARCHAR

y la tabla virtual customer1_subscriptions:

Nombre de la tabla	Nombre de la columna	Tipo de datos	Clave
customer1_subscriptions	Id customer1	VARCHAR	PK/FK
customer1_subscriptions	suscriptions_index_lvl0	BIGINT	PK
customer1_subscriptions	valor	VARCHAR
customer_address	ciudad	VARCHAR
customer_address	región	VARCHAR
customer_address	país	VARCHAR
customer_address	código	VARCHAR