XQuery und statische Typisierung
Gilt für: 
SQL Server
XQuery in SQL Server ist eine statisch typierte Sprache. Sie gibt bei der Abfragekompilierung einen Typfehler aus, wenn ein Ausdruck einen Wert zurückliefert, dessen Typ oder Kardinalität von einer bestimmten Funktion oder einem Operator nicht angenommen wird. Darüber hinaus kann eine Überprüfung des statischen Typs auch erkennen, ob ein Pfadausdruck eines typisierten XML-Dokuments falsch typisiert ist. Der XQuery-Compiler realisiert zuerst die Normalisierungsphase, in der die impliziten Vorgänge, wie die Atomisierung, hinzugefügt werden. Anschließend erfolgen die Inferenz und die Überprüfung des statischen Typs.
Inferenz des statischen Typs
Die Inferenz des statischen Typs ermittelt den Rückgabetyp eines Ausdrucks. Hierbei wird aus den statischen Typen der Eingabeparameter und aus der statischen Semantik des Vorgangs der statische Typ des Ergebnisses abgeleitet. Beispiel: Der statische Typ des Ausdrucks 1 + 2,3 wird wie folgt abgeleitet:
- Der statische Typ von 1 ist xs:integer , und der statische Typ von 2,3 ist xs:decimal. Basierend auf der dynamischen Semantik konvertiert die statische Semantik des + Vorgangs die ganze Zahl in eine Dezimalzahl und gibt dann eine Dezimalzahl zurück. Der abgeleitete statische Typ wäre dann "xs:decimal".
Für nicht typisierte XML-Instanzen gibt es spezielle Typen, mit deren Hilfe angegeben wird, dass die Daten nicht typisiert sind. Diese Information wird bei der Überprüfung des statischen Typs und zur Durchführung bestimmter impliziter Datentypkonvertierungen verwendet.
Bei typisierten Daten wird der Eingabetyp aus der XML-Schemaauflistung abgeleitet, die die XML-Datentypinstanz einschränkt. Wenn das Schema beispielsweise nur Elemente vom Typ "xs:integer" zulässt, sind die Ergebnisse eines Pfadausdrucks mit diesem Element null oder mehr Elemente vom Typ "xs:integer". Dies wird derzeit mithilfe eines Ausdrucks ausgedrückt, z element(age,xs:integer)* . B. wo das Sternchen (*) die Kardinalität des resultierenden Typs angibt. In diesem Beispiel kann der Ausdruck zu null oder mehr Elementen mit dem Namen "age" und dem Typ "xs:integer" führen. Andere Kardinalitäten sind genau eins und werden mit dem Typnamen allein, null oder eins ausgedrückt und mit einem Fragezeichen (?) und 1 oder mehr ausgedrückt und mit einem Pluszeichen (+) ausgedrückt.
In manchen Fällen kann die Inferenz des statischen Typs ableiten, dass ein Ausdruck immer eine leere Zeichenfolge zurückliefert. Wenn z. B. ein Pfadausdruck für einen typierten XML-Datentyp nach einem <Namenselement> innerhalb eines <Kundenelements (/customer>/name) sucht, aber das Schema keinen Namen> innerhalb eines <Kunden> zulässt<, leitet die statische Typausleitung darauf ab, dass das Ergebnis leer ist. Dies wird verwendet, um falsche Abfragen zu erkennen und wird als statischer Fehler gemeldet, es sei denn, der Ausdruck war () oder daten( () ).
Die detaillierten Inferenzregeln werden in der formalen Semantik der XQuery-Spezifikation angegeben. Microsoft hat diese nur geringfügig für typisierte XML-Datentypinstanzen angepasst. Die wichtigste Änderung zum Standard besteht darin, dass der implizite Dokumentknoten den Typ der XML-Datentypinstanz kennt. Aus diesem Grund wird ein Pfadausdruck der Form /age auf der Grundlage dieser Information exakt typisiert.
Mithilfe von SQL Server-Profilervorlagen und -Berechtigungen können Sie die statischen Typen sehen, die als Teil der Abfragekompilierungen zurückgegeben werden. Dazu muss die Ablaufverfolgung das XQuery Static Type-Ereignis in der TSQL-Ereigniskategorie aufweisen.
Überprüfung des statischen Typs
Die Überprüfung des statischen Typs stellt sicher, dass bei der Ausführung zur Laufzeit nur Werte des für den Vorgang passenden Typs empfangen werden. Da die Typen nicht zur Laufzeit geprüft werden müssen, können potenzielle Fehler zu einem frühen Zeitpunkt der Kompilierung festgestellt werden. Dies verbessert die Leistung. Die statische Typisierung setzt jedoch voraus, dass der Verfasser der Abfrage diese sorgfältiger formuliert.
Folgende Typen können verwendet werden:
Typen, die durch eine Funktion oder einen Vorgang explizit zugelassen werden.
Ein Untertyp eines explizit zugelassenen Typs.
Untertypen werden auf der Grundlage der Untertypisierungsregeln definiert, um Ableitungen durch Beschränkung oder Erweiterung des XML-Schemas zu verwenden. Ein Typ S ist beispielsweise ein Untertyp von T, wenn alle Werte, die den Typ S besitzen, auch Instanzen des Typs T sind.
Darüber hinaus sind alle Ganzzahlwerte auf der Grundlage der Typhierarchie des XML-Schemas auch Dezimalwerte. Nicht alle Dezimalwerte sind allerdings ganze Zahlen. Aus diesem Grund ist eine ganze Zahl ein Untertyp einer Dezimalzahl, aber nicht umgekehrt. Der Vorgang lässt beispielsweise + nur Werte bestimmter Typen zu, z. B. die numerischen Typen "xs:integer", "xs:dezimal", "xs:float" und "xs:double". Wenn Werte anderer Typen, z . B. xs:string, übergeben werden, löst der Vorgang einen Typfehler aus. Dies wird als strenge Typisierung bezeichnet. Werte anderer Typen, wie der Typ atomic, der untypisiertes XML kennzeichnet, können implizit in einen Wert eines Typs konvertiert werden, den die Operation zulässt. Dies wird als schwache Typisierung bezeichnet.
Wenn eine implizite Konvertierung notwendig ist, stellt eine anschließende Überprüfung des statischen Typs sicher, dass an eine Operation nur Werte des zugelassenen Typs mit der richtigen Kardinalität übergeben werden. Bei "string" + 1 wird erkannt, dass der statische Typ von "string" xs:string ist. Da dies kein zulässiger Typ für den + Vorgang ist, wird ein Typfehler ausgelöst.
Wenn das Ergebnis eines beliebigen Ausdrucks E1 zu einem beliebigen Ausdruck E2 addiert wird (E1 + E2), bestimmt die Inferenz des statischen Typs zuerst die statischen Typen von E1 und E2 und prüft diese dann gegen die für den Vorgang zulässigen statischen Typen. Wenn beispielsweise der statische Typ von E1 entweder ein xs:string - oder ein xs:integer-Wert sein kann, löst die Überprüfung des statischen Typs einen Typfehler aus, auch wenn einige Werte zur Laufzeit ganze Zahlen sein können. Das gleiche wäre der Fall, wenn der statische Typ von E1 xs:integer*wäre. Da der + Vorgang nur genau einen ganzzahligen Wert akzeptiert und E1 null oder mehr als 1 zurückgeben konnte, löst die Überprüfung des statischen Typs einen Fehler aus.
Wie zuvor erwähnt, ermittelt die Typinferenz häufig einen Typ, der breiter angelegt ist, als dies dem Benutzer hinsichtlich des zu übergebenden Datentyps bekannt ist. In diesen Fällen muss der Benutzer die Abfrage neu schreiben. Einige typische Fälle umfassen Folgendes:
Der Typ folgert einen allgemeineren Typ, wie einen Untertyp oder eine Typvereinigung. Wenn der Typ atomic ist, müssen Sie den Datentypkonvertierungsausdruck oder die Konstruktorfunktion verwenden, um den tatsächlichen statischen Typ anzugeben. Wenn beispielsweise der abgeleitete Typ des Ausdrucks E1 eine Wahl zwischen xs:string oder xs:integer ist und das Hinzufügen xs:integer erfordert, sollten Sie anstelle
xs:integer(E1) + E2vonE1+E2. Dieser Ausdruck kann zur Laufzeit fehlschlagen, wenn ein Zeichenfolgenwert gefunden wird, der nicht in "xs:integer" umgewandelt werden kann. Der Ausdruck wird jetzt jedoch die Überprüfung des statischen Typs durchlaufen. Dieser Ausdruck wird der leeren Sequenz zugeordnet.Aus dem Typ wird eine höhere Kardinalität abgeleitet, als die tatsächlich in den Daten enthaltene. Dies tritt häufig auf, da der XML-Datentyp mehr als ein Element der obersten Ebene enthalten kann und eine XML-Schemaauflistung dies nicht einschränken kann. Um den statischen Typ zu reduzieren und sicherzustellen, dass stattdessen maximal ein Wert übergeben wird, müssen Sie das Positionsprädikat
[1]verwenden. Beispiel: Um 1 zum Wert des Attributscdes Elementsbunter dem Element der obersten Ebene zu addieren, müssen Siewrite (/a/b/@c)[1]+1angeben. Zusätzlich können Sie mit einer XML-Schemaauflistung das Schlüsselwort DOCUMENT verwenden.Bei einigen Vorgängen geht bei der Inferenz die Typinformation verloren. Wenn beispielsweise der Typ eines Knotens nicht bestimmt werden kann, wird er zu anyType. Dieser wird nicht implizit in irgendeinen anderen Typ umgewandelt. Das tritt am deutlichsten während der Navigation mithilfe der übergeordneten Achse auf. Sie sollten die Verwendung solcher Vorgänge vermeiden und die Abfrage neu schreiben, falls der Ausdruck einen statischen Typfehler erzeugt.
Typüberprüfung von Union-Typen
Union-Typen erfordern aufgrund der Typüberprüfung eine sorgfältige Handhabung. In den folgenden Beispielen sind zwei der Probleme dargestellt.
Beispiel: Funktion für Union-Typ
Betrachten Sie eine Elementdefinition für <r> einen Union-Typ:
<xs:element name="r">
<xs:simpleType>
<xs:union memberTypes="xs:int xs:float xs:double"/>
</xs:simpleType>
</xs:element>
Innerhalb des XQuery-Kontexts gibt die Funktion fn:avg (//r) "mittelwert" einen statischen Fehler zurück, da der XQuery-Compiler keine Werte verschiedener Typen (xs:int, xs:float oder xs:double) für die <>rElemente im Argument "fn:avg()" hinzufügen kann. Um dieses Problem zu beheben, müssen Sie den Funktionsaufruf als fn:avg(for $r in //r return $r cast as xs:double ?) umschreiben.
Beispiel: Operator für Union-Typ
Die Additionsoperation ('+') erfordert präzise Typen der Operanden. Daher gibt der Ausdruck (//r)[1] + 1 einen statischen Fehler zurück, der die zuvor beschriebene Typdefinition für das Element <r>aufweist. Eine mögliche Lösung besteht im Umschreiben des Ausdrucks als as (//r)[1] cast as xs:int? +1, wobei das "?" das Auftreten von 0 oder 1 anzeigt. SQL Server erfordert "Cast as" mit "?", da jede Umwandlung die leere Sequenz als Folge von Laufzeitfehlern verursachen kann.