PHP - MySQL alapú raktárkezelő nyilvántartó rendszer

Miskolci Egyetem Miskolci Egyetem

Gépészmérnöki és Informatikai Kar Gépészmérnöki és Informatikai Kar

Alkalmazott Informatikai Intézeti Tanszék Általános Informatikai Intézeti Tanszék

PHP - MySQL alapú raktárkezelő

nyilvántartó rendszer

Szakdolgozat

Készítette:

Szilágyi Gergely

Szak: Mérnökinformatikus BSc,

Termelésinformatikai szakirány

Neptun kód: QD9VQE

Cím: 4935 Gelénes,

Kossuth út 33.

EREDETISÉGI NYILATKOZAT

Alulírott Szilágyi Gergely; Neptun-kód: QD9VQE

a Miskolci Egyetem Gépészmérnöki és Informatikai Karának végzős mérnökinformatikus BSc

szakos hallgatója ezennel büntetőjogi és fegyelmi felelősségem tudatában nyilatkozom és

aláírásommal igazolom, hogy

PHP – MySQL alapú raktárkezelő nyilvántartó rendszer

című szakdolgozatom/diplomatervem saját, önálló munkám; az abban hivatkozott szakirodalom

felhasználása a forráskezelés szabályai szerint történt.

Tudomásul veszem, hogy szakdolgozat esetén plágiumnak számít:

- szószerinti idézet közlése idézőjel és hivatkozás megjelölése nélkül;

- tartalmi idézet hivatkozás megjelölése nélkül;

- más publikált gondolatainak saját gondolatként való feltüntetése.

Alulírott kijelentem, hogy a plágium fogalmát megismertem, és tudomásul veszem, hogy

plágium esetén szakdolgozatom visszautasításra kerül.

Miskolc, 2018. 11. 30.

…….……………………………….…

Hallgató

Tartalomjegyzék

1. BEVEZETÉS ................................................................................................................... 1

2. RAKTÁROZÁS, RAKTÁRKEZELÉS LOGISZTIKAI FOLYAMATA .................. 4

2.1. RAKTÁRAK................................................................................................................... 4

2.2. RAKTÁROZÁS ............................................................................................................... 5

2.3. TÁROLÁS ...................................................................................................................... 6

2.4. RAKTÁROZÁSI FOLYAMATOK ....................................................................................... 7

2.5. KÉSZLET ...................................................................................................................... 7

3. WEBES ARCHITEKTÚRA, FEJLESZTÉSI MÓDSZEREK ................................... 8

3.1. WEBES ALKALMAZÁSOK .............................................................................................. 8

3.1.1. Statikus weboldalak.............................................................................................. 8

3.1.2. Dinamikus weboldalak ......................................................................................... 8

3.2. WEBES ARCHITEKTÚRA ................................................................................................ 9

3.2.1. Kliens-szerver modell .......................................................................................... 9

3.2.2. Háromrétegű modell ........................................................................................... 12

3.3. FEJLESZTÉSI MÓDSZEREK ........................................................................................... 16

3.3.1. Kliensoldali technológiák ................................................................................... 16

3.3.1.1. HTML .......................................................................................................... 16

3.3.1.2. XML ............................................................................................................ 16

3.3.1.3. CSS .............................................................................................................. 17

3.3.1.4. JavaScript .................................................................................................... 17

3.3.1.5. AJAX ........................................................................................................... 18

3.3.2. Szerveroldali technológiák ................................................................................. 18

3.3.2.1. Java .............................................................................................................. 18

3.3.2.2. ASP.NET ..................................................................................................... 19

3.3.2.3. Perl ............................................................................................................... 20

3.3.2.4. Python .......................................................................................................... 20

3.3.2.5. Ruby ............................................................................................................ 21

3.3.2.6. Oracle Application Express (APEX) ........................................................... 22

3.3.2.7. PHP .............................................................................................................. 22

3.3.3. Adatbázis-kezelés ............................................................................................... 23

3.3.3.1. SQL .............................................................................................................. 23

3.3.3.2. MySQL ........................................................................................................ 23

4. TERVEZÉS .................................................................................................................... 25

4.1. SPECIFIKÁCIÓ ............................................................................................................. 25

4.1.1. Követelmények feltárása és specifikációja ........................................................ 25

4.1.2. Megvalósíthatóság .............................................................................................. 28

4.2. UML, USE CASE MODELL ........................................................................................... 30

4.3. ARCHITEKTURÁLIS TERVEZÉS .................................................................................... 32

4.3.1. WAMP ............................................................................................................... 33

4.3.2. Eclipse PDT........................................................................................................ 35

4.4. AZ ADATBÁZIS MEGTERVEZÉSE.................................................................................. 37

4.4.1. Szükséges táblák meghatározása ........................................................................ 37

4.4.2. Normalizálás....................................................................................................... 37

4.4.3. ER modell ........................................................................................................... 38

4.4.4. Relációs adatmodell ........................................................................................... 39

5. IMPLEMENTÁCIÓ ...................................................................................................... 43

5.1. ADATBÁZIS SÉMA IMPLEMENTÁCIÓJA ........................................................................ 43

5.1.1. Táblák létrehozása .............................................................................................. 44

5.1.2. Idegen kulcs és további megszorítások .............................................................. 44

5.1.3. Naplózó log táblák ............................................................................................. 45

5.2. A RENDSZER MODULJAINAK ÖSSZEKAPCSOLÁSA ........................................................ 47

5.2.1. PHP implementáció ............................................................................................ 47

5.2.1.1. functions.php ............................................................................................... 47

5.2.1.2. header.php, index.php .................................................................................. 49

5.2.1.3. felhasznalok.php .......................................................................................... 51

5.2.1.4. login.php, logout.php ................................................................................... 52

5.2.2. Bootstrap és jQuery integrálása a PHP fájlokba ................................................ 53

6. A RENDSZER MŰKÖDÉSÉNEK LEÍRÁSA, TESZTELÉSE ................................ 56

6.1. TESZTELÉS PÉLDAADATOK FELTÖLTÉSÉVEL .............................................................. 60

6.2. JÖVŐBELI FEJLESZTÉSI LEHETŐSÉGEK ........................................................................ 66

ÖSSZEGZÉS ...................................................................................................................... 67

SUMMARY ........................................................................................................................ 68

IRODALOMJEGYZÉK ................................................................................................... 69

CD MELLÉKLET TARTALMA..................................................................................... 72

PHP - MySQL alapú raktárkezelő nyilvántartó rendszer

1

1. Bevezetés

A szakdolgozatom témája egy olyan web alapú raktárkezelő nyilvántartó rendszer

tervezése, fejlesztése, bemutatása, amelyben egy LED izzókat és fénycsöveket gyártó cég

termékeit, és az azokat alkotó alkatrészeket tárolhatjuk el, és rendelhetjük egymáshoz úgy,

hogy ezen adatokat egyszerűen és gyorsan kezelhesse az arra jogosult személy.

A mérnökinformatikus képzésen kötelező Szakmai gyakorlatom ezen cégnél végeztem.

Hat hetet töltöttem ott, az ottlétem alatt pedig engem bíztak meg azzal, hogy készítsek el a

lehetőségekhez és időtartamhoz mérten egy raktárkezelő nyilvántartó rendszert a cég

számára, ugyanis az addigi Excelben vezetett kezdetleges raktárnyilvántartásuk kevésbé

volt átlátható, és sok volt benne a redundáns adat, így a raktáros beosztásban dolgozó

munkatársuknak ezzel lényegesen megkönnyíteném és meggyorsítanám a munkáját.

Szakdolgozatomban az általuk kért rendszert fejlesztem tovább újabb hasznos funkciókkal.

Egyetemi és korábbi tanulmányaim során nem készítettem még ilyen volumenű programot,

ezért úgy gondoltam, ez egy jó lehetőség arra, hogy fejlődjek, fejlesszem a

problémamegoldó és programozási készségemet.

A cég logisztikai vezetőjével való megbeszélés során körvonalazódott az elképzelésük,

elvárásuk a rendszerrel kapcsolatban.

Követelmény, elvárás a rendszerrel szemben:

- könnyen megérthető legyen, hogy azt a laikus, fejlesztési módszereket nem ismerő

személlyel is rövid idő alatt meg lehessen ismertetni

- átlátható, lényegre törő és egyszerű legyen a felület megvalósítása

- könnyű telepíthetőség

- visszafogott erőforrás-használat

- megfelelés az adatbiztonsági követelményeknek.

Fő célom az volt, hogy olyan rendszert tervezzek és fejlesszek, amelynek alrendszerei

kompatibilisek egymással, zökkenőmentesen és rugalmasan együtt tudnak működni,

kiforrott technológiák.


2

A rendszer alapjául természetesen egy adatbázist képzeltem el, a mérnökinformatikus

képzés alatt az Adatbázis rendszerek I. és II. tárgyak során megismerhettem és

megtanulhattam az adatbázis-kezelés és az SQL lekérdezőnyelv alapjait, ezt a tudást

alkalmaztam is a tervezés és fejlesztés közben.

Mivel az adatbázis alapú webfejlesztés egyik legnépszerűbb és leggyakrabban használt

architektúrája a PHP és a MySQL együttese, kliensoldalon pedig a JavaScript a népszerű

választás, ezért én is ezen fejlesztői eszközök mellé tettem le a voksomat.

A PHP felel a logika és a lekérdezések végrehajtásáért, a JavaScript pedig a felhasználói

felület dinamikusságáért, gördülékenységéért, az AJAX technológia használata pedig segít

a két programozási nyelv közös kommunikációjában. A PHP-vel és a JavaScripttel

tanulmányaim alatt ugyan nem találkoztam, de az Objektum orientált programozás tárgy

keretén belül a Java programozási nyelvvel megismertem azt a felfogást,

gondolkodásmódot, ami szükségeltetik a két nyelv megértéséhez, megtanulásához és

alkalmazásához. Az interneten fellelhető hatalmas mennyiségű információ, leírás, tananyag

és példaprogram segítségével lehetőségem nyílt ismereteimet bővíteni, és a gyakorlatba

ültetni ezt a tudást.

A szakdolgozatom első részében röviden bemutatom a raktározás és raktárkezelés témáját.

Az internet térnyerésének köszönhetően az informatika területén az egyik leggyorsabban,

legdinamikusabban fejlődő ág a webes alkalmazások fejlesztése. Így a webes architektúrát

és az ahhoz kapcsolódó ismert, elterjedt módszereket, programozási nyelveket is

ismertetem röviden, azok előnyeivel és hátrányaival.

A következő részben magát a megvalósítandó rendszert tervezem. Mivel a rendszer alapja

adatbázis, ezért annak az egyedeit/relációit, tulajdonságait, és ezek kapcsolatait alaposan

meg kell tervezni. Ezt vizuálisan is megjelenítve, a könnyebb átláthatóság érdekében ER-

modellel és relációs modellel is ábrázolom.

A szakdolgozatom második felében a konkrét architektúra és adatbázis tervezéssel,

implementációval, és a választott eszközök segítségével kialakított rendszer részletes

ismertetésével foglalkozom. A feladat bemutatása során fiktív elnevezéseket és

számadatokat fogok használni. A rendszerek tesztelése is fontos feladat, így erre, illetve a

jövőbeli bővíthetőségre, fejlesztésre is kitérek.


3

Végül az irodalomkutatással, tervezéssel, fejlesztéssel és teszteléssel szerzett

tapasztalataimmal, véleményemmel és értékelésemmel zárul a szakdolgozatom.


4

2. Raktározás, raktárkezelés logisztikai folyamata

Napjainkban egyre nagyobb szerep jut a raktár-technológiának. Növekszik a jelentősége a

gazdaságban is, ugyanis a sikeres vállalkozások jövőjét nagyban befolyásolja egy jól

működő raktározási rendszer.

A raktározás speciális helyet foglal el a termeléstől a felhasználásig terjedő

folyamatrendszerben, ahol épületeivel, felszereléseivel szakszerűen végzi el a

nyersanyagok, félkész- és késztermékek, eszközök állapotának megóvását, a készletek

összehangolását, és kiegyenlítését.

2.1. Raktárak

A részfolyamatok összekötő elemei a raktárak, amelyeket nem, mint épületeket kell

kezelni, hanem mint komplex létesítményeket. A raktározással összefüggő, konkrét

feladatokat a raktár látja el. Célja a betárolt áruk minőségi és mennyiségi változásának a

megakadályozása, valamint a termelés és a kiszállítás anyagigényeinek biztosítása.

A raktár részeit képezik a raktári létesítmények, tároló-berendezések, tároló rendszerek, az

információs berendezések és eszközök, valamint az áruk szállítására és mozgatására

alkalmas gépek. Manapság a gyárak, üzemek, termelő egységek, szolgáltató helyek,

üzletek stb. elképzelhetetlenek korszerű és minden igényt kielégítő raktárak nélkül.

Ezeknek leginkább a pozitív tényezőit látjuk. Azonban gyakran előforduló probléma a

termelési és az elosztási folyamatok különböző működési sebessége. A raktárak ilyenkor

kiegyenlítő szerepet játszanak. Szintén pozitív tényező, hogy folyamatosan rendelkezésre

állnak, hogy a termelés folyamatossága ne szakadjon meg. Összekötő szerepet játszik a

belföldi és a külföldi logisztikai egységek között. A raktárak olyan körülményeket

biztosítanak a nyers, félkész és késztermékeknek, hogy azok minősége minden esetben

megfelelő maradjon. Ezt építészeti és egyéb körülmények kialakításával éri el.

A raktárak nem csak kedvező tényezőkkel rendelkeznek. Negatívumként említhető, hogy a

raktárak létesítése, fenntartása és üzemeltetése jelentős költségekkel jár. Továbbá növelheti

az átfutási időt a logisztikai folyamat raktár területén történő megállítása. Nem


5

elhanyagolható az a tény sem, hogy a raktárterek kihasználtsága az év nem minden

időszakában egyforma.

A raktárak kialakításakor vagy helyének kiválasztásakor ezeket a pozitív és negatív

tényezőket egyaránt figyelembe kell venni.

2.2. Raktározás

A raktározásnak két alapvető feladata van: a tárolás és az ellátás. A raktározás tárolási

funkciója azt jelenti, hogy a már előállított és legyártott termékek minőségromlás nélküli

elhelyezését biztosítsa. Az ellátás során az áru igény szerinti rendelkezésre bocsátását

valósítja meg. A logisztika alapelvei szerint a két funkció közül az ellátás a fontosabb,

ezért mindig a vevő igényeit kell figyelembe venni és minőségileg megfelelő árut

biztosítani. Ezért előnyt élvez az ellátási funkció a tárolással szemben. A két funkció

azonban nem független egymástól, sőt azok összehangolása a kívánatos. Minden esetben

szükséges, hogy a tárolt készletek megfelelő minőségben és mennyiségben álljanak

rendelkezésre.

Az áruforgalom folyamatában a raktározás kiemelt helyen szerepel. A raktározási folyamat

kezdete az a pont, ahol a beszerzési folyamat véget ér. Végpontja pedig vagy a termelés

vagy az értékesítés kezdete. Persze attól függően, hogy a produktum átdolgozásra kerül-e

vagy sem.

A raktározás részfolyamatai a következők:

az áru átvétele

az áru tárolása és kezelése

az áru felhasználási helyére való eljuttatása

Az áruátvételt követően a termékeket minden esetben tárolni, raktározni kell. A folyamat

célja az, hogy az áru értékcsökkenését lassítsa és romlását megakadályozza. Több káros

hatás negatívan befolyásolhatja az áru minőségét: a raktári kártevők jelenléte, a nem

megfelelő hőmérséklet, a magas páratartalom, az erős napsugárzás, a szakszerűtlen tárolás.

A raktárak kialakításakor több, az áru és az ergonómia szempontjából is alapvető dolgot

kell figyelembe venni. A könnyű megközelíthetőség mind a raktárépület környezetében,


6

mind a belső tér kialakításában rendkívül fontos. Az árumozgatások lebonyolítására gyors

és akadálymentes, azaz lépcső és küszöb nélküli útvonalat kell biztosítani a kézi

szállítóeszközök, daruk, targoncák és rakodógépek számára, mint ahogy az 1. ábrán is

látható.

1. ábra [1], Egy raktár megvalulás

Olyan környezet kialakítására kell törekedni, amelyben érvényesülnek a munka-,

balesetvédelmi és tűzrendészeti előírások, valamint a higiéniai szempontok. A jól

megválasztott világítástechnika kiépítése nagyban elősegíti a munkafolyamatok

gördülékenységét, a megfelelő szellőzőrendszerrel pedig elkerülhetőek a tárolási

veszteségek, amelyek általában a nem megfelelő hőmérsékletre vezethetőek vissza.

2.3. Tárolás

A termékek tárolását befolyásolja az anyag kiszerelése, azok fizikai és kémiai

tulajdonságai. A tárolóeszközök kiválasztásakor arra kell törekedni, hogy az áru számára a

legkedvezőbb tárolási módot válasszuk. Ez lehet halmos vagy tömbtárolás, polcrendszerű

vagy soros tárolás illetve ömlesztett vagy speciális tárolás. A zsákos, ládás, kosaras

göngyölegekben szállított termékeket jellemzően halmazokban tárolják. Polcos elhelyezést


7

abban az esetben érdemes alkalmazni, ha nagy választékú, kisebb egységekbe csomagolt

árukat raktározunk. A polcok elhelyezkedésénél fontos szempont, hogy áttekinthetőek és

könnyen megközelíthetőek legyenek. A polcok kialakítása szerint beszélünk soros, járható,

eltolható és átmenő görgős elrendezésről.

2.4. Raktározási folyamatok

A raktározási folyamatok feladata a belső tevékenységek és az egymás közötti

kapcsolatoknak az irányítása, az ott folyó tevékenységek ellenőrzése valamint a hozzájuk

tartozó nyilvántartási feladatok végrehajtása. Ezek közül a legfontosabbak: a törzsadatok

nyilvántartása, a beszállítókkal való kapcsolattartás, a beszerzési és pénzügyi folyamatok

kezelése, munkafolyamatok irányítása és a készletgazdálkodás. Kiegészítő feladatai még a

naprakész adatállomány megléte, a ki- és betárolási műveletek adminisztrációja,

készletváltozási előrejelzések, készletutánpótlások aktualizálása.

A raktározás egyik feladata a megfelelő készletezés. A helyes készletezéssel elkerülhetjük

a termelés és a fogyasztás közötti időbeni eltérést. A hozzá fűződő tevékenység nagyban

befolyásolja az üzleti eredményt, mert az áru tárolása is jelentős költséggel jár, és nagy

pénzösszegeket köt le a túlzott felhalmozás.

2.5. Készlet

A készleteknek több fajtája van. Az állandó készlet az áruforgalom folyamatos

lebonyolításához szükséges. A törzskészlet ezen felül a tervezett növekedéshez igazodik. A

biztonsági készlet az előre nem látható igényeket szolgálja ki. A minimális készlet a

biztonsági és a törzskészlet összességét jelenti. A forgókészlet készletvonzata egy

áruszállítási és utánpótlási időszaknak. A teljes készlet magában foglalja a minimális és a

forgókészletet.

A készletet vizsgálhatjuk időpontra vonatkozóan, időszakra vonatkozóan, az átlagkészlet

és az anyagfelhasználás viszonya szerint illetve az átlagkészlet és az árbevétel viszonya

szerint. [2][3]


8

3. Webes architektúra, fejlesztési módszerek

3.1. Webes alkalmazások

A webes alkalmazások fejlesztése egy olyan terület az informatikán belül, ami nem egy

önálló, elkülönített rész, hanem több másik terület kombinációjából, társításából származó

ágazat. A hagyományos és a webes alkalmazások eltérő fejlesztését a navigációs felépítés,

a felhasználói felület, az elvárások, használati szokások különbségeiben kereshetjük. Ilyen

különbségek lehetnek például az egyszerű, könnyen megérthető funkciók, a

platformfüggetlenség, a szélesebb célközönség, az állandó elérhetőség, a rövidebb

fejlesztési ciklus. A fejlesztés sosincs kész, ugyanis főleg a tartalom terén, folyamatos

fejlesztésre van szükség. [4]

3.1.1. Statikus weboldalak

A web kezdetén a weboldalak statikusak voltak. A statikus tartalomkiszolgálás során a

tartalom nem változik, csak ha kézi frissítés történik, hisz a webszerver csak a háttértárain

elhelyezett állományokat tudja kiszolgálni. [5] A statikus kódolásra alkalmas a HTML, a

JavaScript, a CSS, és minden olyan webes nyelv, ami kliens oldalon fut.

3.1.2. Dinamikus weboldalak

A dinamikus tartalmak iránt növekvő igény következtében elterjedtek a dinamikus

weboldalak, ezek teszik ki napjainkra a web legnagyobb részét. A különbség a statikus

weboldalakhoz képest, hogy a tartalmuk változhat a felhasználótól, a nap szakaszától, az

időzónától, a felhasználó országától és anyanyelvétől, és más egyéb tényezőktől függően.

A dinamikus weboldal tartalmazhat kliensoldali és szerveroldali szkriptet, vagy ezek

kombinációját, hogy létrehozza a változó tartalmat. Ezen oldalak HTML programozást is

tartalmaznak az alap struktúrához. [6]

Azon weboldalak, amelyek változnak egy oldalon belüli akcióra válaszolva, mint például

egy egér vagy egy billentyűzet tevékenység, kliensoldali szkriptet használnak. A

kliensoldali szkriptek kliensoldali tartalmat generálnak. A kliensoldali tartalom a szerver

helyett a felhasználó számítógépén generálódik. Ezekben az esetekben a böngésző letölti a


9

weboldal tartalmát a szerverről, végrehajtja a beágyazott kódot, aztán megjeleníti a

frissített tartalmat a felhasználó számára. A szkriptnyelvek, mint a JavaScript és Flash,

lehetővé teszik, hogy a weboldal reagáljon a kliensoldali eseményekre.

A betöltés vagy látogatás során változó weboldalak szerveroldali szkripteket használnak. A

szerveroldali tartalom olyan tartalom, ami weboldal betöltésekor generálódik. Például:

bejelentkező oldalak, fórumok, űrlapok, webáruház bevásárlókosarak, mind szerveroldali

szkriptet használnak, mivel ezek a weboldalak a hozzájuk beküldött adatoktól függően

változnak. [7]

3.2. Webes architektúra

3.2.1. Kliens-szerver modell

A kliens-szerver modell egy szoftver architektúra modell, ami két részből, kliens és szerver

rendszerekből áll, és egy számítógép hálózaton vagy ugyanazon a számítógépen

kommunikálnak egymással. A kliens-szerver alkalmazás egy elosztott rendszer, ami kliens

és szerver komponens együtteséből épül fel, és megfelelő lehetőséget biztosít a

terhelésmegosztásra. A kliens processz mindig egy kapcsolatot kezdeményez a szerverrel,

míg a szerver processz mindig kérelmekre vár bármely klienstől.

A kliens és szerver közötti interakciót gyakran szekvenciadiagramokkal ábrázolják, ezen

diagramok pedig UML-ben (Unified Modeling Language) standardizáltak.

A kliens-szerver szoftver architektúra az egyik legalapvetőbb modellé vált a hálózati

számítástechnikában, számos alkalmazás eme modell alapján lett megírva. Alapvető

hálózati funkciók, mint az E-mail, web elérés, adatbázis elérés, a kliens-szerver modellen

alapul. Például a böngésző is egy kliens program a felhasználó számítógépén, ami a világ

bármely webszerverén lévő információhoz hozzáférhet.

Kliens jellegzetességek:

Mindig kérelmet kezdeményez a szerverek felé

Válaszokra vár

Válaszokat fogad

Általában kisszámú szerverhez kapcsolódik egy időben


10

A végfelhasználókkal általában közvetlenül egy felhasználói,

grafikus interfészen keresztül lép kapcsolatba

Szerver jellegzetességek:

Mindig egy kérelemre vár valamely klienstől

Kiszolgálja a kliens kérelmeket, aztán a kért adattal válaszol a

kliensnek

A szerver kommunikálhat más szerverekkel annak érdekében,

hogy kiszolgálja a kérelmeket

Ha további információra van szükség a kérelem végrehajtásához

(vagy az adatbiztonság meg van valósítva), a szerver kérelmezhet

további adatokat (pl. jelszó) a klienstől, mielőtt feldolgozza a

kérelmet

A végfelhasználók jellemzően nem lépnek kapcsolatba

közvetlenül a szerverrel, hanem egy klienst használnak

A modell előnyei:

Lehetséges kicserélni, javítani, fejleszteni, vagy akár áthelyezni

egy szervert úgy, hogy közben a kliensei előtt ez mind észrevétlen

marad, és nem érinti őket a változás. Ezt a változástól való

függetlenséget enkapszulációnak is szoktuk nevezni.

Az összes adat a szervereken van tárolva. A szerverek jól tudják

kontrollálni a hozzáférhetőséget és az erőforrásokat, hogy

garantáltan csak azok a kliensek férjenek hozzá és módosítsák az

adatokat, amelyeknek megfelelő engedélyük van.

Mivel az adattárolás centralizált, az adminisztrátorok

egyszerűbben tudják módosítani az adatokat.

Már számos fejlett kliens-szerver technológia elérhető, amelyek

úgy lettek tervezve, hogy céljuk az adatbiztonság, a

felhasználóbarát felület, és a könnyű használat biztosítása legyen.

A modell több különböző specifikációjú klienssel is működik.

A modell hátrányai:


11

Ahogy a szervernek egyidejűleg szóló kérelmek száma nő, úgy a

szerver túlterheltté válhat.

Ha egy szerver hibás, a kliensek kérelmeit nem lehet kiszolgálni.

[8]

A tradicionális kétrétegű modell az 2. ábrán látható. Meglehetősen egyszerű: a kliens

alkalmazások és a kapcsolódó alkalmazások közvetlenül hozzáférnek az adatbázishoz.

2. ábra [9], Kétrétegű architektúra

Egy hagyományos kétrétegű alkalmazásban az összes feldolgozás a kliens alkalmazásban

történik – az adatbázis csak egy adattárolóként szolgál. A szerver logikája tartalmazhat

egyszerű megszorításokat (pl. idegen kulcs megszorítás, nem nulla megszorítás). Ezek az

adatbázis megszorítások elutasítják azokat a műveleteket, amelyek nyilvánvaló

adatintegritási problémákat okoznának.

A kétrétegű modell előnyei:

Ismert architektúra

Könnyen hozzáférhető

Produktív


12

Széles körben bevált

A kétrétegű modell hátrányai:

Skálázhatóság

Gyenge logika megosztás

Alkalmazás elosztás

Távoli használat

Adatbázis struktúra

3.2.2. Háromrétegű modell

Ezekben a modellekben az alkalmazás három formális rétegre van osztva: prezentációs

rétegre (vagy GUI réteg), középső rétegre (vagy alkalmazás szerver) és adat rétegre. A

kulcsfontosságú kiegészítés ebben a modellben az alkalmazás szerver, amibe be van

ágyazva az alkalmazás üzleti logikája. A 3. ábra bemutatja a háromrétegű architektúrát.

3. ábra [10], Háromrétegű architektúra


13

Prezentációs réteg

A prezentációs réteg különféle kliens típusokat tartalmazhat, úgy, mint a szabványos kliens

(a kliens-szerver alkalmazás részeként), internet kliens, és jelentéskészítő eszközök. Mivel

az üzleti logika a középső rétegben van megvalósítva, viszonylag kevés munkát igényel, ha

szükség esetén két vagy több környezetben ugyanazt a funkciót kellene biztosítani. A

prezentációs réteg az alkalmazás szervertől kér szolgáltatásokat, de ez nem korlátozódik a

GUI kliensekre. A „legfelső” réteg elemei tartalmazhatnak egyéb applikációkat is,

amelyeknek információt vagy adatot kell cserélniük ezen alkalmazással.

Középső réteg (Alkalmazás szerver)

Az alkalmazás szervert több gazdagépen is el lehet osztani. Transaction Processing (TP)

tranzakció-kezelő vagy Object Request Broker (ORB) használható a kliens kérelmek több

adatbázis szerveren történő kiegyenlítésére, valamint szükség esetén további alkalmazás

szerver példányok elindítására/leállítására.

CORBA:

„A CORBA az Object Management Group egyik technológiai ajánlása. A rövidítés

jelentése Common Object Request Broker Architecture, azaz egy ORB (Object Request

Broker) általános felépítése. Az ORB-t fordíthatnánk objektum ügynöknek, kezelőnek, de

leginkább csak összekötőnek vagy hírvivőnek. Az Object Management Group kidolgozott

egy olyan architektúrát, amely objektum-orientált rendszerek közös váza lehet (Object

Management Architecture). Ilyen rendszerben vagy rendszerekben az egyes

számítógépeken különféle objektumok vannak installálva, amelyek úgy tudnak igazán

hatékonyan működni, ha egymás műveleteit hívni tudják. Ennek az architektúrának az

alapja az ORB, amely az objektumok közötti üzenetváltásokat (művelethívásokat)

bonyolítja. Azért nem tekinthető objektum kezelőnek egy ORB, mert a kezelőtől

megszokott szolgáltatásokat (objektumok létrehozása, tárolása, aktiválása stb.) nem ő

végzi, hanem ezek tőle elkülönülő illetve rajta alapuló szolgáltatások.

Mit tesz egy ORB, ha beérkezik egy objektum-hívás:

1. Megkeresi a hívott objektumot (amely lehet más számítógépen, de mindenképpen

ugyanazon az ORB-n belül),


14

2. Az objektumot aktiválja ha kell, azaz olyan állapotba hozza, hogy az fogadni tudja

a hívást,

3. Meghívja a műveletet az adott paraméterekkel,

4. Végül a hívóhoz visszajuttatja a művelet eredményeit vagy az esetleges

hibaüzeneteket.

Az ORB szempontjából két ügyfelet különböztethetünk meg; a klienst, hívót, amely

valamelyik objektum valamilyen műveletét szeretné végrehajtatni, és az objektum

implementációját, amely a műveletekhez tartozó kódokat tartalmazza. Egy alkalmazáson

belül persze a szerepek keverednek, vagyis vannak olyan objektum implementációk,

amelyek más implementációkat hívnak, azaz hívóként viselkednek. Az ORB-hez két

szolgáltatás nélkülözhetetlen: az interfész és az implementáció tároló. Az interfész tároló a

hívó számára fontos információkat tartalmazza, míg az implementáció tároló magát a

végrehajtható kódot tárolja és kezeli.” [11]

Mivel az alkalmazás szerver tartalmazza az üzleti logikát (ahol a komplex feldolgozás

nagy részének be kellene következnie), így lehetséges több felhasználó támogatása több és

gyorsabb alkalmazás szerver hozzáadásával, anélkül, hogy újra kellene tervezni az

architektúrát vagy újraépíteni az alkalmazást.

Nem szükséges fizikailag meghatározni a középső réteget a saját szerverén. Az alkalmazás

korai kiadásában (ahol limitált számú felhasználó lehet) a középső réteg esetlegesen a

kliens gépen vagy az adatbázis szerveren is telepíthető. Amikor a felhasználók száma

növekszik (a későbbi verzióknál), a középső réteg áthelyezhető különálló szerver(ek)re, így

megkaphatók a kívánt skálázási előnyök.

Adat réteg

Az adat réteg tartalmazza az adatbázist, de tartalmazhat még adathozzáférési eljárásokat is.

Az adatbázis elhelyezhető egy különálló helyen, vagy elosztható, ha szükséges.

A háromrétegű modell előnyei:

Skálázhatóság

Hatékonyabb újrafelhasználás

Fejlettebb adatintegritás

Fejlettebb biztonság

Csökkentett elosztás


15

Fejlettebb elérhetőség

Rejtett adatbázis struktúra

A háromrétegű modell hátrányai:

Megnövekedett komplexitás

Kevesebb eszköz [12]


16

3.3. Fejlesztési módszerek

3.3.1. Kliensoldali technológiák

3.3.1.1. HTML

A HTML (Hypertext Markup Language, azaz hiperszöveges jelölőnyelv) egy szerzői

eszköz, amit internetes weboldalak létrehozására használnak. A HTML használatakor egy

szövegblokk körül van véve tagekkel, amelyek jelzik a böngészőnek, hogy hogyan jelenjen

meg a szöveg (például vastagon szedve vagy dőlt betűvel). HTML olyan platform-

független stílusok gyűjteménye, amelyek definiálják egy webes dokumentum különböző

komponenseit. A weboldalak készítésének preferált eszköze, mert minden böngésző tudja

értelmezni.

HTML-t a HTTP-vel (Hypertext Transport Protocol) és az URL-lel (Uniform Resource

Locator) együtt Tim Berners-Lee hozta létre az 1980-as évek második felében.

A HTML grafika területén lévő gyengeségeinek köszönhetően létrehozták a dinamikus

HTML-t. [13]

3.3.1.2. XML

A 2000-es évek elejére az XML (Extensible Markup Language, azaz bővíthető jelölőnyelv)

hamar a World Wide Web közvetítőnyelvévé emelkedett, kiszorítva a HTML-t, a web

kezdete óta a tartalom kódolásának a domináns nyelvét. A World Wide Web Consortium

(W3C) 1996 szeptemberében elindította az XML Munkacsoportot, az XML 1.0-s verziója

1997 decemberében gördült ki, mint W3C ajánlás, és következő év februárjában a

szervezet jóváhagyta az XML-t, mint szabványt.

Bár az XML széles körben nyelvként ismert, mégis a szakértők metanyelvnek hívják – egy

nyelvtan, amely meghatározza a nyelv szabályait és folyamatait. Az XML csaknem

korlátlan abban a kapacitásában, hogy nem csak a formát, hanem tartalmat is

meghatározzon. Ez azt jelenti, hogy egyetlen, univerzális tag gyűjtemény sincs, ami az

XML-t alkotja: az egyéni felhasználók, vállalatok, iparágak és más csoportok képesek új

nyelveket és attribútumokat meghatározni a saját igényeiknek megfelelően. Technikailag

az XML nem helyettesíti a HTML-t, hanem lefedi azt. [14]


17

3.3.1.3. CSS

A CSS-t 1994. október 10-én dolgozta ki Håkon Wium Lie, és a W3C-n belül egy,

úgynevezett CSS Munkacsoport tartotta fenn. A CSS Munkacsoport dokumentumokat,

azaz specifikációt hoz létre.

A Cascading Style Sheets, azaz CSS, egy egyszerű tervezési nyelv, amelynek szándéka,

hogy leegyszerűsítse a weboldalak tisztességes külsejűvé alakításának folyamatát. A CSS

használatával szabályozni lehet a szöveg színét, a betűtípusok stílusát, a bekezdések

közötti távolságot, az oszlopok méretét és elrendezését, háttérképek vagy háttérszínek

használatát, különböző eszközök képernyőméreteit, valamit számos egyéb hatást. A CSS-t

leggyakrabban a HTML vagy XHTML jelölőnyelvekkel kombinálják.

A CSS előnyei:

Időmegtakarítás

Az oldalak gyorsabb betöltése

Egyszerű karbantartás

Más eszközökkel való kompatibilitás

Globális webes szabványok

Offline böngészés

Platformfüggetlenség [15]

3.3.1.4. JavaScript

1995 májusában Brendan Eich hozta létre, majd ugyanezen év decemberében, a Sun

védjegyengedélyének megszerzésével, a JavaScript nevét elfogadták. [16]

A JavaScript egy olyan programozási nyelv, amelyet kifejezetten a világhálón lévő

elektronikus dokumentumokra terveztek. Szkriptnyelvként a JavaScript célja, hogy

weboldal tervezői egy lépéssel túllépjenek a HTML-en, egy teljes programozási nyelv

bonyolultsága, összetettsége nélkül. Egy egyszerű JavaScript program érdekes interaktív

funkciókat kölcsönözhet egy weboldalnak. A JavaScriptben nincs fordítás, a HTML-be

ágyazva a böngésző értelmezi. [17]

A JavaScript előnyei:

Sebesség


18

Egyszerűség

Sokoldalúság

Csökkentett szerver terheltség

A JavaScript hátrányai:

Biztonság

A végfelhasználótól való függés [18]

3.3.1.5. AJAX

Az Ajax nem egy programozási nyelv vagy eszköz, hanem egy koncepció, egy kliensoldali

szkript. A legmegfelelőbb definíció talán az, hogy az Ajax az az eljárás, ami adatot cserél a

szerverrel, és frissíti a weboldal egyes részeit – az egész oldal újratöltése nélkül. Maga az

Ajax többnyire egy általános kifejezés a különféle JavaScript technikákhoz, amelyek a

webszerverhez való dinamikus csatlakozásra használhatók, több oldal szükségszerű

betöltése nélkül. Az AJAX eredetileg egy mozaikszó az Aszinkron JavaScript és XML-re.

Az aszinkron azt jelenti, hogy több esemény történik egymástól függetlenül. [19]

Az Ajax előnyei:

Visszahívások

Aszinkron hívások

Felhasználóbarát

Fokozott sebesség

Az Ajax hátrányai:

Vissza és a Frissítés gombok hasztalanná válhatnak

Keresőmotor indexelés [20]

3.3.2. Szerveroldali technológiák

3.3.2.1. Java

A Java egy objektumorientált programozási nyelv, amelyet James Gosling és a

munkatársai a Sun Microsystems-nél fejlesztettek ki az 1990-es évek elején. A


19

hagyományos nyelvektől eltérően a Java-t egy bájtkódra kell fordítani, amelyet ezután

(általában JIT-összeállítással) Java virtuális gép futtat. A Java csak távolról áll

kapcsolatban a JavaScripttel, bár hasonló a nevük és C-szerű szintaxison osztoznak. [21]

A webes alkalmazások létrehozásához használt Java technológiák részei a Java EE

platformnak, számos Standard Edition (Java SE) osztály és csomag mellett.

Java előnyei:

Egyszerű

Objektumorientált

Platformfüggetlen

Elosztott

Allokáció

Többszálú

A Java hátrányai:

Teljesítmény

Biztonsági aggodalmak [22]

3.3.2.2. ASP.NET

A Microsoft Active Server Pages (ASP) egy Microsoft által létrehozott szerveroldali

szkript technológia, ami megkönnyíti az interaktív webes alkalmazások fejlesztését. Az

ASP megoldásokat kínál a tranzakciók feldolgozására és a munkamenet állapotának

kezelésére.

Az ASP.NET-et a fejlesztők ASP-vel kapcsolatos problémáira való közvetlen válaszként

fejlesztették ki. Az ASP.NET egy egységes webfejlesztési modell, amely magában foglalja

a vállalati szintű webes alkalmazások fejlesztéséhez szükséges szolgáltatásokat, minimális

kódolással. Az ASP.NET része a .NET-keretrendszernek, és alkalmazások írásakor

hozzáférhetünk a keretrendszerhez tartozó osztályokhoz. [23]

Az ASP.NET olyan szolgáltatásokat nyújt, amelyek lehetővé teszik az interaktív,

adatvezérelt webes alkalmazások és webszolgáltatások létrehozását, telepítését és

végrehajtását. Mint az ASP, az ASP.NET is szerveroldali technológia. [24]


20

3.3.2.3. Perl

A Perl egy általános célú programozási nyelv, amelyet Larry Wall fejlesztett ki 1987-ben.

A Perl állítólag a „Practical Extraction and Reporting Language” kifejezést jelenti, bár

valójában nem egy rövidítés; egy rövidített változata a program eredeti nevének, a

Pearlnek. A Perlt úgy írták le, mint a programozási nyelvek „svájci bicskája”. Erről az

elnevezésről következtethetünk arra, hogy a programozók hogyan látják a Perl nyelvet –

egy nagyon hatékony eszköz, ami szinte mindenre képes.

A Perl tipikus használata: szövegfeldolgozás, rendszeradminisztrációs feladatok, CGI és

webes programozás, adatbázis interakció, egyéb internetes programozás, kevésbé tipikus

alkalmazások.

A Perl előnyei:

Együttműködő

Ingyenes

Gyors

Biztonságos

Könnyen tanulható

Rugalmas [25]

A Perl hátrányai:

Limitált GUI támogatás

Saját kód védelme - ha megosztjuk a megosztjuk a saját

megoldásunkat, magát a kódot osztjuk meg

Megbízhatósági aggodalmak

Szriptek karbantartása – a Perlt sokan olvashatatlannak tartják

[26]

3.3.2.4. Python

Az 1980-as évek végén Guido Van Rossum létre akart hozni egy interpretált nyelvet, ami

kiterjeszthető, így született a Python. [27] A Python egy könnyen tanulható, hatékony,

interpretált programozási nyelv. Magas szintű adatszerkezeteket és egyszerű, de effektív


21

megközelítést kínál az objektumorientált programozáshoz. [28] A Python ingyenes és nyílt

forráskódú, szabadon felhasználható és terjeszthető, akár kereskedelmi célokra is, sőt, a

forráskódja is módosítható. A Python egy nagy közösségnek köszönhetően folyamatosan

javítja, fejleszti az egyes iterációkat.

A Python alkalmazása: webes alkalmazások, tudományos és numerikus számítások,

szoftver prototípusok létrehozása, programozás megtanulásához.

A Python hátrányai:

Hiányos a mobil számítástechnikában és a böngészőkben

Futásidejű hibák

Fejletlen adatbázis hozzáférési rétegek [29]

Django: a Django egy ingyenes és nyílt forráskódú web keretrendszer a Python számára.

Amellett, hogy könyvtárakat biztosít az olyan közös webes feladatok számára, mint az

adatbázis interakció és munkamenet menedzsment, a Django beépített adminisztrációs

oldalt is tartalmaz. [30]

3.3.2.5. Ruby

Alkotója, Yukihiro „Matz” Matsumoto a kedvenc nyelvei részeit vegyítette össze (Perl,

Smalltalk, Eiffel, Ada és Lisp), hogy egy új nyelvet hozzon létre, ami egyensúlyba állítja

funkcionális programozást az imperatív programozással. A Ruby egy hatékony és

dinamikus nyílt forráskódú, objektumorientált nyelv, amelyet 1993-ban kezdett el

fejleszteni Matsumoto. A Ruby teljesen ingyenes, szabadon használható, másolható,

módosítható és terjeszthető. [31]

A Ruby alkalmas következő problémákra: szövegfeldolgozás, CGI programozás, GUI

programozás, XML programozás, prototípuskészítés [32]

A Ruby hátrányai:

Skálázhatóság

Lassúság [33]


22

Ruby on Rails: a Rails egy szoftverkönyvtár, amely kiterjeszti a Ruby programozási

nyelvet. A Rails egy weboldalak építésére való keretrendszer. Egyesíti a Ruby nyelvet a

HTML-lel, CSS-sel és a JavaScripttel, hogy webszerveren futó webes alkalmazást

hozhasson létre. Mivel egy webkiszolgálón fut, a Railst szerveroldali vagy backend webes

alkalmazásfejlesztési platformként tartják számon. [34]

3.3.2.6. Oracle Application Express (APEX)

Az Oracle Application Express egy hosztolt deklaratív fejlesztői környezet az adatbázis-

központú webes alkalmazások fejlesztéséhez és telepítéséhez. A beépített

szolgáltatásoknak köszönhetően – mint a felhasználói felület témák, navigációs vezérlők,

űrlap kezelők és rugalmas jelentések – az Oracle Application Express felgyorsítja az

alkalmazásfejlesztési folyamatot. Az Application Express motor valós időben rendereli az

alkalmazásokat az adatbázis táblákban tárolt adatokból.

Az Oracle APEX története ott kezdődik, amikor 2004-ben az Oracle piacra hozta a HTML

DB-t. Egy évvel később megjelent a HTML DB verziója egy grafikus felhasználói

interfésszel. A következő években javították a felhasználói interfészt és új funkciókat adtak

hozzá. 2006-ban változott meg a név HTML DB-ről APEX-re. [35]

Oracle APEX előnyei:

Egyszerű

Hatékony és bizonyított

Biztonságos

Hordozható [36]

3.3.2.7. PHP

Az 1994-ben Rasmus Lerdorf eredetileg az online önéletrajza látogatásainak a nyomon

követésére használta, ezen szkriptek csomagját Personal Home Page Toolsnak nevezte.

[37]

A PHP (Hypertext Preprocessor) egy széles körben használt nyílt forráskódú általános célú

szkriptnyelv, amely különösen alkalmas a webfejlesztésre, és beágyazható a HTML-be.

Hogy a kimenő eredmény HTML legyen, a PHP oldalak HTML-t tartalmaznak, beágyazott

kódokkal. A PHP kódot olyan speciális kezdő és végződő feldolgozó utasítások zárják


23

közre, mint a <?php és ?>, amelyek lehetővé teszik a „PHP módból” való ki és beugrást.

[38] A PHP elsősorban a szerveroldali szkriptekre fókuszál, így mindent megtehetünk,

amit bármilyen más CGI program tud, mint például az űrlapadatok gyűjtése, dinamikus

oldal tartalom készítése vagy cookie-k küldése és fogadása.

Három fő terület, ahol a PHP szkripteket használják: szerveroldali szkriptek, parancssor

szkriptelés, asztali alkalmazások írása.

Támogatja a ma használt webszerverek nagy részét, mint például az Apache-t. A PHP

egyik legerősebb és legjelentősebb jellemzője az adatbázisok széles körének támogatása.

Az adatbázis-alapú weboldalak írása rendkívül egyszerű az adatbázis-specifikus

kiterjesztések (mint például a MySQL) használatával. [39]

3.3.3. Adatbázis-kezelés

3.3.3.1. SQL

Az SQL, azaz Structured Query Language (Strukturált Lekérdezőnyelv) egy sztenderd

számítógépes nyelv a relációs adatbázisok eléréséhez, kezeléséhez és manipulálásához. Az

SQL adatok lekérdezésére, hozzáadására, frissítésére és módosítására használható.

Az 1970-es évek korai szakaszában az IBM-nél Raymond Boyce és Donald Chamberlin

által fejlesztett SQL-t a Relational Software Inc. (amit ma Oracle Corporation néven

ismerünk) hozta kereskedelmi forgalomba. A jelenlegi SQL szabványt az Amerikai

Nemzeti Szabványügyi Intézet (ANSI) felügyeli. [40]

Az SQL parancsok négy alcsoportba oszthatók:

- DDL, Data Definition Language, azaz adatdefiníciós nyelv

(CREATE, ALTER, DROP)

- DML, Data Manipulation Language, azaz adatkezelő nyelv

(INSERT, UPDATE, DELETE)

- DQL, Data Query Language, azaz adatlekérdező nyelv (SELECT)

- DCL, Data Control Language, azaz adatvezérlő nyelv (GRANT/

REVOKE, COMMIT/ ROLLBACK) [41] [42]

3.3.3.2. MySQL


24

A MySQL egy nyílt forráskódú, megbízható és rugalmas relációs adatbázis-kezelő

rendszer (RDBMS), amelyet PHP-vel használunk.

Mi a MySQL?

- 1994-ben fejlesztette ki Michael Widenius és David Axmark

- Egy adatbázis rendszer, amit a web alapú szoftver alkalmazások

fejlesztésére használnak

- Kis és nagy alkalmazásokra is használják

- Támogatja a szabványos SQL-t

- Ingyenesen letölthető és használható

- Jelenleg az Oracle Corporation által fejlesztett, forgalmazott és

támogatott

- C-ben és C++-ban íródott.

Kik használják?

- A legismertebb weboldalak, mint a Facebook, Wikipédia, Google

(nem a kereséshez), YouTube, Flickr

- CMS rendszerek, mint a WordPress, Drupal, Joomla, phpBB

- Számos webfejlesztő a világon, webes alkalmazások fejlesztésére.

[43]


25

4. Tervezés

4.1. Specifikáció

4.1.1. Követelmények feltárása és specifikációja

Miután kiderült, hogy egy raktárkezelő nyilvántartó rendszer elkészítése lesz a feladatom a

gyakorlatom során, első dolgunk a követelmények feltárása és specifikációja volt, ami

kritikus része egy program fejlesztésének, ugyanis az itt történt megbeszélések, és az azok

alapján általam készített feljegyzések kihatnak a tervezés és a fejlesztés későbbi szakaszára

is. Hibás specifikáció kiderülése esetén elkerülhetetlen a program módosítása, így emiatt

jelentősen megnőhet a fejlesztési idő. [44]

„A programfejlesztésben a specifikáció valamilyen programmal, programrésszel, vagy

szolgáltatással szemben támasztott követelmények leírása. A specifikáció jellemzően a

programfejlesztés korai szakaszában készül el, alapot szolgáltatva egyrészt a megbízóval

történő egyeztetéshez, másrészt a megvalósítás fő irányainak kialakításához.” [45]

Az én esetemben az egyeztetés a cég logisztikai vezetőjével történt.

A cég területén két raktár található, ezekben raklapos polcrendszeres a tárolás megoldása,

8-8 soros állvánnyal, 3 szintes polcokkal, könnyű megközelíthetőséggel. Ezen sorokon

belül találhatóak a lokációk, a lokációkon belül pedig a terméket vagy alkatrészeket

tartalmazó dobozok a raklapokon. A raklapok le és felemelését targonca segítségével

oldják meg. A dobozok homogének, azaz belül csak azonos típusú termékek és alkatrészek

lehetnek. A FIFO (First In First Out) elv alapján a doboz adatbázisba vitelének dátumát el

kell tárolni, a legrégebbi készletet kell először felhasználni, el kell kerülni a beragadást.

Az alkatrészek, amelyek a termékekhez szükségesek: búra, LED panel, táp, ház és foglalat.

A cég LED izzó, illetve fénycső típusainak a felépítése megegyezik, különbségüket a ház

anyagában, a foglalatban és teljesítményükben találhatjuk.


26

4. ábra [46], Izzó felépítése

5. ábra [47,] Izzó felépítése

A 4. ábra egy LED izzó, a 5. ábra pedig egy LED fénycső általános felépítését szemlélteti.

A megbeszélés során körvonalazódtak a követelmények. A cél egy raktárkezelő

nyilvántartó rendszer elkészítése, ami a következő feladatokat, problémákat oldja meg:


27

Lehessen:

termékeket és alkatrészeket kézzel felvinni és tárolni, megadni a

termékek és alkatrészek minimum készletét,

megadni, hogy melyik terméket milyen alkatrészek alkotnak és

hány darab szükséges belőlük a termék előállításához,

a termékeket vagy alkatrészeket tároló dobozokat kézzel felvinni

és megadni a dobozban található termék vagy alkatrész

darabszámot,

a dobozok lokációját és a lokációkat tartalmazó raktárakat kézzel

felvinni és megadni,

módosítani és törölni az összes kézzel felvitt adatot,

név alapján szűrni a felvitt adatokat,

hozzáadás, módosítás, törlés rekord interakciót egy naplózó log

táblában az adatbázisban letárolni.

Mindezek weboldalszerűen, gombokkal és űrlapokkal legyenek megoldva, jól átlátható és

könnyen megérthető felületen.

Fontos kitűzés volt még, hogy ne férhessen hozzá és ne tudja módosítani bárki az adatokat.

Azaz legyen egy bejelentkező felület, ahol a megfelelő személyek, akik felhasználónevet

és jelszót kapnak a cégen belül, be tudjanak lépni azzal, és a hozzájuk tartozó akciókat el

tudják végezni. A raktáros és az operátor munkakörű dolgozóknak különböző legyen az

elérhető felhasználói felület, a raktárosok mindent elérhessenek, felvihessenek és

módosíthassanak, az operátorok csak megtekinthetik a felvitt adatokat, információkat.

Ezen követelményeket a szakdolgozatom készítése alatt kiegészítettem olyan funkciókkal,

mint:

adatbiztonság megoldása különböző adatvédelmi programozási

technikákkal,

a dobozok megadásánál a dátum megadása, a beragadás

elkerülése

egy „Hiány” nevű menüpont, ahol a minimum készlet alá

csökkenő darabszámú termékeket vagy alkatrészeket tudjuk

megjeleníteni,


28

mozgatások (dobozokban felvétel, kivétel) követése egy külön

táblában,

havi ütemezésű termék/alkatrész raktárkészlet változás grafikon,

adatbázis biztonsági mentése.

Az adatbázis, amit létrehozunk, csak ezen az egy helyen lesz használva, így nem szükséges

az eloszthatóságon gondolkozni, ugyanis a cégnek ez az egyetlen telephelye, ahol a LED

termékek összeszerelése zajlik, így értelemszerűen az itt dolgozóknak kell csak elérniük az

adatokat.

Következő kérdés az volt, hogy az adatbázisban tárolt bejegyzések száma milyen

nagyságrendű lesz. A raktár, lokáció egyedek száma véges, helyes felvitel után nem

változnak, kis nagyságrendű számokról beszélünk. A termék, alkatrész egyedek száma

akkor változhat, ha a cég új, eddig nem gyártott LED izzók vagy fénycsövek gyártását

tervezi, de egyébként itt sincs szó hatalmas számosságról. A dobozok száma lehet még

változó, de a raktárak véges kapacitása miatt túl nagy változásra itt sem lehet számítani.

Könnyen belátható, hogy a legnagyobb bejegyzésszámmal rendelkező táblák a naplózó

mozgáskövető és log táblák lesznek, ugyanis ezek akár napi szinten is többször

változhatnak, így mindig új bejegyzés kerül a táblákba, ami könnyen növelheti az adatbázis

méretét. Mivel a cég kis cégnek számít, és a LED izzók gyártása a fő profilja, ezért az

adatbázisuk volumene eltörpül a nagyobb gyárak több ezer bejegyzéses tábláinak az

adatbázisai mellett.

4.1.2. Megvalósíthatóság

A specifikáció eme fázisában ellenőriztük, hogy a kívánalmak kielégíthetőek és

megvalósíthatóak-e a cég hardver- és szoftverrendszerével. A cég rendelkezik belső

hálózattal és egy szervergéppel, amit minden dolgozó elér a saját számítógépén. A gépek

Windows 7 operációs rendszerrel vannak ellátva, a szükséges fejlesztői eszközök pedig

könnyen beszerezhetők az internetről, és telepíthetők a gépekre. Mivel az adatbázis mérete

előreláthatóan nem lesz kirívóan nagy, így a szerver tárhelye elegendőnek bizonyul a

tárolásához.


29

A követelmények ellenőrzése és validálása során megállapítottam, hogy azok valószerűek,

és megvalósíthatónak tartottam a kitűzött feladatok megoldását. A rendelkezésemre álló

időt elegendőnek gondoltam a rendszer elkészítéséhez és teszteléséhez.


30

4.2. UML, Use case modell

Az UML (Unified Modeling Language) egy általános célú modellező nyelv a

szoftverfejlesztés területén, amelynek célja, hogy egy szabványos módszert nyújtson egy

rendszer tervének a szemléltetésére. Az UML megteremtését eredetileg az a törekvés

motiválta, hogy szabványosítsák az különböző jelölési rendszereket és megközelítéseket a

szoftvertervezéshez. [48]

A használati eset (use case) modell egy UML diagram típus, amelyben a felhasználó,

megrendelő szemszögéből modellezzük a rendszert. Még az implementáció előtt, a

tervezési fázisban kell elkészíteni, a specifikáció része. Tartalmazza, hogy milyen

felhasználói követelményeket támasztottunk a rendszerrel szemben, mit kell tudnia és

milyen funkciói legyenek.

Elemei: a rendszer, aktorok, használati esetek és relációk.

Az aktor a rendszer használója, egy szerepkör, lehet ember vagy egy másik rendszer, de

mindenképp a rendszeren kívül áll. Jelölése egy pálcikaember, alatta pedig az aktor

elnevezése.

A használati eset egy jól meghatározott, elvárt viselkedés, csak azt írja le, hogy mit kell

csinálnia, azt nem, hogy hogyan. Jelölése egy ellipszis, a közepére írva a viselkedés neve.

A relációk az aktorok és a használati esetek között lévő kapcsolatot jelölik. [49]

A 6. és a 7. ábrán a rendszer két felhasználója, a Raktáros és az Operátor nevű aktor use

case diagramja látható, a rendszerben végrehajtott viselkedésükkel.


31

6. Ábra, Raktáros feladatai

7. ábra, Operátor feladatai


32

4.3. Architekturális tervezés

Ebben a szakaszban el kellett dönteni, hogy konkrétan melyik fejlesztési eszközöket fogom

használni a feladat elkészítésére. Fő célom az volt, hogy olyan rendszert válasszak,

amelynek alrendszerei/moduljai kompatibilisek egymással, zökkenőmentesen és

rugalmasan együtt tudnak működni, kiforrott technológiák, és van „közös múltjuk”.

Mivel az egyetemi tanulmányaim alatt az Adatbázis rendszerek tárgyak keretében

megismerkedtem az adatbázisok és az adatkezelés világával, ezért onnan merítettem ihletet

a választott adatbáziskezelő-rendszerrel kapcsolatban. A tárgy tematikájának nagy részét

az SQL lekérdezőnyelv ismertetése tette ki, aminek szimpatikus és könnyen megtanulható

volt számomra a szintaktikája, ezért egyértelmű volt, hogy egy SQL alapú adatbáziskezelő-

rendszert válasszak.

Egy olyan weboldal építéséhez, ami egy adatbázis adatait jeleníti meg, szükségünk van:

- Egy RDBMS-re (Relational Database Management System,

relációs adatbázis-kezelő rendszer), mint a MySQL

- Egy szerveroldali szkriptnyelvre, mint a PHP

- Az SQL használatára, hogy megkapjuk a számunkra szükséges

adatokat

- HTML / CSS használatára az oldal külcsínéhez.

Mivel a webes adatbázisrendszerek egyik leggyakrabban használt architektúrája a PHP-

MySQL kettőse, ezért én is mellettük tettem le a voksomat. A PHP-vel tanulmányaim alatt

nem találkoztam, viszont döntésemet könnyítette, hogy a két technológia között szoros

együttműködés alakult ki, telepítő csomagokat hoztak létre a működtetésükhöz szükséges

eszközökből, és népszerűségüknek köszönhetően az interneten rengeteg tananyagot,

gyakorlóvideót, minta- és példaprogramot lehet találni.

A felhasználói felület elkészítése a HTML és CSS együttesével oldható meg

legkönnyebben. A CSS használatát megkönnyíti a Bootstrap nevű keretrendszer, ami a

reszponzív weboldalak kialakításához nyújt előre megírt könyvtárakkal segítséget. A

kliensoldali ellenőrzéseket és az AJAX technológia támogatását pedig a JavaScript, azon

belül is a jQuery nevű JavaScript függvénykönyvtár segíti, így ezek lesznek a további

felhasznált technológiák.


33

8. Ábra; A rendszer architektúrája

Az 8. ábrán az általam készített rendszer moduljai láthatóak, a webes architektúra

háromrétegű modelljének formális rétegei szerinti felosztásban. „A modul rendszerint

egyszerű rendszerkomponens, amely más modulok számára szolgáltatás(oka)t biztosít.”

[50]

A legalsó adat réteget a MySQL adatbázis szerver, a középső réteget (alkalmazás szerver)

a PHP program és az Apache webszerver, a legfelső réteget (prezentációs réteg) a

JavaScript, a HTML és a CSS kód, és a felhasználó által használt böngésző reprezentálja.

A MySQL tárolja az adatokat, a PHP kapcsolódik hozzá és eléri azokat

függvényhívásokon keresztül. A böngésző (kliens) küldi az URL-t, az Apache webszerver

pedig fogadja azt, megkeresi a hozzá tartozó PHP fájlt, lefordítja a PHP kódot és küldi a

kliensnek. A JavaScript AJAX technikával adatot cserél a PHP-vel, és a HTML-lel és a

CSS-sel karöltve formázza a megkapott lefordított kódot, és a böngésző értelmezi és

megjeleníti a dinamikusan előállított HTML-weblapot.

4.3.1. WAMP

A WAMP a Windows, Apache, MySQL, PHP rövidítése. Ez a rövidítés egy teljesen

működőképes, dinamikus weboldalak fejlesztésére használt összeállítást ír le.

Az Apache-ot az előző bekezdésben már említettem, ez a komponens tulajdonképpen egy

szabad, nyílt forráskódú webszerver alkalmazás, ami lehetővé teszi, hogy a PHP program a

saját gépünkön is futtatható legyen.


34

A WAMP egy olyan csomag, amely összeköti a tartalmazott programokat, tehát nekünk

nem kell telepíteni és beállítani őket külön-külön. Ez azt jelenti, hogy egyszerűen csak

letöltjük és telepítjük a programot, követjük az instrukciókat, hogy a webfejlesztő

szerverünk fel legyen állítva és el legyen indítva rövid időn belül, minimális fáradozással.

Több alternatíva közül is választhatunk egyébként, például a WampServer, XAMPP,

EasyPHP, Glossword WAMP. Az interneten utánakeresve a WampServert ajánlották a

legtöbb helyen ezekre a feladatokra, így erre a programcsomagra esett a választásom.

Ingyenesen letölthető a fejlesztője weboldaláról, és telepítés után el is indíthatjuk a helyi

WAMP szervert, ami a magyar nyelvet is támogatja.

Mivel úgy kellett megoldanom a rendszert, hogy minden cégnél található gépről elérhető

legyen, ezért a szervergépre telepítettem fel a WampServert. Hogy minden esetben

lehetőség legyen a kliens gépekről elérni a WampServer által biztosított szolgáltatásokat,

meg kellett bizonyosodnom arról, hogy automatikusan elindul-e a program és a

szolgáltatások a Windows indításával. Ezek után az első dolgom volt ellenőrizni, hogy

minden helyesen működik-e. Ehhez meg kell próbálni megjeleníteni az alapértelmezett

weboldalt, ami a szerver dokumentum gyökér könyvtárában lett eltárolva a telepítés után.

Ezt kétféleképpen lehet elérni, a böngésző címsorába beütött localhost, vagy a 127.0.0.1

címmel. A localhost szó használata a helyi számítógép meghatározására használandó, ami

a 127.0.0.1 IP címre is hasonlóan reagál, tehát mindkét módszert használhatjuk a

webszerverünk gyökérkönyvtárának az előhívásához. A gyökérkönyvtár az a könyvtár, ami

tartalmazza egy domain fő webdokumentumait. Alapértelmezésben a következő könyvtárat

használja a WampServer:

C:/wamp/www

Ha mindent jól csináltunk, akkor a böngésző címsorába beütött localhost hatására

megjelenik a WampServer kezdőoldala (9. ábra).


35

9. Ábra, WAMP vezérlő panel

4.3.2. Eclipse PDT

Mivel megkönnyíti az implementációt és akár le is rövidítheti a fejlesztési időt, ezért úgy

gondoltam, mindenképp érdemes egy PHP fejlesztést segítő IDE-t (Integrated

Development Environment), azaz integrált fejlesztői környezetet használnom. Számos IDE

elérhető a weben, személyes preferencia, hogy ki melyiket részesíti előnyben. Én az

Eclipse PDT-t választottam, ugyanis tanulmányaim során a Java programozás nagy részét

ugyancsak Eclipse IDE-ben végeztem. Az ismerős felépítés mellett további előny volt az

ingyenesség.

Az Eclipse PDT (PHP Development Tools) egy IDE (Integrated Development

Environment), azaz integrált fejlesztői könyezet keretrendszer az Eclipse platformhoz. Ez a

projekt magában foglalja a PHP-alapú webes alkalmazások fejlesztéséhez szükséges

fejlesztői összetevőket, és elősegíti a bővíthetőséget. Előnyei: szintaxis kiemelés, tartalom

segéd, kódformázás, refaktorálás, kód sablonok, szintaxis validáció, PHP debug. [51]

A program elindítása után be kell állítanunk a workspace-t, azaz a munkaterületet, ahol az

Eclipse dolgozik. Számomra az IDE egyik legnagyobb előnye, hogy a php fájl mentése

után azonnal tudjuk futtatni a programunkat az Eclipse-en belül. Ehhez viszont

elengedhetetlen volt, hogy workspace-nek a WampServer „www” nevű gyökérkönyvtárát


36

válasszam, így a project mappa és a php fájlok a mentéskor ebbe a könyvtárba kerülnek.

Továbbá futtatás előtt be kellett állítani egy PHP webalkalmazásokhoz tartozó

konfigurációt, ahol meg lehet adni az éppen használt php fájl pontos elérési útvonalát.

Ahogy a 10. ábrán látható, a programunk futtatásakor tulajdonképpen egy beépített

böngészőablak nyílik az Eclipse-en belül, ami további időt takarít meg nekünk, ugyanis

nem kell a fejlesztői környezet és az alapértelmezett böngésző ablakai között váltogatni

teszteléskor.

10. Ábra, Fejlesztő környezet


37

4.4. Az adatbázis megtervezése

4.4.1. Szükséges táblák meghatározása

Mindenképp szükség van egy Termék és egy Alkatrész táblára, viszont az már előzetesen

is látható, hogy sok redundáns adatunk lenne és anomáliák léphetnének fel, ha nem

normalizálnánk ezeket a táblákat. Mivel több termék és alkatrész is lehet ugyanazon a

lokáción és ugyanazon raktárban, ezért sok felesleges ismétlődő információt kellene újra és

újra eltárolni, ami idő- és erőforrás-pazarlás.

Szükségünk lesz egy hozzáadás, módosítás és törlés utáni változásokat vezető Log táblára

is, viszont ezt nem szükséges normalizálni, minden bejegyzése automatizált lesz, így

előfordulhat ismétlődés, használata kimerül bizonyos időközönkénti megtekintésében.

A mozgatások (dobozokban kivétel, felvétel) követésére is létre kell hozni egy táblát.

4.4.2. Normalizálás

Ha a táblák 1NF-ben, azaz első normálformában vannak, azt jelenti, hogy nincs két

egyforma rekord, a mezők száma és sorrendje minden rekordban megegyező, és egyik

mező sem többértékű.

A következő lépés a 2NF, azaz második normálformára hozás. A 2NF előfeltétele, hogy a

tábláink 1NF-ben legyenek, és úgy jutunk 2NF-be, ha megszüntetjük a táblákban a

részleges funkcionális függéseket, ha azok jelen vannak. Az adatbázisokban a 3NF, azaz

harmadik normálforma néhány kivételes esettől eltekintve mindig szükséges. Ezért erre az

alakra hozva a tábláink szétválasztódnak, több kisebb tábla keletkezik, amelyek között

különféle kapcsolatok vannak. Ezt ábrázolom és fejtem ki bővebben a következő

fejezetben.

A 3NF, azaz a harmadik normálforma akkor teljesül, ha minden tábla 2NF-ben van, és

nincs a táblákon belül tranzitív függés. [52] Tranzitív függés megszüntetése azt jelenti,

hogy megszüntetjük az elsődleges kulcstól nem függő mezőket, azaz új táblákat hozunk

létre az említett mezőkkel. [53]

A 3NF-ben lévő táblák és a közöttük lévő kapcsolatok ábrázolására az ER és a relációs

modellt fogom használni.


38

4.4.3. ER modell

Az ER modell absztrakt adatmodellt jelent, amely olyan adat- vagy információs struktúrát

határoz meg, amely egy adatbázisban, jellemzően relációs adatbázisban valósítható meg.

[51] A 11. ábrán az általam tervezett séma ER modellje látható.

Az ER, azaz Entity-Relationship modell három alapelemből áll: egyed (entity), kapcsolat

(relation), és az egyedek tulajdonságai (attributes).

Népszerűségét annak köszönheti, hogy egyszerű, átlátható, könnyen megérthető, mégis jól

szemlélteti az adatszerkezetet, és ezen felül könnyen átalakítható relációs adatmodellé.

11. ábra, Egyed-kapcsolat modell

„Az egyed a külvilág többi részétől egyértelműen megkülönböztethető dolog, objektum”.

[54] A modellben téglalappal jelöljük, az egyed nevét a közepére írva.

Az egyednek lehetnek tulajdonságai, ezek jellemzik az egyedet. Jelölése ellipszis, benne a

tulajdonság neve. A kulcs tulajdonság aláhúzva, ez az egyed egyértelmű azonosítója.


39

Az egyedek között kapcsolatokat is le tudjuk írni a modellel. Jelölésük rombusszal és

azokból induló nyilakkal történik, a nyíl típusa függ a kapcsolat jellegétől.

A kapcsolatok típusai a következők:

Az 1:1, azaz egy az egyhez kapcsolatban egy A egyed előforduláshoz csak egy B egyed

előfordulás tartozhat, és ugyanígy fordítva. Jelölése rombuszból, és abból mindkét egyed

felé kiinduló szimpla végű nyílból áll.

Az 1:N, azaz egy a többhöz kapcsolatban egy A egyed előforduláshoz több B egyed

előfordulás is tartozhat, viszont minden B egyed előforduláshoz csak egy A egyed

előfordulás tartozik. Jelölése a rombuszból, az A egyed felé mutató szimpla végű, a B

egyed felé pedig dupla végű nyíllal történik.

Az N:M, azaz több a többhöz kapcsolatban A és B egyed előforduláshoz is több tartozhat.

Jelölése a rombuszból kiinduló, mindkét irányba mutató dupla végű nyíl.

A kapcsolatoknak is lehet nevük és tulajdonságaik.

Az adatbázis felépítését, elemeit, kapcsolatait bővebben a relációs adatmodellre való

konvertálás után fejtem ki.

4.4.4. Relációs adatmodell

Ebben a modellben az adatokat kétdimenziós táblákba szervezzük, és a kapcsolat

kialakítása egy közös mező tárolásával történik. A modellt 1970-ben mutatta be E.F Codd,

és azóta ez a legszélesebb körben használt adatbázis-modell. A relációs modell adatainak

alapvető szerkezetei a táblázatok. Az adott típushoz tartozó összes információt az adott

táblázat soraiban tárolja. Ezért a táblákat relációknak is nevezzük. [55] Egyszerűségének,

könnyen tanulhatóságának és rugalmasságának is köszönheti népszerűségét.

A relációs adatmodell alapelemei:

- domain (a mező típusa, a felvehető értékek)

- mező (egyértékű tulajdonság, ami jellemzi a rekord

előfordulásokat)

- rekord: (a mezők együttese)

- reláció (táblának is nevezhető, az azonos típusú rekord-

előfordulások együttese)


40

- adatbázis (a táblák/relációk összessége) [56]

Az ER modellről való konvertálás után a következőképpen alakulnak a tábláink:

12. ábra, Relációs adatmodell

A 12. ábrán az általam létrehozott relációs adatmodell látható. A táblák fejlécében a reláció

elnevezése található. Az alattuk lévő oszlopokban a mezők találhatók, a relációk

tulajdonságainak elnevezésével. Folytonos vonallal aláhúzott névvel a tábla elsődleges

kulcsai láthatók, a szaggatott vonallal aláhúzottak pedig a tábla idegen kulcsai. A táblák

közötti kapcsolat az egyik tábla idegen kulcsából kiinduló, és a másik tábla elsődleges

kulcsára mutató nyíllal jelölhető. Akkor jön létre tényleges kapcsolat, ha a két mező értéke

megegyezik. A mezőkön belül a típust is meg lehet adni (domain), az adatbázisomban a

kulcsok és a darabszámot jelző tulajdonságok INT, az elnevezések pedig VARCHAR

típusúak. Zárójelben a hosszúságukat lehet megadni.

A konvertálás utáni elemek részletes leírása, magyarázata:

A TERMÉK egyedből TERMEK reláció lesz, ez a tábla a termékeket jellemzi, ahol:

- termek_id: a TERMEK tábla azonosítója, elsődleges kulcs, INT

típusú

- termek_nev: a termék elnevezése, VARCHAR típusú

- termek_minimum: a termék minimum készlete, INT típusú

- termek_darab: a termék raktáron lévő darabszáma, INT típusú


41

- termek_leiras: a termék leírása, VARCHAR típusú

Az ALKATRÉSZ egyedből ALKATRESZ reláció lesz, ez a tábla az alkatrészeket

jellemzi, felépítése megegyezik a TERMEK relációéval.

A KOMPONENS N:M kapcsolatból KOMPONENS reláció lesz, ami a termékek és az

alkatrészek közötti több-több kapcsolatot szimbolizálja, azaz melyik termékhez milyen

alkatrészek tartoznak, és melyik alkatrész milyen termékek alkotórésze. Mezői:

- komponens_id: a KOMPONENS tábla azonosítója, elsődleges

kulcs, INT típusú

- termek_id: idegen kulcs, a kapcsolathoz tartozó terméket

azonosítja, INT típusú

- alkatresz_id: idegen kulcs, a kapcsolathoz tartozó alkatrészt


- mennyi_kell: mennyire van szükség az adott alkatrészből a

termék legyártásához, INT típusú

A TERMÉK DOBOZ egyedből TERMEK_DOBOZ reláció lesz, ez a tábla a termékeket

tartalmazó dobozokat jellemzi, ahol:

- t_doboz_id: a TERMEK_DOBOZ tábla azonosítója, elsődleges

kulcs, INT típusú

- t_toboz_nev: a terméket tartalmazó doboz elnevezése,

VARCHAR típusú

- termek_id: idegen kulcs, a dobozban lévő terméket azonosítja,

INT típusú

- lokacio_id: idegen kulcs, a terméket tartalmazó doboz lokációját


- t_doboz_darab: a dobozban hány darab van az adott termékből,

INT típusú

- datum: a doboz felvitelének dátuma, TIMESTAMP típusú

Az ALKATRÉSZ DOBOZ egyedből ALKATRESZ_DOBOZ reláció lesz, ez a tábla az

alkatrészeket tartalmazó dobozokat jellemzi, felépítése megegyezik a TERMEK_DOBOZ

relációéval.


42

A LOKÁCIÓ egyedből LOKACIO reláció lesz, ez a tábla a raktáron belüli lokációt

jellemzi, ahol:

- lokacio_id: a LOKACIO tábla azonosítója, elsődleges kulcs, INT

típusú

- lokacio_nev: a raktáron belüli lokáció elnevezése, VARCHAR

típusú

- raktar_id: idegen kulcs, a lokációt tartalmazó raktárt azonosítja,

INT típusú

A RAKTÁR egyedből RAKTAR reláció lesz, ez a tábla a raktárat jellemzi, ahol

- raktar_id: a RAKTAR tábla azonosítója, elsődleges kulcs, INT

típusú

- raktar_nev: a raktár neve, VARCHAR típusú.

A relációs modellt felhasználhatjuk a konkrét adatbázis implementációnál is, mint séma,

ugyanis a relációs adatbázisunkban hasonlóan fognak megjelenni a tábláink és rekordjaink.


43

5. Implementáció

5.1. Adatbázis séma implementációja

Az adatbázis implementációjánál segítségünkre van a WampServer egyik grafikus felületű

adatbázis-kezelő modulja, a phpMyAdmin. Ezt a localhostról, azaz a WampServer

kezdőoldaláról, egy webes kezelőfelületről érhetünk el.

Belépéskor az adatbázisunk biztonsága érdekében első feladatunk egy felhasználó és a

hozzá tartozó megfelelően „erős” jelszó létrehozása, valamint ezen felhasználó

adatbázishoz és táblákhoz való jogainak megadása. Meg kell néznünk, hogy az összes

meglévő felhasználóhoz van-e jelszó hozzárendelve, ha nincs, akkor meg kell adnunk

egyet, ugyanis például az alapértelmezett root felhasználó egy úgynevezett

szuperfelhasználó, aminek mindenre van privilégiuma, így nem szeretnénk, ha bárki

hozzáférhetne korlátlanul az adatbázisunkhoz.

Miután létrehoztunk egy admin felhasználót, hozzáadunk egy új adatbázist, raktar_db

néven, ebben fogunk dolgozni. A phpMyAdmin grafikus felületének köszönhetően ritkán

van csak szükségünk SQL parancsokat begépelni, szinte mindent hozzá tudunk adni és be

tudunk állítani az űrlapok kitöltésével, opciók kiválasztásával, és gombnyomásra

végrehajthatjuk a parancsokat. Ha mégis kézzel szeretnénk az SQL parancsokat megadni, a

phpMyAdmin automatikus tartalom kiegészítéssel segíti a munkánkat.

Ha nem konfigurálunk más tárolómotort, akkor a MySQL-ben a táblák létrehozásakor az

InnoDB lesz az alapértelmezett. Az InnoDB egy általános célú tárolómotor, amely

egyensúly teremt a magas megbízhatóság és nagy teljesítmény között.

Főbb előnyei:

- A DML műveletei követik az ACID modellt, ami az atomiság,

konzisztencia, izoláció és tartósság rövidítése

- A sor szintű zárolás lehetőséget ad a felhasználók

konkurenciájára és a teljesítmény növelésére

- Az InnoDB táblák az elsődleges kulcsok alapján rendezik az

adatokat a lemezen, hogy optimalizálják a lekérdezéseket

- Az adatok integritásának megőrzése érdekében támogatja a

FOREIGN KEY, azaz idegen kulcs megszorítást. [57]


44

5.1.1. Táblák létrehozása

A táblák létrehozásakor mindig azokat kell elsőnek hozzáadni, amelyekben nem szerepel

más tábla elsődleges kulcsa, azaz nincs idegen kulcs mezője. A raktar, a termek és az

alkatresz tábláknak nincs idegen kulcsa, így ezeket adjuk hozzá először az

adatbázishoz.

Minden tábla azonosítója, azaz elsődleges kulcsa AUTO_INCREMENT funkcióval lesz

ellátva, ami azt jelenti, hogy az azonosító értéke mindig automatikusan eggyel nő a rekord

hozzáadásakor az előző rekord azonosítójához képest. Az elnevezések mindegyike

UNIQUE megszorítással lesz beállítva, ugyanis nem lehet két egyforma nevű termék,

alkatrész, lokáció, doboz, raktár és kapcsolat. A phpMyAdmin egyik nagy előnye, hogy

miután megadjuk a tábla létrehozásához szükséges tulajdonságokat, egy SQL előnézete

gombbal meg tudjuk nézni, hogy fog kinézni a CREATE utasításunk. Példának okáért itt

van a termek táblát megadó SQL kód:

DROP TABLE IF EXISTS `termek`;

CREATE TABLE IF NOT EXISTS `termek` (

`termek_id` int(10) NOT NULL AUTO_INCREMENT,

`termek_nev` varchar(20) NOT NULL,

`termek_minimum` int(10) NOT NULL,

`termek_darab` int(10) NOT NULL,

`termek_leiras` varchar(255) NOT NULL,

PRIMARY KEY (`termek_id`),

UNIQUE KEY `termek_nev` (`termek_nev`) ) ENGINE=InnoDB

DEFAULT CHARSET=utf8;

5.1.2. Idegen kulcs és további megszorítások

Az idegen kulcs megszorítás hozzáadása úgy történik, hogy létrehozzuk a táblát a

szükséges mezőkkel, amik között ott van a táblával kapcsolatban álló szülő tábla

elsődleges kulcsa. Miután létrejött a táblánk, úgy a 13. ábrán látható módon, a Szerkezet

menüpontban a Kapcsolati nézetben ki tudjuk választani, melyik oszlop legyen az idegen

kulcsunk, és a szülő tábla melyik oszlopához rendeljük ezt a kulcsot. A lokacio tábla


45

példájában a raktar_id mező az idegen kulcsmező, és kiválasztjuk hozzá a raktar

tábla raktar_id mezőjét, ami annak a táblának az elsődleges kulcsa.

13. Ábra, Adatbázis-kezelő panel

Az ON DELETE és ON UPDATE CASCADE megszorítások segítségével azt tudjuk elérni,

hogy ha a szülő táblában egy rekord törlődik vagy módosul, akkor a kapcsolódó rekordok a

gyermek táblában is törlődnek vagy módosulnak.

Az SQL parancs így fog kinézni:

ALTER TABLE `lokacio` ADD FOREIGN KEY (`raktar_id`)

REFERENCES`raktar`(`raktar_id`) ON DELETE CASCADE ON

UPDATE CASCADE;

Létrehozzuk a raktar, termek, alkatresz, lokacio, komponens,

termek_doboz és alkatresz_doboz táblákat a relációs modellnek megfelelő

sémával és megszorításokkal. Szükség lesz még egy felhasznalok táblára is, ahol a

rendszert használó userek lesznek eltárolva, ez bővebben a 5.2.1.3. fejezetben taglalom.

5.1.3. Naplózó log táblák

A rekord interakciók, azaz a hozzáadás, módosítás törlés naplózására létrehozunk a

termek és az alkatresz táblához tartozó log táblát. Ezeknek a tábláknak a szerkezete

a következő oszlopokból fog állni: id, regi_nev, uj_nev, regi_minimum,

uj_minimum, regi_darab, uj_darab, datum, tipus. A táblák automatikus

„kitöltéséhez” triggereket használunk, ezeket a phpMyAdmin felületén egyszerűen hozzá

lehet adni az adatbázis kiválasztásával, az Eseményindítók menüpont alatt.

Példának bemutatom a termék módosításához való triggert:

BEGIN


46

INSERT INTO `raktar_db`.`termek_log_table` (ìd`,

`regi_nev`, ùj_nev`, `regi_minimum`, ùj_minimum`,

`regi_darab`, ùj_darab`, `datum`, `tipus`)

VALUES (OLD.`termek_id`, OLD.`termek_nev`,

NEW.`termek_nev`, OLD.`termek_minimum`,

NEW.`termek_minimum`, '', '', NOW(), 'MODOSITAS');

END

Ez a kód a termek_log_table nevű táblába beszúrja a megadott adatokat, a NEW.

előtag az adott oszlophoz tartozó új, módosított adatot jelenti, az OLD. pedig a régit. A

NOW()a változás bekövetkezésekor adott időpontot jelenti, TIMESTAMP típusú. Az

utolsó oszlopba pedig az esemény elnevezése kerül.

Az alkatresz táblához tartozó alkatresz_log_table ugyanígy van felépítve, és

a triggere is megegyezik, de értelemszerűen az alkatrészhez tartozó névadatokkal.

A termek_log és az alkatresz_log táblákat a mozgások, a dobozokkal kapcsolatos

ki és felvétel naplózására használjuk. Tárolva lesz az azonosító, a név, a darabszám, a

mozgás típusa, és az aktuális dátum és időpont.

A termek_mentes és alkatresz_mentes táblák lesznek a grafikon

megjelenítéséhez használt táblák, ennek havonta lesz egy MySQL-ben automatizált

beépített eseménye, amikor is a termek, illetve alkatresz tábla éppen akkori adatait

eltárolja. A termek_mentes példája:

CREATE DEFINER=àdmin` EVENT `termek_mentes` ON SCHEDULE

EVERY 1 MONTH STARTS '2018-11-30 00:00:00' ON COMPLETION

NOT PRESERVE ENABLE DO

INSERT INTO termek_mentes (id, termek_nev,

termek_darab)

SELECT termek.termek_id, termek.termek_nev,

termek.termek_darab

FROM termek;

Miután létrehoztuk az adatbázisunkat, következhet a különböző modulok programozása és

„összekapcsolása”.


47

5.2. A rendszer moduljainak összekapcsolása

Mint ahogy egy korábbi fejezetben kifejtettem, az általam alkalmazott programozási

nyelvek, eszközök, technikák a MySQL, PHP, JavaScript (jQuery), AJAX, CSS

(Bootstrap) és a HTML lesznek. Mivel nagyon rugalmasan együtt tudnak működni, ezért

viszonylag egyszerű dolgom volt velük, ugyanis a különböző PHP fájlokban el tudtam

helyezni minden technológiát. Persze ez az egyszerűség nem jelentette azt, hogy azonnal

működésre tudtam bírni együtt őket. Voltak problémáim a PHP-MySQL kapcsolódással, a

rendszerbe való bejelentkezéssel, a munkamenet-kezeléssel (session), a lekérdezések

helyes működésével, de talán, ami a fejlesztésből a legtöbb időt tette ki, a PHP és a

JavaScript AJAX ”kommunikációja” egymással. A rengeteg módosítás, próbálgatás

viszont meghozta a gyümölcsét, és egy működőképes rendszert sikerült összehoznom.

Nem tervezek részletesen végigmenni a programozás összes lépésén, csak az

alapfunkciókat, fontosabb részeket mutatom be röviden.

5.2.1. PHP implementáció

5.2.1.1. functions.php

Létrehoztam egy functions.php fájlt, amellyel az volt a célom, hogy tartalmazza a

főbb függvényeket, amelyeket más PHP fájlokból is el akarok érni később.

<?php

$dbhost = 'localhost';

$dbname = 'raktar_db';

$dbuser = 'admin';

$dbpass = 'admin_password88';

$connection = new mysqli($dbhost, $dbuser, $dbpass,

$dbname);

if ($connection->connect_error) die($connection-

>connect_error);


48

function queryMysql($query)

{

global $connection;

$result = $connection->query($query);

if (!$result) die("Hibás adat lett megadva!");

return $result;

}

function destroySession()

{

$_SESSION=array();

if (session_id() != "" ||

isset($_COOKIE[session_name()]))

setcookie(session_name(), '', time()-2592000, '/');

session_destroy();

}

function sanitizeString($var)

{

global $connection;

$var = strip_tags($var);

$var = htmlentities($var);

$var = stripslashes($var);

return $connection->real_escape_string($var);

}

?>

Első és legfontosabb feladatunk csatlakozni a MySQL-hez PHP-vel, ugyanis csak így

tudjuk fejlesztés közben ellenőrizni, hogy a kódunk és a lekérdezések megfelelően

működnek.

A csatlakozáshoz meg kell adni a hosztnevet, ami a localhost lesz, mivel azon a

szervergépen tároljuk az adatbázisunkat, amin a rendszer működtetjük, az adatbázis nevét,

ami raktar_db lesz, és az adatbázishoz használt felhasználónevet és jelszót. Ezeket

különböző változókba tároljuk el.


49

Ez a kód létrehoz egy új $connection nevű objektumot, ami meghívja egy új példányát

a mysqli metódusnak, és átadja a változókban tárolt értékeket. A hibaellenőrzés a

$connection->connect_error jellemzőre (property) való hivatkozással történik.

A „nyíl” -> operátor mutatja, hogy a jobb oldalán álló elem a bal oldalon található

objektum jellemzője vagy metódusa. Ebben az esetben, ha a connect_error-nak van

értéke, akkor hiba történt, tehát meghívjuk a die függvényt, és megjelenítjük vele ezt a

property-t, ami tartalmazza a csatlakozással kapcsolatos hibát. A kapcsolat zárása a

$conn->close(); kóddal történik.

A queryMysql függvény a lekérdezések végrehajtásáért felelős, paraméterként megkap

egy $query változót, amiben a lekérdezés stringje van, aztán átadja a $connection

objektum query metódusának, ami visszaadja az eredményt, amit elhelyezünk a

$result objektumban.

A destroySession függvény a session befejezéséhez való, általában egy felhasználó

általi kijelentkezésénél használjuk, funkciót biztosít a session megsemmisítésére, és a

session összes adatát törli.

A sanitizeString függvényt a $_POST tömbbel küldött esetleges hackertámadások

ellen használjuk, mivel megpróbálkozhatnak JavaScript kódokat vagy MySQL parancsokat

injektálni a kitöltendő formokban, amivel manipulálhatják a program és az adatbázis

működését. Így bármikor, amikor a $_POST segítségével akarunk adatot küldeni, ezzel a

függvénnyel „hatástalanítjuk” az összes olyan karaktert, amivel bármilyen manipuláló

kódot injektálhatnának a programunkba.

5.2.1.2. header.php, index.php

A header.php fájlt az uniformitás miatt készítettem, a rendszer minden oldalának

ugyanazokat a funkciókat kell elérniük. Tartalmazza a functions.php-t, és minden

egyéb fájl pedig ezt a header.php-t tartalmazza.

A munkamenet-kezelés (session) használata egy módja annak, hogy változókban tároljunk

információkat a felhasználó beállításairól, hogy több lapon is használhassuk azokat. A

sütikkel ellentétben, az információ nem a felhasználó gépén tárolódik. A webszerver nem


50

tudja, hogy kik vagyunk, és mit csinálunk, ezért a session-kezeléssel meg tudjuk oldani ezt

a problémát. [58]

if (isset($_SESSION['user']))

{

$user = $_SESSION['user'];

$loggedin = TRUE;

}

else $loggedin = FALSE;

if ($loggedin)

{

if($user=='raktaros'){ /*ide kerül a oldalt

felépítő HTML-kód*/ }

elseif($user=='operator'){/*HTML-kód*/

}

Ez a kódrészlet a header.php-ből származik. A session_start függvény elindítja a

sessionünket. Ahogy a session elkezdődik, a program ellenőrzi, hogy a user session

változóhoz van-e érték hozzárendelve. Ha van, a felhasználó bejelentkezett és a

$loggedin értéke TRUE lesz, ha nincs értéke, akkor FALSE. Ha TRUE, akkor vizsgálja,

hogy raktaros vagy operator név lett beírva a bejelentkező formban, amit a

login.php-ben adtam meg, így dönti el, hogy mely menüpontokat, lehetőségeket jeleníti

meg a böngészőben.

A felépítés és a menüsáv kódolása a header.php-ben HTML kóddal és a Bootstrap

segítségével történik.

Az index.php egy triviális fájl, de szükséges a projektünkhöz, hogy adjunk neki egy

kezdőoldalt. Tartalma mindössze a header.php fájl inkludálása:

<?php

require_once 'header.php';

?>


51

5.2.1.3. felhasznalok.php

A cégnél kétféle típusú felhasználó van: egy raktaros és egy operator nevű, ez

annyit tesz, hogy a raktáros munkakörben dolgozó elérheti az összes menüpontot a

rendszerben, adatokat vihet fel, módosíthat, törölhet, a készletmozgásokat kezelheti. Míg

az operátor munkakörben dolgozó (aki csak az összeszereléseket végzi) csak korlátozott

tartalmat érhet el, ez pedig a termékek, alkatrészek, terméket alkotó alkatrészek

(komponensek) a megtekintését jelenti.

Ebben a fájlban hozzuk létre a felhasznalok táblát a felhasználónév és jelszó

tárolásához. Az alábbi kód a felhasznalok.php fájl egy részlete:

$salt1 = "hackerek";

$salt2 = "ellen";

$felhasznalonev = 'raktaros';

$jelszo = 'raktarosjelszava';

$token = hash('ripemd128', "$salt1$jelszo$salt2");

user_hozzaad($connection, $felhasznalonev, $token);

$felhasznalonev = 'operator';

$jelszo = 'operatorjelszava';

$token = hash('ripemd128', "$salt1$jelszo$salt2");

user_hozzaad($connection, $felhasznalonev, $token);

Mivel nem akarjuk az adatbázisunkban sima szövegként tárolni a jelszavakat az esetleges

hackertámadások miatt, ezért egy függvényt használunk, ami átkonvertálja a stringben lévő

szöveget egy látszólag véletlenszerű stringre. Erre a PHP hash funkcióját használjuk. A

ripemd algoritmus visszaad egy 32-karakteres hexadecimális számot, amit a $token

változónak ad át. Sajnos a hash önmagában nem elég a jelszavaink védelmére, ezért az

úgynevezett „sózás” (salting) módszerével, ami azt takarja, hogy valamilyen plusz

szöveget adunk a jelszavunkhoz. A példámban a jelszavak elé és mögé is egy stringet

illesztettem.


52

5.2.1.4. login.php, logout.php

A bejelentkezéshez létrehoztam egy login.php fájlt, azon belül pedig egy HTML

formot. Ebben a formban a required attribútummal kikényszerítem, hogy mindenképp

szükséges kitölteni az adott beviteli mezőt, ami a felhasználónevet és a jelszót kérné.

oninvalid="this.setCustomValidity('Kérem írja be a

felhasználónevét!')"

oninput="this.setCustomValidity('')"

Ezzel a fenti kódrészlettel, amit a felhasználónév és a jelszó input tag-jében is

alkalmaztam, figyelmeztetést ír ki, ha üresen próbálnánk elküldeni a formot.

A következő kódrészlet a header.php-nek küldi el a $_SESSION változóban a HTML

formba beütött felhasználónevet és jelszót, persze előtte vizsgálva, hogy létezik-e ilyen

felhasználónév a felhasznalok táblában.

if ($token == $row[1])

{

$_SESSION['user'] = $user;

$_SESSION['pass'] = $pass;

header('Location: header.php');

}

Így ennek köszönhetően tudja eldönteni a header.php, hogy mit jelenítsen meg, attól

függően, hogy a raktaros vagy az operator nevű felhasználó lépett be.

A logout.php a kijelentkezéshez szükséges. Vizsgáljuk benne, hogy a session

változónk létezik-e, ha igen, akkor a functions.php-ből meghívott

destroySession függvénnyel törlünk minden adatot a munkamenetünkből.

if (isset($_SESSION['user']))

{

destroySession();

header('Location: header.php');

}


53

5.2.2. Bootstrap és jQuery integrálása a PHP fájlokba

A Bootstrap a világ legnépszerűbb CSS-keretrendszere, egy nyílt forráskódú projekt,

könyvtár, amiben előre elkészített komponensek és jQuery-ben írt pluginek találhatók.

Segítségével igényes táblázatokat, felugró űrlapokat,

„A jQuery nem más, mint egy gyors és tömör JavaScript nyelvű függvénykönyvtár, ami

előre megírt függvényeket tartalmaz. A hagyományos programozási nyelvektől eltérően

“csak” értelmez, nem pedig végrehajt. A jQuery megpróbálja leegyszerűsíteni a

bonyolultabb dolgokat a JavaScript-ből, (például az AJAX-hívások, DOM-manipulációk),

így sokkal könnyebben, és gyorsabban használhatjuk azt a weboldalon.” [59]

Használatukhoz a PHP fájlnak tartalmaznia kell a Bootstraphez és jQuery-hez tartozó

könyvárakat. Ezt úgy tudjuk megoldani, hogy letöltjük a hivatalos honlapjukról a

megfelelő .js és .css kiterjesztésű fájkolat, bemásoljuk abba a mappába, ahol a

forrásfájljainkkal dolgozunk, és linkeljük a forráskódunkba, amelyekben használni

szeretnénk:

<script src="jquery-3.3.1.min.js"></script>

<script src="bootstrap.min.js"></script>

<script src="jquery.dataTables.min.js"></script>

<script src="datatables.min.js"></script>

<link rel="stylesheet" href="bootstrap.min.css">

<link rel="stylesheet"

href="dataTables.bootstrap.min.css">

<link rel="stylesheet" href="jquery.dataTables.min.css">

Fontos odafigyelni a scriptek sorrendjére, ugyanis ha nem a jQuery könyvtárának a

forrásfájlját tesszük előre, akkor nem fog működni a Bootstrap.

Először a header.php fájlban valósítottam meg a rendszer felépítését, kinézetét. A

tervem az volt, hogy legyen felül egy sáv, ahol a rendszer címe szerepel, alatta egy

menüsáv legyen, ami az oldal lefelé irányuló tekerésével „felragad” a böngésző ablakának

a tetejére, hogy mindig elérhető legyen. A Bootstrapet úgy tudjuk integrálni a fájlunkba,

hogy a különféle előre megírt, meghatározott osztályait megadjuk az adott HTML tag class

attribútumának. Ezeknek a leírását, ismertetését a Bootstrap hivatalos oldalán, a

https://getbootstrap.com/ dokumentációjában lehet elérni.

https://getbootstrap.com/


54

A külsőség és a felépítés egyéni preferencia kérdése, de a célom ettől függetlenül egy

könnyen átlátható, egyértelműen és ésszerűen felépített, és a szemnek kellemes

színösszeállítású weboldal volt.

Miután ezzel elkészültem, következhetett a konkrét menüpontok funkcióinak

megvalósítása.

A menüpontok funkcióit tartalmazó fájlok felépítése és a megoldás technikája nagyon

hasonló, ezért most absztrakt módon mutatom be a megvalósításukat.

Először is szükség volt egy táblázatra, a hozzá tartozó funkcionális gombokra, és a

gombok hatására felugró ablakra, amiben a hozzáadást és a szerkesztést és elfogadást

tudjuk végezni. Ebben segítségemre volt a Bootstrap, és a jQuery könyvtárának

függvényei. Úgy oldottam meg, hogy az egyik PHP fájlban, például a termek.php-ben

az adatbázis lekérdezések, a másik, termek_tabla.php-ben pedig a táblázat felépítése

és a jQuery szkriptek kerültek. Ezen azonos menüpontért, funkcióért felelős fájlok között

pedig AJAX technikával információt és adatot cserélnek, hogy gördülékeny és azonnali

legyen az oldalak használata.

Nézzük meg például az említett fájlokat. A Bootstrap által használt elemeket főleg <div>

tagekkel és a class attribútumokban megadott osztályok nevével tudjuk integrálni. A

Bootstrap böngészőablak méretváltozására reszponzív rács-szerkezetét a ”container”

class-szal vesszük használatba, ezen belül valósítjuk meg a különféle elemeket, például a

”modal fade” class (a böngészőfelület elsötétedésével felugró ablak), ”table

table-hover” (táblázat egérkurzor rávitellel „elsötétedő” sorok). Ezeknek az

elemeknek ha adunk az id attribútumának egy elnevezést, akkor a jQuery kódokban

tudunk rá hivatkozni, és különféle akciókat tudunk hozzájuk csatolni.

$(document).ready(function() {

$("#addNew").on('click', function () {

$("#tableManager").modal('show');

});

}

„A Dokumentum Objektum Modell (DOM) egymással gyerek-szülő kapcsolatban álló

objektumok rendszere. A dokumentum tartalmát, illetve a dokumentum valamennyi

összetevőjét magában foglalja.” [60] Például ez a függvény hivatkozik a dokumentumra, és


55

ha betöltött a teljes dokumentum, akkor az #addNew id-jű elemre való kattintáskor egy

újabb függvényt indít, ami pedig hivatkozik a #tableManager id-jű elemre, ami a show

paranccsal előhozza az előugró modal ablakot.

A termek.php fájlból egy rövid példát mutatok be, a hozzáadás query-t:

$nev = sanitizeString($_POST['nev']);

$nev = sanitizeString($_POST['nev']);

$minimum = sanitizeString($_POST['minimum']);

$leiras = sanitizeString($_POST['leiras']);

if ($_POST['key'] == 'addNew'){

$query = "SELECT termek_id FROM termek WHERE

termek_nev = '$nev'";

$result = queryMysql($query);

$rows = $result->num_rows;

if ($rows > 0)

exit("Már van ilyen nevű termék!");

else{

$query = "INSERT INTO termek VALUES(NULL,

'$nev', '$minimum', 0, '$leiras')";

$result = queryMysql($query);

exit("Termék hozzáadva!");

}

}

Itt a termek_tabla.php jQuery szkriptjétől megkapja a felugró ablak mezőibe beütött

név, minimum darab és leírás értékeit, aztán nézi, hogy ha az elküldött változó értéke

addNew, akkor ellenőrzi egy SELECT lekérdezéssel a névegyezést, ha van, hibát küld

vissza, ha nincs, akkor végrehajtja az INSERT query-t a megkapott kitöltő adatokkal,

aztán a „Termék hozzáadva!” szöveggel jelzi a query sikerességét.


56

6. A rendszer működésének leírása, tesztelése

Mivel az általam írt index.php fájlt a Wamp gyökérkönyvtárában helyeztem el, ezért ha

a szervergépen akarjuk használni a rendszert, akkor a böngészőbe beírjuk, hogy

localhost/, ha pedig a kliens gépeken kívánjuk használni, akkor a szerver címét adjuk

meg (SERVER/). Entert ütve a rendszer kezdőlapján találjuk magunkat.

Felül a menüsávban a BEJELENTKEZÉS menüpontra kattintva bejön egy bejelentkező

űrlap (14. ábra), amit helyesen kitöltve bejutunk a rendszerbe, ha viszont helytelenül adjuk

meg az adatainkat, akkor nem enged belépni és hibaüzenettel jelzi, hogy helytelen

felhasználónevet vagy jelszót adtunk meg.

14. ábra, Bejelentkező ablak

Sikeres bejelentkezés után a főoldalon látható menüpontok attól függően jelennek meg,

hogy raktáros vagy operátor felhasználónévvel léptünk be.

Raktáros:

Raktáros felhasználónak értelemszerűen több lehetősége van, a use case diagramban is jól

látható, hogy a Raktáros aktorhoz mennyi használati eset tartozik. Nézzük is meg

részletesebben ezeket.


57

A Menü feliratú gombra kattintva egy legördülő menüben az adatbázisban eltárolásra

szükséges különböző elemeket vihetjük fel, illetve módosíthatjuk és törölhetjük. Ebben a

legördülő menüben a lehetséges opciók: Termékek, Alkatrészek, Termék dobozok,

Alkatrész dobozok, Lokációk, Raktárak, Terméket alkotó alkatrészek megadása és Hiány

(15. ábra).

15. ábra, Menü lista

A Termékek menüpontra kattintva bejön egy táblázat, ami abban az esetben, ha még nem

vittünk fel bejegyzést, üresen jelenik meg. Jobb felső sarkában az ÚJ TERMÉK

HOZZÁADÁSA gomb megnyomására egy felugró ablak jelenik meg, ahol értelemszerűen

kitölthetjük azt a szükséges adatokkal, amiket az űrlap mezőjében le is ír.

A helyesen kitöltött űrlapot a Hozzáadás gombra kattintva el tudjuk tárolni az adatbázisunk

termek táblájába. Ha kifelejtünk egy mezőt és úgy kattintunk a Hozzáadásra, a mezőt

piros körvonallal jelzi, hogy nem adtuk meg. Ha sikeres volt a hozzáadás, egy

figyelmeztetés ugrik fel, „Termék hozzáadva!” szöveggel. Az ablakon kívül bárhova

kattintva bezáródik a hozzáadó ablak. A táblázat frissül, és az új bejegyzésünk már

megtalálható benne.

Az Opciók oszlopban a Módosítás és a Törlés gombok találhatók.

A Módosítás gombra kattintva a Hozzáadáshoz hasonló ablak ugrik fel, viszont itt már

kitöltve jelenik meg az űrlap, azon termék adataival, amelynek a sorában a Módosítás


58

gombra kattintottunk. Ha módosítottuk a kívánt adatokat, akkor a Módosítás mentése

gombra kattintva elfogadhatjuk azt, egy felugró figyelmeztetés jelzi a sikeres módosítást.

Mint a Hozzáadás ablakban, itt is működik az üresen hagyott mező ellenőrzése.

A Törlés gombra kattintva egy felugró figyelmeztetés teszi fel a kérdést, hogy biztosan

törölni akarjuk-e a bejegyzést. A Mégse gombra kattintva visszavonhatjuk a

kezdeményezést, viszont ha az OK gombra kattintunk, akkor megtörténik a rekord törlése,

amit egy felugró figyelmeztetés „A rekord törölve!” szöveggel jelez.

A táblázatban lehetőségünk van az egy oldalon megjelenített bejegyzések számát

kiválasztani. Ha sok bejegyzés van, lehet lapozni az oldalak közt, valamint a táblázat jobb

felső sarkában a Szűrés melletti mezőben név és szám alapján is szűrhetjük a rekordokat,

ami már az első karakter beütése után azonnal szűri a táblázat elemeit. További lehetőség

még az oszlopok fejlécére kattintva rendezni az oszlop tartalmát ABC vagy szám szerint

növekvő, illetve csökkenő sorrendben.

A legördülő menüben tovább haladva az Alkatrészek menüpont felépítésében és elemeiben

teljesen megegyezik a Termék menüpontban leírtakkal, értelemszerűen az alkatrészekre

vonatkozóan.

A következő menüpont a Termék doboz. Felépítése hasonló, mint az előzőek, viszont itt

már hozzáadásnál a felugró ablakban nem csak szövegesen adhatunk meg adatokat, hanem

legördülő listából választhatjuk ki a Termék dobozhoz tartozó szükséges adatokat. A doboz

elnevezésének megadása után a doboz által tartalmazott terméket választhatjuk ki a

listából. feltéve, ha már vittünk fel az adatbázisba terméket. A következő választandó elem

a lokáció, ugyanis meg kell adnunk, hogy a doboz melyik lokáción található, feltéve, ha

korábban már tároltunk el lokációt. A Termék darabszám azt a számot jelentené, ahány

darab termék van ebben a dobozban. Ha egy ugyanolyan típusú termék el van tárolva egy

vagy több dobozban, akkor a doboz(ok)ban megadott darabszám összege kerül a termek

tábla Termék darabszám (az adatbázisban termek_darab) oszlop soraiba.

Az Alkatrész doboz menüpont felépítése teljesen megegyezik a Termék dobozéval, csak az

alkatrészekre vonatkoztatva.

A Lokációk menüpont is hasonló az előzőekhez, viszont itt az új lokáció hozzáadásánál a

legördülő listából a raktárakat kell kiválasztani, feltéve, ha adtunk már meg korábban.


59

A Raktár menüpontban csak a Raktár nevét tudjuk megadni, felépítése megegyezik az

előzőekével.

A KIJELENTKEZÉS gombra kattintva azonnal kijelentkeztet a rendszerből, és visszaugrik

az eredeti üres kezdőlapra, ahol csak a BEJELENTKEZÉS gomb található a menüsorban.

A többi menüpontot a következő fejezetben, teszteléskor ismertetem, ugyanis a funkcióit

feltöltött adatok mellett tudjuk vizsgálni.

Operátor:

Az operátor felhasználónak, mint azt korábban leírtam, és a use case diagramban az

Operátor nevű aktorhoz tartozó használati eseteken is látható, korlátozott felhasználása

van.

A BEJELENTKEZÉS gombot értelemszerűen ugyanúgy eléri, viszont csak 3 menüpont

jelenik meg neki a legördülő menüben: Termékek, Alkatrészek és Komponensek. Ha ezek

közül bármelyikbe belépünk, nincs módosító és törlő gomb, csakis kizárólag megtekintésre

használhatják ezen táblák rekordjait (17. ábra).

17. ábra, Terméklista


60

6.1. Tesztelés példaadatok feltöltésével

A tesztelés során fiktív, kitalált adatokkal fogok dolgozni. A teszteléshez a Google Chrome

legfrissebb változatát használtam, Windows 7 64 bites rendszer alatt.

Először azokat a táblákat kell feltöltenünk, amelyekben nincs más táblára mutatió idegen

kulcs, azaz érdemes a Raktár menüponttal kezdenünk. Miután megadtuk a két raktárt, jöhet

a lokációk feltöltése. A lokációk után a termékeket és az alkatrészeket adtam hozzá, a 18.

ábrán a Termék menüben láthatóak a táblázatban a feltöltött rekordok. Ezután már

lehetőségem volt párosítani a termékekhez az alkotórészeiket.

18. ábra, Mintaadatbázis

A legördülő menüben lévő elem a Terméket alkotó alkatrészek megadása. Itt is hasonló

táblázat jelenik meg az előzőekhez, azzal a különbséggel, hogy itt tudjuk megadni azt,

hogy mely terméket mely alkatrészek alkotják. ALKATRÉSZ HOZZÁADÁSA

TERMÉKHEZ feliratú gomb megnyomása után legördülő listából tudjuk kiválasztani a


61

szükséges terméket és a komponensét (alkatrészt), a Mennyire van szükség mezőbe pedig

beírhatjuk, hogy hány darab kell a termék legyártásához az adott alkatrészből. Ezt a

folyamatot ábrázolja a 19. ábra.

19. ábra, Alkatrész hozzáadás menü

Miután összepárosítottam az összes alkatrészt az összes hozzá tartozó termékkel,

következett a dobozok feltöltése. A 20. ábrán látható, hogy külön tudjuk a termék, külön az

alkatrész dobozokat feltölteni, ki tudjuk választani listából, hogy melyik terméket vagy

alkatrészt akarjuk a dobozba tenni, melyik lokáción tároljuk ezt a dobozt, mennyi darabot

rakunk bele, és a feltöltés dátumát.


62

20. ábra, Doboz hozzáadás menü

Egy bizonyos doboz feltöltése után a dobozban lévő termék vagy alkatrész típusának a

raktárkészlete is nő, több dobozból összeadódik, és az érték megjelenik a Termék vagy

Alkatrész menü táblázatában.

A legördülő menüben a Hiány menüpont alatt azokat a termékeket vagy alkatrészeket

találjuk, amelyekből hiány van, azaz a raktárkészlet nem éri el a minimumkészletet az

adott termékből vagy alkatrészből (21. ábra). Gombbal válthatunk a termékek és

alkatrészek között.


63

21. ábra, Hiányt mutató ablak

A KI/BE MOZGATÁS menüpont alatt a dobozokból való termék vagy alkatrész kivételt

vagy bevételt értjük, ezt a 22. ábrán láthatjuk. Itt is gombbal válthatunk a termékek és

alkatrészek között, a ki- és bevételt legördülő listából választjuk ki, a szóban forgó

terméket vagy alkatrészt és dobozát is, és megadjuk a kívánt darabszámot.

22. ábra, Alkatrész mozgatás ablak


64

Ehhez szorosan kapcsolódó funkció a MOZGÁSKÖVETŐ LOG menüpont alatt található

(23. ábra). Itt a ki- és felvitelt tárolja el automatikusan egy naplózó táblába, ahol a

darabszám, a mozgatás típusa és a dátum található.

23. ábra, Naplózó ablak

A KÉSZLETVÁLTOZÁS GRAFIKON menüpont alatt (24. ábra) egy kiválasztott termék

vagy alkatrész készletének a változását követhetjük egy Google Chart grafikonon, egy év

intervalluma alatti adatokkal, havi lebontásban. Ehhez egy automatizált eseményt

állítottam be a phpMyAdminban az adatbázishoz, ami a kezdési időponttól számítva

minden hónapban az 1 hónappal későbbi éppen aktuális raktárkészletet tárolja el egy

táblában. A szemléltetés kedvéért fiktív adatokkal előre kitöltöttem ”visszamenőleg”.


65

24. ábra, Készletváltozás grafikon

Lehetőségünk van az ADATBÁZIS MENTÉSE menüpont alatt az adatbázis biztonsági

mentésére is, itt egy form mezőjébe ha beírjuk az általunk kívánt fájlnevet, akkor elmenti

egy .sql kiterjesztésű fájlba abba a mappába, amelyben épp dolgozunk a WAMP-pal.

A tesztelés során arra törekedtem, hogy minden menüpontot, űrlapot, gombot kipróbáljak.

Kikényszerítettem a felhasználói input hibáit, szándékosan helytelen adatokat adtam meg.

A rendszer minden ilyen próbálkozást hibaüzenettel konstatált, vagy jelezte, hogy

szükséges az adott mező kitöltése a továbbhaladáshoz.


66

6.2. Jövőbeli fejlesztési lehetőségek

Az általam készített rendszer a piac megoldásaihoz képest kezdetleges, és sok fejlesztésre

lenne még szüksége ahhoz, hogy egy nagyobb cég használni kívánja.

Egyik ilyen fontos fejlesztési lehetőség egy Rendelés modul készítése lenne, ahol újabb

fogalmak kerülnének bevezetésre, mint a megrendelések kezelése, selejtkezelés, termékek

elérhetősége, megrendelőlapok készítése, szállítással kapcsolatos információk, pénzügyek

kezelése.

Másik fejlesztési ötlet a teljes reszponzív mobil verzió lenne, ugyanis napjainkban az

okostelefonok rohamszerű elterjedésével már minden területen az emberek hasznára válik

a gyorsaságuk és kompaktságuk miatt. Igaz, a Bootstrap rácsrendszere ebben a

reszponzivitásban segít, az ablakméret-változtatás hatására változtatja az oldalunk

kinézetét, de külön nem szenteltem időt és figyelmet arra, hogy mobilos böngészőn is

kipróbáljam, teszteljem.

Hasznos módosítás lenne még a vonalkódok bevezetése és vonalkódolvasó használata a

gyors bevitelhez.

Nem a legfontosabb kérdés, de esetleges képfeltöltési lehetőség is jó megoldás lehetne a

termékekhez és alkatrészekhez.

A külsőségekkel kapcsolatban lehetne még esetleg különféle beépített választható

témákkal, elrendezésekkel változtatni a rendszer kinézetét, menü- és gombrendszerét.


67

Összegzés

Feladatom egy webes alapú raktárkezelő nyilvántartó rendszer tervezése, fejlesztése és

bemutatása volt. Fő célom az volt, hogy olyan rendszert hozzak létre, amely megfelel az

adatbiztonsági követelményeknek, alrendszerei, moduljai kompatibilisek egymással és

zökkenőmentesen és rugalmasan együtt tudnak működni, használata pedig egyszerű,

átlátható és könnyen megérthető egy laikus felhasználó számára is.

Az irodalomkutatás során új ismeretekre tettem szert a raktárkezelés, és a különféle webes

architektúrák és fejlesztési módszerek világával kapcsolatban, ezáltal bővítve a

szemléletem az informatika ezen területén.

A program fejlesztése során rengeteget tanultam, fejlődtem, ugyanis előtte tanulmányaim

során a felhasznált programozási nyelvek, technológiák és fejlesztési eszközök nagy

részével nem találkoztam. Mivel ilyen volumenű programot még nem készítettem életem

során, ezért eleinte nehézkesen ment a fejlesztés, főleg, hogy a különböző elérhető

keretrendszerek segítsége nélkül írtam a PHP programomat. Sok időt vett igénybe az

alkalmazott programozási nyelvek használatának megtanulása, a modulok

összekapcsolása, összhangba hozása, és a webes alapú programozási felfogás elsajátítása.

Segítségemre voltak az interneten fellelhető leírások, minta- és példaprogramok, tutorialok

és a különféle szabadon felhasználható könyvtárak és pluginek.

A rendszerem kissé kezdetleges a piac hasonló raktárkezelő nyilvántartó rendszer

megoldásaihoz képest, sok hasznos funkciót lehetne még fejleszteni hozzá, és tudom, hogy

azok elkészítéséhez sokat kell még fejlődnöm, de úgy érzem, a tudásomhoz mérten sikerült

megoldanom a célkitűzésemet.


68

Summary

The topic of my thesis was to design, develop and present a web-based warehouse

inventory management system. The aim was to create a system that is in compliance with

data security requirements, its sub-systems, modules are compatible with each other, their

interaction is smooth and adaptable and its use is simple, clear and easy-to-understand even

for a non-professional user.

During my research, I acquired new knowledge concerning inventory control, the different

web architectures and development methods. Thereby I was able to broaden my

perspective on this particular field of IT.

I was learning, improving a lot while developing this program, as previously, during my

studies I haven’t learned about most of these programming languages, technologies and

development tools. Due to it being the first time developing a programme with such

volume, the development at the beginning was a bit difficult, especially, since I wrote the

PHP program without the help of any of the available frameworks. It took time to learn the

programming languages I applied, to connect the modules, to synchronize them and also to

adapt to the perception of web-based programming. It has been a great help to find

specifications, model programs, tutorials and various free libraries and plug-ins.

The system I designed is not as advanced as similar warehouse inventory management

systems on the market, it could include more useful features, and I am aware that in order

to do that I need to improve myself further, however, I feel that considering my current

knowledge, I managed to achieve my objective.


69

Irodalomjegyzék

[1] https://ingatlanhirek.hu/wp-content/uploads/2018/04/IPARI-

rakt%C3%A1rk%C3%A9p-3..jpg

[2] http://kepzesevolucioja.hu/dmdocuments/4ap/18_1429_011_101030.pdf

[3] https://www.tankonyvtar.hu/hu/tartalom/tamop412A/2011-

0085_logisztikai_alapismeretek/ch02.html

[4] http://ade.web.elte.hu/wabp/lecke1_lap1.html

[5] http://web.progtanulo.hu

[6] https://www.computerhope.com/jargon/d/dynasite.htm

[7] https://www.doteasy.com/web-hosting-articles/what-is-a-dynamic-web-page.cfm

[8] https://simple.wikipedia.org/wiki/Client-server

[9] https://www.softwaretestingclass.com/wp-content/uploads/2013/01/two-tier-

architecture.png

[10]

https://www.tankonyvtar.hu/hu/tartalom/tamop425/0038_informatika_Projektlabor/

ch01s04.html

[11] http://old.sztaki.hu/~micsik/corba/

[12] http://www.woodger.ca/archmult.htm

[13] https://www.encyclopedia.com/science-and-technology/computers-and-electrical-

engineering/computers-and-computing/html

[14] http://www.encyclopedia.com/science-and-technology/computers-and-electrical-

engineering/computers-and-computing/xml-extensible

[15] https://www.tutorialspoint.com/css/what_is_css.htm

[16] https://www.w3.org/community/webed/wiki/A_Short_History_of_JavaScript

[17] http://www.encyclopedia.com/science-and-technology/computers-and-electrical-

engineering/computers-and-computing/javascript

[18] http://www.mediacollege.com/internet/javascript/pros-cons.html

[19] https://www.seguetech.com/ajax-technology/

[20] http://www.jscripters.com/ajax-disadvantages-and-advantages

[21] http://www.freejavaguide.com/history.html

[22] https://www.mindsmapped.com/java-j2ee/java-advantages-and-disadvantages/

[23] https://msdn.microsoft.com/en-us/library/4w3ex9c2(v=vs.100).aspx

https://ingatlanhirek.hu/wp-content/uploads/2018/04/IPARI-rakt%C3%A1rk%C3%A9p-3..jpg

https://ingatlanhirek.hu/wp-content/uploads/2018/04/IPARI-rakt%C3%A1rk%C3%A9p-3..jpg

http://kepzesevolucioja.hu/dmdocuments/4ap/18_1429_011_101030.pdf

https://www.tankonyvtar.hu/hu/tartalom/tamop412A/2011-0085_logisztikai_alapismeretek/ch02.html

https://www.tankonyvtar.hu/hu/tartalom/tamop412A/2011-0085_logisztikai_alapismeretek/ch02.html

http://ade.web.elte.hu/wabp/lecke1_lap1.html

http://web.progtanulo.hu/

https://www.computerhope.com/jargon/d/dynasite.htm

https://www.doteasy.com/web-hosting-articles/what-is-a-dynamic-web-page.cfm

https://simple.wikipedia.org/wiki/Client-server

https://www.softwaretestingclass.com/wp-content/uploads/2013/01/two-tier-

https://www.softwaretestingclass.com/wp-content/uploads/2013/01/two-tier-



http://old.sztaki.hu/~micsik/corba/

http://www.woodger.ca/archmult.htm

https://www.encyclopedia.com/science-and-technology/computers-and-electrical-

https://www.encyclopedia.com/science-and-technology/computers-and-electrical-

http://www.encyclopedia.com/science-and-technology/computers-and-electrical-


https://www.tutorialspoint.com/css/what_is_css.htm

https://www.w3.org/community/webed/wiki/A_Short_History_of_JavaScript



http://www.mediacollege.com/internet/javascript/pros-cons.html

https://www.seguetech.com/ajax-technology/

http://www.jscripters.com/ajax-disadvantages-and-advantages

http://www.freejavaguide.com/history.html

https://www.mindsmapped.com/java-j2ee/java-advantages-and-disadvantages/

https://msdn.microsoft.com/en-us/library/4w3ex9c2(v=vs.100).aspx


70

[24] https://www.codeproject.com/Articles/4468/Beginners-Introduction-to-ASP-NET

[25] http://perltraining.com.au/notes/perlintro.pdf

[26]

http://ods.com.ua/win/eng/program/Perl5Unleashed/ch1.phtml#WhatAretheNegativ

esofUsingPerl

[27] https://www.programiz.com/python-programming

[28] https://python.swaroopch.com/about_python.html

[29] https://medium.com/@mindfiresolutions.usa/advantages-and-disadvantages-of-

python-programming-language-fd0b394f2121

[30] https://www.pythoncentral.io/introduction-to-pythons-django

[31] https://www.ruby-lang.org/en/about

[32] http://www.informit.com/articles/article.aspx?p=18225

[33] http://www.bestprogramminglanguagefor.me/why-learn-ruby

[34] http://railsapps.github.io/what-is-ruby-rails.html

[35] http://o7planning.org/en/10343/what-is-oracle-application-express#a1111956

[36] https://apex.oracle.com/en/platform/why-oracle-apex/

[37] http://php.net/manual/en/history.php.php

[38] http://php.net/manual/en/intro-whatis.php

[39] http://php.net/manual/en/intro-whatcando.php

[40] https://www.techopedia.com/definition/1245/structured-query-language-sql

[41] http://www.tech-recipes.com/rx/55356/dml-ddl-dcl-and-tcl-statements-in-sql-with-

examples/

[42] https://www.w3schools.in/mysql/ddl-dml-dcl/

[43] https://www.w3schools.in/mysql/intro

[44] https://users.iit.uni-miskolc.hu/~mileff/szf/Szoftverfejlesztes_beta4.pdf

[45] https://wiki.prog.hu/wiki/Specifik%C3%A1ci%C3%B3

[46] https://kimsun.en.made-in-china.com/productimage/BNZmoWhEbnkG-

2f1j00kdpTqrysklcO/China-E27-B22-A60-12W-Plastic-with-Aluminum-LED-

Bulb-Parts-with-Nom-Approved.html

[47] https://www.manufacturer.lighting/file/upload/201612/25/190932171.jpg

[48] https://en.wikipedia.org/wiki/Unified_Modeling_Language

[49] https://www.tankonyvtar.hu/hu/tartalom/tamop425/0027_RSZ5/ch01s03.html

https://www.codeproject.com/Articles/4468/Beginners-Introduction-to-ASP-NET

http://perltraining.com.au/notes/perlintro.pdf

http://ods.com.ua/win/eng/program/Perl5Unleashed/ch1.phtml%23WhatAretheNegativesofUsingPerl

http://ods.com.ua/win/eng/program/Perl5Unleashed/ch1.phtml%23WhatAretheNegativesofUsingPerl

https://www.programiz.com/python-programming

https://python.swaroopch.com/about_python.html

https://medium.com/@mindfiresolutions.usa/advantages-and-disadvantages-of-

https://medium.com/@mindfiresolutions.usa/advantages-and-disadvantages-of-

https://www.pythoncentral.io/introduction-to-pythons-django

https://www.ruby-lang.org/en/about

http://www.informit.com/articles/article.aspx?p=18225

http://www.bestprogramminglanguagefor.me/why-learn-ruby

http://railsapps.github.io/what-is-ruby-rails.html

http://o7planning.org/en/10343/what-is-oracle-application-express%23a1111956

https://apex.oracle.com/en/platform/why-oracle-apex/

http://php.net/manual/en/history.php.php

http://php.net/manual/en/intro-whatis.php

http://php.net/manual/en/intro-whatcando.php

https://www.techopedia.com/definition/1245/structured-query-language-sql

http://www.tech-recipes.com/rx/55356/dml-ddl-dcl-and-tcl-statements-in-sql-with-

http://www.tech-recipes.com/rx/55356/dml-ddl-dcl-and-tcl-statements-in-sql-with-

https://www.w3schools.in/mysql/ddl-dml-dcl/

https://www.w3schools.in/mysql/intro

https://users.iit.uni-miskolc.hu/~mileff/szf/Szoftverfejlesztes_beta4.pdf

https://wiki.prog.hu/wiki/Specifik%C3%A1ci%C3%B3

https://kimsun.en.made-in-china.com/productimage/BNZmoWhEbnkG-2f1j00kdpTqrysklcO/China-E27-B22-A60-12W-Plastic-with-Aluminum-LED-Bulb-Parts-with-Nom-Approved.html



https://www.manufacturer.lighting/file/upload/201612/25/190932171.jpg

https://en.wikipedia.org/wiki/Unified_Modeling_Language

https://www.tankonyvtar.hu/hu/tartalom/tamop425/0027_RSZ5/ch01s03.html


71

[50]

https://www.tankonyvtar.hu/en/tartalom/tamop425/0046_szoftverfejlesztes/ch06.ht

ml

[51] https://www.eclipse.org/pdt

[52]

https://www.tankonyvtar.hu/hu/tartalom/tamop425/0005_25_adatbazis_kezeles_sco

rm_03/362_normlformk.html

[53] https://support.microsoft.com/hu-hu/help/283878/description-of-the-database-

normalization-basics

[54] https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model

[55]

https://www.tankonyvtar.hu/en/tartalom/tamop425/0049_29_adatmodellezesi_es_a

datkezelesi_technikak/3334/index.html

[56] https://www.studytonight.com/dbms/database-model.php

[57] https://dev.mysql.com/doc/refman/8.0/en/innodb-introduction.html

[58] http://web.progtanulo.hu/web-programozas-alapismeretek/3-szerver-oldali-

mukodes/37-felhasznalokezeles/372-munkamenet-kezeles

[59] https://webdesigntanfolyam.com/bevezetes-a-jquery-be/

[60] https://hu.wikipedia.org/wiki/Document_Object_Model

A linkeket 2018. 11. 28-án ellenőriztem, a [20]-as hivatkozáson kívül mindegyik elérhető

volt.

https://www.tankonyvtar.hu/en/tartalom/tamop425/0046_szoftverfejlesztes/ch06.html

https://www.tankonyvtar.hu/en/tartalom/tamop425/0046_szoftverfejlesztes/ch06.html

https://www.eclipse.org/pdt

https://www.tankonyvtar.hu/hu/tartalom/tamop425/0005_25_adatbazis_kezeles_scorm_03/362_normlformk.html

https://www.tankonyvtar.hu/hu/tartalom/tamop425/0005_25_adatbazis_kezeles_scorm_03/362_normlformk.html

https://support.microsoft.com/hu-hu/help/283878/description-of-the-database-

https://support.microsoft.com/hu-hu/help/283878/description-of-the-database-

https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model

https://www.tankonyvtar.hu/en/tartalom/tamop425/0049_29_adatmodellezesi_es_adatkezelesi_technikak/3334/index.html

https://www.tankonyvtar.hu/en/tartalom/tamop425/0049_29_adatmodellezesi_es_adatkezelesi_technikak/3334/index.html

https://www.studytonight.com/dbms/database-model.php

https://dev.mysql.com/doc/refman/8.0/en/innodb-introduction.html

http://web.progtanulo.hu/web-programozas-alapismeretek/3-szerver-oldali-mukodes/37-felhasznalokezeles/372-munkamenet-kezeles

http://web.progtanulo.hu/web-programozas-alapismeretek/3-szerver-oldali-mukodes/37-felhasznalokezeles/372-munkamenet-kezeles

https://webdesigntanfolyam.com/bevezetes-a-jquery-be/

https://hu.wikipedia.org/wiki/Document_Object_Model


72

CD melléklet tartalma

Dolgozat nevű mappában:

SZAKDOLGOZAT_SZILÁGYI_GERGELY_QD9VQE.docx

SZAKDOLGOZAT_SZILÁGYI_GERGELY_QD9VQE.pdf

SZAKDOLGOZAT_FELADATKIÍRÁS.doc

SZAKDOLGOZAT_FELADATKIÍRÁS.pdf

ÖSSZEFOGLALÁS.docx

ÖSSZEFOGLALÁS.pdf

SUMMARY.docx

SUMMARY.pdf

Program nevű mappában:

A program .php fájljai, a mintaadatbázis exportált .sql fájlja, és a forrás .css, .js és

képfájlok.

Documents

PHP - MySQL alapú raktárkezelő nyilvántartó rendszer