Adatbázis-tervezés konzultáció 5. Előadás Dr. Pauler Gá bor , egyetemi docens, ev.

1. Adatbázis-tervezés konzultáció 5. 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

2. Az előadás tartalma Az idő dimenzió szerkezete az MDH-ban • Az adatbáziskezelők nyújtotta időábrázolási szolgáltatások • Miért nem elég az adatbáziskezelők időábrázolása? • Naptipusok és történetiségük • Napszaktipusok és történetiségük • Naptár és Napszaktár Az idődimenzió felhasználásai • A BPD-ken szereplő logikai időpontok, mérföldkövek ábrázolása • Gyógyszer kutató labor BPD-je • Taxivállalat BPD-je • A munkaidő nyilvántartása: Virtuális műszaktervek és Műszakok • Időben változó hierarchikus fa-szerkezetek modellezése • „Tulipán”-modell: a szerkezet változik • „Fásszárú”-modell: a szerkezet stabil, a tartalom változik • Az MDH-hierarchia szintek időbeli tárolása • Minta és MintaTipus egyedek • MintaTörténet és MintaStátusz egyedek • A bizonylati elv érvényesülése az MDH szint időbeli tárolásában • Az MDH szintet karbantartó eljárások • 5.1. ESETTANULMÁNY: Tömegközlekedési Vállalat • A probléma ERD-je, a Fordák, FordaSzakaszok és FordaSorok fogalma • Import karbantartó eljárások • A karbantartó eljárások általános szerkezete • Összegzés Szakirodalom

3. Az adatbáziskezelők nyújtotta időábrázolási szolgáltatások A legtöbb modern adatbáziskezelő (MSSQL, Oracle, MySQL, IBM DB2) fixpontos törtszámként tárolja a lineáris időt (Linear Time): Speciális csillagászati és navigációs alkalmazásokban – pl. GPS – ugyan számíthat, hogy az idő a relativitáselmélet szerint nagy tömegek és sebességek esetén lelassul, de a mindennapi/üzleti életben a lineárisan múló newtoni értelemben használjuk: • A 0.00 érték valamilyen egyezményes időpont, általában 1900-01-01 00:00:00.000 • A szám egészrésze az azóta eltelt napok száma • Törtrésze a napon belüli arányos rész, pl: 0.5 = 12:00:00.000 • Negatív értékei a kezdő időpont előtti időpontok • Hosszabb változata 8byte-os (pl. MSSQL: Date), századmásodperc pontossággal tárol, több száz évnyi időintervallumon • Rövidebb változata 4byte-os (pl. MSSQL: ShortDate), másodperc pontossággal tárol, kb. 100 éves időintervallumon • Speciális 8byte-os változata az időbélyeg (pl. MSSQL: TimeStamp), ennek az értékét az adatbáziskezelő automatikusan tölti ki, és sohasem vehet fel ismétlődő értéket, akkor is, ha 1 századmásodpercen belül kérünk újat, így alkalmas arra, hogy a teljes adatbázisrendszer összes táblájára kiterjedően egyedi kulcs legyen Az adatbáziskezelők dátum/időkezelő függvények széles választékát kínálják a dátum/idő tipusokra alapozva, amelyek megoldják: • Az öröknaptár-kezelést (dátumszámítás, szökőnapok), • A hetek és napok éven belüli sorszámozását, • Időpontok közti különbség kiszámítását 365 napos évben/ 30 napos hónapban/ hétben/ napban/ órában/ percben/ másodpercben. • Ezért fontos, hogy dátumokat mindig dátum/idő formátumban tároljunk és NE számként vagy szövegként, mert elesünk a dátumkezelő függvények használatától, és pazaroljuk a tárolóhelyet!!! Ezek az automatikus funkciók a gyakorlatban azonban még kevesek az üdvösséghez, mert nem oldják meg: • A téli- és nyári időszámítás közti átállást, aminek időpontjai és mértéke országonként változhat. Az adatbáziskezelők az aktuális időpontok lekérdezésekor az operációs rendszer órájára hagyatkoznak, és nem tartják nyilván ezeket (kiv. Oracle). Ez akkor zavaró, ha órában mért időkülönbségeket számítunk a téli és a nyári időszámítási zónában fekvő időpontok közt (kézzel kódolva hozzá kell adni vagy le kell vonni az eltolás mértékét).

4. Miért nem elég az adatbáziskezelők időábrázolása? • A munkanapok, 1/több napos nemzeti/vallási ünnepek nyilvántartását, ami országonként/ vallásonként változhat, ráadásul évente csúsztatják ide-oda a naptár változásai miatt, hogy hosszú hétvégéket hozzanak létre. (Ebből a szempontból egyszerűbb az USA, ahol a Karácsony és Függetlenség Napja kivételével az összes ünnepet adott hónap adott sorszámú hetének adott napjára rögzítik (pl. a munka napja (Labour Day) NEM május 1, hanem május első péntekje) Holott, a legtöbb jogi/közigazgatási szabályozásban, illetve üzleti munkaütemezésben nem a naptári napok, hanem az eltelt munkanapok száma számít!!! • Ha napon belüli időszakok szintjére megyünk le, számíthat, hogy más évszakokban vagy páros/páratlan heteken nem ugyanaz a napon belüli munkabeosztás. Ebben a témában legsúlyosabban érintettek a közle-kedési vállalatok, mert nekik alkalmazkodni kell a cégek és intézmé-nyek, iskolák működési idejéhez, ami ciklikusan más és más lehet. Mindezekből belátható, hogy az idő valódi szerkezete minden, csak nem lineáris, és komoly adatbázis rendszer működésképtelen fejlett időleíró dimenzió nélkül: • A taxivállalat MDH-modelljében (ld.: VechicleRoutingERD.vsd) az idő-leíró dimenzió egyszerűbb változatát látjuk:az üzleti év (Business Year) – amely nem biztos, hogy megegyezik a naptári évvel – a negyedév (Quarter), a hónap (Month), a hét (Week) és a nap (Day) egyedek fix szintszámú hierarchiát alkotnak, annyi csavarintással, hogy mivel a hetek átlóghatnak hónapok közt, ezért köztünk nem sok értelme van 1:több kapcsolatot definiálni. Ehelyett a negyedév és a hét, illetve a hónapok és a napok közt definiálunk 1:több kapcsolatot. • A hierarchia aljára csatlakozik az ünnepnapok (Celebration) egyed (1naptöbbünnepnap lehet), aminek a segítségével egy lekérdezés kiszámíthatjuk a munkanapok számát 2 dátum közt: Select Count(Day.DayID) /Számold össze a napok darabszámát From Day Left Join Celebration On Day.DayID = Celebration.DayID /Úgy, hogy a napokra rácsatolod az ünnepeket, ha tartoznak hozzájuk Where IsNull(Celebration.CelebrationID) /Ha adott nap nem ünnep And Day.StartDate Between(KezdDatum,VegDatum); /És dátuma beleesik a vizsgált időintervallumba

5. Naptipusok és történetiségük • A fenti megoldás igen egyszerű, de óriási hátránya, hogy a felhasználónak kézzel kell beírogatni minden egyes ünnepnapot (+a hétvégéket), hiába ismétlődnek meg ciklikusan minden évben vagy héten–sok munka! A közlekedési vállalatok (ld.: MassTransportERD.vsd) olyan bonyolult időrend szerint dolgoznak, annyiféle napok közti és napon belüli időintervallumot kell kezelniük, hogy a fenti idő dimenzió nekik elégtelen • Ezért van szükség rá, hogy napok halmazára kiterjedő időszakokat (NapTipus) évre, hóra, hétre, napra ciklikusan, virtuálisan lehessen definiálni (Cyclic/Virtu-al definition), időben változó módon, történetiséggel (Historic Def.):a NapTipusTort opcionális mezőiben: • Kezd/VegRelDatum: pl. ”minden év márc.1.-aug.21.” • Kezd/VegHonap:pl. ”minden hó 1.-21.-ig” • Kezd/VegHoHet:pl. „minden hó 1.-4. hetéig” • ParosHet:1:”páros héten”0:”páratlanon”,Null:”bármely” • Kezd/VegEvHet:pl. „minden év 13.-28. hetéig” • Kezd/VegHetNap:pl. „minden héten kedd-csütörtök” (A különböző mező-párok szerint adott definíciók ÉS operátorral összegződnek,pl. „03.1-08.21, kedd-csüt.”) • A definíciók mindig a KezdDatum-VegDatum közti abszolút időintervallumban érvényesek (a vége opcio-nális, nyitott), pl: „2008.03.12-től minden hó 1.-14.-éig” • A NapTipus egyed SzuloID opcionális idegen kulcson keresztüli önmagára mutató 1:több kapcsolata nem fix szintszámú hierarchiát hozhat létre a naptípus-definíci-ók közt, és a PozitivHalmazDef bináris jelző(Flag) mező mutatja, hogy halmazba foglalásról vagy kivétel-ről van szó. Ilyen módon ábrázolható a következő nyalánkság: „minden év március 11. – aug 21., kivéve a hónapok második szerdáját” (valós példa): FőNapTipus: Kezd/VegRelDatum = 03.11..08.21 AlNapTipus: Kezd/VegHoHet = 2..2, Kezd/VegHet Nap = Szerda..Szerda, PozitivHalmazDef =0

6. Napszaktipusok és történetiségük • A NapTipusSzintID jelzi, hányadik szintre ágya-zódik be az adott naptipus-definíció • A NapTipusStatuszID jelzi, életciklusának mely szakaszában van az adott definíció: 0:Létrejött, de még nem aktív, módosítható 1:Aktívan használt, már nem módosítható 2:Már nem aktív, archiválandó 3:Már nem aktív, törlendő Teljesen hasonló logika szerint épül fel a naponta ciklikusan ismétlődő NapSzakTipusok definiálá-sa, azzal a különbséggel, hogy itt a definíció jóval egyszerűbb, Kezd/ VegRelIdo-re korlátozódik, pl. „naponta 9.30-11.45-ig” • A NapTipus és a NapSzakTipus egyedek közt 1:több kapcsolatot definiálunk, vagyis minden naptípusnak meglehet a saját külön napon belüli időszakaszolása. Pl.: „2016.01.01-től minden év márc.11.-től aug.28-ig a főszezonban a keddi és szerdai éjszakás műszak 21.15-6.15-ig tart”: NapTipus: NapTipusID=1 NapTipusLeir=„FőszezonKeddSzerda” NapTipusSzint=1, PozitivHalmazDef=1 NapTipusTort: NapTipusID=1 Kezd/VegRelDatum=03.11..08.28 Kezd/VegHetNap=Kedd..Szerda Kezd/VegDatum=2016.01.01..Null NapTipusStatuszID=0 /Még nem hatályos NapSzakTipus: NapSzakTipusID=4 NapTipusID=1 NapSzakTipusLeir=„ÉjszakásMűszak” NapSzakTipusSzint=1 NapSzakTipusTort: NapSzakTipusID=4 Kezd/VegRelIdo=21.15..06.15 Kezd/VegDatum=2016.01.01..Null NapTipusStatuszID=0 /Még nem hatályos

7. Naptár és napszaktár egyedek • Ne feledjük, hogy az eddigi táblák konkrétan nem írnak le egy fia napot meg napszakot sem, csak adott időintervallumban érvényes definíciókat tárolnak! • Ezért van szükség Naptar egyedre, amely a konkrét napok tulajdonságait tárolja: Datum, Honap, Honap-Het, ParosHet, EvHet, HetNap (a plusz tulajdonsá-gokat dátumkezelő függvényekkel számítjuk ki előre a dátumból, hogy gyorsan lekérdezhetők legyenek) • A hozzá 1:több csatlakozó NapSzakTar egyed a konkrét napokon belüli konkrét elemi időszeleteket (System Tick) tárol: ez a legkisebb időegység, ami-hez kötve napszaktipus definíció kezdődhet/záródhat, és az IdoSzelet egyed definiálja (pl. a közlekedési vállalatnál ez 15 perc:1.:0.00-0.15 2.:0.15-0.30,stb.) • A NapTipus:NapTar és a NapSzaTipus:NapSzak-Tar kapcsolata több:több (pl. 1NapTipustöbbNapTari naphoz tartozik, és 1NapTari naphoz is többNapTipus - pl. Főszezon ÉS Munkaszüneti nap - tartozhat), így mindkét esetben relációs tábla köti őket össze: NapTarNapTipus: NaptarID-t a NapTi-pusID-vel, illetve NapSzakTarNapSzakTipus a Nap-SzakTarID-t aNapSzakTipusID-vel • Ezek a relciós táblák elég sok helyet fogyasztanak, és teljesen redundáns tárolók, a definíciókból egy SQL lekérdezés automatikusan kiszámíthatja előre a tartalmukat. A cél itt adott napra/napszakra vonatko-zó információk minél gyorsabb lekérdezése, illetve a kézi naptárazás kiváltása, és nem a helymegtakarítás • A Most egyed mindig 1 mezős, 1 rekordos tábla, amely folyamatosan felszedi az oprendszer dátumát, és minden más lekérdezés a Most.Most-ra hivatko-zik, ha aktuális dátumot használ. Így az adatbázis rendszer központilag könnyen visszaállítható időben, pl. hogy el tudjunk végezni utólag visszadátumozva olyan műveleteket,amire real time nincs kapacitásunk

8. Az előadás tartalma Az idő dimenzió szerkezete az MDH-ban • Az adatbáziskezelők nyújtotta időábrázolási szolgáltatások • Miért nem elég az adatbáziskezelők időábrázolása? • Naptipusok és történetiségük • Napszaktipusok és történetiségük • Naptár és Napszaktár Az idődimenzió felhasználásai • A BPD-ken szereplő logikai időpontok, mérföldkövek ábrázolása • Gyógyszer kutató labor BPD-je • Taxivállalat BPD-je • A munkaidő nyilvántartása: Virtuális műszaktervek és Műszakok • Időben változó hierarchikus fa-szerkezetek modellezése • „Tulipán”-modell: a szerkezet változik • „Fásszárú”-modell: a szerkezet stabil, a tartalom változik • Az MDH-hierarchia szintek időbeli tárolása • Minta és MintaTipus egyedek • MintaTörténet és MintaStátusz egyedek • A bizonylati elv érvényesülése az MDH szint időbeli tárolásában • Az MDH szintet karbantartó eljárások • 5.1. ESETTANULMÁNY: Tömegközlekedési Vállalat • A probléma ERD-je, a Fordák, FordaSzakaszok és FordaSorok fogalma • Import karbantartó eljárások • A karbantartó eljárások általános szerkezete • Összegzés Szakirodalom

9. Az idődimenzió felhasználásai 1 Az idődimenzió ilyen rész-letességű kifejtése túl-zónak tetszhet, amíg bele nem bonyolódunk, hogy az üzleti folyamat diagrammon (Business Process Diagram, BPD, ld.: Session1) megjele-nő mérföldköveket (Mi-lestone) próbáljuk ábrá-zolni az adatbázis-ban: • Egyszerűbb BPD-k esetén (lásd pl. gyógy-szerkutató labor Rese-archLabBPD.vsd), ahol nincsen túl sok ciklus, az időtengely majdnem teljesen lineáris szerke-zetű lehet (pl. itt napok-ra (Day) van felosztva, azon belül pedig a rá-csos osztásjelek mun-kaórákat (Hour) jelente-nek). Ennek megfelelő-en a rendszer időábrá-zolása sincs túlbonyo-lítva (ld.: Research-LabERD.vsd): az alap-modell lényegében csak a műszak (Shift) egyed-del egészül ki, amely rögtön ténylegesen, fizi-kailag létező műszako-kat ábrázol,ezért manu-álisan kell feltölteni:

10. Az idődimenzió felhasználásai 2 Magasabb szintű idődimenzió kezelésre akkor lehet szükség, ha a BPD sok elágazást és ciklust tartalmaz: • Pl. a taxivállalat bérsofőr (Party Driver) rendszere olyan szolgáltatást támogat, mely autóval szórakozni indult, de időköz-ben vezetésképtelenné vált ügyfeleket (Customer) visz haz autóstól. A folyamat (ld.: VehicleRoutingBPD.vsd) azzal kezdő-dik, hogy a telefonos diszpécser (Operator) kikérdezi a szellemileg nem mindig a topon lévő ügyfelet a megrendelés adatairól (Mikor?, Honnan?, Hová?, Milyen tipusú, színű és rendszámú autót? Hol találkoznak?). Ennek számos buktatója van, legalább 5 egymásra épülő, egymásba ágyazott feltételnek kell teljesülni, hogy a fuvar vállalható legyen - ezt nevezzük hagymahéj-logikai szerkezetnek (Onion-Skin Structure) – így hiába írtunk oda a telefonbeszélgetés időtengelyére perceket, ezek nem lineáris fizikai időpontok, hanem különféle logikai időintervallumok határai! Pl. a Minute1 mérföldkő valójában azt jelenti, hogy már sikerült annyi adatot begyüjteni az ügyféltől, hogy előütemezést végezhet a rendszer, kb. mikorra melyik sofőrt tudja odaküldeni. • Ezen logikai időintervallumok ábrázolása viszont nem megoldható NapSzakTipus és NapSzakTipusTort egyedek használata nélkül.

11. Az idődimenzió felhasználásai 3 Nagyon nagy segítség a fejlett idődimenzió a tömeg-közlekedési vállalat (ld.: MassTransportERD.vsd) igen bonyolult szerkezetű műszak-ábrázolásánál: • A sofőrök alapvetően itt is 8 órás műszakokat teljesítenének, csakhogy törvényi szabályozás írja elő, hogy nem vezethetnek 8 órát egyfolytában! • Ezért a műszakot feldarabolják osztott-idő nevű részekre, a melyek közt pihenőidők vannak, de a felosztás nem fix, függ az évszaktól, hó eleje-/vé-gétől, a hét napjától és a nappali/éjszakai munka-rendtől is (éjjel csak rövidebb időket lehet osztani) • Azonban előre nem látható forgalmi és időjárási okok miatt az egész beosztás megcsúszhat és szükség van az osztott-idő határok kézi állítására, akár az utolsó pillanatban is, sőt utólagosan! Ezeket úgy olgjuk meg, hogy a VirtMuszak egyed tárolja a tervezett műszakok virtuális, logikai definícióját, ami fejlett idődimenzió birtokában meglepően egyszerű lesz: • MuszakTipusID:műszaktípus(normál/rendkívüli) • PozicióID:nem konkrét sofőrre szól, hanem egy buszállomás adott képzettségű sofőrjére • A NapTipusID és a NapSzakTipusID együtt tet-szőlegesen bonyolult időszerkezetet rendel hozzá (Ha nem csináltunk volna bonyolult idődimenziót (ld.: MassTransportERD.vsd), most majdnem az ösz-szes tábláját berakhatnánk a műszakleíráshoz!!!) A hozzá 1:több kapcsolódó Muszak egyed már csak történetiségében ábrázolja az elvégzett munkákat: • AlkalmazasID: konkrétan kicsoda végezte el • NaptarID: melyik naptári napon lett teljesítve • ManKezd/VegIdo, ManOsztIdoKezd/Veg: ha nem a terv szerint ment az időosztás,akkor hogy történt • MuszakStatuszID: 0:tervezett műszak, még lehet módosítani, 1:aktív műszak, 2:archivált, 3:törlendő

12. Ver0.0: T.M(R)=0 Ver1.1(B): T.M(R)=2 Ver1.0(A): T.M(R)=1 Időben változó hierarchiák modellezése 1 • Az MDH által tárolt hierarchiák időben jelentősen változhatnak, mind fa-szerkezetük (Tree structure: hány ága van az adott szinten), mind adattartamuk (Content) tekintetében: a Session4-ben a Naplo egyed önmagára mutató 1:több kapcsolata példát mutatptt rá, hogyan kell hierarchiába kapcsolódó időbeli adatváltozás-verziókat tárolni. • Nem biztos azonban, hogy minden esetben a nem fix szintszámú hierarchia a legjobb módszer időbeli változások tárolására. Lássuk ezt hierarchiákat alkotó növények példáján: a fenti megoldás egy hagymáról minden évben (ld.színek) kinövő tulipánbokorra emlékez-tet, ahol a struktúra (szárak) és az adattartalom (virágok) is újraépül minden időpontban.Ez akkor hatékony,ha mindkettő gyorsan változik. • Más a helyzet, ha a struktra csak kevéssé változik, viszont az adattar-talom nagyon intenzíven: ez esetben a tulipán rengeteg felesleges munkát végez azonos ágszerkezet minden évben újranövesztésével • Ez esetben hatékonyabb szerkezet egy fa, ahol a struktúra fix, de minden évben levelek új verziója akasztható rá, minimális munkával! • Látható, hogy időben változó hierarchiák hatékony tárolási megoldása erősen függ attól, hogy az alkalmazási környezetben mi változik gyorsabban.Lássunk most egy kompromisszumos tárolási megoldást: ≠ > 2000 2001 2002 2003 2004

13. Az előadás tartalma Az idő dimenzió szerkezete az MDH-ban • Az adatbáziskezelők nyújtotta időábrázolási szolgáltatások • Miért nem elég az adatbáziskezelők időábrázolása? • Naptipusok és történetiségük • Napszaktipusok és történetiségük • Naptár és Napszaktár Az idődimenzió felhasználásai • A BPD-ken szereplő logikai időpontok, mérföldkövek ábrázolása • Gyógyszer kutató labor BPD-je • Taxivállalat BPD-je • A munkaidő nyilvántartása: Virtuális műszaktervek és Műszakok • Időben változó hierarchikus fa-szerkezetek modellezése • „Tulipán”-modell: a szerkezet változik • „Fásszárú”-modell: a szerkezet stabil, a tartalom változik • Az MDH-hierarchia szintek időbeli tárolása • Minta és MintaTipus egyedek • MintaTörténet és MintaStátusz egyedek • A bizonylati elv érvényesülése az MDH szint időbeli tárolásában • Az MDH szintet karbantartó eljárások • 5.1. ESETTANULMÁNY: Tömegközlekedési Vállalat • A probléma ERD-je, a Fordák, FordaSzakaszok és FordaSorok fogalma • Import karbantartó eljárások • A karbantartó eljárások általános szerkezete • Összegzés Szakirodalom

14. Az MDH hierarchia szintek (Hierarchy Levels) időbeli (Dynamic) tárolása Az MDH-ban minden hierarchia szintet 4 egyed jelenethet meg, de nem biztos, hogy mindig mind a 4-re szükség van. Legyen most az adott hierarchia szint neve Minta (ahogy korábban pl. NapTipus, NapSzakTipus): • A Minta egyed írja le a fix szintszámú, idő-ben csak lassan változó hierarchia adott szintjét: a felettes szint Minta egyedére 1:több kapcsolattal kapcsolódik, az alantas szint Minta egyede 1:több kapcsolódik rá (az előbbi példában ez a fa törzse/ágai) • Ha a Minta egyed előfordulásai többfélék lehetnek, ezt a MintaTipus kódtábla írja le • A Minta egyedhez 1:több kapcsolódik a MintaTort egyed, mely a Minta1 rekordjá-nak több lehetséges egymást követő idő-intervallumbeli (KezdDatum..VegDatum) állapotát írja le, ezért ez tárol minden olyan sima AdatMezőt, ami időben megváltozhat • A lehetséges időbeli állapotokat a Minta-Satusz kódtábla írja le, illetve hogy az álla-potok hogy követhetik egymást (Sorszam) • Ha az adott dimenzió hierarchiájának szer-kezete is nagyon gyorsan változik időben, akkor, akkor nem a Minta egyedre kötjük 1:több-bel az alantas szint Minta egyedét: • Ha a dimenzió hierarchikus szintjei fix-ek időben (pl.Szevezet,Osztály, Pozí-ció), de az elágazásaik brutálisan gyor-san változnak időben, akkor a Minta-Tort egyedre kötjük az alantas szintet • Ha a szintek sem maradnak fixek, ak-kor ezt a MintaTort egyed SzuloID idegen kulcson keresztül önmagára mutató 1:több kapcsolatával ábrázoljuk • Látható, hogy a MintaTort egyed viselke-dése alapesetben megfefelel az előbbi példában a fásszárú fa leveleinek • De gyors strukturális változások ábrázo-lásakor, mikor belőle ágazik ki a követke-ző szint, átveheti a fa ágainak szerepét!

15. FaraoTort FaraoTortID FaraoNeve KezdDatum VegDatum ElozoFarao Módosító Módosítva Állapot • FaraoTort • FaraoTort • FaraoTort • FaraoTort • FaraoTort • FaraoTortID:1 • FaraoNeve:Rákosi • KezdDátum:1949 • VégDátum:1953 • ElozoFaraoID:Null • FaraoTortID:2 • FaraoNeve:Nagy • KezdDátum:1953 • VégDátum:1956 • ElozoFaraoID:1 • FaraoTortID:3 • FaraoNeve:Kádár • KezdDátum:1956 • VégDátum:1989 • ElozoFaraoID:2 • FaraoTortID:4 • FaraoNeve:Németh • KezdDátum:1989 • VégDátum:1990 • ElozoFaraoID:3 • FaraoTortID:5 • FaraoNeve:Antall • KezdDátum:1990 • VégDátum:1993 • ElozoFaraoID:4 MDH hierarchia szintek tárolása: a bizonylati elv (Documentary Principle) 1 • Felvetődik a kérdés, miért van szükség egyáltalán egy MDH hierarchia szint ábrázolásakor Minta egyedre, amikor az nem tud időbeliséget ábrázolni, és időben minden változhat? Miért nem elég a MintaTort egyed önmagában, amelynek rekordjait egy SzuloID nevű idegen kulcson keresztüli önmagára mutató 1:több kapcsolattal követési láncba akaszthatnánk? (pl. az Állam dimenzió legfelső szintjét egy FaraoTort egyed képezné, önmagára mutató 1:több kapcsolattal, és az időben egymást követő fáraók rekordjai összeláncolódnának…) • Ezzel a megoldással az a baj, hogy erre az egyedre kismillió más egyed fog 1:több kapcsolattal kapcsolódni az adatbázisban, akik nem egy konkrét, hanem az aktuális fáraóra szeretnének hivatkozni, és ekkor csak 2 nagyon-nagyon rossz megoldás közül választhatunk: • Mindenki mindig az első fáraóra hivatkozik, és az adatbázis motor a láncoláson végighaladva, egymásba ágyazott SQL lekérdezések sorozatával keresi az aktuálisat/ szúr be/ töröl a láncból, iszonyat nagy erőforráspazarlással: pl. 70 tagú lánc estén 69×egymásba ágyazott SQL kód kell, mindegyikhez egy láthatatlan ideiglenes tábla, 69×ezve a helyfoglalást működés közben. Vagy SQL helyett kódolhatjuk kézzel PL/SQL-ben vagy TransactSQL-ben a láncolás műveleteit (de akkor mi a halálnak használunk adatbáziskezelőt?) • Új fáraó beszúrásakor, az összes hivatkozó tábla összes idegen kulcsát Update-eljük az új fáraóra. Ezt SQL-ben technikailag egy-szerű programozni, de borzalmasan gép- és időigényes! • Ha viszont van Minta egyedünk, ennek rekordjai betöltik egy bizonylat (Voucher) fejlécének (Header), és minden külső egyed erre hivatkoz-hat fixen, akkor a fenti csúnya problémák nem lépnek fel! A bizonylati fejlécre 1:több ráakasztott MintaTortbizonylati tétel (Voucher Item) rekordok közt már halálosan egyszerű és gyors SQL-ben meg keresni az aktuálisat 1 reláción átugorva 1 időbeli szűrőfeltétel segítségével: SELECT FaraoTort.[Aktuális fáraó adatai] FROM Farao INNER JOIN FaraoTort ON Farao.FaraoID=FaraoTort.FaraoID WHERE FaraoTort.KezdDatum<=AktualisDatum AND (FaraoTort.VegDatum>AktualisDatum OR IsNull(FaraoTort.VegDatum));

16. t MDH hierarchia szintek tárolása: a bizonylati elv (Documentary Principle) 2 Mindezen megfontolásokat összefoglalva, a bizonylati elv (Documentary Principle) azt jelenti: • A szervezet összes adatát teljes életciklusában (Lifecycle) (Létrehozás/ Olvasás/ Módosí-tás/ Archiválás/ Törlés) történetileg nyomon kell követni a felelősségekel (Létrehozó, Utol-só módosító fehasználó) együtt • Bizonylatok (Voucher) segítségével, amelyek 1 fejléchez (Header) csatolva többbizony-lati tételt (Voucher Item) tárolnak egy listában, amelyek folyamatosan egymáshoz csatla-kozó, egymást időben kölcsönösen kizáró, balról zárt, jobbról nyitott időintervallumokat (Connected, Mutually Exclusive, Left-closed, Right-opened Time Intervals) ábrázolnak (nem lehet közös részük): • A bizonylatra minden külső hivatkozás a fejlécen keresztül történik, ezért ezek nem módosulnak a bizonylati tételek változásával. A fejlécből kiindulva a tételek egyetlen 1:több reláción áthaladva, időbeli szűrő segítségével gyorsan, egyszerűen kereshetők A bizonylati elv MDH hierarchikus szintekben történő alkalmazásának további üdvös hatása az, hogy jóval egyszerűbb szerkezetűek és könnyebben szabványosíthatók lesznek a karbantartást (Létrehozás/ Olvasás/ Módosítás/ Archiválás/ Törlés) végző tárolt eljárások: 5.1.ESETTANULMÁNY: Tömegközlekedési Vállalat (TV): (a teljes ERD-t lásd: MassTransportERD.vsd, az időkezelési és import/export rendszer ERD-je: DataLoggingERD.vsd, az ezt karbantartó eljárások BPD-je: DataLoggingBPD.vsd): • A TV helyiérdekű buszjáratokat üzemeltet nagyvárosokban, járatnyilvántartó és utas-tájékoztatási rendszere MSSQL2000 szerveren lévő relációs adatbázis, amely kétirányú GPRS kapcsolatban van a buszokon elhelyezett fedélzeti számítógépekkel (FSZG), amelyek valójában nem rendes ipari PC-k, hanem költségtakarékossági okokból megnövelt memóriával és GPS-vevővel felszerelt mikrokontrollerek, amelyek meg tudják határozni a busz pillanatnyi koordinátáit, és a memóriájukban tárolt járat-adatbázisból ennek megfe-lelő feliratokat/ábrákat írnak ki a buszon feszerelt elektromágneses utastájékoztató táblákra (távlatilag pedig LCD-képernyőkre), illetve automatikusan összeállított hangfel-vételeket játszik le a busz hangszórórendszerén: pl. várható késés/sietés előző/ következő megálló, járatinformációk, csatlakozások, menetidő, stb. • A mikrokontrollerekre C#-ban írtak egy nagyon leegyszerűsített adatbáziskezelőt, amely az SQL szerveren tárolt központi adatbázis kicsi, leegyszerűsített verzióját tükrözi le, onnan rendszeres időperiódusonként (általában éjszakánként) frissül, illetve a busz mozgásával, üzemanyag-fogyasztásával, tengelyterhelésével, pillanatnyi- és átlagsebes-ségével kapcsolatos adatokat tölt fel (elsősorban a sofőrök üzemanyag-lopásának megakadályozására és az agresszív, rossz sofőrök kiszűrésére)

17. Tömegközlekedési vállalat esettanulmány 1 A következőkben a TV rendszer járat-nyilvántartási dimenziójának kis ré-szét tárgyaljuk,csak a felső szinteket: • Forda, FordaTort: bizonylat fej/téte-lek adott járműfajta (JarmuFajtaID) biznyos napokból álló időszakhoz (NapTipusID) rendeléséről, időben változó módon • FordaSzakasz, FordaSzakaszTort: a Forda-hoz tartozó napok napsza-kokra (NapSzakTipusID) bontása, kézi felülbírálati lehetőséggel (Kezd-Ido, VegIdo, OsztottIdoKezd, Osz-tottIdoVeg), időben változó módon • FordaSor, FordaSorTort: adott jár-műfajta, adott időszak adott napsza-kában adott Járat (pl. 6-os busz) ré-szét képező Viszonylaton (pl. Kon-zum..Kertvárosi buszpályaudvar) érvényes Menetido-sorozathoz (pl. Konzum:indulás+15min, Zsolnay-szobor:indulás+16min, stb.) rende-lése,konkrét (Indul) és (Erkezik) idő-pontokkal, időben változó módon. (A sofőr képzettsége, személye, és a konkrét jármű ezen a szinten még nincs rögzítve, azt a dimenzió alsóbb szintjei intézik) Mindhárom szint táblapárjaiba azonos nevű …Temp táblákból importáljuk az adatokat (ezeket korábbi szoftve-rek munkaképernyői töltik), és a tör-ténet táblákat azonos nevű Fed… táblákba tükrözzük az FSZG-kre.

18. ADataLoggingBPD.vsdszerint: • A legfelső szinten (Forda) egy importvezérlő nyit egy tranzakciót és meghívja az importálást a FordaTemp táblából, amit felhaszn. tölt • Ennek aktuális rekord-elé-rését gyorsító kurzort nyi-tunk, majd elenőrizzük a kötelező mezők kitöltöttsé-gét, és az idegen kulcsok-ra a referenciális integritást • Ha még nem tároljuk az a-dott FordaSzamú fordát, akkor beszúrjuk Forda-ba • Ezután aFordaTortbe pró-báljuk beszúrni a Forda-Temp rekord tartalmát, ha nem ütközik nem írható, éppen aktív rekordokkal: • Levágjuk az előző történet rekord végét, ha új belelóg • Vágjuk a következő elejét • Töröljük az új által időben átfedett történet rekordot • Megnyújtjuk az utolsót, ha nem éri el a vége az újat • Ezután Fordabeszúró el-járás beágyazva mehívja az alsóbb szintű Forda-Szakasz beszúró eljárását és egy GyerekRekordban átadja neki az a felső szint lentebb meghivatkozandó adatait (FordaSzam) Mérf.kő:Vezérlő |Kitölt.ell |Ideg.kulcs.ell |Elsődl.kulcs ell. |Hier.tölt |Tört.tölt |Gyerek hív Forda Tortek Forda Tempek FordaSzak FordaSzak Tortek FordaSzak Tempek FordaSor FordaSor Tortek FordaSor Tempek Fordák FordaSzak beszúr GyerekRekord FordaSzam GyerekRekord FordaSzakKod Beszúrandó ütközik időben nem írhatóval? Következő elejét vág Előző végét vág utolsóvég lekérdez Utolsó hosszabbít FordaSzakTort beszúr Átfedett letöröl Utolsó után rés? Idegen kulcsok léteznek? Van már ilyen Forda rekord? Kötelezők kitöltve? Gyerek rekord tölt Gyerek hív Kurzor nyit FordaSor beszúr Beszúrandó ütközik időben nem írhatóval? Következő elejét vág Előző végét vág utolsóvég lekérdez Utolsó hosszabbít FordaSorTort beszúr Átfedett letöröl Utolsó után rés? Idegen kulcsok léteznek? Van már ilyen Forda rekord? Kötelezők kitöltve? Kurzor nyit TV esettanulmány 2: Import karbantartó eljárások Import vezérlő Tranzakc nyit Forda beszúr Beszúrandó ütközik időben nem írhatóval? Következő elejét vág Előző végét vág utolsóvég lekérdez Utolsó hosszabbít FordaTort beszúr Átfedett letöröl Utolsó után rés? Idegen kulcsok léteznek? Van már ilyen Forda rekord? Kötelezők kitöltve? Gyerek rekord tölt Gyerek hív Kurzor nyit

19. TV esettanulmány 3: karbantartó eljárások szerkezete, Összegzés • A FordaSzakaszokat beszúró eljárás csak az ennek megfelelő forda szakaszait szúrja be, és nem mindenféle fordához tartozó szakszt tömegesen! • Folytatólagosan, a FordaSzakaszokat beszúró eljárás is meghívja a végén beágyazva az ő alantas szintjét, a FordaSorokat beszúró eljárást, egy GyerekRekordban átadva neki a felettes szint meghivatkozandó adatait (FordaSzakaszKod) • A FordaSorokat beszúró eljárás csak az ennek megfelelő fordaszakasz sorait szúrja be és más sorokat nem! A fentiekből látható, hogy az MDH hierarchikus szintek egymást beágyazva hívogató import eljárásai úgy szúrják be az importálandó táblák rekordjait, ahogy egy fa nő: • Már létező főágakból növesztenek ki al-ágakat, és azokból al-alágakat, stb. • Ez sokkal biztonságosabb módszer, mintha különböző hierachikus szintek tartalmát az összefüggések ellenőrzése nélkül, egyszerre, tömegesen beöntenénk az adatbázisba • A többi karbantartó eljárás (törlő és exportáló eljárások) ugyanilyen módon működnek: hierarchikusan egymásba ágyazva hívogatják egymást. Összegezve az eddig elhangzottakat, elmondhatjuk: • Az MDH szerkezet dimenziókba, azonbelül szintekbe szervezi az adatbázis egyedeit • Minden szintet történetiségében maximum 4 egyed ír le (Minta, MintaTipus, MintaTort, MintaStatusz), de nem mindig létezik mind a 4, pl. ha nem kell történetet ábrázolni. A 4 tábla rendkívül gyosan klónozható előre definiált tábla sablonokból • Minden szinthez definiálhatunk karbantartási célú (Importáló-felülíró, Törlő, Exportáló) tárolt eljárásokat • Ezek az összes dimenzió összes szintjén egy sztenderd szerkezet alapján működnek, nagyon kis helyi változtatásokkal, ezért rendkívül gyorsan klónozhatók általános sablonokból kiindulva • Egy dimenzión belül a felsőbb szint adott célú karbantartó eljárása mindig meghívja beágyazva az alsóbb szint hasonló célú karbantartó eljárását • Látható, hogy az MDH-szerkezet következetes alkalmazása nemcsak az adatbázis tárolási rendszerét segít hatékonnyá teni, hanem a rengeteg karbantartó eljárás programozását is egyszerűsíti és felgyorsítja!

20. Szakirodalom Időmodellezés hópehely struktúrában (magyarul): http://users.iit.uni-miskolc.hu/~kovacs/db2/ora10.html Adatok 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 Bizonylatolás: Bizonylati elv (magyarul): www.jgytf.u-szeged.hu/tanszek/kozmuv/nagy/segedanyag/szamvitel1.doc