XQuery és statikus gépelés

A következőkre vonatkozik:SQL Server

Az SQL Server XQuery egy statikusan beírt nyelv. Ez azt jelzi, hogy típushibákat okoz a lekérdezések fordítása során, ha egy kifejezés olyan értéket ad vissza, amely egy adott függvény vagy operátor által nem elfogadott típussal vagy számossággal rendelkezik. Emellett a statikus típusellenőrzés azt is észleli, hogy egy beírt XML-dokumentum elérési útjának kifejezése helytelenül lett-e begépelve. Az XQuery fordító először a normalizálási fázist alkalmazza, amely hozzáadja az implicit műveleteket, például az atomizálást, majd statikus típusú következtetést és statikus típusellenőrzést végez.

Statikus típus következtetése

A statikus típusú következtetés határozza meg egy kifejezés visszatérési típusát. Ezt a bemeneti paraméterek statikus típusainak és a művelet statikus szemantikájának figyelembe vételével és az eredmény statikus típusának következtetésével határozza meg. Az 1 + 2.3 kifejezés statikus típusa például a következő módon van meghatározva:

• Az 1 statikus típusa xs:egész szám, a 2.3 statikus típusa pedig xs:decimális. A dinamikus szemantika alapján a + művelet statikus szemantikája decimálissá alakítja az egész számot, majd visszaad egy decimális értéket. A következő statikus típus xs:decimálislesz.

A nem beírt XML-példányok esetében speciális típusok jelzik, hogy az adatok nem lettek begépelve. Ezeket az információkat a statikus típusellenőrzés során és bizonyos implicit leadások végrehajtásához használjuk fel.

A beírt adatok esetében a bemeneti típus abból az XML-sémagyűjteményből származik, amely korlátozza az XML-adattípuspéldányt. Ha például a séma csak az xs:egésztípusú elemeket engedélyezi, az adott elemet használó elérésiút-kifejezés eredménye nulla vagy több, xs:egész számtípusú elem lesz. Ez jelenleg egy olyan kifejezéssel van kifejezve, mint például a element(age,xs:integer)*, ahol a csillag (*) az eredményként kapott típus számosságát jelzi. Ebben a példában a kifejezés az "age" név nulla vagy több elemét eredményezheti, és beírhatja xs:egész szám. Az egyéb számosságok pontosan egyek, és csak a típusnév használatával, nullával vagy egyel vannak kifejezve, kérdőjel (?) és 1 vagy több, pluszjel (+) használatával kifejezve.

Néha a statikus típusú következtetés arra következtethet, hogy egy kifejezés mindig az üres sorozatot adja vissza. Ha például egy beírt XML-adattípus elérési útjának kifejezése egy <név> elemet keres egy <ügyfél> elemén (/ügyfél/név) belül, de a séma nem engedélyezi a <név> egy <ügyfél>belül, a statikus típus következtetése arra következtet, hogy az eredmény üres lesz. Ez a helytelen lekérdezések észlelésére szolgál, és statikus hibaként jelenik meg, kivéve, ha a kifejezés () vagy adat( () ).

A részletes következtetési szabályokat az XQuery specifikációjának formális szemantikája tartalmazza. A Microsoft ezeket csak kis mértékben módosította, hogy a gépelt XML-adattípus-példányokkal működjön. A szabvány legfontosabb változása az, hogy az implicit dokumentumcsomópont tud az XML-adattípus-példány típusáról. Ennek eredményeképpen az űrlap /age elérési útkifejezése pontosan ezen információk alapján lesz begépelve.

SQL Server Profiler-sablonok és -engedélyekhasználatával a lekérdezés-fordítások részeként visszaadott statikus típusok láthatók. Ezek megtekintéséhez a nyomkövetésnek tartalmaznia kell az XQuery static type eseményt a TSQL-esemény kategóriájában.

Statikus típus ellenőrzése

A statikus típusellenőrzés biztosítja, hogy a futásidejű végrehajtás csak a művelethez megfelelő típusú értékeket kapja meg. Mivel a típusokat nem kell futásidőben ellenőrizni, a fordítás korai szakaszában lehetséges hibák észlelhetők. Ez segít a teljesítmény javításában. A statikus gépelés azonban megköveteli, hogy a lekérdezésíró körültekintőbb legyen a lekérdezések kialakításában.

Az alábbiakban a megfelelő típusokat használhatja:

• Függvény vagy művelet által kifejezetten engedélyezett típusok.

• Explicit módon engedélyezett típus altípusa.

Az altípusok az XML-séma korlátozásával vagy kiterjesztésével történő származtatás használatára vonatkozó altípus-szabályok alapján vannak definiálva. Az S típus például a T típusú altípus, ha az összes S típusú érték szintén T típusú példány.

Emellett az összes egész szám is decimális érték, az XML-sématípus hierarchiája alapján. Azonban nem minden tizedesérték egész szám. Ezért az egész szám a decimális altípus, de nem fordítva. A + művelet például csak bizonyos típusú értékeket engedélyez, például az xs:egész szám , xs:decimális, xs:lebegőpontosés xs:dupla. Ha más típusú értékek, például xs:sztring, a művelet típushibát okoz. Ezt erős gépelésnek nevezzük. Más típusú értékek, például a nem beírt XML jelzésére használt atomi típus, implicit módon konvertálhatók olyan típusú értékké, amelyet a művelet elfogad. Ezt gyenge gépelésnek nevezzük.

Ha implicit átalakítás után szükséges, a statikus típusellenőrzés garantálja, hogy csak a megfelelő számossággal rendelkező engedélyezett típusok értékei lesznek átadva egy műveletnek. A "string" + 1 esetében felismeri, hogy a "sztring" statikus típusa xs:string. Mivel ez nem engedélyezett típus a + művelethez, a rendszer típushiba lépett fel.

Ha egy tetszőleges E1 kifejezés eredményét egy tetszőleges E2 (E1 + E2) kifejezéshez adja hozzá, a statikus típusú következtetés először az E1 és az E2 statikus típusait határozza meg, majd a művelethez engedélyezett típusokkal ellenőrzi a statikus típusokat. Ha például az E1 statikus típusa lehet xs:sztring vagy xs:egész szám, a statikus típusellenőrzés típushibát jelez, annak ellenére, hogy bizonyos értékek futásidőben egész számok lehetnek. Ugyanez lenne a helyzet, ha az E1 statikus típusa xs:egész szám*lenne. Mivel a + művelet csak egy egész számot fogad el, és az E1 nullát vagy 1-nél többet is visszaadhat, a statikus típusellenőrzés hibát jelez.

Ahogy korábban említettük, a típuskövetkeztetések gyakran olyan típusra következtetnek, amely szélesebb, mint amit a felhasználó tud az átadott adatok típusáról. Ezekben az esetekben a felhasználónak újra kell írnia a lekérdezést. Néhány tipikus eset a következő:

• A típus egy általánosabb típusra, például egy szupertípusra vagy egy típusok egyesítésére következtet. Ha a típus atomtípus, akkor az öntött kifejezés vagy a konstruktor függvény használatával kell jeleznie a tényleges statikus típust. Ha például az E1 kifejezés kikövetkeztetett típusa xs:string vagy xs:egész szám, és a hozzáadáshoz xs:egész számszükséges, akkor E1+E2helyett xs:integer(E1) + E2 kell írnia. Ez a kifejezés futásidőben meghiúsulhat, ha olyan sztringértéket tapasztal, amely nem adható xs:egész szám. A kifejezés azonban most már megfelel a statikus típus ellenőrzésének. Ez a kifejezés az üres sorozatra van leképezve.

• A típus magasabb számosságot mutat, mint amit az adatok ténylegesen tartalmaznak. Ez gyakran fordul elő, mert az xml adattípus több legfelső szintű elemet is tartalmazhat, és egy XML-sémagyűjtemény nem korlátozhatja ezt. Annak érdekében, hogy csökkentse a statikus típust, és garantálja, hogy valóban legfeljebb egy érték van átadva, használja a pozíció predikátumot [1]. Ha például 1-et szeretne hozzáadni az elem c attribútum értékéhez, b a legfelső szintű elem alatt, write (/a/b/@c)[1]+1kell. Emellett a DOCUMENT kulcsszó egy XML-sémagyűjteménysel együtt is használható.

• Egyes műveletek a következtetés során elveszítik a típusadatokat. Ha például egy csomópont típusa nem határozható meg, bármelyTypelesz. Ez nem implicit módon más típusra van adva. Ezek az átalakítások elsősorban a navigáció során történnek a szülőtengely használatával. Kerülje az ilyen műveletek használatát, és írja át a lekérdezést, ha a kifejezés statikus típusú hibát okoz.

Egyesítő típusok típusellenőrzése

Az egyesítő típusok gondos kezelést igényelnek a típusellenőrzés miatt. Az alábbi példák két problémát mutatnak be.

Példa: Függvény uniótípuson keresztül

Vegye figyelembe az egyesítő típusú <r> elemdefinícióját:

<xs:element name="r">  
<xs:simpleType>  
   <xs:union memberTypes="xs:int xs:float xs:double"/>  
</xs:simpleType>  
</xs:element>  

Az XQuery-környezetben az "átlag" függvény fn:avg (//r) statikus hibát ad vissza, mivel az XQuery-fordító nem tud különböző típusú értékeket hozzáadni (xs:int, xs:float vagy xs:double) az <r> elemekhez az fn:avg()argumentumában. Ennek megoldásához írja át újra a függvényhívást fn:avg(for $r in //r return $r cast as xs:double ?).

Példa: Operátor uniótípuson keresztül

Az összeadási művelethez (+) pontos operandustípusokra van szükség. Ennek eredményeképpen a (//r)[1] + 1 kifejezés olyan statikus hibát ad vissza, amely az <r>elemhez korábban leírt típusdefinícióval rendelkezik. Az egyik megoldás a (//r)[1] cast as xs:int? +1átírása, ahol a "?" 0 vagy 1 előfordulást jelez. Az SQL Serverhez "cast as" és "?", mivel a leadások futásidejű hibák miatt okozhatják az üres sorozatot.

Lásd még:

XQuery Language Reference (SQL Server)