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.
JDBCautomatische Schemagenerierung
Amazon DocumentDB ist eine Dokumentendatenbank und hat daher nicht das Konzept von Tabellen und Schemas. BI-Tools wie Tableau erwarten jedoch, dass die Datenbank, mit der sie eine Verbindung herstellen, ein Schema darstellt. Insbesondere wenn die JDBC Treiberverbindung das Schema für die Sammlung in der Datenbank abrufen muss, fragt sie nach allen Sammlungen in der Datenbank ab. Der Treiber ermittelt, ob bereits eine zwischengespeicherte Version des Schemas für diese Sammlung vorhanden ist. Wenn keine zwischengespeicherte Version vorhanden ist, wird anhand der Sammlung nach Dokumenten gesucht und ein Schema erstellt, das auf dem folgenden Verhalten basiert.
Themen
Einschränkungen bei der Schemagenerierung
Der JDBC DocumentDB-Treiber begrenzt die Länge von Bezeichnern auf 128 Zeichen. Der Schema-Generator 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.
-
scanMethod= <option>
-
random - (Standard) - Die Beispieldokumente werden in zufälliger Reihenfolge zurückgegeben.
-
idForward- Die Musterdokumente werden in der Reihenfolge ihrer ID zurückgegeben.
-
idReverse- Die Musterdokumente werden in umgekehrter Reihenfolge der ID zurückgegeben.
-
all — Probieren Sie alle Dokumente in der Sammlung aus.
-
-
scanLimit= <n>- Die Anzahl der Dokumente, die untersucht werden sollen. Der Wert muss eine positive ganze Zahl sein. Der Standardwert ist 1000. Wenn auf all gesetzt scanMethodist, wird diese Option ignoriert.
Amazon-DocumentDB-Datentypen
Der Amazon DocumentDB-Server unterstützt eine Reihe von MongoDB-Datentypen. Im Folgenden sind die unterstützten Datentypen und die zugehörigen JDBC Datentypen aufgeführt.
MongoDB-Datentyp | Wird in DocumentDB unterstützt | JDBCDatentyp |
---|---|---|
Binäre Daten | Ja | VARBINARY |
Boolesch | Ja | BOOLEAN |
Double | Ja | DOUBLE |
32-Bit-Ganzzahl | Ja | INTEGER |
64-Bit-Ganzzahl | Ja | BIGINT |
String | Ja | VARCHAR |
ObjectId | Ja | VARCHAR |
Datum | Ja | TIMESTAMP |
Null | Ja | VARCHAR |
Regulärer Ausdruck | Ja | VARCHAR |
Zeitstempel | Ja | VARCHAR |
MinKey | Ja | VARCHAR |
MaxKey | Ja | VARCHAR |
Object | Ja | virtuelle Tabelle |
Array | Ja | virtueller Tisch |
Decimal128 | Nein | DECIMAL |
JavaScript | Nein | VARCHAR |
JavaScript (mit Umfang) | Nein | VARCHAR |
Undefined | Nein | VARCHAR |
Symbol | Nein | VARCHAR |
DBPointer(4.0+) | Nein | VARCHAR |
Zuordnung skalarer Dokumentfelder
Beim Scannen einer Stichprobe 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 entsprechen:
Tabellenname | Spaltenname | Datentyp | Schlüssel |
---|---|---|---|
Mannschaft | Team-ID | VARCHAR | PK |
Mannschaft | Name | VARCHAR | |
Mannschaft | age | INTEGER |
Förderung von Konflikten beim Datentyp
Beim Scannen der Musterdokumente ist es möglich, dass die Datentypen für ein Feld von Dokument zu Dokument nicht einheitlich sind. In diesem Fall stuft der JDBC Treiber den JDBC Datentyp auf einen gemeinsamen Datentyp herauf, der für alle Datentypen aus den Stichprobendokumenten geeignet ist.
Beispiel:
{ "_id" : "112233", "name" : "Alastair", "age" : 25 } { "_id" : "112244", "name" : "Benjamin", "age" : "32" }
Das Altersfeld ist im ersten Dokument vom Typ 32-Bit-Ganzzahl, im zweiten Dokument vom Typ Zeichenfolge. In diesem Fall JDBC stuft der Treiber den JDBC Datentyp so hoch, VARCHAR dass er einen der beiden Datentypen verarbeiten kann, wenn er darauf trifft.
Tabellenname | Spaltenname | Datentyp | Schlüssel |
---|---|---|---|
Mannschaft | Team-ID | VARCHAR | PK |
Mannschaft | Name | VARCHAR | |
Mannschaft | age | VARCHAR |
Förderung skalar-skalarer Konflikte
Das folgende Diagramm zeigt, wie Konflikte zwischen skalaren und skalaren Datentypen gelöst werden.
![Hierarchy diagram showing data type relationships from Binary Data to various scalar types.](images/jdbc/scalar-scalar-promotion.png)
Förderung von Konflikten vom Typ skalarkomplexer Natur
Wie bei Skalar-Skalar-Typkonflikten kann dasselbe Feld in verschiedenen Dokumenten widersprüchliche Datentypen zwischen komplexen (Array und Objekt) und skalaren Datentypen (Integer, Boolean usw.) aufweisen. All diese Konflikte werden für diese Felder gelöst (heraufgestuft). VARCHAR In diesem Fall werden Array- und Objektdaten als JSON Repräsentation zurückgegeben.
Beispiel für einen Konflikt zwischen eingebettetem Array und Zeichenkettenfeld:
{ "_id":"112233", "name":"George Jackson", "subscriptions":[ "Vogue", "People", "USA Today" ] } { "_id":"112244", "name":"Joan Starr", "subscriptions":1 }
Das obige Beispiel entspricht dem Schema für die Tabelle customer2:
Tabellenname | Spaltenname | Datentyp | Schlüssel |
---|---|---|---|
Kunde2 | Kunde2-ID | VARCHAR | PK |
Kunde2 | Name | VARCHAR | |
Kunde2 | Abonnement | VARCHAR |
und die virtuelle Tabelle customer1_subscriptions:
Tabellenname | Spaltenname | Datentyp | Schlüssel |
---|---|---|---|
customer1_subscriptions | Kunde1-ID | VARCHAR | PK/FK |
customer1_abonnements | subscriptions_index_lvl0 | BIGINT | PK |
customer1_abonnements | Wert | VARCHAR | |
customer_address | city | VARCHAR | |
customer_address | Region | VARCHAR | |
customer_address | country | VARCHAR | |
customer_address | Code | VARCHAR |
Behandlung von Objekt- und Array-Datentypen
Bisher haben wir nur beschrieben, wie skalare Datentypen zugeordnet 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, getrennt durch einen Unterstrich („_“).
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 obige Beispiel ist dem Schema für die Kundentabelle zugeordnet:
Tabellenname | Spaltenname | Datentyp | Schlüssel |
---|---|---|---|
customer | Kunden-ID | VARCHAR | PK |
customer | Name | VARCHAR |
und die virtuelle Tabelle customer_address:
Tabellenname | Spaltenname | Datentyp | Schlüssel |
---|---|---|---|
customer_address | Kunden-ID | VARCHAR | PK/FK |
customer_address | Adresse 1 | 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
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 obige Beispiel ist dem Schema für die Tabelle customer1 zugeordnet:
Tabellenname | Spaltenname | Datentyp | Schlüssel |
---|---|---|---|
Kunde1 | Kunde1-ID | VARCHAR | PK |
Kunde1 | Name | VARCHAR |
und die virtuelle Tabelle customer1_subscriptions:
Tabellenname | Spaltenname | Datentyp | Schlüssel |
---|---|---|---|
customer1_subscriptions | Kunde1-ID | VARCHAR | PK/FK |
customer1_abonnements | subscriptions_index_lvl0 | BIGINT | PK |
customer1_abonnements | Wert | VARCHAR | |
customer_address | city | VARCHAR | |
customer_address | Region | VARCHAR | |
customer_address | country | VARCHAR | |
customer_address | Code | VARCHAR |