Oracle Business Intelligence

Mérnök lettem

2009-06-18T14:48:00.004+02:00

Ma megvolt a diploma védése, melynek során mérnökké nyilvánítottak. Juppi!

Diplomamunkám ezen a címen érhető el, a bizottság ötösre értékelte az elvégzett munkám, és így végeredményben a diplomám minősítése négyes lett. A védésen tartott prezentációm diái itt vannak.

Fordító

2009-05-24T17:57:00.003+02:00

Rövid bejegyzés lesz, mostanában picit kevés a szabadidőm (diplomamunka, záróvizsgák):

Fordító programom

A fenti linken pár screenshot látható a diplomamunka keretében implementált T-SQL - PL/SQL fordítóról. Amolyan proof-of-concept munka, ANTLR+StringTemplate segítségével. Ha leadtam a leadni valókat és befejeztem a befejezni valókat, majd írok egy összefoglalást, hogy mennyire fényjézus ez az ANTLR.

Tranzakciókezelés és zárolás SQL Server és Oracle alatt

2009-04-23T15:07:00.003+02:00

Az SQL Server és az Oracle adatbáziskezelő tranzakció kezelése különbözik egymástól.

Arról már írtam egy korábbi bejegyzésben, hogy egy tranzakció SQL Server alatt (alapértelmezetten) explicit, azaz begin transaction … commit/rollback transaction utasítások jelölik az elejét illetve a végét, míg Oracle alatt az első végrehajtható SQL utasításkor kezdődik, és commit/rollback (vagy hiba, disconnect) hatására ér véget. Viszont nem ez az egyedüli különbség, a két rendszer a zárakat is eltérően kezeli.

Az SQL Server a SELECT utasítás hatására egy shared zárat helyez a táblára, míg az Oracle semmilyet se. Gondoljuk végig, hogy ez mit jelent: egy SELECT tehát csak akkor tud lefutni SQL Server alatt, ha rá tud tenni egy shared zárat, azaz a táblán maximum shared zár van jelenleg (nincs exclusive lock). Ennek következtében a SELECT és az UPDATE utasítások fizikailag szerializáltan hajtódnak végre.

Ezzel szemben Oracle alatt egy SELECT utasítást nem blokkolja semmi, és egy SELECT utasítás nem blokkol senkit (FOR UPDATE klauzula nélkül).

Képzeljünk el egy olyan T-SQL tárolt eljárást, ami kiolvassa egy számla egyenlegét egy változóba, elszöszmötöl egy darabig, majd – ha van elég pénz az egyenlegen – csökkenti azt. Ennek az eljárásnak a kódja valahogy így nézhet ki:


declare @balance money
begin transaction
 select @balance = balance from tran_balance where userid=20
 -- some very serious calculation..
 if @balance > 1500
     update tran_balance set balance=balance-1500 where userid=20
commit transaction

Mi itt a hiba? Ez a kód bizonyos időzítés mellett helyesen működik SQL Server alatt, Oracle alatt viszont (alapértelmezett izolációs szinten) szinte sehogy se.
Tegyük fel, hogy az alábbi ábrán látható módon indul el két tranzakció.

SQL Server alatt az alábbi lépések fognak történni:

A SELECT kirak egy shared lock-ot a táblára
Az UPDATE kirak egy exclusive lock-ot a táblára
Indulna a 2. tranzakció, de a SELECT nem tud shared lock-ot kirakni, mert a másik tranzakció exclusive lock-ja még érvényben van
Az első tranzakció lefut, végrehajtódik a COMMIT utasítás
Elindul a 2. tranzakcióban levő SELECT utasítás is, és az első tranzakció által véglegesített értéket olvassa ki.

Ha az időzítésen variálunk egy picit, pl: feljebb „toljuk” a 2. tranzakció SELECT-jét az első tranzakció SELECT és UPDATE utasítása közé, akkor SQL Server-en is „nem várt” működést tapasztalhatunk (akkor nem várt, ha nem tudjuk, hogy működik :)):

lefut az első SELECT
lefut a második tranzakció SELECT-je is, a shared lock miatt (a shared lock-ok egymással kompatibilisek)
lefut az első UPDATE
a második UPDATE blokkolódik, egészen addig, amíg az első tranzakció nem fejeződik be.

Mi a helyzet Oracle alatt? A SELECT utasítás mindkét (bármilyen) esetben le fog futni, kiolvasva az utolsó elcommitált értéket. A fenti példakód esetében tehát a konkurens tranzakciók lehet, hogy úgy terhelik be az egyenleget, hogy már nincs is rajta fedezet. Azaz, ha „ész nélkül” (automatikusan) fordítjuk át T-SQL kódjainkat PL/SQL-re, akkor a fenti „kicsit” rossz kódból nagyon rossz kódot kapunk.

Ebben a példában két lehetőség van a javításra, Oracle oldalon. Az egyik a SERIALIZABLE izolációs szint használata: ezen a szinten levő tranzakciók ha egy olyan táblát szeretnének módosítani, amit egy másik – még el nem commitált – tranzakció már módosított, akkor hibát kapunk:

Hiba a(z) 1. sorban:
ORA-08177: ehhez a tranzakcióhoz nem lehet sorbarendezni a hozzáférést
ORA-06512: a(z) helyen a(z) 6. sornál

A másik megoldás a LOCK TABLE használata: még mielőtt bármit is olvasnánk a táblából, rárakunk egy zárat. Ezzel elérhetjük az SQL Server-éhez hasonló működést, azzal a különbséggel, hogy nem a SELECT utasítás fog blokkolódni, hanem az előtte lévő LOCK TABLE.

HOUG 2009

2009-04-20T08:16:00.003+02:00

Idén először vettem részt a Magyarországi Oracle Felhasználók Konferenciáján, melyet április 6-9. között a siófoki Hotel Azúrban tartottak.

Én szerda reggel érkeztem meg, kiváncsian vártam Kardkovács Zsolt és Éberhardt Péter előadását a Közel valós idejű, adaptív műsorajánló digitális televíziózáshoz címmel, amikor is a terem előtt hallottam, hogy sajnos elmarad. Helyettük Sárecz Lajos (akinek a jóvoltából vehettem részt a konferencián) tartott előadást Real Application Testing témában.

A szerdai nap további részét főleg az Üzleti intelligencia és az Adatbiztonság szekciók előadásain töltöttem, illetve befurakodtam Czinkóczki László - szokásosan - teltház előtt tartott SQL érdekességek, újdonságok előadására.

Az előadásokat egy számomra rendkívül érdekes panelbeszélgetés zárta szintén adatbiztonság témában, ahol a meghívott vendégek Kirner Attila (PSZÁF), Jakab Péter (MKB Zrt.), Dr. Suba Ferenc (Magyar Kormány Informatikai Biztonsági Incidenskezelő Központ), Antal Lajos (PwC Kft.), Bártfai Attila (kancellár.hu Zrt.), Keleti Arthur (KFKI Zrt.) voltak.

A beszélgetésről talán mindent elmond az, hogy az első kérdés megválaszolása, kivesézése 50 percig tartott.

Az esti vacsorát látványos zenés programok, sör, beszélgetések színesítették, majd egy csocsó-"bajnokság" :)

A csütörtöki nap számomra továbbra is BI + SQL/PLSQL témában telt, az adatbiztonság helyét Tóth Balázs kiváló Change Management a 11g Oracle adatbázisban előadása vette át.

Én hasznosnak éreztem a konferenciát, csak néha tényleg a bőség zavarával kűzködtem: túl sok jó előadás volt :)

Oracle 4 prezident :)

2009-04-19T14:03:00.003+02:00

A Világgazdaság Online arról számol be, hogy felmerült Füzes Péter, az Oracle Hungary ügyvezető igazgatójának neve lehetséges gazdasági miniszterként.

Ennek alátámasztására azt írják, hogy a szakember együtt sportol Bajnai Gordon miniszterelnökkel. :)

PLS-00990 és PLS-00989

2009-04-02T12:59:00.003+02:00

Ez a két hibaüzenet kissé elkeserített, ugyanakkor megmagyarázza számomra, hogy az SQL Developer Migration Workbench miért több kurzor változó segítségével oldja meg az eredményhalmazok visszaadását a tárolt eljárásokból, és miért nem egy kurzor változókat tartalmazó tömb segítségével.

A válasz egyszerű: mert nem lehet kurzor változókat tartalmazó tömböt készíteni:

PLS-00990: Index Tables of Cursor Variables are disallowed
PLS-00989: Cursor Variable in record, object, or collection is not supported by this release

A "this release" pedig az Oracle Database 11g Enterprise Edition Release 11.1.0.6.0. Pedig milyen jó ötletnek tűnt.. :)

Oracle Junior Professional Program

2009-03-31T08:13:00.002+02:00

Tegnap éjszaka megérkezett a tájékoztató e-mail, miszerint:

Örömmel értesítünk, hogy az előző félévben tett sikeres vizsgád eredményéül feltöltheted adataidat abba az adatbázisba, amelyből partnereink kiválasztják azokat, akiknek munkaszerződést ajánlanak és így részt vehetnek az intenzív nyári képzésen.

Végülis, ahhoz képest, hogy legkésőbb január végére ígérték a tájékoztatást, nem is olyan rossz.. :)

Kicsit deja vu érzésem van, tavaly is voltam vizsgázni, tavaly is volt ilyen nyári program, tavaly is mehettem volna, de végül nem tettem, maradtam annál a cégnél, ahol már 2007 óta dolgozok, idén márciustól már teljes állásban.

Hogy idén mi lesz, még nem tudom, viszont mivel június 8. a jelentkezési határidő, ezért még bőven van időm eldönteni. Majd meglátjuk.

Formális nyelvek és az ANTLR

2009-03-29T16:53:00.003+02:00

A nyelv formális definíciója

Jelölje ∑ a nyelv karakterkészletének véges halmazát. Ezt a halmazt nevezzük a nyelv alfabetájának.

Legyen ∑* a ∑ alfabetából alkotott véges, de nem korlátos hosszúságú jelsorozatok halmaza. Nem üres ∑ halmaz esetén ∑* halmaz megszámlálhatóan végtelen számosságú.

Egy adott alfabetából képezhető összes lehetséges jelsorozatba beletartozik az üres jelsorozat, az ε is.

Valamely - egy adott ∑ alfabeta felett értelmezett - L nyelv a ∑* halmaz egy tetszőleges részhalmaza.

Fordítók

Egy fordító általánosságban nem más, mint egy olyan program, ami valamilyen bemeneti jelsorozatra valamilyen kimeneti jelsorozattal válaszol. Bemeneti jelsorozat alatt nem akármilyen karaktereket, hanem a nyelv karakterkészletébe, alfabetájába tartozó karaktereket értünk. A bemeneti jelsorozatokat szokás még mondatoknak nevezni. Tehát a fordító egy L nyelvbe tartozó s mondatot valamilyen t mondatra képez le.

A nyelveket formálisan nyelvtanok segítségével írhatjuk le. Nyelvtanok segítségével a nyelv mondatai levezethetőek, generálhatóak. A gyakorlatban a nyelvtanokat mégis arra használjuk, hogy eldöntsük, egy mondat eleme-e az adott nyelvnek.

A nyelvtanokat egy négyes határozza meg:

G = (N, ∑, P, S)

ahol N a nyelvtani szimbólumok véges halmaza, ∑ a nyelv alfabetája, P a levezetési, vagy másnéven helyettesítési szabályok összessége, S pedig a mondatszimbólum.

Chomsky-féle nyelvosztályok

A nyelvtanokat meghatározó helyettesítési szabályok (vagy másnéven levezetési szabályok) bonyolultsága alapján Chomsky a nyelveket osztályokba sorolta.

3-as nyelvosztály

A 3-as nyelvosztály nyelvtanaiban csak kétféle levezetési szabálytípus engedélyezett:

A → a illetve A → aB

ahol a nemterminális szimbólumokat nagy, a terminális szimbólumokat kis betűvel jelöljük.

Az ilyen alakú nyelvtanokat reguláris (jobbreguláris) nyelvtanoknak nevezzük. Ezek a nyelvtanok generálják a reguláris nyelveket.

2-es nyelvosztály

A 2-es nyelvosztály helyettesítési szabályainak alakja:

A → α

ahol α tetszőleges terminális és nemterminális szimbólumokat tartalmazható jelsorozat. Az ilyen alakú szabályokat úgy lehet értelmezni, hogy az A nemterminális szimbólum a környezetétől függetlenül bármikor helyettesíthető az α jelsorozattal. Ezért ezen nyelvosztály nyelveit környezetfüggetlen, Context Free (CF) nyelveknek nevezik.

1-es nyelvosztály

Az 1-es nyelvosztály helyettesítési szabályainak alakja:

βAγ → βαγ

azaz a A → α szabály csakis a β-γ környezetben alkalmazható. Ezért ezeket a nyelveket környezetfüggő, Context Sensitive (CS) nyelveknek nevezik.

0-ás nyelvosztály

A 0-ás nyelvosztályban alkalmazható szabályokra nézve nincsen korlátozás.

ANTLR nyelvtanok

Az ANTLR számára megadhatunk nyelvtanokat, amik nem mások, mint szabályok halmazai. Ezekből a szabályokból az ANTLR egy rekurzív-leszálló (recursive-descent) elemzőt készít, ami az adott nyelv mondatait ismeri fel, azaz eldönti, hogy az adott mondat eleme-e a nyelvnek, a mondat követi-e a nyelvnek a nyelvtanban leírt szabályait.

Például, az ANTLR jelölésrendszerét használva (ami nem más, mint az EBNF (Extended Backus-Naur Form) jelölésrendszer) egy C-szerű nyelv változódeklarációit leíró nyelvtan egy részlete így nézhet ki:


variableDef
 : declaration SEMICOLON
 | declaration EQUALS expr SEMICOLON
 ;

ahol a ':' előtt álló rész egy nemterminális szimbólum, az utáni rész pedig nemterminális (kis kezdőbetűvel kezdődő) és terminális (nagy kezdőbetűvel kezdődő) szimbólumok halmaza. Ez a levezetési szabály két alternatívát tartalmaz: egy sima változó deklaráció, vagy deklaráció inicializációval. Az alternatívákat a '|' szimbólum választja el.

Használva az előzőleg bevezetett formális jelölést, a fenti nyelvtan így néz ki:

N: variableDef, declaration, expr
∑: SEMICOLON (';'), EQUALS ('='), illetve egyéb, a fenti szabályban fel nem sorolt karakterek
P: a szabályok halmaza
S: a mondatszimbólum, ahonnan indul a levezetés. ANTLR-ben bármelyik nemterminális szimbólum lehet mondatszimbólum.

Az EBNF jelölésrendszer CF nyelvtanok leírását teszi lehetővé. Sajnos több nyelv nem illeszkedik a CF nyelvosztályba, egy adott kifejezés szintaktikai értelmezéséhez szükséges a kontextus ismerete. Például, C++ nyelvben a T(i) kifejezés kétféleképpen is értelmezhető: lehet függvényhívás, vagy típuskonverzió is, attól függően, hogy T függvény-e, vagy egy típus.

Az ANTLR az ehhez hasonló problémákat úgynevezett predikátumok használatával oldja meg: szemantikus és szintaktikus predikátumokkal.

A szemantikus predikátumok szemantikus megszorításokat fejeznek ki. Három esetet különböztethetünk meg. Az első az ellenőrző (validating) szemantikus predikátumok esete, melyek logikai kifejezések, amik kiértékelése futásidőben történik. Ha a kifejezés hamis, akkor az adott szabály használata meghiúsul (az elemző kivételt dob). A szintaxis a következő: {*kifejezés*}?

Például, ha maximum 4 számból álló sorozatot akarunk értelmezni, használhatjuk az alábbi szabályt:


data: ( b+=BYTE )+ {$b.size()<=4}? 
 ;

ahol egy $b nevű listát építünk a BYTE terminális szimbólumokból, egészen addig, amíg a lista mérete kisebb vagy egyenlő mint 4.

A második eset a "kapcsoló" (gated) szemantikus predikátumok használata, amik egy szabályon belül egy alternatíva használatát kapcsolják ki-be. Ezek szintén logikai kifejezések, melyek kiértékelése futásidőben történik. Ha a kifejezés hamis, akkor az adott alternatíva az elemző számára láthatatlan. Ennek használatára remek példa lehet az SQL nyelv, ahol különböző utasításokkal lehet ki vagy bekapcsolni a nyelv egy adott kiegészítését. Ennek szintaxisa {*kifejezés*}?=>

A "maximum 4 elem illesztése" megszorítást kapcsoló predikátumokkal is megoldhatjuk:


data
@init {int n=1;}
 : ( {n<=4}?=> BYTE {n++;} )+
 ;

ahol az @init részben deklarálunk egy n nevű lokális változót deklarálunk. A BYTE alternatíva csak akkor látszódik, ha a kifejezés (n<=4) értéke igaz.

Az utolsó pedig a többértelműséget feloldó szemantikus predikátumok esete. A szintaxis megegyezik az ellenőrző predikátumok szintaxisával. A működésük is igen hasonló. A különbség mindösszesen annyi, hogy a többértelműséget feloldó predikátumok csak akkor jutnak szerephez, ha a szintaxis maga nem egyértelmű.

Az ANTLR által generált LL(*) elemző (az LL(k) elemzők kiegészítése tetszőleges k értékkel) az alternatívák között egy véges automata (DFA) segítségével dönt. A többértelműséget feloldó predikátumok segítik a véges automatát a helyes döntés meghozatalában.

Felhasznált irodalom:

Bach Iván: Formális nyelvek (Typotex Kiadó, 2001)
Terence Parr: The Definitive ANTLR Reference: Building Domain-Specific Languages (Pragmatic Bookshelf, 2007)

ANTLR + StringTemplate

2009-03-23T09:37:00.005+01:00

A hétvégén tovább folytattam az ANTLR-el való ismerkedést. Az ANTLR egy parser-generátor, ami egy nyelvtan alapján generál egy rekurzív leszálló (recursive descent) szintaktikai elemzőt.

Egy elemző alapesetben nem csinál mást, minthogy eldönti, hogy egy adott mondat része-e a nyelvnek, szintaktikailag értelmes-e. Az ANTLR segítségével viszont könnyedén készíthetünk olyan nyelvtanokat, amikből a generált parser egy bemenő mondatból kimenetként egy absztrakt szintaxis fát (AST) állít elő. Ezt a fát bejárva akár kiértékelhetjük a bemenetet (utasításokat), akár transzformációkat végezve átfordíthatjuk egy másik nyelvre.

Terence Parr a könyvében azt javasolja, hogy AST-k bejárásához is használjunk nyelvtanokat, pontosabban egy nyelvtan leírásából generált parsert, aminek a bemeneti mondatai az AST-k, kimenete meg mondjuk egy StringTemplate sablon megfelelő kitöltése.

Ezt a folyamatot szemlélteti - szintén Parr könyvéből származó - ábra:

A Code Generation honlapján 2005-ben megjelent egy cikk, "Language Translation Using ANTLR and StringTemplate" címmel, amiben Terence Parr bemutatja, hogyan lehet egy fordítót készíteni, ami egy C-szerű nyelvből Java, Python, vagy Java bytecode kódot állít elő. A példa nyelvtanok sajnos még az ANTLR 2-es verziójával készültek, amit azóta több szempontból is felülmúlt a legújabb, 3-as verzió. A hétvégén ezt alakítottam át, hogy működjön a 3-as verzióval, és először egy AST-t generáljon, majd az AST-t bejárva töltse ki a sablonokat.

A nyelvtanok itt találhatóak:

A tesztelést megvalósító Java kód:

Test.java

Működése pedig:

A teszt bemenet legyen a honlapon is fentlevő kódrészlet:


 char c;
 int x;
 int foo(int y, char d) {
   int i;
   for (i=0; i<3; i=i+1) {
     x=3;
     y=5;
   }
 }

Ezt Python-ra fordítva az alábbi kimenetet kapjuk:


kelda@psycho:~/ANTLR/cminus$ cat input.txt | java Test
(GLOBALS (VAR char c)) (GLOBALS (VAR int x)) (FUNCTIONS
(FUNCTION int foo (PARAMS (PARAM int y) (PARAM char d))
(BLOCK (LOCALS (VAR int i)) (STATEMENTS (FOR (INIT (= i
0)) (COND (< i 3)) (STMT (= i (+ i 1))) (BLOCK LOCALS
(STATEMENTS (= x 3) (= y 5))))))))

def foo(y, d):
  i = 0
  while ( i < 3 ):
      x = 3
      y = 5
      i = i + 1

Az elején az AST látható (gyökér levél1 levél2 ... levéln) formában, utána pedig a kimenet.

Ez a bejegyzés igazából nem akart másról szólni, minthogy illusztrálja az ANTLR és a StringTemplate erejét, a részletek bemutatása nélkül. Később részletesen is bemutatom majd a működését, a nyelvtanok felépítését, és hogy az egész hogyan is illeszkedik a blogomba :)

Egy kis segítségként annyit elárulhatok, hogy az SQL Developer egyik könyvtárában van egy oracle.sqldeveloper.migration.translation.sqlserver.jar file, aminek a belsejében található egy generic.stg és egy tsql.stg StringTemplate sablon. Azaz az SQL Developer Migration Workbench is az ANTLR és a StringTemplate segítségével végzi a nyelvi fordítást.

Diplomaterv

2009-03-16T18:49:00.004+01:00

Ebben a félévben főleg a diplomatervem elkészítésével fogok foglalkozni, melynek címe:

Adatbázis migráció Microsoft SQL Server adatbázisról Oracle adatbázis-kezelőre

azaz az előző féléves önálló labor témámat folytatom. A diplomaterv kiírásom pontjai:

Ismertesse az adatbázisok migrációinak általános problémáit a hazai és nemzetközi szakirodalom alapján!
Mutassa be a Microsoft SQL Server 2005 és Oracle 10g közötti migrációs eljárások és megoldások lehetőségeit és korlátait!
Készítsen funkcionális tervet a T-SQL nyelven írt üzleti logika szemantikailag helyes PL/SQL nyelvre fordítására a nyelvek kifejezőerejéből adódó korlátok között!
Implementálja és értékelje az elkészített rendszer egyes komponenseit, különös tekintettel

a PL/SQL kód olvashatóságára,
a PL/SQL kód szintaktikai helyességére,
a fordítási hibák jellegére és arányára.

Az első pont egy kicsit trükkös, ugyanis eddig igen kevés releváns szakirodalmat sikerült találnom. Amit találtam, azok is főleg az adatok migrációjával foglalkozik. Ezek közül kiemelendő Erik Peter Bansleben diplomamunkája az esettanulmány hasonlósága miatt:

The source systems consisted of a combination of Microsoft SQL Server and Access databases, while the target platform was an Oracle 9i server which was to serve as the backend database for the new system.

Ha esetleg tud valaki a témába vágó irodalomról, megköszönném, ha jelezné akár hozzászólásban, akár e-mailben: orveny kukac gmail pont com. Nagy segítség lenne :)

Az előző félévben gyakorlatilag a második ponttal foglalkoztam, így úgy érzem, ez nem fog különösebb kihívást jelenteni.

Ami érdekesebb, az a 3. és 4. pont: gyakorlatilag egy Transact-SQL -> PL/SQL fordítót kell készítenem. Szerencsére rátaláltam az ANTLR framework-re, aminek segítségével egy nyelvtanból viszonylag könnyedén lehet szintaktikus elemzőket, fordítókat készíteni.

A honlapján megtalálható Dermott O'Neill-től, az SQL Developer egyik fejlesztőjétől egy idézet:

The decision to use Antlr and StringTemplate for Oracles next generation Migration and SQL Developer features was easy due to the fantastic support on the forums, extensive documentation and great tools. In particular, the ability to parse trees and define target languages using StringTemplate, provided the end to end language translation technology we required. Other parser generators left us high and dry with only half the solution.

Egyelőre még csak az irodalom feldolgozás fázisában tartok, de mindenesetre igen bíztató, hogy egy olyan eszköz használatát tanulom, amivel az SQL Developer Migration Workbench is működik :)

Összefoglalás

2008-12-12T19:06:00.005+01:00

Ma este lezárult egy szakasz: teljesítettem az önálló laborokat. A dokumentumokat feltöltöttem a netre:

8. félév: Adattárházak tervezése
9. félév: Migráció

Természetesen bármiféle hozzászólást, kritikát szívesen fogadok!

A héten megérkezett az idei Oracle Szeminárium vizsga eredménye is: 74,15%-ot értem el. Bevallom, jobbra számítottam, de hát ez van.

A blog írását folytatni fogom, az önálló labortól függetlenül is, és hát a diplomatervezés még hátra van..

Mentegetőzések

2008-11-30T19:37:00.003+01:00

Több mint egy hónap telt el az utolsó blogbejegyzés óta. Ezt a hosszú szünetet nem üdüléssel töltöttem, hanem készült mindkét önálló labor doksim (migráció és adattárházak), meg persze egyéb házi feladatok, zh-k, előadások, munka, stb. Tehát csak a szokásos.

Menjünk időrendben: részt vettem az Oracle BI Fórumán, ahol több igen érdekes, és pár kevésbé érdekes előadást hallgattam meg. Sajnos, amit leginkább vártam, az FHB adattárház megvalósításáról szóló előadás sikeredett szerintem a leggyengébbre. Az előadás témája nagyon jó volt, csak maguk az előadók lehettek volna picit "meggyőzőbbek". Nekem valahogy úgy jött le az egész, hogy vagy álmosak, vagy nem akarják elmondani a "tutit" :) Egy hónap távlatából összesen annyira emlékszek, hogy több rendszerrel egy időben történt az adatbázis bevezetése, kialakítása, és nagyon nagyon összetett és bonyolult és komplex.

Az Essbase-es előadások viszont felkeltették a figyelmem. Szerintem majd "szabadidőmben" utána fogok olvasni, mi is az az essbase :)

Készülnek az önálló labor dokumentumaim is. Pontosabban a migrációról szóló már kész van, az adattárházak tervezéséről szóló pedig folyamatban van. Amint befejezem (abbahagyom?), felrakom azt is az internetre.

Ezen a héten volt az Oracle Szeminárium záró eseménye: a vizsga. Szerintem nem volt nehéz, de a jellege miatt (teszt, több helyes válasz is lehet, rossz válasz mínusz pont) akár igen gyengén is sikerülhetett.. Mindenesetre várom az eredményt :)

Oracle Blogger Dinner - 2008. ősz

2008-10-26T16:52:00.004+01:00

Holnap délután 17 órakor az Oracle irodaházban kerül megrendezésre a harmadik Oracle Blogger Dinner, ahol magyar bloggerek beszélgetnek, esznek, isznak, jót mulatnak, de elsősorban a migrációról szóló előadásomat hallgatják :)

A slide-okat most is feltöltöttem a netre, a jelszó a szokásos (titok), a szokásos okból.

Habár a téma nem a legegyszerűbb, és én is belemegyek majd technikai részletekbe, remélem a sok T-SQL és PL/SQL kód között azért majd lesz idő egy koccintásra is :) És nagyon remélem, hogy ezúttal látszódni fognak a screenshot-jaim a projektoron, nem úgy, mint az egyetemi önálló labor előadáson..

Migráció V.

2008-10-26T12:39:00.004+01:00

Oracle Relational Migration Maps

Az Oracle Relational Migration Maps (röviden: Migration Maps) az Oracle által használt módszertan egy meglévő adatbázis Oracle adatbáziskezelőre migrálásához.

Nem tudom, hogy ez mennyire aktuális, ugyanis a honlapja jól láthatóan egy régebbi design-ba illeszkedik, viszont az OTN-ről jelenleg is elérhető, ezért én úgy veszem, hogy az ott leírtak még ma is tükrözik az Oracle álláspontját :) De igazából nem is a konkrét részletek az érdekesek, hanem az eddig leírt részletes technikai problémák és megoldási javaslatok helyett három lépést hátralépve madártávlatból is megnézzük egy migráció folyamatát.

A folyamatban négy fő szerepkör lett definiálva:

Ügyfél
Migrációs projekt menedzser
Adatbázis migrációs mérnök
Alkalmazás migrációs mérnök

Az ügyfél feladata, hogy technikai segítséget nyújtson a migráció során az alkalmazással kapcsolatban felmerülő kérdésekben, ugyanis ebben a módszertanban a migrációt alapvetően az Oracle szakemberei végzik az ügyfél aktív közreműködésével. Ezen kívül a projekt elején ki kell tölteni egy úgynevezett Assessment Questionnaire-t, aminek célja az alapvető követelmények meghatározása, a szükséges erőforrások felbecsülése, a jelenlegi alkalmazás bemutatása. A kérdőívben olyan kérdések szerepelnek, mint például: "What business problems does your application system solve?" vagy "What is the timeframe for your current migration project?". Talán a "Select all of the technologies and languages used in your application system." kérdésre adható válaszlehetőségekből is látszik, hogy ezt a kérdőívet bizony nem ma írták, ugyanis a listában nem szerepel a C# .NET, sőt, a .NET egyedül ASP.NET kontextusban merül fel.

Az általános kérdések közé becsempésztek pár igen komoly - technológiai különbségekre utaló - kérdést is, ezek:

"Does your database or application system require any precision past seconds in the DATETIME column?": ez azért érdekes, mert az Oracle DATETIME adattípusa csak másodperc pontossággal képes az időt tárolni, míg SQL Serverben ez 3.33 ms.
"Does your database or application system evaluate empty strings ('') and NULLs as the same?": ugyanis Oracle alatt az üres string az NULL.

A kitöltött kérdőíven felül el kell küldenie az alkalmazás forráskódját is a migrációs projekt menedzsernek.

Igazából ezek egyszerű igen/nem kérdéseknek tűnnek, de ha mondjuk nekem kéne megválaszolnom őket, nem tudom, hány napig tartana a helyes válasz kiderítése.. Persze, ha valakinek olyan rendszerrel van dolga, ahol a legutolsó kis részlet is végletekig dokumentálva van, akkor más a helyzet.

A migrációs projekt menedzser áll a középpontban, ő biztosítja a magas minőségű munkát az Oracle részéről, illetve kezeli az ügyfél igényeit. Rajta keresztül zajlik a kommunikáció, ő tervezi meg a feladatokat, illetve azok időzítését. Magyarul ő a projekt menedzser, ennek minden feladatával és felelősségével együtt :)

Az adatbázis migrációs mérnök az Oracle Migration Workbench segítségével (akkor, amikor ezt a módszertant készítették, a Migration Workbench még egy különálló alkalmazás volt, most már az SQL Developer-be integrálták) migrálja a forrás adatbázist, és teszteli, hogy valóban úgy működik, mint az eredeti verzió.

Ehhez hasonlóan, az alkalmazás migrációs mérnök az alkalmazás megfelelő módosításaiért felelős.

A migráció 6 fő lépésből áll, melyeket az alábbi ábra szemléltet:

Forrás: http://www.oracle.com/technology/tech/migration/maps/index.html

A definíciós fázisban kell elvégezni a meglévő rendszer részletes vizsgálatát, felmérni a feladat komplexitását, hogy meg lehessen becsülni a migrációs feladatokat, azok időtartamát.

Az analízis fázisban kezdődik az igazi munka. Egyeztetni kell az ügyféllel a definíciós fázisban felderített kérdéseket, problémákat, javaslatokat. Egy migráció során nem triviális, hogy az ügyfél mennyire ismeri a célrendszert, annak sajátosságait, a forrásrendszerrel szembeni különbségeit, ezért fontos feladat az oktatás. Az analízis fázisban kell meghatározni, hogy az ügyfélnek milyen témákban van szüksége oktatásra.

Ezen felül szükséges még az adatbázis biztonsági, adminisztrációs követelményeinek illetve biztonsági mentések és visszaállítások stratégiájának vizsgálata.

A tervezési fázis arról szól, hogy a definíciós és analízis fázis során szerzett ismeretek alapján megtervezzük a felmerült feladatok, problémák megoldását, azaz elkészítjük az oktatási tervet, a célrendszer hardver, hálózati és szoftver architektúráját, a felmerült architektúrális problémákra a megoldási terveket (például: ideiglenes táblák, séma-objektum nevekben történő változások, stb.), az adatok migrációjának a stratégiáját, átállási stratégiát, stb.

A migrációs fázis célja, hogy tömör, megbízható script-ek és riportok álljanak az ügyfél rendelkezésére, amikből felépítheti a célrendszer alatt az adatbázis sémát. Ebben a fázisban történik a tesztelés is.

Az átállás fázis - mint ahogy a nevéből is következik - az átállást hivatott megvalósítani, azaz a migrált rendszer feltelepítését, ügyfél általi tesztelését, adatkonverziót illetve élesbe állást.

Az utolsó, üzemeltetési fázisban szükség lehet, hogy a már feltelepített, éles rendszerben kell támogatást nyújtani az ügyfélnek.

Migráció IV.

2008-10-25T16:43:00.004+02:00

Tranzakciókezelés

Microsoft SQL Server 2000 alatt három féle módon lehet tranzakciót kezdeni:

explicit módon: egy BEGIN TRANSACTION utasítás kiadásával
implicit módon: amennyiben a SET IMPLICIT_TRANSACTIONS ON utasítással bekapcsoltuk ezt a módot, akkor az ezt követő utasítás automatikusan egy tranzakciót fog nyitni. Amikor az befejeződik, akkor a következő utasítás egy új tranzakciót kezd, és így tovább.
autocommit: ez az alapértelmezett mód az SQL Server-ben: minden egyes T-SQL utasítás vagy véglegesítésre kerül (commit), vagy visszagörgetődik (rollback).

Explicit tranzakciók esetén a programozó határozza meg a tranzakció elejét és végét is, Transact-SQL scriptek esetén BEGIN TRANSACTION / COMMIT / ROLLBACK utasításokkal, ADO.NET esetén pedig az SqlConnection objektum BeginTransaction() illetve Commit() / Rollback() metódusaival.

A BEGIN TRANSACTION utasítás 1-el növeli a @@TRANCOUNT változó értékét (alapesetben a változó 0), a COMMIT 1-el csökkenti, míg a ROLLBACK 0-ra állítja. Ez azért van így, mert SQL Server alatt úgy lehet tranzakciókat egymásba ágyazni, hogy a beágyazott tranzakciók esetében az adatbázis a COMMIT utasításokat figyelmen kívül hagyja, csak a legkülső COMMIT után lesznek a módosítások véglegesítve. A ROLLBACK utasítás viszont minden aktív tranzakciót visszagörget.

Ezzel szemben Oracle adatbáziskezelő alatt egy tranzakció az első végrehajtható SQL utasítással kezdődik, és vagy akkor ér véget, amikor explicit módon kiadunk egy COMMIT illetve ROLLBACK utasítást, vagy implicit módon, pl.: egy DDL utasítás végrehajtásával, vagy az adatbázisból történő kilépéskor (disconnect).

Léteznek még úgynevezett autonóm tranzakciók (autonomous transactions), amik teljesen függetlenek a "hívó" tranzakciótól. Például, ha egy tárolt eljárás az AUTONOMOUS_TRANSACTION direktívával lett lefordítva, akkor, amikor meghívódik egy külső tranzakcióból, nem látja annak a még nem véglegesített adatait, illetve tőle függetlenül lesz véglegesítve vagy visszagörgetve. Ez például naplózást megvalósító eljárások esetén lehet hasznos.

Az Oracle Migration Workbench a BEGIN TRANSACTION utasításokat a SET TRANSACTION READ WRITE utasítássá fordítja át, ami az aktuális tranzakciót úgy állítja át, hogy utasítás szintű konzisztenciát biztosítson (statement-level read consistency).

Ez annyiban nem szerencsés, hogy míg a BEGIN TRANSACTION tetszőleges helyen szerepelhet egy T-SQL blokkban, addig Oracle alatt a tranzakció tulajdonságait csak az első utasításban lehet beállítani. Azaz például, ha egy INSERT szerepel a BEGIN TRANSACTION előtt (az explicit tranzakción kívül, alapértelmezetten autocommit módban), akkor ezt a Migration Workbench segítségével PL/SQL-re fordítva valami ilyesmit kapunk:

CREATE OR REPLACE PROCEDURE sp_something
AS
BEGIN
INSERT INTO proba
VALUES ( 1, SYSDATE );

SET TRANSACTION READ WRITE;

INSERT INTO proba
VALUES ( 2, SYSDATE );

ROLLBACK;

END;

ami - habár szintaktikailag helyes, azaz le fog fordulni - futáskor hibát fog adni:

ORA-01453: SET TRANSACTION must be first statement of transaction

Gond van még a @@TRANCOUNT változóval is, mert a dokumentáció szerint hiába támogatja a Migration Workbench a globális változók migrációját, nekem összesen annyit sikerült elérnem, hogy a @@TRANCOUNT-ot v_transcount-ra cserélte. A SwisSQL (a Migration Workbench konkurrenciája) ezt a kérdést úgy oldja meg, hogy egy package-ben deklarál egy változót, amit minden egyes tranzakciókezelő utasításkor növel/csökkent, azaz BEGIN TRANSACTION helyett növeli eggyel, COMMIT után csökkenti eggyel, és ROLLBACK után pedig 0-ra állítja.

Önálló labor beszámoló

2008-10-15T18:36:00.003+02:00

Ma délután kértek fel arra, hogy holnap tartsak egy előadást az önálló labor témámról (migráció), mivel többen visszamondták a sajátjukat. Gyorsan összedobtam egy pár slide-ból álló prezentációt, aztán majd lesz, ami lesz :) Elvégre benne vagyok a témában, tehát olyan nagy meglepetés nem érhet..

A .rar archívumhoz a jelszó: titok, csak azért védtem így le, mert benne van az email-címem, aztán a csúnya spam-robotok nehogy megszeressenek.

Október 27-én egy Oracle Blogger Dinner keretén belül egy másik előadást is fogok tartani, szintén migráció témában, de az picit nagyobb lélegzetvételű lesz: kb. 1 óra a mostani 10-15 perc helyett. Ha elkészül majd - terveim szerint a jövő heti hosszú hétvége alatt - akkor azt is közzé fogom tenni.

Oracle Business Intelligence Fórum

2008-10-13T18:20:00.004+02:00

November 6-án, csütörtökön 9 órától lesz az Oracle Business Intelligence Fóruma, ahol bemutatják az Oracle üzleti intelligencia és adattárház megoldását, annak újdonságait és terveit.

Előzetes napirend:

9:00-9:30: Regisztráció
09:30–10:00: Az Oracle üzleti intelligencia és adattárház megoldástérképe
Joerg Fuchslueger, regionális üzletfejlesztési igazgató - Oracle
10:00–10:30: Adatbiztonság, skálázhatóság az adattárházban, adattárház újdonságok
Sárecz Lajos - Oracle , Radnai Szabolcs - Oracle
10:30–10:50: Banki adattárház megoldás a gyakorlatban
10:50–11:10: HP Oracle Database Machine és Oracle Exadata Storage Server
Győr Ferenc – Hewlett Packard, Radnai Szabolcs – Oracle
11:10–11:30: Szünet
11:30–12:00: Oracle BI csomagok és BI Alkalmazások
Fekete Zoltán - Oracle
12:00–12:30: Hangbányászati alkalmazás és az Oracle Business Intelligence
Bódogh Attila – Nextent
12:30–13:00: Oracle Essbase – kézenfekvő megoldás a kontrolling számára
Oliver Gratzl – Oracle
13:00–13:30: A KSH új generációs adattárháza Oracle Essbase alapokon
Antoni S. Soma – KSH , Szente István DSS
13:30: Beszélgetés, Ebéd

A rendezvény ingyenes, regisztrációhoz kötött. Én megpróbálok ott lenni, mindenesetre már regisztráltam :)

Dimenzionális modellezés - bitmap indexek

2008-10-12T16:39:00.006+02:00

Az előző dimenzionális modellezésről szóló bejegyzésben megemlítettem, hogy a csillag sémának az egyik előnye a jó lekérdezési teljesítmény. Akkor ezt hagytam lógni a levegőben, nem indokoltam meg, hogy miért. Ez a bejegyzés viszont arról szólna, hogy csillag séma esetén milyen technikák léteznek a lekérdezések optimalizálására.

Az indexek a lekérdezésekben szereplő szelekciós feltételek kiértékelésénél használatosak (pl.: WHERE T.A = 1000). Általános esetben egy lekérdezés végrehajtási ideje az indexek feldolgozásának és az adatok kinyerésének ideje. Ha egy lekérdezés eredményhalmazának mérete jelentős a tábla teljes méretéhez viszonyítva, akkor az adatelérés ideje megközelítheti egy teljes "table scan" (amikor a tábla minden során egyesével végigmegyünk) idejét. Ilyen esetekben az indexek használata épphogy lassítaná a lekérdezést.

Erre a problémára az egyik elterjedt megoldás az ún. bitmap indexek, vagy magyarra fordítva bittérképes indexek használata. Bitmap indexekből is többféle létezik, a család legegyszerűbb tagja az egyszerű bitmap indexek (simple bitmap indexes). Például, ha az indexelni kívánt attribútum a nemek (ami tipikusan két értéket vehet fel: Férfi, Nő), akkor az index egy két bitből álló vektor lenne, az egyik bit a férfiak esetén lenne 1-es, a másik pedig nők esetében:


gender='M'     gender='F'

cust_id 70     0    1
cust_id 80     0    1
cust_id 90     1    0
cust_id 100    0    1
cust_id 110    0    1
cust_id 120    1    0
cust_id 130    1    0
cust_id 140    1    0

A fenti táblázat minden sora az Ügyfél (Customer) tábla egyik rekordjához tartozik. Az egyszerű bitmap indexek mérete az indexelendő attribútum kardinalitásának és a tábla méretének lineáris függvénye, és az index feldolgozás ideje az index méretének lineáris függvénye. Emiatt rögtön látszódik az egyszerű bitmap indexek egyik hátrányos tulajdonsága: ha az indexelendő attribútum sokféle értéket vehet fel, akkor a táblázat igen ritka lesz (sparsity problem), egy sorhoz tipikusan csak egy darab 1-es fog tartozni, a többi bit értéke 0 lesz. Ez pedig nem nevezhető hatékony tárhely-kihasználásnak. Erre megoldás lehet a bittérképek tömörítése (pl.: futáshossz kódolással), de így elveszítenénk a bitmap indexek egy igen kellemes tulajdonságát: ha több feltétel egyszerre történő teljesülését akarjuk vizsgálni, akkor a bittérképek adott oszlopainak logikai ÉS kapcsolatát kell csak kiszámolnunk:


        gender='M'  region='central'

cust_id 70     0          1           0
cust_id 80     1          1           1
cust_id 90     1    AND   0    =      0
cust_id 100    0          0           0
cust_id 110    1          1           1

azaz a 80-as és a 110-es ügyfél tartozik a központi régióban levő férfiak közé. Ming-Chuan Wu a Query Optimization for Selections using Bitmaps című munkájában két olyan bitmap indexet is javasol, amik megőrzik a fent bemutatott előnyöket és mégis hatékonyabb tárhelykihasználtságot tesznek lehetővé.

Bit-sliced indexing

Az első az ún. bit-sliced indexelés (ezt inkább nem próbálom meg magyarra fordítani, úgyis csak valami zagyvaság lenne belőle:) ). Egy attribútum bit-sliced indexe az attribútum értékének bitenkénti leképezése. Például, ha egy A attribútum egy 16-bites egész szám, és értékei 100 és 900 közötti értékeket vehetnek fel, akkor a hozzá tartozó index így nézhet ki:


A        b15...b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0
201         0...0    0  0  1  1  0  0  1  0  0  1
100         0...0    0  0  0  1  1  0  0  1  0  0
900         0...0    1  1  1  0  0  0  0  1  0  0

A bitvektorok száma megegyezik az attribútum típusának méretével, a vektorok hossza pedig az indexelt tábla kardinalitásával.

Egy bit-sliced indexnek nem feltétlen kell bináris alapúnak lennie, elképzelhető például decimális alapú bit-sliced index is. Az előző példában szereplő A attribútum tizes alapú indexe három komponensből állna, a helyiértékeknek megfelelően.


A     b9 b8 b7 b6 b5 b4 b3 b2 b1 b0    b9 b8 b7 b6 b5 b4 b3 b2 b1 b0    b9 b8 b7 b6 b5 b4 b3 b2 b1 b0
124     0  0  0  0  0  0  0  0  1  0     0  0  0  0  0  0  0  1  0  0     0  0  0  0  0  1  0  0  0  0
      harmadik komponens                  második komponens               első komponens

Ilyen típusú indexek esetén a kiválasztás a megfelelő bitvektorok kiolvasásával és össze-ÉS-eléssükkel történik. Például az A=124 szűrőfeltétel esetén a b1 b2 b4 vektorokat olvassuk ki rendre a harmadik, második illetve első komponensekből, és logikai ÉS kapcsolatba hozzuk őket. Az eredmény pedig azon sorokat tartalmazza, ahol az A értéke 124.

Az alap kiválasztása a tárhelykövetelményeket és a feldolgozási sebességet befolyásolja. A fenti példában a bináris alapú index 16 bitvektorból áll, míg a tizes alapú 30-ból. Egy szűrő feltétel kiértékelése (pl.: A=124) bináris alapon 16 bitvektor végigpásztázását jelenti, decimális alapon viszont csak háromét.

Encoded Bitmap Indexing

Egy másik bitmap indexelést kódolt bitmap indexelésnek neveznek (encoded bitmap indexing, EBI). Az EBI az attribútum értelmezési tartományát leképezi egy kódoló függvény segítségével, és a kódolt értékeken felépít egy bináris alapú bit-sliced bittérképet. A bináris alap és kódolás segítségével hatékony tárhelykihasználtságot tesz lehetővé, ugyanakkor viszont megtartja a lekérdezés-optimalizálás lehetőségét jóldefiniált kódolás segítségével (well-defined encoding). Például, ha egy B attribútum értelmezési tartománya {a, b, c, d, e, f, t, u, v, w}, akkor egy M függvényt az alábbi módon definiálhatunk:


B      M(B)
void    0000
NULL    0001
a      0010
b      0011
c      0100
d      0101
e      0110
f      0111
t      1000
u      1001
v      1010
w      1011

a void az adatbázisból törölt, a NULL pedig a NULL értékeket reprezentálja. A fenti táblázathoz tartozó minterm-ek:


f_void=/b3/b2/b1/b0    f_b = /b3/b2b1b0
f_null=/b3/b2/b1b0     f_c = /b3b2/b1/b0
f_a   =/b3/b2b1/b0     f_d = /b3b2/b1b0

f_e = /b3b2b1/b0       f_u = b3/b2/b1b0
f_f = /b3b2b1b0        f_v = b3/b2b1/b0
f_t = b3/b2/b1/b0      f_w = b3/b2b1b0

EBI segítségével egy szűrés az alábbi módon hajtható végre:
szűrőfeltétel: B eleme {a, b, e, f}
Ezekhez az elemekhez tartozó minterm-ek egy Boole függvényt alkotnak: f_a + f_b + f_e + f_f, amit tovább lehet egyszerűsíteni /b3b1-re. Azaz, azon értékek elégítik ki a szűrőfeltételt, amik b3 bitjét negálva majd b1 bitjükhöz ÉS-elve 1-et kapunk.

Az EBI valójában nem más, mint egy bináris alapú bit-sliced bitmap index egy attribútum kódolt értelmezési tartományán. Az EBI-knek két előnyük van a bit-sliced indexek felett:

a bitvektorok száma nem több, mint a bit-sliced esetében, hiszen a szükséges bitvektorok száma az adott attribútum számosságának kettes alapú logaritmusa (+2 a törölt és NULL értékek miatt, és ennek a felsőegészrésze).
EBI esetében több optimalizálási lehetőség van "megfelelő" kódoló függvény kiválasztása esetén. Ilyen függvényeket Wu: Encoded Bitmap Indexing for Data Warehouses című írásában mutat be.

Csillag transzformáció bitmap indexekkel

Ezen kitekintő után térjünk vissza a csillag sémánkhoz. Például, egy szokásos értékesítési adatokat tartalmazó "sales" tény-tábla esetén dimenziók lehetnek: idő, ügyfél, termék, értékesítési csatorna.

Tekintsük az alábbi lekérdezést:


SELECT ch.channel_class, c.cust_city, t.calendar_quarter_desc,
SUM(s.amount_sold) sales_amount
FROM sales s, times t, customers c, channels ch
WHERE s.time_id = t.time_id
AND   s.cust_id = c.cust_id
AND   s.channel_id = ch.channel_id
AND   c.cust_state_province = 'CA'
AND   ch.channel_desc in ('Internet','Catalog')
AND   t.calendar_quarter_desc IN ('1999-Q1','1999-Q2')
GROUP BY ch.channel_class, c.cust_city, t.calendar_quarter_desc;

Oracle adatbáziskezelő alatt a csillag transzformáció feltétele, hogy minden illesztéshez használt oszlopon definiálva legyen egy bitmap index, ebben az esetben cust_id, time_id, channel_id. A lekérdezést két menetben hajtja végre az adatbáziskezelő motor. Az alábbi lekérdezés végrehajtásával csak azokat a sorokat gyűjti ki a tény táblából, amik valóban szükségesek:


SELECT ... FROM sales
WHERE time_id IN
(SELECT time_id FROM times
WHERE calendar_quarter_desc IN('1999-Q1','1999-Q2'))
AND cust_id IN
(SELECT cust_id FROM customers WHERE cust_state_province='CA')
AND channel_id IN
(SELECT channel_id FROM channels WHERE channel_desc IN('Internet','Catalog'));

Ebben a lekérdezésben a tény táblán a time_id-re definiált bitmap index segítségével kiválasztjuk azokat a sorokat, amik 1999. első negyedévére vonatkoznak. Ez valójában annyit jelent, hogy azokat a sorokat választjuk ki, amiknél a bittérképben az 1999-Q1 bit értéke 1-es értékű. Hasonlóan történik a második negyedév adatainak kiválasztása. A kettő bitenkénti VAGY kapcsolatba hozásával kapjuk meg a kívánt időszakot.

Ugyanilyen módon történik az ügyfelekre és értékesítési csatornákra történő szűrőfeltételek kiértékelése. A kapott három bittérképet majd logikai ÉS kapcsolatba hozva csupán azon sorok esetén kapunk 1-es értéket, amik az összes feltételt kielégítik.

A második lépésben történik meg a tény tábla kiválasztott sorainak a dimenzió táblákhoz történő illesztése. Mivel a dimenzió táblák relatíve kis méretűek a tény táblákhoz viszonyítva, az Oracle általában teljes "table scan"-t használ az elérésükhöz.

Források:

Migráció III.

2008-10-11T18:08:00.002+02:00

Visszatérési értékek

A visszatérési értékek okozzák a legizgalmasabb problémákat a migráció során. SQL Server alatt egy tárolt eljárás háromféle módon képes adatokat visszaadni a hívója felé:

kimenő paraméterekkel: CREATE PROCEDURE sp_demo (@something int OUT)
visszatérési értékkel: return @someValue
úgynevezett eredményhalmazokkal (result set-ekkel): egy T-SQL tárolt eljárás képes visszaadni egy tetszőleges SELECT utasítás által visszaadott eredményhalmazt

Kimenő paraméterekből és visszaadott eredményhalmazokból - ha jól tudom - tetszőleges számú lehet, persze elképzelhető, hogy van valami igen magas felső korlát.

Egy példa ezen módok bemutatására:

CREATE PROCEDURE sp_demo (@something int out)
AS
begin
set @something = 5
select 7
return 9
end

Az eljárást futtatva az alábbi eredményt kapjuk:

Az első eredményhalmazt a tárolt eljárás adta vissza (SELECT 7), a második pedig az @i, @j változók tartalmát mutatja.

Mint azt már egy korábbi, migrációról szóló bejegyzésben írtam, a migráció egyik célja az lenne, hogy a .NET-es vastag kliens lényegében kizárólag tárolt eljárás hívásokkal kommunikál az adatbázissal. Mind a módosító, mind a lekérdező funkciókat tárolt eljárások valósítják meg: az eljárás által visszaadott eredményhalmazt a kliens valahogy feldolgozza (pl.: megjeleníti táblázatos formában). De természetesen vannak olyan eljárások is, amik nem adnak vissza semmit sem, hanem csak az adatbázisban módosítanak valamit.

Oracle adatbáziskezelő alatt viszont egy tárolt eljárás csak kimenő paraméterekkel képes adatokat visszaadni. Nincs sem visszatérési érték, sem eredményhalmaz. Eredményhalmazokat kurzor referenciákkal (REF CURSOR) lehet emulálni. Az Oracle Migration Workbench is ezt a módszert követi: ha egy T-SQL tárolt eljárás eredményhalmazokat adna vissza, azt úgy fordítja át PL/SQL-re, hogy felvesz annyi darab kurzor referencia kimenő paramétert, ahány eredményhalmazt az eljárás visszaad. Például, a fenti sp_demo eljárás PL/SQL-es változata így nézne ki:

CREATE OR REPLACE FUNCTION sp_demo
(
v_something OUT NUMBER,
cv_1 IN OUT SYS_REFCURSOR
)
RETURN NUMBER
AS
BEGIN
v_something := 5;

OPEN cv_1 FOR
SELECT 7
FROM DUAL ;

RETURN 9;
END;

Hoppá! Az OMWB függvényt csinált az eljárásunkból! Ez azért van, mert visszatérési értéke csak és kizárólag függvényeknek lehet PL/SQL-ben. Viszont egy függvény és egy tárolt eljárás között számos lényegi különbség van, amik miatt nem szerencsés csak úgy egyikből a másikat csinálni. Egy függvény nem végezhet adatmódosító (DML) utasításokat SQL utasításokban. Csupán azért alakította a migráló eszköz függvénnyé, mert csak azoknak lehet visszatérési értéke.

Tehát annyit már most is kijelenthetünk, hogy ha vannak olyan T-SQL tárolt eljárásaink, amiknek van visszatérési értékük, akkor célszerű elgondolkozni azon, hogy hogyan alakítsuk át őket. Például felvehetünk kimenő paramétereket, vagy, ha eddig valójában függvényként használtuk az eljárást, akkor alakítsuk is át függvénnyé.

Az eredményhalmazok kérdése viszont trükkösebb. Ugyanis a kimenő paramétereket az eljárás hívásakor explicit fel kell venni. Ha egy eljárás hív egy másikat, akkor a hívó eljárásban is deklarálni kell egy kurzor változót, amit paraméterül adunk a másik eljárásnak. Ha viszont .NET alól szeretnénk ilyen eljárásokat meghívni, akkor a paraméterlistába kell felvenni a kimenő kurzor típusú paramétert:

cmd.Parameters.Add("cv_1", OracleType.Cursor).Direction =
ParameterDirection.Output;

Ha ezt elmulasztjuk, akkor a hívás exception-t fog dobni, PLS-00306 hibaüzenettel: "wrong number or types of arguments in call to '*spname*'". Ugyanez igaz fordítva is, azaz ha olyan eljárásnál próbálnánk hozzáadni, aminek valójában nincs ilyen paramétere.

És ezzel eljutottunk egy igen kemény problémához: a migráció célja ugye az, hogy ugyanaz a kliens legyen használható SQL Server és Oracle adatbáziskezelő esetén is. SQL Servernek nem kell explicit megmondani, hogy a tárolt eljárás fog-e visszaadni eredményhalmazt, Oracle-nek viszont igen. Egy T-SQL tárolt eljárás tetszőleges számú eredményhalmazt is visszaadhat, egy PL/SQL-es viszont pontosan annyit, ahány kimenő kurzor változó paramétere van.

Mivel a migráció során úgyis hozzá kell nyúlni minden egyes tárolt eljárás kódjához (ha másért nem, akkor azért, hogy megnézzük, úgy működik-e, ahogy szeretnénk), ezért arra a kompromisszumos megoldásra jutottunk, hogy:

minden tárolt eljárásnak kötelezően van egy cv_1 nevű kimenő paramétere, a paraméterlista első helyén, attól függetlenül, hogy visszaad-e eredményhalmazt, vagy sem
azon tárolt eljárások esetében, amik több eredményhalmazt is visszaadnának, újragondoljuk a funkciójukat, és szükség esetén feldaraboljuk több eljárássá, azaz eljárásonként pontosan egy visszaadott eredményhalmaz.

Az eljárások egymást is hívják, ezért a kódot ilyen esetekben is módosítani kell. Mit nyerünk ezzel? Azt, hogy a kliens kód megtarthatja az univerzális jellegét, és nem kell kliens oldalon is minden egyes eljáráshíváshoz hozzányúlni. (Pl.: ott is megmondhatnánk explicit módon, hogy a hívott eljárás vissza fog-e adni eredményhalmazt, vagy sem, és ennek hatására SQL Server esetén nem történne semmi, Oracle esetén viszont felkerülne a paraméterlistába a kimenő kurzor változó.)

Az MSDN-en szerepel egy viszonylag részletes leírás arról, hogy hogyan kell .NET alatt PL/SQL tárolt eljárásokat hívni, illetve érdekes olvasmány még Vadim Tropashko kurzorokról szóló blogbejegyzése. Ennek a cikknek a végén szerepel egy kemény kijelentés:

It seem that the genesis of “a better cursor demand” is a stream of programmers from SQL Server world, where a procedure which doesn’t even bother to declare its outputs as a cursor like this

CREATE OR REPLACE PROCEDURE TESTSPROC2
AS
select * from test_table order by id_no;
GO

Its a pity that TSQL designers give an impression of not understanding the difference between a procedure and a query.

Hát, ez kicsit úgy hangzik, mintha az Oracle megoldása lenne az egyetlen járható út.

Készítettem egy buta kis Windows-os alkalmazást, ami azt próbálja demonstrálni, hogy a kliens oldalon milyen változtatások szükségesek ha SQL Server helyett Oracle adatbáziskezelőt akarunk használni. Az egyedüli különbség (a használt osztályokat leszámítva) a kurzor paraméter deklarációja. A kód letölthető innen.

Migráció II.

2008-09-21T16:30:00.003+02:00

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:

CREATE TABLE new_employees
(
id_num int IDENTITY(seed,increment),
fname varchar (20),
minit char(1),
lname varchar(30)
)

Forrás: http://msdn.microsoft.com/en-us/library/aa933196(SQL.80).aspx

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.

Még pár szó a konverziókról

2008-09-21T12:29:00.002+02:00

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:

FUNCTION convert_(p_dataType IN VARCHAR2, p_expr IN VARCHAR2, p_style IN VARCHAR2 DEFAULT NULL) RETURN VARCHAR2;

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:

select value from v$NLS_PARAMETERS where parameter = 'NLS_DATE_FORMAT'

Ez nálam azzal jár, hogy elveszik minden idő jellemző (óra, perc, másodperc). Például a 108-as stílus (hh:mi:ss) a convert_() függvénnyel használhatatlan.

Ezek után már csak egy költői kérdés maradt hátra, hogy a függvény kódjában a 108-as stílushoz miért a HH12-as formátum tartozik, amikor SQL Server alatt a hh 24 órás megjelenítést jelent.

Oracle szeminárium - 2008 ősz

2008-09-11T17:06:00.009+02:00

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 :)

Migráció I.

2008-09-07T17:12:00.008+02:00

Lassan egy hónapja tart a migráció előkészítése, gyűjtjük a megoldásra váró problémákat, próbálunk egy átfogó képet szerezni az előttünk álló folyamatról. Ebben a bejegyzésben megpróbálom összefoglalni, hogy mire jutottunk eddig.

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:

CAST ( expression AS data_type [ (length ) ])
CONVERT ( data_type [ ( length ) ] , expression [ , style ] )

Forrás: http://msdn.microsoft.com/en-us/library/ms187928.aspx

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:

Forrás: http://msdn.microsoft.com/en-us/library/ms187928.aspx

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

Forrás: http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/sql_elements002.htm#i46862

explicit konverziók:

Forrás: http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/sql_elements002.htm#i46862

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.

Dimenzionális modellezés - a csillag séma

2008-08-17T19:44:00.004+02:00

A csillag séma a tény tábla és a dimenzió táblák csillag szerű összekapcsolásából áll. A középen álló tény tábla tartalmazza a számszerű (lehetőleg összeadható) mértékeket, valamint a csillag-szerűen kapcsolódó dimenzió táblákra való hivatkozásokat (távoli kulcsokat). A dimenzió táblák pedig - mint már említettem - a lehető legtöbb leíró tulajdonságot tartalmazza.

Forrás: Wikipedia

A legkézenfekvőbb tulajdonságai a csillag sémának az egyszerűség, és a szimmetria. Talán már ránézésre is érthetővé válik, hogy milyen üzleti folyamatot reprezentál a modell, még egy informatikában kevésbé jártas üzleti felhasználó számára is.

Az egyszerűség másik jelentős következménye a jó lekérdezési teljesítmény. Az adatbázis motor sokkal kevesebb join segítségével tudja végrehajtani a lekérdezéseket.

A szimmetriának köszönhetően minden dimenzió teljesen ekvivalens, mindegy melyik dimenzió felhasználásával indít lekérdezéseket a felhasználó, nincs különbség. Nincsenek a modellbe épített feltételezések a leendő lekérdezéseket illetően.

Mark Rittman írt egy bejegyzést a blogjába arról, hogy hogyan lehet egy normalizált modellből az Oracle BIEE segítségével dimenzionális modellt építeni.

OMWB - két újabb idegesítő bug?

2008-08-14T16:51:00.003+02:00

Folytatódik a munkahelyemen a migráció előkészítése: nézegetjük, hogy egyrészt mire képes a Migration Workbench, másrészt mik azok a lehetséges buktatók, amikre még nem gondoltunk.

Eközben találtam egy újabb bug-gyanús - igen idegesítő - hibát az OMWB-ben:

Ha valamilyen Oracle kulcsszó szerepel azonosítóként az SQL Server oldali kódban, azt okosan átalakítja, például:

select @something = date
from MyTable

ez a kód teljesen jó SQL Server alatt, ha a MyTable táblának van date nevű oszlopa. Ezt az alábbi kódra alakítja át:

SELECT date_
INTO v_something
FROM MyTable ;

A konvertálás előtt egy kollégám elkészített egy olyan sémát, ahol az összes oracle-s kulcsszó mögé egy _-t szúrt. Tehát már SQL Server oldalon az összes date-ből date_ lett, a type-okból type_, és így tovább. Viszont konvertálás után az összes type_ azonosítóra való hivatkozásból újra type lett. Ami SQL Server alatt:

select @something = type_
from MyTable

az konvertálás után:

SELECT type
INTO v_something
FROM MyTable ;

ami természetesen hibás. Ugyanez más kulcsszó esetén nem jött elő, tehát a date_-ek megmaradtak :)

A másik bug a következő: amit már egy korábbi bejegyzésben írtam is, az SQL Server megengedi, hogy egy tárolt eljárás bemenő paraméterét mezei változóként kezeljük, azaz állhat értékadás bal oldalán. Ezt az OMWB kezeli is, egy belső, rendesen deklarált változó segítségével. Ha a paraméterre való hivatkozás mindenhol pontosan ugyanaz, case sensitive-en:

create procedure foo (@bar int)
as
begin
select @Bar=5
end

itt ugye a hivatkozás megegyezik, leszámítva a kis/nagy B betűt. Az OMWB emiatt megzavarodik picit:

CREATE OR REPLACE PROCEDURE foo
(
v_bar IN NUMBER DEFAULT NULL
)
AS
BEGIN
v_Bar := 5;

END;

Sajnos ezek igen idegesítő hibák, remélem valahogy meg lehet majd őket kerülni, vagy ha nem, akkor hamar kijavítják.

UPDATE: visszaigazolt bug: 7332018: FORUMS: PROCEDURE ARGUMENTS NEED TO MATCH VARIABLE NAMES IN CASE.

OMWB - Probléma a nagy 'L' betűkkel

2008-08-12T14:55:00.004+02:00

Találtam egy remek blogot a Migration Workbench-ről, ahol csomó ismert problémán kívül szerepel egy rövid leírás, hogy milyen lépések mentén célszerű a migrációt elvégezni. Ezt végignyomkodtam, csak próbaképp, hogy lássam, mennyire működőképes.

Miután lefutott (kb. 2-3 óra alatt) meglepődve tapasztaltam, hogy az összes nagy 'L' betűt, ami valamilyen azonosítóban (táblanév, oszlopnév, stb) szerepelt, eltűntette. Tehát pl.: az FX_Leg táblából FX_eg lett, a LoginCount oszlopnévből oginCount..

Erről nyitottam is egy fórum-topicot az OTN-en, de közben elkezdtem én is nézni, hogy mi lehet a gond.

A migráció elején, amikor létrehozzuk a repository-t (Associate Migration Repository), létrejön egy MIGRATION_TRANSFORMER nevű PL/SQL package, aminek az elején szerepel egy konstans:

C_DISALLOWED_CHARS CONSTANT NVARCHAR2(100) := ' #.@`!"%^&*()-+=[]{};:,.<>?/~''L';

Hogy miért került a felsorolás végére a nagy L betű, nem tudom. Mindenesetre, ha kiszedem onnan, és újrafordítom a csomagot, már működik :)

UPDATE: visszaigazolt hiba: We saw the English pound symbol problem, we now define the character as:

C_DISALLOWED_CHARS CONSTANT NVARCHAR2(100) := ' #.@`!"%^&*()-+=[]{};:,.<>?/~'''||UNISTR('\00A3');

Oracle SQL Developer Migration Workbench

2008-08-06T19:28:00.006+02:00

Egyik előző bejegyzésben már írtam, hogy a migrációhoz igen nagy segítséget jelent az SQL Developer Migration Workbench része (dokumentáció itt). Van egy ún. Translation Scratch Editor része, ami két panelből áll, egyikbe beírja az ember a Transact-SQL kódot, és egy gombnyomásra megjelenik a másik oldalon a PL/SQL változata. Meglepő, de a generált kód igen nagy százalékban működik, és helyes! :)

Eddig két tipikus esetet találtunk, amikor valami bug miatt mégsem jó kódot generál. Az egyik paraméterkezeléssel kapcsolatos, a másik a T-SQL-ben létező INSERT INTO ... EXEC szerkezet átalakításával.

Az SQL Server megengedi, hogy a bemenő paramétereket mezei változóként használjunk, azaz a lenti kód helyes:

CREATE PROCEDURE foo (@dummy int = null)
AS
begin
select @dummy = 5
end

PL/SQL-ben viszont bemenő paraméter nem szerepelhet értékadás bal oldalán. A konvertáló ezt a kódot helyesen az alábbira alakítja át:

CREATE OR REPLACE PROCEDURE foo
(
iv_dummy IN NUMBER DEFAULT NULL
)
AS
v_dummy NUMBER(10,0) := iv_dummy;
BEGIN
v_dummy := 5;

END;

Azaz létrehoz egy változót is, aminek kezdeti értékül a paraméter értékét adja. Ez teljesen jó.

Viszont abban az esetben, ha az értékadást nem SELECT, hanem a SET operátorral végezzük:

CREATE PROCEDURE foo (@dummy int = null)
AS
begin
set @dummy = 5
end

már nem veszi észre, hogy valójában egy paraméterről van szó, és egy az egyben átfordítja:

CREATE OR REPLACE PROCEDURE foo
(
v_dummy IN NUMBER DEFAULT NULL
)
AS
BEGIN
v_dummy := 5;

END;

Ez a kód természetesen nem fordul le.

A másik hiba akkor fordul elő, ha T-SQL-ben meglévő INSERT INTO...EXEC struktúrát próbálja átalakítani. T-SQL-ben lehetőség van arra, hogy egy táblába szúrjuk bele egy tárolt eljárás által visszaadott eredményhalmazt (ugyanis T-SQL tárolt eljárás képes eredményhalmazokkal is visszatérni, nem úgy, mint a PL/SQL eljárások). Az alábbi T-SQL kódot:

CREATE PROCEDURE foo
AS
begin
insert into sometable (foobar)
exec sp_something
end

erre fordítja át:

CREATE OR REPLACE PROCEDURE foo
AS
v_temp SOMETABLE%ROWTYPE;
BEGIN
sp_something();
LOOP
FETCH cv_1 INTO v_temp;
EXIT WHEN cv_1%NOTFOUND;
INSERT INTO sometable VALUES v_temp;
END LOOP;
CLOSE cv_1;

END;

Maga a logika teljesen jó lenne: a tárolt eljárás egy kurzorváltozóval tér vissza, amin végigmenve egyesével beszúrjuk a sorokat a táblába. A bökkenő csak az, hogy nem deklarálja a cv_1 kurzorváltozót, így a fenti kód szintén nem fordul.

UPDATE: visszaigazolt bug No: 7335256 FORUMS: INSERT INTO .. EXEC PROCEDURE HAS UNDECLARED VARIABLES.

Ezek a hibák természetesen nem vészesek akkor, ha valaki csak pár eljárást szeretne átkonvertálni. Viszont akkor, ha több ezerről lenne szó, akkor már bosszantóak, ugyanis így nehézkes automatizálni.

Kulcsszavak mint oszlopnevek Oracle alatt

2008-08-06T10:27:00.004+02:00

A migráció kapcsán rögtön belefutottunk egy érdekes problémába: SQL Server oldalon több olyan oszlopnevet is használunk, ami Oracle alatt kulcsszó vagy fenntartott szó: name, text, comment, date, number, stb.

Úgy gondoltuk, hogy ha ezeket az oszlopneveket nagybetűsen és ""-k között hozzuk létre (és így is hivatkozunk rájuk) akkor működhet. A táblák létre is jöttek, viszont több esetben egyéb gondok léptek fel. Pl.:

CREATE TABLE asdf (
"DATE" date
);

Select * from asdf;

Ez tökéletesen lefut, viszont:

declare
v_temp number;
begin

select 1 into v_temp from dual where exists (select 1 from asdf);
end;

ez már nem:

ORA-06550: line 5, column 61:
PL/SQL: ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-320: the declaration of the type of this expression is incomplete or malformed
ORA-06550: line 5, column 2:

Gondoltuk, hogy baj van, akkor át kell nevezni az oszlopokat. Elkezdtem próbálkozni, hogy milyen kulcsszavakkal van még gond, és nem az összes reserved word-del van baja:

CREATE TABLE asdf (
"AUDIT" date
);

Elvileg az audit is reserved word mégsem fut hibára a fenti kódrészlet.

A következő gondolat az volt, hogy a típusnevekkel van csak gondja, de ez sem teljesen igaz, ugyanis a lenti esetben:

CREATE TABLE asdf (
"DATE" int
);

Szintén hiba nélkül lefut a PL/SQL kód, ellenben, ha "NUMBER" int van (tehát nem "NUMBER" number), akkor megint csak az említett hibára fut.

Maradt még egy utolsó kombináció, méghozzá a kulcsszavak kisbetűsen, ""-k között:

CREATE TABLE asdf (
"number" number
);

Így jelenleg minden (date, number, stb.) működik. Egyelőre. Már csak az a költői kérdés maradt hátra, hogy ebben így mi a logika?

Migráció Microsoft SQL Serverről Oracle adatbázisra

2008-08-03T21:23:00.003+02:00

Munkahelyemen elkezdődött a puhatolózás, hogy miből állna egy migráció SQL Serverről Oracle adatbázisra. Ebben nagy segítség az Oracle SQL Developer Migration Workbench-je, valamint a Migrating Applications from Microsoft SQL Server to Oracle9i Database című white paper, amiben részletesen ki van fejtve jópár szintaktikai és szemléletmódbeli különbség is. Ezen az oldalon is fel van sorolva néhány :)

Mivel az üzleti logika jelentős része Transact-SQL tárolt eljárások formájában van megvalósítva, ezért talán az egyik legnagyobb feladat ezek PL/SQL-re konvertálása lesz. A Migration Workbench része egy scratch editor, amiben kb. gombnyomásra lehet az egyszerűbb (és nem SQL Server specifikus) kódokat átkonvertálni, több kevesebb sikerrel. Sajnos vannak még hibái, de mindenesetre nagyon ígéretes! Szerintem nem fogunk unatkozni az elkövetkezendő hónapokban :)

Új kinézet

2008-08-03T21:19:00.002+02:00

Lecseréltem a blog alatti template-et, hogy picit kultúráltabb legyen a kinézete :) Remélem úgy sikerült, hogy nem ment a funkcionalitás rovására.

Dimenzionális modellezés - bevezetés

2008-08-02T21:55:00.006+02:00

Tény táblák

A tény táblák (fact tables) a dimenzionális modellezés központi elemei: ezek azok a táblák, ahol az adott üzleti folyamat számszerű mértékei szerepelnek. Például egy üzletlánc napi eladásait reprezentáló táblában ez a mérték lehet az eladott mennyiség, vagy az értük kapott pénzösszeg. Minden nap, bármelyik boltban bármelyik termék értékesítésre kerül, készül egy bejegyzés is. A dimenziók ezen listája határozza meg a tény tábla finomságát, felbontását.

Egy adattárház szempontjából a leghasznosabb mértékek számszerűek és összeadhatóak, mivel igen ritka az az eset, amikor egyetlen sorra kiváncsi a felhasználó a tény táblából. Éppen ellenkezőleg, általában a sorok százezreinek az aggregált értékére kiváncsi (az elmúlt hónapban eladott termékek mennyisége, bevétel, stb.). A fenti példában az eladott mennyiség és a pénzösszeg is összeadható bármelyik dimenzió mentén.

Nem minden tényadat összeadható, léteznek részlegesen összeadható (semiadditive) mértékek, amelyeket csak bizonyos dimenziók mentén lehet összeadni, és nem összeadható mértékek is. Például egy raktárkészlet aktuális állapotát vagy számlák aktuális egyenlegét reprezentáló tény táblák tipikusan ilyen részlegesen összeadható adatokat tartalmaznak, ugyanis értelmes összeadni a számlaegyenlegeket például ügyfelek szerint, de értelmetlen az idő szerint. Ilyen esetekben a legcélszerűbb megközelítés az átlagolás: az adott periódusra szóló átlag-egyenleg, vagy átlagos raktárkészlet.

Dimenziók

A dimenziók a tény táblák kísérői. Ezek a táblák tartalmazzák a szöveges leírásait az adott üzleti folyamatnak. Egy jól megtervezett dimenzionális modellben egy dimenzió táblának lehető legmagasabb számú oszlopa vagy másnéven attribútuma van, ugyanis ezek az attribútumok játszanak a lekérdezéseknél, elemzéseknél csoportosító, megszorító, vagy magyarázó szerepeket. Emiatt létfontosságú, hogy minél több jól definiált, értelmes dimenzió attribútum legyen, mert ezek határozzák meg az adattárház használhatóságát. A dimenziók jelentik az interfészt az adattárház és a felhasználó között.

Míg a tény adatok főleg számszerűek és folytonos értékkészletűek, addig a dimenzió attribútumok általában szövegesek, és diszkrétek.

A dimenziók sokszor hierarchikus kapcsolatot reprezentálnak. Például egy termék egy adott márkához tartozik, amiket kategóriákba sorolunk, és így tovább. A termék dimenzió táblában minden sorban (minden termékre) eltároljuk az adott termék márkáját és a kategória szöveges jellemzését is. Ez épp ellentétes egy normalizált adatbázissal, ugyanis rengeteg redundáns információt tartalmaz. A dimenzió táblák tipikusan denormalizáltak (kivéve snowflake séma esetében), a performancia és az egyszerűség, könnyen érthetőség érdekében feláldozzák a szükséges tárhely mennyiségét.

Adattárház rendszerek összehasonlító elemzése

2008-07-19T16:36:00.002+02:00

Ma a neten böngészgetve a SZTAKI oldaláról eljutottam Sidló Csaba honlapjáig, ahol fent van a diplomamunkája is, melynek témája az adattárházak összefoglaló jellegű, általános bemutatása, valamint az Oracle és az SAP adattárház megoldásainak összehasonlítása.

A tartalomjegyzéket átfutva biztos vagyok benne, hogy hasznos olvasmány a téma iránt érdeklődők számára!

BIC2G és MS SQL Server

2008-07-06T16:03:00.004+02:00

Ma ismét nekifutottam, hogy rávegyem az Oracle BI Server-t, hogy ugyan csatlakozzon már az én kis Microsoft SQL Server 2000-emhez, ugyanis ezt eddig még sehogy sem sikerült elérnem. A legnagyobb gondom az volt, hogy nem találtam olyan ODBC driver-t, amivel csatlakozni is lehet, és még a BIEE is szereti. Egész egyszerűen azért nem találtam, mert azt sem tudtam, hogy hol keressem.. Van ugyanis egy odbc.ini a /ora/biee/10.1.3.2/OracleBI/setup könyvtárban, de nem tudtam, hogy mit írjak a Driver=/ora/biee/10.1.3.2/OracleBI/server/Bin/libnqsodbc.so sor helyére.

Mivel tegnap sikerült az adatbázis szerverből csatlakozni a hs segítségével, gondoltam kipróbálom a FreeTDS driverét:

[ODBC Data Sources]
AnalyticsWeb=Oracle BI Server
Cluster=Oracle BI Server
SSL_Sample=Oracle BI Server
InFoRex=InFoRex Source

[InFoRex]
Driver=/usr/local/lib/libtdsodbc.so
Server=192.168.1.100
Description=InFoRex Data Source
UID=sa
PWD=sa
Database=InFoRex
Port=1433
TDS_Version=8.0

És láss csodát:

Nem csalás, nem ámítás, a Profiler-ből látszódik, valóban az SQL Server-ből szedte ki a nevemet :)

Csatlakozás Oracle adatbázisból MS SQL Server-hez Linux alatt

2008-07-05T14:23:00.004+02:00

Előfordulhat, hogy valaki egy Oracle adatbázisból egy másik, külső adatbázis szerverhez szeretne csatlakozni. Például Oracle Warehouse Builder-ben szeretne adatforrásnak SQL Server-t használni. Ennek a megvalósítására számos (1 2 3) leírás létezik, én viszont szerettem volna kicsit komplikálni a szituációt (csesszünk ki magunkkal mozgalom): az Oracle adatbázis Linux alatt fut (VMware image-ben), és ingyenes drivereket szeretnék használni.

Oracle alól ODBC-vel (vagy JDBC-vel) lehet külső szerverekhez kapcsolódni a heterogeneous services segítségével. Tehát először is szükség van egy linuxos ODBC megvalósításra, legyen ez a unixODBC.

unixODBC-vel SQL Server-hez többféle módon is lehet kapcsolódni: vagy használjuk az EasySoft driver-ét (30 napos trial verzió, avagy 500 angol font), vagy FreeTDS segítségével, ami egy ingyenes TDS (Tabular Data Stream) implementáció. Én mindkettőt kipróbáltam, az EasySoft driverével szinte minden ment azonnal, viszont kicsit drága. A unixODBC + FreeTDS kombó habár ingyenes, közel sem annyira triviális a beállítása.

Első lépésben nem árt feltelepíteni mindkettőt:

# wget http://www.unixodbc.org/unixODBC-2.2.12.tar.gz
# tar zxvf unixODBC-2.2.12.tar.gz
# cd unixODBC-2.2.12
# ./configure –-enable-gui=no
# make
# make install
# wget http://ibiblio.org/pub/Linux/ALPHA/freetds/stable/freetds-stable.tgz
# tar zxvf freetds-stable.tgz
# cd freetds-0.82
# ./configure --with-tdsver=8.0 --with-unixodbc=/usr/local
# make
# make install

Ezek után már indulhat a móka, vi-re fel!

# cd /usr/local/etc/
# vi odbcinst.ini

[FreeTDS]
Description = FreeTDS Driver
Driver = /usr/local/lib/libtdsodbc.so
UsageCount = 2
TDS_Version = 8.0

# vi odbc.ini
[Northwind]
Driver = /usr/local/lib/libtdsodbc.so
Description = Northwind DSN
Trace = Yes
# ide fogunk logolni
TraceFile = /tmp/sql.log
ForceTrace = Yes
# az SQL Server IP cime ez
Server = 192.168.1.100
Database = Northwind
Port = 1433
# SQL Server 2000-t hasznalunk
TDS_Version = 8.0

# vi freetds.conf
…
# A typical Microsoft server
[TZ]
host = 192.168.1.100
port = 1433
tds version = 8.0

Akkor teszteljük is le azt, amit eddig műveltünk. Jár a FreeTDS-hez egy tsql nevű utility, ami tökéletesen megfelel diagnosztikai célokra:

# tsql -S TZ -U sa
locale is "en_US.UTF-8"
locale charset is "UTF-8"
Password:
1> select 1
2> go

1
(1 row affected)
1> quit
#

Juhé, a FreeTDS-st sikeresen beállítottuk, nézzük mi a helyzet az ODBC-vel:

# isql -v Northwind sa sa
+---------------------------------------+
| Connected! |
| |
| sql-statement |
| help [tablename] |
| quit |
| |
+---------------------------------------+
SQL> select 1
+------------+
| |
+------------+
| 1 |
+------------+
SQLRowCount returns 1
1 rows fetched
SQL> quit

Ez eddig már fél siker! Most már „csak” az Oracle db-t kell rávenni, hogy csatlakozzon ő is:

# cd $ORACLE_HOME/hs/admin
# vi tnsnames.ora
…
hsodbc =
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)
(HOST=localhost)
(PORT=1521))
(CONNECT_DATA=(SID=hsodbc))
(HS=OK)
)

# vi listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /ora/db/10.2.0)
(PROGRAM = extproc)
)
(SID_DESC=
(SID_NAME=hsodbc)
(ORACLE_HOME=/ora/db/10.2.0)
(PROGRAM=hsodbc)
)
)

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
)
)

HSODBC =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))
(ADDRESS=(PROTOCOL=ipc)(KEY=PNPKEY))
)
)

Ezek után szükség van egy inicializáló fájlra is, aminek a neve init.ora kell, hogy legyen. Ebben a példában inithsodbc.ora:

# vi inithsodbc.ora
# This is a sample agent init file that contains the HS parameters that are
# needed for an ODBC Agent.

#
# HS init parameters
#
HS_FDS_CONNECT_INFO = "DSN=Northwind;UID=sa;PWD=sa"
HS_FDS_SHAREABLE_NAME = /usr/lib/libodbc.so

#
# ODBC specific environment variables
#

#
# Environment variables required for the non-Oracle system
#
#set =

Ennél a pontnál nem tudom pontosan, hogy újra kell-e indítani valamit vagy sem, mindenesetre én újraindítottam az egész gépet :)
Jöjjön az utolsó ellenőrzés:

# cd $ORACLE_HOME/bin
# ./tnsping hsodbc

TNS Ping Utility for Linux: Version 10.2.0.3.0 - Production on 05-JUL-2008 07:48:23

Copyright (c) 1997, 2006, Oracle. All rights reserved.

Used parameter files:

Used TNSNAMES adapter to resolve the alias

Attempting to contact (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521)) (CONNECT_DATA= (SID=hsodbc)) (HS=OK))
OK (20 msec)

Ez az OK mondja meg nekünk, hogy jók vagyunk! Akkor hozzuk létre az adatbázis linket, lépjünk be a kedvenc SQL konzolunkba:

# sqlplus tz@orcl
SQL*Plus: Release 10.2.0.3.0 - Production on Sat Jul 5 07:52:29 2008

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

Enter password:

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining Scoring Engine options

SQL> CREATE DATABASE LINK HSTEST CONNECT TO sa IDENTIFIED BY sa USING 'HSODBC';

Database link created.

SQL> SELECT COUNT(*) FROM Customers@hstest;

COUNT(*)
----------
91

Ezzel meg is volnánk, mostantól használhatjuk az előbb elkészített linket akár Warehouse Builder-ben, akár máshol.

Oracle szeminárium

2008-05-31T09:01:00.002+02:00

Megjött az Oracle által szervezett "Nagy méretű adattárházak és BI rendszerek fejlesztése és üzemeltetése" című szeminárium sorozat vizsgaeredménye, miszerint sikeres, 70% feletti tesztet írtam. Je \o/
Így most gondban vagyok..

7. féléves prezentáció

2008-05-13T19:54:00.002+02:00

Elkészítettem a 7. féléves önálló laborhoz tartozó szóbeli prezentációt. Remélem bele fogok férni az 5 percbe..

Költöztetés

2008-05-04T14:14:00.004+02:00

Mint már írtam, az Oracle termékei erőforrás-igényesek. Ezen a hosszú hétvégén "telt be a pohár", ugyanis a VMware-ben futó BIC2G (ami egy Oracle Enterprise Linux + Oracle DB + BIEE Server + sok egyéb..), az XP-n futó SQL Server és a Warehouse Builder olyannyira leterhelte szegény notebook-ot, hogy egy kattintás eredményére másodperceket kellett várni. Igen, 2 GB RAM és 2 magos Intel processzor az gyenge.

Ezért a desktop PC-mre átraktam a VMware-t, és hálózaton keresztül csatlakozok hozzá a notebookról. A PC-n Ubuntu fut, és habár többeknek problémát okozott Hardy-n VMware telepítése, nekem pár apró trükk, patch után szépen elindult.

Az egyetlen bosszantó apróság az volt, hogy lejárt az Easysoft ODBC driverem licensze, amivel az SQL Server-hez kapcsolódok, ezért igényeltem még egy 30 naposat, ugyanis az 500 fontos árat picit sokalltam.. :)

7. féléves összefoglaló

2008-05-01T17:17:00.002+02:00

Mivel én ebben a félévben csinálom a 7. féléves (2 kredites) önálló labor tárgyat is, ezért el kellett készítenem a hozzá tartozó összefoglaló dokumentumot is, ami ezen a címen érhető el.

A screenshot magyarázata

2008-05-01T17:15:00.003+02:00

Az előző screenshot lényege, hogy három különböző felületen is megjelenik ugyanaz a szám: 10502. Hogy ez miért érdekes? Az 10502 a megkötött ügyletek darabszámát jelenti.

Az ábra jobb oldaláról haladva: legszélén egy Microsoft SQL Server Management Studio látható, amiben a forrásadatbázisnak intézet SQL lekérdezés eredménye a darabszám.

Ezt követően Oracle Warehouse Builderrel egyszerűen átvittem az ügyleteknek két attribútumát: az azonosítót (ticket) és az ügyfélazonosítót (customer). Még nem végeztem semmiféle transzformációt, ellenőrzést (pl.: csak a már jóváhagyott de még nem törölt ügyletek az érdekesek). Így tehát a komplett tábla átkerült egy Oracle adatbázisba, amihez a screenshot közepén levő Oracle SQL Developerrel csatlakoztam. És láss csodát! Ott is megjelent az 10502 :)

Ahhoz, hogy a Warehouse Builderrel ezt el tudjam végezni, rá kellett bírni az Oracle szervert, hogy csatlakozzon az SQL Server-hez. Mivel az Oracle adatbázis szerver Linux alatt fut nálam (Oracle Enterprise Linux), ezért ehhez az Easysoft ODBC driver-ét telepítettem.

Miután átkerültek az adatok az Oracle adatbázis szerverére, az Oracle BI Administration Tool segítségével összeállítottam egy igen egyszerű "üzleti" fogalmat a BIEE szerveren: ügyletek darabszáma (# of deals).

Majd az Oracle Answers felületen összekattintgattam az ábra bal oldalán szereplő primitív Dashboard-ot.

Az egésznek a lényege mindösszesen annyi volt, hogy megteremtettem egy "csővezetéket" egy forrás-adatbázis és a végfelhasználó előtti felület, az Oracle Dashboard között.

És igen!

2008-04-20T13:03:00.005+02:00

Több napos próbálkozások után végre elértem ezt:

a következő post-ban részletesen leírom majd, hogy ez miért nagy szám, illetve, hogy mi is ez:)

(és igen, az Oracle szoftverei erőforrásigényesek. Nagyon.)

CDC III. – szinkron vs. aszinkron módok

2008-04-05T14:59:00.000+02:00

Szinkron CDC

Szinkron CDC-nél a forrás-táblákra elhelyezett DML triggerek segítségével lehet a változásokat nyomon követni. Emiatt a változások azonnal bekerülnek a change table-be, amint a tranzakciók befejeződtek. Ennek megfelelően a CDC-ből adódó extra terhelés a forrás-adatbázist súlytja (triggerek végrehajtási ideje + a change table-k is a forrás-adatbázisban helyezkednek el).

Ennél a módnál csak egy előre definiált change source létezik: SYNC_SOURCE, ezt nem lehet megváltoztatni, vagy letörölni.

Aszinkron CDC

Az aszinkron CDC a forrás-adatbázis redo log file-jaiból szerzi meg a megváltozott adatokat, ezért a loggolás miatti terhelés a forrás-adatbázist terheli.

Aszinkron HotLog

Aszinkron HotLog módban az on-line redo log file-ból lehet a változásokat kigyűjteni, kis késéssel a tranzakciók jóváhagyása után. A change table-k a forrás-adatbázisban kell, hogy elhelyezkedjenek.

A loggoló processz (Logwriter process, LGWR) feljegyzéseit a CDC az Oracle Streams technológia segítségével dolgozza fel.

Ennél a módnál is csak egyetlen, előre definiált change source létezik: HOTLOG_SOURCE.

Aszinkron Distributed HotLog

Elosztott HotLog módban a CDC tevékenységek fel lettek osztva a forrás-adatbázis és a staging adatbázis között: a change source-ok a forrás-adatbázisban definiáltak, míg a change set-ek már a staging adatbázisban, tehát a változásokat tartalmazó change table-k így lehetnek akár más hardveren is, az adatbázis verziója sem kell, hogy megegyezzen. A két rendszer között a kommunikáció az Oracle Net protokollon keresztül zajlik.

Ennél a módnál két publisher beállítása is szükséges: egy a forrás-adatbázison, egy pedig a staging-en.

Aszinkron AutoLog

AutoLog módban a Redo transport services által felügyelt redo log file-okból kerülnek kigyűjtésre a megváltozott adatok. Ez a szolgáltatás automatikusan átmásolja az on-line vagy archivált log fájlokat a forrás-adatbázisból a staging területre, ami lehet egy távoli gépen, viszont a futtatott operációs rendszer és adatbázis verzió meg kell, hogy egyezzen.

A megfelelő mód kiválasztásában az alábbi szempontok fontosak:

A staging terület távoli gépen van-e (Async distr. hotlog, autolog online/archive) vagy sem (sync, async hotlog).
A megengedhető késés a változások létrejötte és a change table-ben való megjelenésük között (szinkrontól aszinkron autolog archive-ig folyamatosan nő)
A forrás-adatbázisra eső extra terhelés (szinkrontól aszinkron autolog archive-ig folyamatosan csökken)
Azonos hardveren/operációs rendszeren fut-e a két adatbázis, azonos-e az Oracle adatbázisok verziója.

CDC II. – termelő-fogyasztó modell

2008-04-05T14:55:00.001+02:00

Az Oracle is a termelő-fogyasztó modell szerint oldja meg a megváltozott adatok kezelését, adattárházba juttatását, PL/SQL csomagokkal megvalósítva: DBMS_CDC_PUBLISH és DBMS_CDC_SUBSCRIBE.

A termelő általában az adatbázis adminisztrátor (DBA), aki létrehozza és karbantartja a CDC-hez szükséges sémaobjektumokat. Egy módot leszámítva (Distributed HotLog) csak egy termelő van.

Az Oracle az alábbi CDC fogalmakat definiálja:

forrás-táblák (source tables): azok a forrás-adatbázisban szereplő táblák, amiknél figyelni akarjuk a változásokat.
redo log file-ok: aszinkron CDC esetén a változásokat a tranzakciós redo log file-ok alapján gyűjti ki a rendszer.
change source: a forrás-adatbázis logikai reprezentációja
change set: a megváltozott adatoknak egy olyan részhalmaza, ami garantáltan konzisztens. Egy vagy több change table-ből áll.
change table: egy olyan tábla, ahová egy adott forrás-táblából a változások kerülnek.

feliratkozás (subscription): egy feliratkozás felügyeli a megváltozott adatokhoz való hozzáférést
feliratkozási ablak (subscription window): a feliratkozási ablak határozza meg a sorok azon halmazát, amit a fogyasztó egy feliratkozási nézetben láthat
feliratkozási nézet (subscription view): a fogyasztó csak azokat az adatokat láthatja, amikre a termelő engedélyt adott.

A CDC az alábbi előnyöket nyújta:

Garantálja, hogy minden fogyasztó értesül minden változásról.
Egyszerre több fogyasztót képes kezelni, megosztott hozzáférést nyújt a változásokhoz.
Automatikusan eltávolítja a már nem szükséges adatokat egy change table-ből.

Labor prezentáció

2008-04-03T09:57:00.002+02:00

A mai napon egy 15 perces bemutató előadást kell tartanom az önálló labor témámról. Az előadás vázlata itt érhető el.

Oracle Change Data Capture

2008-03-30T14:56:00.002+02:00

Az adattárházakba bizonyos időközönként (tipikusan éjszaka, amikor az OLTP rendszerekre kisebb, vagy épp semmi terhelés jut) be kell tölteni az újonnan keletkezett vagy módosult adatokat. Tehát fontos feladat az új/módosult adatok azonosítása a forrásadatbázisokban. Ennek a megoldásában nyújthat segítséget a CDC (Change Data Capture).

CDC nélkül két féle módon juthatunk hozzá a változott adatokhoz:

Különbségképzés (table differencing): a forrásadatbázisból a tábla teljes tartalmát a staging adatbázisba másoljuk, ahol az SQL MINUS operátorával lekérdezhetjük az újonnan beinsert-ált, illetve update-elt sorokat:

SELECT * FROM new_version

MINUS SELECT * FROM old_version

Vagy, ha a kitörölt sorokra vagyunk kiváncsiak:

SELECT * FROM old _version

MINUS SELECT * FROM new_version

Ennek a megközelítésnek a problémái nyilvánvalóak:

Mivel a tábla teljes tartalmát át kell másolni a két adatbázis között, ez hatalmas overhead-del jár.
Magának a MINUS operátor elvégzésének a számítási költsége is rendkívül nagy.
Nem lehet azonosítani a megváltoztatott, majd az eredeti értékre visszaállított adatokat.
Nem lehet megállapítani, hogy milyen változtatások történtek egy tranzakción belül.

Change-value selection: egy, a forrástáblában levő speciális oszlop segítségével csak az előző betöltés óta megváltozott/újonnan létrehozott sorokat választjuk ki. Egy ilyen oszlop tipikusan valamilyen időpontot tárol, pl.: LAST_UPDATE_DATE.

Ezzel a következő problémák vannak:

A megváltozott adatok azonosításával járó overhead a forrásadatbázist terheli.
Ezzel a módszerrel sem lehet megállapítani, hogy milyen változtatások történtek egy tranzakcióban.
A change-value alapján történő felosztás finomsága nem feltétlen megfelelő: például, ha másodperc finomságú, és az előző kinyerés mondjuk 10:15:33-kor történt, akkor a következő kinyeréskor a 10:15:33 utáni rekordokat fogjuk csak kiválasztani. Tehát ha ugyanabban a másodpercben történt módosítás, akkor az el fog veszni.
Gyakorlati szempontból talán a legnagyobb hátrány az, hogy a kinyerő mechanizmust figyelembe véve kell megtervezni a forrástáblákat is, amik legtöbbször 3rd party adatbázisokban szerepelnek.

Megváltozott adatok kinyerése CDC-vel

Az Oracle CDC másfajta megközelítést követ: az INSERT, UPDATE, és DELETE utasítások következtében beállt változásokat rögzíti egy ún. change-table-ben, amiket utána ellenőrzött módon bocsát az alkalmazások számára.

A CDC-t két különböző módon lehet használni:

Szinkron: a forrástáblákra elhelyezett triggerek segítségével a DML utasítások eredményét a módosítás tranzakciójának részeként rögzíti.
Aszinkron: az elcommit-ált módosításokat tartalmazó redo log file alapján nyeri ki a módosult adatokat. Aszinkron módon háromféleképpen lehet a CDC-t megvalósítani: HotLog, Distributed HotLog, AutoLog.

Ezekről a módokról a későbbiekben részletesen be fogok számolni.

Forrás: Oracle Data Warehousing Guide

Adattárházak

2008-03-18T20:13:00.007+01:00

"Az adattárház lekérdezésekre és analízisre optimalizált adatbázis." Ezt a tömör definíciót kifejtve az alábbiakat lehetne mondani:

Egy vagy több különböző, általában OLTP (on-line transaction processing) rendszerben különböző (általában tranzakciós) adatok keletkeznek, ezek a rendszerek vagy egymástól függetlenül, vagy integráltan működhetnek, egymás között adatokat cserélhetnek.

Ezekből az adatforrásokból ún. ETL (Extraction-(Transportation)-Transformation-Loading) folyamat segítségével egy adattárházat táplálunk. Az Extraction folyamat során a szükséges adatokat a forrásadatbázisokban azonosítjuk, kinyerjük. A kinyert adatokat a célrendszerbe vagy egy átmeneti rendszerbe (staging area) szállítjuk (Transportation), ahol feldolgozzuk, konzisztens formára hozzuk (Transformation). A Loading a feldolgozott adatok adattárházba töltését takarja. Fontos megérteni, hogy az ETL egy átfogó folyamatot takar, nem pedig egy jól meghatározott lépéssorozatot.

A cél az, hogy elsősorban üzleti felhasználók számára összesített, konszolidált formában egységes képet tudjunk adni a rendszerekben található adatok (a vállalat) egészéről.

Az ábrán egy lehetséges adattárház-architektúra szerepel: a forrásokból származó adatokat először egy ún. staging area-ba töltjük előfeldolgozás, tisztítás céljából (a staging area nem szükségszerűen része egy adattárháznak). Az adattárházaknak fontos részei az összesítések (Summaries), amiket az Oracle materializált nézeteknek hív. Az összesítések időigényes aggregálások, számítások előre letárolt eredményei. Végül az adatokat csoportosíthatjuk akár részlegek szerint is: specifikus adattárházakat (data marts) építhetünk a „fő” adattárházunkból.

Az adattárházaknak négy fontos tulajdonságuk van:

téma-orientált: egy vállalatot több szervezeti egységre oszthatunk, melyek döntéshozóinak más és más adatokra van szükségük az adott területet vagy a vállalat egészét érintő döntések meghozatalához
Vállalati szinten integrált: az adattárházakba különböző heterogén forrásokból kerülnek be az adatok, melyeket ahhoz, hogy egyetlen, konzisztens képet tudjanak adni a vállalat egészéről transzformálni, konvertálni kell.
El nem tűnő: szemben a tranzakciós rendszerekkel, ahol az adatok módosítása, törlése mindennapi művelet, az adattárházakban levő adatok a betöltés után csupán lekérdezhetőek.
Időben változó: minden adattárházban szereplő adat az időnek egy adott pillanatában érvényes

Fontos kihangsúlyozni, hogy végső soron az adattárházak felhasználói nem IT-s emberek, hanem általában controllerek, managerek, vezetők, ezért olyan technológiákra is szükség van, amik az adattárházakban levő információkat emészthető formában képesek „tálalni”, ad-hoc módon lekérdezhetővé teszik, azokból jelentéseket, riasztásokat képesek generálni, összefoglalva: az üzleti döntések meghozatalát támogatják.

Forrás: Oracle Data Warehousing Guide

Tavasz

2008-03-07T20:42:00.003+01:00

Megkésve bár, de újult erővel én is ismét belevetem magam az Oracle technológiák gyönyöreibe :)

Tavaly decemberben abban maradtam Kardkovács Zsolttal, hogy a 2 kredites önálló labor tárgyat akkor nem teljesítem, hanem ebben a félévben a 8 kredites rendszertervezés mellett fogom azt is.

A rendszertervezés izgalmasnak ígérkezik, ugyanis mind a konzulensek, mind a kollégáim, és én is igen csak hajlok afelé, hogy összekössem a labortémámat a munkámmal: a cégnél fejlesztett szoftvert mint adatforrást felhasználva egy BI rendszert "fölé" tervezni, megvalósítani.

A következő hét végéig terveim szerint körvonalazódni fog a megvalósítandó feladat, a cél, addig is megpróbálok minél több ismeretet összeszedni az Oracle Data Integratorról, és erről a blogon be is számolnék.

Külön jó, hogy most tavasszal az Oracle Szemináriumsorozat témája is a nagyméretű adattárházak és BI rendszerek. Kíváncsian várom, hogy milyen lesz, habár a most csütörtöki számomra egy picit csalódás volt (nagyon semmitmondó volt az előadás).

Összefoglalás

2007-12-06T12:22:00.000+01:00

Elkészült a két szükséges dokumentáció, ami a féléves munkámat tartalmazza. Sajnos az időhiány nagy úr, egyéb elfoglaltságaim (lakásvásárlás, munka) miatt közel sem sikerült olyan részletességgel feldolgozni a témát, mint ahogy azt eredetileg terveztem.

A tárgyfelelősnek készült dokumentum itt, a konzulenseknek készült pedig itt található.

BI Publisher

2007-12-02T18:45:00.000+01:00

Ebben a bejegyzésben az Oracle BI Publisher programjáról szerettem volna írni, de egy rejtélyes hiba ezt meghiúsította: egyszer már kipróbáltam (két kattintás erejéig) a Publisher-t, de mostanra a Microsoft Word-ből eltűnt a menüpontja.

Az újratelepítés részben segített, a menüpont visszakerült a helyére, de a Log On menüpontra kattintva az alábbi hibaüzenet fogad:

A Word súgója szerint ennek az lehet az oka, hogy egy szükséges DLL nincs regisztrálva. Az interneten rákeresve a hibaüzenetre, úgy tűnik, nem vagyok egyedül:

http://forums.oracle.com/forums/thread.jspa?messageID=2195944

ahol egy hozzászóló ad is megoldást: Uninstalled everything including .net runtime, bip, word. Ehhez nekem most nincs időm/kedvem :)

A BI Publisher amúgy egy olyan eszköz lenne, amivel rendkívül rugalmas módon, többféle formátumban, többféle adatforrást felhasználva lehet sablon alapú jelentéseket készíteni. A képernyőmentésen jól látható módon a Microsoft Word-be integráltan lehetne használni, már amikor működik :)

Oracle Delivers

2007-11-18T17:54:00.000+01:00

Az Oracle Delivers egy olyan eszköz, aminek a segítségével bizonyos feltételek teljesülése esetén adott tartalmú üzeneteket lehet eljuttatni a címzetteknek.

A feltétel lehet időbeli – minden héten hétfőn reggel 7:30-kor – vagy logikai jellegű. Az időbeli feltételeket a Scheduler kezeli, a megadott időpontokban elindítja az iBot-nak nevezett „programokat”. Segítségével be lehet állítani, hogy mikortól kezdve hány órakor, milyen gyakorisággal (egyszeri, napi, heti, havi) és meddig indítsa el az iBot-ot, azaz mi az iBot élettartama.

Például lehet egy olyan – az Answers felületen összeállított – táblázatunk, amik az eladási statisztikák változásait mutatják havi bontásban. Valós igény lehet az, hogy bizonyos személyek e-mailben megkapják ezeket a táblázatokat, színkódokkal jelezve a kimagaslóan jó/rossz értékeket.

Logikai jellegű feltételek esetén (Conditional iBot) az iBot-hoz egy filtert lehet csatolni. A filterek az Answers felületen összeállított request-ek találatait szűkítik. Egy conditional iBot akkor fut le (akkor tekinthető triggereltnek), ha a request legalább egy találatot ad vissza.

Ennek a gyakorlati alkalmazására példa lehet a romló statisztikák esetén történő figyelmeztetés. Például minden hónap elején lehetőség van arra, hogy figyelmeztetést küldjünk az illetékes manager-eknek, ha valamilyen mutató (pl.: előző hónapban eladott mennyiség) egy adott érték alá csökken.

Az eddig említett lehetőségeken felül arra is mód van, hogy egy iBot bemenő feltétele egy másik iBot futási eredménye legyen (chained iBot). Ezt úgy lehetne gyakorlatiasabban megfogalmazni, hogy ha az első iBot feltétele nem teljesül (a filterrel ellátott request nem ad vissza egyetlen sort sem), akkor nem történik semmi. Ha ez a feltétel teljesül, akkor lefut az első iBot (pl.: e-mail értesítést küld), majd elindít egy másik iBot-ot.

Adattárolás - megjelenítés

2007-10-22T20:02:00.000+02:00

"Az Üzleti intelligencia megoldások magukban foglalják tehát az adattárolási, a valós idejű lekérdezési, analitikai, előrejelzési és adatbányászati eljárások modern formáit."

Ebben a bejegyzésben az adattárolás, adatokhoz való hozzáférés, és a megjelenítés lehetőségeit szeretném bemutatni Oracle Business Intelligence Challenge 2 Go Enterprise Edition (BIC2G) környezetben.

A BIC2G egy előre telepített, konfigurált üzleti intelligencia csomag, számos kulcsra kész példával, amik közül a Sales History-n (SH) keresztül a legegyszerűbb az alapok bemutatása.

A Sales History adatbázis-séma - mint ahogy a neve is mutatja - értékesítési adatokat tartalmaz különféle termékekre vonatkozóan. A példában ezt egy Oracle 10g adatbázis-szerver tárolja, de tetszőleges ODBC vagy XML adatforrást is választhattunk volna. Az adatbázisban a termékeket a PRODUCTS tábla tartalmazza, fontosabb mezők: PROD_ID, PROD_NAME, PROD_CATEGORY, PROD_SUBCATEGORY, ..., az eladási információkat pedig a SALES tábla: PROD_ID, CUST_ID, TIME_ID, QUANTITY_SOLD, AMOUNT_SOLD

A fizikai adattárolás és a megjelenítés közötti kapcsolatot az Oracle BI Administration segédprogram segítségével teremthetjük meg:

Például érdekelhet minket az összes eladott termék darabszáma, vagy a különböző vásárlók száma. Ezeket a fogalmakat az Administration Tool segítségével képezhetjük le az adatbázis megfelelő relációira: SUM(SALES.AMOUNT_SOLD) és COUNT(DISTINCT SALES.CUST_ID).

Vagy egy kicsit összetettebb példa lehet az eladott termékek számának százalékos változása az előző hónaphoz képest:


case    when sum(SALES.AMOUNT_SOLD) <> 0
and (sum(SALES Mago.AMOUNT_SOLD) = 0
or sum(SALES Mago.AMOUNT_SOLD) is null)
and not sum(SALES.AMOUNT_SOLD) is null
then 100.0
when (sum(SALES.AMOUNT_SOLD) = 0
or sum(SALES.AMOUNT_SOLD) is null)
and (sum(SALES Mago.AMOUNT_SOLD) = 0
or sum(SALES Mago.AMOUNT_SOLD) is null)
then 0.0
when sum(SALES Mago.AMOUNT_SOLD) <> 0
and not sum(SALES Mago.AMOUNT_SOLD) is null
and sum(SALES.AMOUNT_SOLD) is null
then -100.0
else (sum(SALES.AMOUNT_SOLD) - sum(SALES Mago.AMOUNT_SOLD))
  * 100.0 / nullif( sum(SALES Mago.AMOUNT_SOLD) , 0)

Az Oracle Answers segítségével reportokat készíthetünk, amiknek az eredményét az interaktív Dashboard felületen tekinthetjük meg: például lekérdezhetjük azon termékeket, amiknek a neve "Mini DV"-vel kezdődik:

Ennél egy fokkal hasznosabb példa lehet az egyes kategóriákban szereplő termékek eladási mennyiségeinek változását egy diagrammon megjeleníteni az elmúlt 12 hónapra vetítve. Ehhez szükségünk van az alábbi megjelenítési rétegbeli fogalmakra: termék kategória (Prod Category), hónap (Calendar Month Name a megjelenítéshez ill. Desc a rendezéshez), eladott mennyiség (Amount Sold), illetve egy szűrőre, ami azt mondja meg, hogy csak az utolsó 12 hónap adataira vagyunk kiváncsiak. Ezt úgy írhatjuk le SQL nyelven, hogy Calendar."Calendar Month Id" between VALUEOF(maxMonthID)-11 and valueof(maxMonthID), ahol a maxMonthID egy ún. Repository Variable, ami az értékét egy függvénytől (Repository Variable Init Block) kapja:

select TIME_ID, CALENDAR_YEAR, CALENDAR_MONTH_DESC, CALENDAR_MONTH_ID from TIMES WHERE TIME_ID = (select max(TIME_ID) from SALES)

, azaz azon legutolsó hónap azonosítója, amire van értékesítési adat (a SALES táblában).

Ezeket az elemeket az Answers felület Criteria részén pillanatok alatt össze tudjuk kattintani:

Megjelenítésnek egy vonalas Chart-ot választva szemléltethetjük a legjobban az eladási statisztikák alakulását:

A különféle chart-ok (Vertical/horizontal bar, bubble, line, pareto, pie, radar, scatter, area) helyett választhatunk akár szöveges táblázatokat is.

Üzleti intelligencia

2007-10-03T20:44:00.001+02:00

,,Az üzleti intelligencia a rend és a tisztánlátás megteremtésén keresztül a megértés és a tudás megszerzésének az eszköze egy vállalaton belül.''

Ezt a definíciót Sipos Ferenc, az IQSYS Informatikai Rt. igazgatója adta a Napi Gazdaság egyik interjújában. Ahhoz, hogy megérthessük ezt az igencsak jól hangzó mondatot, először tisztán kell látni, hogy mi is történik egy vállalaton belül, mik is azok az üzleti folyamatok.

Már Magyarországon is bő 10-15 éve meghatározó szerepe van az informatikának a vállalatok - elsősorban a pénzintézetek - életében. Ma egy cég sem tud versenyképesen működni informatika nélkül, már 1-2 hetes rendszerleállás is komoly (fatális) veszteségeket okoz. Ennek köszönhetően egyre több gyártó készít "üzleti" (business) szoftvereket, amiknek a célja a vállalat folyamatainak irányítása, menedzselése. Vagy nem.

Ugyanis - ahogy Alexander Ryan egy publikációjában rámutat - az informatikában és az üzleti világban az "üzleti folyamat" (business process) mást jelent. Talán a legáltalánosabb tévedés az, amikor a "munkafolyamattal" (workflow) keverik össze, ami egy manuális folyamat automatizálása egy vagy több szoftver segítségével. Például egy pénzügyi rendszerben egy ügylet rögzítésekor, vagy könyveléskor számtalan folyamat indulhat meg a háttérben, amiket az adott program menedzsel.

Ezzel szemben az üzleti folyamat egy adott üzleti cél elérésének érdekében tett összefüggő cselekvések rendezett sorozata. Az üzleti folyamatoknak három típusát különböztethetjük meg:

irányító folyamatok (management processes): azok a folyamatok, amik a cég működését irányítják. Például: stratégiai tervezés, operatív irányítás, pénzügyi menedzsment
alapfolyamatok (operational processes): ezek azok a folyamatok, amik az elsődleges értéket (primary value) állítják elő egy cégen belül. Ilyenek például: beszerzés, termelés, marketing, sales.
támogató folyamatok (support processes): tipikusan az alapfolyamatokat támogatják. Például: IT-support, könyvelés, munkaerő toborzás.

Jelentős különbség a munkafolyamatokkal szemben az, hogy az üzleti folyamatok tipikusan egy magasabb absztrakciós szintet képviselnek.

Itt jön a képbe az üzleti intelligencia (business intelligence) fogalma: Korcsmáros István szerint amikor egy vállalat az üzletmenetük automatizálásán (workflow) túl döntéshozatali eljárásaik (management processes) elősegítése céljából is igénybeveszi az informatikát, akkor már üzleti intelligenciáról beszélhetünk. Ez valójában csak egy része azon területeknek, amikről az üzleti intelligencia szól.

Az ugyanis egy ún. ernyő-fogalom, ami csomó technológiát és megoldást foglal magába. A Controlling Portál az alábbi definíciót adja: ,,olyan alkalmazások és technológiák, amik a szükséges adatokhoz való hozzáférés biztosításával, ezen adatok megfelelő tárolásával, valamint sokoldalú elemzési lehetőségekkel támogatják a vállalati döntéshozatalt. Az Üzleti intelligencia megoldások magukban foglalják tehát az adattárolási, a valós idejű lekérdezési, analitikai, előrejelzési és adatbányászati eljárások modern formáit.''

Az elkövetkezendő félévben ezeket a megoldásokat fogom részletesebben megvizsgálni, elsősorban az Oracle által készített (vagy felvásárolt) termékekre koncentrálva.

Kapcsolódó linkek:

Bemutatkozás

2007-09-26T19:54:00.000+02:00

Ez a blog elsősorban abból a célból jött létre, hogy a BME-n tartott önálló labor című tárgy kapcsán lehetőség legyen az on-line kapcsolattartásra, információ-áramlásra a konzulensek (Kardkovács Zsolt (BME), Sárecz Lajos (Oracle) és Fekete Zoltán (Oracle)) és köztem.

Ennek "mellékhatásaként" viszont remélhetőleg egy olyan magyar nyelvű forrás jöhet létre, amit más - a téma iránt érdeklődő - is hasznosnak találhat.