Geração automática de esquema JDBC

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

O Amazon DocumentDB é um banco de dados de documentos e, portanto, não tem o conceito de tabelas e esquemas. No entanto, ferramentas de BI, como o Tableau, esperam que o banco de dados conectado apresente um esquema. Especificamente, quando a conexão do driver JDBC precisar obter o esquema da coleção no banco de dados, ela pesquisará todas as coleções no banco de dados. O driver determinará se já existe uma versão em cache do esquema dessa coleção. Se uma versão em cache não existir, ela fará uma amostra da coleção para documentos e criará um esquema com base no comportamento a seguir.

Limitações de geração de esquemas

O driver JDBC DocumentDB impõe um limite no tamanho dos identificadores em 128 caracteres. O gerador de esquema pode truncar o comprimento dos identificadores gerados (nomes de tabelas e nomes de colunas) para garantir que eles se encaixem nesse limite.

Opções do método de verificação

O comportamento da amostragem pode ser modificado usando as opções de cadeia de conexão ou fonte de dados.

Tipos de dados do Amazon DocumentDB

O servidor do Amazon DocumentDB suporta vários tipos de dados do MongoDB. Listados abaixo estão os tipos de dados compatíveis e seus tipos de dados JDBC associados.

Mapeamento de campos de documentos escalares

Ao digitalizar uma amostra de documentos de uma coleção, o driver JDBC criará um ou mais esquemas para representar as amostras na coleção. Em geral, um campo escalar no documento é mapeado para uma coluna no esquema da tabela. Por exemplo, em uma coleção chamada team e em um único documento{ "_id" : "112233", "name" : "Alastair", "age": 25 }, isso seria mapeado para o esquema:

Promoção de conflitos de tipos de dados

Ao digitalizar os documentos de amostra, é possível que os tipos de dados de um campo não sejam consistentes de documento para documento. Nesse caso, o driver JDBC promoverá o tipo de dados JDBC a um tipo de dado comum adequado a todos os tipos de dados dos documentos de amostra.

Por exemplo:

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

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

O campo de idade é do tipo inteiro de 32 bits no primeiro documento, mas string no segundo documento. Aqui, o driver JDBC promoverá o tipo de dados JDBC para VARCHAR para lidar com qualquer tipo de dados quando encontrado.

Promoção de conflitos escalar-escalares

O diagrama a seguir mostra a maneira pela qual os conflitos de tipo de dados escalar-escalar são resolvidos.

Promoção de conflitos do tipo complexo escalar

Assim como os conflitos do tipo escalar-escalar, o mesmo campo em documentos diferentes pode ter tipos de dados conflitantes entre complexos (matriz e objeto) e escalares (inteiro, booleano etc.). Todos esses conflitos são resolvidos (promovidos) à VARCHAR nesses campos. Nesse caso, os dados da matriz e do objeto são retornados como a representação JSON.

Matriz incorporada - Exemplo de conflito de campo de string:

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

O exemplo acima mapeia o esquema da tabela customer2:

e a tabela virtual customer1_subscriptions:

Manipulação de tipos de dados de objetos e matrizes

Até agora, descrevemos apenas como os tipos de dados escalares são mapeados. Os tipos de dados de objeto e matriz são (atualmente) mapeados para tabelas virtuais. O driver JDBC criará uma tabela virtual para representar campos de objetos ou matrizes em um documento. O nome da tabela virtual mapeada concatenará o nome da coleção original seguido pelo nome do campo separado pelo caractere sublinhado (“_”).

A chave primária da tabela base (“_id”) assume um novo nome na nova tabela virtual e é fornecida como uma chave externa para a tabela base associada.

Para campos do tipo matriz incorporada, as colunas de índice são geradas para representar o índice na matriz em cada nível da matriz.

Exemplo de campo de objeto incorporado

Para campos de objeto em um documento, um mapeamento para uma tabela virtual é criado pelo driver JDBC.

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

O exemplo acima mapeia o esquema da tabela de clientes:

e a tabela virtual customer_address:

Exemplo de campo de matriz incorporada

Para campos de matriz em um documento, um mapeamento para uma tabela virtual também é criado pelo driver JDBC.

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

O exemplo acima mapeia o esquema da tabela customer1:

e a tabela virtual customer1_subscriptions: