Esettanulmány: Mozi helyfoglaló rendszer adatbázisának visszafejtése

Adatbázis-kezelés, Adatbázis tervezése

Szabályok és technikák

Esettanulmány: Mozi helyfoglaló rendszer adatbázisának „visszafejtése” Eddig leginkább az adatbázis-tervezés lépéseivel és az adatmodell elemeivel foglalkoztunk. Egyszerű példákat mutattunk be, amelyek igazából nem érzékeltették a feladat nehézségét, és azt, hogy a tervezés során ajánlatos ismernünk néhány szabályt és technikát, melyeket alkalmazva a problémák zűrzavarában hatékonyan el tudunk igazodni. Tehát mivel nem foglalkoztunk?

Az erdő és a fák Mindannyian ismerjük a mondást: „Nem látja a fáktól az erdőt.” Mit jelent ez a mi esetünkben? Amikor adatbázis-feladatot kapunk, természetes, hogy adatok halmazába ütközünk, hiszen a valóságban konkrét adatokkal, és nem fogalmakkal találkozunk. Az adatmodellezés azt mondja, hogy határozzuk meg az egyedeket, aztán a feladat szempontjából fontos tulajdonságokat, azonosítókat; definiáljunk kapcsolatokat stb. De mit látunk a valóságban? Adatok tömegét, melyet jól-rosszul szerkesztett adatlapokon, nyomtatványokon és egyéb bizonylatokon tárnak elénk. Később az is kiderülhet, hogy a valóban fontos adatok mindenféle cetliken, füzetekben találhatók, melyekről kezdetben nem is tudtunk.

Példa bonyolultabb adatbázisra Nézzük az alábbi példát! Biztos sokan ismerik a Palace mozik internetes jegyrendelő szolgáltatását (www.palacecinemas.hu). A jegyrendelő rendszer feladata az, hogy lehetővé tegye adott moziba egy kiválasztott filmre és időpontra jegyek foglalását. Ehhez elénk kell tárnia a kínálatot, és regisztrálnia kell a foglalásunkat. Miután sok előadásra sok vevő foglal jegyet mindenféle paraméterek mellett, az adatok tárolásának és későbbi visszakeresésének megoldása nem egyszerű.

Készítette: SZÁMALK Zrt, Szakképzési Igazgatóság

1



Ennek a rendszernek a felületét (illetve annak minket érdeklő részletét) látjuk az alábbi képen:

1. ábra Palace mozik műsora

Próbáljuk meg rekonstruálni azt az adatbázist (legalábbis annak egy lehetséges megoldását), ami a jegyfoglaló rendszer mögött van! (A feladat hasonló, mint amikor megbízást kapunk egy cég ügyviteli rendszerének számítógépesítésére). Itt most annyi a feladatunk, hogy a látottakat és azokat az adatokat, melyeket nem látunk, de szükségesek, egy olyan adatbázisba szervezzük, amely ki tudja szolgálni a jegyfoglalás igényét. Hogy mi ez az igény, azt ki is próbálhatjuk. A feladat megoldása során – a háttérben – feltételezzük, hogy a konkrét megvalósítás relációs adatbázis-modellel történik majd.

Tegyük fel, hogy a Campona moziban meg akarjuk nézni az Este című filmet. Ketten mennénk, stílusosan valamikor este. Ehhez a következő műveleteket kell végrehajtani (javasoljuk az olvasónak, hogy ha nem ismeri, valóban játssza végig velünk): 1. 2. 3. 4. 5.

mozi kiválasztása (fent, a filmhirdetések felett) nap kiválasztása (csak maximum 3 napra előre lehet foglalni) a film kikeresése után kattintunk az előadás időpontján megadjuk a jegyek darabszámát kiválasztjuk az ülőhelye(ke)t


2



2. ábra Előadás kiválasztása

Az időponton való kattintás után a jegyek számát adjuk meg:

3. ábra Jegyek számának megadása

A hosszú gombra kattintva pedig eljutunk a hely kiválasztásához.


3



Itt a mozi adott termének térképén olyan zöld területre kell kattintani, amely mellett balra van annyi hely, amennyi jegyet korábban rendeltünk. Foglalásunkat sárga téglalapok jelzik.

4. ábra Helyválasztás

A foglalást a jobb alsó sarokban megadott jelszóval (ezt kell majd a pénztárnál bemondani) és a Foglalás gombra kattintással véglegesíthetjük. Tehát ez a jegyfoglalás folyamata: ahhoz, hogy ez működjön, a rendszer rengeteg adatot bocsát a rendelkezésünkre, és mi is közlünk vele néhányat. Láthatjuk, hogy a feladat már nem olyan egyszerű, mint korábbi példáink. Hogyan fogjunk hozzá?

Az adatbázis megtervezése Korábban tanultunk egy tervezési folyamatot, amit természetesen felhasználunk. A valóságos fejlesztési feladatokhoz hasonlóan nem vonunk éles határt az elemzési, tervezési, kivitelezési, tesztelési lépések között; ezeket ugyanis a gyakorlatban felváltva, szükség szerint, sokszor újra és újra ismételve szoktuk alkalmazni. Kezdjünk hozzá! A helyfoglalási rendszert olyan számítógépes alkalmazásnak tekinthetjük, amely egy programból és a hozzá tartozó adatbázisból áll. A program működését, szolgáltatásait azok a követelmények szabták meg, amelyeket szakmai és jogszabályi alapokon valamikor, valakik deklaráltak. A program mögött levő adatbázis szintén ezen követelmények folyománya. Mind a program szerkezete, moduljai, mind a háttérben levő adatbázis felépítése a rendszer általános, illetve ezen belüli részcéljait szolgálja.


4



A jegyfoglaló rendszer célja az, hogy a nézők az interneten jegyet tudjanak rendelni a megnézni kívánt előadásra. Az adatbázis célja: A jegyfoglalási folyamat során felmerülő adatszolgáltatási és adattárolási igény kiszolgálása. Most két irányban léphetnénk tovább: 1. A már megismert adatokat vizsgálva, megpróbáljuk ezeket rendszerezni és felállítani az adatmodellt. 2. Felvázoljuk a folyamatot és megállapítjuk adatigényét; a már ismert adatokat ennek megfelelően rendszerezzük, és kipótoljuk a még szükségesekkel. Bár a második változat tűnik nyilvánvalóan ésszerűbbnek és eredményesebbnek, célszerűnek láttuk így leírni, mivel tapasztalataink szerint sokan mégis az első változattal indítanak, majd miután a fejlesztés elbukik, akkor kezdenek el gondolkozni. Tehát rajzoljuk fel a rendszer folyamatmodelljét, és a kapcsolódó adatigényeket!

5. ábra A jegyfoglalás folyamata és a kapcsolódó adatok

Ne akarjunk egyszerre mindennel foglalkozni, bontsuk a feladatot kisebb részekre. A továbbiakban foglalkozzunk csak a napi műsorral (pirossal keretezett). A részfeladatok és megoldási sorrendjük megállapítása nem ötletszerű – a teljes követelményrendszer (amelynek most csak egy része áll rendelkezésünkre) elemzésén alapul. Például: A rendszer a mozik műsorát napokra bontva, mozihét egységekben, mozikra bontva mutatja. Megtehetjük-e, hogy az első körben figyelmen kívül hagyjuk a mozihét és a több mozi követelményeket, és csak a napi műsorra koncentrálunk? Mint később látni fogjuk, itt és most igen – de más feladatoknál nem biztos, hogy ezt az egyszerű lépcsőzetes módszert alkalmazni tudjuk.


5



Egyedek és tulajdonságaik A napi műsor felsorolja a filmek címét (piros: premier), a termet, a szinkronnyelvet, a film hosszát percben és a vetítési időpontokat. Ennek a képernyőnek az a célja, hogy a néző ki tudja választani azt a vetítést, amelyre jegyet (és helyet) akar foglalni.

6. ábra Az egyik nap műsora

Milyen „dolgokat” tudunk itt megkülönböztetni? Látunk címeket, sorszámokat, perceket, időpontokat: ezek adatok, és valamikre vonatkoznak: a címek filmekre, a sorszámok termekre, az időpontok vetítésekre. Próbáljuk meg azonosítani, összegyűjteni ezeket a „valamiket, dolgokat”, és a megtalált adatokat csoportosítsuk hozzájuk! Ha megragadunk a mozilátogató szemléleténél, akkor például mondhatjuk azt, hogy a filmnek van címe, terme, szinkronnyelve, hossza és vetítési időpontja. Kísérletképpen próbáljuk meg a Felkoppintva című film adatait ebben elhelyezni, mintha egy konkrét filmet akarnánk az adatbázisban tárolni! Az első három adattal nincs gond, de a harmadik (az időpont) problémás: több van belőle. Több adatot pedig nem tudunk egy helyre írni, hiszen a második felülírná az elsőt, a harmadik a másodikat és így tovább, végül csak az utolsó időpontunk maradna meg.


6



Mi ez a jelenség? Mit tegyünk, ha azt vesszük észre, hogy egy egyed valamely attribútumához egyszerre több adatot kellene hozzárendelni? Ha ilyet tapasztalunk, akkor nagy valószínűséggel egy rejtett egyedbe botlottunk; nem árt felülvizsgálni eddigi fogalmainkat. Az időpont ugyanis nem a film tulajdonsága, attribútuma! Ha visszanézzük eddigi leírásunkat, találunk egy ilyen mondatot: „Ennek a képernyőnek az a célja, hogy a néző ki tudja választani azt a vetítést, amelyre jegyet (és helyet) akar foglalni.” Vetítés! Ez a fogalom valahogy elsikkadt, pedig nagyon fontos. A gondot okozó időpont attribútum ugyanis a vetítés tulajdonsága, nem a filmé. Valójában nem „valahogy” sikkadt el: a hiba természetesen adódott abból, hogy nem a helyes nézőpontból – a moziéból –, hanem a nézőéből szemléltük a feladatot.

Milyen tulajdonságai vannak még a vetítésnek? Nyilván valamilyen filmet, valahol vetítenek, tehát tartozik még hozzá egy film és egy terem is. A teremről tudjuk, hogy sorszáma van, tehát megtaláltuk az első egyedeket:

7. ábra Az első azonosított egyedek

A nyilvánvalóan felismerhető egyedek mellett lehetnek olyanok is, amelyekre csak másodlagos jelekből következtethetünk; például abból, hogy • •

egyes tulajdonságokat nem tudunk egyik, már ismert egyedhez sem kapcsolni, vagy egy egyed valamely tulajdonságában egyszerre több értéket is tárolnunk kellene.

Ekkor elemezzük ezeket a tulajdonságokat, átgondoljuk céljukat, feladatukat. Meghatározzuk a szükséges (újabb) egyedeket, és a „gazdátlan” vagy többértékű tulajdonságokat ezekhez kapcsoljuk.


7



Kapcsolatok és azonosítók Miután feltártuk az egyedeket, megvizsgáljuk kapcsolataikat. Elég nyilvánvaló, hogy a vetítéshez helyet kell biztosítani (terem), és ha már hely van, valamit (filmet) kell ott vetíteni. A későbbiekre nézve célszerű, ha pontosan definiáljuk az egyedeket, esetünkben az új vetítés fogalmat. Vetítés alatt azt értjük, hogy egy film egy teremben hány órakor kezdődik. A vetítés tehát a film és a terem között helyezkedik el, ez hozza azokat kapcsolatba egymással.

8. ábra Az adatbázisterv jelen részfeladatunkra

Ahhoz, hogy a Vetítés egyed be tudja tölteni a filmek és termek közti kapcsoló szerepét, mindkét „felet” ismernie kell; ezt biztosítják a Vetítésben elhelyezett új tulajdonságok (film és terem). A film adat majd valamelyik film, a terem adat pedig valamelyik terem azonosítójának értékét veszi fel. A Termekre vonatkozóan tudjuk, hogy a mozikban a teremsorszámozás egyedileg azonosítja a termeket, így a sorszám megfelel kulcsnak – ennek értéke fog a Vetítés terem tulajdonságában (idegen kulcsként) szerepelni. Mi a helyzet a Vetítéssel? Van-e olyan tulajdonsága, melynek értékei majd minden vetítésnél szigorúan különbözőek lesznek? A film nem, mert ugyanazt a filmet többször is vetíthetik; a terem nem, mert ugyanabban a teremben több vetítés is van; és az időpont sem, mert más vetítések is kezdődhetnek ugyanabban az időpontban. Akkor vizsgáljuk meg, hogy két tulajdonság együttes értékei ismétlődhetnek-e több vetítésnél? A film-terem páros igen, mert ugyanazt a filmet ugyanabban a teremben többször is vetíthetnek; a film-időpont igen, mert ugyanazt a filmet ugyanabban az időben többször is vetíthetnek (csak más teremben); a terem–időpont viszont nem, mert egy teremben ugyanabban az időpontban csak egy vetítés lehet. A terem–időpont páros a vetített filmet is egyértelműen meghatározza.

A Vetítésnek tehát a terem+időpont összetett kulcs lesz az azonosítója. A Film esetében a cím attribútum nem lehet azonosító (kulcs), mert létezhetnek és léteznek is azonos című filmek. Mivel más attribútum sem jöhet kulcsként szóba (és párosításaik sem!), ezért a filmeknek mesterségesen képzett kulcs-attribútumot adunk: egy sorszám-azonosítót.


8



9. ábra Az egyedek azonosítói (kulcsok) és kapcsolathordozói (idegen kulcsok)

Meghatároztuk azokat az azonosítókat, amelyek azonosítják az egyedeket, illetve támogatják a kapcsolatok realizálását. Az azonosítók lehetnek egy tulajdonságból álló egyszerű, illetve több tulajdonságból képzett összetett azonosítók. Eljutottunk tehát oda, hogy • • •

meghatároztuk az egyedeket, a képernyőn talált adatokat tulajdonságokként azonosítottuk és a megfelelő egyedhez kapcsoltuk, és az egyedek tulajdonságai közül ki tudtuk választani (vagy képeztünk) azonosítókat.

Az azonosítók (kulcsok) minden egyedben egyértelműen meghatározzák a többi tulajdonság felvehető értékeit. A Vetítés egyednél a terem sorszáma és a film azonosítója idegen kulcsként (is) szolgál (kapcsolathordozók).

10. ábra Idegen kulcsok a Vetítésben

További attribútumok Nézzünk utána, nem maradtak-e ki attribútumok! Egyet valóban kihagytunk: a premiert. A műsor a premier filmeket piros kiemeléssel mutatja, a megjelenítő programnak tehát valahonnan tudnia kell erről. A hétköznapi szóhasználatban premier-filmekről szoktunk beszélni. Nézőként premier filmnek nevezzük az újonnan forgalomba került filmeket. De ne feledjük, hogy a jegyfoglaló rendszer (minden látszat ellenére) a mozi számára készül: a mozi szemszögéből nézve pedig mi a premier? Mitől függ a „premierség”? Ha átgondoljuk, rájövünk, hogy nem a filmtől (egy új film először premier, aztán elveszti ezt a tulajdonságát), akkor vajon mitől? A premier attribútum (konkrét értéke nyilván Igen/Nem, Igaz/Hamis, vagy 0/1 lesz) a vetítésre vonatkozik: egy film első vetítései premier-vetítések, a későbbiek már nem.


9



Érvényesítve összes módosításunkat, adatmodellünk az alábbiak szerint alakul:

11. ábra A pontosított modell

Az adatbázis bővítése a további feladatok igényei szerint Pillanatnyilag ott tartunk, hogy adatbázisunk nyilvántartja a filmeket, a termeket és a vetítéseket, utóbbiak segítségével össze lehet rakni a mozi egy napi programját. Viszont még nem lehet jegyet rendelni, fejlesszük tehát ebbe az irányba tovább a rendszert.

12. ábra A jegyfoglalás további lépései

Mint a fenti ábrán látható, a jegyek (helyek) számával, azok foglalásával fogunk tehát foglalkozni. A működő rendszerben ez a 2. ás 3. képernyőn realizálódik. Idézzük fel a 2. képernyőt!


10



13. ábra Jegyek számának megadása

A második képernyő egyrészt összefoglalja a vetítésre vonatkozó adatokat, másrészt bekéri a foglalandó helyek számát. Az itt megadott adat átmeneti – tranziens – jellegű, a 3. képernyőn történő helyfoglaláshoz szükséges, az adatbázisban nem kell eltárolni. Ennek megfelelően már lépünk is tovább, és megvizsgáljuk, mi kell a helyfoglalás megoldásához. Emlékeztetőként a 3. képernyő:

14. ábra Helyválasztás


11



A rendszer megjeleníti az adott termet, mégpedig a helyeket illetően valósághűen. A jelmagyarázatból kitűnik, hogy a helyeket hozzáférhetőségük szerint színezik; foglaláskor zöldet lehet választani, ami először sárga lesz, majd a Foglalás gomb megnyomása után narancssárgára vált. Ha egy foglalást ki is fizetnek, akkor piros lesz. A kék és fekete színnel jelölt helyek nem eladhatók (lépcső területe, illetve fenntartott helyek). Mivel a termek „térképét” a programnak meg kell jelenítenie, s ezen belül még a helyeket is külön kell kezelnie, az adatbázisban az ezekre vonatkozó adatokat tárolni kell. Ha jól megnézzük a képet (illetve megnézünk más termeket is) láthatjuk, hogy végül is mindegyik téglalap alakú, csak a teljes terület és a letiltott területrészek mérete változik. A terem méretezésének egysége a hely (szék). Ha kiegészítjük a Terem egyedet a méretet meghatározó (m x n) adatokkal, akkor ki is tudjuk majd rajzolni.

15. ábra A Terem egyed kiegészítve a méret adatokkal

A korrekt kirajzoláshoz ez nem elég, mert nem tudjuk, melyek lesznek a tiltott helyek. Egy teremben több tiltott hely is lehetséges. Ezeket termenként rögzíteni kell:

16. ábra Terem és Tiltott zónák

Egy teremhez több tiltott hely is tartozhat; az egyes helyeket szintén koordinátáikkal írjuk le. Például az alábbi, pirossal jelzett terület tiltott helyeinek koordinátái: (K,7), (K,8).


12



17. ábra Tiltott terület koordinátái a teremben

A foglalható helyeket egyenként viszont nem kell nyilvántartani, mert azt tudjuk, hogy összesen hány hely van: ha eladunk egyet, ezt kell regisztrálni, ez érdekel minket. Egy vetítés meghatározásakor a terem összes helye szabad, kivéve a tiltott helyeket (ezek azonban nagyon ritkán változnak, mert vagy a terem olyan részeit jelölik, ahol nincsenek székek (pl. lépcső), vagy a hatóságilag előírt rendőr és tűzoltó helyeket jelentik. Amikor helyeket foglalunk, ezt tárolni kell az adatbázisban, hogy amikor a pénztárnál bemondjuk a jelszót, akkor ellenőrizhessék, és ki tudják adni a jegyeket. Kérdés, hogy milyen újabb egyedeket és attribútumokat jelent ez? Itt megint alaposan át kell gondolnunk a helyzetet: mi történik, amikor kattintunk? Ekkor foglalás történik, amely adott számú helyre (székre) vonatkozik. Tehát megjelenik a Foglalás egyed. Milyen attribútumai vannak? Egy foglalás egy adott székre vonatkozik, egy adott vetítés idejére. Vagyis a foglalás a vetítésekhez kapcsolódik:

18. ábra Helyfoglalás


13



Egy vetítésre természetesen több foglalás is érkezhet, ezért a kapcsolat foka egy– több. A foglalásokhoz nem tudtunk olyan saját attribútumot találni, amely egyedi azonosítóként funkcionálhatna, ezért képeztünk egy technikai sorszámot (hasonlóan, mint a filmeknél). A vetítésazonosítóval kapcsolatban ne feledjük: a Vetítés egyed három attribútumból álló (terem sorszám+időpont), összetett kulcsát fogja tartalmazni. De ez még kevés, hiszen ezzel csak a foglalás tényét rögzíthetjük, a konkrét helyeket nem. Ráadásul egy foglalás több helyre is vonatkozhat. Az egyes helyek pozícióját x,y koordinátákkal jelölve, és kiegészítve a foglalás alatt – lefoglalt – kifizetett státuszok jelzésére szolgáló Státusz attribútummal:

19. ábra Foglalás a helyek megadásával

Mi van még hátra adatbázis-tervezési feladatunkból? A „teteje”, vagyis a több-napos, több-mozis képességgel való kiegészítés.


14



20. ábra A jegyfoglalás további lépései

Menjünk sorban: mi kell ahhoz, hogy ne csak egy, hanem több napra is tudjunk moziműsort készíteni? A „műsor” tulajdonképpen a vetítések felsorolása. Ha a vetítéseket nem csak időponttal (óra és perc), hanem dátummal is ellátjuk, akkor meg is oldódott a dolog. A dátum attribútum szintén része lesz a vetítések egyedi azonosítójának.

Mivel a mozik heti programokat készítenek, a dátum helyett alkalmazhatnánk egy 1-től 52-ig terjedő hét-sorszámot plusz egy 1–7 intervallumú napsorszámot is).

A dátum attribútum tehát a Vetítés egyedhez kerül. Hogyan oldjuk meg a több mozit? A Palace mozik műsoradatbázisát építgetjük: ebből mi független az egyes moziktól és mi mozi-specifikus?


15


Mozitól független


Mozispecifikus

21. ábra Az adatbázis mozitól független és mozispecifikus részei

Ez az a pont, ahol – felhasználva a példánkban előállt szituációt – szót ejtünk az adatbázis-tervezés néhány más aspektusáról is. A tervezésnek nem csak az adatbázis tartalmi-szerkezeti felépítésére kell koncentrálnia, hanem figyelembe kell vennie más, átfogóbb követelményeket is, ugyanakkor ez utóbbiak vissza is hathatnak a belső kialakítás megoldásaira. Mire gondolunk?

Méretezés, bonyolultság Jelen állás szerint adatbázisunk a filmekkel és egyetlen mozi műsorával, illetve helyfoglalásával kapcsolatos adatok tárolására képes. Technikailag megoldható, hogy ugyanebben az adatbázisban több mozi adatait is elhelyezzük, de vajon célszerű-e, érdemes-e? Nézzük például a Terem egyedet! Amikor az adatbázist ténylegesen létrehozzuk (pl. relációs adatbázis formájában), a Terem egyed egy Termek táblában fog realizálódni, melynek annyi sora lesz, ahány terem a moziban van. Ha az adatbázis több mozi adatait is tartalmazza, minden mozi termei ebben a táblában lesznek majd felsorolva, és azt, hogy melyik terem melyik mozié, egy mozi azonosítónak kell majd jelölnie. Ez megoldható, de ekkor a Termek tábla – az egy-mozis állapothoz képest – hirtelen a többszörösére nő. Ugyanez lesz a helyzet a vetítéseket, foglalásokat stb. tároló táblákkal is, ez utóbbiak ráadásul alapesetben is lényegesen nagyobbak, mint a Termek tábla.


16



Ha több mozi adatait egyetlen adatbázisban tároljuk, ahogy halad az idő és készülnek a műsorhetek, fizikailag (a sorokat tekintve) egyre nagyobb méretű táblákat kapunk. A nagyméretű táblák kezelése, az egyes mozikra való adatleszűrések egyre több időt igényelnek majd. Az idő pedig itt kényes dolog, mivel – mint látjuk – a rendszer az interneten keresztül üzemel. Az internetes használattal kapcsolatban sok más tényező (kliensgépek képességei, sávszélesség, szolgáltató gépei stb.) is befolyásolja a szolgáltatás időigényét, nem hiányzik ezekhez még a rendszer túlméretezéséből, túlbonyolításából eredő probléma.

Biztonság Az adatbázisok – és egyáltalán, az adatfeldolgozás – biztonságát sok tényező befolyásolja, ezek között az egyik a közvetlen használati, feldolgozási módok megoldása. Ha minden mozit egy adatbázisba zsúfolunk össze, akkor az adatbázis minden része (minden táblája) állandóan „mozgásban” lesz, valamelyik mozival vagy filmmel kapcsolatban mindig lesz adatváltozás. Az adatbázis tartalmának módosítása pedig mindig kockázattal járó művelet; márpedig, ha például X mozinál teremváltozás következik be, ezt abba a táblába kell bejegyeznünk, amely az összes többi mozi termeit is tárolja, vagyis bár a többi mozit nem érinti a dolog, de a tábla változása ezeket is veszélyeztetheti. Az adatbázisok üzemeltetése közben óhatatlanul előfordulnak hibák („csak az nem hibázik, aki nem dolgozik”). Ezek kijavítása, rendbetétele az adatbázis rövidebbhosszabb ideig tartó, használatból történő kivonásával járhat. Ha adatbázisunk egyben tartalmaz minden mozit, akkor a leállítás az összes mozit érinteni fogja, pedig lehet, hogy csak egyetlen mozi adatainál merült fel probléma.

Teljesítmény Teljesítmény alatt a rendszer időegység alatti szolgáltatási tempóját értjük; webes rendszereknél ezt a sebességet több tényező is befolyásolja, például: a szerver számítógép sebessége, a szerveren futó alkalmazás minősége, az internet-kapcsolat sebessége, a kliens gép sebessége, stb. A mi feladatunknál – ha ténylegesen meg kellene oldani, figyelembe kellene venni azt, hogy a rendszerhez egy időben sok felhasználó fog kapcsolódni. Jelenlegi megoldásunk ezzel még nem számol, ezért nincsenek még beépítve a folyamatos adatfeldolgozási, számítási igényeket csökkentő, átmeneti technikai mergoldások. Például: Jelenleg, ha valaki jegyet akar rendelni, a weboldal megjelenítéséhez rendszerünknek minden esetben „ki kell számolnia” a terem aktuális állapotát, majd ennek megfelelően készíti el a képet. Sok néző egyidejű kapcsolódása esetén ez nagy műveleti terhet jelent, így a rendszer exponenciálisan lassulni fog. Ennek kivédésére például alkalmazható az a megoldás, hogy a termeket egy segédtáblában ténylegesen létrehozzuk (minden foglalható és tiltott helyet, azok koordinátáival együtt), és ennek alapján jelenítjük meg a képet. Ekkor a rendszernek nem kell minden esetben kiszámolnia a terem képét, és a foglalások menedzselése, ellenőrzése is gyorsabb. A nap végén aztán az ilyen átmeneti adattárakból létrehozható a végleges tárolás, amely inkább a helytakarékosságot célozza. Készítette: SZÁMALK Zrt, Szakképzési Igazgatóság

17



Az együtt-tárolás értelme Végül arról se feledkezzünk meg, hogy egyáltalán: miért kellene a mozikat együtt, egy adatbázisban tárolni? Milyen feladat, logika igényelné ezt? Van-e a mozikkal kapcsolatban egyáltalán olyan közös „ügy”, ami a közös adatbázist indokolná? A mozik esetében – legalábbis jelenlegi ismereteink szerint – legfeljebb a filmek a közösek: mind ugyanabból a filmtárból választ. De ehhez miért kellene a mozikat közös adatbázisba tenni, inkább a filmeket emeljük ki egy, minden mozi számára elérhető, önálló adatbázisba! Nézzük az alábbi megoldást! Ebben minden mozi adatbázisa fizikailag elkülönül egymástól, a filmek pedig szintén önálló (jelenleg egy egyedes) adatbázisba kerültek.

22. ábra Filmadatbázis és a mozik adatbázisai külön-külön

A fenti megoldás lényegesen rugalmasabb, biztonságosabb és áttekinthetőbb alkalmazást, használatot biztosít, mint az egy-adatbázisos megoldás. •

Az egyes mozik adatbázisai egymástól függetlenül használhatók. o Az adatbázisokat igénybe vevő programok nem egyszerre, egy adatbázisra „ugranak rá”, hanem sokszor egymástól függetlenül dolgoznak. o Az egyik mozi adataival kapcsolatos problémák, és javításuk nem érinti a többi működtetését.

•

A rendszer sokkal könnyebben és biztonságosabban módosítható, bővíthető. Utóbbi – a bővítés – egy mindig fejünk felett lógó „Damoklész kardja”: a jövő mindig új követelményeket, feladatokat hoz, amelyeket szintén meg kell majd oldani – és erre már most, előre fel kell készülnünk – az adatbázisok belső szerkezetének (egyedek tulajdonság-összetétele) utólagos, már használat közbeni módosítása nagyon kockázatos és drága mulatság!


18



Példa Ha megnézzük a weboldalt, akkor láthatjuk: a filmekkel kapcsolatban sokkal nagyobb információs igényt kell kielégíteni, mint azt a mostani, „minimálrendszer” teszi: tartalmat, szereposztást, rendezőket, bemutató részleteket kell tudni közölni, amely a filmekkel kapcsolatos adatbázisrész jelentős bővítését követeli meg. Ezt sokkal egyszerűbb egy különálló filmadatbázisban megtenni, mint a teljes, nagy adatbázist átalakítgatva. Nem beszélve arról, hogy miért is kellene a mozikat bolygatnunk egy olyan feladat miatt, ami nem is érinti őket?

Összefoglalás Jelen fejezetünk sok, fontos dologra hívta fel a figyelmet. Talán itt érzékelhettük igazán, hogy az adatbázisok készítése nem egyszerű feladat, és sok tényezőt, eszközt kell tervezésük közben figyelembe vennünk, illetve alkalmaznunk: • • • •

az adatbázisok belső szerkezetének és tartalmának kialakítására vonatkozó követelményeket, szabályokat és technikákat, a magasabb rendű, befoglaló feladat adta, későbbi működtetési körülményeket, biztonsági követelményeket, nem utolsó sorban – a lehetőségekhez képest – a jelen feladatának megoldása közben már a jövőre is gondolnunk kell.

Az adatbázis tervezése közben igyekeztünk felhívni a figyelmet a buktatókra, a gondolkodási, szemléleti problémákból eredő hibákra, és kijavításuk alapvető fontosságára is.


19

Esettanulmány: Mozi helyfoglaló rendszer adatbázisának visszafejtése

Recommend Documents