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á.

# Geração automática de esquema JDBC
<a name="connect-jdbc-autoschemagen"></a>

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. 

**Topics**
+ [Limitações de geração de esquemas](#connect-jdbc-autoschemagen-limits)
+ [Opções do método de verificação](#connect-jdbc-autoschemagen-scanningoptions)
+ [Tipos de dados do Amazon DocumentDB](#connect-jdbc-autoschemagen-datatypes)
+ [Mapeamento de campos de documentos escalares](#connect-jdbc-autoschemagen-scalarfields)
+ [Manipulação de tipos de dados de objetos e matrizes](#connect-jdbc-autoschemagen-objectandarray)

## Limitações de geração de esquemas
<a name="connect-jdbc-autoschemagen-limits"></a>

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
<a name="connect-jdbc-autoschemagen-scanningoptions"></a>

O comportamento da amostragem pode ser modificado usando as opções de cadeia de conexão ou fonte de dados.
+ *scanMethod=*<option>
  + *random - (padrão) - Os documentos de amostra são retornados em ordem aleatória.*
  + *idForward* - Os documentos de amostra são devolvidos na ordem de identificação.
  + *idReverse* - Os documentos de amostra são retornados na ordem inversa da identificação.
  + *tudo* - Faça uma amostra de todos os documentos da coleção.
+ *ScanLimit=* <n>- O número de documentos a serem amostrados. O valor deve ser um inteiro positivo. O valor padrão é *1000*. Se *ScanMethod* estiver definido como *tudo*, essa opção será ignorada.

## Tipos de dados do Amazon DocumentDB
<a name="connect-jdbc-autoschemagen-datatypes"></a>

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.


| Tipos de dados MongoDB | Compatível com o DocumentDB | Tipo de dados JDBC | 
| --- | --- | --- | 
| Dados binários | Sim | VARBINARY | 
| Boolean | Sim | BOOLEAN | 
| Duplo | Sim | DOUBLE | 
| 32-bit Integer | Sim | INTEGER | 
| 64-bit Integer | Sim | BIGINT | 
| String | Sim | VARCHAR | 
| ObjectId | Sim | VARCHAR | 
| Data | Sim | TIMESTAMP | 
| Null | Sim | VARCHAR | 
| Expressão Regular | Sim | VARCHAR | 
| Timestamp | Sim | VARCHAR | 
| MinKey | Sim | VARCHAR | 
| MaxKey | Sim | VARCHAR | 
| Objeto | Sim | tabela virtual | 
| Array | Sim | tabela virtual | 
| Decimal128 | Não | DECIMAL | 
| JavaScript | Não | VARCHAR | 
| JavaScript (com escopo) | Não | VARCHAR | 
| Não definido | Não | VARCHAR | 
| Símbolo | Não | VARCHAR | 
| DBPointer (4.0\$1) | Não | VARCHAR | 

## Mapeamento de campos de documentos escalares
<a name="connect-jdbc-autoschemagen-scalarfields"></a>

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:


| Nome da tabela | Nome da coluna | Tipo de dado | Chave | 
| --- | --- | --- | --- | 
| equipe | id da equipe | VARCHAR | PK | 
| equipe | name | VARCHAR |  | 
| equipe | idade | INTEGER |  | 

### Promoção de conflitos de tipos de dados
<a name="connect-jdbc-autoschemagen-conflictpromo"></a>

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.


| Nome da tabela | Nome da coluna | Tipo de dado | Chave | 
| --- | --- | --- | --- | 
| equipe | id da equipe | VARCHAR | PK | 
| equipe | name | VARCHAR |  | 
| equipe | idade | VARCHAR |  | 

### Promoção de conflitos escalar-escalares
<a name="connect-jdbc-autoschemagen-scalarconflictpromo"></a>

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

![\[Diagrama de hierarquia mostrando como tipos de dados conflitantes serão promovidos quando não forem consistentes nos documentos.\]](http://docs.aws.amazon.com/pt_br/documentdb/latest/developerguide/images/jdbc/scalar-scalar-promotion.png)


### Promoção de conflitos do tipo complexo escalar
<a name="connect-jdbc-autoschemagen-scalar-complex"></a>

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: 


| Nome da tabela | Nome da coluna | Tipo de dado | Chave | 
| --- | --- | --- | --- | 
| customer2 | customer2 id | VARCHAR | PK | 
| customer2 | name | VARCHAR |  | 
| customer2 |  Assinatura | VARCHAR |  | 

e a tabela virtual customer1\$1subscriptions:


| Nome da tabela | Nome da coluna | Tipo de dado | Chave | 
| --- | --- | --- | --- | 
| customer1\$1subscriptions | customer1 id | VARCHAR | PK/FK | 
| customer1\$1subscriptions | subscriptions\$1index\$1lvl0 | BIGINT | PK | 
| customer1\$1subscriptions | valor | VARCHAR |  | 
| customer\$1address | cidade | VARCHAR |  | 
| customer\$1address | region | VARCHAR |  | 
| customer\$1address | país | VARCHAR |  | 
| customer\$1address | código | VARCHAR |  | 

## Manipulação de tipos de dados de objetos e matrizes
<a name="connect-jdbc-autoschemagen-objectandarray"></a>

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 (“\$1”).

A chave primária da tabela base (“\$1id”) 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
<a name="connect-jdbc-autoschemagen-embededobj"></a>

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: 


| Nome da tabela | Nome da coluna | Tipo de dado | Chave | 
| --- | --- | --- | --- | 
| customer | customer id | VARCHAR | PK | 
| customer | name | VARCHAR |  | 

e a tabela virtual customer\$1address:


| Nome da tabela | Nome da coluna | Tipo de dado | Chave | 
| --- | --- | --- | --- | 
| customer\$1address | customer id | VARCHAR | PK/FK | 
| customer\$1address | address1 | VARCHAR |  | 
| customer\$1address | address2 | VARCHAR |  | 
| customer\$1address | cidade | VARCHAR |  | 
| customer\$1address | region | VARCHAR |  | 
| customer\$1address | país | VARCHAR |  | 
| customer\$1address | código | VARCHAR |  | 

### Exemplo de campo de matriz incorporada
<a name="connect-jdbc-autoschemagen-embedarray"></a>

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: 


| Nome da tabela | Nome da coluna | Tipo de dado | Chave | 
| --- | --- | --- | --- | 
| customer1 | customer1 id | VARCHAR | PK | 
| customer1 | name | VARCHAR |  | 

e a tabela virtual customer1\$1subscriptions:


| Nome da tabela | Nome da coluna | Tipo de dado | Chave | 
| --- | --- | --- | --- | 
| customer1\$1subscriptions | customer1 id | VARCHAR | PK/FK | 
| customer1\$1subscriptions | subscriptions\$1index\$1lvl0 | BIGINT | PK | 
| customer1\$1subscriptions | valor | VARCHAR |  | 
| customer\$1address | cidade | VARCHAR |  | 
| customer\$1address | region | VARCHAR |  | 
| customer\$1address | país | VARCHAR |  | 
| customer\$1address | código | VARCHAR |  |