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.

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.

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