Von JDBC Mediator generierte Abfrage
Wenn Sie keine SQL-Anweisung SELECT angeben, generiert der DMS (Data Mediator Service) diese Abfrage unter Verwendung der bei der Instanzerstellung bereitgestellten Metadaten.
Die interne Abfrageengine konstruiert eine Abfrage anhand von Angaben zu Tabellen, Spalten, Beziehungen, Filtern und OrderBy-Objekten, die in den Metadaten enthalten sind. Wie bei den bereitgestellten Abfragen werden UPDATE-, DELETE- und INSERT-Anweisungen automatisch für jedes DataObject generiert, wenn der Mediator die Änderungen am DataGraph in der Datenbank festschreibt.
Filter
Filter definieren eine SQL-Klausel WHERE, die Parametermarken enthalten kann. Diese werden zur WHERE-Klausel der SELECT-Anweisung im DataGraph hinzugefügt. Filter werden so verwendet, wie sie sind. Sie werden nicht syntaktisch analysiert oder in irgendeiner Form interpretiert. Es gibt somit auch keine Fehlerprüfung. Die Verwendung eines falschen Namens oder Prädikats bzw. einer falschen Funktion wird nicht erkannt. Eine so generierte Abfrage ist ungültig. Wenn eine Filterklausel WHERE Parametermarken enthält, werden der Parametername und -typ mit Filterargumenten definiert. Vor dem Abrufen des Diagramms werden diese Parameter mit Parameter-DataObjects gefüllt. Nachfolgend sehen Sie ein Beispiel für die Filter und Parameter-DataObjects für generierte Abfragen.
Parameter-DataObjects für generierte Abfragen
// Die Factory ist ein MetadataFactory-Objekt.
Filter filter = factory.createFilter();
filter.setPredicate("CUSTSTATE = ? AND CUSTZIP = ?");
FilterArgument arg0 = factory.createFilterArgument();
arg0.setName("customerState");
arg0.setType(Column.String);
queryInfo.getFilterArguments().add(arg0);
FilterArgument arg1 = factory.createFilterArgument();
arg1.setName("customerZipCode");
arg1.setType(Column.Integer);
queryInfo.getFilterArguments().add(arg1);
// custTable ist das Customer-Tabellenobjekt
custTable.setFilter(filter);
..... // Mediator konfigurieren
DataObject parameters = mediator.getParameterDataObject();
// Der erste Parameter ist der Name, der dem Argument
// vom FilterArgument zugeordnet wird.
parameter.setString("customerState", "NY");
parameter.setInt("customerZipCode", 12345);
DataObject graph = mediator.getGraph(parameters);
Order-by
// Bei diesem Beispiel wird vorausgesetzt, dass die Tabelle
// custTable in den Metadaten und das MetaDataFactory-
// Objekt factory bereits erstellt wurden.
Column firstName = ((TableImpl)custTable).getColumn("CUSTFIRSTNAME");
OrderBy orderBy = factory.createOrderBy();
orderBy.setColumn(firstName);
orderBy.setAscending(true);
metadata.getOrderBys().add(orderBy);
Externe Tabellen
Eine externe Tabelle ist eine in den Metadaten definierte Tabelle, die in dem vom JDBC DMS zurückgegebenen DataGraph nicht erforderlich ist. Eine solche Tabelle kann geeignet sein, wenn Sie die Ergebnisliste ausgehend von Daten einer Tabelle filtern möchten, die Daten dieser Tabelle jedoch nicht in der Ergebnisliste enthalten sein müssen. In einem Beispiel mit der Beziehung zwischen Kunden (Customers) und Bestellungen (Orders) könnten Sie die Ergebnisse so filtern, dass alle Kunden zurückgegeben werden, die am ersten des Monats Waren bestellt haben. In diesem Fall sollen keine Bestellinformationen zurückgegeben werden. Die Bestellinformationen müssen jedoch gefiltert werden. Wenn die Tabelle der Bestellungen (Orders) eine externe Tabelle ist, werden die Bestellinformationen nicht in den DataGraph aufgenommen, so dass sich die Größe des DataGraph verringert und die Effizienz steigt. Um eine Tabelle zu einer externen Tabelle zu machen, müssen Sie von einem Tabellenobjekt in den JDBC-DMS-Metadaten die Methode "setExternal(true)" aufrufen. Falls der Client versucht, vom DataGraph aus auf eine externe Tabelle zuzugreifen, tritt eine Ausnahme wegen eines unzulässigen Arguments ein.
Allgemeine Bedingungen für generierte Abfragen
Für das Verständnis der Einschränkungen des Features für Abfragegenerierung im JDBC DMS sind zwei Dinge von Bedeutung. Zunächst ist zu beachten, dass mit dem DataGraph das Modell eines gerichteten zusammenhängenden Diagramms ohne Zyklen (d. h. ein Baumstrukturdiagramm) in das Modell eines ungerichteten und potenziell unzusammenhängenden Diagramms mit Zyklen eingeführt wird. Gerichtet bedeutet hier, dass der Entwickler durch Auswahl einer Stammtabelle die Ausrichtung des Diagramms vorgibt. Zusammenhängend bedeutet, dass alle Tabellen, die Member des DataGraph sind, von der Ausgangsebene aus erreichbar sind. Alle von der Ausgangsebene nicht erreichbaren Tabellen können nicht in den DataGraph aufgenommen werden. Wenn eine Tabelle von der Ausgangsebene erreichbar sein soll, muss für jedes Tabellenpaar im DataGraph eine Fremdschlüsselbeziehung definiert sein. Ohne Zyklen bedeutet, dass es für ein Tabellenpaar im DataGraph nur eine Fremdschlüsselbeziehung gibt. Die Baumstruktur des DataGraph bestimmt, wie Abfragen erstellt werden und welche Daten eine Abfrage zurückgibt.
- Der JDBC DMS erstellt eine Ergebnisliste (d. h. einen DataGraph). Dies geschieht unabhängig davon, ob der DataGraph aus einer Tabelle oder mehreren Tabellen erstellt wird.
- Jeder Pfad durch die Fremdschlüsselbeziehungen in den DMS-Metadaten, vom Stammverzeichnis zu den einzelnen Blattknoten, ist ein gesonderter Pfad. Die Daten für diesen Pfad werden mit Verknüpfungen der Fremdschlüssel abgerufen, die zwischen den Tabellen im Pfad definiert sind. Die Verknüpfungen sind standardmäßig innere Verknüpfungen.
- Alle Pfade in einem DataGraph werden als unabhängig voneinander betrachtet und müssen daher miteinander verbunden werden, um durch die vom Mediator generierte Abfrage eine Ergebnisliste erstellen zu können.
- Als Erstes werden alle benutzerdefinierten Filter auf die Tabellen angewendet. Anschließend wird das Ergebnis mit dem Rest des Pfades verknüpft.
- Relationale Datenbanken erfordern generell, dass OrderBy-Objekte auf die gesamte Ergebnisliste und nicht auf temporäre Ergebnisse angewendet werden.