Adatbázis-tervezés konzultáció 10. Előadás Dr. Pauler Gábor, egyetemi docens, ev. Adószám: 63673852-3-22 Számlaszám: 50400113-11065546 Telephely: 7666.

Adatbázis-tervezés konzultáció 10. 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.hupauler@t-online.hu

Az előadás tartalma A tömegközlekedési adatbázis rendszer háttere Tömegközlekedési vállalat forgalomszervezése az MDH-ban A Tér dimenzió speciális részei A Vonal dimenzió A Forda dimenzió Tömegközlekedési vállalat utastájékoztatása az MDH-ban Feliratok kezelése Hangok kezelése MDH struktúra mobilinformatikai eszközökre telepített kis teljesítményű adatbáziskezelőn történő leegyszerűsített tükrözése Egymást kölcsönösen kizáró történetek egyszerűsített ábrázolása Az alapvető dimenziók egyszerűsített ábrázolása Tömegközlekedés-specifikus dimenziók egyszerűsített ábrázolása Szakirodalom

A tömegközlekedési adatbázis rendszer háttere A Session5–ben már említésre került a Tömegközlekedési Vállalat (TV):Session5 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) A Session5-ben elemeztük már MDH-struktúrában az idő- és műszakkezelését, foglalkoztunk a járatnyilvántartás történeti kezelésével és karbantartó eljárásaival, a Session8-ban megtárgyaltuk a jármű-nyilvántartását. mostani anyagrészünkben 3 másik területével foglalkozunk (ld.:MassTransportERD.vsd):Session5Session8MassTransportERD.vsd A forgalomszervezési dimenziók szerkezete, kapcsolódása más dimenziókhoz. A fedélzeti utastájékoztatási rendszerek szerkezete. Ezt a 2 egységet úgy tár- gyaljuk, hogy általánosítható legyen más tömegközlekedési rendszerek esetére Az MDH struktúra fontos dimenzióinak leegyszerűsített tükrözése a fedélzeti mobil informatikai eszközök adatbáziskezelőin

Forgalomszervezés: a Tér dimenzió speciális részei 1 A forgalomszervezési adatbázishoz szükséges, hogy az MDH Tér dimen- zióját kiegészítsük néhány tömeg- közlekedés-specifikus elemmel: A Megallo egyedhez kötődő tábla- négyes a megállóhelyeket történeti- ségükben írja le. Első ránézésre a megállót statikus CimID címmel és PontID koordinátaponttal azonosított helynek gondolnánk, de valóságban majdnem annyit mászkál, mint az autóbuszok: –Forgalomszervezési okok miatti végleges áthelyezés (ez a ritkább) –Építkezések miatti ideiglenes áthelyezés (ez a gyakoribb) –A GPS pontatlanságai miatti „mászkálás”: hosszas gyakorlati tapasztalat, hogy háború esetén az USA 8-9 méter random hibát visz bele a GPS rendszerbe, amit csak a felkészített katonai vevők tudnak helyesen kompenzálni, nehezítendő az ellenfél GPS- alapú célzását. Ilyenkor a megálló „sávot válthat”. Ezt úgy oldjuk fel, hogy a megálló mért koordinátáit hosszú időn keresztül átlagolva megkapjuk a tényleges helyét, és a járművek koordinátáit 8-9 méteres sugarú körön belül ehhez „hozzátapasztjuk”

Forgalomszervezés: a Tér dimenzió speciális részei 2 A korszerű városi közlekedésben egyes forgalmi lámpa csoportok a közlekedési helyzettől függően a vezérlési ciklusuk adott pontjain „zöld utat” nyithatnak a tömegközlekedési járművek közeledtére (a nyitást egy független rádiótáv- irányító rendszer végzi a jármű fedélzetéről): A ForgLampaCsop egyed ír le egy csomópontot, amely középpontja adott PontID koordinátákban van, adott CimID cimen, a megközelítési irányban a DirektKozTer, keresztirányban a KeresztKoz- Ter utcák/utak alkotják, ForgLampaTipus típusú lámpákkal van felszerelve, és az aktuális irányba néző lámpáknak ForgLampaCsopKod a kódja Az ehhez 1:több kapcsolódó ZoldUt egyed írja le, hogy a jármű mely ForgSavBolID ForgSavBaID kap ZoldUtTipus jellegű szabad utat. Látható hogy intenzíven használjuk a Tér dimenzió koráb- ban definiált, forgalmi sávokat leíró részeit (ld.: MassTransportERD.vsd), így a zöld út definíciója viszonylag egyszerű marad! MassTransportERD.vsd A zöld utak történetiségét a ZoldUtTort egyed írja le: időben változhat az rádiótávirányítású nyitást végző un. SiemensKod, valamint a zöld út nem csak egyszerűen valamilyen Kezd/VegDatum közt él, hanem bonyolult ciklikus idődefiníció tartozhat hozzá (pl. adott zöld út csak nyári szünidőben, péntek de. 9-11-ig működik), amit a NapTipusID, NapSzakTipusID idegen kulcsokkal írunk le. Megint csak intenzíven építünk az MDH sztuktúra fejlett Idő dimenziójára (ld. Session5), így a zöld út történeti szerkezete viszonylag egyszerű maradhat.Session5

Forgalomszervezés: a Vonal dimenzió 1 Általában véve, a tömegközlekedési rendszerek legnagyobb, legkevésbé változó egysége a Vonal. Ez azonban csak elméletben igaz: A vonalak vonalcsaládokba tömörülnek (pl. egy városban a 3-mal kezdődő számú vonalak egy végállomáshoz kötődnek) Nagyobb városokban vonalnak lehetnek alverziói (pl. 7-eshez 107-es, vagy piros 7-es gyorsjárat) A kisebb városokban viszont ezek hiányoznak. Ezért ezt nem fix szintszámú hierarchiaként oldjuk meg, hogy ne kelljen annyi egyedet feleslegesen definiálni: a Vonal egyednek önmagára mutató 1:több kapcsolata van a SzuloID idegen kulcson keresztül, és a VonalSzintID mutatja melyik szinten járunk. Ha kell, a VonalSzinID jelzi, ha adott vonal a VonalSzam melett színjelölést is kap A vonalaknak természetesen jelentős történetisége is van, amit a VonalTort egyed ír le. It megadhatjuk, hogy a vonal mily Kezd/VegDatumok közt létezik, illetve ciklikusan mely NapTi- pusID, NapSzakTipusID által jelölt időszakokban. Ezenkivül a később ismertetett Médiatár dimenzióból vonal felvezető bemondó hang (HangID) és felvezető feliratok (FeliratCsopID) tartoznak hozzá (pl. „7: Városháza- Állatkert- Városháza”)

Forgalomszervezés: a Vonal dimenzió 2 A Vonalra 1:több csatlakozik az alatta lévő hierarchikus szint a Viszonylat. Egy vonal általában két viszonylatra oszlik, az „Oda”- és „Vissza” irány szerint, amit a ViszonylatTipusID ábrázol. Ez akkor is igaz, hogy ha a járművek fizikailag nem azonos útvonalon közlekednek oda és vissza, hanem körjáratban. A ViszonylatTort szerkezete lényegében megegyezik a VonalTort egyedével, a funkciója az, hogy adott vonal oda- és vissza viszonylatához különböző napokon és napszakokban történő közlekedést lehessen definiálni (ami bizony a valóságban gyakran előfordul), illetve viszonylatonként eltérő felvezető hangot és feliratcsoportot. Innen tudják ugyanis az utasok, hogy ha a végállomáson szállnak fel, jó irányban közlekedő járműre szálljanak. Gyakran látunk olyan esetet, hogy a végállomásra beérkező jármű sofőrje felveszi a megzavarodott utast, aki eltévesztette a viszonylatot, poénból viszi még 50 métert, majd kölcsönös beanyázások közepette kidobja. helyes viszonlat felvezető hangok és feliratok esetén ez ritkábban fordul elő

Forgalomszervezés: a Vonal dimenzió 3 A Viszonylat tovább bontható az 1:több kapcsolódó ViszonylSzakasz egyed által leírt szakaszokra. Ennek az a célja, hogy meg lehessen határozni megállók olyan egymást követő csoportját, amelyek bizonyos esetekben kimaradnak (pl. a 7- es hétvége és munkaszüneti napok kivételével nem megy be az állatkerten belüli megállókhoz). A ViszonylSzakaszTort egyedben ugyan a MegalloSorszam jelöli, a viszonylat hányadik megállójától kezdődik a szakasz, de ez nem fix információ: ha megállók/szakaszok kimaradnak, erősen változhat. Ezért a viszonylat fix definíciója nem is ezen alapul, hanem: A Viszonylat egyedhez 1:több kapcsolódik a ViszonylatSor egyed, amely adott viszonylaton lehetséges összes megálló definíciója, MegalloID fizikai helyekre hivatkozva. A Viszonyl- Szakasz kezdetét ezért a kezdő ViszonylatSorID hivatkozásként adjuk meg, ami az időtől független

Forgalomszervezés: a Vonal dimenzió 4 A ViszonylatSor egyedhez kötődő MDH dimenzió hierarchia-szint leíró tábla- négyes modellezi, hogyan jelenik meg egy Megallo az adott Vonal adott Viszonylatán Az érdemi információkat a Viszonylat- SorTort egyed tárolja, hiszen ezek időben mind megváltozhatnak: A MegalloSorszam egy MegalloTipusID típusú („Fix”/”Ideiglenes”) MegalloID kódú megálló sorszáma az adott viszonylaton, ami MTavMertEgysID mértékegy- ségben mért MegalloTav távolságra van az előző megállótól (általában átlagos forgalmi viszonyokra számított menetidő- percként adják meg) Adott Kezd/VegDatum közt, NapTipus- ID, NapSzakTipusID ciklikus időszakok- ban képez megállót A megálló után ZoldUtID jelzésű zöld utat nyithat a jármű a következő forgalmi lámpánál ZoldUtStratID stratégia alapján (a stratégiák leírásával nem foglalkozunk, mert ezt a Siemens rendszer végzi, csak a kódjukat tároljuk. A stratégia arra vonatkozik, hogy a forgalmi lámpa ciklus mely pontjain kaphat a jármű zöld utat) FeliratCsopID-vel jelölt feliratcsoport jelenik meg a járművön a megálló adott sugarú körzetébe történő belépéskor AtszallasID-vel jelölt átszálláscsoport tartozik hozzá más vonalakra

Forgalomszervezés: a Vonal dimenzió 5 Az Atszallas egedhez kötődő táblané- gyes adott Vonal adott Viszonylatának adott Megallojában (ViszonylatSor) fellépő átszálláscsoportot ír le (pl. „a 7-es Petőfi utcai megállójában át lehet szállni: a 31-es, a piros 31-es buszra és a 4-es villamosra”) Az AtszallasTort egyed lényegében csak az átszállási listát felvezető feliratcsoportot (FeliratCsopID) és hangot (HangID) tárolja (pl. „a 7-es Petőfi utcai megálló- jában át lehet szállni:”), valamint, hogy az átszálláscsoport milyen időben érvényes (Kezd/VegDatum, NapTipusID, NapSzakTipusID) Felvetődik a kérdés, miért kell a Vonalak- hoz, Viszonylatokhoz, ViszonylatSorok- hoz, Atszallasokhoz külön felvezető hangot tárolni, miért nem lehet ezeket előre rögzített kulcsszavakból összerakni, ami a tárolás helyigénye miatt jóval hatékonyabb megoldás lenne? A gyakorlatban bebizonyosodott, hogy a megfelelő hangsúlyozás nélkül, gépileg szavakból összelegózott szöveg a jármű háttérzaja mellett teljesen érthetetlen, ezért kell minden szinten külön felvett felvezető szöveget tárolni.

Forgalomszervezés: a Vonal dimenzió 6 Az AtszallasSor egyed és a hozzá kötődő táblanégyes adott Vonal adott Viszonylatának adott ViszonlatSorával definiált megállóhoz kötődő Atszallas csoport átszállási lehetőségeit írja le tételesen (pl. „a 31-es, a piros 31-es buszra és a 4-es villamosra”) Az AtszallasSorTort egyed tárolja, az átszállási lehetőségek közt milyen más ViszonylatID-vel jelölt viszonylatokat emlitünk és hányadikként (AtszallasSor- szam), milyen időszakokban (Kezd/Veg- Datum, NapTipusID, NapSzakTipusID)

Forgalomszervezés: a Vonal dimenzió 7 A MenetIdo és a hozzá kötődő táblanégyes az adott Viszonylaton érvényes összesített menetidőt ábrázolja (pl: „7-es Városháza –Állatkert viszonylaton 35 perc, munkaszüneti napok kivételével”) A MenetIdoTort egyed írja le, hogy adott Viszonylat mennyi OsszRelIdo alatt jrható be adott időszakban (Kezd/Veg- Datum, NapTipusID, NapSzakTipusID)

Forgalomszervezés: a Vonal dimenzió 8 A MenetIdo egyedhez 1:több kapcsolódó MenetIdoSor egyed és a hozzá kötődő táblanégyes adott Viszonylaton adott időszakban érvényes összmenetidő tételes felbontását tartalmazza Viszony- latSorokkal leírt megállók szerint A MenetidoSorTort egyed irja le az adott megállóhoz tartozó ErkezRelIdo-t és a TartozkIdo-t (pl: „7-es Városháza – Állatkert viszonylat (munkaszüneti napok kivételével): 1. Megálló: Király mozi 5.5 perc, állás 30 másodperc 2. Megálló: Gyömbér cukrászda: 8 perc, állás 20 másodperc, stb.”)

Forgalomszervezés: a Forda dimenzió 1 Amíg az MDH Vonal dimenziója egy elméleti menetrend tervet ír le, hogyan kellene járműveknek térben és időben mozognia, a Forda dimenzió célja az lesz, hogy végső soron ehhez a tervhez konkrét járműveket és sofőröket rendeljen, akik a tervet teljesítik, és dokumentálja, hogyan sikerült a teljesítése: A Forda, FordaTort egyedek és a hozzájuk kötődő táblanégyes azt ábrázolja, hogy a rendelkezésre álló JarmuTipusID / JarmuAlTipusID-vel azonosított járműfajtákból milyen mennyiséget (VirtJarmuID) rendelünk biznyos napokból álló időszakhoz (NapTipusID) adott Kezd/VegDatumok közt (pl. „2008.03.01 és 2008.09.11 közt a munkanapokon 48 db 120 személyes 3 tengelyes csuklós buszra lesz szük- ség, amelyek B/T3/Sz120-001..-048 virtuális kódok alatt futnak”) Ez a járműtervezés legaggregáltabb szintje, amely csak időben osztja el a különféle típusú járműveket, és még nem foglalkozik vele, melyik Vonal melyik Viszonylatán futnak majd A terv készítésekor a jelenlegi járműállo- mányt, a várható beszerzéseket /eladáso- kat és selejtezéseket veszik figyelembe, valamint biztonsági tartalékokat képeznek meghibásodás esetére

Forgalomszervezés: a Forda dimenzió 2 A FordaSzakasz, FordaSzakaszTort egyedek és a hozzájuk kötődő táblané- gyes célja a Fordakhoz tartozó, NapTi- pusID-vel jelzett napok napszakokra (NapSzakTipusID) bontása, kézi felülbí- rálati lehetőséggel (ManKezd/ VegIdo, ManOsztottIdoKezd/Veg), időben válto- zó módon (Kezd/VegDatum) közti érvé- nyességgel Ezekhez a szakaszokhoz rendelhetők történetükben VirtSoforök, akik még nem konkrét járművezetők, hanem adott Jogo- sitvanyTipussal rendelkező alkalmazotti kontingens. A manuális beavatkozási lehetőségre azért van szükség, mert munkavédelmi jogszabályok szabályozzák, hogy egy sofőr maximum mennyi időt tölthet egyfolytában adott fajta járművön, és ez után minimálisan mennyi pihenőidőt kell kitöltenie. Ezért lehet szükség egy egy- séges 8 órás műszak kézi felosz-tására, amellett, hogy az MDH fejlett Idő dimen- ziója önmagában is lehetőséget ad osz- tott napszakok definiálására (NapSzak- TipusID) A FordaSzakasz tehát a legaggregáltabb munkaerőtervezési szint, elméleti sofő- rőket rendel elméleti autóbuszokhoz, ciklikusan ismétlődő napszakokban, de még nem foglalkozik vele, mely Vonalakon és Viszonylatokon fognak járkálni

Forgalomszervezés: a Forda dimenzió 3 A FordaSor, FordaSorTort egyedek és a hozzájuk kötődő táblanégyes adott FordaSzakasz által adott ciklikus napszakra meghatározott virtuális jármű- és virtuális sofőr kontingenst (pl. „B/T3/Sz120-001..-048 buszok S001..S048 csuklós képesítésű sofőrőkkel munkanapokon 9-11 óráig”) oszt szét térben: Adott Vonal (pl. „6-os”) adott Viszony- latán (pl. „Konzum áruház..Kertvárosi buszpályaudvar”) adott ciklikus időszakban (pl. „munkanapokon 9-11 óráig”) érvényes Menetido-sorozathoz (pl. „Konzum: indulás + 15 perc, Zsolnay-szobor: indulás + 16 perc”, stb.) rendeli őket, konkrét (TervInd- RelIdo) és (TervErkRelIdo) időpontokkal (pl. „9.05-9.45, 9.17-9.57, stb.”), időben változó módon, Kezd/VegDatumok közt (pl. „2008.03.01-2008.09.11”). Ezen a ponton kapcsolódik össze a Vonal és a Forda MDH-dimenziók tartalma, de még mindig nincs szó konkrét sofőrökről és járművekről

Forgalomszervezés: a Forda dimenzió 4 A tervezésben a következő szintet a Vezenyles egyed írja le, amely adott FordaSzakaszhoz rendel konkrét járművet (JarmuID), valamint konkrét sofőrt (SoforID) egy konkrét műszakban (MuszakID), akinek a terv szerint végig kellene járni adott FordaSzakaszhoz tartozó FordaSorokban megjelenő Viszonylatokat adott MenetIdo szerint. Ez azonban még mindig csak terv, és sok tényező hátráltatja, hogy megvalósuljuon: a jármű meghibásodik, a sofőr megbeteg- szik/ sztrájkol/ leissza magát és elkapják a szondával (a valóságban kevés sofőr képes teljesen józanul jól vezetni…), adott útvonal bejárhatatlanná válik az időjárás vagy baleset miatt, stb. Ezért a következő szint, a Jarat egyed a tényleges jármű-indulásokat dokumen- tálja FordaSorokhoz kötve. Mégegyszer felvesszük, hogy melyik SoforID milyen elektronikus kártyával (AlkKartyaID) melyik tényleges JarmuID fedélzetén indult el, mert ez egyáltalán nem biztos, hogy megegyezik a Vezenylesben részletezett tervvel, viszont a baleseti felelősségek tisztázásakor elengedhetet- lenül szükséges (pl. „Ki vezette 2008.03.01-én 18.55-kor a BZ-67-78-55 forgalmi rendszámú, 7-es jelzésű buszt, amely az elsőbbség meg nem adása miatt balesetet okozott”)

Forgalomszervezés: a Forda dimenzió 5 Az elindult Jarat ezután – jó esetben – a ViszonylatSor-terv által meghatározott térbeli pontokat, vagyis a Megallokat érinti, amit a JaratPont egyed dokumentál. Itt feljegyezzük, hogy, mi vot a tényleges ErkezIdo és TartozkodIdo, hogy össze lehessen vetni a tervvel, volt-e késés vagy sietés. Az utólagos feldolgozás gyorsítására némi helypazarlás árán prejoinolunk, és eltároljuk azt is milyen HangID, milyen FeliratCsopID volt kijelezve adott ponton, és milyen ForgalmiLampaCsop- ID zöldút-vezérlését hívta meg a jármű a megállóból elindulása után Ezenkívül, a fedélzeti számítógép érzékelőkön keresztül méri a jármű egy csomó paraméterét (tengelyterhelés – ebből az utaslétszámra lehet következtetni, üzemanyagszint, üzemanyag fogyasztás, vízhő, olajhő, ajtók állapota, sebesség, vátófokozat, stb.), ami az üzemanyag-lopó és üzemanyag-pazarlóan vezető sofőrök elleni hadjárat alapja. Ezek az adatok a JaratPontAdat egyedben tárolódnak, amely JaratPontID-hez rendel JaratAdatTi- pusID-t. (Ez a megoldás analóg a Session8-ban tárgyalt, CikkParam egyedben megvalósított, dinamikus árucikk-paraméterezési megoldással, légi közlekedésben pedig ez a „fekete doboz”)Session8 Nem pályához kötött járművek esetén lehet ennek egy sokkal tárolóhelyigényesebb verziója, amikor a Jarat teljes JaratPalyaja mentén ciklikus időközönként adatokat rögzí- tünk, szárazföldi közlekedésben azonban az ilyen szintű bontás általában nem szükséges

Forgalomszervezés: a Forda dimenzió 6 A MenetLevel egyed és a hozzá kötődő táblané- gyes egy bizonylat (Voucher)-jellegű szerkezet (lásd: Session5):Session5 Amely a MenetLevel fejlécén adott Sofor által adott Jarmuvon tejesített FordaSzakasz adatait tárolja, kiegészítve a ténylegesen megvalósult kezdő- és záróidőkkel (ElsoIndulIdo, Utolso- ErkezIdo, ManKezdIdo, ManVegIdo, ManOsz- tottIdoKezd, ManOsztottIdoVeg) A MenetlevelSor-tételekben pedig azt részletezi, hogy a FordaSzakasz FordaSoraiból, mint tervből milyen tényleges Jaratok indultak el, részletezve a tervhez képest eltérő valós időket (Indul/ErkezIdo) Ez a bizonylat a sofőrök bérszámfejtésének az alapja, amivel a rendszer mr nem foglalkozik, de adatot szolgáltat hozzá

Utastájékoztatás: Feliratok 1 Az utastájékoztatással az MDH-struktúra Médiatár dimenziója foglalkozik (ld:MassTransportERD.vsd)MassTransportERD.vsd A tömegközlekedési járműveken többféle szerepet tölthetnek be kijelzők (KijelzoSzerep): lehet front-, hát-, oldal, és utastéri oldal-/ vagy tetőkijelző. Ezeken mindegyiken többféle funkciójú felirat (FeliratFunkcio) is megjelenhet: Vonalszám, viszonylat-kijelzés, megálló-kijelzés, átszállás- kijelzés, késés-sietés kijelzés, reklám, stb. A FeliratCsop egyed és a hozzá kötődő táblák ezen rengetegféle felirat csoportosítását végzik, történeti nyomonkövetéssel, hogy a Vonalhoz, Viszonylathoz, Megallohoz, Atszallashoz, AtszallasSorhoz egyetlen FeliratCsopID idegen kulcssal komplett feliratkészletet lehessen rendelni Az ehhez 1:több kapcsolódó FeliratSzakasz, illetve FeliratSzakaszTort egyed részletezi, hogy a csoport milyen KijelzoSzerepID kijelzőre milyen FeliratFunkcioID funkciójú feliratokat tartalmaz

Utastájékoztatás: Feliratok 2 A FeliratSzakaszhoz 1:több kapcsolódik a FeliratSor egyed, illetve a hozzá kötődő táblák. Ennek a szintnek az értelme, hogy ha adott szerepű kijelző adott funkciójú felirata animált, akkor egy feliratsorozatot tud tárolni az animáció megjelenítésére A FeliratSorTort egyed határozza meg a fedélzeti számítógépen tárolt feliratfájl- okra történő hivatkozást. És az igazi káosz itt szabadul el: Régebben a kijelzők mágnestáblásak voltak, amelyek kizárólag adott fajta karaktereket tudtak megjeleníteni egy funkciójukban, így a felirat-információ tisztán karakteres lehetett Később bevezették a pixel-mátrix alapú mágnestáblás kijelzőket, amelyek már egyszerűbb grafikákat is megjelenítettek és formázni is tudták a betűket, ezért formázó vezérlőkarakterek kerültek a felirat-szövegekbe, amelyek természete- sen nem szabványosak a különböző típusú kijelzők közt, ezért a KijelzoMezo- ID idegen kulccsal megjelölve egy feliratot több kijelzőtípusra is tárolni kell! A drága és érzékeny (hideg, meleg, pára, vandálok, rázkódás, stb.) mágnestáblás kijelzőket rohamosan szorítják ki az egyre olcsóbb LCD-s óriáskijelzők, amelyek képfájlokból (FajlPozicioTol, FajlPozi- cioIg) nagy felbontású színes grafikát jelenítenek meg. A közeljövőben várható, hogy az adatbázisterv ezen része kifejlő- dik HTML-oldalakat és a hozzájuk tartozó

Utastájékoztatás: Hangok elemeket tároló adatbázissá, amelyeket egy érintőképernyős beltéri LCD akár interaktívan is megjeleníthet A Hangok és történetük tárolása jóval egyszerűbb műfaj, mert a kellő erejű hang – amely a jármű és azutasok valamint a környezet zaja mellett is jól hallható - a jármű utasterében igen kevéssé szepa- rálható, ráadásul jóval lassabb kommu- nikációs csatorna, mint a feliratok, így alkalmazása korlátozott. Elkészítése ezzel szemben igencsak élőmunka-igényes, mert a beszédszintetizátorok még nem tartanak olyan fokon, hogy automatikusan alkossanak szövegből olyan érthető módon hangsúlyozott mondatokat, amelyek a nagy alapzaj mellett is érthetők!

Forgalmi és utastájékoztatási rendszer fedélzeti mobil eszközökre tükrözése Az előzőekben láthattuk, hogy mind a Vonal, mind a Forda MDH dimenzióknak 8-9db szintje van, szintenként 3-4db táblával Felvetődik a kérdés, hogy hogyan lehet ekkora adatbázis szerkezetet letükrözni a járművek fedélzeti számítógépeinek operációs rendszerein (Windows Mobile, Palm OS, Symbian, Linux, stb.) futtatható kis kapacitású, egyszerű adatbázis- kezelőkbe, és ott gyorsan lekérdezni Az nem megoldás, hogy a fedélzeti számítógép ne tároljon semmit, hanem online kérdezgesse a szervert minden sarkon real time, mit írjon ki a kijelzőkre: ez vagy fizikailag nem fér bele a kommunikációs csatorna sávszélességébe, vagy nagyon gazdaságtalan ekkora sávszélességet fenntartani az irányító központ és a járművek közt Ekkor viszont szembesülünk azzal, hogy egy kis kapacitású, egyszerű adatbázis motornak akár 17 nagy táblát kellene össze joinolnia egy felirat előbányászásához, másodperceken belül. A helyzetet esetünkben súlyosbította, hogy a fedélzeti számítógép nem igazi ipari PC volt, hanem takarékossági okokból egy feltupírozott mikrokontroller, amin C#-ben futott egy alap adatbázis motor, amely csak az elsődleges kulcsokat volt képes indexelni, az idegen kulcsokat nem!!! Viszont az is nyilvánvaló, hogy a fedélzeti mobil eszközön nincs szükség olyan bonyolultságú adatbázis struktúrára, mint a szerveren: a fedélzeten soha nem fogunk előtervezést, történeti karbantartást végezni, és főleg csak lekérdezünk, az adatbázist csak néhány egyszerűbb tábla tekintetében írjuk (Jarat, JaratPont, JaratPontAdat, JaratPalya, JaratPalyaAdat) Így nagyon fontos szabály, hogy a szerveren lévő MDH-struktúrát sohasem szabad 1 az egyben letükrözni a fedélzeti eszközre! (ld.: DataLoggingERD.vsd)DataLoggingERD.vsd

Tükrözés: Leegyszerűsített adatbázis szerkezet A fő trükk itt az, hogy az egyes MDH dimenzió-szintek (lásd: Forda, FordaSzakasz, FordaSor) statikus- és történeti táblit egybeolvassuk egy lekérdezéssel szintenként 1 táblába (FedForda, FedFordaSzakasz, FedFordaTort), és ezt exportáljuk a fedélzeti mobil eszközre. A fedélzeti tábla mind a statikus, mind az időben változó adatokat tárolni fogja, némi helypazarlás árán (pl. a FedForda egyed minden For- daTortID-vel azonosított rekordjában letárolja a Forda egyetlen statikus adatát, a FordaSzam külső azonosítót) Így kiesik a statikus tábla és a törté- nete közti reláció, és az átlagos fedélzeti lekérdezésekben a pici adatbázis motor által feldolgozandó relációk száma a felére csökken, a számolási idő a négyzetgyökére! A fedélzeti táblaszerkezet egy igen furcsa valami lesz: önmagában nem alkot relációs adatbázist, de egy adott időpillanatban érvényes törté- neti rekordok szintjén azzá válik (Time Window Based Relational Data Structure, TWBRDS): pl. a FedForda és FedFordaSzakasz egyedek nyilván 1:több kapcsolatban állnak, de a FedForda Forda- TortID elsődleges kulcsára egy icike- picike idegen kulcs sem hivatkozik

Tükrözés: Karbantartó eljárások a FedFordaSzakasz táblában. Viszont van benne FordaID, ami viszont nem elsődleges kulcs a Fed- Forda táblában, megismétlődik minden azonos fordához tartozó történeti elemnél, így a hivatkozás nem egyértelmű. Azonban, mivel az MDH-ban a történet jellegű táblákban a rekordok egymást kizáró, folyamatosan csatlakozó időintervallumokat alkotnak, ha az összes fedélzeti táblában inaktiváljuk azokat a rekordokat, amelyek nem érvényesek az aktuális időpillanatban, a maradék relációs adatbázist fog alkotni! Ilyenkor a FedFordaSzakasz.FordaID már egyértelműen hivatkozik a FedForda.FordaID-re, mert egy időpontban érvényes rekordokat tekintve a FordaID ott egyedi! A trükk karbantartó eljárásai (DataLoggingBPD.vsd):DataLoggingBPD.vsd Az első a szerveren fut, az adott dimenzió szint statikus és történet tábláját inner joinolja egybe és exportája a fedélzeti táblába, exportált „E” státuszúnak jelölve a történeti rekordokat A második is a szerveren fut, várakozó „V” státuszt ad az exportált, de még nem aktív rekordoknak, ha „eljön az idejük” „A”-ra állítja őket, ha lejár, „R”-re, és ezenkívül letörli a történet táblából a már réges régen fedélzeti rendszerbe exportált rekordokat A harmadik a fedélzeti eszközön fut, folyamatosan körözik az összes fedélzeti tábla összes rekordján: –-1-re állítja azon rekordok státuszát, amelyeknek „még nem jöt el az ideje”, –0-ra az adott időpontban éppen érvényesek státuszát (minden fedélzeti lekérdezés minden táblára WHERE Statusz=0 szűrővel fog futni!!!) –+1-re állítja azon rekordok státuszát, amelyeknek már „lejárt az ideje”, és ha ez régen történt, le is törli őket

Tükrözés: Alapvető dimenziók Az alábbiakban az Idő, a Hely, a Szervezet és a Jármű dimenziók fedélzeti verzióit láthatjuk az egymást követő tábla-oszlopokban balról jobbra. Figyeljük meg, mennyivel egyszerűbb és kevesebb táblát tartalmaz ez a szerkezet a szerveren lévőhöz képest! Természetesen ez karbantartási képességeinek jelentős csökkenésével jár, de a fedélzeti rendszerben ez nem szempont

Tükrözés: Tömegközlekedés-specifikus dimenziók 1 A következőkben a bonyolultabb dimenziók (Vonal, Forda, Médiatár, Fedélzeti eszközök) fedélzeti verziójának táblaoszlopai láthatók A relációk csirkelábait azért nem rajzoltuk be, hogy érzékeltessük, ezek a táblák alapban NEM alkotnak relációs adatbázist, csak az egy időpontban érvényes rekordjaik!

Tükrözés: Tömegközlekedés-specifikus dimenziók 2 A következőkben a bonyolultabb dimenziók (Vonal, Forda, Médiatár, Fedélzeti eszközök) fedélzeti verziójának táblaoszlopai láthatók A relációk csirkelábait azért nem rajzoltuk be, hogy érzékeltessük, ezek a táblák alapban NEM alkotnak relációs adatbázist, csak az egy időpontban érvényes rekordjaik!

ESRI Inc. térinformatikai-szállítási adatmodell (angolul): http://www.esri.com/industries/transport/resources/data_model.html http://www.esri.com/industries/transport/resources/data_model.html Szállítással kapcsolatos honlapok linkgyűjteménye (angolul): http://faculty.washington.edu/krumme/transport/sites.html http://faculty.washington.edu/krumme/transport/sites.html Cikk tömegközlekedési adattárházak építéséről (angolul): http://www.scielo.oces.mctes.pt/pdf/iop/v26n1/v26n1a02.pdf http://www.scielo.oces.mctes.pt/pdf/iop/v26n1/v26n1a02.pdf Szakirodalom

Adatbázis-tervezés konzultáció 10. Előadás Dr. Pauler Gábor, egyetemi docens, ev. Adószám: 63673852-3-22 Számlaszám: 50400113-11065546 Telephely: 7666.

Hasonló előadás

Az előadások a következő témára: "Adatbázis-tervezés konzultáció 10. Előadás Dr. Pauler Gábor, egyetemi docens, ev. Adószám: 63673852-3-22 Számlaszám: 50400113-11065546 Telephely: 7666."— Előadás másolata:

Hasonló előadás

Projectumról

Visszajelzés

Bejelentkezés

A társadalmi hálózaton keresztül belépni:

Adatbázis-tervezés konzultáció 10. Előadás Dr. Pauler Gábor, egyetemi docens, ev. Adószám: 63673852-3-22 Számlaszám: 50400113-11065546 Telephely: 7666.

Hasonló előadás

Az előadások a következő témára: "Adatbázis-tervezés konzultáció 10. Előadás Dr. Pauler Gábor, egyetemi docens, ev. Adószám: 63673852-3-22 Számlaszám: 50400113-11065546 Telephely: 7666."— Előadás másolata:

Hasonló előadás

Projectumról

Visszajelzés