Excel konzultáció 1. Gyakorlat Dr. Pauler Gábor, egyetemi docens, ev.

Az előadások a következő témára: "Excel konzultáció 1. Gyakorlat Dr. Pauler Gábor, egyetemi docens, ev."— Előadás másolata:

1 Excel konzultáció 1. Gyakorlat Dr. Pauler Gábor, egyetemi docens, ev.
Adószám: Számlaszám: Telephely: 7666 Pogány, Széchenyi u. 1. Tel: 30/

2 A gyakorlat tartalma A relációs adatbázis kezelés alapfogalmai Különbség a papír-alapú rendszerektől Adatbázis táblák, elsődleges- és idegen kulcsok Relációs táblák és egyedkapcsolati diagramm Normalizáció, adatbázis tervezés Lekérdezések működése Felhasználói felület, űrlapok Relációs adatbázisok tervezése A manuális tervezés problémái Az MS Access automatikus adatbázis tervező varázslója A varázsló értékelése Relációs adatbázisok és felhasználói felületük megvalósítása MS Accessben Tábladefiníciók és lekérdezések Űrlapok és alűrlapok Webes felület létrehozása Vezérlőpanelek és alkalmazás futtatási beállítások 1. Házi feladat: Automatikus adatbázis tervezés

3 A relációs adatbázis kezelés alapfogalmai 1
A Session1–ben láthattuk, hogy az Excel kapacitáskorlátai miatt nem alkalmas bonyolult struktúrájú, nagy tömegű tranzakció adatok kezelésére. Azonban, ha elé rakunk egy relációs adatbázis kezelő rendszert (Relational Database Management System, RDBMS), akkor ez megtöbbszörözi a rendelkezésre álló adatdkezelési kapacitást, és az Excel -ebből adatokat kinyerve - már igen jól használható és gyors felhasználói felületet képez. Illő tehát megismerkednünk az RDBMS-ek alapfogalmaival és tervezésével: Egy létező, papír-alapú adatkezelő rendszert nem könnyű hatékony adatbázis rendszerré alakítani: A papír logikailag rendkívül rugalmas struktúrájú adattároló: számot, szöveget, képet tárol, akár laponként változó szerkezetben, viszont visszakeresési sebessége borzalmasan lassú és élőmunka-igényes, mert fizikai anyagmozgatást igényel. Ezért a papír-alapú rendszerek adatstruktúráit, űrlapjait úgy tervezik, hogy minden fontos egyedből beleszorítanak egy pár fontos tulajdonságot, és csak pár rekordnak adnak helyet. (Erre látunk példát egy igen közkeletű űrlapon: az ÁFA-s számla a Számla, a Kibocsátó, a Vevő, egyedek tulajdonságait tudja tárolni, illetve a Megvásárolt tétel 12 előfordulását. Mivel az eladó neve és a fizetve jelzés lemaradt róla tervezéskor, egyszerűen ráfirkantják). Ennek a rugalmasságnak azonban nagyon nagy ára van a lassúság mellett is: A 13. megvásárolt tétel már nem fér rá, ezért vagy adatvesztés (Data loss) jön létre, Vagy új számlát kell nyitni, ami szinte megduplázza a munkát és a szükséges tárolóhelyet: minden más adatot feleslegesen még egyszer be kell írni, ez a redundancia (Redundancy) Vagy nem töltik ki a többi adatot, de ekkor nem egyértelmű a hivatkozás (Ambigous Reference), kié a számla

4 A relációs adatbázis kezelés alapfogalmai 2
Egy adatbázis tábla (Database Table) önmagában rendkívül rugalmatlan tároló: soraiban rekordok (Record) találhatók, amelyek egy egyed (pl. Ügyfél) adott előfordulásait (pl. „Kovács Jánosné”, „Nagy Józsefné”) tárolják, és a merevlemezen sorfolytonosan egymás után állnak. A rekordok csak azonos mező (Field) szerkezetűek lehetnek, a mezők az egyed-előfordulások tulajdonságait tárolják. Ezért a rekordok tárolási hossza fix, így előre kiszámítható, hol kezdődik a merevlemezen az n-edik rekord, anélkül, hogy végig kellene olvasni az előzőket, emiatt itt a visszakeresés gyors lesz, de ennek ára van: A valóságban előforduló adatszerkezetek NEM fix hosszúságúak (pl. egy anyának igen eltérő számú gyereke lehet – Kovács Józsefné: 0.6, Orsós Petronella Dzsenifer: 12). Ha fix számú gyerek adatait tudjuk csak tárolni, a legtöbbször tárolóhelyet pazarlunk (Redundancy), néhol pedig adatot vesztünk (Data Loss) Nem lehet két rekord közé beszúrni egy harmadikat, csak a végéhez írni, Ha kitörlünk egy közbülső rekordot, a helye ott marad kihasználatlanul. Az E.F Codd által 1971-ben feltalált relációs adatbáziskezelés (Relational DataBase Management, RDBM, lásd: Codd) nem fix hosszúságú struktúrákat kezelni képes, nagy sebességű, redundancia-mentes, adatvesztés-mentes, egyértelmű hivatkozásokat tárol: A nem fix hosszúságú gyakorlati adatstruktúrákat addig bontja szét (Decomposition), amíg fix hosszúságú rekord-struktúrákat tartalmazó táblákat nem kap Minden táblába rekordjaikat egyedileg (Unique) azonosító elsődleges kulcs (Primary Key) mezőket vezet be. Utána a szétbontott egyedeket az eredeti struktúra adatainak megőrzése érdekében relációkkal (Relation) köti össze: 2 tábla rekordjai közti hivat-kozási kapcsolat, ahol az 1 oldali tábla adott rekordjának elsődleges kulcsára a több oldali táblába rakott idegen kulcsmező (Foreign Key) megegyező értéke hivatkozik: több gyerek : 1 anyához

5 A relációs adatbázis kezelés alapfogalmai 3
Két tábla rekordjai közti reláció számossága elvileg háromféle lehet:1:1 pl. Menyasszo-nyok:Vőlegények, 1:több pl. Anyák:Gyerekek, több:több pl. Könyvek:Kikölcsönzők. De ezek ábrázolása megoldható kizárólag 1:több kapcsolatokkal: Ha két tábla rekordjai 1:1 kapcsolatban vannak, a két tábla összevonható egy táblába Ha a két tábla rekordjai több:több kapcsolatban vannak, ez ábrázolható, úgy hogy a két összekötött törzstábla (pl. Könyvek, Kikölcsönzők) elsődleges kulcsaira hivatkozó idegen kulcsokat tartalmazó relációs tábla (Relation Table) (pl. Kölcsönzések) köti őket össze 2db 1:több-höz kapcsolattal (1 Könyv vagy 1 Kölcsönző:több Kölcsönzés): Könyvek Kód Író Cím 1 Jókai Mór Arany 2 Kőszívű 3 Jancsó-Hernádi Közös... 4 Krúdy Gyula A pofon 5 Mike Tyson Kölcsönzések Kód KönyvKód KölcsKód 1 2 3 5 4 Kikölcsönzők Kód Név Cím 1 Nagy József 7622 Pécs, Rákóczi u. 80. 2 Kiss Katalin 7632 Pécs, Eszék u. 8. 3 Kovács Mihály 7632 Pécs, Nagy Imre u. 105. 4 Török István 7624 Pécs, Jakabhegyi u. 6. 5 Szabó Miklós 7621 Pécs, Fehérhegyi u. 1. (A relációs táblának is lehet elsődleges kulcsa, de annak nincs szerepe a kapcsolat ábrázolásában. Arra szolgál, hogy a relációs táblára is hivatkozhassanak más táblák.) Mivel egy nagy adatbázis sok táblája közti rengeteg relációt nem lehet áttekinthető módon ábrázolni a táblák tartalmán keresztül, szükség volt egy egyszerűsített szimbolikus ábrázolásmódra a táblaszerkezetek (egyedek) és relációik ábrázolására. Ez az egyedkapcsolati diagramm (Entity Relationship Diagram, ERD), amely a relációs adatbázis tervezés fő eszköze, és a következő jelöléseket alkalmazza: az egyedek névvel ellátott, lekerekített sarkú dobozok, bennük az elsődleges kulcsok narancsszínűek, elő-jelölőjük #, a sima tulajdonságok lilák, az idegen kulcsok sötétzöldek. A kötelezően kitöl-tendők előjelölője *, az opcionálisaké o, az 1:több kapcsolatot csirkeláb (Crow Leg) jelöli: Könyv # Kód * Író * Cím Kikölcsönző * Név Kölcsönzés * KönyvKód * Kölcskód 1 Könyv:több Kölcsönzés több Kölcsönzés:1 Kölcsönző

6 A relációs adatbázis kezelés alapfogalmai 4
Kpfizetési számla # Számlaszám * Kibocsátó neve * Kibocsátó címe * Kibocs. Adósz. * Vevő neve * Vevő címe * Számla kelte * Áfa-tartalom% * Végösszeg * Áthárított adó% o Eladó neve o Fizetve Az adatfolyam diagramm tevékenységeinél rög-zített valós adatstruktúrák (pl. ÁFA-s számla) nem alkalmasak az adatbázisba tételre, mert tele vannak belső 1:több kapcsolatokkal, amelyek redundanciát, adatvesztést, és kétértelmű hivatkozásokat okoznak, pl: Egy számlához több tétel tartozik: együtt tá-rolva őket csak fix számú tételt tudunk kezelni Egy cég több eladót alkalmaz: de melyik adta melyik számlát melyik vevőnek? Egy vásárló több számlát kap: de miért kell mindig újra és újra beírni az összes adatát? Egy termék több tételben szerepel: de miért kell mindig újra kitölteni az ÁFA-százalékát? Ezért a valós adatstruktúrákat át kell tervezni, normalizálni (Normalize) kell 5 lépésben: 1. Valós adatstruktúra szétszedése belső 1:több kapcsolatokat nem tartalmazó egyedekre 2. Elsődleges kulcs kijelölése minden egyedben 3. Nem a kulcstól függő tulajdonságok kidobása külön egyedbe (pl. az irányí- tószám meghatározza a tele- pülésnevet, így ez különválik) 4. Az egyedek összefüggő rend- szerbe kötése relációkkal 5. Több:Több kapcsolatok kivál- tása 1:több+relációs táblákkal A normalizáció eredményeként a valós adatszerkezet ember szá- mára áttekinthetetlenül sok egyed- re esik szét, de ez az adatbáziske- zelőt nem zavarja: helypazarlás nélkül, pontosan tárol adatokat és nagyon gyorsan keres vissza! Tétel * ITJ-kategória * Termék neve * Menny. egység * Mennyiség * Egységár * Érték Cég # Adószám * Név * Házszám * Emelet * Lakásszám * Közterületnév * Közter.típus * Irányítószám Eladó # Eladókód * Adószám Számla # Számlaszám * Dátum * Végösszeg * Áthárít.adó% * Fizetve * Eladókód * Vásárlókód Tétel # Tételkód * Mennyiség * Érték * SzlaSzám * Vonalkód Irányszám # Irányítószám * Településnév Vásárló # Vásárlókód Termékfajta # Vonalkód * Menny.egys. * Egységár * ITJ-kategória IparTermJegyz # ITJ-kategória * Áfa-sáv ÁfaKategoria # Áfa-sáv * Áfa%

7 A relációs adatbázis kezelés alapfogalmai 5
Egy belső orvoshoz több eset tartozik és egy eset is több belső orvoshoz tartozik Egy beteghez több eset tartozik, de egy eset csak egy beteghez tartozik BelsőOrvos # OrvosKód * Név * Beosztás * Tel * SzakTerül * Fizetés Beteg # SzemIgSzám * Név * LeányNév * Kor * CsaládÁll * Foglalkozás * Lakcím * HozzátartNév * Apanév * ApaFoglalk A normalizált szerkezetű relációs adatbázis az SQL nyelv segítségével kérdezhető le egyszerűen és nagy sebességgel: Pl. Lekérdezés: Kik a főorvos úr betegei? A belépési pont (Entry Point) az ismert információ (pl. főorvos), a WHERE (szűrőfeltétel) részben foglal helyet. A kilépési pont (Exit Point) az eredmény, ami kell (pl. beteg neve), a SELECT (kiválasztott eredmény) részben foglal helyet. A lekérdezési útvonal (Query Path) a két pont közt halad minimális számú reláción keresz-tül, és a FROM részben definálódik: ezt nem kell bepötyögni, csak az utat egérrel kihúzni! SELECT Beteg.SzemIgSzam, Beteg.Név FROM ( Beteg INNER JOIN Eset ON Eset.SzemIgSzam= Beteg.SzemIgSzam) OvosEset ON OrvosEset.EsetKod= Eset.EsetKod) BelsoOrvos ON BelsoOrvos.OrvosKod = OrvosEset.OrvosKod) WHERE BelsoOrvos.Beosztas = „Főorvos”; húz húz OrvosEset * OrvosKód * EsetKód Eset # EsetKód * SzemIgSzám húz OrvosEset OrvosKód EsetKód 11 411 412 13 413 Eset SzemIgSzám EsetKód GZ-II-2547 411 GF-I-3624 412 413

8 A relációs adatbázis kezelés alapfogalmai 6
Az SQL kód arra is alkalmas, hogy a normalizáció által széttagolt sok-sok táblából felhozzon/ azokba visszavi-gyen adatokat egy elektronikus, akár interneten is elérhető űrlapokból (Forms) álló grafikus felhasználói felületről, amely hasonlóan nézhet ki az eredeti papír űrlapokhoz, hogy ismerős legyen a felhasználónak. A nagy különbség, hogy ezek korlátlanul bővíthetők (pl. 1 számlának tetszőleges számú tétele lehet), az adatrög-zítés nagy része menüből mehet, és nem pötyögéssel, és a mögöttük álló normalizált táblaszerkezet gyorsan, pontosan tárol és keres vissza! SELECT Szamlak.SzlaSzam, Szamlak.Datum, Szamlak.VegOsszeg, Szamlak.Fizetve, Szamlak.EladoKod, Szamlak.VasarloKod, Eladok.Nev, Eladok.AdoSzam, Cegek.Nev, Cegek.HazSzam, Cegek.Emelet, Cegek.LakasSzam, Cegek.KozTerNev, Cegek.IranySzam, IranySzamok.TelepulNev, Vasarlok.Nev, Vasarlok.HazSzam, Vasarlok.Emelet, Vasarlok.LakasSzam, Vasarlok.KozTerNev, Vasarlok.IranySzam, IranySzamok_1.TelepulNev FROM ((IranySzamok AS IranySzamok_1 INNER JOIN Vasarlok ON IranySzamok_1.IranySzam = Vasarlok.IranySzam) INNER JOIN(((IranySzamok INNER JOIN Cegek ON IranySzamok.IranySzam = Cegek.IranySzam) INNER JOIN Eladok ON Cegek.AdoSzam = Eladok.AdoSzam) INNER JOIN Szamlak ON Eladok.EladoKod = Szamlak.EladoKod) ON Vasarlok.VasarloKod = Szamlak.VasarloKod); Cég # Adószám * Név * Házszám * Emelet * Lakásszám * Közterületnév * Közter.típus * Irányítószám Eladó # Eladókód * Adószám Számla # Számlaszám * Dátum * Végösszeg * Áthárít.adó% * Fizetve * Eladókód * Vásárlókód Tétel # Tételkód * Mennyiség * Érték * SzlaSzám * Vonalkód Irányszám # Irányítószám * Településnév Vásárló # Vásárlókód Termékfajta # Vonalkód * Menny.egys. * Egységár * ITJ-kategória IparTermJegyz # ITJ-kategória * Áfa-sáv ÁfaKategoria # Áfa-sáv * Áfa%

9 A gyakorlat tartalma A relációs adatbázis kezelés alapfogalmai Különbség a papír-alapú rendszerektől Adatbázis táblák, elsődleges- és idegen kulcsok Relációs táblák és egyedkapcsolati diagramm Normalizáció, adatbázis tervezés Lekérdezések működése Felhasználói felület, űrlapok Relációs adatbázisok tervezése A manuális tervezés problémái Az MS Access automatikus adatbázis tervező varázslója A varázsló értékelése Relációs adatbázisok és felhasználói felületük megvalósítása MS Accessben Tábladefiníciók és lekérdezések Űrlapok és alűrlapok Webes felület létrehozása Vezérlőpanelek és alkalmazás futtatási beállítások 1. Házi feladat: Automatikus adatbázis tervezés

10 Relációs adatbázisok tervezése
A fentiekből láthattuk, hogy relációs adatbázis rendszer – még a mezítlábas Accessben létrehozva is – nagyságrendekkel nagyobb adatkezelési kapacitással rendelkezik, mint az Excel. Akkor mégis miért van az, hogy szerencsétlen Excelt próbálják tranzakció adatok kezelésére használni – amire nyilván alkalmatlan – és ezzel gyakran tízmilliókat eresztenek a szélbe? A szűk keresztmetszet a relációs adatbázisok tervezésénél van: a hatékony adatbázisok tervezése nehezen algoritmizálható folyamat. A normalizáció 5-6 lépése csak a vázát adja meg, de rengeteg intuitív döntésre van benne szükség, amelyhez jelentős absztrakciós készségre, gyakorlásra és tapasztalatokra van szükség. Ráadásul, teljesen másképp kell gondolkodni, mint a régóta jól megszokott papír-alapú adatkezelő rendszereknél: ott az az elv, hogy mindenféle adatból szorítsak bele egy kicsit egy űrlapba, mert nehéz más aktát visszakeresni. Ha elfogy a hely, majd a margóra írunk. Az adatbázis tervezése során viszont addig darabolom a gyakorlati adatstruktúrát táblákra, amíg abszolút fix helyen tárolható rekordokból állnak, mert nincs margó, ahova beszúrhatnék valamit! A visszakeresési idő viszont nem téma, mert brutálisan gyorsabb, mint papíron: a szerver akkor is miliszekundumok alatt talál meg egy táblát, ha 2 van belőlük vagy 2000 Mindezek miatt sajnos a BSc képzésről kikerülő informatikusoknak jó, ha a 2-3%-a tud elfogadható szinten adatbázist tervezni (itt nem arra gondolunk, hogy nagy nehezen össze tud kapcsolni 2 táblát a copy-paste szakdolijában!!!) Azonban néhány rendszer (pl. MS Access) tartalmaz automatikus adatbázis tervezési varázslót, adatbázis tervezésben kevésbé jártas felhasználók (pl. üzleti elemző) részére. Automatizált tervezésre akkor van esély, ha: A gyakorlati adatstruktúrákhoz jelentős mennyiségű és jó minőségű mintaadatunk van: Nincs bennük sok hiányzó érték Nincs bennük sok elgépelés, vagy korruptálódott adat A különböző adatstruktúrák mezői a nevük és a tipusuk hasonlósága alapján megfeletethetők (pl. ami egyik adatforrásban RendszerDatum, az a másik adatforrásban is megvan RDatum vagy R_Date néven, dátumnak kinéző tipussal) Amelyeket már elektronikus formában tárolnak, vagy a megrendelő erőforrásokat biztosít az adatok normalizálatlan, széttagolt adatbázis táblákban történő rögzítésére (a legtöbbször nem adnak pénzt egy pocsék papír-alapú rendszer adatrögzítésére)

11 Az MS Access adatbázis-tervező varázslója 1
A Stores.xls fájlban egy NY, PA, OH álla-mokban tevékenykedő áruházlánz 160 üzletének natural joinolt adatai találhatók. Első lépésként, importáljuk ezt Accessbe (a végeredményt lásd: Stores.mdb): Fájl|Külső adatok|Import menüvel indítsuk el az importáló varázslót! Válasszuk ki az Excel fájlt, és jelöljük be, hogy oszlopfejléc az első sorban van Tovább gombbal lépve, bejelöljük, hogy új táblát szeretnénk Majd felülírhatjuk a mezők neveit, ha kell Majd magunk választunk elsődleges kulcsot (StoreID) Majd megadjuk az importált tábla nevét: Stores Majd a Befejez gombbal zárjuk a varázslót Erre a tábla megjelenik a Táblák listában Duplán kattintva rajta, megnézhetjük a tartalmát katt katt katt kat-kat katt katt katt katt

12 Access adatbázis-tervező varázslója 2
A Stores tábla kijelölése után Eszközök| Analizálás|Tábla menüvel indíthatjuk a Táblaanalizáló varázslót: Ez a gyakorisági táblás módszerrel meg-próbálja automatikusan dekompozícionál-ni a táblát, ha bejelöljük varázsló dönt-öt A széttagolt táblákat kijelölve a gomb-ra kattintva nevezhetjük el őket (az elne-vezésben segít, hogy a varázsló mit jelölt elsődleges kulcsnak a táblában, és ne adjuk meg már létező tábla nevét!) Ha úgy gondoljuk, valamely mezőt rossz táblába tette, egérrel áthúzhatjuk a táblák közt, illetve több mezőt egyszerre kijelöl-ve Shift+katt-tal, egy üres helyre húzva őket, új táblát készít belőlük A kézzel kibontott táblában gombbal jelölhetünk ki elsődleges kulcsot, ha nem lenne alkalmas mező, gombbal adha-tunk hozzá mesterséges kulcsot Az eredményben látható, hogy a varázsló a főbb összefüggéseket jól bontja ki: 1 városhoz(City) több üzlet(Store) tartozik 1 régióhoz(Region) több város(City) 1 megyéhez(County) több város(City) Azonban a bontás nem tökéletes: Nem veszi észre az állam(State):régió (Region)=1:több kapcsolatot, mert van olyan állam (OH), amiben csak 1 régió van, és ez megzavarja Nem bontja ki a telefonszámkörzet(Area): város(City) = több:több kapcsolatot A problémás mezőket mindig a tábla el- sődleges kulcsa elé rakja! katt katt katt katt katt katt katt katt

13 Access adatbázis-tervező varázslója 3
Ezenkívül nem ír fel olyan rendundáns relációkat, amelyek a lekérdezések gyorsításához kellenének: 1 államhoz(State) több város(City) tartozik 1 államhoz(State) több megye(County) 1 államhoz(State) több számkörzet(Area) A varázsló viszont detektálja, hogy a város: telefonszámkörzet kapcsolat kevés kivé-teltől eltekintve majdnem több:1 kapcsolat: 3 olyan City van csak, ahol több Area kód is jelen van. Ha ezek eltűnnének, az el-sődleges kulcs (City) egyértelműen meg-határozná az Area-t, így az a City tábla rendes mezője lehet (ld. 3.Normálforma) A varázsló feltételezi, hogy a kilógó esetek elgépelés miatt vannak, és kinyit egy ablakot, amiben lehetőséget ad arra, hogy 1 City számára kiválasszunk a több előforduló közül 1 érvényes Area kódot, visszanyomva a City:Area kapcsolatot több:több kapcsolatból több:1 kapcsolatba Az adattisztítási műveletek végeztével a varázsló felkínálja, hogy készítsen-e olyan lekérdezést, amely egy nézettáblában összerakja az eredeti natural joinolt táblát a szétbontott táblákból, és azt átnevezve más névre,beáll a helyére az adatbázisban A varázslót befejez gombbal bezárva bele-írja az adatbázisba a szétbontott táblákat és a köztük lévő relációkat, meghagyva az eredeti táblát is Eszközök|Kapcsolatok menüben megte-kinthető a szétbontott szerkezet relációs diagrammja, és kézzel tovább finomítható! katt katt katt katt katt katt katt

14 Access adatbázis-tervező varázslója 4
Ha a varázsló elégséges adat híján nem bontott ki egy relációt (pl. állam(state): régió(Region) = 1:több), a szétbontott táblát (Regions1) kijelölve, a varázslót újraindítva, azt kézzel tovább bonthatjuk: Ilyenkor a táblából kibontandó mezőket Shift+katt-al kijelöljük, és egérrel kihúz-zuk egy üres helyre, ahol új táblát alkot-nak, amit gombbal elnevezhetünk, gombbal pedig elsődleges kulcsot jelölhetünk ki benne. Az MS Access adatbázis-tervező varázslójának előnyeit és hátrányait a következőkben foglalhatjuk össze:  Képes automatikus dekompozíciót végrehajtani, ha a natural joinolt táblában elégséges mennyiségű és reprezentati-vitású (Representativeness) adatot kap: vagyis az adatok minden, a valóságban gyakran előforduló kombinációjából kap a gyakoriságukkal arányosan rekordokat  Automatikusan detektálja az elsődle-ges kulcsnak alkalmas mezőket  Automatikusan detektálja, ha egy tábla egy mezőjét nem határozza meg egyértelműen a tábla elsődleges kulcsa (3. Normálforma megsértése), és ilyenkor a kilógó adatok módosítását javasolja  csak 1:több, független:függő kapcsola-tokat tud felismerni, igy messze nem használja ki a gyakorisági táblás elemzés összes lehetőséget  n szétbontott egyedet n-1 relációval köt össze, nem kínálja fel a lekérdezéseket katt katt húz gyorsító redundáns relációk létrehozását, mert ehhez be kellene gyűjteni adatokat a felhasználótól arról, hogy mely mezőből (belépési pont) mely mezőt (kilépési pont) milyen gyakorisággal akar lekérdezni.  Abszolút használhatatlan, ha nincsen elégséges mennyiségű mintaadat az elemzéshez, vagyis az estek 95%-ában, például, amikor klasszikus papír alapú rendszerre fejlesztünk rá. Igazából olyan, már régóta működő adatbázisokat lehet vele kijavítani, amiben kisebb normalizá-ciós hibák vannak.  Általában nincs elég adat,ha üzleti mé-retű táblás rendszert akarunk normalizálni vele, mert n tábla szétbontá-sához átlagosan 16/6×n×(n-1) reprezen-tatív rekord kell az alábbi tábla alapján: 100 táblához reprezentatív rekord kell! Megállapítjuk,hogy a varázsló inkább tanulási segédeszköz, de annak sem tökéletes

15 A gyakorlat tartalma A relációs adatbázis kezelés alapfogalmai Különbség a papír-alapú rendszerektől Adatbázis táblák, elsődleges- és idegen kulcsok Relációs táblák és egyedkapcsolati diagramm Normalizáció, adatbázis tervezés Lekérdezések működése Felhasználói felület, űrlapok Relációs adatbázisok tervezése A manuális tervezés problémái Az MS Access automatikus adatbázis tervező varázslója A varázsló értékelése Relációs adatbázisok és felhasználói felületük megvalósítása MS Accessben Tábladefiníciók és lekérdezések Űrlapok és alűrlapok Webes felület létrehozása Vezérlőpanelek és alkalmazás futtatási beállítások 1. Házi feladat: Automatikus adatbázis tervezés

16 Relációs adatbázisok és felhasználói felületük megvalósítása MS Accessben 1
Egy nőgyógyászati kérdőíves felmérés adatait tároló adatbázishoz (lásd: L.mdb) már elvégeztük az MS Access varázslójával a táblaszer-kezetek megtervezését: 1 leányka többször lehet válaszadó, de 1 válaszadáshoz 1 leányka tartozik 1 válaszadóhoz több anyaság tartozhat, de 1 anyaság csak 1 válaszadóhoz tartozhat A felhasználó a következő felhasználói felületen keresztül szeretné használni az adatbázist: A létrehozandó 1 űrlap alapvetően 1 válaszadó adatait ábrázolja majd, ezért ezt bázisegyednek (Base Entity) nevezzük Az ezzel több:1 kapcsolatban álló leányka csatolt egyed (Join Entity) lesz: adatai a bázissal azonos űrlapon jelenhetnek meg, mert 1 válaszadáshoz 1 leányka tartozik A bázishoz 1:több kapcsolódó anya alűrlap egyed (Subform Entity) lesz, és adatai a bázis munkaképernyőbe ágyazott, gördíthető képernyőn, alűrlapon (Subform) jelennek meg, mert 1 válaszadóhoz egyszerre több anyaság tartozhat, listát kellene róluk mutatni Csatolt Bázis Alűrlap

17 Relációs adatbázisok és felhasználói felületük megvalósítása MS Accessben 2
Csatolt Bázis Alűrlap 1.Lépés: az egyedek alapján táblastruktú-rákat definiálunk a Táblák|Tábla létre-hozás szerkesztő nézetben menüvel, Fájl|Mentés menünél beírjuk a nevüket 2.Lépés: Számláló tipusú, Egyednév+ID ne-vű mezők hozzáadása a táblákhoz, gombbal elsődleges kulcsnak jelöljük 3.Lépés:Hosszú egész tipusú idegen kulcsok hozzáadása a relációk( ) több oldalán a táblákhoz, nevük megegyezik a hivat-kozott elsődleges kulcséval,Megjelené-sük legyen Kombinált lista, melyek sorforrásai a relációk 1 oldali Táblái,kö-tött oszlopuk az 1-es(elsődleges kulcs). Hasonlóképp formázzuk azon mezőket, amik értéklista tipusúak (pl.”Jó/Rossz”) 4.Lépés:Eszközök|Kapcsolatok( )menüben gombbal hozzáadunk a diagrammhoz minden táblát, és a megfelelő elsődle-ges és idegen kulcsokat összehúzzuk egérrel, majd a relációs vonalakon dup-lán kattintva beállítjuk a Hivatkozási in-tegritást és az Illesztés tipus gombnál az 1.pontot(csak az egyezők csatolása) 5.Lépés:Mivel 1 űrlapnak csak 1 adatforrása lehet, viszont a Bázis és Csatolt táblák tartalmát 1 űrlapon kellene mutatni, Le-kérdezések|Új lekérdezés tervezőben menüvel készítünk adatforrás lekérde-zést: gombbal hozzáadjuk ezen táb-lákat, és mezőiket egérrel behúzgáljuk a Megjelenítésbe.Fájl|Mentés menüvel mentjük a lekérdezés kódját egy néven katt katt katt katt katt katt katt katt katt katt katt katt húz kat kat- katt katt katt húz katt katt katt

18 Megvalósítás Accessben 3
6.Lépés:a kérdőív főűrlap létrehozására indít-suk el az Űrlapok|Űrlap létrehozása varázslóval menüvel az űrlapvarázslót: Válasszuk ki az adatforrás lekérdezést, és >> gombbal jelöljük ki összes mezőjét Ezután válasszuk ki a lekérdezésben szereplő bázis-táblát (pl.Válaszadók) Az űrlap szerkezete legyen Oszlopos Stílus legyen Szabványos,címe Főűrlap 7.Lépés:Befejez gombra a varázsló lefut, és Tervező nézetre( ) kapcsolva szer-keszthetjük az űrlapot: húzzuk lejjeb a láblécet, hogy az oldaltesten legyen hely az alűrlapnak, és igazítsuk el egérhúzás-sal a főűrlap adatbeviteli kontroljait 8.Lépés:Nézet|Eszköztárak|Vezérlők eszköz-sorról gombbal adjunk hozzá alűrlapot, egérrel kihúzva helyét az üres területen. Erre elindul a segédűrlap-varázsló: Meglévő táblát akarunk adatforrásául Jelöljük ki az alűrlapos táblát (pl.Anyák) és >> gombbal az összes mezőjét Listából választunk felkínált kap- csolómezőt (pl.VálaszadóID) Elnevezzük Segédűrlapnak Befejez gombra lefut a varázs- ló és az alűrlap kontroljai szer- keszthetők egérhúzással 9.Lépés:Az alűrlapot kijelöljük a bal felső űrlap-kijelölő gombbal( ) és jobbkattra előug-ró menüben a Tulajdonságokat kinyitjuk Itt a Formátum fülön Folytonos nézetet jelölünk be,hogy több rekordot mutasson A főűrlap hasonló menüjében az Adat fülön Adatbevitel módot állítunk, a Törlést tiltjuk Megvalósítás Accessben 3 katt katt katt katt katt katt katt katt katt katt katt katt katt katt húz húz katt húz katt katt húz húz katt húz katt katt katt katt katt katt katt katt katt

19 Megvalósítás Accessben 4
10.Lépés:Űrlap nézetre( ) váltással az űrlap fut-tatható. A főűrlapon és az alűrlapon kitöltött adatokat visszaviszi az adatforrás táblákba: A főűrlap adatforrását képező FőűrlapBá-zisLekérdezés ilyenkor fordítva működik, és az alapjául szolgáló Válaszadók és Le-ánykák táblát tölti a főűrlap adataival Az alűrlap közvetlenül az Anyák táblát tölti A táblák elsődleges kulcsai automatikusan számozódnak az új rekordok létrejöttével, mert számláló típusúak Azt, hogy a felhasználó mely táblák mely rekordjait töltötte egyszerre az űrlapon, az elsődleges kulcsokra 1:több relációkon( ) keresztül hivatkozó, automatikusan beíró-dó idegen kulcsok tárolják 11.Lépés:A működőképes és letesztelt űrlapot Fájl|Mentés másként|Adatelérési lap menüvel menthetjük Html-formátumban, (ld.: L.htm), ami ezek után az adatbázis *.mdb fájljával (ld.: L.mdb) együtt feltölt-hető a lekérdezésekhez rendelkezésre álló webszerverre. Sajnos, az Access automatikus weblap-generátora alűrlap- okat nem képes kezelni, ezeket kihagyja Ezért kifinomoltabb megoldásokhoz használjunk MySql +PHP-t, vagy MS SQL szerver és .Net környezet kom -binációját! katt Válaszadók VálaszadóID Születési idő Születési hely Koraszülött volt LeánykaID 1 Pécel Igen 2 Kisújbánya Nem 3 Leánykák LeánykaID Első menstruáció Nőgyógyász neve 1 Réz Gyula 2 Gózon István katt katt Anyák AnyaID Szülés Dátuma Gyerek állapota VálaszadóID 1 Rossz 2 Jó 3 4 5 6 7 8

20 Megvalósítás Accessben 5
12.Lépés:Ha a kérdőív olyan sok kérdést tartalmaz, hogy egy Access űrlap nem tudja kezelni a hozzájuk tartozó adat-beviteli kontrollokat (max. 255 mehet rá), akkor a kérdőívet oldalanként bont-suk több adatbeviteli űrlapra, majd az Eszközök|Adatbázis segédeszközök| Kapcsolótábla-kezelő menüvel hoz-zunk létre föléjük vezérlőpanel-űrlapot: Válaszoljunk Igen-t az új létrehozására Nevezzük el FőKapcsolótáblának és Szerkesztés gombbal szerkesszük A listához Új gombbal adjunk új elemet Nevezzük el a vezérlőt (pl.Főűrlap) A Parancslistából válasszuk ki, mit csináljon (pl.Űrlap Hozzáadás módban: a felhasználó feltölthet új egy új üres űrlapot, de nem néze-getheti a régieket) Adjuk meg, mely űrlapot indítja a vezérlő (pl.Főűrlap) Ügyeljünk rá, hogy legyen egy Ki-lép az alkalmazásból vezérlő is! Bezár gombra létrejön a vezérlőpanel 13.Lépés:Az alkalmazás indítási beállításai. Hogy az adatrögzítő kézzel ne tudjon belepiszkálni az Access adatbázisba, az Eszközök|Indít menüben állítsuk: Az alkalmazás címét: Szüléstörténet Az indító ikonját *.ico formájú fájlként Melyik űrlappal induljon: Vezérlőpanel Adatbázis ablak megjelenjen: Nem Állapotsor megjelenjen: Nem Access menük megjelenjenek: Nem Úgy fog kinézni, mintha önálló program lenne Megvalósítás Accessben 5 katt katt katt katt katt katt katt katt katt katt katt katt katt katt katt katt katt katt

21 A gyakorlat tartalma A relációs adatbázis kezelés alapfogalmai Különbség a papír-alapú rendszerektől Adatbázis táblák, elsődleges- és idegen kulcsok Relációs táblák és egyedkapcsolati diagramm Normalizáció, adatbázis tervezés Lekérdezések működése Felhasználói felület, űrlapok Relációs adatbázisok tervezése A manuális tervezés problémái Az MS Access automatikus adatbázis tervező varázslója A varázsló értékelése Relációs adatbázisok és felhasználói felületük megvalósítása MS Accessben Tábladefiníciók és lekérdezések Űrlapok és alűrlapok Webes felület létrehozása Vezérlőpanelek és alkalmazás futtatási beállítások 1. Házi feladat: Automatikus adatbázis tervezés

22 1. Házi feladat: Automatikus adatbázis tervezés
Janice Schoemaker, a Pops Friendly Markets Inc. (157 szupermarketből álló lánc az USA északkeleti érészén) marketing menedzsere nagy bajban van: a negyedéves üzlet-értékelési adatokat egyetlen táblázatba ömlesztve kapta meg a meglehetősen gondatlanul és nem hozzáértő módon dolgozó Computer Associates Inc. informatikai alvállalkozótól (lásd: StoreMassData.mdb). Ezért megbízta a nemzetközi ösztöndíj-csereprogramban épp Buffaloban tartózkodó, és a Pops-nál nyári gyakorlatát töltő Butler Jánost, aki a PTE-PMMK-n végzett 2002-ben, hogy próbálja kihalászni a következő adatokat, és egy „rendesen működő” adatbázisba tenni (Janice nem informatikai szakember, és csak nagyjából tudta körülírni a feladatot): A táblában valamilyen POS kezdetű mezőkben az AC Nielsen Inc. nevű független piackutató cégtől az üzletekre vonatkozó adatok vannak Valamilye Store kezdetű mezőkben a saját üzletek pénzügyi jelentéseinek adatai Nem világos a kapcsolat a két mezőcsoport közt Próbálja meg az MS Access táblaanalizáló varázslója segítségével, illetve saját szöveges elemzése alapján normalizált adatbázis szerkezetbe szétszedni a StoreMassData.mdb tábla adatait! (3p) A normalizált adatbázishoz hozzon létre űrlapokból-alűrlapokból álló felhasználói felületet! (2p) A megoldás: 1-1Megoldas.mdb MassDataTable POSCode POSChainCode POSChain POSStore POSLabel Address City State Zip Latit Longit 111941 2984 TOPS MARKETS 9 Tops 0009:Portage,Niagara Falls,Ny 1000 PORTAGE RD NIAGARA FALLS NY 14301 111942 21 Tops 0021:Transit,Lockport,Ny 5827 S TRANSIT RD LOCKPORT 14094 111943 22 Tops 0022:Niagara,Niagara Falls,Ny 7200 NIAGARA FALLS BLVD 14304 111944 34 Tops 0034:Vineyard,Dunkirk,Ny 3956 VINEYARD DR DUNKIRK 14048 111945 38 Tops 0038:Lockport,Lockport,Ny 3949 LOCKPORT OLCOTT RD