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

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.

Einschränkungen bei der Schemagenerierung

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

Das Sampling-Verhalten kann mithilfe von Verbindungszeichenfolgen- oder Datenquellenoptionen geändert werden.

Amazon-DocumentDB-Datentypen

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.

Zuordnung skalarer Dokumentfelder

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:

Förderung von Konflikten nach Datentyp

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.

Scalar-scalar Förderung von Konflikten

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

Scalar-complex Geben Sie Konfliktherstellung ein

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:

und die virtuelle Tabelle customer1_subscriptions:

Behandlung von Objekt- und Array-Datentypen

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

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:

und die virtuelle Tabelle customer_address:

Beispiel für ein eingebettetes Array-Feld

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:

und die virtuelle Tabelle customer1_subscriptions: