Adatbázis-tervezés konzultáció 4. Előadás Dr. Pauler Gábor, egyetemi docens, ev. Adószám: 63673852-3-22 Számlaszám: 50400113-11065546 Telephely: 7666 Pogány, Széchenyi u. 1. Tel: 30/9015-488 E-mail: pauler@t-online.hu

Az előadás tartalma A Multidimenzionális Hierarchikus (MDH) szerkezet származtatása Csillag- és hópehely struktúrák Aggregációs diagramm Példák MDH Szerkezetekre Szupermarket adatbázis marketing adattára Elektronikai gyár beszerzési rendszere Kutatólabor külső és belső logisztikája Taxivállalat bérsofőr rendszere Tömegközlekedési vállalat járatszervezési és utas-tájékoztatási rendszere Általános MDH sablon A rendszerleírás dimenzió jelentősége és tartalma Szerver egyed Kliens és Klienstörténet egyedek Rendszerfunkció és rendszerfunkció történet egyedek Felhasználó és Felhasználótörténet egyedek A Jogosultság egyed A Szekció egyed A Szoftver és Szoftvertörténet egyedek Az Export és Exporttörténet egyedek A rendszernaplózás Az adatbáziskezelők automatikus tranzakció naplózása Saját rendszernaplózás Hierarchikus szerkezetű adatloggolás és verziózás naplózása Szakirodalom

A Multidimenzionális-Hierarchikus (MDH) adatbázis-szerkezet származtatása 1 A Session3–ben már láthattuk, hogy a Multidimenzio-nális-Hierarchikus (Multi-dimensional Hierarchic, MDH) adatbázis szerkezetnek számos előnye van: A rendszer bővítése új felhasználói igények miatt könnyen megoldható a moduláris felépítés miatt: nem kell folyton teljesen új törzstábla struktúrákat bevezetni, amelyeknek a nagy része kísértetiesen hasonló lesz, hanem csak a már meglévő dimen-ziók tábláira hivatkozó idegen kulcsokat kell létre-hozni (meglévő vagy új relációs táblákban) Emellett azonban az MDH a hatékony jelentési (Reporting) rendszer alapjául is szolgál: A Session1–ben láttuk, hogy az OLAP-kockák csillag/ hópehely struktúra (Star/ Snowflake Structure) tábla-csoportokban tárolódnak az adattárházban: A struktúra középpontjában mindig tranzakciókat (pl. eladások), az üzleti folyamat műveleteit leíró egyedek találhatók, ezek OLAP-ban a tény- egyedek (Facts) A tényegyedekben szereplő elsődleges-/ idegen kulcsmezőket tényattribútumoknak (Fact Attribute) nevezzük, más mezőik mértékek (Measure) lesznek A tényegyedekre csatolódnak (Fact-Dimension Join) körben a dimenzió leíró egyedek (Dimensions) A dimenziók önmagukban is 1:több csatolásokkal (Intra-Dimension Join) láncba kapcsolt egyedekből álló fix szint-(Level) számú hierarchiát (Hierarchy) alkothatnak A dimenziókban szereplő elsődleges- és idegen kulcsok a dimenzió attribútumoknak (Dimension attribute), más mezőik a dimenzió leíró adatok (Dimension-related Data) Termék # Vonalkód * Név * Egységár * ITJ-kateg Cég # Adószám * TuldKód Vásárló # Vásárlókód * SzegmKód Számla # Számlaszám * Dátum * Végösszeg * Adószám * Vásárlókód Tétel # Tételkód * Mennyiség * Érték * Szlaszám * Vonalkód ITJ # ITJ-kateg Szegmens # SzegmKód Tulajdonos # TuldKód

A Multidimenzionális-Hierarchikus (MDH) adatbázis-szerkezet származtatása 2 Bonyolultabb csillag- és hópehely struktúrákat aggregációs diag-rammon (Aggregation Diagram) ábrázolhatunk, amely egy 2 ten-gelyű koordináta rendszerbe írt, dimenzió és tranzakció egyedek kapcsolati diagrammja: A vízszintes tengelyen az alkal-mazási probléma aggregációs szintjei (alsó,közép,felső) vannak A függőleges tengely sávjaiban a probléma dimenziói vannak, 1:több kapcsolt felső:alsó szintű egyedekkel. Ezek lehetnek elá-gazó (Fork) dimenziók: 1 egyed-hez több felettes egyed tartozik, és lehetnek rekurzív (Recursive) dimenziók: egy szint egyedjének önmagára mutató 1:többkapcso-lata van, nem fix szintszámú hi-erarchiát alkotva (pl. TermCsop) Az MDH struktúra tulajdonképpen az aggregációs diagramm 90°-kal történő elforgatásával keletkezik a kompaktabb ábrázolhatóság és jobb bővíthetőség érdekében A fentiekből belátható, hogy érde-mesebb az adatbázist az OLAP riportolást közvetlenül támogató MDH-ban tervezni, mint egy más módon tervezett adatbázisból még külön kifejteni az adatokat lekérdezések hosszas sorával egy hópehely-struktúrába Alsó- Közép- Felső- aggreg.szintek Dimenziók: Tér Idő Termék Üzlet Fogyasztó Tényadatok Negyedév # NegyÉv * ÉvSzám Tranzakció # TranzKód * Dátum * ÜzletKód * KártyaKód Tétel # TételKód * Mennyiség * TranzKód * ÁrazKód Termék # Vonalkód * Leírás * TermKód TermCsop # TermKód * TermNév * FelettKód Kártya # KártyKód * VevőNév * HáztKód Szegmens # SzegKód * SzegNév * LojKód * ProfKód Háztartás # HáztKód * Cím, demo * Duráció * CBG Kód * SzegmKód * LegjobbÜzl Üzlet # ÜzlKód * RégióKód * VersCsop Régió # RégióKód * RégióNév VersCsop # VersCsop * CsopNév Profit # ProfKód * ProfNév Lojalitás # LojKód * LojNév Árazódás # ÁrazKód * VonalKód * Hétszám * EgységÁr * EgysKtg Kupon * Típus * Engedm Nap # Dátum * HétSzám Hét # HétSzám * NegyÉv Év # ÉvSzám Fogyasztás # FogyKód * Fogyaszt * CBG CBG # CBGKód * Terület * Demogr.

Az előadás tartalma A Multidimenzionális Hierarchikus (MDH) szerkezet származtatása Csillag- és hópehely struktúrák Aggregációs diagramm Példák MDH Szerkezetekre Szupermarket adatbázis marketing adattára Elektronikai gyár beszerzési rendszere Kutatólabor külső és belső logisztikája Taxivállalat bérsofőr rendszere Tömegközlekedési vállalat járatszervezési és utas-tájékoztatási rendszere Általános MDH sablon A rendszerleírás dimenzió jelentősége és tartalma Szerver egyed Kliens és Klienstörténet egyedek Rendszerfunkció és rendszerfunkció történet egyedek Felhasználó és Felhasználótörténet egyedek A Jogosultság egyed A Szekció egyed A Szoftver és Szoftvertörténet egyedek Az Export és Exporttörténet egyedek A rendszernaplózás Az adatbáziskezelők automatikus tranzakció naplózása Saját rendszernaplózás Hierarchikus szerkezetű adatloggolás és verziózás naplózása Szakirodalom

Példák MDH szerkezetekre 1 Tanulmányaink során számos MDH adatbázist tárgyalunk: a SuperMarketERD.xls fájl egy szupermarket adatbázis marketing célú adattára (ez inkább aggregációs diagramm elren-dezésű, és a relációkat az idegenből az elsődleges kulcsra mutató  nyilak ábrázolják):

Példák MDH szerkezetekre 2 Az ElectrManufERD.vsd fájl egy elektronikai gyár beszerzését (Buying) mutatja MDH-ban:

Példák MDH szerkezetekre 3 A ResearchLabERD.vsd fájl egy kutatólabor beszerzése, értékesítése, kutatása MDH-ban:

Példák MDH szerkezetekre 4 A VechicleRoutingERD.vsd fájl egy taxivállalat bérsofőr tevékenysége MDH-ban

Példák MDH szerkezetekre 5 A MassTransportERD.vsd 1 közlekedési vállalat járattervezése és utasinformációja MDH-ban

MDH sablon Visio-ban A MintaERD.vsd fájl egy általános MDH sablon. A következőkben ennek részeit tárgyaljuk:

Az előadás tartalma A Multidimenzionális Hierarchikus (MDH) szerkezet származtatása Csillag- és hópehely struktúrák Aggregációs diagramm Példák MDH Szerkezetekre Szupermarket adatbázis marketing adattára Elektronikai gyár beszerzési rendszere Kutatólabor külső és belső logisztikája Taxivállalat bérsofőr rendszere Tömegközlekedési vállalat járatszervezési és utas-tájékoztatási rendszere Általános MDH sablon A rendszerleírás dimenzió jelentősége és tartalma Szerver egyed Kliens és Klienstörténet egyedek Rendszerfunkció és rendszerfunkció történet egyedek Felhasználó és Felhasználótörténet egyedek A Jogosultság egyed A Szekció egyed A Szoftver és Szoftvertörténet egyedek Az Export és Exporttörténet egyedek A rendszernaplózás Az adatbáziskezelők automatikus tranzakció naplózása Saját rendszernaplózás Hierarchikus szerkezetű adatloggolás és verziózás naplózása Szakirodalom

A Rendszerleírás dimenzió 1 A Terminátor című hülye hollywoodi moziban a Cyberdine által kifejlesztett Skynet 1997 augusztus 29-én, az ítélet napján „öntudatra ébred”, rakétákat lő ki Oroszországra, elpusztítva a világot A valóságban több mind 10 év telt el azóta, és sok vacakul tervezett számítógépes rendszer pusztítja a világot – meg az idegeinket – apró részletekben, mert az istennek sem hajlandók „öntudatra ébredni”, vagyis intelligens módon reagálni a környezet változásaira Ehhez ugyanis arra lenne szükség, hogy a profin tervezett adatbázis - az adott alkalmazás adatai mellett - tárolja a saját rendszerleírását (System Description) is: Az adatbázis, a lekérdezések és a felhasználói felület logikai terve A rendszer hardver/ szoftver környezete és beállításai A felhasználók adatai és jogosultságai A rendszer internetes/port csatlakozásainak beállításai Miért van szükség ezek tárolására? Pontosabb, ISO-kompatibilis rendszernaplózás érdekében: ki, mikor, milyen hardverről, milyen szoftver környezetben, melyik rendszerfunkciót indította, és ez mely táblák mely mezőiben milyen változást okozott? Az adatbázis rendszer funkcióinak és szolgáltatásainak felhasználóhoz és hardver/szoftver környezethez történő automatikus igazítása érdekében

A Rendszerleírás dimenzió 2 Felvive: felviteli dátum ModositoID: az utolsónak módosító felhasználó Modositva: utolsó módosítás dátuma NaploID: rendszer-napló bejegyzés idegen kulcsa, opci-onális, nem mindig van, csak a fonto-sabb változásokat naplózzuk! RekStatuszID: a rekord logikai stá-tusza a rekord élet-ciklusban (Record Lifecycle): 0: Táblába beszúrt, de még nem aktív rekord 1: Aktív rekord 2: Nem aktív, de archivált 3: Logikailag törölt rekord A Kliens több:1 kapcso-lódik a Szerverhez: Analóg módon hardver, oprendszer, rendszer-gazda, telepítési, elér-hetőségi adatokat tárol 1 Klienshez több Kli-ensTorténet rekord kapcsolódhat, melyek időintervallumokbeli Stá-tuszváltozásait rögzítik A Szerver egyedre akkor van igazán szükség, ha a rendszer több szerver-re tükrözve (Mirror) jele-nik meg: az adatabázis táblái vagy azok partíci-ói több szerveren táro-lódnak biztonsági okok-ból és automatikusan keresztbe frissülnek egymás változásaival: Minden más adatbázis táblában SzerverID idegen kulcs mutatja, adott rekord melyik szerveren tárolódik A Szervernél tároljuk a hardver, az oprendszer, az utolsó telepítés, a rendszeradminisztrátor, a tűzfal és az elérhető-ségek adatait: VPN: virtual private network beállítások Webszerver adatok ReplFtp: a fejlesztő azon FTP szervere, ahol az adatbázis replikája található Az adatstruktúrát ál-talános rendszer nap-lózó mezők zárják: FelvivőID: rekordot rögzítő felhasználó

A Rendszerleírás dimenzió 3 Ezek a státuszok min-den történet-jellegű e-gyednél mások, (pl. a KliensTort-nél 0:telepí-tett,nem aktív, 1:aktív, 2:karbantartás alatt, 3:megszűntetve) szem-ben az általánosan ér-vényes rekordstátusszal A RdszFunkc egyed az adatbázis munkaképer-nyőinek (Form) jegyzé-ke, az ADD-terven (ld. Session3), illetve a BPD és FHD terveken sze-replő módon: A RdszFunkcFelelősID idegen kulcs mutatja, ki-nek az illetékességi körébe tartozik a mun-kaképernyő A SzuloRdszFunkcID önmagára mutató ide-gen kulcs segítségével a rendszerfunkciók közt nem fix szintszámú hierarchia építhető A hozzá 1:több kapcsolódó RdszFunkcTort egyed írja le, adott időinterval-lumban melyik lekérde-zés (Query) vagy tárolt eljárás (Stored Proc.) hajtja meg a munkakép-ernyőt (SzoftverID), illetve egyáltalán hasz-nálatos-e, vagy csak moduljelöltként, forrás-kódban létezik (Rdsz-FunkcStatuszID) A Felhaszn egyed a fel- nálók adatait tárolja. Ezt ugyan megteszi az a-datbáziskezelő is, de itt kiegészítjük a felhasz-náló személyi (Sze-melyID) és Szervezet-be illeszkedési (Fel-hasznTipusID, Alkal-mazottID) adataival, Valamint az 1:több kapcso-lódó FelhasznTort e-gyedben a státuszának időintervallumbeli változásaival A Jogosultsag relációs egyed felhasználó tipusokhoz rendel rendszerfunkciókat adott időintervallumban A Szekcio relációs egyed az egyes felhasználók klienshsználati idő intervallumait rögzíti Ehhez még 1:több tartoz-hat SzekcioTort egyed, ami az egyes szoftver használatokat rögzíti a szekcióban

A Rendszerleírás dimenzió 4 A Szoftver egyed a Szoft-verTipusID-ben tárolja, hogy az adott modul: SQL lekérdezés (Que-ry): minden futáskor új-rafordítja szerver, lassú Tárolt eljárás (Stored Proc): procedurális uta-sításokkal kiegészített SQL nyelven (Oracle-ben PL/SQL, MSSQL-ben Transact SQL) írt modul, ami a szerveren előre lefordítva tárolha-tó, ezért gyorsan lefut Külső program (External Routine):C, Java, Basic, Delphi, stb. nyelvű, SQL lekérdezéseket haszná-ló előre lefordított kód Továbbá tárolja, mely Szervezet gyártotta (GyartoID) és ki a Kontaktja (Kon-taktID) A hozzá 1:több kapcsolódó SzoftverTort egyed írja le az adott modul telepí-tési adatait adott időin-tervallumokban Ehhez 1:több csatlakozhat egy MezoHaszn relá-ciós egyed, amely leírja, a modul mely Tablak mely Mezoit használja, milyen jogosutságokkal Ha az adatbáziskezelő oly primitív, hogy nem kér-dezhető le rendszertáb-lákból a felhasználói táblák mezőszerkezete (pl. MS Access-ben), akkor az 1:több kap-csolódó Tabla és Mezo leíró egyedeket is ne-künk kell létrehoznunk! Ha az adatbázis rendszer periodikusan exportál vagy importál külső adatbázisokba/-ból, ezeket 1:több kapcsoló-dó Export, ExportTort, és Import, ImportTort táblapárok tárolják Az, hogy a rendszerleírás dimenziót milyen részle-tesen,hány táblában kell kibontani, erősen függ attól, hogy az adatbázis-kezelő milyen minősé-gű: elérhető-e a táblák, mezők, munkaképer-nyők, programmodulok, felhasználók leírása rendszertáblákból vagy egy objektum-hierarchia elemeként (pl. Oracle, IBM DB2), vagy csak a tábláké (MSSql, MySql) vagy semmi (Access)

Az előadás tartalma A Multidimenzionális Hierarchikus (MDH) szerkezet származtatása Csillag- és hópehely struktúrák Aggregációs diagramm Példák MDH Szerkezetekre Szupermarket adatbázis marketing adattára Elektronikai gyár beszerzési rendszere Kutatólabor külső és belső logisztikája Taxivállalat bérsofőr rendszere Tömegközlekedési vállalat járatszervezési és utas-tájékoztatási rendszere Általános MDH sablon A rendszerleírás dimenzió jelentősége és tartalma Szerver egyed Kliens és Klienstörténet egyedek Rendszerfunkció és rendszerfunkció történet egyedek Felhasználó és Felhasználótörténet egyedek A Jogosultság egyed A Szekció egyed A Szoftver és Szoftvertörténet egyedek Az Export és Exporttörténet egyedek A rendszernaplózás Az adatbáziskezelők automatikus tranzakció naplózása Saját rendszernaplózás Hierarchikus szerkezetű adatloggolás és verziózás naplózása Szakirodalom

A rendszernaplózás 1 A Session1-ben említett Carlzon-elv szerint bármely szervezet akkor működik hatékonyan, ha minden pozíciónál arányban vannak a felelősségek, a hatáskörök és az információ ellátás. A BPR sokat segít a hatáskörök hatékony szétosztásán, egy jól tervezett adatbázis rendszer megoldja az információ ellátást, de még mindig külön probléma marad a felelősségek nyomonkövetése hatékony rendszernaplózás (System Logging) révén. Ez az a terület, amelyet mind a fejlesztők, mind a megrendelők szeretnek elsinkófálni: Az előbbiek számára sok munkát jelent, és nem hoz külön profitot Az utóbbiak számára erősen csökkenti a korrupciós visszaélések lehetőségét A fejlett adatbáziskezelők kifinomult lehetőségeket hordoznak magukban a rendszernaplózásra. Ismerkedjünk meg ennek alapfogalmaival: Tranzakció (Transaction) olyan, általában beszúrás (Insert), felülírás (Update) és törlés (Delete) utasításokból álló műveletsorozat, amelynek hardver/szoftver okokból történő váratlan félbeszakadása korruptálja az adatbázis adatait: vagy egyben végrehajtandó, vagy meg sem történjen Automatikus tranzakció naplózás (Automatic Transaction Logging): az adatbáziskezelő egy alrendszere, amely megfelelő utasítás (pl. MSSQL-ben BEGIN TRAN) kiadása után rendszer-visszaállítási pontot (System Rollback Point) definiál, és biztonsági okokból az adatbázist tároló fájloktól elkülönített!!!, más könyvtárban, más meghajtón lévő tranzakció napló (*.Log) fájlokba tárolja az utána bekövetkezett adatváltozások visszavonásához szükséges adatokat (Undo Data). Ha a tranzakció sikeresen lefut, akkor véglegesítési utasítás (pl. MSSQL-ben COMMIT) kiadása után a hozzá tartozó tranzakciónapló letörlődik, hogy ne foglalja a helyet Ha a tranzakció sikertelenül félbeszakad, és az adatbázis korruptált állapotba kerül, visszavonás utasítás (Pl. MSSQL-ben ROLLBACK) hatására a rendszer a tranzakció napló undo adatai segítségével visszakerül az utolsónak definiált rendszervisszaállítási pontba. Ezután a tranzakciónapló törlődik, és a tranzakció újra megkísérelhető A tranzakció általában egy adatbáziskezelőben sem tartalmazhat a táblák vagy relációk adatszerkezetén bármit is változtató utasításokat (pl.ALTER TABLE,DROP TABLE,stb.) Ha ilyen jó automata rendszer van erre, miért kell mégis foglalkoznunk a rendszernaplóval? Az automatikus rendszernaplózás borzalmas mennyiségű tárolóhelyet fogyaszt, mert a visszavonás adatai jóval hosszabb helyen tárolhatók, mint maguk az adatváltozásoké, illetve válogatás nélkül minden adatváltozást rendszernaplóz, olyanokat is, amelyek baj esetén könnyen visszaállíthatók lennének (pl. egy rekord egyik táblából másikba másolása, üres táblába beszúrt új rekordok, stb.)

A rendszernaplózás 2 Ezért van szükség a Naplo egyedre, amelyre a rendszer bármely más táb-lája hivatkozhat opcionális NaploID idegen kulccsal, de nem szükség-szerűen hivatkozik: csak azon adatváltozásokat naplózzuk, amelyek: Elég fontosak az alkalmazás szempontjából, vagy valamely ISO-szabvány előírja, hogy az adott adat teljes életciklusában (Data Life Cycle) nyomon kell követni a változásokat Rendszernapló nélkül nagyon nehéz lenne visszaállítani őket Arról, hogy készül-e rendszernapló bejegyzés, mindig az adott tranzakciót futtató tárolt eljárás hoz döntést. Ha készül, akkor eltároljuk, hogy mely Szerver (SzerverID) mely Kliensén (KliensID) mely Felhasználó által indított mely Szekcióban (SzekcioID), milyen Rendszerfunkcióval (RdszFunkcID) mely Tabla (TablaNev) mely rekordjának (RecID) mely mezőjében (MezoNev) milyen érték (RégiErtek) milyenre változott (UjErtek) mely időpontban (NaploIdo): Ügyeljünk rá, hogy a régi- és az új értékek bármilyen adattipusúak lehetnek, a bittől a mozifájlig. Ezért ezek karakteres mezők, ahol egész-/törtszámot, dátum/időt, külső fájl URL-jét le tudjuk írni, viszont zabálják a helyet rendesen Előnyösebb megoldás, ha az adatbáziskezelő lehetőséget ad változó típusú adatra szóló pointer (pl. Visual Basic-ben a variant tipus) tárolására, ami mindig 4byte-ot eszik, és meghivatkozza a máshol tárolt adattartalmat További probléma, ha a rendszerleírás dimenzió nem elég pontos és részletezett, ezért mintánkban a tábla és a mező nevét bazi sok helyet evő 24 karakteres szövegekként kell tárolni. Ha kifejtettük volna őket külön táblákba (vagy hivatkozhatnánk az adatbáziskezelő rendszertábláiban tárolt leírásokra) 4byte-os Long tipusú idegen kulcsokkal hivatkozhatnánk rájuk 24 byte-os szövegmezők helyett! Itt térül vissza nagyon hamar a pontos rendszerleíró dimenzió megtervezésébe befektetett munka!!!

A rendszernaplózás 3 További nagyon fontos szerepe van a Naplo egyed SzuloID idegen kulcson keresztül önmagára mutató 1:több kapcsolatának: A Naplo által tárolt adatváltozások ugyanis többnyire nem függetlenek egymástól, hanem láncba (Chain) kapcsolódhatnak: ilyen egy tranzakció utasítás-szekvenciája által okozott adatváltozás-sorozat Vagy, az adatváltozások nem fix szintszámú hierarchia-fába (Tree) is kapcsolódhatnak, ha például több felhasználó megosztva használja az adatbázist, és valamilyen ok miatt (pl. nincs on-line kapcsolatuk, vagy nem szeretnék, hogy más belezavarjon a saját munkájukba) aszinkron kénytelenek használni. Ennek két esete lehetséges: Pl. A felhasználó megváltoztatja T tábla M mezőjének értékét az R-edik rekordban 0-ról 1-re, és a továbbiakban az új értékkel számol. De B felhasználó nem látja, vagy nem akar tudomást venni erről a változásról, és az eredeti 0 értéket 2-re állítja. Ettől kezdve az adatbázis minden olyan része, amelynek megváltoztatásában az aszinkron módosított rész részt vett, 2 ágra (Node) szakad. Ezt nevezzük az adatbázis adattartalom szerint több verzióra ágazásának (Hierarchic Data Logging) Pl. A felhasználó letörli T táblát és létrehozza helyette T1-et, és a továbbiakban erre alapozva tervezi az adatbázist, még B felhasználó nem látja, vagy nem akar tudomást venni erről a változásról, és az eredeti T táblára alapoz. Ettől kezdve az adatbázis azon része, amelyhez T tábla relációkkal kapcsolódik, illetve amelynek megváltoztatásában adatai részt vesznek, 2 ágra szakad. Ezt nevezzük az adatbázis szerkezet szerint több ágra ágazásának (Versioning). Az MSSQL 2005-ös verziójától automatikusan kezeli többfelhasználós rendszerek esetén a Versioninget, azonban ez a teljesítmény drasztikus csökkenésével jár, használata csak az adatbázis tervezési időszakában ajánlott! Mindkét esetet úgy naplzzuk, hogy az újonnan létrejött ághoz tartozó Naplo-rekord mutat a SzuloID idegen kulccsal arra az ághoz tartozó Naplo-rekordra, amelyből létrejött Ver0.0: T.M(R)=0 Ver1.0(A): T.M(R)=1 Ver1.1(B): T.M(R)=2

Szakirodalom Csillagstruktúra: Alapdefiníció (angolul): http://en.wikipedia.org/wiki/Star_schema Tervezési fogások (angolul): http://www.ciobriefings.com/whitepapers/StarSchema.asp A többdimenziós tervezés elmélete (angolul): http://c2.com/ppr/stars.html Gyorsítása denormalizációval (angolul): http://www.dwoptimize.com/2007/06/aiming-for-stars.html Sebességi benchmark (angolul): http://www.cs.umb.edu/~poneil/StarSchemaB.PDF Hópehely struktúra: Alapdefiníció (angolul): http://en.wikipedia.org/wiki/Snowflake_schema Összehasonlítása a csillagstruktúrával (angolul): http://oracle-online-help.blogspot.com/2006/11/star-vs-snowflake-schema.html Bitmap indexelés jelentősége (angolul): http://www.lorentzcenter.nl/awcourse/oracle/server.920/a96520/schemas.htm IBM RedBrick Data Warehouse példák hópehely sémákra különböző alkalmazási területeken (angolul): http://publib.boulder.ibm.com/infocenter/rbhelp/v6r3/index.jsp?topic=/com.ibm.redbrick.doc6.3/wag/wag32.htm Időmodellezés hópehely struktúrában (magyarul): http://users.iit.uni-miskolc.hu/~kovacs/db2/ora10.html Adatok hierarchikus loggolásának alaptechnikái (angolul): http://www.ciselant.de/projects/pg_ci_diff/doc.html Adatabázis-sémák verziózása (angolul): http://www.infoq.com/news/2008/02/versioning_databases_series http://edndoc.esri.com/arcsde/9.1/general_topics/what_versioned_dbase.htm http://docs.codehaus.org/display/GEOS/Versioning+WFS+-+Database+design