Ábrahám Péter Gazdaságinformatika Levelező szak ESEVND Adatbázis háttér játszóházi beléptető és nyilvántartó rendszerhez Egy valós rendszer bemutatása "1
Tartalomjegyzék Bevezetés, feladat ismertetése Adatbázisok tervezése, kapcsolatok, jogosultságok MySQL Adatbázisok tervezése, kapcsolatok, jogosultságok Adatbázis kapcsolati ábra Végszó 3. oldal 4. oldal 4. oldal 5. oldal 9. oldal 10. oldal "2
Bevezetés, feladat ismertetése Jelen dolgozat témája, hogy bemutassam egy éles környezetben futó játszóházi beléptető és tagnyilvántartó rendszer adatbázisát és kapcsolatait. A program alapjait örököltem, vagyis egy másik fejlesztő kezdte el, kb 30%-os készültségi fokban szálltam be a projektbe, ezért előfordulhat, hogy egyes tábla/mező nevekben felfedezhető lesz a kétféle logika. Nem volt cél a korábbi, kész fejlesztéseket eldobni, befejezést és kiegészítést céloztam meg. A rendszer 2005-ben indult, én 2008-ban vettem át (mivel a kivitelező eltűnt), azóta három olyan fejlesztési fázison ment keresztül, ami a működést modernné, kényelmessé teszi. Első körben adódott, hogy fel kell mérni a jelen helyzetet. Az aktuális állapotban a kész funkciókat már használta az ügyfél, így szerencsére teszt adatokkal feltöltést nem kellett végezni. Egy komplex biztonsági mentést követően (sql dump és file backup) megkezdődött a munka. Ezt követően felvázoltunk egy rendszer működési modellt, mely kielégíti a következő igényeket: - teljesen operációs rendszer független (Windows/OSX/Linux/iOS/Android) és bárhonnan elérhető (online használat) - teljes elérés a kezelők és az adminok részére is (akár otthonról) - vonalkód leolvasó rendszer integráció (büfé eladás, karszalag kezelés) - rendezvény foglalás - játékok/gyerekek nyilvántartása, statisztika - büfé termékek eladása - további hiányzó funkciók pótlása, a meglévő funkciók hibáinak javítása "3
Adatbázisok tervezése, kapcsolatok, jogosultságok A rendszer üzemelésére az online működés miatt a PHP 5.x rendszert választottam, MySQL adatbázis kezelő programmal. Ez később könnyen migrálható másik serverre is akár. Kliens oldalon adatkezelésre minimális esetben kerül sor, így ott jquery dinamikus rendezhető táblázatok elegendőnek bizonyultak. A tábláknak az adatbázisban a jatszohaz_ előtagot adtuk, a könnyebb azonosíthatóság érdekében. Elsődleges cél a redundancia elkerülése. Redundancia alatt értjük, ha egy(több) adat azonos formában több helyen is szerepel, így ha ez az adat frissül, akkor minden előforduláson frissíteni kell, különben hibás működés jöhetne létre. Ez egyrészt káros, másrészt felesleges tárterület foglaláshoz vezet. Ennek megfelelően az adatbázisok kialakításánál törekedtünk arra, hogy minden táblában kizárólag a releváns adatok szerepelhessenek, és minden adatnak legyen egyedi IDje, ami alapján egy másik tábla releváns adatsorához kapcsolható. A kapcsolatok változatosak, általában 1-1 vagy 1-n alapúak. Az adatkapcsolatokat az MS Access segítségével fogom bemutatni, mivel MySQL-hez nem áll rendelkezésemre grafikus kapcsolatábrázoló kiegészítés. Másodlagos, de nem kisebb fontosságú, hogy egy táblában valóban csak azt az adatot tároljuk, ami az adott nézetben szükséges. Egyes táblák látszólag nem kapcsolódnak a rendszer maghoz, ezek beállítási adatok at tartalmazó táblák. Ezekben csak olyan alapadatok találhatók, amik önálló lekérdezések alapján adnak választ (percdíjak, termékek árai, stb). Ennek megfelelően 19 tábla készült a rendszerhez, melyek felépítését és működését a következő pontokban olvashatjuk. MySQL A MySQL kiváló választás osztott, többfelhasználós, interneten elérhető adatbázis építési célra. A GNU/GPL licenc alapján ingyenes, az Apache, IIS és NginX szerverek is kezelik, sok esetben alapértelmezett módon. Ennek köszönhetően rendkívül költséghatékony módon építhetünk belőle adatbázist. A motor maga jól kezeli a nagy méretű táblákat is, indexelhető, és rugalmasan bővíthető. Kezeli a TRIGGER és PROCEDURE eljárásokat is, VIEW is elérhető. (A jelen rendszerben ezen funkciók nincsenek kihasználva, de rendkívül hasznos funkciók). A lekérdezések gyorstárazhatók, így a hasonló lekérdezések cache-ből érkezve sokkal gyorsabban lefutnak, mint első alkalommal. "4
A program működése és az alaptáblák bemutatása A program célja, hogy a játszóházba beérkező gyermekek adatait letároljuk későbbi újrahasznosítás érdekében, valamint a benti történetüket kövessük. Értve ez alatt a játékok kezelését perc alapon, a játékok mentését későbbi statisztika generálásához, és a büfében történő fogyasztással is el tudjunk számolni. A büfé termékek leltárja is megoldott, valamint részletes napló és kassza áll rendelkezésre. A kassza zárása és a büfé standolása fileba kerül mentésre, így a tábla adott időponti állapota mindig elérhető csv file formátumban. A programmal akár a nagy alapterületű játszóházak igényei is kielégíthetők, de kiválóan alkalmazható kisebb egységekben is. A karszalagokkal egyszerre többféle beléptetés is követhető (sószoba, szülinapos játék, kísérőjegy, csoport jegy ) A felhasznált táblák: jatszohaz_alapdij: ebben a táblában tároljuk az alapdíjat. Az alapdíj annyit jelent, hogy fizetéskor ha az itt tárolt percek nem teltek el a belépés óta, ezt mindenképpen ki kell fizetni. Általában egy sor van tárolva, de azért került külön táblába, mert előfordulhat, hogy valakinek más napon más alapdíjra van szüksége jatszohaz_arak_1(2 és 3 azonos szerkezettel): ebben a három táblában különböző árakat tárolunk. Az arid mező szükséges a törlésekhez, sorba rendezéshez, az ardate mezőben pedig az adott ár érvényessége található. A 3 táblának oka, hogy három különféle ár-adat található bennük. Az elsőben a percdíjak találhatók, ardate 1-7 esetén a hét napjaira vonatkozó, illetve 20-ig speciális árak, ahol pedig élő dátum van beírva, ott az eredeti napi ár helyett alkalmazandó egyedi ár található (példa: gyermeknapra beállított 0Ft ár). A másodikban a rendezvények, teremfoglalások árai, hasonló módon, a harmadikban pedig különböző rendezvény speciális árak találhatók jatszohaz_berlettipusok: ebben a táblában tároljuk el az eladható bérletek tipusait, azok lejárati idejét, a benne foglalt percdíjakat, és az eladható státuszokat jatszohaz_berletek: ebben a táblában tároljuk el a gyerekek által megvásárolt bérleteket, azok vásárlási idejével és lejáratával együtt. A használat közben csökkenő perc-hátralék nyilvántartás is itt történik. "5
jatszohaz_foglalas: a tábla tartalmazza a lefoglalt rendezvényeket órás bontásban, termenként, gyermekenként. (példa: különterem foglalva az 1-es gyermekhez, 4 főre, és adott dátum/órára, több óra esetén óránként egy sor) jatszohaz_gyerekek: a tábla tartalmazza az összes gyerek személyes adatait (név, cím, telefonszám, születési idő, szülők adatai megjegyzésben) jatszohaz_hitelek: játék közben a büfében hitelre elfogyasztott termékek, melyeket ki kell fizetni a játék végén jatszohaz_hirlevel: a megírt hírlevelek archívuma (ismételt küldéshez minden hírlevelet letárolok archívumban) jatszohaz_jatekok: az egész rendszer szíve és lelke ez a tábla. A játék indításakor felírja a játék sorszámát, a gyermek sorszámát, a kezdés idejét, és hogy mely kezelő indította. Extra opció az együtt belépő gyermekek száma (jfo). Játék végén felírja a megállítás idejét (jstop), a játékidőt (magyarázat: időkedvezmény jár születésnap esetén, 2 óra után kezd számolni, agy a játékidő és a jstop-jstart időbélyeg érték nem biztos, hogy egyezik!), a státuszt átállítja fizetés alatti státuszra, fizetéskor pedig fizetett játék állapotra, és rögzíti a kapott kedvezményt (megjegyzés: a személyes kedvezményen felül kaphat valaki kedvezményt még) jatszohaz_karszalagok: a kiadott karszalagokat vonalkóddal lementi egy egy játékhoz kapcsolódóan. A játékok táblától külön kezelés oka, hogy minden alkalommal, mikor egy gyermek belép, ellenőrizni kell, hogy a vonalkódot valaha kiadták-e már játékra (nem érvényes) illetve a karszalag csomag tartományok közé tartozik-e a leolvasott kód. A keresés "6
a jatszohaz_jatekok táblában sokkal lassabb lenne, mint egy ilyen szűkre szabott táblában. És itt kizárólagos elsődleges kulcsként lehet jelen a vonalkód, ami tovább gyorsítja a lekérdezést. A játékok táblában vagy fulltext keresés kellene, vagy csak másodlagos kulcs lehetne. Én ezt választottam. jatszohaz_karszalag_csomagok: ebben a táblában tárolom az előbb említett karszalag csomagok (tömbök) kezdő és záró sorszámát, illetve a csomagok rögzítésének idejét. Ami vonalkód ezen tartományokon kívül esik, azzal nem lehet játékot indítani. jatszohaz_kassza: a kasszában tárolódik minden fizetési információ, a kassza zárásáig. A fizetéseket csoportosítja eladás szerint (mire) és fizetés szerint is (bankkártya, kp, utalvány). Mivel ide az összes fizetés bekerül, egy olvasható szöveg képében tárolom az eladási módot, nem hivatkozom más táblákra, ugyanis lehet büfé termék, játék fizetés, vagy épp rendezvény foglalás, vagy csak vezetői betét/kivét, így nem lehet optimálisan kapcsolni táblákhoz. A kapcsolódásokat lekéréskor a WHERE clause-ban adom meg, szöveg rész egyezéssel, it tagoló elemekként [ ] zárójeleket alkalmazva a szövegben elrejtem a kulcsokat. (ezt nem tudom a kapcsolati ábrán ábrázolni) jatszohaz_mail_cron: a táblába kerülnek mentésre a kiküldésre váró hírlevelek, és ahogy a cron job lefut, 200db-ot elküld, és töröl, ha sikeres. A végén kiürül a tábla, és várja a további hírleveleket. jatszohaz_naplo: minden eseményt rögzítek a naplóban. Belépések, játékok indítása, leállítása, fizetések, beállítás módosítások, stb. Így az események visszakövethetők, kontrollálhatók. jatszohaz_rendezvenyek: ebben a táblában a foglalásokhoz rögzíthető extra opciók, illetve csomagok adatai vannak letárolva. Egy rendezvény foglalás állhat óra/fő vagy csomag alapokon is. "7
jatszohaz_users: ebben a táblában találhatók a kezelők, adminisztrátorok belépési adatai, név, jelszó, rögzítés és utolsó belépés ideje. jatszohaz_bufe: a büfében kapható termékek táblája. Név, vonalkód, mennyiségi egység, mennyiség, gyártott termék esetén alapanyag lista, alaptermék esetén bekerülési ár. A táblák kapcsolati ábrája (eltávolítva azokat a táblákat, amik direkt módon nem kötődnek másik táblához) a következő oldalon tekinthető meg: "8
"9
Végszó Az előzőekben felvázolt rendszer a jelenlegi, véglegesnek tekinthető kialakítás. Természetesen a programozás alatt folyamatosan kellett apróbb módosításokat, kiegészítéseket felvinni az adatbázisba, de ez a jól megtervezett felépítésnek köszönhetően nem okozott problémát. Mivel az adatok megfelelően elszeparált táblákban tárolódnak, nincs redundancia, és csak a megfelelő ID-kel kötjük őket össze, így egy módosítást nem kell adatbázis szinten egynél több helyre felvezetni. 10 év elteltével a rendszer tartósan stabilnak bizonyult, melyet a benne tárolt adatok mennyisége is igazol (az adatok a fő felhasználási pont adatai, a program több játszóházban üzemel): Gyermekek száma: 8.450 fő Játékok száma: 20.582 játék Összes napló bejegyzés: 218.190 db "10