Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Automatische JDBC-Schemagenerierung
<a name="connect-jdbc-autoschemagen"></a>

Amazon DocumentDB ist eine Dokumentdatenbank und hat daher nicht das Konzept von Tabellen und Schemas. BI-Tools wie Tableau erwarten jedoch, dass die Datenbank, mit der sie verbunden werden, ein Schema präsentiert. Insbesondere wenn die JDBC-Treiberverbindung das Schema für die Sammlung in der Datenbank abrufen muss, werden alle Sammlungen in der Datenbank abgefragt. Der Treiber ermittelt, ob eine zwischengespeicherte Version des Schemas für diese Sammlung bereits existiert. Wenn keine zwischengespeicherte Version vorhanden ist, sucht er in der Sammlung nach Dokumenten und erstellt ein Schema, das auf dem folgenden Verhalten basiert. 

**Topics**
+ [Einschränkungen bei der Schemagenerierung](#connect-jdbc-autoschemagen-limits)
+ [Optionen für die Scanmethode](#connect-jdbc-autoschemagen-scanningoptions)
+ [Amazon-DocumentDB-Datentypen](#connect-jdbc-autoschemagen-datatypes)
+ [Zuordnung skalarer Dokumentfelder](#connect-jdbc-autoschemagen-scalarfields)
+ [Behandlung von Objekt- und Array-Datentypen](#connect-jdbc-autoschemagen-objectandarray)

## Einschränkungen bei der Schemagenerierung
<a name="connect-jdbc-autoschemagen-limits"></a>

Der DocumentDB-JDBC-Treiber begrenzt die Länge von Bezeichnern auf 128 Zeichen. Der Schemagenator kann die Länge der generierten Bezeichner (Tabellennamen und Spaltennamen) kürzen, um sicherzustellen, dass sie dieser Grenze entsprechen. 

## Optionen für die Scanmethode
<a name="connect-jdbc-autoschemagen-scanningoptions"></a>

Das Sampling-Verhalten kann mithilfe von Verbindungszeichenfolgen- oder Datenquellenoptionen geändert werden.
+ *ScanMethode= * <option>
  + *random — (Standard) — Die Beispieldokumente werden in zufälliger Reihenfolge zurückgegeben. *
  + *idForward * — Die Beispieldokumente werden in der Reihenfolge ihrer ID zurückgegeben.
  + *idReverse * — Die Beispieldokumente werden in umgekehrter Reihenfolge der ID zurückgegeben.
  + *all * — Probieren Sie alle Dokumente in der Sammlung aus.
+ *ScanLimit= * <n>— Die Anzahl der Dokumente, für die eine Stichprobe erstellt werden soll. Der Wert muss eine positive ganze Zahl sein. Der Standardwert ist * 1000. * Wenn * ScanMethod auf * all gesetzt * ist*, wird diese Option ignoriert.

## Amazon-DocumentDB-Datentypen
<a name="connect-jdbc-autoschemagen-datatypes"></a>

Der Amazon DocumentDB-Server unterstützt eine Reihe von MongoDB-Datentypen. Nachfolgend sind die unterstützten Datentypen und die zugehörigen JDBC-Datentypen aufgeführt.


| MongoDB-Datentyp | Wird in DocumentDB unterstützt | JDBC-Datentyp | 
| --- | --- | --- | 
| Binäre Daten | Ja | VARBINARY | 
| Boolesch | Ja | BOOLEAN | 
| Double | Ja | DOUBLE | 
| 32-Bit-Ganzzahl | Ja | INTEGER | 
| 64-Bit-Ganzzahl | Ja | BIGINT | 
| Zeichenfolge | Ja | VARCHAR | 
| ObjectId | Ja | VARCHAR | 
| Date | Ja | TIMESTAMP (ZEITSTEMPEL) | 
| Null | Ja | VARCHAR | 
| Regulärer Ausdruck | Ja | VARCHAR | 
| Zeitstempel | Ja | VARCHAR | 
| MinKey | Ja | VARCHAR | 
| MaxKey | Ja | VARCHAR | 
| Objekt | Ja | virtueller Tisch | 
| Array | Ja | virtueller Tisch | 
| Decimal128 | Nein | DECIMAL | 
| JavaScript | Nein | VARCHAR | 
| JavaScript (mit Zielfernrohr) | Nein | VARCHAR | 
| Undefined | Nein | VARCHAR | 
| Symbol | Nein | VARCHAR | 
| dbPointer (4.0\+) | Nein | VARCHAR | 

## Zuordnung skalarer Dokumentfelder
<a name="connect-jdbc-autoschemagen-scalarfields"></a>

Beim Scannen einer Auswahl von Dokumenten aus einer Sammlung erstellt der JDBC-Treiber ein oder mehrere Schemas, um die Beispiele in der Sammlung darzustellen. Im Allgemeinen wird ein Skalarfeld im Dokument einer Spalte im Tabellenschema zugeordnet. In einer Sammlung mit dem Namen team und einem einzelnen Dokument würde dies `{ "_id" : "112233", "name" : "Alastair", "age": 25 }` beispielsweise dem Schema zugeordnet werden:


| Tabellenname | Spaltenname | Datentyp | Key (Schlüssel) | 
| --- | --- | --- | --- | 
| Team | Team-ID  | VARCHAR | PK | 
| Team | Name | VARCHAR |  | 
| Team | age | INTEGER |  | 

### Förderung von Konflikten nach Datentyp
<a name="connect-jdbc-autoschemagen-conflictpromo"></a>

Beim Scannen der ausgewählten Dokumente ist es möglich, dass die Datentypen für ein Feld von Dokument zu Dokument nicht konsistent sind. In diesem Fall stuft der JDBC-Treiber den JDBC-Datentyp auf einen gemeinsamen Datentyp um, der für alle Datentypen der Stichprobendokumente geeignet ist. 

Zum Beispiel:

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

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

Das * * Altersfeld hat im ersten Dokument den Typ 32-Bit-Ganzzahl, im zweiten Dokument jedoch eine Zeichenfolge. Hier stuft der JDBC-Treiber den JDBC-Datentyp auf VARCHAR um, um beide Datentypen zu verarbeiten, wenn er angetroffen wird.


| Tabellenname | Spaltenname | Datentyp | Key (Schlüssel) | 
| --- | --- | --- | --- | 
| Team | Team-ID  | VARCHAR | PK | 
| Team | Name | VARCHAR |  | 
| Team | age | VARCHAR |  | 

### Scalar-scalar Förderung von Konflikten
<a name="connect-jdbc-autoschemagen-scalarconflictpromo"></a>

Das folgende Diagramm zeigt, wie Konflikte zwischen skalaren Datentypen gelöst werden.

![Das Hierarchiediagramm zeigt, wie widersprüchliche Datentypen heraufgestuft werden, wenn sie in Dokumenten nicht konsistent sind.](http://docs.aws.amazon.com/de_de/documentdb/latest/devguide/images/jdbc/scalar-scalar-promotion.png)


### Scalar-complex Geben Sie Konfliktherstellung ein
<a name="connect-jdbc-autoschemagen-scalar-complex"></a>

Wie bei Konflikten zwischen skalarem Typ und Skalar kann dasselbe Feld in verschiedenen Dokumenten widersprüchliche Datentypen zwischen komplex (Array und Objekt) und skalar (Integer, Boolean usw.) aufweisen. Alle diese Konflikte werden für diese Felder in VARCHAR aufgelöst (heraufgestuft). In diesem Fall werden Array- und Objektdaten als JSON-Repräsentation zurückgegeben.

Beispiel für einen Konflikt zwischen eingebettetem Array und Zeichenfolgenfeld:

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

Das vorherige Beispiel ist dem Schema für die Tabelle customer2 zugeordnet: 


| Tabellenname | Spaltenname | Datentyp | Key (Schlüssel) | 
| --- | --- | --- | --- | 
| Kunde2 | Kunde2 ist  | VARCHAR | PK | 
| Kunde2 | Name | VARCHAR |  | 
| Kunde2 | Abonnement | VARCHAR |  | 

und die virtuelle Tabelle customer1\_subscriptions:


| Tabellenname | Spaltenname | Datentyp | Key (Schlüssel) | 
| --- | --- | --- | --- | 
| customer1\_subscriptions | Kunde 1 ist  | VARCHAR | PK/FK | 
| customer1\_Abonnements | abonnement\_index\_lvl0 | BIGINT | PK | 
| Kunde 1: Abonnements | value | VARCHAR |  | 
| customer\_address | city | VARCHAR |  | 
| customer\_address | Region | VARCHAR |  | 
| customer\_address | country | VARCHAR |  | 
| customer\_address | Code | VARCHAR |  | 

## Behandlung von Objekt- und Array-Datentypen
<a name="connect-jdbc-autoschemagen-objectandarray"></a>

Bisher haben wir nur beschrieben, wie skalare Datentypen abgebildet werden. Objekt- und Array-Datentypen werden (derzeit) virtuellen Tabellen zugeordnet. Der JDBC-Treiber erstellt eine virtuelle Tabelle, die entweder Objekt- oder Array-Felder in einem Dokument darstellt. Der Name der zugewiesenen virtuellen Tabelle verkettet den Namen der ursprünglichen Sammlung, gefolgt vom Feldnamen, der durch einen Unterstrich („\_“) getrennt ist.

Der Primärschlüssel der Basistabelle („\_id“) nimmt in der neuen virtuellen Tabelle einen neuen Namen an und wird als Fremdschlüssel für die zugehörige Basistabelle bereitgestellt.

Für Felder vom Typ eingebettetes Array werden Indexspalten generiert, um den Index im Array auf jeder Ebene des Arrays darzustellen.

### Beispiel für ein eingebettetes Objektfeld
<a name="connect-jdbc-autoschemagen-embededobj"></a>

Für Objektfelder in einem Dokument wird vom JDBC-Treiber eine Zuordnung zu einer virtuellen Tabelle erstellt.

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

Das vorherige Beispiel ist dem Schema für die Kundentabelle zugeordnet: 


| Tabellenname | Spaltenname | Datentyp | Key (Schlüssel) | 
| --- | --- | --- | --- | 
| customer | Kunden-ID  | VARCHAR | PK | 
| customer | Name | VARCHAR |  | 

und die virtuelle Tabelle customer\_address:


| Tabellenname | Spaltenname | Datentyp | Key (Schlüssel) | 
| --- | --- | --- | --- | 
| customer\_address | Kunden-ID  | VARCHAR | PK/FK | 
| customer\_address | Adresse1 | VARCHAR |  | 
| customer\_address | Adresse2 | VARCHAR |  | 
| customer\_address | city | VARCHAR |  | 
| customer\_address | Region | VARCHAR |  | 
| customer\_address | country | VARCHAR |  | 
| customer\_address | Code | VARCHAR |  | 

### Beispiel für ein eingebettetes Array-Feld
<a name="connect-jdbc-autoschemagen-embedarray"></a>

Für Array-Felder in einem Dokument wird vom JDBC-Treiber auch eine Zuordnung zu einer virtuellen Tabelle erstellt.

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

Das vorherige Beispiel ist dem Schema für die Tabelle customer1 zugeordnet: 


| Tabellenname | Spaltenname | Datentyp | Key (Schlüssel) | 
| --- | --- | --- | --- | 
| Kunde1 | Kunde1 ist  | VARCHAR | PK | 
| Kunde1 | Name | VARCHAR |  | 

und die virtuelle Tabelle customer1\_subscriptions:


| Tabellenname | Spaltenname | Datentyp | Key (Schlüssel) | 
| --- | --- | --- | --- | 
| customer1\_subscriptions | Kunde 1 ist  | VARCHAR | PK/FK | 
| customer1\_Abonnements | abonnement\_index\_lvl0 | BIGINT | PK | 
| Kunde 1: Abonnements | value | VARCHAR |  | 
| customer\_address | city | VARCHAR |  | 
| customer\_address | Region | VARCHAR |  | 
| customer\_address | country | VARCHAR |  | 
| customer\_address | Code | VARCHAR |  |