2008. március 5., szerda

Architektúra part #4 – Séma objektumok (1/2)

Sémának (Schema) nevezzük az egy felhasználóhoz tartozó logikai adatstruktúrák (séma objektumok) összességét. Ezek az objektumok nem feleltethetőek meg egy az egyben fizikai diszken tárolt fájloknak. Logikailag egy objektum egy tablespacen belül helyezkedik el, fizikailag azonban tárolódhat akár több datafileban is. A sémák és tablespacek között nincs semmilyen összefüggés: egy tablespace tartalmazhat objektumokat több különböző sémából, illetve egy séma objektumai is tárolódhatnak különböző tablespacekben (ábra).

Az alábbi objektumok tartoznak a séma objektumok közé:
klaszterek; kényszerek; adatbázis hivatkozások; adatbázis triggerek; dimenziók; külső eljáráskönyvtárak; indexek és indextípusok; Java osztályok; materializált nézetek és a hozzájuk tartozó logok; objektum táblák, objektum típusok és objektum nézetek; operátorok; szekvenciák; tárolt függvények, eljárások és csomagok; szinonimák; táblák és indexelt táblák; nézetek.
Nem tartoznak séma alá a következő objektumok:
kontextusok; könyvtárak; paraméter fájlok (PFILEs) és szerver paraméter fájlok (SPFILEs); profilok; szerepek; rollback szegmensek; tablespacek; felhasználók.

Táblák (Tables):
A táblák jelentik az Oracle adatbázisban az alapvető adattárolási egységet. Alapvető tulajdonságainak részletes ismertetése itt.
Tárolása: a tábla létrehozásakor automatikusan lefoglalunk neki egy adatszegmenst a tablespacen belül. Ennek vezérlésére használhatjuk a már ismertetett PCTFREE és PCTUSED paramétereket, vagy beállíthatjuk az adatszegmens tárolási paramétereit. Klaszter használata esetén nincs lehetőség külön táblánként tárolási paramétereket állítani, hanem csak egységesen, az klaszter összes táblájára vonatkozóan állíthatjuk be őket.
Sorok formátuma és mérete: ha egy sor 256 oszlopnál kevesebbet tartalmaz, s adatai elférnek egy adatblokkban, akkor az adatbázis a sort egy adatblokkon belül, egy darabban tárolja. Azonban ha a sor adatai méretüknél fogva nem tehetőek be egy adatblokkba, vagy a sor legalább 256 oszlopból áll, akkor több adatblokkra van szükség a tároláshoz. Ezt láncolásnak nevezzük -- a további adatblokkok ROWID-jét a sor headerjében tároljuk (ábra).
ROWID: azonosítja az egyes sordarabokat helyük vagy címük alapján. Érdemes hivatkozni rájuk SQL utasításokban, hiszen értékük sosem változik meg.
Oszlopsorrend: tárolási szempontból általában megegyezik a tábla létrehozásakor megadott oszlopsorrenddel (kivétel pl. ha LONG típust használunk, ugyanis azt az adatbázis mindig utolsó oszlopként tárolja -- illetve újonnan felvett oszlopok is mindig hátra kerülnek), ezért célszerű a gyakran NULL értéket felvevő oszlopokat a sorrendben hátulra tenni, mivel így (ha nincs LONG típusunk deklarálva) jelentős mennyiségű helyet takaríthatunk meg.
Táblák tömörítése: az egy blokkon belül többször előforduló adatokat nem tároljuk el külön-külön többször, hanem csak egyszer a blokk elején (egy ún. szimbólum táblában), s a későbbi előfordulások alkalmával csak egy hivatkozást illesztünk be a szimbólum tábla megfelelő elemére. A tömörítés nem jelent semmilyen funkcionalitásbeli hátrányt, s a LOB (Long OBject) típusokon kívül minden más típussal működik. A törlés (DELETE) és beillesztés (INSERT) sem kerül több időbe, mint a tömörítés nélkül tárolt tábláknál. Egyedül az adatok frissítése (UPDATE) esetén fordulhat elő, hogy a végrehajtás lassabb lesz. Célszerű tehát a tömörítést minden csak olvasható, illetve ritkán változtatandó táblánál használni (mivel csökkenti a használt merevlemezt, memóriát –buffer cache- és gyorsítja a lekérdezés végrehajtást – cserébe azonban csak egy csekély CPU-val fizetünk).
Partícionált táblák: által lehetőség van az adatok kisebb részekre bontására, s ezáltal könnyebb managelésére.
Egymásba ágyazott táblák (Nested tables): egy tábla oszloptípusának megadhatunk egy másik táblát is, ezáltal egymásba ágyazott táblákat is létrehozhatunk. A beágyazott táblát az Oracle adatbázis egy külön táblában tárolja.
Ideiglenes táblák (Temporary tables): nem permanens táblák. Tranzakcióhoz vagy sessionhöz tartozhatnak, így csak azok élettartama alatt léteznek. Mivel az adott tranzakció, ill. session kizárólagos joggal rendelkezik felettük, így zárkezelésre sincs szükség. Ellentétben a permanens táblákkal, számukra csak az első INSERT utasítás kiadását követően foglalunk szegmenst.
Külső táblák (External tables): által lehetőség van külső adatbázisokban található adatokhoz történő hozzáférésre úgy, mintha azok a saját adatbázisunk egy táblájában lennének tárolva. A külső táblák nem tartalmazzák, hogy a külső forrásnál hogyan vannak az adatok tárolva (az adatok transzformálását az Access Driver végzi), csupán azok megjelenítéséért felelősek. Természetesen csak olvashatóak, nem rendelhetünk hozzájuk indexeket, s a virtuális oszlopok sem támogatottak.

Nézetek (Views):
A nézetek olyan virtuális táblák, melyek adataikat egy vagy több fizikai táblából, vagy más nézetekből veszik. Fő feladatuk tehát az adatoknak egy előre megszabott formában történő megjelenítése, s ezáltal bizonyos adatok elrejtése. Működésük és a rajtuk végrehajtható műveletek többé-kevésbé megegyeznek a tábláknál megszokottakkal.
Tárolás: mivel a nézetek csak egy lekérdezés által definiáltak, s nem tartalmaznak ténylegesen adatokat, ezért tárolási helyet sem kell biztosítani a számukra. Csupán magát a lekérdezést tároljuk el a data dictionaryben.
Felhasználás: tábla bizonyos sorainak vagy oszlopainak rejtése; adat komplexitás elrejtése; egyszerűbb lekérdezések megfogalmazása; többféle adat megjelenítés; alkalmazások függetlenítése az alap táblákon végrehajtott változtatásoktól.
Működés:

  • A nézetre történő hivatkozás helyére behelyettesítődik a nézet által definiált lekérdezés.
  • Szintaktikai elemzést hajt végre az így kialakult utasításon.
  • Végrehajtja az utasítást.


Updatable Join Views: két vagy több táblából vagy nézetből származtatott nézet, melyen engedélyezettek az UPDATE, INSERT és DELETE műveletek. Az adatszótár (data dictionary) ALL_UPDATABLE_COLUMNS, DBA_UPDATABLE_COLUMNS és USER_UPDATABLE_COLUMNS nézetei tartalmazzák, hogy a nézet mely oszlopai frissíthetőek (UPDATEelhetőek). Ennek feltétele, hogy a nézet ne tartalmazza a következő struktúrák egyikét sem: halmaz operátorok; DISTINCT operátor; aggregátumok és analitikus funkciók; GROUP BY, ORDER BY, CONNECT BY és START WITH klauzulák; kollekciós kifejezés vagy allekérdezés a SELECT után; illesztések (néhány kivételtől eltekintve). A nem frissíthető nézeteket INSTEAD OF triggerek használatával módosíthatjuk.
Object Views: objektum nézetekből kinyerhetjük, frissíthetjük, beilleszthetjük és törölhetjük az adatokat pontosan úgy, mintha objektum típusként lennének tárolva.
Inline Views: nem séma objektum, csak egy allekérdezés egy aliasszal.


Materializált Nézetek (Materialized Views):
A materializált nézeteket adatok összegzésére, számítására, replikázására és szétosztására használhatjuk. Ebből kifolyólag főként adattárházaknál (data warehouse), döntéstámogató rendszereknél és elosztott vagy mobil számításoknál használjuk őket. Az optimalizáló (optimizer) automatikusan felismeri, hogy mikor lehet egy kérést materializált nézet segítségével kielégíteni, s automatikusan behelyettesíti azt a lekérdezésbe. Így nem szükséges közvetlen a táblákból vagy nézetekből kinyerni a kívánt adatokat, amivel növelhetjük a teljesítményt. Néhány szempontból tehát a materializált nézetek hasonlítanak az indexekre:

  • tárhelyet fogyasztanak.
  • ha változnak az adatok a master táblájában, akkor frissíteni kell őket.
  • lekérdezések behelyettesítése által növelik az SQL végrehajtások teljesítményét.
  • felhasználók és alkalmazások szempontjából átlátszóak.


Ellentétben azonban az indexekkel, a materializált nézetekhez közvetlenül is hozzáférhetünk egy SELECT utasítással, illetve a frissítés típusának függvényében akár közvetlenül is alkalmazhatunk rajtuk INSERT, UPDATE vagy DELETE műveleteket.
Nézeteken alkalmazott kényszerek: multidimenziós adatok felismerhetősége érdekében lehetőség nézeteken is bizonyos kényszerek megfogalmazására: primary key, unique és referential integrity constrainteket adhatunk meg.
Frissítés: kétféle frissítési eljárás használtható: inkrementális (fast refesh) és teljes. Előbbi esetén a materialized view log vagy a direct loader log tartalmazza a változtatásokat. A frissítés maga történhet azonnal vagy előre meghatározott időközönként.
Materialized View Logs: séma objektumok, melyek az egyes master táblákban történt változásokat jegyzik a materializált nézet számára, ha az inkrementális frissítést használ. Helye a master tábla sémájában van.


Kapcsolódó link:
Oracle® Database Concepts: Schema Objects

Nincsenek megjegyzések: