Adatbázis vezérelt webhelyek

Bevezetés        

A 6. Munka az adatbázisokkal című fejezet azoknak a PHP-s eszközöknek a hasz­nálatát mutatta be, amelyekkel az adatbázisokban tárolt információkhoz férhe­tünk hozzá. Az előző fejezetben a felhasználói felület és a kód szétválasztásának módszeréről volt szó a sablon alapú rendszerek felhasználásával. Ez a két 535f54f fejezet együtt adja ennek a fejezetnek a keretrendszerét, amelyben a részletek magas szintű tervezésével és implementálásával foglalkozunk. Az alacsony szintű adat­bázis-kezelő függvényekről ezen a helyen nem szólunk. (Azokról a 6. fejezetben és a 2. kötetben, a referenciakönyvben találhat további információkat.)

Az adatbázis tervezése

A szoftverfejlesztés esetében a jó termék mindig a jó tervezés eredménye. Az adatbázis megfelelő tervezésének elmulasztása általában az integrációval, kar­bantartással és a gyártással kapcsolatos problémákhoz vezet. A megfelelő adat­bázis-tervezés megannyi fantasztikus könyv témája. A probléma túl nagy és túl komplex, így csak a munka elkezdéséhez szükséges alapvető információkat tár­gyaljuk.

Az első adatbázis-kezeléssel kapcsolatos döntésünkkor az adatbázis-kezelőt (Database Management System, DBMS) választjuk ki, amelyet használni fogunk. Mivel a PHP elég sok népszerű DBMS-t támogat, ezért a döntést a költség, a szükséges funkciók, a skálázhatóság és más DBMS-kulcskérdések vizsgálatával fogjuk meghozni, és nem a nyelvi támogatás a döntő szempont.

Sok PHP-alkalmazás esetén a MySQL DBMS nagyszerű választás, hiszen a PHP-be alapértelmezésként beépítették a MySQL támogatását. A MySQL a GNU nyilvános licence {General Public License, GPL) alatt áll rendelkezésre. Kiterjeszthető SQL-támogatást biztosít, ezenfelül gazdag API-t is. A MySQL installálást és hasz­nálatát részletesen ismertettük a 6. fejezetben. Jelen fejezet példáit MySQL-adatbázissal fejlesztettük.

Más DBMS-ek is rendelkezésre állnak, és mindegyiknek megvan a maga elő­nye. Ha nagy forgalmú webes alkalmazást szeretnénk fejleszteni, vagy a tranzak­ciók támogatására van szükség, akkor fontolóra kell venni az Oracle-t vagy a Microsoft SQL Servert mint DBMS-t. Az alkalmazáshoz szükséges megfelelő DBMS kiválasztásához a DBMS árát, támogatottságát, skálázhatóságát és a funkciókat kell mérlegelnie. A DBMS rossz kiválasztásával a megpróbáltatások súlya alatt gyengén teljesítő vagy teljes egészében kudarcra ítélt alkalmazás készülhet. Ha előfordulhat, hogy az alkalmazás életciklusa alatt a DBMS megváltozhat, akkor generikus API használata javasolt, hogy elszigeteljük az alkalmazástól a DBMS-specifikus függvényeket, és használjunk szabványos SQL-t. Ezenkívül ügyelni kell a különféle DBMS-ek SQL-támogatásának különbségeire is. Az Oracle például támogatja a következőhöz hasonló lekérdezéseket:

select * from table1 where id in ( select id from table2 )  

A könyv írásának idején a MySQL nem támogatta hasonló konstrukciók használatát. DBMS-semleges SQL-kód fejlesztése kihívásokkal teli feladat, ezért egy DBMS lecserélése egy nem praktikus megoldás, még relatíve kis alkalmazások esetén sem.

A DBMS kiválasztása után következik az aktuális adatmodell körültekintő lét­rehozása. Példaképpen képzeljünk el egy on-line árukatalógust, amelyben több kereskedő vagy "bolt" van. Ebben a fejezetben egy ilyen típusú adatbázis tervezé­sét és implementációját ismertetjük részletesen, majd a következő két fejezetben használatos keretrendszert hozzuk létre. Az on-line katalógus célja egyszerű adat­bázis, amely az adatokat különböző kereskedők között osztja fel úgy, hogy mind­egyik kereskedő több kereskedelmi kategóriával rendelkezzen. A magas szintű modellt a 15.1. ábra mutatja be.

A 15.1. ábra alapján minden kereskedő kialakíthat egy vagy több kereskedelmi kategóriát, és minden kereskedelmi kategória tartalmazhat egy vagy több termé­ket. Az előbb említett alapvető részletekből az egész adatmodell megformálható. A 15.2. ábra szemlélteti az árukatalógus teljesen kifejlesztett adatmodelljét. A modell tényleges implementációja a 15.1. programlistában olvasható.

Ha a modellt megalkotta és ellenőrizte, akkor kezdődhet az alkalmazás imp­lementációja. Az árukatalógust létrehozó alkalmazás elsődleges céljai a követ­kezők:

A termékek információinak logikus, könnyen használható formátumban történő megjelenítése.

Tegye lehetővé egy kereskedő számára, hogy bármikor frissítse a termé­kekről szóló információkat bármilyen internetkapcsolattal rendelkező helyről.

Tegye lehetővé a kereskedőnek, hogy bármikor kezelje a termékkategóriákat, és termékeket rendeljen a kategóriákhoz bármilyen internetkapcso­lattal rendelkező helyről.

Tehát az alapvető feladat az, hogy egy internet alapú módszert biztosít­sunk az árukatalógus információinak bővítésére, törlésére, módosítására és meg­jelenítésére. Az adatkezelés lehetőségeiről részletesen a következő fejezetben lesz szó.

Adatkezelő alkalmazás

Ha már megterveztük és implementáltuk az adatbázist egy DBMS-ben, akkor kialakíthatjuk az alkalmazás logikáját, amellyel a meglévő adatbázis rekordjait módosítjuk. Az alapműveletek, amelyeket bármilyen típusú adaton végre kell tudnunk hajtani: az új adatok felvétele, meglévő adatok szerkesztése, illetve törlé­se. Ebben az alkalmazásban az adatok hierarchiáját is tudnunk kell kezelni. Ah­hoz, hogy ezt teljesíteni tudjuk, azt az egyetlen üzleti szabályt állítjuk fel, hogy legalább egy termékkategóriával rendelkeznie kell a kereskedőnek ahhoz, hogy új terméket vegyen fel.

Ezt a szempontot szem előtt tartva logikus, hogy úgy kezdjük a munkát, hogy lehetővé tesszük a kereskedőknek a kategóriák információinak kezelését. Az al­kalmazás előfeltétele, hogy a kereskedő képes legyen a webhely-kezelőhöz beje­lentkezni. A bejelentkezés során beállítjuk a kereskedő ID-jét tartalmazó session változót, amelyet az egész menedzsmentalkalmazásban használni fogunk. Az előzőekben bemutatott sablon alapú rendszert, a FastTemplate-et alkalmazzuk. A 15.2.-15.4. programlistákban olvasható sablonfájlok az adatkezelő alkalmazás alapját alkotják.

A 15.2.-15.4. programlistákban olvasható fájlok tartalmazzák az adatkezelő alkalmazás alapvető keretrendszerét. A kategóriaspecifikus kezelőlap sablonjai az 15.5.-15.7. programlistákban olvashatók. A 15.8. programlistában olvasható szkriptet használtam a sablonok és az adatbázis információinak összeillesztésére.

A szkript először is elindít egy sessiont és ellenőrzi a kereskedő azonosítóját, a $aMerchantID-t. Ha a kereskedő azonosítója nincs beállítva, akkor a felhaszná­lót egy bejelentkező lapra kényszerítjük. A bejelentkező lap ellenőrzi a látogató igazolványait, és ha az ellenőrzés pozitív eredménnyel zárul, akkor az előbb emlí­tett session változót a kereskedő azonosítójára állítja be. Ezután a szkript a keres­kedő azonosítójával mint szűrővel ellenőrzi a létező kategóriákat az adatbázisban. Ha legalább egy kategória létezik, akkor a szkript egy ciklussal végigmegy az adatokon, és a létező kategóriákból előállít egy táblázatot. A 15.3. ábra mutatja a főlapot, ahogyan azt egy kereskedő két kategóriával látja.

A szkript egy egyszerű hivatkozás segítségével biztosítja egy új kategória felvé­telét. Ha léteznek kategóriák, akkor minden kategóriának megvan a saját szer­kesztés (edit) és törlés (delete) hivatkozása (lásd 15.2. ábra). Az új kategória felvé­telét megvalósító szkripteket lásd a 15.9. és 15.10. programlistákban.

A 15.10. programlistában található szkript abban hasonlít a többi könyvben található adatok gyűjtésére és érvényesítésére szolgáló szkriptre, hogy ugyanazt a szkriptet használjuk a form nyújtására, a form kezelésére és az elküldött adat érvé­nyesítésére. Ebben az esetben az érvényesség ellenőrzését az IsVlidCategory() és az új kategória tárolását a SaveCategory() függvényekbe csomagoltuk. Ezek a segédfüggvények később a teljes mgmt_funcs.php fájlban olvashatók. Az érvé­nyesítést végző rutin egyszerűen csak egy ugyanolyan nevű kategória meglétét ellenőrzi.

A kategória kezelésének szerkesztő és törlő függvényei nagyon hasonlítanak a könyv többi szkriptjéhez. A 15.8. programlista vizsgálatakor láthatja, hogy minden kategória szerkesztés és törlés hivatkozásai tartalmazzák a kategória azonosítóját. Például a ruházati (Apparel) kategória törlésére szolgáló URL a https://testserver.com/ch 15/mgmt_cat_del.phtml?cat_id = 1. A kategória azo­nosítóját átadjuk a szkriptnek, így egy egyszerű SQL törlő utasítást lehet összeál­lítani. A szerkesztéshez is ugyanezt a mechanizmust használtuk a szerkesztő me­zőben a név kitöltésére. Nem ismertetjük itt a függvények teljes forrását, mert azok kódja hasonló a 15.9. és 15.10. programlistában láthatókhoz. A kategóriá­kat törlő és módosító függvényeket az mgmt_juncs.php fájlban találhatjuk (15.12. programlista).

Egy kategória módosításának feltétele, hogy a kategória új neve nem lehet azo­nos egy már létező kategória nevével. Kategória törlésekor feltétel, hogy a kate­gória nem tartalmazhat egyetlen terméket sem. Ha termékek lennének a kategó­riában, akkor magának a kategóriának a törlése árva termékrekordokat eredmé­nyezne, ami az alkalmazás hibájához vezet. Adatbázis által vezérelt webes alkal­mazások létrehozásánál a siker fontos tényezője az üzleti szabályok betartása az alkalmazás kódjában. Néhány szabályt a DBMS szolgáltatásaival is betarthatunk: ilyenek például a kényszerített kapcsolati szabályok és a lépcsőzetesen összekapcsolt adatműveletek. Más szabályoknak a triggerek és tárolt eljárások alkalmazá­sával tudunk a DBMS segítségével megfelelni. Ráadásul az alkalmazás kódját gyakran az üzleti szabályok betartatására használjuk.

Ha az üzleti szabályok menedzsmentjének kódjára támaszkodunk, jó, ha az üzleti szabályok összes aspektusára biztosítunk függvényt. Például használjunk egy DeleteEntity() (entitás törlése) nevű függvényt ahelyett, hogy a törlés SQL-utasítását a kódba építené. Ilyenkor az üzleti szabályokon is gyorsan változtatha­tunk, aminek hatása a teljes alkalmazásban azonnal megmutatkozik. A DeleteEntity() függvény belsejébe zárhatja az adatbázis integritásával kapcsola­tos megszorítások ellenőrzésének logikáját és egyéb üzleti szabályokat, és hibakó­dokat adhat vissza a cselekvés meghiúsulása okának megfelelően. Ez a kód újra­hasznosítását mozdítja előre, és egyszerűsíti az egész alkalmazásra érvényes új lo­gika bevezetését.

Visszatérve az árukatalógushoz, a következő lépés a létező termékek adatainak kezelésére szolgáló lapok létrehozása. Ezek a lapok logikailag azonosak a kategó­riák kezelésére szolgáló lapokkal. Az adatkezelő lapot a 15.4. ábra mutatja be, a lapot generáló fő szkript pedig a 15.11. programlistában olvasható.

Az új termékek felvételét, a meglévő termékek törlését és szerkesztését megva­lósító lapokat nem részletezzük. Egy új termék felvételének üzleti szabályai a kö­vetkezők:

A terméket egyetlen kategóriához kell hozzárendelnünk.

Kategóriáján belül a termék nevének egyedinek kell lennie.

A termék ára csak nulla, vagy annál nagyobb érték lehet.

A termék rakodási súlya csak nulla, vagy annál nagyobb érték lehet.

Pillanatnyilag a termék törlésének nincsenek megkötései. Amikor egy termék adatait szerkesztjük, akkor ugyanazokat az üzleti szabályokat kell betartanunk, mint egy új termék felvételekor. Az mgmt_funcs.php fájl egy részlete a 15.12. prog­ramlistában tartalmaz néhányat az alkalmazás egésze során használt adatbázis-kezelő függvények és üzleti szabályok közül.

Az adatkezelő alkalmazás csak egy kis része az egész termékkatalógus alkalma­zásunknak és a webes kezelői felületet biztosítja a katalógus adatainak karbantar­tására és kezelésére. A termékkatalógus másik fő célja a tételek megjelenítése, a tételek közötti keresés lehetővé tétele, valamint részletes információk megjelení­tése a katalógus elemeiről. A fejezet következő részében erről lesz szó.

Adatok megjelenítése

A termék adatbázis-adatai megjeleníthetők a kategória szerint, betűrend szerint, illetve egy adott termék keresésének lehetőségét tartalmazza. Ahhoz, hogy a ter­mékeket és a kategóriákat kereskedők szerint különíthessük el, ismét olyan session változót használunk, amivel az aktuális kereskedő megjelenítendő adatait azono­sítani tudjuk. Ezt a session változót még azelőtt beállítjuk, mielőtt a látogató először belép a termékeket megjelenítő területre.

A termékkatalógus főlapja a 15.5. ábrán látható. Ez a lap azonnali hozzáférést biztosít a kategóriák információihoz és a keresőszolgáltatáshoz. Ha nem létezik ka­tegória (nem tartalmaz terméket), a lap kiírja, hogy a kereskedő számára nem áll rendelkezésre termék. Az ezt generáló fő szkriptet lásd a 15.13. programlistában.

A főlapot generáló sablonfájlok nagyon hasonlítanak a kategóriák kezelését megvalósító szkriptben használatosakhoz. Az előző programlistában a kategóri­ákra történő kattintáskor az URL-t előállító GerCategoryHREF() függvényhez egy érdekes megjegyzést fűzünk. A függvény az mgmt_funcs.php fájl része, aho­gyan az a 15.14. programlistában is látható. A függvény megírásával egy olyan módszert biztosítottunk, amelynek segítőjével ugyanazzal a szkripttel több sta­tikus lapot is tudunk generálni a dinamikus adatokból. Ezt a módszert részletei­ben a következő fejezetben mutatjuk majd be.

A termékeket kilistázó szkriptet lásd a 15.15. programlistában. Ez az egyszerű szkript szolgál a kategória szerinti listázás, a betűrendes listázás és a keresés ered­ményeinek megjelenítésére is.

A szkript az első lépésben meghatározza a megfelelő adatok kiválasztásának módszerét. Ha a szkriptet egy HTTP POST eredményeképpen aktiválták, akkor a keresési szolgáltatás megvalósítására fogjuk használni. Ellenkező esetben ez vagy egy kategória, vagy egy betűrend szerinti listázás. Ha a $cat_id változó be van állítva, akkor kategória szerinti listázást kértek. A szkript a kérés típusáról függően állítja össze az SQL-utasítást. Az SQL-utasítás eredményei alapján az ered­ménylap termékek egy listáját vagy egy üzenetet tartalmaz, amely tudatja, hogy egyetlen termék sem felelt meg a kritériumnak. Minden rekordra ellenőrizzük a has_image_flag értékét is. Ha az érték true, akkor a kép szabályossá tett nevét használjuk fel, ellenkező esetben pedig egy alapértelmezett képet jelenítünk meg.

A kategóriák szerinti listázás, a betűrendes listázás és a keresés alapú listázás kimeneteit sorrendben a 15.6., 15.7. és 15.8. ábrákon figyelhetjük meg. Alaphoz a "knit" keresési feltételt használtuk.

Eddig tehát az adatbázisok által vezérlet webhelyek megjelenítésére koncent­ráltunk. Az adatbázisban található adatok megjelenítése általában sokkal egysze­rűbb az adatok kezelésénél, mert kevesebb kielégítendő feltétel van, valamint kevesebb alkalma adódik a felhasználónak a hibázásra. A következő két fejezet az itt ismertetett információkra és példákra épít.

Összefoglalás

Adatbázis-vezérelt webes alkalmazások létrehozásához sok tervezési és fejlesztési munkára van szükség, de az eredmény megéri a befektetett energiát. Ha az adatkezelő rendszer a helyére kerül, akkor az alkalmazást akárhonnan, bármikor módosíthatjuk, ami nagyon dinamikus, kezelhető webes alkalmazást eredményez. Fontos az adatbázis körültekintő tervezése és az alkalmazás üzleti szabályainak megragadása, amelyet a moduláris programozással tehetünk meg. Ha ezeket a lépéseket gondosan megtervezzük és implementáljuk, akkor az alkalmazás keze­lése és karbantartása is nagymértékben egyszerűsödik.