Oracle Business Intelligence

Identity/Szekvencia

Microsoft SQL Server alatt az automatikus azonosító generálásra az IDENTITY típusú oszlopok szolgálnak. A típus megadására a CREATE TABLE illetve ALTER TABLE utasításokkal van lehetőség:


ahol a seed a legelső táblába beszúrt értéket, az increment pedig a növekményt jelöli. Az IDENTITY típusú oszlopokhoz kapcsolódnak a @@IDENTITY, IDENT_CURRENT() illetve SCOPE_IDENTITY() függvények. Az IDENT_CURRENT() egy adott táblára mondja meg, hogy mi volt az utolsó IDENTITY érték, a SCOPE_IDENTITY az adott hatáskörben teszi meg ugyanezt, az @@IDENTITY pedig hatáskörtől függetlenül a legutolsó értéket adja vissza. A hatáskör lehet tárolt eljárás, trigger, függvény vagy batch.

Például ha van két tábla IDENTITY mezőkkel, T1 és T2, és a T1-be történő beszúrás hatására lefut egy trigger, ami a T2 táblába szúr be egy sort, akkor az INSERT utáni @@IDENTITY és SCOPE_IDENTITY() más értékeket fog visszaadni: az @@IDENTITY a legutolsó beszúrás eredményét, tehát a T2-be beszúrt identity értéket, a SCOPE_IDENTITY() pedig a T1-be beszúrtat.

Oracle alatt az IDENTITY oszlopok helyett szekvenciák vannak. A szekvenciák önálló séma objektumok, amik automatikusan generálnak egyedi értékeket. Az IDENTITY-hez hasonló működést szekvenciák és triggerek segítségével lehet elérni. Erről Pém Gábor is írt egy bejegyzést a blogjában. Viszont az @@IDENTITY, SCOPE_IDENTITY(), IDENT_CURRENT() függvényekkel ekvivalens nincs Oracle alatt, ezeket a szekvenciákhoz tartozó CURRVAL, NEXTVAL pszeudo-oszlopokkal lehet emulálni.

Az SQL Developer Migration Workbenchje az IDENTITY oszlopokat úgy fordítja át, hogy meggenerálja a hozzájuk tartozó triggereket és szekvenciákat, valamint beállítja az sqlserver_utilities PL/SQL package identity nevű változóját, amivel a @@IDENTITY működését próbálja szimulálni. Ha a T-SQL kódban használjuk a SCOPE_IDENTITY() vagy az IDENT_CURRENT() függvényeket, akkor minden esetben manuálisan kell átírni a logikát PL/SQL-re.

Azonosító nevek, fenntartott kulcsszavak

A kulcsszavak és fenntartott szavak (keywords and reserved words) problémájáról már írtam egy bejegyzést, amit valahogy úgy lehetne összefoglalni, hogy ne használj kulcs- és fenntartott szavakat adatbázis objektumok nevekként.

Ha az ember a nulláról indul egy adatbázis megtervezésekor, akkor természetesen ez az ajánlott út. Viszont ha már van egy kész séma, többszáz táblával, amikre többezer hivatkozás is van, akkor bizony kénytelenek leszünk kompromisszumokat kötni. Egy fontos szabály, amit nem lehet áthágni: azonosító név maximum 30 karakter (30 byte) hosszú lehet (kivéve adatbázis név - 8 byte, adatbázis-link név - 128 byte). Ha van olyan táblánk, oszlopnevünk, T-SQL változónk, függvényünk, stb., ami 30 karakternél hosszabb, akkor azt át kell nevezni (a Migration Workbench egyszerűen levágja a végét, ha névütközés van, akkor sorszámmal látja el az azonos neveket, pl: myverylongtable_1, myverylongtable_2, stb.).

A dokumentáció szerint "-k között szereplő fenntartott szavak lehetnek azonosító nevek, pl.: "DATE", de - mint már írtam - ebből lehetnek még problémák. Feltehetően egy bug miatt ha még SQL Server oldalon átnevezzük a fenntartott szavakat úgy, hogy egy _ postfixet teszünk a végükre, pl.: Type_, akkor a Migration Workbench "visszanevezi" őket, azaz leveszi a postfixünket. Ezt eddig csak a Type-nál vettem észre.

A kívánatos út szerintem az, ha még migráció előtt SQL Server oldalon átnevezünk minden 30-nál hosszabb illetve fenntartott azonosító nevet, illetve az azokra történő hivatkozást. Nagy adatbázis esetén nagy munka, de megkímélhetjük magunkat későbbi kellemetlen meglepetésektől. Például, ha van egy tárolt eljárásunk, ami visszaad valamilyen recordsetet, ahol bizonyos oszlopnevek vagy alias-ok 30 karakternél hosszabbak, akkor a kliens oldalon külön kell kezelni, hogy az eredményt T-SQL eljárás adta-e vissza (30+ hosszú is lehet egy oszlopnév ill. alias), vagy PL/SQL (max 30 karakter) ha szerepelnek a kliens-kódban oszlopnévre történő hivatkozások. Ez nem járható út.

A migrációval kapcsolatos előző bejegyzésben az implicit és explicit konverziókról is írtam pár gondolatot. Azóta észrevettem egy furcsaságot, amit fel is vetettem az OTN fórumban, de azóta nem kaptam rá választ.

Röviden összefoglalva: az SQL Developer SQL Serverről történő migrációkor automatikusan generál egy sqlserver_utilities nevű PL/SQL package-et, ami számos T-SQL függvény implementációját tartalmazza, köztük a CONVERT() függvényét is.

Az 1.5.1-es SQL Developerben a függvény deklarációja így néz ki:


Az első paraméter szöveges módon tartalmazza az adattípust, hogy mire konvertálunk, például 'varchar'. A második paraméter maga a kifejezés, amit konvertálni szeretnénk, az utolsó pedig egy opcionális stílus paraméter, ami a különböző dátum, szám illetve egyéb formátumokat határozza meg, attól függően, hogy a konvertálandó kifejezés milyen típusú.

És itt jön elő az implicit konverzió kérdése, ugyanis ha egy dátum típusú kifejezést szeretnénk yyyy/mm/dd formátumú varchar-á konvertálni, ami T-SQL-ben így néz ki:

declare @mydate datetime
select convert(varchar, @mydate,111)

azt az sqlserver_utilities.convert_() függvény segítségével - elvileg - így tehetnénk meg:

DECLARE
cv_1 SYS_REFCURSOR;
v_mydate DATE;
BEGIN
OPEN cv_1 FOR
SELECT sqlserver_utilities.convert_('VARCHAR2(4000)', v_mydate, 111);

Ebben az esetben viszont a v_mydate először implicit módon varchar-á konvertálódik, méghozzá az alapértelmezett formátumnak megfelelően:

Idén ősszel is lesz ingyenesen látogatható Oracle szeminárium minden csütörtökön 18 órától a BME I. épületében. Az előadás témái:

• Oracle adatbázis-kezelő architektúra
• Fürtözött adatbázis
• Adatbázis üzemeltetés
• Adatreplikáció és katasztrófatűrő adatbázis
• Adatbányászat
• Térinformatika az adatbázisban
• Adatbiztonság
• XML adatok tárolása az adatbázisban
  

Bővebb információ itt. Én már jelentkeztem :)

Jelenleg van egy .NET-es, C#-ban írt alkalmazás (kliens), ami Microsoft SQL Server-t használ adatbázisként. A kliens oldalon szinte kizárólag tárolt eljárás hívások szerepelnek. A cél az, hogy ugyanaz a kliens szoftver képes legyen SQL Server-t is és Oracle Database-t is használni adatbázisként, azaz egy klienshez lenne két külön adatbázis-oldali rész. Ezért a migrációnak csak minimális mértékben kéne visszahatnia a kliens oldali részre. Sajnos ez közel sem olyan egyszerű. Lássuk a problémás területeket!

Adattípusok

Habár az Oracle és az SQL Server által támogatott adattípusok különböznek egymástól, szerencsére az esetek igen nagy százalékában megfeleltethetőek egymásnak. Egy Oracle white paper szerint is: "Microsoft SQL Server and Oracle9i Database data types differ. However these differences are usually small enough to have little or no impact on your applications."

Az SQL Developerbe integrált Migration Workbench (OMWB) a konvertáláskor automatikusan leképezi az SQL Server adattípusokat Oracle adattípusokra. Számunkra lényeges eltérés a (N)VARCHAR típus maximális hosszában van: míg SQL Server alatt maximum 8000 karaktert képes tartalmazni, addig Oracle alatt ez a szám 4000. De szerencsére az OMWB a 4000-nél hosszabb (N)VARCHAR típusokat automatikusan (N)CLOB-okká konvertálja.

Különböznek még a dátum típusok pontosságai: míg SQL Server alatt a DATETIME 3.33 mikroszekundum pontosságú, addig Oracle alatt másodperc pontosságú a DATETIME-nak megfelelő DATE típus. Ahol ez nem elég, ott érdemes a TIMESTAMP típust használni, ami viszont már 1 mikroszekundum pontosságú. Persze kérdés az, hogy az adatbázisunkban kismillió helyen használt DATETIME-ok közül hol elég a másodperces felbontás, és hol nem. Ebből még lehetnek bonyodalmak..

Az adattípusok konvertálásáról bővebben lehet még olvasni az SQL Developer dokumentációjában és a Migrating Applications from Microsoft SQL Server to Oracle9i Database című white paper-ben.

Implicit/explicit konverzió

Az adattípusokhoz erősen kapcsolódó téma a típusok közötti implicit vagy explicit konverziók kérdése.

SQL Server alatt az explicit típuskonverziót a CAST és CONVERT függvények valósítják meg:


A CONVERT függvény SQL Server specifikus, és nagyobb rugalmasságot biztosít dátumok és tört számok konvertálásakor. A CAST pedig inkább ANSI-szerű, ezért többé-kevésbé ugyanolyan szintaxissal lehet használni a különböző adatbázis szerverek alatt.

Implicit konverzió például akkor történik, amikor két különböző típusú adatot hasonlítunk össze, vagy ha egy tábla adott oszlopába szúrunk be egy attól különböző típusú értéket. Az implicit konverzió a felhasználó elől rejtve marad.

SQL Server alatt a lehetséges implicit és explicit típuskonverziók mátrixát az alábbi kép tartalmazza:



Ugyanez az ábra Oracle alatt picit máshogy néz ki, implicit konverziók:



explicit konverziók:



Habár implicit típuskonverzió alkalmazása több okból is helytelen (a kód nehezebben értelmezhető, nem feltétlen optimális az utasítások végrehajtása performancia szempontból, a különböző verziók során változhatnak a konverziós szabályok, stb.) mi mégis több helyen alkalmazzuk, egész egyszerűen azért, mert kényelmes. Például SQL Server a képen látható módon többféle dátumformátumot is képes kezelni:


Kavarodás itt is történhet (ÉV-HÓNAP-NAP, NAP-HÓNAP-ÉV, stb.), de ha az ember ragaszkodik valami megszokott formátumhoz, nem érheti baj. Kivéve, ha a kódot más adatbázis szerver alatt is szeretné használni :)

Oracle alatt az alapértelmezett formátumot az NLS_DATE_FORMAT paraméter tartalmazza, ami az én szerveremen:

SELECT Value FROM v$nls_parameters WHERE parameter = 'NLS_DATE_FORMAT'

VALUE
-----
RR-MON-DD

Azaz a '2008-01-01' például csak explicit módon konvertálható át DATE típusúvá. Ilyen esetekben célszerűbb a TO_DATE függvény használata. A mi esetünkben tehát minden ilyen esetben kézzel át kell írni minden implicit konverziót tartalmazó kódot explicit konverzióvá.

Ideiglenes táblák, táblaváltozók

Ideiglenes táblák SQL Server és Oracle alatt is léteznek, a különbség annyi, hogy míg SQL Server alatt a táblában tárolt adatok és maga a struktúra is ideiglenes, addig Oracle alatt a struktúra (séma) állandó.

A Migration Workbench kiszedi a tárolt eljárások kódjából az ideiglenes táblákat létrehozó DDL utasításokat, és külön hozza létre őket:

/* Translation Extracted DDL For Required Objects */
CREATE GLOBAL TEMPORARY TABLE tt_foo
(
...
);

Az ideiglenes táblákat törlő DROP utasításokból pedig ez lesz:

EXECUTE IMMEDIATE ' TRUNCATE TABLE tt_foo ';

Azaz csak a tartalmát törli a táblának, magát a táblát nem.

Egyelőre úgy tűnik, hogy számunkra ez tökéletesen megfelelő. Egyedül az zavaró, hogy (hanyagságból) rengeteg #temp nevű táblát használunk SQL Server oldalon, és mivel Oracle alatt a séma nem ideiglenes, ezért ahány helyen #temp táblát használunk, annyi darab TT_TEMP_n jön létre Oracle oldalon. Az n jelenleg olyan 30 körüli (TT_TEMP_1, TT_TEMP_2, ... TT_TEMP_30, ..).

Táblaváltozók viszont nincsenek Oracle alatt, ezek kiváltására vagy ideiglenes táblákat, vagy PL/SQL collection-öket kell majd használnunk. Azaz itt is marad a kézi átírás.