Kupcsikné Fitus Ilona

ADATBÁZISKEZELÉS II.

SZÁMALK

Budapest, 2004

Impresszum

ELŐSZÓ Tisztelt Tanuló! Üdvözöljük virtuális osztályközösségünkben! Köszönjük bizalmát, megtiszteltetés számunkra, hogy Ön is segítségünkkel kíván új ismereteket szerezni. Az Ön tudásának és készségeinek fejlesztése olyan feladat, amelyet tanáraival együttműködve kell megoldania. Ehhez kívánunk türelmet, kitartást és sok sikert a teljes tanulási folyamatban! Ön tanulmányai során egyre több alkalommal fog találkozni olyan tananyagokkal, amelyek a részben vagy teljesen önálló tanulást segítik. Ezek között is megkülönböztethetők a hagyományos önálló tanulást segítő (nyomtatott) tananyagok, továbbá egyre gyakrabban találkozhatunk elektronikus tananyagokkal is. Az elektronikus tananyagok definíciója még nem egységes. Az elektronikus tananyag (e-learning tananyag) kifejezést alkalmazzák a webre felhelyezett (elektronikusan megjelenített) jegyzetekre, példatárakra, könyvekre, CD-formátumú, tanulási célra készített multimédia-anyagokra éppúgy, mint azokra az előre tervezett e-learning taneszközökre, amelyeket meghatározott képzés adott tantárgyához, önálló tanulás céljára készítenek. Szakértőcsoportunk olyan önálló tananyagokból álló csomagot készített Önnek, amelyek azonos szerkezetben és formai megoldással készültek. (Feladatgyűjtemények esetében természetesen ettől eltérhetünk.) Minden anyag kisebb fejezetekből, tanulási egységekből áll. Ön minden tantárgy bevezetőjéből megtudhatja, hogy mik az adott tananyag követelményei, milyen kisebb egységekből épül fel az anyag, valamint azt is, hogy mennyi időt kell a megtanulására szánnia. Az anyag elsajátításához tanulási tanácsokat is fog kapni. Minden tanulási egység feldolgozása közel azonos időt igényel Öntől. Javasoljuk, hogy egyszerre egy ilyen egységet „dolgozzon fel”, de ne ragaszkodjon mereven a javasolt időhöz. A feldolgozás három részből áll. A tanulási folyamat első fázisában olvassa végig az anyagot, akár többször is. A második fázisban csak az összefoglalót olvassa el. A tanulási folyamat harmadik fázisában oldja meg az önellenőrző feladatokat, válaszolja meg a kérdéseket. Természetesen a megoldásokat is megtalálhatja a tananyagban.

Az önellenőrzést nagyon fontosnak tartjuk, ezért ezt a részt különös figyelemmel készítettük el az Ön számára. Az alábbi lehetőségei vannak, ha saját tudását egy-egy tanulási egység végén ellenőrizni kívánja: • Válaszoljon az önellenőrző kérdésekre, oldja meg a feladatokat, és a

válaszokat írja be a felkínált helyre! Ha a kérdés, feladat megoldása alternatívák közül választható, akkor válasszon!

• Ha közvetlenül a megoldás után ellenőrizni szeretné válaszait, kattintson a megoldás ikonra, melynek eredményeképpen külön ablakban láthatja a megoldást.

• Ha a teljes kérdéssor vagy feladatsor megoldása után szeretné kinyomtatni a kérdéseket és a saját válaszait, akkor kattintson a nyomtató ikonra! Amennyiben a jó megoldásokat is nyomtatni szeretné, akkor kattintson a megoldás nyomtatása ikonra!

A tananyagot törzs- és kiegészítő anyagra osztottuk. A törzsanyag ismerete, illetve az abban foglaltak elsajátítása feltétlenül szükséges. A kiegészítő anyag szorosan kapcsolódik egy-egy témához, tananyagrészhez, de ennek funkciója egyrészt a hiányzó ismeretek pótlása, másrészt kiegészítő információk, anyagok biztosítása azon tanulók számára, akik az adott témakörben többet szeretnének tudni. A tanulási folyamat megkönnyítése érdekében terminológiai szótárat is készítettünk, melyben megtalálja azokat a szavakat, amelyek az adott tananyagban új, idegen kifejezésként fordulnak elő. A terminológiai szótárban szereplő kifejezések a szövegben kék színnel, aláhúzva szerepelnek. Ezekre kattintva külön ablakban a jelentésüket is elolvashatja. Minden tananyagban kiemeltük a hangsúlyos anyagrészeket, definíciókat, melyeket Önnek feltétlenül meg kell tanulnia, illetve ezek gyakorlását javasoljuk. A tananyagokban alkalmazott jelölések, ikonok: Az elektronikus tananyagainkban az alábbi ikonokat használjuk. Ezek jelentése valamennyi általunk fejlesztett tananyagban azonos, a következők szerint

Kiegészítő ismeretanyag Egyes helyeken kisebb betűvel szerkesztve, vagy az ikonra kattintva bővebb ismeretanyaghoz juthatunk. Nagyon fontos, a tárgykör (témakör, készség) elsajátításának elengedhetetlen feltételeként meghatározott tudás- vagy készségtartalom. Megoldandó feladat vagy példa.

Az ikonra kattintva az általunk mellékelt Access-adatbázist letöltheti a saját gépére. A megoldás ikonra kattintva egy külön ablakban megjelennek az adott kérdésre adandó jó válaszok, illetve a feladat megoldása.

Magyarázat, részletes további indoklás.

Az önálló feladatmegoldáshoz kérhető plusz segítség.

A nyomtatás ikonra kattintva az adott oldalt nyomtathatja ki, az Ön által beírt válaszokkal együtt. A megoldás nyomtatása ikonra kattintva nyomtathatja ki az adott feladathoz tartozó helyes megoldásokat. Az egységek nyomtatása ikonra kattintva azt a szövegegységet nyomtathatja ki, amelynek címe mellett az ikon áll. Videoanyagok megtekintése ikon a tananyaghoz kapcsolódó videofájlokat indítja el. Hanggal kiegészített videoanyagok megtekintése ikon a tananyaghoz kapcsolódó videofájlokat indítja el.

Az elektronikus tananyag használatáról részletes ismertetést, praktikus tanácsokat talál a Segítség menüpont alatt. Javasoljuk, hogy a tanulás megkezdése előtt mindenképpen olvassa el az itt leírtakat, illetve használja a menüt minden olyan esetben, amikor a tananyag használata során problémája adódik. Engedje meg, hogy tanulását még négy kérdéssel és az ezekre adott válaszokkal is segítsük! Hol tanuljak? Bárhol, ahol a feltételek adottak. Iskolában, otthon, buszon, esetleg vonaton. Mivel az elektronikus tananyag is nyomtatható, így „papír” formában magával is viheti bárhová és olvashatja. Ugyanakkor meg kell mondjuk, a leghatékonyabb, ha a képernyő előtt tanul, mert a „beépített” navigációs utat betartva haladhat leginkább a tanulásban (a nyomtatott tananyag nem tartalmaz linkeket, beépített segítségeket, például a válaszokat a kérdésekre, illetve kiegészítő anyagokat).

Mikor tanuljak? Természetesen akkor, amikor erre ideje van, illetve amikor szükséges. Erre a kérdésre azonban az igazán jó válasz az, hogy ütemterv – a tananyaghoz tartozó tanulási útmutató – szerint. (A tanulási útmutatót a tantárgy tanulásának megkezdésekor kapja meg.) Ne feledje, Ön közvetlenül felelős azért, hogy tanulási folyamata sikeres legyen! A tananyagfejlesztők és tanárai ebben segítenek Önnek. Elkészítették ezt a tananyagot, megfogalmazták a tanulás és a készségfejlesztés sorrendjét, a tananyagfeldolgozás és az értékelés menetét, így részt vállaltak az Ön tanulási folyamatában, de a többi az Ön dolga. Hogyan tanuljak? Amit feltétlenül ajánlani lehet: úgy tanuljon, ahogyan azt megtervezték az Ön számára. Fogadja el a javaslatokat, ugyanakkor az Ön saját, jól bevált tanulási szokásait sem kell elfelejtenie. Ezek jól hasznosíthatók, ha ütemterv szerint halad, és sikerül teljesítenie azt. Amennyiben egyedül nem boldogul a tananyaggal, kérhet tanácsot tanáraitól. Ne feledje: Ön a tanulás főszereplője, mi valamennyien segítjük Önt, ha kéri. Végül, de nem utolsó sorban, tegye fel önmagának a következő kérdést: Miért tanuljak? Erre a kérdésre bizonyára tudja is a választ. Nyilván mielőtt jelentkezett, átgondolta, milyen előnyökkel járhat, ha elvégzi ezt a képzést. Biztosan számos dolog motiválta, amikor elkezdett tanulni, de az is valószínű, hogy lesznek időszakok, amikor nagyon elkeseredett lesz, vagy már nem tartja annyira fontosnak azt, amire vállalkozott. Ne adja fel! Bízzon önmagában! A tanulás a lehető legjobb dolog, amire vállalkozhatunk, gazdagabbak leszünk általa, és értékesebb munkát végezhetünk. A szerzők és a tananyagfejlesztők nevében jó tanulást és sok sikert kívánok! Dr. Sediviné Balassa Ildikó főszerkesztő

Bevezető Üdvözöljük Tanulóként abban a tanulási folyamatban, amelynek célja, hogy megismertessük Önt a széles körűen alkalmazott relációs adatbázisok felépítésével, és előkészítsük annak SQL-ben történő feldolgozását. Az anyaghoz kapcsolódó példatár és feladattár a gyakorlati munka kelléke: kidolgozott példákon keresztül végigvezet egy lehetséges megoldáson, valamint önálló feladatmegoldásra késztet. Tanárként és tananyagszerzőként az a feladatunk, hogy lehetőséget és segítséget adjunk Önnek ahhoz, hogy az adatbázisok felépítésének megismerése után munkájában használni tudja azokat, és a speciális feladatokra felépített adatbázis minőségét helyesen értelmezni tudja. Együttműködésen alapuló tanítási-tanulási folyamatot szeretnénk megvalósítani, ezért javasoljuk Önnek tananyagunk elektronikus használatát, amelyben az elméleti ismereteken felül gyakorlati példákat, valamint az elmélet elsajátítását támogató és segítő feladatokat is találhat, és azonnal meg is oldhat. (Minderre az anyag nyomtatott formában történő használatánál nincs módja.) A tantárgy célkitűzése Mire készíti fel Önt ez a tantárgy? A tantárgy tanításának célja, hogy megismerje:

• Az adatbázisok fajtáit és alapelemeit; • A relációs adatbázist, a kulcsokat, a jelöléseket; • A funkcionális függőségeket, a normalizálás lépéseit; • Az adatbázisbeli szabályok megadását; • Adatbázis specifikáció dokumentálását; • Mindezeket típuspéldákon keresztül is lássa; • Kidolgozott és levezetett példákon át a szemléletét is megértse; • Feladatok segítségével gyakorolja.

A tantárgy célja továbbá az alábbi készségek fejlesztése: 1. problémamegoldó készség; 2. gondolkodási készség; 3. a tanultak gyakorlati alkalmazásának készsége.

A végső cél az, hogy a tanulási folyamatban megszerzett tudást és gyakorlati tapasztalatot képes legyen munkájában önállóan alkalmazni, és ezzel növelni munkavégzése hatékonyságát.

A tantárgy struktúrája, tartalma A tananyagot 5 fő részre osztottuk. Ezek a konkrét ismeretek elsajátítását segítik elő, és a megszerzett tudás elmélyítését, kiszélesítését, gyakorlását szolgálják. A tananyag tanulása előtt ajánlatos az alábbi tananyag átismétlése:

• Olajos Zsolt: Adatbázis 1. Számalk tananyag A tantárgy tanulásának időszükséglete A tantárgy befejezésekor elvárt ismeret- és készségszint elsajátítása egyénenként más és más időráfordítással érhető el. Ennek figyelembevételével elkészítettünk egy javaslatot, amely átlagos teljesítményt feltételez. A tananyag feldolgozásához 20+12+38 órát javasolunk kontaktóra, csoportos gyakorlatok és önálló tanulás formájában. Az általunk javasolt időbeosztás témakörönként:

Téma Kontakt Csoportos

gyak. Önálló tanulás

1. Az adatbázisok fogalma, az adatbázisbeli redundancia veszélye 3 0 1

2. Az adatmodell alapelemei 3 0 6 3. A relációs adatmodell, a reláció

megadása, a reláció kulcsai, kapcsolatok

3 3 9

4. A funkcionális függőség fogalma, sajátosságai, speciális funkcionális függőségek

3 3 6

5. Normalizált adatbázis, mintasorok készítése 3 3 6

6. A adatbázisbeli megszorítások megfogalmazása 3 3 6

7. Adatbázis-specifikáció dokumentálása 2 0 4 Összesen: 20 12 38

Az önellenőrző kérdések megoldásának időszükséglete és értékelése Az ellenőrző feladatsorokban – nyolcféle adatbázisra 1-1 minta-vizsgasorral – adott normalizált adatbázisra vonatkozó kérdések fordulnak elő, az alábbi csoportosításban: • elméleti alapfogalmak (4+2+2+2+2 pont a helyes válasz) • mintasorok készítése (8 pont a helyes válasz) Miután a Feladatsor nem teszt jellegű, de megjeleníthetők a jó megoldások is, az Ön által adott válaszokat Önnek kell kiértékelnie. A vizsgán rendelkezésre álló idő: 50 perc; a javasolt alsó korlát: 50%. Követelmények a tantárgy megtanulása után Mire lesz képes, amikor a tantárgy tanítási-tanulási folyamata véget ér?

• Felismeri a normalizált – több táblából álló – adatbázist; • Adott eseményt tükröző mintasorokat tud készíteni, melyek az

adatbázis hivatkozási épségét és adatösszefüggéseit nem sértik meg; • Konkrét adatbáziskezelő eszközzel képes adatbázist létrehozni és

karbantartani a hivatkozási épség megőrzése mellett, ill. az adatösszefüggések figyelembe vételével;

Ahhoz, hogy ezek a célok megvalósulhassanak, az alábbi részkövetelményeknek kell megfelelnie:

• A konzultációk alatt értelmezze az ott elhangzottakat, és próbálja meg önálló tanulással, utánajárással elmélyíteni a tanultakat.

• A konzultációk során értse meg, illetve sajátítsa el a korábbiakban ismeretlen tananyagrészeket, a példák megoldásával pedig gyakorolja az új programfunkciók használatát is.

• A valós munkafeladatokat próbálja meg informatikai környezetben értelmezni és kivitelezni.

Jó munkát kíván a Szerző.

BEVEZETÉS Mottó : „...a természet semmit sem tesz hiába, s mindaz, ami sok ok révén történik, bár kevesebbel is megvalósítható lett volna, fölösleges. A természet ugyanis egyszerű, s nem használja a dolgok felesleges okait.” (Newton) Jelen tananyag arra szolgál, hogy bevezetést nyújtson az adatbázisokhoz kapcsolódó fogalomkörbe. Ugyanakkor háttér-információval szolgál az adatbázisokat támogató rendszerek megvalósítását és használatát illetően is, hiszen a háttérben zajló események megértése fontos ahhoz, hogy tisztán lássuk, miért vannak úgy megtervezve az adatbázisok, ahogyan vannak, és hogy miért vannak bizonyos korlátozások az adatbázisokon végrehajtható műveletekre vonatkozóan. Az Adatbáziskezelés II. tananyaga az adatbázis-kezelés alapjait tárgyalja az általános informatikusi szakmai elvárásnak megfelelő szinten. Az adatbázis fogalmának tisztázása után az uralkodó relációs adatmodellbeli jártasság elsajátítása a cél. Mivel az adatbázis-tervezés önálló hivatás és specifikusan felsőfokú szakmai követelmény, képzésünknek nem lesz a témája. Viszont ahhoz, hogy legalább lekérdezzünk egy relációs adatbázisból, tisztázni kell a redundanciamentes adatbázis szerkezetét, meg kell tanulni a mások által megtervezett adatbázisban való tökéletes tájékozódást. Éppen ezért itt csak bemutatjuk a normalizáláshoz szükséges lépéseket és azok matematikai eszközeit. Több életszerű adatbázisban végigkövetjük az ügyviteli funkciók szabályos adatfolyamatait. A relációs adatbázis szabványosított lekérdező nyelvével (SQL) a következő félévben ismerkedünk meg az Adatbáziskezelés III. keretében. Ahhoz, hogy jól használjuk majd az SQL lehetőségeit, fontos az alapfogalmak tökéletes tisztázása, és a tárolt adatok közti összefüggések felismerése. Rengeteg példa-adatbázisban fogjuk végiggondolni az ún. üzleti logikát, (előírt szabályokra épülő adatbáziskezelés) előkészítve így az igényes SQL-alapú adatbázis szemléletet, miszerint csak a jól megtervezett adatbázist lehet hatékonyan feldolgozni. Hallgatóink a következő félévben képesek lesznek majd felismerni, munkájuk során pedig kritikusan szemlélni minden adatbázist, amelyből minimum helyes SQL-lekérdezésket kell készíteniük. Jelölésrendszerünkben a hagyományokkal rendelkező rendszerfejlesztés előírásaihoz igazodunk. A gyakorlati háttér az Adatbáziskezelés I. alatt megismert korszerű adatbáziskezelő szoftver, legalább valamely MS Access. Cél, hogy hallgatóink a lehető legtöbb minta-adatbázist próbálják ki, ellenőrizzék bennük/hiányolják belőlük a megszorításokat és döntsék el az ügyviteli funkciók

ellentmondásmentességét. (Mindezekre találhatók Access-illusztrációk a tananyagban.) Bizonyos adatbáziskörüli teendőkről (tervezés, specifikálás) azért szólunk legalább érintőlegesen, hogy hallgatóinknak ne okozzon majd gondot, ha munkahelyükön valamely konkrét adatbázisról szakmailag kifogástalanul kell tudniuk kommunikálni. A elméleti tankönyv fejezetei eléggé tagoltak, teljesen a tematikát követik. A fejezetek felvezetéséből kiderül, mivel foglalkozik, és mennyire fontos része a számonkérésnek, esetleg csak a megértést segíti. Tartozik az anyaghoz Példatár, ahol összetettebb adatbázisokra gyakorolhatjuk a számonkérés egyik-másik típusfeladatát. Formailag teljesen a számonkérést mintázzák a Feladattár vizsgasorai; mellettük pedig javaslat található az értékelésre. A fejezetek végén a kulcsszavak felsorolása hívja fel a figyelmet az elengedhetetlen elméleti fogalmakra. A tankönyv Fogalomtára valójában a definíciók és szintaxisok gyűjteménye.

ADATBÁZISOK Az adatfeldolgozás szemléletének fejlődése Az adatbázisok lényege érthetőbb, ha áttekintjük az adatfeldolgozás fejlődésének útját. Az információk kijelentéseket tartalmaznak a valós világ összetevőiről, a képzetes mennyiségeiről, valamint fogalmairól. (Az információt gyakran együtt értik a hordozójával.) Legkisebb egységei a szavak (adat-előfordulások). Az adatok csak más adatokkal együtt képeznek értelmes kijelentéseket. Minden adat lehetséges értelmezését annak típusa határozza meg, értéke pedig az adat pillanatnyi állapota. Az adatokat bizonyos szabályok betartása mellett általában felírhatjuk NULLák vagy egyesek sorozataival. Ez képezi a kettes számrendszerbeli digitális adattárolás alapját. Az algoritmusok a számítási, tágabb értelemben adatfeldolgozó eljárások mikéntjét fogalmazzák meg – nagyrészt tekintet nélkül az adott feladat pillanatnyi adatértékeire. Neumann János egyik fontos újítása volt a számítástudományban, hogy a számítási eljárásokat is információknak tekintette. Adatokat nagy tömegben mágneses háttértárolókon tárolunk, melyekhez a programok az operációs rendszeren keresztül férnek hozzá. Az összetartozó adatok állományokba (fájlok) vannak szervezve, melyek rekordokból épülnek fel. A rekordon belül rendszerint az azonos adattípusú adatok azonos sorrendben követik egymást. Az adatállományokon végzett alapműveleteket 1969-ben szabványosították a Cobol nyelv leírásának keretében. Az ott rögzítetteket azóta sokféle programozási nyelvben, fájlkezelő rendszerben alkalmazták. A rekordokra vonatkozó négy alapművelet: olvasás, írás, visszaírás, törlés. Az adatállományok rekordjaihoz való hozzáférés háromféle lehet: sorfolytonos, közvetlen cím szerinti, indexelt. Egyre inkább követelmény lett, hogy ugyanazokhoz az adatokhoz egyidőben több alkalmazás is hozzáférjen. Az adatok adattípusaik szerinti értelmezéséhez, valamint az értékekre vonatkozó szabályokhoz szükségessé vált egy katalógus (adatszótár). További igényt támasztott az, hogy ezen katalógus megkerülésével senki se férjen az adatokhoz. Ez megkövetelte a négy adatkezelési alapművelet kibővítését illetve szigorítását. Az adatbázisok lényege tehát az adatkatalógusok és az azokra támaszkodó adatkezelő rendszerek jelenléte. (Stolnicki Gyula: SQL kézikönyv, ComputerBooks 1995.)

Lényegében az adatbázis nem más, mint hosszú ideig meglévő információk gyűjteménye, amelyet egy adatbázis-kezelő rendszer kezel. Egy ilyen rendszerrel szemben az alábbi elvárásaink vannak: • Tegye lehetővé a felhasználó számára új adatbázis létrehozását. • Engedje meg a felhasználónak az adatok lekérdezését,

módosíthatóságát. • Támogassa nagy mennyiségű adat hosszú ideig való tárolását,

garantálja az adatok biztonságát, és tegye lehetővé a hatékony adathozzáférést.

• Felügyelje a több felhasználó által egyidőben történő adathozzáféréseket, és ezek ne vezessenek az adatok következetlenné válásához.

Az első adatbázis-kezelő rendszerek a hatvanas években kezdtek megjelenni. Ezek a fájlkezelő rendszerekből alakultak ki, amelyek a fenti pontok egyikének sem feleltek meg maradéktalanul. Az első rendszerek arra ösztönözték a felhasználót, hogy az adatokat olyan vizuális formában ábrázolja, ahogyan azok tárolva vannak. A legfontosabb modellek a hálós és hierarchikus modellek voltak, amelyek gráffal ábrázolták az adatokat. Ez utóbbit egy Adatrendszerekkel és Nyelvekkel Foglalkozó Bizottság szabványosította. Ezen korai modellek hátránya az volt, hogy semmilyen magas szintű lekérdező nyelvet nem támogattak. Ted Codd 1970-ben publikálta híres cikkét, amelyben azt javasolta, hogy az adatbázis-rendszereknek az adatokat a felhasználó felé táblázatok formájában kellene megjeleníteni: ezeket a táblákat nevezzük relációknak. Ellentétben a korábbi rendszerekkel, egy relációs rendszer felhasználójának nem kell törődnie az adatok tárolási struktúrájával. A lekérdezések olyan magas szintű nyelv segítségével fejezhetők ki, amelyek használata jelentősen növeli a programozói hatékonyságot. Az IBM volt az első cég, amely relációs és korábbi modelleket támogató adatbázis-kezelő rendszereket is árusított. Később számos újabb cég alakult, amely relációs adatbázis-kezelők megvalósításával és árusításával foglalkozott. Ma már ezek közül néhányan a világ vezető szoftverkereskedő cégei közé tartoznak. (Ullman – Widom: Adatbázis-rendszerek alapvetés nyomán) Kulcsszavak a fejezetben: adatbázis

Adat, információ Ebben a fejezetben röviden áttekintjük az információkezelés történetét, és megkíséreljük az információ szemantikai jelentését megfogalmazni. Erre azért van szükség, mert az adattárolás szervezettségének foka egyenes arányban van a valódi információtartalommal. Tudnunk kell, hogy csak azon adatokat vagyunk képesek feldolgozni, és ezzel újabb információkat szerezni, amelyeknek ismerjük a rendezettségét, vagyis dekódolni tudjuk azok tárolási szerveződését. Amíg nem jelentek meg az energiátalakító gépek a történelemben, nem esett szó energiáról. Most is ilyen korban élünk: információátalakító gépek születtek, tehát időszerű az információról is beszélni. Szabványos bevezető helyett, mely minden számítástechnikai könyv elején megtalálható az adatról és információról, olvassuk el figyelmesen a következő idézetet: „Az információ ugyanúgy a világegyetem fizikai valóságához tartozik, mint az anyag és az energia.” (Tom Stonier: Információ és az univerzum belső szerkezete, Springer Hungarica 1993.) Ez a bevezető egy mai fizikus vitaindító könyvéből való, mely szerint a tiszta információt időszerű lenne definiálni, mert ennek hiányában nincs általános információelmélet, az információ-feldolgozás pedig nem válik tudománnyá. Valóban, ha elgondolkodunk azon, hogy a tiszta információ akkor is benne van a tankönyvben, ha mi ki sem nyitjuk és el sem olvassuk, akkor hajlunk arra, hogy az információ szemantikai jelentését átgondoljuk. Amennyiben el tudjuk olvasni a tankönyvet, azaz fel tudjuk dolgozni a benne kódolt információt, akkor számunkra jelentést hordozóvá válik. Az ilyennek pedig hatalmas irodalma van a távközléssel foglalkozó munkákban. A könyvet viszont csak akkor tudjuk elolvasni, ha ismerjük azt a nyelvet, amelyen írták, azaz a festékmolekulák szerkezeti elhelyezkedését meg tudjuk fejteni. Tehát a tiszta információ valahogy a rendezettségben nyilvánul meg, mint ahogy a fény az árnyékban. A tiszta információ hordozói például a tankönyv, a DNS-molekula, vagy a számítógépes input adatok. Ezek feldolgozására csak olyan ember, sejt vagy program képes, mely ismeri azok szervezettségét, tehát dekódolni tudja az abban rejlő információt. Így válik a feldolgozó számára hasznossá, azaz jelentést hordozó információvá. Azon sem csodálkozunk, hogy egy DNS molekulában magasabb fokú rendezettség lehet, mint egy sókristályban. A tiszta információtartalom valószínűleg a rendezettség mértékével függ össze, vagyis minél bonyolultabb a szervezettség, annál több információt rejt magában. Ebben a tárgyban óriási jelentősége lesz a tárolt adatok szervezettségének, tehát az abba fektetett hasznos munka nagyobb információtartalommal fog szolgálni a feldolgozó számára. Látni fogjuk, hogy a feldolgozó csak akkor tudja az adatokat feldolgozni, ha ismeri azok rendezettségét. Az adatok közti kapcsolatok értelmezése után például további összetett információ előállítására lesz alkalmas a feldolgozó. A tiszta információ definiálása nem történt meg, de a tudós szerint a mennyisége azzal a hasznos munkával arányos, amely az anyag rendezett állapotban tartásához vagy rendezett állapotba hozásához szükséges. Ez

teljességgel ellentmond a távközlési szakirodalomnak, de a fizikában működik. Tehát a tiszta információ tőlünk függetlenül létezik, és nem kell összekeverni a hordozóival, sem a feldolgozásával. Az információkezelés rövid története

• Távközlési szakemberek munkái Shannon A hírközlés matematikai elmélete c. munkája az első, amely az információval tudományosan foglalkozik, sőt, bevezeti az információmennyiség mértékét is. Ahogy a cím is sugallja, hogy a jelentést hordozó információról van szó.

• Az elsősorban matematikai problémák megoldására használt számítógépek összetett információk feldolgozására alkalmas gépekké válnak A számítógépek egyre inkább alkalmasak az algoritmizálható folyamatok elvégzésére, tehát nem lepődünk meg, ha nem csak számszerű következtetésekre adnak választ.

• A genetikai információ hordozójának felfedezése Óriási lendületet adott a szakterület fejlődésének, hogy felfedezték a genetikai információ hordozóját, illetve a vele utazó örökítő programot.

• Az információ mint "érték" Piacorientált világban egyre nagyobb érték lett az információ birtoklása, ezért annak gyors beszerzése az elektronikus tárolást sürgette.

• Igény született intelligens adatbázisokra és az azokat kezelő programokra Fontossá vált az adatok több szempont szerinti rendezett tárolása, és az ezeket létrehozni, illetve feldolgozni képes programok gyártása.

• Adatmodellekben való gondolkodás Az adatok szabvány szerinti szervezése szakmai kihívást jelentett, mert célkitűzéssé vált az adatok sokak által történő felhasználása.

Az információ elektronikus tárolása:

• szövegszerű (szinte rendezettség nélküli) • állományi (valamilyen fokú rendezettséggel bír)

Eszerint a jelenlegi információ-feldolgozó programok számára még nem értelmezhető teljes egészében például egy választékosan megírt regény annak minden hangulatával és összefüggéseivel. Mint tudjuk, még nincsenek tökéletes nyelvi fordítóprogramok sem. Ha az adatok tárolása mellett az azok közti kapcsolatokat is szeretnénk letárolni, akkor valóban információtárolásról beszélünk, de ennek megtervezése komoly feladat. Ennek algoritmizálható részéről nemsokára szó lesz, de műveléséről csak a következő félévben. Kulcsszavak a fejezetben: információ, információtárolás.

Adatmodellek, alapelemek Ebben a fejezetben beszélünk az adatmodellben való gondolkodás kialakulásáról, tisztázzuk az adatbázis fogalmát az alapelemek definiálásával: melyek az egyed, a tulajdonság és a kapcsolat. Ezek segítségével megkülönböztetjük az adatmodellek fajtáit.

Az első adatbázis-kezelő rendszert az IBM vezette be IMS (Information Management System) néven 1969-ben. Ebben a rendszerben az adattárolás faszerkezetekre vezethető vissza. Az adatkezeléshez szabványosított eljáráskészletet nyújtott az IBM. A CODASYL (Committee on Data Systems and Languages) 1971-ben újfajta adatbáziselvet tett közzé, a hálós szerkezeten alapuló adatszerkezetet. Nyilvánvaló hátránya, hogy a logikai kapcsolat megváltoztatása a tárolás átszervezését okozta. Viszont értékes újítást jelentett az adatdefiníciók elválasztása az adatkezeléstől nyelvi eszközeiben. Híres megvalósítás: IDMS (Integrated Database Management System). Az említett gondok leküzdését szem előtt tartva vázolta fel 1971-72-ben E. F. Codd a relációs adatmodellt. A logikailag hasonló egyedeket táblázatokba foglalta, melyek kezelését a halmazelmélet műveleteire alapozta. Az adategyedek azonosítására és kikeresésére annak kiválasztott adatmezőit használta, és azokat kulcsnak nevezte el. P. Chen 1976-ban továbbfejlesztette Codd modelljét, és bevezette az adategyedek közti tartós kapcsolatokat jellemző kulcsok definiálását (ERM: Entity Relationship Model). Stolnicki Gyula: SQL kézikönyv, ComputerBooks 1995. Adatmodell-próbálkozások 1. Formalista megközelítés

Ebben a modellben az adatok és kapcsolataik tárolása gráfokkal ábrázolható. Ebből fejlődött ki a hierarchikus és hálós adatmodell.

2. Szemantikai megközelítés

A modellt verbálisan, szavakkal írták le, ami kudarcot vallott. Akkor ugyanis még nem volt bizonyított, hogy nyelvi fordítóprogramot sem lehet készíteni.

3. Matematikai megközelítés

Matematikai struktúrák felhasználásával életképes modellt állított elő Codd, de csak jóval később nyert elismerést. A nevével is jelzett modell matematikai indoklásból a relációs adatmodell elnevezést kapta.

Adatbázis-kezelő rendszer (továbbiakban: ABKR):

Az a szoftver (DBMS – Database Management System), amellyel az adatbázist kezelni tudjuk. Két fontos műveletet kell tudnia:

1. létrehozás (karbantartás) 2. visszakeresés (lekérdezés)

Ennek megfelelően adatdefiníciós nyelvre, illetve adatkezelési nyelvre bomlik. (Napjaink ABKR-eiben az adatbiztonsági utasítások további csoportot alkotnak.) Az adatbázis-kezelő rendszerek két fajtája: 1. beépülő típus (IDMS, SQL)

ahol egy behívó nyelvvel együtt használható az adatfeldolgozó nyelv 2. valóságos programozási nyelv (dBase, Clipper, Paradox, Oracle,

Informix...) ahol önálló adatfeldolgozó nyelvként használható

Az adatbázis-kezelő rendszerek segédfeladatai: 1. adatvédelem, adatbiztonság

Önállóan vagy az operációs rendszerrel együtt egyre nagyobb fokú biztonságra törekszenek az ABKR-ek gyártói.

2. integritási feltételek Az adatok közti kapcsolat és az egyes adatokra vonatkozó szabályok megőrzése nélkül ellentmondó információkhoz jutnánk. Ebben a pillanatban kicsit korai a hivatkozási integritás taglalása, de modelltől függetlenül máris egyetértünk olyan, rendszerelemzés során található összefüggésekkel, mint:

• nem szabad rendelt tételt addig felvinni, amíg a keretrendelés nem létezik;

• nem szabad keretrendelést törölni addig, amíg vannak tételei; • nem szabad olyan cikkre hivatkozni, ami nincs a cikkek

törzstárában; • nem szabad cikket addig kitörölni a törzstárból, amíg hivatkozik rá

egy rendelési tétel stb. 3. Szinkronizáció

Többfelhasználós esetben meg kell oldani az egyidejű hozzáférés anomáliáit.

Az adatmodellek alapelemei

EGYED TULAJDONSÁG KAPCSOLAT

Az egyed: minden olyan dolog (objektum), ami minden más dologtól (objektumtól) megkülönböztethető. Előzetes tanulmányokra támaszkodva az egyedet nevezzük fájlnak. Az egyed egy konkrét értéke: előfordulás. Például: DOLGOZÓ, AUTÓ, BETEG, ÜGYFÉL, CIKK, BIZONYLAT... Tehát én, mint Kupcsikné Fitus Ilona egy előfordulás leszek a Számalk Rt. Dolgozó egyedében vagy egy balesetet követően az egyik kórház Beteg-egyedében. Már most érezzük, hogy a két egyedben más-más jellemzőimmel fogok szerepelni. A tulajdonság: az egyed belső szerkezete. Az egyedeket tulajdonságokkal (attribútumokkal) írjuk le. A tulajdonság értékeivel egy adott egyed konkrét értékét határozzuk meg. A dolgozó nevű egyed tulajdonságai például: név, lakcím, dolgozószám, fizetés, végzettség, osztály,... A beteg nevű egyed tulajdonságai: név, életkor, TAJ-szám, diagnózis,... Amennyiben egy tulajdonság vagy tulajdonságok egy csoportja egyértelműen meghatározza, hogy az egyed melyik értékéről van szó, akkor ezeket együtt kulcsnak nevezzük. Pl. hallgatókód a HALLGATOban A hallgató jelentkezéskor előírás szerint megadja azt az 5 adatát, amely őt egyértelműen azonosítja. Ezek: neve, lakcíme, születési helye, ideje, anyja neve. Miután ez az 5 tulajdonság nagyon hosszú kulcsnak, ezért a nyilvántartásba vételkor azonnal generálnak neki egy rövid azonosítószámot, amit hallgatókódnak nevezhetnek el. A kapcsolat: az egyed külső szerkezete. A kapcsolat az egyedek közötti viszony. A konkrét értékek a kapcsolat előfordulásai. Példa: VEVŐ-RENDELÉS, SZÁMLA-CIKK ... A példákban már az egyedek neve is sugallja a kapcsolatok fajtáját: 1 vevőhöz több rendelés tartozhat, több számlán szerepelhet 1 bizonyos cikk. Egyelőre csak sejtjük, hogy azért van több egyedünk az adatbázisban, mert ugyanazt az adatot feleslegesen többször nem fogjuk tárolni. Egy vevőnek van rengeteg olyan tulajdonsága, ami egyértelmű: a törzsadatai (pl. név, születési hely, idő, különféle azonosítószám stb.) és aktuális adatai (mint pillanatnyi lakcíme, telefonja, utolsó vásárlásának dátuma stb.). Ezen kívül vannak a forgalmi adatai, melyek minden rendelése alkalmával tárolásra kerülnek (pl. rendelés dátuma, fizetési határidő, összérték stb.). Ha belegondolunk, hogy egy rendelés több tételt is tartalmazhat, akkor minden egyes rendelési adathoz több rendeléstétel is tartozhat, vagyis új egyed szükséges, melyben a konkrét rendelésbeli cikk és az abból megrendelt mennyiség kerül tárolásra.

Később meglátjuk, hogy milyen algoritmus szerint járnak el az egyedek kialakításánál relációs modell esetén. A kapcsolatok fajtái adatmodelltől függetlenül:

1:1 kapcsolat 1:N kapcsolat N:M kapcsolat

Az egy-egy típusú kapcsolat: Az egyik egyedhalmaz mindegyik eleméhez a másik egyedhalmaznak pontosan egy eleme kapcsolódik. Például DOLGOZÓK : KÜLSŐK A példa az „alegyed” esetére (az összes dolgozónak egy részhalmaza a külsők halmaza) vonatkozik, ugyanis ekkor ajánlott az ilyen kapcsolat-fajta. Ez azt jelenti, hogy a minden egyes dolgozóról tárolt törzsadatot egyben tartunk, és azokról, akiket további tulajdonságokkal kell jellemezni, új egyedben tartjuk ezekkel a megkülönböztetett tulajdonságokkal. Az egy-több típusú kapcsolat: Az A egyedhalmaz mindegyik eleméhez a B egyedhalmaznak több eleme is tartozik. Például VEVŐ : RENDELÉS Ahogy fentebb írtuk, 1 vevőhöz több rendelés is tartozhat, míg fordítva nem igaz: egy rendelés kizárólag egy vevőtől jön. A több-több típusú kapcsolat: Az A egyedhalmaz minden eleméhez a B egyedhalmaz több eleme tartozhat, és fordítva. Például TERMÉK : ALKATRÉSZ Ha végiggondoljuk, hogy 1 termék több alkotóból állhat, és 1 alkatrész is több terméknek lehet az alkotója, akkor rádöbbenünk, hogy van ilyen kapcsolat-fajta. Figyelem, amint modellt választunk (a logikai modell fizikai megvalósításra kerül), a kapcsolatfajták csökkenhetnek. Három adatmodell létezik az alapelemek fizikai tárolásától függően:

egyed tulajd kapcs hálós, hierarchikus

+ - +

relációs + + - objektumos + + +

objektum-relációs: vegyes adatmodell

A hálós modellben gráffal ábrázolható az adatbázis: a gráf csúcsain az egyed-előfordulások, az éleken a köztük lévő kapcsolat helyezkedik el. A legkisebb címezhető egység a rekord, tehát a tulajdonságok leírása csak a dokumentációban található meg. A relációs modellben, ahol az egyed egy táblázat, óriási szerepet kapnak a tulajdonságok. Viszont fizikailag nem tárolódnak a kapcsolatok, csak a dokumentáció tartalmazza. (Amennyiben a külső kulcsok megszorításként való definiálására gondolnak, az bizony logikai utalás: csak egy program segítségével lehet az értékek egyezőségét megkeresni.) A PC-k elterjedésével monopolhelyzetbe kerültek az ilyen modellt kezelő adatbázis-kezelők, és így kifejlődött a szabványos lekérdező nyelvük (az SQL). A tiszta objektumos modellben a tulajdonság lehet felsorolt típusú, és egy ilyenben a vele kapcsolatban álló másik egyed rekordjainak fizikai címeit tartjuk. Ez a kapcsolat fizikai tárolása. Meg kell jegyezni, hogy az ilyen adatbázis-kezelők nem tudnak elterjedni, mert még nincs szabványos lekérdező nyelvük, vagyis programozni kell minden funkciót. Viszont gyorsan fejlődnek az öszvér-megoldások, amikor a robosztus relációs adatbázis-kezelőket javítják fel az objektumos lehetőségekkel. Miután a nagy relációs adatbázis-kezelő rendszerek gyártói igyekeznek az SQL nyelvet állandóan bővíteni, ez az újabb szabványok bevezetését eredményezi, de az eredeti szabványt mindegyik termék érti. Idén megismerjük az első szabvány SQL nyelvet, jövőre pedig az újabb szabványok lehetőségeit. Senki se higgye, hogy ezek szerint a legfejlettebb modell a relációs, mert minden feladat meghatározza saját alkalmas modelljét, csak a körülmények (pl. valamely adatbázis-kezelő megléte) befolyásolják a rendszerfejlesztési választást. Az igazsághoz az is hozzátartozik, hogy hálós adatbázis-kezelő csak nagygépes operációs rendszerekre létezik, a tiszta objektumos adatbázisok kezeléséhez pedig programozói tehetség kell. Ezek után a definíciók: Az adatmodell véges sok egyednek, azok véges számú tulajdonságainak és kapcsolataiknak a halmaza. Az adatbázis véges sok egyed-előfordulásnak, azok véges sok tulajdonságértékének és kapcsolat-előfordulásának az adatmodell szerint szervezett együttese. Kulcsszavak a fejezetben: egyed, tulajdonság, kapcsolat, kapcsolat-fajták, adatmodellek.

RELÁCIÓS ADATBÁZIS A PC-k elterjedésével helyzetbe került modell kezelésének fejlesztése Codd 1971-es eredményeire alapozva állandó fejlődésben van, és számos szoftvercég érdekeit tiszteletben tartva folyik a feldolgozás nyelvének szabványosítása. A korai modellekkel szemben a relációs modellt egy magasszintű lekérdező nyelv támogatja, amely nemcsak a lekérdezést, hanem az adatdefiniálást és az adatmanipulálást is ellátja. Ez a nyelv az SQL. Az első ilyen adatbázis az R adatbázis (IBM, 1976) volt, melynek kidolgozói – Codd, Chen és Date – megvalósították azt a törekvést, hogy az adatok tárolási módja független legyen a logikai adatszerkezettől. Reláció Ebben a fejezetben a relációs adatmodell matematikai értelmezését illetve szabványos leírását adjuk meg. Innen kezdve a relációt táblának fogjuk nevezni. Figyeljük meg, hogy a táblát nemcsak nevével, hanem szerkezetével kell megadni.

A relációs adatmodell Az egyedet egy táblázattal adjuk meg. A táblázat oszlopai a tulajdonságok. Például Személyeket kívánunk tárolni nevükkel, születési dátumukkal és aktuális lakhelyükkel egy táblázatban. A sorok felvitelkor automatikus sorszámot kapnak.

Reláció: a tulajdonsághalmazok Descartes-szorzatának részhalmaza. Mivel minden tulajdonság egy halmaz, azok Descartes-szorzatának egy részhalmaza valójában a táblázat. Mivel a matematikában az ilyen szorzatok részhalmazát relációnak nevezik, a modell erről kapta a nevét. Magyarázatként a reláció matematikai értelmezéséről: Vegyünk 2 halmazt, képezzük azok Descartes-szorzatát, majd vegyük annak egy részhalmazát (azaz matematikailag egy relációt): NÉV = {K,L,B, M} KOR = {21,16,35}

név szüldát lakhely 1 Aba Tamás 68. 01. 03 Sarkad 2 Varga Péter 27. 03.12 Pécs 3 Varga Károly 88. 08.22 Battonya

NÉV x KOR = { [K,21], [K,16], [K,35], [L,21], [L,16], [L,35], [B,21], [B,16], [B,35], [M,21], [M,16], [M,35] } RELA1 = { [K,35], [L,21], [M,21] } RELA1 ⊆ NÉV x KOR A tábla tehát a reláció (R), melynek oszlopai az attribútumok, sorai a rekordok. A relációs adatbázis rövid jelölése: R {A1, A2, ..., An} ahol R a reláció neve, Ai pedig az i. attribútum. Legyen : A = {A1,A2,...,An} a tábla attribútumainak halmaza. A fenti példa relációja tehát: SZEMÉLY {név, szüldát, lakhely} Tekintsük az alábbi hétköznapi bizonylatot: Minta

Vevő neve Kelt Vevő címe Határidő

RENDELÉS

cikkszám1 cikknév1 egysár1 x db cikkszám2 cikknév2 egysár2 y db

Összérték

aláírás pecsét

Ha az ilyen rendelési bizonylatok nyilvántartását szeretnénk megvalósítani, akkor az ügyvitelt figyelembe véve a következő fontos dolgot kell figyelembe vennünk: • minden bizonylat kap beérkezéskor egy rendelési számot (rendszám); • egy vevő több rendelést is küldhet, tehát vevőkóddal érdemes ellátni

(vkód); A kiindulási reláció, mely pillanatnyilag a nyilvántartásunk adatbázisa: RENDELÉS {rendszám, vkód, vevőnév, vevőcím, kelt, határidő, cikkszám, cikknév, egysár, rendmenny, összérték}

Természetesen azonnal látjuk, hogy a táblázat redundáns adatokat tartalmaz:

• egy vevő több törzsadata (vevőnév, vevőcím) minden bizonylat alkalmával tárolódik;

• egy bizonylat fej- és lábléc-adatai (vevő, kelt, határidő és összérték) minden tétel alkalmával tárolódnak;

• egy cikk több törzsadata annyiszor tárolódik, ahány bizonylaton megrendelték.

A továbbiakban arra törekszünk, hogy ezt a redundanciát megszüntessük. Kulcsszavak a fejezetben: reláció, relációs adatmodell, reláció szabványos megadása, redundancia

Kulcsok Ebben a fejezetben a relációs adatbázisban fennálló kapcsolatokat kell tisztázni az egyes táblák elméleti kulcsának és külső kulcsának segítségével. Meg kell tanulni az SQL nyelv használata céljából, hogy két tábla csak akkor áll kapcsolatban, ha az egyik külső kulcsként tartalmazza a másik kulcsát. Az adatbázisban való jártasság érdekében jól kell használni az egyszerű és összetett kulcs, illetve a kulcsszerepű és másodlagos tulajdonság fogalmát. Az általános alapfogalmak bevezetésénél már volt szó a különleges tulajdonságról vagy tulajdonságcsoportról, mely egyértelműen meghatározza az egyed-előfordulást. Relációs adatmodell esetén is (amikor az egyed tábla), annak valamely tulajdonsága, vagy tulajdonságcsoportja képes lehet a tábla sorát beazonosítani. A reláció kulcsa Az A attribútumhalmaz egy K részhalmaza kulcs, ha: 1. a K értékei az R reláció mindegyik sorát egyértelműen

meghatározzák; 2. de ha egyetlen attribútumot is elhagyunk K-ból, az 1. már nem

teljesül. Aláhúzással jelöljük a reláció kulcsát. Pl.: A rendelési bizonylatok egyetlen táblájának, a RENDELÉSnek a kulcsa: {rendszám, cikkszám} halmaz; valószínűleg azért, mert egy bizonylat egyetlen tételét a rendelésszám és cikkszám egyértelműen meghatározza. Figyelem, az ilyen információt a rendszerfejlesztés megbízójától szerezheti meg a fejlesztő, de legalább tőle kap megerősítést, amikor tapasztalatból ezt megsejti. Nézzük csak meg: ha ismerjük a rendszám és a cikkszám értékét, akkor az összes többi tulajdonság értékét ismerjük. Ez a kettő egyértelműen meghatározza a tábla többi oszlopának értékét, beleértve a rendelt mennyiséget is. Az is nyilvánvaló, hogy a kulcsértéknek ezek után csak egyszer szabad előfordulnia a relációban. Ebből az is következik, hogy a kulcsot kötelezően ki kell tölteni. A kulcsok csoportosítása: egyszerű kulcs: egyetlen attribútumból áll összetett kulcs: egyébként kulcsszerepű attribútum: a kulcsnak a része másodlagos attribútum vagy leíró: egyébként Például: A {személyiszám} egyszerű kulcs a DOLGOZÓ {személyszám, név, fizetés} relációban,

A {személyiszám, hónap} összetett kulcs a TÖRLESZTÉS {személyszám, hónap, összeg}-ben. Az összetett kulcs (halmazelméleti indokból) tagjainak sorrendje nem számít. Tehát az elméleti kulcs fogalmát ne keverjük a technikai kulcskifejezés fogalmával, ahol már fontos a sorrend, mert rendezési szempont. (A Törlesztés kulcskifejezése lehet személyszám és azon belül hónap, vagy fordítva, hónapon belül személyszám. De az egyik mellett döntve biztos létrehoznánk egy duplikált, nem egyedi kulcsot is a hónapra vagy a személyszámra, mert arra is kell majd keresni.) A táblák közti kapcsolat szempontjából lényeges fogalom a külső vagy idegen kulcs. Külső/idegen kulcs : az a tulajdonság (vagy több tulajdonság együttese), amely egy másik relációnak a kulcsa. Pl. a személyszám a Törlesztésben külső kulcs. A külső kulcs • lehet kulcsszerepű, de lehet másodlagos tulajdonság is; • a kapcsolat hordozója. Fogadjuk el, hogy relációs modellben: Két reláció csak akkor áll kapcsolatban egymással, ha az egyik külső kulcsként tartalmazza a másik kulcsát. Ez azt jelenti, hogy relációs modellben, amikor a redundancia megszüntetése miatt több kisebb táblára fogjuk bontani az adatbázisunkat, az egyes táblák közt fennálló kapcsolatokat csak logikai redundanciával érjük el, azaz az egyik tábla kulcsát bevisszük a másik tábla oszlopai közé. Azt is mondhatnánk, hogy a külső kulcs értékei egyértelműen fognak rámutatni egy másik tábla valamely sorára a kulcs alapján. Gyakran hívjuk gyerektáblának azt, ahol külső kulcsként szerepel egy másik tábla – az ő szülőtáblájának – kulcsa. Amikor a kulcs és külső kulcs elnevezése azonos, és egyértelműen kell megfogalmazni, melyikről beszélünk, legrövidebben a táblanév.mezőnév alakban tehetjük meg. Az adatbázis épségének biztosítása miatt a külső kulcsba írt érték csak olyan lehet, ami kulcsként már létezik abban a táblában, amire hivatkozik. Kulcsszavak a fejezetben: a reláció kulcsa, egyszerű és összetett kulcs, kulcsszerepű és másodlagos tulajdonság, külső kulcs, táblák közti kapcsolat.

Jelölések Ebben a fejezetben a relációs adatbázisban fennálló kapcsolatok szabványos jelölését ismertetjük, és egyiküket bevezetjük saját használatra. Tipikus mintapéldákon illusztráljuk a lehetséges kapcsolatokat.

Egyedek közti kapcsolat jelölése

vonalas:

E1

E2

Chen-féle:

E1

1 : N

E2

varjúlábas:

E1

E2

egyértelmű:

E1

E2

Két kapcsolatban álló tábla közé vonalat húzni általában nem elég. Ha a vonalra írjuk, melyik oldalon van az 1 érték, melynek a másik oldalon több felel meg, akkor mindent jeleztünk a kapcsolatról. Természetesen sokkal kellemesebb mindezt a vonal típusával jelezni, mint ráírni. Az általános rendszerfejlesztési szakirodalomhoz igazodva rajzolhatunk varjúlábat, amelynek az ujjai a sok felé mutatnak; vagy a modern case-eszközök stílusához igazodva rajzolhatunk nyilat, amelynek a hegye az egy felé mutat. Mi az utóbbihoz ragaszkodjunk, mert egyszerű és mindenki számára világos, hogy oda mutat, ahol egyértelműen meghatároz egy előfordulást. Kapcsolatban álló relációk ábrázolása kulcsszerepű

tulajdonságok kulcsszerepű

tulajdonságok EGYED1 EGYED2 másodlagos tulajdonságok

másodlagos tulajdonságok

Ugyancsak az általános rendszerfejlesztési szakirodalomhoz igazodva használjunk a relációk megadására egyoszlopos táblázatot, melyben a kulcsszerepű tulajdonságokat a másodlagosaktól a reláció neve választja el. Tehát a tábla tulajdonságait egy oszlopban soroljuk fel, melyek elején a kulcsot alkotó tulajdonságok vannak, majd megkülönböztetett betűvel a tábla neve, végül a leíró tulajdonságok. Amennyiben két tábla között kapcsolat áll fenn, akkor nyilat húzunk közéjük. Aki megteheti, még a nyilat is úgy helyezi el, hogy az az egyik tábla külső kulcsából mutasson a másik tábla kulcsára. Igaz, a nyílhegy egyértelműen a tábla kulcsára mutathat, de ahonnan ered, bizony nem mindig beszédes, mint külső kulcs. 1. példa

azonosító azonosító

dátum DOLGOZÓ PRÉMIUM név fizetés

összeg

Példánkban a dolgozóknak az azonosítójukon túl nevük és aktuális fizetésük van. A prémium-kifizetésekről azt tároljuk, hogy ki, mikor, mekkora összeget kapott: a kulcs alapján egy nap csak egyszer kaphat valaki. A Prémium.azonosító külső kulcs, és a Dolgozóra mutat. Bármelyik dolgozó többször kaphat prémiumot (akár naponta), tehát a Dolgozó:Prémium kapcsolat 1:N. További magyarázatot talál a videón.

2. példa

azonosító DOLGOZÓ név fizetés főnök

Példánk szerint a főnök is dolgozó. A Dolgozó tábla főnöke külső kulcs, mely egy Dolgozóra (tehát azonosítóra) mutat. Így világos, hogy minden dolgozó törzsadatai közt a közvetlen főnökét (mint egy másik létező azonosítót) is tároljuk. Figyelem, ilyen esetben a legnagyobb főnöknek nincs főnöke, ezért meg kell engedni egy különleges azonosító (a létező azonosítóktól teljesen különböző jelsorozat) bevitelét is a külső kulcsban. Az ilyen kapcsolat rekurzív, mert a tábla önmagával van (1:N) kapcsolatban. További magyarázatot talál a videón.

3. példa

azonosító

rendszám

SZEMÉLY GÉPKOCSI név cím

tulajdonos üzemeltető

Példánkban mindkét tábla törzsfájl, ugyanis egyszerű kulccsal rendelkeznek. A Személyben mindenki csak egyszer, a Gépkocsiban minden kocsi csak egyszer fordulhat elő. De a gépkocsinak – pl. egy taxi-vállalatnál – van tulajdonosa és üzemeltetője is, akik nem feltétlenül azonos személyek. Mindkét tulajdonság külső kulcs és egyenként pontosan egy (nem feltétlenül különböző) Személyre mutatnak. Mivel a külső kulcsok nem kulcsszerepűek, hanem csak leírók, külön gondoskodunk arról, ha kötelező kitölteni. Az ilyen kapcsolat párhuzamos, mert a Személy tulajdonosként vagy üzemeltetőként 1:N kapcsolatban van a Gépkocsival. További magyarázatot talál a videón.

4. példa

azonosító

jogszám SZEMÉLY JOGOSÍTVÁNY név cím

azonosító állapot

Ugyancsak két törzs között áll fenn kapcsolat, mégpedig 1 személynek lehet több jogosítványa. No, nem a retikülben, hanem abban a nyilvántartóban, ahol a jogosítványokat kiadják. Valójában a jogosítványnak állapota is van: pl. személyenként legfeljebb egy az aktuális, akár több az ellopott vagy elveszett stb. Itt is leíróként szerepel a külső kulcs, tehát alaphelyzetben lehet ismeretlen (nem kitöltött) értéke is. Ha viszont kitöltjük, akkor csak a személyben már létező azonosító-értékkel tehetjük azt meg. További magyarázatot talál a videón.

5. példa Gyakori eset a relációs modellben, amikor az elméleti több:több viszonyt ún. kapcsolótáblával lehet megoldani. Jelenleg 1 számlán több termék és 1 termék több számlán is szerepelhet. Ezért a két törzstábla közé harmadik táblát kell létrehozni – egy későbbi fejezetben vezetjük le ennek technikáját –, és az lesz kapcsolatban a másik kettővel.

szlaszám

szlaszám tkód

tkód

SZÁMLA TÉTELEK TERMÉK kelt vevő

darab

elnevezés egységár

Nevezzük Tételeknek a kapcsolótáblát, melyben mindkét törzs – Termék, illetve Számla – kulcsa külső kulcsként fog szerepelni, esetünkben éppen kulcsszerepben. Ez azt jelenti, hogy egy számlán egy termék csak egyszer fordulhat elő. Figyelem: a Számla:Tételek kapcsolat 1:N (1 számlán több termék lehet), a Termék:Tételek kapcsolat 1:N (1 termék több számlán fordulhat elő), a Számla:Termék között pedig nincs kapcsolat. További magyarázatot talál a videón. Kulcsszavak a fejezetben: kapcsolatok jelölése a relációs adatbázisban.

Funkcionális függőség Ebben a fejezetben a reláció tulajdonságai között fennálló függőségeket fogalmazzuk meg, majd ezekből újakat származtatunk. Az adatok redundáns tárolásának megszüntetése miatt további speciális függőségeket vezetünk be, hogy ezek segítségével végezzük majd el az adatok több táblára való bontását. Funkcionális függőség Legyen R{A1, A2 ..., An } egy reláció és P, Q az A attribútumhalmaz részhalmazai. Azt mondjuk, hogy P funkcionálisan meghatározza Q-t (vagy Q funkcionálisan függ P-től), ha abból, hogy a reláció valamely két sora megegyezik a P halmazon, következik, hogy a két sor értékei megegyeznek a Q halmazon is. Jele: P→Q Rendelésnyilvántartó példánkban az egyetlen tábla 11 tulajdonságból állt: RENDELÉS {rendszám, vkód, vevőnév, vevőcím, kelt, határidő, cikkszám, cikknév, egysár, rendmenny, összérték} Legyen P = {rendszám}, Q = {vkód, kelt, határidő, összérték} Ekkor P →Q teljesül, ugyanis ha ismert a rendszám (a rendelési bizonylat száma), akkor egyértelmű a vevő kódja, a bizonylat kelte, határideje és összértéke. További funkcionális függőségek: {vkód} →{vevőnév, vevőcím} {cikkszám} →{cikknév, egysár} {rendszám, cikkszám} →{rendmenny} Tehát a vkód egyértelműen meghatározza a vevő törzsadatait, a cikkszám a cikk törzsadatait, de ahhoz, hogy egyértelmű legyen a rendelt mennyiség értéke, bizony ismerni kell, melyik bizonylat melyik tételéről van szó, tehát a rendszámot és a cikkszámot is. Megjegyzés A kulcs definíciójából következik, hogy a K kulcs funkcionálisan meghatározza:

• a „kulcson kívüli” attribútumhalmazt példánkban: {rendszám, cikkszám} → {vkód, vevőnév, vevőcím, kelt, határidő, cikknév, egysár, rendmenny, összérték}

• az egész attribútumhalmazt K → A

Rendelés-nyilvántartó adatbázisunkban ezen fejezet elején felsoroltunk 4 tapasztalható funkcionális függőséget:

1. {rendszám} → {vkód, kelt, határidő, összérték} 2. {vkód} →{vevőnév, vevőcím} 3. {cikkszám} → {cikknév, egysár} 4. {rendszám, cikkszám} → {rendmenny}

Függőségi család Egy adatbázisban lehet több olyan (P,Q) pár is, melyre P→Q. Ezek halmazát az adatbázis funkcionális függőségi családjának hívjuk, és F-fel jelöljük 1. kérdés: Ismert funkcionális függőségekből kikövetkeztethetők-e újabbak? A válasz: Igen. Az ún. Armstrong-axiómák (szabályok) alapján. A funkcionális függőségek tulajdonságai

1. Reflexivitás Ha Q ⊆P ⊆A, akkor P → Q

2. Bővítés Ha P → Q és S ⊆A, akkor P ∪S → Q ∪S

3. Tranzitivitás Ha P → Q, Q → S, akkor P → S

4. Egyesítési szabály Ha P → Q, P → S, akkor P → Q ∪S

5. Pszeudotranzitivitási szabály Ha P → Q,T ∪Q → S, akkor P ∪T → S

6. Dekompozíciós szabály Ha P → Q és S ⊆Q, akkor P → S

Alkalmazás: Mivel {rendszám} → {vkód, kelt, határidő, összérték} és {vkód} →{vevőnév, vevőcím}, ezért a 6. és 3. szabály értelmében : {rendszám} → {vevőnév, vevőcím} 2. kérdés: Egy X → Y függőség kikövetkeztethető-e egy F családból az Armstrong-axiómák alkalmazásával ? A válasz: igen. A lezárt fogalmának segítségével.

Az X+ (X lezártja F-re nézve) azon Q attribútumok halmaza, amelyre az X→Q függőség az Armstrong-axiómák segítségével F-ből kikövetkeztethető. A 2. kérdésre a válasz: Az X→Y függőség akkor és csak akkor következik egy F függőségi családból az Armstrong-axiómák alapján, ha az Y részhalmaza az X lezártjának, azaz Y⊆X+. Ez valóban némi kerülőt jelent, hiszen az összes tulajdonságot kell összegyűjteni, amiket a bal oldal meg tud határozni, majd el kell dönteni, hogy a kérdéses jobb oldal közte van-e az előállított összesnek. De ez a módszer algoritmizálható, tehát egy számítógépes módszer lehet. Példa RENDELÉS {rendszám, vkód, vevőnév, vevőcím, kelt, határidő, cikkszám, cikknév, egysár, rendmenny, összérték} adott az F függőségi család: {rendszám} → {vkód, kelt, határidő, összérték} {vkód} → {vevőnév, vevőcím} {cikkszám} → {cikknév, egysár} {rendszám, cikkszám} → {rendmenny} Következik-e F-ből: {rendszám} → {vevőcím} 1. lépés: {rendszám} lezártjának meghatározása 2. lépés: {vevőcím} részhalmaza-e a lezártnak 1. lépés: Az X-ből indulunk ki és megnézzük, hogy az X részhalmazai melyik függőség bal oldalán fordulnak elő. X(0) = {rendszám} Ahol ilyet találunk, annak a jobb oldalát hozzávesszük a halmazunkhoz, és folytatjuk a részhalmazok keresését a függőségek bal oldalán. X(1) = {rendszám}∪{vkód, kelt, határidő, összérték} X(2) = {rendszám, vkód, kelt, határidő, összérték} ∪ {vevőnév, vevőcím} X(3) = X(2)

Az algoritmusnak akkor van vége, ha már nem bővül a halmazunk (maximum addig tart, amíg az összes, véges sok tulajdonság belekerül), azaz minden olyan tulajdonság belekerült, akiket az X egyértelműen meghatároz a F családból a szabályok segítségével. Tehát : {rendszám}+ = {rendszám, vkód, kelt, határidő, összérték, vevőnév, vevőcím} 2. lépés: {vevőcím} ⊆{rendszám}+ igaz. A kérdéses függőség tehát származtatható volt a megadott függőségekből.

Relációk szétbontása Módszereket dolgoztak ki arra, hogy a relációk szétbontása veszteségmentes legyen (a funkcionális függőségek megmaradjanak). Cél: A redundancia megszüntetése. Speciális funkcionális függőségek Definiálnunk kell legalább az alábbi 3 speciális függőséget, de előtte felhívjuk a figyelmet arra, hogy létezésük kívánatos-e vagy sem. teljes: jó részleges: rossz tranzitív: rossz Ezek segítségével tanulhatjuk meg a relációk szétbontásának veszteségmentes módszerét. Valójában a módszer a redundancia mértéket nagyban csökkenti (általában megszünteti), és óriási előnye, hogy algoritmizálható. Ebben a képzésben csak annyira mélyedünk el a módszerben, hogy a mások által megtervezett adatbázist felismerjük és megértsük az adatok több táblában való elhelyezését. Teljes függőség Legyen P, Q ⊆A és P → Q. Q funkcionálisan teljesen függ P-től, ha Q a P egyetlen részhalmazától sem függ. Ellenkező esetben részleges a függőség. Példák: 1. RENDELÉSTÉTEL {rendszam, cikkszam, darab} 2. TÖRLESZTÉS {szemszám, hónap, összeg, kelt} 3. LÁTOGATÁS {azonosító, dátum, időpont, téma, időtartam} A fenti 3 különálló tábla mindegyikének összetett kulcsa van, és a leíró tulajdonságok a kulcstól teljesen függnek. Ha például a Rendeléstételben benne lenne a vevőkód vagy a cikknév, akkor azok nem teljesen függnének saját kulcsuktól, hiszen a vevőkód csak a rendszámtól, a cikknév pedig csak a cikkszámtól függ teljesen. Ilyen esetben a vevőkódot mindannyiszor megismételnénk, ahány különböző cikket vennénk fel mellé, illetve a cikk nevét is annyiszor megismételnénk, ahány különböző rendelésszámon előfordul. A Törlesztésben egy személy havonta legfeljebb egyszer törleszt és azt egyértelműen valamilyen napon teszi valamekkora (valószínűleg különböző) összeggel. Itt sincs a leírók között csak a személyre, illetve a hónapra vonatkozó törzsadat, mert bizony feleslegesen többször kellene tárolnunk.

A Látogatás kulcsa szerint egy ügyfél adott napon akár több időpontban is látogatást tehet (esetünkben a főnökünknél, akinek a nyilvántartását vezetjük), és valahány percet valamilyen témában ott töltött, de vitatkozhatunk azon, hogy ha többen vannak egyidőben a megbeszélésen, akkor esetleg egy témáról folytatnak megbeszélést. Tehát a részleges függés redundanciát okoz, ellentettje a teljes, amire törekedni kell. Ez azt jelenti, hogy a kulcs mellett valóban csak olyan leíróknak van helyük, melyek egyike sem függ a kulcs valamely valódi részhalmazától. Tranzitív függőség Az S tranzitíven függ P-től, ha létezik olyan Q ⊆A, hogy P → Q, Q → S, de visszafelé nem igazak a függőségek. Példák: 1. DOLGOZÓ {szemszám, név, osztkód, osztelnev} 2. RENDELÉSFEJ {rendszám, vkód, vevőnév, vevőcím, kelt, határidő,

összérték} 3. LÁTOGATÓK {azonosító, név, cég, cégnév, cégcím, cégtel} A fenti 3 különálló tábla mindegyike redundáns, mert tranzitív függőség van bennük. A Dolgozóban az osztály elnevezése függ tranzitíven a kulcstól, mégpedig az osztály kódján keresztül. Minden dolgozó valamelyik egyetlen osztályon dolgozik, de többen dolgoznak ugyanazon az osztályon, így több dolgozó mellett ugyanazt az elnevezést tároljuk. Az osztelnev tulajdonság tehát nem maradhat a Dolgozó táblában. A Rendelésfejben pedig a vevőnév és vevőcím tárolódik feleslegesen sokszor, mert egy vevőnek több rendelésszáma is lehet. A rendszám egyértelműen meghatározza a vevő kódját, attól pedig a vevő törzsadatai függnek teljesen. A Látogatók táblában pedig a cég törzsadatainak nincs helyük, hiszen a kulcstól tranzitíven függnek a cég kódján keresztül. Valóban több látogatónk is lehet ugyanattól a cégtől, tehát a cég nevét, címét és telefonját nem illik minden dolgozó mellett tárolni. A következő fejezetben pontosítjuk a részleges és tranzitív függés kiszűrésének menetét, de addig fogadjuk el, hogy a Dolgozóba csak az osztkód kerülhetne az osztályadatok közül, a Rendelésfejbe pedig csak a vkód a vevőadatok közül, illetve a Látogatókba csak a cég a cégadatok közül. A többi leíróval nem volt gond. Kulcsszavak a fejezetben: funkcionális függőség, teljes (részleges) és tranzitív függőség.

Normalizálás Ebben a fejezetben megfogalmazzuk az első 3 normálformát, mint a redundancia megszüntetésének algoritmizálható lépéseit. Az eljárást egy mintapéldán keresztül mutatjuk be, de a normalizálás készségszintű művelését a képzésben résztvevő hallgatóknak nem kell elérni. Itt azért kell az eljárással megismerkedni, hogy a már – esetleg mások által – megtervezett adatbázist is felismerjük, és képesek legyünk feldolgozni.

Normálforma: az egyed szerkezeti állapota. A normálformák egymásra épülnek, azaz normálformában lenni annyit jelent, hogy már az (n-1). formában benne van. Ha relációs modellben az emberekről a nevet, születési dátumot és a szakképzettségeket kellene tárolni, akkor egyelőre 3-oszlopos táblát képzelünk el, melyben a szakképzettség bizony többértékű tulajdonság lenne.

NÉV SZAKKÉPZETTSÉG SZÜLETÉSI DÁTUM Nagy Zsolt gépészmérnök 52.02.16 közgazdász Kiss Pál lakatos 58.08.08

R 0. normálformában van (0NF, vagy N1NF típusú), ha létezik olyan másodlagos attribútum, amely a kulcstól funkcionálisan független. Magyarul a táblázat ismétlődő ismeretet tartalmaz (esetünkben a szakképzettség, mely a név és születési dátum kettőstől nem függ, azaz nem egyértelmű a kulcs alapján). Gondolhatunk először olyan ostoba megoldásra, mely szerint a szakképzettség tulajdonságot olyan hosszúra (vagy változó hosszúságúra) definiáljuk a tábla létrehozásakor, hogy oda beférjen több szakképzettség is (valamilyen elválasztójelek között). Nos, ilyen esetben nemcsak az a gond, hogy esetleg mégis rövidnek bizonyul, hanem az, hogy nem tudunk benne majd gyorsan keresni. Például, a „Kik a közgazdászok?” kérdésre minden sorban hosszasan kell majd rész-karakterláncokat ellenőrizni, hátha előfordul benne a keresett szó, pedig ha minden sorban csak egy szerepelne, akkor arra érdemes lenne lerendezni, hogy felező módszerrel lehessen benne keresni. Gondolhatunk még rettenetesebb megoldásra is: mintegy soremeléssel az új sorban csak a következő szakképzettséget töltjük ki az előző sor személyéről. De a személyekről nem egyszerre viszik be az összes szakképzettséget, mert esetleg később szereznek újabbakat, vagyis nem működhet a lásd előző módszere. Arról nem beszélve, hogy adatainkat több szempont szerint szeretnénk rendezni, hogy majd gyorskereshessünk. Milyen szörnyű lenne egy név szerinti rendezésben egymás alatt a sok-sok csupa szóköz név,

melyek mellett a nem első szakképzettségekről már nem lehetne tudni, hogy kihez tartoznak. R 1. normálformájú (1NF típusú), ha minden másodlagos tulajdonság funkcionálisan függ a kulcstól. Magyarul a táblázat minden sorában pontosan egy attribútumérték lehet minden oszlopban. (Ez nem azt jelenti, hogy kell: vagyis azokat a tulajdonságokat, amelyek nem kötelezők – mint a hajszín –, nem kell kitölteni.) Az előző példa 1NF-ben:

NÉV SZAKKÉPZETTSÉG SZÜLETÉSI DÁTUM Nagy Zsolt gépészmérnök 52.02.16 Nagy Zsolt közgazdász 52.02.16 Kiss Pál lakatos 58.08.08

R 2. normálformájú (2NF típusú), ha 1-es normálformában van, és minden másodlagos attribútuma a reláció bármely kulcsától teljesen függ. Tehát nincs benne részleges függés. Az előző fejezetben tisztáztuk, hogy csak azok a tulajdonságok maradhatnak egy táblában, amelyek a kulcstól teljesen függnek, ugyanis a részleges függés redundanciát okoz. Cél, hogy minden tulajdonság olyan táblába kerüljön, amelynek kulcsától teljesen függ. Megjegyzések

• Ha az R kulcsa egyetlen attribútumból áll, akkor máris 2NF típusú. Ugyanis a kulcsnak nincs valódi részhalmaza, amitől függni lehetne.

• Ha nincsen R-ben másodlagos attribútum, akkor úgyis 2NF típusú. Ugyanis nincsenek leírók, amik valamelyike a kulcstól részlegesen

függhetne. Példa: a BIZONYLATFEJ és BIZONYLATTÉTEL esete Általában mindenféle bizonylat, ami több tételt is tartalmazhat, mindig fej- és tétel-adatokra fog bomlani, ugyanis vannak olyan tulajdonságok, amik csak a bizonylat számától függnek teljesen, és vannak azok, amelyek egyértelmű meghatározásához a bizonylatszám mellett legalább a tételsorszámra szükség van. (Rendelés-mintánkban a tételt a rendszám és cikkszám azonosította.)

R 3. normálformájú (3NF típusú), ha 2-es normálformában van, és egyetlen másodlagos attribútuma sem függ tranzitíven valamely kulcstól. Tehát nincs benne tranzitív függés. Az előző fejezetben tisztáztuk, hogy csak azok a tulajdonságok maradhatnak egy táblában, amelyek egy másik leíró tulajdonságtól sem függnek, ugyanis a tranzitív függés redundanciát okoz. Cél, hogy minden tulajdonság olyan táblába kerüljön, amelynek csak a kulcsától függ. Példa: a BIZONYLATFEJ és PARTNER esete Általában mindenféle bizonylat pontosan egy partnertől érkezik, és az a partner több bizonylatot is küldhet. A partner sok törzsadata mellett bizonyára kap egy kódot nálunk, aminek valóban be kell kerülni a bizonylatfejbe, de a többi törzsadatnak nem. A partner kódja a partner táblában lesz kulcs, ami mellett a többi törzsadatot tároljuk helyesen. Megjegyzések 1. Nézzünk példát a csupakulcs-esetre:

ÜGYELET {ki, mikor} Itt a tábla csak kulcsszerepű tulajdonságokat tartalmaz (ki mikor jött be ügyeletet tartani), tehát 3NF-ben van. Valószínűleg a ki egy dolgozókódra mutat, a mikor pedig egy dátum. Ha naponta több műszak lenne, akkor a műszak sorszámát is tárolni kellene, de kérdés, hogy a kulcs részeként, vagy leíróként. Ha a feladat olyan helyre készül, ahol egy dolgozó egy napon csak egy műszakban ügyelhet, akkor leíróként tároljuk, hányadik műszakban jelent meg, egyébként pedig kulcsszerepben.

2. Nézzünk példát a több kulcsjelölt esetére:

SZÁMLATÉTEL {szlaszám, sorszám, cikkszám, mennyi} Itt a táblának több kulcsa is van: az aláhúzással jelölt számlaszám és sorszám (ez az általános), de sokszor előfordul, hogy a dőlt betűvel jelzett számlaszám és cikkszám (miután egy számlán egy cikk csak egyszer szerepelhet). Igazság szerint (ha poroszosan letároljuk a sorszámokat is), dönteni kell, melyik legyen az elsődleges kulcs, amit automatikus megszorításként kezel majd egy adatbázis-kezelő rendszer, majd gondoskodni kell a másik egyediségéről is egy újabb megszorításban.

Normalizálás (normálforma dekompozíció): Az eljárás, amelyben a kedvezőtlen normálformájú egyedet lebontjuk több kívánt normálformájú egyedre. Célja: a tárolási és karbantartási káosz megszüntetése veszteségmentesen.

Eszerint a redundancia csökkentése érdekében normalizálunk, de úgy, hogy a funkcionális függőségeket ne veszítsük el. Az eljárást egy ősrégi példán (Autósbolt) mutatjuk be, és bebizonyítjuk, hogy a redundancia meghagyása anomáliákat okozott volna az adatbázis feldolgozásában. Eredeti példánk: Első relációnk a 11 tulajdonságból álló Rendelés-tábla volt. RENDELÉS {rendszám, vkód, vevőnév, vevőcím, kelt, határidő, cikkszám, cikknév, egysár, rendmenny, összérték} A kulcs definíciója alapján tudjuk, hogy a kulcs egyértelműen meghatározza az összes tulajdonság értékét, azaz minden tulajdonság funkcionálisan függ a kulcstól: {rendszám, cikkszám} → {vkód, vevőnév, vevőcím, kelt, határidő, cikknév, egysár, rendmenny, összérték} A tulajdonságok között további funkcionális függőségek is fennállnak (az előző fejezetben már felsoroltuk): {rendszám} → {vkód, vevőnév, vevőcím, kelt, határidő, összérték} {vkód} → {vevőnév, vevőcím} {cikkszám} → {cikknév, egysár} A normalizálás 1. lépése, hogy minden sor önálló bejegyzésként legyen rögzítve (egyetlen tulajdonság sem lehet azért nem kitöltött, mert „ld. előző sorbeli érték”). A 11 tulajdonságot kitöltve redundáns táblát kapunk, mert több tulajdonság sem teljesen függ a kulcstól. A 2. lépés tehát a kulcstól való részleges függőség megszüntetése. Összetett kulcsunk mellett nem maradhatnak azok a tulajdonságok, melyek a kulcs valamelyik részétől függnek csak (vkód, vevőnév, vevőcím, kelt, határidő, összérték, cikknév, egysár); új táblába kell kerülniük olyan kulccsal, melytől teljesen függnek: {rendszám, cikkszám} → {rendmenny} {rendszám} → {vkód, vevőnév, vevőcím, kelt, határidő, összérték} {cikkszám} → {cikknév, egysár} Ezen teljes függőségek alapján 3 táblánk lesz az 1 helyett; mindháromnak nevet fogunk adni, ha végeztünk. (Vegyük észre, hogy az összetett kulcs tagjai ilyen esetben külső kulcsokká válnak.) A 3. lépésben a kulcstól való tranzitív függőséget kell megszüntetni. Jelen esetben ilyen csak a 2. teljes függőségben található; mert a leírók között függőség áll fenn:

{vkód} → {vevőnév, vevőcím} Emiatt van tranzitivitás: {rendszám} → {vkód} → {vevőnév, vevőcím} Ilyen esetben azokat a leírókat, amelyek más leírótól függnek, új táblába kell átrakni azzal a kulccsal, melytől közvetlenül függnek: {vkód} → {vevőnév, vevőcím} {rendszám} → {vkód, kelt, határidő, összérték} (Vegyük észre, hogy az a leíró, melyen keresztül jött létre a tranzitív függés, külső kulccsá válik ilyen esetben.) Így lesz 4 táblánk az eredeti 1 helyett a kapott 4 teljes és nem tranzitív függőség alapján: {cikkszám} → {cikknév, egysár} {rendszám, cikkszám} → {rendmenny} {rendszám} → {vkód, kelt, határidő, összérték} {vkód} → {vevőnév, vevőcím} A táblanevek lehetnének például a fenti sorrendnek megfelelően CIKK, RENDELÉS_TÉTEL, RENDELÉS_FEJ, VEVŐ, ui. a bal oldalon szereplő tulajdonságok lesznek az egyes táblákban a kulcsok, a jobb oldaliak pedig a leírók: CIKK {cikkszám, cikknév, egysár} RENDELÉS_TÉTEL {rendszám, cikkszám, rendmenny} RENDELÉS_FEJ {rendszám, vkód, kelt, határidő, összérték} VEVŐ {vkód, vevőnév, vevőcím} Végül lássuk be, hogy a függőségek megmaradtak az adatbázisban, mégpedig az egyes táblákon belül, mivel „a kulcs egyértelműen meghatározza a tábla összes tulajdonságát”. Tehát, ha normalizált adatbázist látunk, akkor a függőségi családot kiolvashatjuk az egyes táblákból. Ezen függőségekből továbbiakat tudunk bármikor származtatni a funkcionális függőségekre vonatkozó szabályok szerint (az előző fejezetben ezt tettük). Megjegyzés: A harmadik normálformán túl már nem algoritmizálhatók a teendők; csak az elmélyült tervezői agy képes a redundancia csökkentését optimalizálni a funkcionális függőségek megtartása mellett. Azért nem tanulunk magasabb normálformákról és annak érdekében több speciális függőségről, mert azok elérése nem lehet mindig cél. Halassy Béla szerint az adatbázis-tervezést jól csinálni csak megszállottan lehet és hivatásként szabad űzni.

Kulcsszavak a fejezetben: 1NF, 2NF, 3NF, normalizálás.

Autósbolt Egy régi típusú autósbolt (nincs számítógépes számlaadás, az egységárak nem változnak, csak a napi alkatrészenkénti összforgalmat regisztrálják, a napi árbevételből adott összeg marad a kasszában, a többit befizetik) nyilvántartását végezzük el az alábbi napi forgalom kimutatás alapján.

Dátum Alkatrésznév Alkatrészkód Egységár Darab 88.02.03 kuplung TX-5 1500 2 elosztófej XB-3 150 6 kondenzátor ET-2 30 4 fékhenger F-6 120 1 Összérték: 4140 Befizetés: 3140

Legyenek a tulajdonságok: DÁT; ANÉV; AKÓD; EÁR; DB; ÖÉRT, BEFIZ. Az alábbi relációt állítjuk össze: AUTÓSBOLT {DÁT, ANÉV, AKÓD, EÁR, DB, ÖÉRT, BEFIZ} Írjunk mintasorokat az adatbázisra mindjárt 1NF-ben: (a minta-bizonylat alapján írjunk be sorokat az adatbázis egyetlen táblájába)

DÁT ANÉV AKÓD EÁR DB ÖÉRT BEFIZ 88.02.03 kuplung TX-5 1500 2 4140 314088.02.03 elosztófej XB-3 150 6 4140 314088.02.03 kondenzátor ET-2 30 4 4140 314088.02.03 fékhenger F-6 120 1 4140 314088.02.04 fékhenger F-6 120 1 4620 362088.02.04 kuplung TX-5 1500 3 4620 362088.02.05 elosztófej XB-3 150 2 3600 260088.02.05 vízpumpa P-12 1100 3 3600 2600

Határozzuk meg a tábla kulcsát (természetesen a feladat specifikációban meg kell erősíttetni azon sejtésünket, hogy a napi tételes forgalom alapján a dátum és alkatrészkód egyedi). Kulcs = {DÁT,AKÓD} A kulcs valóban meghatározza az összes többi tulajdonságot, de további függőségek is fennállnak: {DÁT}→{ÖÉRT}→{BEFIZ} {AKÓD}→{ANÉV, EÁR} {DÁT, AKÓD}→{DB} Tehát:

• a másodlagos attribútumok nemcsak a kulcstól függnek, hanem annak részhalmazaitól is (részleges függőségek);

• van benne tranzitív függőség. A fenti teljes függőségek alapján azonnal 3 táblára kell bontani az autósboltot, melyek mindegyikében a kulcs mellé csak a kulcstól teljesen függő leírók kerülnek, majd azt a táblát bontjuk ketté, amelyben az egyik leíró egy másik leírótól függ. A felbontás sémája:

DÁT AKÓD

DBÖÉRT→BEFIZ ANÉV EÁR

1. Lesz egy tábla, melynek a kulcsa a DÁT és leírói az ÖÉRT, BEFIZ. 2. Lesz egy tábla, melynek a kulcsa az AKÓD és leírói az ANÉV, EÁR. 3. Lesz egy tábla, melynek a kulcsa az eredeti DÁT és AKÓD, leírója a DB. Nevezzük el a táblákat (tetszőlegesen): NAPIFORG, ALKATRÉSZ, ELADÁS Mintasorokkal illusztráljuk, hogy már csak az elsőben van redundancia: NAPIFORG{DÁT,ÖÉRT,BEFIZ}

DÁT ÖÉRT BEFIZ 88.02.03 4140 3140 88.02.04 4620 3620 88.02.05 3600 2600 88.02.06 4620 3620

Ez a táblázat 2NF-ben van, de nincsen 3NF-ben (BEFIZ függ az ÖÉRT-től). A redundanciát az okozza, hogy ha többször alakul ki ugyanaz az árbevétel, egy helyett többször tároljuk le, mennyit kell belőle befizetni. (Figyelem, ha nem

ilyen egyszerű algoritmussal számolható a befizetendő összeg, akkor pláne tárolni kell.) Bontsuk fel két táblázatra: {DÁT}→{ÖÉRT} alapján például ÁRBEVÉTEL nevű táblára, {ÖÉRT}→{BEFIZ} alapján például BEFIZETÉS nevű táblára. ÁRBEVÉTEL{DÁT,ÖÉRT}

DÁT ÖÉRT 88.02.03 4140 88.02.04 4620 88.02.05 3600 88.02.06 4620

BEFIZETÉS{ÖÉRT,BEFIZ}

ÖÉRT BEFIZ 4140 3140 4620 3620 3600 2600

ALKATRÉSZ{AKÓD,ANÉV,EÁR}

AKÓD ANÉV EÁR TX-5 kuplung 1500 XB-3 elosztófej 150 ET-2 kondenzátor 30 F-6 fékhenger 120 P-12 vízpumpa 1100

ELADÁS{DÁT,AKÓD,DB}

DÁT AKÓD DB 88.02.03 TX-5 2 88.02.03 XB-3 6 88.02.03 ET-2 4 88.02.03 F-6 1 88.02.04 F-6 1 88.02.04 TX-5 3 88.02.05 XB-3 2 88.02.05 P-12 3

A négy táblázat mindegyike 3NF-ben van. Az AUTÓSBOLT adatbázisban fennálló kapcsolatok nagyvonalú ábrázolása:

ALKATRÉSZ ← ELADÁS → ÁRBEVÉTEL → BEFIZETÉS (A normalizálással 4 új tábla keletkezett, de az adatbázis nevét meghagytuk.) Figyelem!

• Megmaradtak a funkcionális függőségek • Megszüntettük a redundáns adattárolást • Eltüntettük a karbantartási anomáliákat

Az utóbbi bizonyítására tekintsük az 1NF-es AUTÓSBOLT-ban fennálló tárolási káoszt, mely káoszt okoz a karbantartásban és lekérdezésben egyaránt. Majd vessük össze a normalizált 4 táblás adatbázissal, melyben nem fordulhatnak elő karbantartási anomáliák:

DÁT ANÉV AKÓD EÁR DB ÖÉRT BEFIZ 88.02.03 kuplung TX-5 1500 2 4140 314088.02.03 elosztófej XB-3 150 6 4140 314088.02.03 kondenzátor ET-2 30 4 4140 314088.02.03 fékhenger F-6 120 1 4140 314088.02.04 fékhenger F-6 120 1 4620 362088.02.04 kuplung TX-5 1500 3 4620 362088.02.05 elosztófej XB-3 150 2 3600 260088.02.05 vízpumpa P-12 1100 3 3600 2600

1. Módosítás

Ha módosítani kell egy alkatrész nevét, akkor végig kell nézni a táblát, és minden sorban, ahol a keresett alkatrész előfordul, ki kell cserélni a nevet. Ez a folyamat hosszú, és ha félbeszakítják, akkor

• egy komolytalan adatbázis-kezelőben félig új, félig régi adat maradna, ami lekérdezéskor okoz gondot,

• egy komoly adatbázis-kezelőben visszagörgetik a tranzakciót (nem módosítanak azonnal) és egy szabadnapon tudják csak lefuttatni az elmaradt tranzakciókat

Normalizált esetben egyetlen helyen (Alkatrészben) kell csak módosítani, ami azonnal végrehajtódhat.

2. Bővítés

Ha fel szeretnénk vinni egy új alkatrészt minden törzsadatával, hogy legközelebb már az elérhető alkatrészek között szerepeljen, nem tehetjük meg, mert jelen adattáblában csak tényleges eladásokból születhetnek sorok. Vagyis, amíg el nem adtunk belőle, fel sem vihető. Normalizált esetben csak a törzs (Alkatrész) bővülne, és legfeljebb nem születne hozzá azonnal egy sor az Eladás-ban. A legközebbi eladáskor már elérhető lenne a többi alkatrésszel együtt.

3. Törlés

Ha épp egy olyan sort kell kitörölni, melyben egy alkatrész először szerepelt, akkor elveszítjük az alkatrész törzsadatait is. Normalizált esetben egy eladás-sor kitörlésével nem veszítjük el az alkatrész törzsadatait, mert a törzsben ott maradnak.

Típuspélda Ebben a fejezetben egy kész, normalizált adatbázist értelmezünk, majd bizonyos függőségek érvényességéről fogunk dönteni. Készítünk mintasorokat az adatbázisra, majd egy kimutatáshoz gyűjtjük össze az adatokat. Végül olyan sorokkal bővítjük az adatbázis tábláit, melyek egy előírt eseményt tükröznek. Rendelésteljesítés Egy cég rendeléseket vesz fel dátum időpontra a raktárán lévő alkatrészekből összeszerelhető termékeire. A vevő nem regisztrált.

kódTERMÉK

névár

azonALKATRÉSZ

nevem_egysegys_árkészlet

kódazon

SZERKEZETmennyi

azon

kód

rend_számkód

RENDELÉSdarabdátum

kód

A rövid leírás és a kapcsolati ábra szerint a következőket lehet tudni: Minden Terméknek van kódja, neve és aktuális ára; minden Alkatrésznek van azonosítója, neve, mértékegysége, aktuális egységára és pillanatnyi készlete. A Termék törzs kulcsa (a kód) külső kulcsként megtalálható a Szerkezetben, illetve az Alkatrész kulcsa (az azon) is külső kulcs a Szerkezetben. A 2 törzs közti viszonyt a Szerkezet kapcsolótábla oldja meg, amiben tárolásra kerül, hogy bármelyik egységnyi termékhez melyik alkatrészből mennyi szükséges annak mértékegysége szerint. A Rendelés valójában rendeléstétel-tábla, mert a kulcsa nemcsak a rendszám (és benne nem a bizonylat fej- és lábléc-adatai vannak), de mivel semmilyen rendelésfejbe illő adatot nem tárolunk, Rendelés

a neve. Ebbe a rendelés alkalmával generált rendszám mellé különféle termékkódokat vihetünk fel, amelyekről azt tároljuk, hogy hány egységet és mikorra kérik. A kapcsolatban álló táblák között nyíl látható, mely mindig a sokból mutat az egybe (rajta pedig a kapcsoló tulajdonság helyezkedik el). A függőségi család pedig ugyancsak kiolvasható az adatbázis tábláiból, miután minden táblán belül a kulcs meghatározza a többi tulajdonságot:

{kód} → {név, ár} {azon} → {neve, m_egys, egys_ár, készlet} {kód, azon} → {mennyi} {rend_szám, kód} → {darab, dátum}

Láttuk az előzőekben, hogy meglevő függőségekből újakat lehet származtatni, és egy függőségről el lehet dönteni, hogy következik-e a meglevőkből. Fennállnak-e az alábbi egyértelmű meghatározások?

• {rend_szám, kód} → {név, ár} igen; a bal oldal meghatározza önmaga részeit, tehát a kódot is, ami pedig meghatározza a nevet és árat

• {rend_szám} → {darab} nem; a bal oldal semmit sem határoz meg egyértelműen (a darabhoz szükséges a rend_számon túl a kód is)

• {azon, kód} → {név, neve, mennyi} igen; a bal oldal egyik tagja az alkatrész nevét, másik tagja a termék nevét, a két tag együtt pedig a szerkezet mennyiségét határozza meg

• {dátum, kód} → {rend_szám} nem; egy napra ugyanabból a termékből többen is rendelhettek, vagyis a rend_szám nem egyértelmű (csak a rend_szám és kód ismeretében biztos a dátum)

• {rend_szám, kód} → {készlet} nem; a készlethez ismerni kell az azonosítót, ami nincs a bal oldalon, és a bal oldal semmilyen része sem határozza meg az azonosítót (rend_számtól függetlenül bármelyik terméknek több alkotója lehet a szerkezet alapján, tehát nem egyértelmű az alkotó aktuális készlete)

Készítsünk mintasorokat az adott adatbázisra! A legfontosabb megszorítás az, hogy az egyes táblákban a kulcstartalom csak egyszer fordulhat elő (összetett kulcs esetén az összefűzött jelsorozat egyedi), majd az adatbázis épsége miatt a külső kulcsok tartalma csak olyan érték lehet, ami már létezik abban a táblában kulcsként, ahova mutat.

kód név ár 111 termék1 2000123 termék2 2000134 termék3 15000141 termék4 45000156 termék5 1890176 termék7 5600

RENDELÉS

rendszám kód darab dátum 977889 123 3 97.02.12 977889 134 1 97.02.12 977890 156 2 97.02.23 977891 134 1 97.03.11 977891 141 5 97.02.23 977891 176 3 97.02.23

ALKATRÉSZ

azon neve me eár készl 12333 alkatrész12 kg 1200 30 23230 alkatrész23 l 90 12 34555 alkatrész34 db 450 21 44555 alkatrész44 m 5600 19 56789 alkatrész56 kg 380 120 87900 alkatrész87 g 12 51

SZERKEZET

kód azon mennyi 123 56789 2.50123 34555 0.25134 12333 1.30134 56789 3.00134 44555 0.75134 23230 0.10

A mintasorokból kiolvasható, hogy pillanatnyilag:

• 7-féle terméket és 6-féle alkatrészt tartunk nyilván; • a 123-as termék 2, a 134-es pedig 4 alkotóból áll; • az 56789-es alkatrész 2 termékbe is beépül; • valójában 3 rendelés tételeit látjuk: a 977889-es rendelésszámon 2

terméket, a 977890-esen 1-et és a 977891-esen 3 tételt kértek; • a 134-es termékről 2 megrendelés is szól; az egyik 97.02.12-re 1

db, a másik 97.03.11-re 1db;

TERMÉK

• minden alkatrészből NULLánál nagyobb készlet van a megfelelő mértékegység szerint;

• valójában a termék- és alkatrésznevek semmitmondóak, de szintén egyediek.

Lehetséges kimenet a mintasorok alapján: A ’97.02.12 - re rendelt termékek alkatrészigénye :

1.3 kg alkatrész12 0.1 l alkatrész23 0.75 db alkatrész34 0.75 m alkatrész44 10.5 kg alkatrész56 Ennek önköltsége : 10096.50 Ft Várható árbevétel : 21000.00 Ft

Az adatbázisból (mintasoraitól függetlenül) sokféle lekérdezést készíthetünk, egyelőre saját algoritmusunkat követve, mely inkább a hagyományos fájlkezelést imitálná, mint az SQL nyelvet. Pl.:

• melyik termékből rendelték eddig a legkevesebbet • adott napra miből mennyit kell elkészíteni • melyik alkatrész a leggyakoribb az alkotók között • adott termékből maximum hány készíthető el a pillanatnyi készletek

alapján • a holnapra elkészítendő megrendelésekhez mennyi hiányzik a

szükséges alkotókból • az egyes termékek által hozott haszon (árbevétel-önköltség) • a legdrágább termék • a legköltségesebb termék • minden termék legdrágább alkotója • a legforgalmasabb nap (amikorra a legtöbb megrendelés szólt) • az a nap, amikorra csak egyféle terméket kellett készíteni • mihez kell egy adott nevű alkatrész • mi a szerkezete egy adott nevű terméknek

(A lekérdezéseket a következő félévben SQL-ben meg fogjuk tudni oldani.) Bővítsük a fenti adatbázist (legyen CUKRÁSZDA) azokkal a mintasorokkal, amelyek a következő eseményt tükrözik: „A mai napon két vevő is rendelt holnapra 1 Dobostortát, de az egyik még 2 adag Sarokházat is kért.”

A feladat 2 termékről és 2 rendelésről szól, melyből az egyik 1, a másik 2 tételből áll. A 2 termék receptje nem került említésre, ezért tetszőlegesen készítjük azt el. (Az az információ, hogy a mai napon vesszük fel a rendelést, nem tárolódik, hiszen fizikai sorrendben kerülnek fel a rendeléstételek, melyek elkészülésének csak a dátuma lényeges az ügyvitelben.)

A termékek (cukrászkészítmények) kódját mi generáljuk, az árat tetszőlegesen választjuk:

kód név ár 101 Dobostorta 2200106 Sarokház 550

A recept leírásához előbb az alkotókat kell felvenni, melyek leíróinak értéke ugyancsak tetszőleges:

azon neve me eár készl 12345 cukor kg 180 30 23456 liszt kg 90 42 34567 tejszín dl 110 20 45678 csokoládé dkg 5 100

A recept legyen (természetesen már létező termékkódokkal illetve alkatrész-azonosítókkal) pl.:

kód azon mennyi 101 12345 1.00101 23456 1.00101 45678 5.50106 34567 5.00106 45678 15.00

A rendeléstételek (ha pl. a mai dátum 2001.12.09.):

rendszám kód darab dátum 018821 101 1 01.12.10 018821 106 2 01.12.10 018822 101 1 01.12.10

Kulcsszavak a fejezetben: mintasorok készítése.

Adatbázis bővítése A fejezet célja, hogy meglévő adatbázis átalakítására egyfajta gondolatmenettel szolgáljon. A technika nem a számonkérés része, de mindenképpen hasznos átvenni az adatbázisok értelmezése miatt. Étterem A rendszer nagyvonalú ismertetése: Az étteremben különféle ételeket és italokat rendelhetünk, amelyeket bizonyos nyersanyagokból, recept szerint készítenek el. A fogyasztás végén számla alapján fizetünk. Az adatbázis hétköznapi, az ügyvitel egyszerű, mindenki számára elképzelhető.

ANYAG tábla a nyersanyagok törzse; pl. ’12345’, ’rétesliszt’, 120, ’kg’ ÉTLAP tábla az ételek törzse; pl. ’122333’, ’Vadas marha’, 750, ’K’ FAJTA tábla az ételek fajtájának szótára; pl. ’F’, ’frissensült’ RECEPT tábla az ÉTLAP és ANYAG kapcsolótáblája, az ételekbe beépülő anyagok mennyiségével; pl. ’555556’, ’54321’, 0.25 SZÁMLAFEJ tábla a számlák törzse; pl. ’2003/3334’, 03.05.23., 4560 SZÁMLATÉTEL tábla az ÉTLAP és SZÁMLAFEJ kapcsolótáblája, a számlákon szereplő ételek mennyiségével; pl. ’2003/1224’, ’444456’, 2 A kapcsolatok ügyesen kiolvashatók az ábrából. (Minden nyíl a külső kulcsról mutat az egyedi kulcsra (bekarikázva), azaz a sokból az egybe.) A kapcsolatok nyelvtani megfelelője:

• egy fajtára több étel is készülhet • egy étel több anyagból épülhet fel recept szerint • egy anyag több ételbe beépülhet

• egy számlán több ételt rendelhettek ( itt nem adagot, hanem ételféleséget)

• egy étel több számlán is szerepelhet Az ügyvitel folyamatainak áttekintése: Itt "végigzongorázzuk" a folyamatokat (mint pl. étlapkészítés, termékdefiniálás, rendelésfelvétel, számlaadás, forgalomkimutatás stb.), miközben technikai adatokkal toldjuk meg az adatállományainkat. Ilyenek pl. 1, az ÉTLAP van logikai mezeje, hiszen ettől függ, mely étel-ital van éppen étlapon. 2, a SZÁMLAFEJ kifizet logikai mezeje, hiszen ennek állapota utal arra, hogy ki van-e már fizetve a számla.

• Termékdefiniáláskor például nemcsak az ÉTLAP bővül egy sorral, hanem

a RECEPT is akár több sorral, ill. az ANYAG, ha eddig még ilyen nem szerepelt. A FAJTA ugyancsak bővülhet, ha új ételtípust definiálunk.

• Az étlapkészítés valójában egy lekérdezés, amit segít majd egy szezontól / szakácstól függő beállítás (van-e).

• Egy rendelés felvétele nem egy funkció, hiszen a rendelést elkezdik, folytathatják és kifizetik. Felvitelkor egy sor születik a SZÁMLAFEJben és legalább egy sor a SZÁMLATÉTELben. A számlaszám generált azonosító, a végösszeg csak a kifizetéskor kerül be. Ha a vendég folytatja a rendelését, akkor meg kell találni a nyitott számlák között az övét, illetve régi tételének módosítását vagy új tétel felvitelét végrehajtani. Ezért legalább a számlák lezárását (kifizetve_e) be kell jegyezni az adatbázisba.

• A számlaadás valójában egy számla lezárását jelenti: a végösszeg kiszámítását követő sor-módosítást és egy tételes lekérdezés nyomtatását.

• A forgalomkimutatás valamilyen statisztika lekérése, mindig egy lekérdezés eredményét jeleníti meg. Pl. napi árbevétel, legjobban fogyó ételek, legsikeresebb ételfajták, stb.

Ne felejtsük el, hogy az adatbázis épségének megőrzése a hivatkozási- és adatintegritás betartásával történik (Ilyenek a külső kulcsok értékei vagy a mennyiségek korlátozása nagyobb, mint NULLára.). Ezeket minden adatbáziskezelő automatikusan betartja, ha gondoskodunk róla a megszorítások definiálásakor. (Megszorításokat ld. később)

Az adatbázis bővítése Beszerzés Legelőször az ANYAG tábla karbantartása tűnik felületesnek. Eddig nyom nélkül bővült a tábla. Tehát általában kell egy BESZERZÉS tábla, ami a "mikor-miből-mennyit-mennyiért" információt tárolná: BESZERZÉS{akód, dátum, beár, menny} De ezzel együtt felveszünk az ANYAGba egy aktuális készlet tulajdonságot, amelyhez beszerzéskor hozzáadjuk a menny-t a konkrét anyag esetén, rendeléskor pedig levonjuk a rendmenny∗szüksmenny szorzatot a recept által előírt összes hozzávaló esetén. ANYAG{akód, név, egysár, mértegys, készlet} Figyelem: a készlet módosítása előtt súlyozott átlagárat kell számolni, hogy az anyag aktuális készlete mellett mindig annak a „mibekerülési” ára szerepeljen. Javasolt funkció: a megrendelő bizonyára ilyenkor minden olyan ételnek megváltoztatná az árát, amibe az éppen megváltozott egységárú anyag beépül. Az ANYAG - BESZERZÉS kapcsolat 1:N.

Megjegyzés: ebben az esetben is bizonylatolhatnánk, mint a „számlaadás”-t. (Ekkor a bejövő számlák fejét és tételeit tartjuk 2 táblában. A BESZERZÉS dátuma a fejbe, a többi adata pedig a tételek közé kerülne. A bejövő számlák számlaszáma nem biztos, hogy egyedi, ezért belső generált azonosítóval látjuk el.) Személyzet Igény lehet a személyzet nyilvántartására, hiszen amint róluk is tud a rendszer, azon nyomban lehetőség nyílik a forgalom pincérekre való lebontására, vagy az árbevételtől függő szakács-bérezésre. Az normalizálás lépései szerint haladva jutunk az alábbi relációkhoz:

SZEMÉLY{kódszám, neve, poszt} BEOSZTÁS{poszt, jelentés} A kapcsolat:1 beosztáshoz több személy tartozhat. A személyek (beosztásukat tekintve pincérek, szakácsok, kukták, zenészek stb.) közül csapatok alakulnak, akik egy adott napon együtt dolgoznak, és mivel egy személy több napon dolgozik, a SZEMÉLY – CSAPAT kapcsolat 1:N. CSAPAT{dátum, kódszám} Ekkor már a napi árbevétel előírt százaléka kiosztható például egyformán a kukták között, további százalék a szakácsnak stb. Ha a pincéreket viszont nem egyformán díjaznák, akkor rögzíteni kell naponta, mennyit dolgoztak (mely tételeket hordták ki ténylegesen). A forgalom pincérhez kötése az „asztalon keresztül” történik, ui. naponta a felszolgáló pincérekhez rendeljük a sorszámozott asztalokat. Ám ne felejtsük el, hogy ebben az esetben a számlán az asztalt fel kell tüntetni. Ennek oka az alábbi funkcionális függőség: {dátum, sorszám}→{kódszám}, ahol a sorszám az asztal egyedi azonosítója. Megjegyzés: nem igaz viszont, hogy a dátum és kódszám meghatározná a sorszámot (ui. adott napon egy pincér több asztalt kap). Az új egyedek a következők: ASZTAL{sorszám, hányfős} KISZOLGÁL{dátum, sorszám, kódszám} A CSAPATból csak bizonyos kódszámok kerülnek a KISZOLGÁLba (most a pincérek), és ott többször szerepelhetnek, mivel 1 személyhez több asztal is tartozhat egy bizonyos napon. A kapcsolat tehát 1:N. Számla - pincér kapcsolatot létesít a sorszám felkerülése a számlára: SZÁMLAFEJ{szlaszám, dátum, végösszeg, sorszám} Így egy kiszolgáláshoz több számla tartozhat (adott napon adott asztalnál több számla születik). Ha valaki felhasználói oldalról közelíti ezt a kérdést, akkor gondoljon arra, hogy egy nyitott számla tételeinek folytatása esetén mit tesz a pincér: lekéri az ő kódszámához tartozó ki nem fizetett számlákat? Nem, mert több olyan is lehet. Asztal-sorszámot kér, melyhez csak egy nyitott számla van. További kapcsolat: 1 asztalnál több számla készül.

A végleges adatbázis ábrázolása:

Áttekintő kapcsolati ábra

(tulajdonságok nélkül és minden felállítható kapcsolattal) Fontos: A hivatkozási épség megőrzése azt jelenti, hogy a 1 KISZOLG-sor 1 CSAPAT-tagra mutat, ami majd 1 SZEMÉLY-re. Ezt a külső kulcsok felállításával érjük el. Itt nem elég egy létező személyre hivatkozni a kiszolgálásban, annak ellenére, hogy a KISZOLG:SZEMÉLY kapcsolat él, és valamely lekérdezés esetén akár kihagyható lesz a CSAPAT. Továbbá másik szabályt is be kell állítani, miszerint csak olyan csapattagokra mutathat bármelyik kiszolgál-sor, amelyhez tartozó személy beosztása pincér.

Csak ők kapnak asztalokat. Az erről való gondoskodást (megszorítás megadásával) a későbbiekben tanuljuk meg. Ugyanígy egy SZFEJ a KISZOLG-soron keresztül mutasson egy ASZTALra. Vagyis a SZFEJ-sor adott dátuma mellett nem akármelyik asztal állhat az ASZTAL sorai közül, hanem csak olyan, amit egy pincérhez hozzárendeltek aznap a KISZOLGban. Csak valamely lekérdezés során hagyható el a KISZOLG a SZFEJ és ASZTAL mellől, mert a kapcsolat eredeti definíciója szerint ez megtehető. Utószó A rendszer még nem piacképes, hiszen nem kezeli például az asztal megbontását, a műszakban dolgozást, nem bizonylatolja a beszerzést. Az utóbbiról már esett szó, az első miatt az adatbázis könnyen átalakítható, de a második igény utólagos átvezetése már nehézkes. Ahhoz, hogy az asztaloknál párhuzamosan több nyitott számla futhasson, elegendő az asztal sorszámoknál megengedni 1 betűkarakterrel többet (pl. 2A, 2B). Elképzelhető, hogy élesben csak a számlában engedjük ezt meg, ahol tehát az utolsó karakter előtti jelsorozat mutat csak a KISZOLGra (erről így csak egy formás megszorítással gondoskodhatunk, nem külső kulcs segítségével). Természetesen eddig sem zártuk ki, hogy 2 számlaszám legyen nyitva egyazon asztal-sorszámhoz, csak éppen akkor zavaros lesz bármely rendelés folytatása annál az asztalnál. Adatbázisunkban egy napon egy személy egyszer jöhet be dolgozni. A napi árbevételen együtt osztoznak, tehát egy műszakról van szó. Amennyiben több műszak is lehet egy napon, akkor nem napi, hanem műszakonkénti árbevételt kell tudni számolni. Ekkor a műszakot (egyszerű sorszám) fel kell ismerni a SZFEJben, amiről a CSAPATban, esetleg KISZOLGban kell gondoskodni. Ha a CSAPATban csak leíróként szerepel a műszak, mert egy nap egy személy csak egy műszakban dolgozhat, akkor a kapcsolódó 2 tábla nem változik. Ha viszont egy csapattag „hosszúzhat”, akkor a műszak kulcs-szerepű, ami azt is jelenti, hogy a KISZOLG dátuma mellett (a kulcsban), illetve a SZFEJ dátuma mellett (leíróként) ott fog szerepelni a műszak is.

ADATBÁZISBELI SZABÁLYOK Ebben a fejezetben tisztázzuk a megszorítás fogalmát, mely az adatbázis kezelésére előírt valamely szabály beépítése az adatbázisba. Most készülünk fel arra, hogy az SQL-alapú adatbázisokban hogyan lehet biztosítani az előírt szabályok és folyamatok érvényesítését. A NULL-érték Minden logikai függvény ill. feltétel előtt tisztáznunk kell egy fontos, adattípustól független érték, az ismeretlen érték fogalmát. Az SQL-alapú adatrendszerek standard adattípusait (számszerűek, karakteresek, logikai, dátumtípusúak) és alapműveleteiket megismertük az Adatbáziskezelés I. tárgy keretében. Vannak esetek, amikor az adatbázis egyes mezőibe nem tudunk határozott értéket elhelyezni, ezért határozatlan tartalmúnak tekintjük. Szerencsétlen angol kifejezéssel: a mező tartalma NULL-érték (nem létező, ismeretlen érték). Adattáblák oszlopaira megtilthatjuk az előfordulását. A NULL-értéket tartalmazó kifejezések eredménye is ismeretlen lesz (kivétel a logikai vagy-művelet, melynek ha az egyik tagja igaz, akkor az eredmény már igaz). Példa: Adott a köv. tábla egy olyan adatbázis részleteként, melyben a diákok feladataik megoldására kapott pontokat tároljuk, ill. a plusz-pontokat, ha további, merőben más megoldásuk is értékelhető volt. MEGOLDÁS {diák_kód, feladat_szám, pont_érték, plusz_pont} Jelen esetben világos, hogy a leírók közül a pont_érték bizonyára korlátozandó: legalább NULLa és legfeljebb egy előírt (másik táblában tárolt) érték. A plusz_pont pedig értelemszerűen NULLa is lehet. Abban az esetben, ha egy/ az összes diák összteljesítményét kellene kiszámolni, akkor a pont_érték+plusz_pont aritmetikai összegeket kellene összegezni (pl. SUM függvénnyel az SQL-ben) adott diák/ az egész tábla soraiban. Nos, ha valaki nem kapott plusz pontot, mert nem is volt második megoldása, akkor a mezőt nem hagyhatjuk kitöltetlenül, mert az összeg ismeretlenné válna. Tehát a plusz_pont nem lehet NULL; alapértelmezett értéke pedig lehetne NULLa.

Megszorítások A megszorítás fogalma után a megszorítások csoportosítását ismerjük meg. Itt fogjuk megtanulni, hogy az adatbázisban hol és hogyan lehet gondoskodni bizonyos feltételek érvényre juttatásáról. Az adatbázis kezelésének ellentmondásmentes ügyvitel szerint kell működniük, ezért az adatokra és az eseményekre vonatkozó szabályokat érvényesíteni kell az adatbázisban. Azért, hogy semmilyen adatkezelési esemény ne vezessen az adatok következetlenné válásához, az összes előírást és korlátozást be kell építeni az adatbázisba. A beépítésre került szabályt megszorításnak nevezzük. A biztonságos adatbáziskezelés tehát a megszorításokkal körülvett adatbázis kezelését jelenti. A szabályok és adatfolyamatok együttesét üzleti logika fedőnéven is emlegetik. Az SQL nyelv napjainkban már olyan lehetőségekkel rendelkezik, melyek segítségével programozás nélkül érvényesíthetjük az előírt szabályokat, vagyis megszorításokkal is bővíthetjük az adatbázist. Idén a megszorításokat elegendő verbálisan – ugyanakkor logikailag helyesen -megfogalmazni; a köv. félévben próbálkozhatunk mindezek SQL-beli megadásával. A megszorítások logikai értékű függvények, amelyektől elvárjuk, hogy igazak legyenek. Az olyan módosításokat, amelyek a megszorításokat megsértik, a rendszer visszautasítja. A megszorítások lényege a hivatkozási épség és az adatösszefüggések felügyelete minden adatkezelés alkalmával. A hivatkozási épség megőrzése az egyedi kulcsok és külső kulcsok felállításával indul, de arról is gondoskodni kell, mi történjen a kulcsérték módosítása / törlése esetén a külső kulcs értékével. Ezen kívül a rejtett kapcsolatban álló táblák esetén is léteznek olyan hivatkozások, amiket nem lehet külső kulcs megadásával biztosítani. Az adatösszefüggések közé tartoznak: • az olyan egyszerű feltételek, mint adott mező nagyobb NULLánál, vagy a

mező nem lehet NULL értékű; • meg az olyan bonyolult feltételek is, mint adott mező kisebb, mint egy

aktuális –, akár több táblából – számított érték. Valójában már a mezők adattípusának meghatározásával korlátozásokat állítunk fel, de ezeket az alapvető szabályokat nem nevezzük megszorításoknak.

Az olyan egyszerű feltételek, amelyek egy tábla egy sorát érintik, könnyen beépíthető megszorítások. Ilyen esetben a táblába történő beszúrást ill. módosítást utasítja vissza a rendszer, ha a megszorítás nem érvényes. Az olyan megszorítások, amelyek több sort vagy több táblát érintenek, a szó igazi értelmében összetettek. Ezek beépítése egy táblába helytelen, ui. csak ebbe a táblába való felvitel/ módosítás váltja ki a megszorítás ellenőrzését. Ha ilyen megszorítást egyszerűen csak abba az egy táblába építenénk be, melynek valamely mezőjére fogalmaztuk meg, akkor a feltételben érintett másik sor vagy másik tábla sorának esetleges törlése esetén a feltétel elromolhat. Tehát önálló megszorításként érdemes megadni, ha azt szeretnénk, hogy az összes érintett táblában történő karbantartás esetén érvényben maradjon. A megszorításokat a következő sorrendben célszerű felállítani: • kulcsok megadása • tulajdonság-értékekre vonatkozó korlátozások • önálló megszorítások Az egyedi kulcsok megadása és az elsődleges kulcs kiválasztása Csak egyetlen elsődleges, de akár több egyedi kulcsa lehet a táblának. Elsődlegesnek azt választjuk az egyediek közül, amire máshonnan hivatkozni kell. Ezek a kulcsok természetesen nem vehetnek fel ismeretlen értéket. (NOT NULL) miután értékükkel csak egyszer fordulhatnak elő saját táblájukban. A kulcsok definiálása a konkrét táblába építendő be. Az idegen kulcsok definiálása A hivatkozási épség biztosítása érdekében adjuk meg a külső kulcsokat, miután ezek a kapcsolat hordozói a táblák között. Hiszen egy mező külső kulcsként csak olyan értéket vehet fel, amit kulcsként már tartalmaz. Ugyanakkor egy kulcsértéket addig nem szabad törölni, amíg külső kulcsként van rá hivatkozás. A külső kulcs szerkezetének természetesen azonosnak kell lennie azon elsődleges kulcséval, melyre hivatkozik; de a kulcsot alkotó oszlopnevek egyezése nincs kikötve. Természetesen lehet több idegen kulcs is egy táblában. Figyelem: ha az idegen kulcs nem kulcsszerepű (csak leíró), akkor nekünk kell eldönteni, hogy lehet-e nem kitöltött az ügyvitel szerint (ha nem, akkor az értékére megszorítást teszünk NOT NULL-lal).

Megjegyzés: általában elegendő a kapcsolt tábla nevét megadni a külső kulcs mellett, de előfordulhat, hogy a megvalósítás megengedi az elsődleges kulcstól különböző, másik egyedi kulcsra való hivatkozást is. Arról is gondoskodni kell, hogy a szülő-tábla hivatkozott sorának törlése/módosítása esetén mi legyen a válaszlépés a gyerek-tábla hivatkozó sorában: • ismeretlen értékkel töltse fel ott is • alapértelmezett értékkel töltse fel ott is • ott is törölje ki a hivatkozó sorokat/ott is módosítsa a hivatkozások értékét

az új értékre • ne tegyen semmit az adatbáziskezelő rendszer. Tulajdonság-értékekre vonatkozó korlátozások A tábla definiálásakor a kívánt tulajdonság (mező) adattípusa után gondoskodhatunk az oszlopérték helyességéről: egész egyszerűen logikai feltétel megfogalmazásával. Például: NOT NULL mező >= 0 mező IN (’2A’, ’2C’, ’3C’) mező > 0 AND mező < 6 mező1 <> mező2 Feltételezzük, hogy a hallgatók emlékeznek az Adatbáziskezelés I. tantárgy során ismertetett adattípusokra, műveletekre és prioritásukra. Megjegyzés Ugyanitt tehetjük meg, hogy az alapértelmezés szerinti értékről (default-érték) gondoskodunk. Figyelem! A megadás ilyen elhelyezését legfeljebb sorfeltétel esetén válasszuk, mert csak abban a táblában kerül ellenőrzésre, amelybe beépítettük. Az adatbáziskezelő rendszerre bízott vizsgálatok hatása az, hogy a beszúrást és módosítást a rendszer utasítsa vissza, ha a feltétel nem áll fenn. Törölni se engedjen, ha a feltétel előírja például a sorban szereplő valamely érték létezését. Amint összetett feltételt kell megfogalmaznunk egy mezőre vonatkozóan, ne a mező táblájának definiálásakor adjuk meg, mert csak ebbe a táblába történő beszúrás/módosítás esetén kerülne ellenőrzésre. A többi érintett sor esetleges törlésével ez a feltétel hamissá válhat.

Például: mező <= SUM(másik mező) mező IN (másik tábla valamely mezője) Előfordulhat, hogy a több sort érintő feltétel olyan logikai feltételt tartalmaz, amely törlés hatására nem romolhat el. Ilyen esetben maradhat a megszorítás a táblában. Önálló megszorítások A tábla-szinten definiált megszorításokat a rendszer csak akkor ellenőrzi, ha a tulajdonság vagy tábla, melyre a feltétel vonatkozik, beszúrás vagy módosítás hatására változik meg. Ezért, hogy a több sort/több táblát érintő feltétel minden esetben igaz maradjon, önálló megszorításként adjuk meg. Ezek az önálló feltételek elkülönülnek a táblák definíciótól, és egy vagy több tábla összefüggéseit szabályozzák. Ez ilyen feltételeket a rendszer mindannyiszor megvizsgálja, valahányszor beszúrás/módosítás/törlés történik az érintett táblák bármelyikében. Például: A fenti összetett feltételeket tehát általában önálló megszorításként adjuk meg. Továbbá: [NOT] EXISTS (tábla) Megjegyzés A fogalomkörhöz tartozó domain-ek és trigger-ek hasznosságáról majd SQL-ben szólunk. Fontos: Idén a megszorítások megfogalmazása verbálisan történik, még azzal sem foglalkozunk, hogy milyen szinten definiálnánk azokat. Ennek elmélyítését szolgálja a hátralevő összes példa. Kulcsszavak a fejezetben: megszorítások, NULL-érték.

Bevezető példa: oktatás Az életből vett rendszer nagyvonalú leírását lefedő adatbázissal foglalkozunk. Egyszerű ügyvitelt feltételezve megbeszéljük, milyen üzleti logikára épül az adatbázis kezelése, azaz milyen szabályok szerint marad ép az adatbázis. Ekkor jelenthető ki, hogy az adatbázis ellentmondásmentes ügyvitelt biztosít. A rendszer ismertetése Egy iskola folyó tanévében a diákok és tanárok viszonyát tartjuk nyilván értelemszerű törzsadatokkal az órarend kialakításáig. Az egyes tantárgyakat osztályoknak tanítják a tanárok, egy osztályba sok diák jár. Egy tanár több tárgyat is taníthat, és fordítva. Ugyanannak az osztálynak több tárgyat, illetve egy tárgyat több osztálynak is taníthat ugyanaz a tanár. A nap és óra sorszámozott típusú (1-5: a napok, 1-8: az órák), a tantárgy kódja beszédes (pl. MAT4: negyedikes matematika). Kellenek a törzsek, a tanítás ténye és maga az órarend. DIÁK {azonosító, név, osztály, ...} TANÁR {kód, név, szoba} TANTÁRGY {tant, megnevezés, heti_óraszám} TANÍT {osztály, tant, kód} ÓRAREND {osztály, nap, óra, tant} Kapcsolatok: TANÁR : TANÍT 1:N TANTÁRGY : TANÍT 1:N TANÍT : ÓRAREND 1:N következmény TANTÁRGY : ÓRAREND 1:N lekérdezésnél jöhet jól, hogy az ÓRAREND közvetlenül is rámutat egy tárgyra További magyarázatot talál a videón.

Azonnal látjuk, hogy ebben az adatbázis-kezdeményben nincs osztály-törzs, és az egyes évfolyamok tematikája nincs tárolva. Ha az iskolatitkár fegyelmezetten indítja a tanévet, és azt kell berögzíteni, akkor ez az adatbázis megfelelő. Követelmények :

• egy osztályba sok diák járhat • egy tanár több osztályt taníthat • egy tanár több tárgyat taníthat • egy tanár egy osztálynak több tárgyat taníthat • egy tanár egy tárgyat több osztálynak taníthat • az órarend mind az osztály, mind a tanár szempontjából

ütközésmentes kell legyen • a heti óraszám korlátozása

Fontos megjegyzés: Az azonosító felépítése szervezői feladat, de tudnunk kell, hogy egy olyan beszédes azonosító kiosztása, amely függ az osztálytól, nem jó (pl. osztály+sorszám). Ilyen esetben azoknak, akik nem buktak meg, évente új azonosítót kellene osztani, ami rossz, mert kényelmetlen. Ilyen esetben lehet a beiratkozás éve+sorszám, vagy egy abszolut sorszám az azonosító.

A követelmények pontosítása után a következő szabályok beépítése kívánatos:

1. létező tantárgyat csak létező tanár taníthat 2. tanítani csak olyan osztálynak lehet, amelybe legalább 1 diák jár 3. egy osztálynak egy tárgyat egy tanár tanítja az adott tanévben 4. egy osztálynak adott nap adott órájában egy tárgyat taníthatnak 5. az órarend a tanár szempontjából is ütközésmentes (azaz a tárgyat

tanító tanár egyszerre nem taníthat több helyen) 6. adott osztálynak adott tárgyat a tárgy heti óraszámában feltüntetett

alkalommal kell szerepeltetni az órarendben 7. a tárgy azonosítójának felépítése feleljen meg az előírásnak 8. minden tantárgynak a heti óraszáma 1 és 10 közötti érték lehet 9. minden osztálynak legyen egy osztályfőnöke, de minden tanár

legfeljebb egy osztálynak lehessen a főnöke

Nem megoldott viszont: a párhuzamos osztályok tanmenetének fixálása

Ezért itt két dolog nem lerendezett:

1. az osztály értékének szabályozása az adatbevitelnél. Ez a diák esetében lehetséges (pl. csak számjegy és betűkarakter a megengedett, vagy felsorolt konkrét osztályok közül való választás), de a tanít-tábla esetében azt kell leszabályozni, hogy csak a DIÁKban előforduló

osztályhoz lehessen sort felvinni. Semmi garancia nincs arra, hogy minden osztályhoz valóban felvittek legalább 1 diákot.

2. az évfolyam leválasztása az osztályból. Az egyes évfolyamok egyforma tematikája nincs tárolva, tehát előfordulhat, hogy a TANÍT ellenőrzése után kimarad az egyik évfolyam minden párhuzamos osztályából valamelyik tárgy. Tehát csak valóban fegyelmezett előmunkálatok után rögzített tanít-tábla esetén maradhat meg ez az adatbázis. Mivel képzésünkben erőn felül (de megtérülően) foglalkozunk az adatbázistervezéssel, a 2. problémát (évfolyam-tematika) meg sem oldjuk. Az 1. probléma pedig nemcsak az osztálytörzs létrehozásával küszöbölhető ki, ha végiggondoljuk a rendszer ügyvitelét. Valószínűleg egy önálló funkcióként, nem pedig az órarendkészítési feladatok szintjén veszik fel az új diákokat (beiratkozás, új osztályok indítása). Bizonyára a tanévzárás is ilyen, hiszen akkor legalább a nem bukottakat tovább kell léptetni (osztályukban az évfolyam számát megnövelni). Tehát bízhatunk abban, hogy az összes diák az aktuális osztályával szerepel az adatbázisban ezen ügyviteli funkció idején. Az órarendkészítés tehát a tanévindítási funkció alatt elhelyezhető feladat, melynek ugyancsak van lezárása, ami után már nem módosítható. Megszorítások: Jelen adatbázis-kezdemény kulcsainak és külső kulcsainak beépítése automatikus ellenőrzéseket állít be az adatbázisban, de bonyolult szabályok figyelését csak önálló megszorítások megadásával érünk el. Nézzük, hogyan gondoskodhatunk a fenti 9 szabály betartásáról: 1. a TANÍT külső kulcsa a tant és a kód 2. a TANÍT osztály előfordul a DIÁK osztályai között 3. a TANÍT kulcsa osztály+tant 4. az ÓRAREND kulcsa osztály+nap+óra 5. naponta, óránként és kódonként 0 vagy 1 sor van az ÓRARENDben 6. osztályonként és tantárgyanként legfeljebb annyi sor van az

ÓRARENDben, ahány a tárgy heti óraszáma 7. a tantárgy azonosítójának formátuma 4 karakteren: betű, betű, betű,

számjegy, és a számjegy korlátozható 8. pl. 0< heti óraszám < 11 9. osztályfőnöki óra bevezetésével oldjuk meg a problémát A kulcsok és külső kulcsok megadását {1),3),4)} egy táblaszerkezetbe már ismerjük, SQL-megvalósítását a következő félévben tanuljuk, mint ahogy a többi egyszerű vagy összetett megszorítás SQL-megfogalmazását is.

További magyarázatot talál a videón. A 8. egy egyszerű feltétel a TANTÁRGY heti óraszámára A 7. egyszerű, mezőre vonatkozó feltétel, mely a TANTÁRGY-bővítésnél kell, hogy érvényesüljön. Az összes többi tábla tant-mezője külső kulcs, tehát csak olyan lehet, ami a törzsben létezik. További magyarázatot talál a videón.

Ezzel szemben a 2. önálló szabály kell legyen, ui. a TANÍT osztálya nem külső kulcs. Ha csak a TANÍT bővítés esetén ellenőriznénk, hogy az osztály csak olyan lehet, ami a DIÁKban létezik, akkor a DIÁKból való törlésekkel előfordulhat, hogy a feltétel elromlik; szemben a külső kulcsos hivatkozások megőrzésének biztosításával. További magyarázatot talál a videón. Az 5. biztosítása jó helyen lesz az ÓRAREND táblában, ui. csak annak bővítése/módosítása esetén kell ellenőrizni. Törléskor nem romolhat el a feltétel. Figyelem: jelen esetben az, hogy az ÓRAREND külső kulcsa az osztály+tant, önmagában nem elég a megszorításhoz, viszont szükséges a feltétel megfogalmazásához. Megjegyzés: ha a TANÍTból törlünk, akkor az itteni külső kulcs miatt lesz annak feltétele, hogy az innen is törlődjön.

További magyarázatot talál a videón. A 6. beállítása gondoskodik minden ÓRAREND-bővítés/módosítás esetén arról, hogy ne ütemezzenek le több alkalmat, mint az előírt heti óraszám. Az órarendkészítés hosszabb folyamat, az ilyen ügyviteli feladat ellátása nem a menüpontból való kilépéssel fejeződik be, tehát az órarendkészítés lezárásának (önálló funkció) feltétele lehet csak, hogy minden osztály összes tantárgya pontosan annyi sorban forduljon elő, ahány a heti óraszáma. További magyarázatot talál a videón.

Mivel általában heti egy, órarendben elhelyezett osztályfőnöki órára van igény, az osztályfőnök szerepe {9)} ebben az adatbázisban ún. osztályfőnöki óra tantárggyal megoldható. Nem a tanárban kell tárolni, hogy ő melyik osztálynak a főnöke (beleértve, hogy ez lehet nem kitöltött érték), mégcsak nem is egy lehetséges osztálytörzsben, hogy ki az osztály osztályfőnöke, hanem tantárgyként kell felfogni. Legyen az OFO rövidnév az osztályfőnöki óra azonosítója, melyet a TANÍTban tárolva az osztályfőnökség tényét rögzítjük. Külön kell az ÓRAREND-bővítéskor ellenőrizni, hogy az adott tanár csak egy osztálynak „taníthassa” ezt a „tárgyat”. További magyarázatot talál a videón. Ezek után nem nehéz megválaszolni az olyan kérdéseket, hogy mi annak a feltétele, hogy valamely táblába felvegyünk/valamely táblában módosítsunk/valamely táblából töröljünk egy sort. (Mód van ezek begyakorlására a Példatárban ill. Feladattárban.) Rejtett kapcsolatok tárgyalása A diák nem kapcsolódik tisztán másik táblához. Az osztály csak egy metszet-tulajdonság, de jelen esetben egy lekérdezés alkalmával a DIÁK és a TANÍT osztályon keresztül való összekapcsolása

jelentéssel bír: minden diák minden tárgya szerepel majd benne azzal a tanárral, aki neki azt tanítja. (ld. SQL-lekérdezés) Ha az évvégi osztályzatokat tárolnánk, akkor az egyes diákok tárgyankénti osztályzatát kellene „lerakni” pl. egy bizonyítvány-táblában. Ennek kulcsa csak akkor lehet az azonosító és tant, ha az előző évfolyamokat nem kell látni, vagyis a bukottak jegyei nem mondanak ellent a kulcsnak. Ilyen bizonyítvány-tábla érdekes viszonyban áll a tanít-táblával: BIZONYÍTVÁNY {azonosító, tant, jegy} TANÍT {osztály, tant, kód} Itt a tant metszet-tulajdonságra alapozott összekapcsolás nem hordozna jelentést, hiszen a tárgyat tanuló összes diák „összeállna” a tárgyat tanuló összes osztállyal, akkor is, ha ő nem oda jár. Ekkor azt kell észrevenni, hogy a DIÁK-BIZONYÍTVÁNY helyes összekapcsolása áll kapcsolatban a TANÍT táblával (ez viszont nem jelölhető semmilyen eszközben). Lekérdezésnél kell észnél lenni, hogy a 3 tábla csak együtt alkalmas az összekapcsolásra (ld. SQL-lekérdezés). További magyarázatot talál a videón. Tehát a Bizonyítvány sorainak felvitele alkalmával nem elegendő ellenőrizni, hogy létező diák és létező tantárgy mellé egy 1-5 közötti jegyet rögzítsünk, hanem azt is, hogy a diák azt a tárgyat tanulta-e (tanították-e neki az osztályában).

Minta feladatmegoldásra Itt 2 kisebb, de szerkezetében érdekes adatbázist ismerünk meg, melyek megszorításait kell megfogalmazni. Futár Adott futárszolgálat nyilvántartását végezzük a fővárosban. Bizonyos cégek, magánemberek, intézmények a partnereink, akik kisebb sürgős küldemények más partnerhez való eljuttatását bízzák a szolgálatra. A szolgálat minden egyes küldeményt a megrendelő megbízásából partnertől partnernek szállíttat valamelyik futárával, akit telefonon ér el. Az adatbázis:

f_szám azonosító kód cím FUTÁR KÜLDEMÉNY PARTNER CÍM f_név megrendelő név elnevezés f_tel kelt telefon kerület időpont cím utca kitől hszám kinek f_szám

Megszorítások: • kulcsok definiálása:

o jelezve, adottak a kulcsok (SSADM jelölésrendszerhez igazodva a reláció neve elválasztja a kulcsszerepű tulajdonságokat a leíró tulajdonságoktól).

o tudjuk, hogy a kulcsot mindig ki kell tölteni (csak így lehet egyedi), tehát automatikusan egyik sem ismeretlen érték.

o további egyedi kulcsok nincsenek. • külső kulcsok definiálása és értékeinek rögzítése:

o a leírás alapján határozzuk meg a külső kulcsokat (azt a tulajdonságot vagy tulajdonságok együttesét, amely másik táblának a kulcsa), és eldöntjük, lehet-e ismeretlen értékű, azaz NULL-típusú. (Az adatbázisban világossal kiemelve láthatók.) Amikor a külső kulcs is kulcsszerepű, automatikusan ki kell tölteni, de másodlagos tulajdonság esetén az ügyvitelből adódóan döntjük el, lehet-e ismeretlen érték. Egyedül a KÜLDEMÉNY.f_szám lehet NULL típusú, azaz később (egy felhasználói funkció hatására) lesz módosítva a sor ezen mezője. Ezzel a hivatkozási épség

megőrzéséről gondoskodtunk, azaz minden külső kulcs megadása esetén csak olyan érték kerülhet be, amely kulcsként már szerepel.

• egyéb leírók korlátozása (az ügyvitelből adódó szabályok

meghatározása): o küldemény.kelt >= rendszerdátum (valószínűleg nem engedhető

meg a visszadátumozás) o kitől <> kinek (egyébként semmi értelme futárt rendelni) o küldemény storno-ja: 1 órán belül lehetséges (pl. előírás szerint a

megrendeléstől számított 60 percen belül, amennyiben még futár sincs hozzárendelve, a küldemény legyen lemondható)

o elnevezés: lehet üres (a címnek magánszemély esetén nem kell. • szigorúan véve nem az adatok integritását jelenti (ui. nincs szó

számított mezőről), de az ügyvitel helyességét jelzi, hogy a pillanatnyilag dolgozó futárok száma nem nagyobb a nem kész (szolgálatban lévő + műszaki hibás) motorok számánál

• létező sor utólagos módosítása az ügyvitelből következően a

Küldemény mezőit (a futárszám megadása után) és a Partner címét illetően itt nem történhet (ilyen esetben új partnerként felvesszük az új címével)

• Küldemény törlése nem megengedett; a többi táblából pedig a

hivatkozások megsértése nélkül lehet csak törölni Megjegyzés: Az adatbázis piacképes verzóját (futárszolgálat) a következő fejezetben találjuk, ahol bemutatjuk, mit kell tartalmaznia egy megtervezett adatbázis dokumentációjának. Kellékes Adott színház egyetlen terméhez az egyes színházi darabok kellékeit tartjuk nyilván. Ilyenek pl. a korabeli bútorok, fegyverek, kosztümök, poharak, esetleg ételek, melyeket az egyes színházi darabok előadásain használnak. A kellékekből több példány is rendelkezésre állhat, de ezeket a frissítésben megfogalmazott előadásszám után cserélni, javítani, tisztítani kell. Azt, hogy az egyes példányokat a legutolsó frissítés óta már hányszor használták, a számlálóban gyűjtjük. Az adatbázis: kellék darab kelt sorszám kellék kellék darab kezdet PÉLDÁNY KELLÉK SZÜKSÉGES DARAB ELŐADÁS számláló elnevezés hány cím darab

frissítés

Megszorítások: • kulcsok definiálása

o jelezve, adottak a kulcsok (SSADM jelölésrendszerhez igazodva a reláció neve elválasztja a kulcsszerepű tulajdonságokat a leíró tulajdonságoktól).

o tudjuk, hogy a kulcsot mindig ki kell tölteni (csak így lehet egyedi), tehát automatikusan egyik sem ismeretlen érték.

o további egyedi kulcsok nincsenek • külső kulcsok definiálása és értékeinek rögzítése

o a leírás alapján határozzuk meg a külső kulcsokat (azt a tulajdonságot vagy tulajdonságok együttesét, amely másik táblának a kulcsa), és eldöntjük, lehet-e ismeretlen értékű, azaz NULL típusú. (Az adatbázisban világossal kiemelve láthatók.) Amikor a külső kulcs is kulcsszerepű, automatikusan ki kell tölteni, de másodlagos tulajdonság esetén az ügyvitelből adódóan döntjük el, lehet-e ismeretlen érték. Egyedül az Előadás-darab lehet NULL típusú, azaz később (egy felhasználói funkció hatására) lesz módosítva a sor ezen mezője. Ezzel a hivatkozási épség megőrzéséről gondoskodtunk, azaz minden külső kulcs megadása esetén csak olyan érték kerülhet be, amely kulcsként már szerepel.

• egyéb leírók korlátozása (az ügyvitelből adódó szabályok

meghatározása) o hány > 0 (fontos, hogy csak ilyen esetben vigyük fel a Szükséges

sorait) o frissítés >= 1 (minimum egy előadáson minden kellék

felhasználható, majd tisztítják, újra beszerzik, vagy javítják. o számláló <= frissítés (amint egy példány eléri a frissítést, mint felső

határt, többször nem használható, mert javítják, tisztítják, vagy egyszerűen elfogyott)

o cím, elnevezés: esetleg nem kötelezően kitöltendő • szigorúan véve nem az adatokra vonatkozó épséget jelenti, de az

ügyvitel helyességét jelzi, amikor egy ügyviteli funkció okozta módosítás feltételét fogalmazzuk meg: az Előadás-darab inputja után kiválasztott példányok száma kellékenként meg kell hogy feleljen a Szükséges-hány-nak, és ezen példányok számlálója 1-gyel meg kell, hogy nőjön.

• egy darab felvitelének lehetne az a feltétele az ügyvitel szerint, hogy

legalább egy kellék legyen szükséges hozzá (ennek megoldása mindig trükkös, miután a Szükséges hivatkozik a Darabra).

• a már előadásra került darabok és az azokhoz szükséges kellékek nem

törölhetők; a példányok sem (legfeljebb örökre maximumon tartjuk az ilyenek számlálóját); megszabott idővel előre az előadás módosítható és értelemszerűen, a hivatkozások megsértése nélkül lehet csak az ilyen és a hozzá tartozó sorokat módosítani törölni.

Megjegyzés: Az adatbázis piacképes verzója sokkal nagyobb, mert tartalmazná a konkrét kellékek közül a kosztümök (ruhák, cipők) méreteit is. Ennek viszont akkor van értelme, ha a színészek méreteit is tárolja, valamint a napi szereposztást.

Adatbázis-specifikáció Ebben a fejezetben nagyvonalúan bemutatjuk, mit kell tartalmaznia az adatbázis-specifikációnak, mely önálló fejezete a rendszerfejlesztés bármely szakaszában elkészítendő dokumentációnak. Az eredeti munka az adatbázis-tervezőtől származik, tehát ebben a képzésben nem kell készségszinten megismerni. Csak azért hasznos az elolvasása, hogy konkrét adatbázis esetén az egyes ügyviteli funkciók elképzelését segítse, amivel az adatbázisban történő adatfolyamatokat leszünk képesek végiggondolni. Futárszolgálat egy nagyváros küldeményeit továbbító diszpécserszolgálat nyilvántartása Rendszerismertetés, követelmények A futárok motorral teljesítenek szolgálatot. A küldeményeket a város valamely címén található partnerek rendelik meg, hogy valamely partnertől másik partnernek elvigyék. A küldemény felvételének pillanata és szállításának stádiuma fontos, mert a diszpécsernek tudnia kell, melyik futár éppen hol tart. Fontos, hogy a rendszer gyorsan válaszoljon arra, ki tart éppen egy adott címre. A partnerek közül több is létezhet ugyanazon a címen (ld. irodaházak esete). A futárok alapóradíját a küldemények száma további díjjal növeli. Valamilyen sűrűséggel a futárokat kifizetik. Értelemszerű lekérdezések. Pontosítások Néhány kikötés, amire a rendszert felkészítjük: • rendelésfelvétel naponta: 8-20 óra • a szabad motorokat a dolgozó futárok elosztják • a futárok munka közben felhívhatók • dolgozó futárnál egyszerre több küldemény is lehet • dolgozó futár állapota tehát:

o adott küldeményért megy (a kitől címére) o adott küldeményt visz (a kinek címére) o küldemény hiányában várakozik (az általa választott címen)

• a futár a szolgálatnak jelzi az egyes küldemények átvételét és átadását (időpontok rögzítése)

• adott naptól az óradíjak és darabárak megváltozhatnak • a futárok kifizetése máshol történik (itt nem készül bizonylat, csak

teljesítés-lista)

Az adatbázis (a kulcsok aláhúzással, a külső kulcsok pirossal kiemeltek) MOTOR {rendsz, adat1,…, kész} a motorok törzse; műszaki adatokkal és egy logikai állapotjelzővel, kész-e a szolgálatra FUTÁR {fszám, fnév, fcím, m_váll1,...} a futárok törzse, névvel, címmel, ami ugyancsak egy CÍMre mutat, valamint munkavállalási adatokkal CÍM {cím, elnev, ker, utca, hsz} a címek törzse, melyben az elnevezés csak irodaházak és vegyes intézmények esetén kitöltött (magánszemély lakcímének nincs neve), a kerület, utca és a többi kötelezően kitöltendő PARTNER {kód, név, tel, cím} a partnerek törzse, akik megrendelik, akiktől elszállítják és akiknek kiszállítják a küldeményeket; mindegyik egy CÍMre mutat KÜLDEM {azon, megrend, kelt, időpont, kitől, kinek, fszám, átvét, átad} a kelt+időpont-ban felvett küldemények törzse, melyek mindegyike sorszámot kap, a megrendelő szerint megadott kitől kinek szállítja egy futár és a felvétel illetve leadás időpontjával jelzi a szállítás stádiumát DOLGOZ {dátum, mettől, fszám, meddig, rendsz, ftel, cím, szám} az egyes futárok munkaidejének (adott dátummal mettől meddig) tárolása az aktuális motorral, pillanatnyi telefonszámmal (amin elérhető), a pillanatnyi címmel (aminek a közelében tartózkodik) és az aktuális számlálóval, amiben a rábízott küldeményeket gyűjtjük (másik egyedi kulcsa: dátum, mettől, rendsz) DÍJAK {mióta, óradíj, dbár} az óradíj és a teljesített küldemények darabára (a legutolsó állapot az aktuális) ELSZÁM {meddig, fszám, összeg} a futárok kifizetéséhez igazolást adunk a teljesítményekről (pl. éppen valahányadikáig) Fogalmak • szám: a dolgozó futárhoz pillanatnyilag hozzá tartozó (még nem

teljesített) küldemények száma • összeg: a kifizetendő összeg a teljesítmény alapján

∑ (meddig – mettől) * óradíj + küldemények_száma * dbár időszakfüggően (Dolgoz.dátum és Küldem.kelt 2 Díjak.mióta közé esésének figyelése alapján illetve az Elszám.meddig óta az aktuális dátumig)

Megszorítások • kulcsok (egyik sem lehet NULL)

o természetesen minden kulcsot ki kell tölteni o itt adjuk meg, ha lennének a további egyedi kulcsokat, amelyeket

nem választottunk meg elsődlegesnek • külső kulcsok (csak a KÜLDEM.fszám lehet NULL)

o azokat a külső kulcsokat, amelyek kulcsszerepűek, természetesen ki kell tölteni, de amelyek leírók, azokról eldöntjük, hogy az ügyvitel alapján maradhatnak-e nem kitöltöttek

o itt csak a Küldemény futárszáma maradhat ismeretlen érték a felvitelkor, mert csak később kerül megadásra egy módosítással (amikor találtunk hozzá futárt)

• elnev, átvét, átad, meddig: lehet NULL o a többi leíró tulajdonságot is meg kell adni ezen 4 kivételével,

ugyanis: o az elnevezés bizonyos partnerek esetén nem létezik o a küldemény átvételének és átadásának időpontja jóval később

válik ismertté a küldemény megrendelésének felvételénél, ezért majd módosítással kerülnek be egymás után, a futár jelzéseinek hatására

o a munkát felvevő futár adatait tárolva még nem adhatjuk meg, meddig dolgozott

• kész: true/false logikai őrszem segít a Motorok közül szabadot találni, melyet egy munkafelvevő futárhoz rendelve azonnal hamisra állítunk, munkavégzéskor pedig elbírálás alapján igazra, ha továbbra is alkalmas a szolgálatra

• óradíj, dbár, összeg: nagyobbak 0-nál • egyszerű feltételek kiosztása a tulajdonságokhoz:

o az óradíj és darabár input adatok, de csak 0-nál nagyobb értékkel van értelme felvinni

o az összeg számolt adat, de csak 0-nál nagyobb értékkel van értelme tárolni

• szám >= 0 a számlálóként működő tulajdonság aktív dolgozónál 0-nál nagyobb, (esetlegesen felülről korlátozható) várakozó dolgozó futárnál (és a munkát leadó futárnál) pedig 0

• ahány kész motor van, annyi futár dolgozhat egyszerre

fontos szabály, nem muszáj önálló megszorításként megadni, ugyanis egy dolgozó futárt csak akkor szabad felvenni, ha van még szabad motor

Kapcsolatok

Minden nyíl a sok felől mutat az egy felé.

Megjegyzések: • A KÜLDEM:PARTNER párhuzamos kapcsolatok ábrázolhatók 3

partnerrel is (Megrendelő, Kitől, Kinek) • A DÍJAK tábla csak a külső kulcs hiánya miatt izolált tábla, hiszen a

DOLGOZ és a KÜLDEM tábla is egyértelműen rámutat. Ez a hozzájuk tartozó sor intervallum-kereséssel adható vissza, mint odaillő sor (mert azonosan egyenlő csak elvétve fordulhat elő).

Felhasználói funkciók (* jelzi, ha itt bemutatjuk a funkció részletes leírását az adatfolyamatokat illetően) • futárok, partnerek, motorok karbantartása • díjak változtatása • küldemény

o megrendelés felvétele * o futár indítása * o teljesítésének ellenőrzése * o átvételének, átadásának rögzítése *

• futár o jelentkezése munkakezdésre/munkavégzésre * o pillanatnyi helyzetének rögzítése * o elszámolása

• napi zárás * • elszámolás továbbítása a számfejtés felé

• listák, kimutatások * Adatfolyamatok Megrendelés felvétele:

új sor KÜLDEMbe azon:=generált szám kelt:=rendszerdátum, időpont:=rendszeridő megrend, kitől, kinek: létező partnerek többi mező: nem kitöltött [új sorok PARTNERbe, CÍMbe] választás dolgozó futárok közül (§): feltétele: szám=0 vagy a kitől és DOLGOZ.cím összevetéséből választjuk őt telefonon megegyezés/további várakozás

Futás indítása:

üres fszám-os küldeményekhez: ld. § azon és kitől bediktálása futárnak fszám módosítása KÜLDEMben szám megnövelése és cím inputja DOLGOZban

Küldemény teljesítésének ellenőrzése:

választott küldemény állapota: futára sincs még (fszám üres) futár megy érte (fszám van és átvét üres) futár viszi címzettnek (fszám és átvét van, átad üres) teljesítve (átad van)

Küldemény átadásának/átvételének rögz.:

feltétel: a futár helyes azon-ra hivatkozik átvét:=rendszeridő, DOLOZ.cím inputja vagy átad:=rendszeridő, szám csökkentése és DOLGOZ.cím inputja

Dolgozó futár helyzetének módosítása:

feltétele: szám=0 (vagy esetleg a futár kezdeményezésére új input) cím: input

Futár munkakezdése:

feltétele: van kész MOTOR új sor DOLGOZba adott fszám, rendszerdátum és -idő, választott kész rendsz, input ftel meddig: üres, cím: input, szám:=0; MOTOR.kész:=false

Futár munkavégzése:

feltétele: szám=0 meddig módosítása, MOTOR.kész: input (hátha mégsem kész, mert hibás)

Napi zárás:

feltétele: minden DOLGOZ.meddig: kitöltve MOTORban a kész frissítése (döntéshozatal hatására) KÜLDEM tételes listázása (törzsadatokkal és aktuális díjakkal) KÜLDEM sorainak felfűzése az ÖSSZKÜLDhez új üres KÜLDEM létrehozása DOLGOZ sorainak felfűzése az ÖSSZDOLGhoz új üres DOLGOZ létrehozása (A KÜLDEM ill. DOLGOZ sorokat naponta érdemes elmenteni az eddigi göngyölt adatokhoz és naponta 2 ilyen üres táblával kezdeni.)

Listák

elszámolások havi/futár szerinti bontása napi szállítások időtartama, napi összes holtidő küldemények napi számának átlaga megrendelők gyakorisága a legsűrűbben felkeresett címek két cím közötti legrövidebb ill. leghosszabb teljesítés stb. (A köv. félévben ezeket a lekérdezéseket megoldhatjuk már SQL-ben.)

Javaslatok archiválásra • hetente teljes másolat készítés • hivatkozás nélküli törzsadatok törlése 3 hónap után legyen

megengedett • időszerű kifizetések adatainak feladása után az ELSZÁM pl.

ELSZÁMév_hó_nap néven csak olvasható legyen Javaslatok bővítésre • küldemény stornózása (a megrendelő lemondja, amíg odaér a futár) • problémás esetek kezelése (baleset - új futár, hibás cím, visszaküldés,

…) • számlázás a megrendelők felé (bizonylat készítése) • futárok kifizetésének bizonylatolása • motorok állapotának (szervizelés, káreset stb.) követése; üzemanyag

nyilvántartás Kulcsszavak a fejezetben: adatbázis-specifikáció

PÉLDATÁR E fejezet jelentősége abban van, hogy több, életből vett adatbázis-részlet értelmezésével gyakoroljuk a számonkérést az alapfogalmak és a megszorítások területéről. Bizonyos esetekben azért nézzük végig az ügyviteli folyamatokat, mert ezek tükrében lehetünk tisztában az adatbázisban tárolt adatok jelentésével és rögzítésük sorrendiségével. Néhány lekérdezést azért válaszolunk meg itt, hogy kialakuljon bennünk az egészséges módja az adatok összeszedegetésének, és kifejlesszük igényünket az SQL-lekérdezés megismerésére. Tanfolyamszervezés Ismertetés Egy intézmény rövid tanfolyamokat hirdet. Néhány tanfolyamból több is indulhat (pl. havonta, ha van rá jelentkező). Az adott tanfolyamnak van egy oktatója, tandíja, kezdete, helyszíne és sok hallgatója; az azonos típusú tanfolyamoknak neve, óraszáma. A hallgatók azokból a jelentkezőkből lesznek, akik fizettek. Oktató is lehet valahol hallgató. Egy oktató az általa vállalt típusú tanfolyamokat különböző minősítéssel (a legutolsó tanfolyamának hallgatói véleménye alapján, 1-5 közötti érték) és tiszteletdíjért (korlátozott egész szám) tartja meg. Az adatbázis felállítása Vannak az eszmei tanfolyamok (ezek a tanfolyam-típusok), melyekből konkrét tanfolyamszámokkal indítanak el képzéseket. A kiírás szerint a konkrét tanfolyamnak van tandíja, tehát ugyanaz a tanfolyam többe kerülhet szeptemberben, mint márciusban. TIPUS {típus, megnevezés, óraszám} TANFOLYAM {tanfszám, típus, indul, kezdés, terem, tandíj, oktatókód} Ha hallgatóról és oktatóról is ugyanazokat az adatokat tároljuk, akkor egy táblában is lehetnek. SZEMÉLY {kód, név, cím, tel, végzettség} Egy konkrét tanfolyamra sok hallgató jelentkezik, és egy hallgató több tanfolyamra is jelentkezhet: JELENTKEZÉS {hallgatókód, tanfszám, fizetve} Mivel az oktató több tanfolyam-típust is vállalhat, letároljuk, miket tud oktatni. Ugyanakkor egy típusra több oktatónk is lehet. OKTAT {oktatókód, típus, minősítés, tiszteletdij}

A minősítést csak az első oktatást követően lehet kitölteni a hallgatói értékelést követően. Ebből a táblából lehet választott sorrend (minősítés szerint csökkenő/tiszteletdíj szerint növekvő) alapján oktatót keresni egy induló tanfolyam előtt. A kapcsolatok tisztán látszanak:

(Minden nyíl sokból az egybe mutat a ráírt külső kulcson keresztül.) Döntsük el, igazak-e az alábbi funkcionális függőségek: (Útmutató: minden kulcs egyértelműen meghatározza saját táblája minden tulajdonságát.)

1. {tanfszám} → {megnev, óraszám} 2. {hallgkód} → {végz} 3. {hallgkód, tipus} → {tandij} 4. {név, cím, tanfszám} → {fizetve} 5. {tanfszám, hallgkód} → {óraszám} 6. {tanfszám} → {tisztdij} 7. {indul, kezdés,oktkód} → {minősít}

Az egyes táblákban hány mintasorral oldható meg a következő esemény rögzítése? „Rendes Elek tartja majd a jövő hétfőn induló MS Access kezdő tanfolyamot 8000 Ft óradíjért. A tanfolyam 30 órás, a B teremben lesz, tandíja 88000 Ft fejenként és van rá 5 jelentkező.”

Mi a feltétele az alábbi karbantartó funkciók elvégzésének?

• 1 TANFOLYAM felvitele • 1 TÍPUS módosítása • 1 JELENTKEZÉS törlése

Raktár Ismertetés Egyetlen raktárból bizonylat kiállításával cikkeket vételezhetnek ki vagy adhatnak le valamely osztály dolgozói. A régi adatbázis:

Az adatbázisban az osztályoknak nincs törzse, egy bizonylat egy dolgozóhoz kötődik, a bizonylat tételei mozgásnemükben egységesek, azaz vagy csupa kivét, vagy csupa bevét. A régi adatbázist módosították a több raktár – benne mindenféle cikk – lehetőségével Ez azt jelenti, hogy több raktár lett, melyek mindegyikében mindenféle cikk van, és innen lehet ezeket vételezni ill. leadni. Vegyük észre, hogy a cikktörzs közös, hiszen mindegyik raktárban ugyanaz az egyforma cikkek megnevezése, az aktuális (egységes) beszerzési ára, csak a készletek különbözők raktáronként. Minden raktárnaknak egy dolgozó lett a vezetője. A bizonylatolás – mely szerint a kivét/bevét a raktár aktuális készletét csökkenti/növeli majd – kétféleképpen történhet.

Hasonlítsuk össze a 2 verziót!

B verzió:

Soroljuk fel mindkét verzióban a megszorításokat!

Szálloda Egy szálloda forgalmára készítünk adatbázist az alábbi bemenő bizonylat alapján:

Cég adatai Kelt

SZOBAFOGLALÁS 3 darab kétágyas zuhanyzós dátumtól - ig 1 darab egyágyas fürdőszobás dátumtól – ig Visszajelzést kérünk.

(aláírás, pecsét) Pontosítások: • a szobákat a szobaszámuk azonosítja • egy szobatípusból több szoba lehet a szállodában, melyek típusa,

ágyszáma és ára megegyező • a megrendelők iktatószámot kapnak a rögzítéskor (a megrendelésre írva

őrzik egy ideig) • a megrendelők, amiket cégek vagy magánszemélyek írnak a szállodának

– azonosítót kapnak (jelen esetben csak cégazon, pedig a cégek között magánszemélyek is lehetnek)

• az aláírást, pecsétet, melyek hivatalossá teszik a megrendelést, képként lehet tárolni, amint egyéb, nem hagyományos típusokat is megenged a választott adatbáziskezelő rendszer

Az alábbi adatbázis, melyben csak a megrendelők (megrendelési bizonylatok) tartalmát tároljuk, nem ad lehetőséget a visszajelzés igényének teljesítésére.

Figyelem! A fenti minta-bizonylatra 2 új sor keletkezne a TARTALOMban.

Ha azonnal le kell tudni kérdezni, van-e kívánt számban üres szoba a kért típusból adott időkorlátok között, akkor a megrendelési bizonylat tartalma helyett a lefoglalást tároljuk. Ez annyit jelent, hogy a megrendelőn kért intervallumban a kért szobatípus szobáit ellenőrizni kell, hogy le vannak-e már foglalva. Tehát a foglalást azonnal szobához kötve osztjuk ki, és ezek között keresünk a további megrendelés alkalmával. Nézzük a használható adatbázist:

Figyelem! A fenti minta-bizonylatra 4 új sor keletkezne a TARTALOMban. Már csak egy probléma lehet: Ha a megrendelő egyes tételei időintervallumának nincs metszete (például előre 3 hónapra lefoglalnak egy megrendelőn 2-2 éjszakát ugyanolyan szobatípusból), akkor most nem foglalhatjuk le ugyanazt a szobát (nézzük meg a foglalt kulcsát!). Ezt kiküszöbölve lássuk a végleges adatbázist:

Figyeljük meg a Foglalt kulcsát: egy szoba adott dátumtól csak egyszer foglalható le. Ebben keresni tényleg nem egyszerű; a nem kiadható szobák az új foglalás kérdéses intervallumával akárhogy ütköző lefoglalt szobák az adott szobatípusból. (A következő félévben viccből majd megállapíthatjuk, hogy ahol napokra előre üresen tátonganak a szobák, bizonyára egyszerűbb minden napot manuálisan bejelölni, mint megírni ezt az SQL-ellenőrzést.) Megjegyzés: A szobatípusnak lehetne leírás mezeje (pl. zuhanyzós, fürdőszobás, panorámás, nászutas stb.). Milyen feltétel mellett lehet az alábbi feladatokat az adatbázisban elvégezni?

• egy cég törlése • egy szobatípus árának megváltoztatása • egy megrendelő felvitele • egy foglalás felvitele

Mintasorok készítésére a Feladattárban találunk példát.

Szerviz Ismertetés Márkaboltok egyetlen szervizében fogadjuk a reklamációkat. A márkaboltok különböző cikkeket tartanak, melyekből konkrét gyártási számmal rendelkező darabokat adnak el. Az eladásokról kell tehát tudnia a szerviznek. A vevő akár többször is reklamálhat, ui. javítást, cserét vagy visszafizetést kérhet. Ezt olvasva, mondatonként vázoljuk az adatbázis tábláit: „Mindegyik márkabolt különböző cikkeket tart.” CIKK {cikksz, megnev, garancia, egysár} „melyekből konkrét gyártási számmal rendelkező darabokat ad el.” ELADÁS {cikksz, gyártsz, kelt} „a vevő” VEVŐ {vkód, név, cím} ELADÁS {cikksz, gyártsz, kelt, vkód} módosult ”többször is reklamálhat (igények)” REKLAM {cikksz, gyártsz, dátum, igény, telj} Az igény legyen 1 karakter, a teljesítés dátuma pedig később kerül bejegyzésre. Vegyük észre, hogy minden boltnak és a szerviznek ugyanaz a cikktörzse, melyben az eszmei cikk garanciaideje (hány hónap) és egységára is található. A konkrét cikk az, amit eladnak, amit a szerviz fogadhat, csak egyetlen vevőnek tudnak eladni, ugyanis 2 egyforma vasalónak csak a cikkszáma azonos, a gyártási számuk már nem. A boltok természetesen saját készleteiket is nyilvántartják, és eladáskor bizonylatot készítenek, de a szerviz csak az eladás tényét akarja látni. Vevő-törzsre szükség van a kiszállításhoz, az értesítési cím miatt. A vevő konkrét cikkét a garanciaidőn belül megreklamálhatja, pl. többször javíttatja, cserélteti, majd visszafizetteti. Lehet, hogy a szervizben javítással indul a dolog, és ott tesznek javaslatot cserére, vagy a sorozatos hibák láttán a visszafizetésre. Valószínűleg erről bizonylatot írnak és a vevő a konkrét márkaboltban intézi ezeket.

Egyelőre itt a fenti adatbázügyvitelét ellátja, annak gonelőállításáról és a bolti elanem térünk ki. Három, eléggé gyakori dolgazzal a céllal, hogy az új táb

A

1. Csere esetén tárolni kellKonkrét cikket csak ugya CSERE {cikksz, gyártsz, Vegyük észre, hogy ez aaz eladott cikkek részhalnem fognak becserélni, hcikket pedig csak egyszszülő tábla, a csere pedkulcs és az eladásra mutMásrészt egy cserére scserében, tehát a csere tis. pl. „A mai napon a régebúj vasalóra cserélték (gyáAz esemény hatása: 1 új

2. Az egységes cikktörzsbeTudni kell a garanciaidők

KAPCSOLATI ÁBR

is felállítása elegendő. Aki a szerviz reklamációs doskodni kell a munkák elvégzéséről, bizonylataik dások fogadásáról. Mindezek nyilvántartására itt

ot szeretnénk a meglévő adatbázishoz kapcsolni lák értelmezése rögződjön olvasóinkban.

, melyik cikkért milyen dátummal melyiket adták. nolyan cikkre lehet cserélni.

kelt, új_gyártsz}

tábla 1:1 kapcsolatban van az eladással, hiszen mazáról van szó. (Minden eladott cikket bizonyára ogy a szerviz 1 táblában tartsa őket, egy eladott er lehet becserélni.) Ilyen esetben az eladás a ig a gyerek; tehát a csere kulcsa egyúttal külső at. zánt új cikk ugyancsak egyszer vehet részt a ovábbi egyedi kulcsa a cikksz és új_gyártsz páros

ben vásárolt vasalómat (gyártási száma 122333) rtási száma 233444).”

sor a CSERE-táblában.

n az egységár néha változik, leginkább megnő. re eső aktuális árakról is.

Ahelyett, hogy minden eladáskor rögzítenénk a tétel mellé a pillanatnyi árat (ez egy zöldséges esetében elfogadható, mert sűrűn változtat eladási árat), itt az árváltozások tárolását oldjuk meg. ÁRVÁLT {cikksz, mióta, új_ár} Úgy érezzük, ez tiszta megoldás a pillanatnyi árak felkutatására. Ekkor a cikktörzsben feleslegesnek tűnik már az aktuális ár tárolása. (Bár SQL-beli lekérdezése adott cikk adott napi árának nem is olyan egyszerű.) De nézzük meg, mi a teendő egy induló adatbázisban. Nos, az összes cikket az induló árával fel kell venni az árváltozásba! (És még nem beszéltünk a sűrű eladások alkalmával tett mindenkori lekérdezések végrehajtásáról...) Vagyis az árváltozás kicsit módosul: ÁRVÁLT {cikksz, mikor, régi_ár} Ekkor a CIKK-törzsben szigorúan ott van az aktuális új ár. A régi árak visszakeresése most is ugyanannyi munkával oldható meg, az induló cikktörzs cikkei pedig nem kerülnek induláskor ide. Eladáskor azonnal kiolvasható az aktuális ár a törzsből. pl. „A mai naptól a vasaló (cikkszáma 12345/6666) ára felmegy; 6500 Ft helyett 7200 Ft lesz.” Az esemény hatása: 1 új sor az ÁRVÁLT táblában (12345/6666, 2003.08.18., 6500) és a cikkszám sorának módosítása a CIKKben (egysár = 7200)

3. Az egyes márkaboltoktól a bizonylatolt eladásokat kapjuk meg. SZÁMLA {szlaszám, dátum, vkód, végösszeg} SZ_TÉTEL {cikksz, gyártsz, szlaszám} A számlatétel nem szokványos, hiszen a számlaszámon belül felesleges sorszámozott tételként felsorolni a konkrét cikkeket, miután mindegyikből csak 1 darab létezik, tehát az kizárólag egy számlára kerülhet fel. pl. „Ma vettem 2 egyforma hajszárítót és 1 vasalót egy számlára.” Az esemény hatása: 1 új sor a SZÁMLA-táblában és 3 új sor a SZ_TÉTELben (a 3 sorban egyforma a szlaszám és a 3 sor közül 2-ben ugyanaz a cikkszám). Feltételezzük, hogy a vevő és a 2-féle cikk már létezik a saját törzsében.

Hallgatói nyilvántartó Adott főiskola hallgatóinak tanulmányi eredményeit nyilvántartó rendszer ismertetése A hallgató beiratkozik valamely szakra, amelynek az elvégzése után bizonyos végzettséget szerez. Ezen rendszer nem foglalkozik a tanárokkal és a termekkel sem. Képzeljük el, hogy a tanulmányi osztály azon részlegének munkáját oldjuk meg, ahol a hallgató kartonját tartják karban, és azt az összes vizsga letétele után átadják a diplomáztatási részlegnek. Itt kísérik figyelemmel a hallgató teljesítményét, félévente ellenőrzik a vizsgatartozásokat, kezelik a bukást és a következő félévre való beiratkozást. Ide tartozik a tematikák felvitele, az évente újra induló szakok kezelése. A jelentkezőket külön tároljuk és csak a tényleges félévindításkor kerülnek át a hallgatók közé. A hallgató leckekönyvi száma (generált sorszám) legyen az egyértelmű azonosító, az adott évben beinduló szak kódszámot kap, ami az összes évfolyamra nézve egyedi. Minden vizsgaköteles tantárgyból az összes kísérlet nyomon követhető. A rendszer egyértelműen két állapottal rendelkezik: a hallgató szempontjából "aktív" (szorgalmi és vizsgaidőszak ill. utóvizsgák ideje) és "passzív" (félévzárás ill. -indítás) időszakkal. Az adatbázis HALLGATÓ {hallg_azonositó, név, cím, anyja_neve, szül_hely, szül_dátum, végzettség, évf_kód, lezárt_szemeszter, bukott_halaszt_kimarad} ÉVFOLYAM {évf_kód, szak, akt_szemeszter, akt_tandíj} SZAK {szak, megnevezés, képesítés, össz_szemeszter} TANTÁRGY {tant, elnevezés, ea_óraszám, gy_óraszám, kollokvium, gyak_jegy} TEMATIKA {szak, szemeszter, tant} VIZSGA {dátum, hallg_azonositó, tant, koll_gyak , jegy} KARTON {hallg_azonositó, tant, koll_gyak, érv_jegy, kelt} A hallgató valamely iskolai évben induló konkrét szakra iratkozik és fizet be. Tematika szerinti tantárgyakat hallgat és a vizsgaköteles tárgyakból vizsgázik.

A VIZSGA táblában az aktuális szemeszterbeli próbálkozások szerepelnek, vagyis új szemeszter indításakor VIZS99/9 néven (év/félév) archiváljuk, és csak az újonnan létrehozott VIZSGA táblába írhatunk. A KARTON-ban van a hallgatók lezárt szemesztereinek minden érvényes jegye (2,3,4,5 vagy 6 pl. a felmentve). Félévindításkor írunk bele, egyébként csak lekérdezzük. Kulcsok, külső kulcsok

További fontos megszorítások:

• a VIZSGA-táblába egy hallgatóval csak olyan tárgyat vihetünk fel,

amelyet az évfolyamának megfelelő szakon az aktuális szemeszterében tematika szerint tanítanak

• a KARTONba csak olyan hallgató, tantárgy, kollokvium/gyakorlat hármas kerülhet, mely a VIZSGA táblában létezik és a mellettük álló jegy 1-nél nagyobb

• a {hallg_azonositó, tant, koll_gyak} nem külső kulcs a VIZSGA táblában (pedig a KARTONra mutathatna), ui. a KARTON nem lehet a VIZSGA szülő-táblája (a VIZSGA soraiból készül a KARTON sora)

• a {hallg_azonositó, tant, koll_gyak, kelt} viszont külső kulcs a KARTONban, miután a VIZSGA táblában meghatároz egy sort; de a kapcsolat 1:1, hiszen a külső kulcs (sőt már egy része) egyszer szerepelhet a KARTONban is (a VIZSGA a szülő, melynek a fix {hallg_azonositó, tant, koll_gyak} több sora közül az egyik dátumú átkerülhet a KARTONba, ha a jegy legalább kettes

tábla egyedi kulcs külső kulcsok (hova mutat) HALLGATÓ hallg_azonositó évf_kód (ÉVFOLYAM) ÉVFOLYAM évf_kód szak (SZAK) SZAK szak - TANTÁRGY tant - TEMATIKA {szak, tant} szak (SZAK);

tant (TANTÁRGY) VIZSGA {dátum, hallg_azonosító

tant, koll_gyak} hallg_azonositó(HALLGATÓ); tant (TANTÁRGY)

KARTON {hallg_azonositó, tant, koll_gyak}

{hallg_azonositó, tant, koll_gyak, kelt} (VIZSGA)

A rendszerbeli funkciókról: A "passzív" szakasz lépései:

• a VIZSGA átnevezésre kerül • tantárgyi tablók készítése • a félévet sikeresen zárók tantárgyi eredményei bekerülnek a

KARTONba (a hallgató lezárt szemesztereinek száma megnő) • a bukottakat megjelöljük a HALLLGATÓban (és lista készül róluk) • az ÉVFOLYAMban az aktuális szemeszter megnő eggyel (tandíj

módosulhat) • felvesszük az új évfolyamkódot, esetleg új szakot definiálunk • azon évfolyamkód lezárt hallgatói, ahol az aktuális szemeszter túlnő

az összes szemeszteren, kikerülnek tözsadataikkal és kartonjukkal ebből a rendszerből

• beiratkozási ív készítése (űrlap, ami bizonylattá válik a tényleges beiratkozáskor, tandíjbefizetés igazolásakor)

• a beiratkozásokat rögzítjük; (megjelölve, ha nem iratkozott be: halasztott vagy kimaradt

• a beiratkozott jelentkezők bekerülnek a HALLGATÓba • a következő félév tematikáit felvisszük (a szükséges új tantárgyakat

definiáljuk) • létrehozzuk az új VIZSGA táblát

Az "aktív" szakaszban történik:

• naplók, vizsgajegyzőkönyvek, pótvizsgajegyzőkönyvek készítése • a VIZSGA folyamatos bővítése

Bármikor lekérdezhető:

• az aktuális tematika • az egyéni teljesítmény • a létszámok • az átlagok, utóvizsgák, felmentések

Itt nem kezeljük :

• a bukott/halasztott hallgató újra csatlakozását • a tematika-frissítés pillanatait • a szigorlati vizsgaformát • a más szakra való átiratkozás lehetőségét

Megjegyzés:

Egy hallgató konkrét évfolyamkódhoz tartozik. Amennyiben egy személy egyidejűleg több szakon is hallgató, akkor több hallgatóazonosítóval rendelkezik.

Mintasorok HALLGATO h_azon nev cim a_neve sz_dat 92111 Kiss Balázs Budapest, Nagy Éva 68.11.12 92113 Kovács János Budapest, Nagy Anna 71.12.23 93112 Dudás Katalin Budapest, Tóth Éva 75.02.03 93113 Tahi Mária Budapest, Varga Zita 68.01.05 93115 Tóth Vilma Budapest, Molnár Edit 58.11.24

sz_hely vegz evf_kod szem buhaki Budapest, K 9202 5 Budapest, K 9202 5 Debrecen F 9303 3 Szolnok K 9304 3 B Miskolc F 9304 3

EVFOLYAM evf_kod szak akt_szem akt_td 9202 02 5 22000 9303 03 3 33000 9304 04 3 35000

SZAK szak megnev kepesit o_szem 02 titkosügynök f 6 03 tánctanár k 4 04 tenyérjós k 4

TANTARGY tant elnev ea_ora gy_ora koll gyakj MAT1 Matematika 15 0 .t. .f. FIZ Fizika 30 15 .t. .t. BIO Biológia 60 30 .t. .t. MAT2 Matematika 45 0 .t. .f.

TEMATIKA szak szem tant 02 1 MAT1 02 1 FIZ 03 1 MAT2 03 1 FIZ 04 1 BIO 02 2 MAT2 02 2 BIO 03 2 BIO

VIZSGA datum h_azon tant kogy jegy 95.12.20 92111 TA2 K 1 96.01.20 92111 TA2 K 2 95.12.18 93112 VE1 G 3 96.02.13 93112 VE1 K 4 96.02.05 93112 BIO G 5

A VIZSGA szerkezetével azonos pl. a VIZS92/1, VIZS92/2, VIZS93/1, VIZS93/2 szerkezete KARTON h_azon tant kogy jegy kelt 92111 MAT1 K 3 92.12.12 93112 FIZ G 4 93.12.21 93112 FIZ K 4 94.02.02 93115 BIO G 5 93.12.21 93115 BIO K 4 94.01.12 93115 TA1 K 3 94.11.28 93115 VE2 K 2 94.12.21 93115 TA2 K 4 95.01.24

(csak részleteket látunk) Zöldséges Ismertetés Képzeljük el egy zöldséges forgalmának nyilvántartását. A zöldséges naponta többször elad, beszerez vagy selejtez az áruiból, és minden kimutatása ezen háromféle forgalom szerint bontott. Biztos van áru- és szállítótörzse, de a vevőket nem regisztrálja. Az adatbázis ÁRU {cikkszám, név, elad_ár, besz_ár, készlet, mért_egys, minimum} SZÁLLITÓ {kód, ...} Az ÁRUban kétféle ár szerepel, a beszerzési ill. az eladási ár. Bármely cikk esetén minden újabb beszerzésnél megváltozhat a készlethez tartozó súlyozott átlagár, melynek hatására a kereskedő átírhatja az egész készlet eladási árát is. Mivel az ilyen árváltozás zöldség-gyümölcs esetén gyakori (akár naponta többször is előfordulhat), ezért a pillanatnyi árat eladás ill. selejtezés esetén inkább eltesszük. Nézzük meg, mit kell letárolni a 3 típusú forgalom bejegyzésekor: ELADÁS {mikor, miből, mennyit, mennyiért(elad_ár)}

BESZERZÉS {mikor, miből, mennyit, mennyiért(input), kitől} SELEJTEZÉS {mikor, miből, mennyit, mennyiért(besz_ár)} Vegyük észre, hogy a 3 tábla szerkezete szinte megegyezik, a beszerzésben van eggyel több oszlop. Ilyenkor lemondunk az alegyedek létrehozásáról, készítünk egy közös forgalom-táblát, melyben minden oszlopot megtartunk, legfeljebb nem mindegyiket kell majd kitölteni, de akkor jegyezni kell, milyen típusú forgalomról szól az aktuális tétel. FORGALOM {típus, kelt, cikksz, menny, ár, kód} A típus 1 katakteren lehet E / B / S (mint eladás / beszerzés / selejtezés). A szállító kódját csak beszerzés esetén kell kitölteni. Figyelem: az ár típustól függően: elad_ár / input / besz_ár. A Forgalomnak nincs kulcsa. A tulajdonságok semmilyen kombinációja nem jó kulcsnak. Ilyenkor generálhatunk minden tételnek egy azonosítót, de bizonylatolás esetén a fej-tábla sorai kapjanak bizonylatszámot, és a tétel-tábla sorait bizonylatszámon belül sorszámozzuk majd. Sorszámozzuk, mert ilyen forgalomnál elképzelhető, hogy egy bizonylaton belül több tétel is ugyanolyan áruról szól! Végül azért leírjuk, mely tulajdonságok fognak a fejbe, és melyek a tételekbe kerülni: FORG_FEJ {bizszám, típus, dátum, kód, összesen} FORG_TÉT {bizszám, sorszám, cikkszám, menny, ár} A FORG_FEJ.összesen egy számított mező; a hozzá tartozó tételek menny és ár mezői szorzatának az összege. Mivel pénzmozgás van mögötte, akár kerekítve, szokás tárolni. Itt az ideje archiválásról gondoskodni ilyen méretű forgalom (tételszám) esetén. Érdemes például havonta zárni, és a havi forgalom-táblákat átnevezve elrakni (akár másik könyvtárba, hogy csak lekérdezhetők legyenek és már nem karbantarthatók). A forg_fej ill. forg_tét táblaneveket hosszabbítsuk meg a hónap (vagy év.hónap) 2-karakteres (vagy 4-karakteres) jelével. Kapcsolati ábra

cikkszam bizszam bizszam kod ARU sorszam FORGFEJ SZALLITO nev FORGTETEL tipus neve keszlet cikkszam datum cime mertegys menny kod megj elad_ar ar osszesen besz_ar minimum

A FORGFEJ.kod lehet NULL; tehát csak kitöltött esetben határoz meg egy Szállítót.

Mintasorok ARU

cikkszam nev keszlet mertegys elad_ar besz_ar minimum 11232 golden alma 53 kg 120 80 2012311 idared alma 70 kg 100 70 2017666 banán 110 kg 190 120 1518122 paradicsom 50 kg 200 100 1018211 édes paprika 150 db 45 30 3018311 tv paprika 80 kg 160 100 2019266 kígyóuborka 25 kg 180 150 821155 leveszöldség 47 cs 100 70 1022341 krumpli 200 kg 80 50 50

SZALLITO kod neve cime megj 211 ZÖLDKERT Bp, 213 Kovács Szeged, * 218 Gömöri Bp, 321 Vitamin Bt Szada

FORGFEJ bizszam tipus datum kod osszesen 97111 E 97.06.11 64097112 E 97.06.11 9609718813 B 97.06.11 321 625097113 E 97.06.11 36097114 E 97.06.11 12097115 E 97.06.11 10329784411 B 97.06.12 218 480097116 E 97.06.12 440979999 S 97.06.12 90097117 E 97.06.12 3009718833 B 97.06.12 321 500097118 E 97.06.12 32097119 E 97.06.12 100979998 S 97.06.13 100097120 E 97.06.13 90

FORGTETEL bizszam sorszam cikkszam menny ar 97111 001 22341 4 11097111 002 11232 2 10097112 001 17666 2 190

97112 002 18122 1 20097112 003 17666 2 1909718813 001 22341 20 809718813 002 11232 30 659718813 003 21155 15 609718813 004 18311 20 9097113 001 11232 3 12097114 001 22341 1.5 8097115 001 17666 2 19097115 002 21155 1 10097115 003 22341 3 8097115 004 21155 2 10097115 005 18311 0.7 1609784411 001 22341 80 6097116 001 11232 2 12097116 002 18122 1 200979999 001 17666 5 120979999 002 18122 3 10097117 001 18122 1.5 2009718833 001 17666 10 1009718833 002 18122 20 909718833 003 18311 20 11097118 001 18311 1 16097118 002 22341 2 8097119 001 21155 1 100979998 001 18122 10 10097120 001 19266 0.5 180

Olvassunk ki eseményeket a mintasorokból!

Könyvtár A példa érdekessége az adatbázis mérete illetve az adatfolyamatok részletezése. A mintasoros illusztrációk miatt feltétlen javasolt a tanulmányozása. Itt összefoglaljuk, miből születtek az adatbázis-táblák, milyen a kapcsolati diagramja, és tárgyaljuk a legszükségesebb felhasználói funkciók adatfolyamatait. Ismertetés Egy könyvtár • beszerez új könyveket (ugyanabból a könyvből több példányt) • selejtezi az elhasznált példányokat (bizonyos idő elteltével automatikusan

vagy direkt) • karbantartja, ezért le tudja kérdezni a könyvek adatait, mint :

kölcsönözhetőség, műfaj, kiadó, kiadás éve, egy vagy több szerző, kezdő és aktuális darabszám, egységár és szorzó, kölcsönzések javasolt száma, recenzió, néhány utalás, mely sorozat része

• kezeli az olvasók alapadatait, mint: születési év, foglalkozás, név, cím • kölcsönzéseket bonyolít, azaz: kiad, visszavételez, felszólít (2-szer, a 3.

már büntetés); előjegyzést vesz fel, értesít • statisztikai kimutatásokat végez legalább évente • forgalmi listákat hoz le adott szempontok szerint bármilyen sűrűséggel A fentiekből látszik, hogy egy bizonyos könyv n számú példányát csak a kölcsönzéskor különböztetjük meg. Mind az n darabnak ugyanazok a fentebb felsorolt adatai, de az már a konkrét darab jellemzője, hogy kinél van, vagy hányszor kölcsönözték ki. Pontosítások Egy bizonyos könyvet írhatott több szerző, és egy szerzőnek több műve is lehet, ezért új relációt hozunk létre a szerzők és könyvek közé. A könyvek általában egyszerzősek, ezért felmerül a kérdés, hogy csak a többi szerzőt rakjuk-e a köztes relációba. Mivel gyorsan akarunk szerző szerint keresni, nem szabad 2 külön sorrendet fenntartani, hiszen akkor előbb össze kellene azokat fésülni. Egy bizonyos könyv utalhat több fogalomra és fordítva. Ezért itt is köztes relációba rakjuk le az utalásokat. Bizonyos könyvnek egy kiadója van, egyetlen sorozatnak a része, és fordítva nem igaz. Ilyen esetben a könyvnél jegyezzük meg a kiadó és a sorozat kódját, de megnevezésüket (a több könyvhöz való tartozásuk miatt) a kiadó- illetve sorozattörzsben tároljuk.

A beszerzés bizonylatolása a raktárnyilvántartó rendszer része, itt most inputként kapjuk a katalógusszámot a példányszámmal. (Valószínűleg év+sorszám alakban osztanak katalógusszámot.) Nálunk történik az egyetlen példány azonosítása, azaz a katalógusszám kibővítése alkatalógusszámmal (sorszám: 1-től példányszámig). A tagdíj befizetését nem kötelező bizonylatolni, hiszen a kölcsönzőívbe pecsételés jelzi az azévi befizetést. Amikor adott évben először jelenik meg az olvasó, akkor fizet majd. A program így is jelezni tudja, ha tagdíjat kell szedni. Új olvasó, új ív, azaz tagdíj. Egy olvasónak egy foglalkozása van, de ugyanaz a foglakozása több olvasónak is lehet. Tehát lesz foglalkozástörzsünk, és minden olvasó törzsadatai között jelöljük meg az ő foglalkozáskódját. Ha bizonyos könyv egyetlen példánya sincs bent, előjegyezzük az olvasót, és érkezési sorrendben próbáljuk kielégíteni a kérését. A lejáratvizsgálat abból áll, hogy a konstansként kezelt változók ismeretében (pl. 30 napos kölcsönzési idő, a felszólítások – számuk 3 – további 15 napot jelentenek, de a 3. már a büntetéskiírás) ellenőrizzük a kölcsönzési dátum óta eltelt időt. Ha a példány elveszett, kikerül a kölcsönözhetők közül. Legyen a büntetés nagysága = egységár∗szorzó, amiről értesítést küldünk (de az összeg beérkezését a pénzügyi osztály figyeli). Automatikus selejtezés-vizsgálat időszakosan történik, de a konkrét példány állapota is vezethet selejtezéshez. Azonosítások:

katal, az „eszmei” könyv alkatal, egyetlen példánya valamely könyvnek kiadó, adott kiadó sorozat, adott sorozat fogalom, utalásbeli fogalom szerző, konkrét szerző olvasó, egy olvasó (kölcsönzőív jelzőszáma) foglalk, egyfajta foglalkozás műfaj, egyetlen karakter (0 - 9); világszabvány

A fentiek szerint igazak az alábbi teljes függőségek: {katal} → {cím, kiadó, kiadév, műfaj, kezdődarabszám, aktuális darabszám, egységár, szorzó, max kölcs.száma, recenzió, sorozat, kölcsönözhetőség}

{katal, alkatal} → {kikölcsönözve, akt. kölcs. száma} (ha megvan a példány) {katal, alkatal} → {kelt, selejt/lopott} (ha nincs meg a példány) {kiadó} → {megnevezés} {sorozat} → {elnevezés} {szerző} → {név} {fogalom} → {hosszúnév} {olvasó} → {név, cím, szület.év, foglalk} {foglalk} → {elnevezés} {olvasó, katal} → {előjegyzés dátuma} {olvasó, katal, alkatal, dátum} → {visszahozatal dátuma, felszólítások száma} {katal, szerző} → {katal, szerző} („ki mit írt” miatt) {katal, fogalom} → {katal, fogalom} („mi mire utal” miatt) Az adatbázis az előbbi függőségek alapján: KÖNYV {katal, cím, kiadó, kiadév, műfaj, kezd_db, akt_db, egys_ár, szorzó, max_kölcs, recenzió, sorozat, kölcs_h} KIADÓ {kiadó, megnevezés} SOROZAT {sorozat, elnevezés} KIMITIRT {katal, szerző} SZERZŐ {szerző, név} UTALÁS {katal, fogalom} FOGALOM {fogalom, hosszúnév} PÉLDÁNY {katal, alkatal, kikölcs, akt_kölcs} OLVASÓ {olvasó, név, cím, szül_év, foglalk} FOGLALKOZÁS {foglalk, elnevezés} KÖLCSÖNZÉS {olvasó, katal, alkatal, dátum, visszahoz_dát, felszólít} ELŐJEGYZÉS {olvasó, katal, előjegyz_dát} NINCS {katal, alkatal,kelt, sel_lop}

Kapcsolati ábra

A kapcsolati ábra értelmezését megnézheti a videón. Megjegyzések: • a Kölcsönzés csak Példányt tartalmazhat, a Példány pedig Könyvet, de

azért egy Kölcsönzés automatikusan meghatároz egy Könyvet (pl. lekérdezésnél kihagyható a Példány)

• a Példány és Nincs közötti 1:1 kapcsolat nem tűnik igaznak, mert a 2 tábla egymást kizáró példányokat tartalmazhat csak (vagy részt vesz még a kölcsönzésben, vagy már nem), de amikor egy Példány bekerül a Nincsbe, akkor léteznie kell Példányként, csak utána törlődik a felhasználó szeme elől

• a Nincs Példányra mutat, a Példány pedig Könyvre, ezért a Nincs ugyancsak meghatároz közvetlenül egy Könyvet (pl. lekérdezésnél kihagyható a Példány)

• a lezárt kölcsönzéseket érdemes elrejteni szem elől (törölt állapot bevezetése) vagy gondoskodni gyakori archiválásukról; így a nyitott kölcsönzéseket gyorsabban ellenőrizzük a lejáratvizsgálatkor, illetve találjuk meg visszahozatalnál.

Felhasználói funkciók (hierarchia nélkül):

1. Törzsek karbantartása 2. Könyvbeszerzés 3. Könyv kikölcsönzése 4. Könyv visszahozatala

5. Könyv leselejtezése 6. Könyv előjegyzése 7. Lejárati értesítők 8. Lekérdezések 9. Kimutatások

Adatfolyamatok nagyvonalú tárgyalása funkciónként 1. KIADÓ, SOROZAT, SZERZŐ, FOGALOM, FOGLALK mellett az OLVASÓ és a KÖNYV is ide tartozik, de a könyv beszerzésének kiemelt fontossága miatt bizonyára külön kezeljük. 2. A KÖNYV mellett a PÉLDÁNY bővül automatikusan, és bővülhetnek a KIADÓ és a SOROZAT, biztosan bővül a KIMITÍRT (vele bővülhet a SZERZŐ) és az UTALÁS (vele pedig a FOGALOM). További magyarázatot talál a videón.

3. A KÖLCSÖNZÉS bővítésekor bővülhet az OLVASÓ (vele pedig a FOGLALK), de kerülhet sor egy ELŐJEGYZÉS törlésére is. További magyarázatot talál a videón.

4. A KÖLCSÖNZÉS módosításával jár automatikusan egy PÉLDÁNY módosítása, mert át kell billenteni a könyv kölcsönzésre vonatkozó állapotát. További magyarázatot talál a videón.

5. A NINCSbe felveszünk, a PÉLDÁNYból törlünk egy sort, a KÖNYVben ugyanakkor módosítunk (aktuális darabszámot). További magyarázatot talál a videón.

6. Az ELŐJEGYZÉS bővül, de ennek szigorú feltétele, hogy minden PÉLDÁNYa ki legyen éppen kölcsönözve. További magyarázatot talál a videón.

7. A 3-féle értesítő nyomtatása lekérdezéssel oldható meg; olvasunk a KÖLCSÖNZÉS, KÖNYV, OLVASÓ táblákból, miközben a felszólítások számát eggyel megnöveljük (tehát a KÖLCSÖNZÉS módosul). Viszont abban az esetben, ha a felszólítások száma 3-ra ugrik, lopást regisztrálunk (ld. teendők a selejtezésnél). További magyarázatot talál a videón.

8. Olvasunk a megfelelő táblákból 9. Olvasunk a megfelelő táblákból Cipőgyártó Ismertetés Bizonyos cipőgyár termékeinek a boltokba történő kiszállítását tartjuk nyilván. A gyár több modellt is gyárt különböző méretben és árban. A modell típusa FI/NŐ/GY; jellege pl. csizma, papucs, stb. A boltok időszakosan modelleket rendelnek, melyekre szállítólevél kíséretében történik a szállítás. A gyár és a boltok között ismert az ún. méreteloszlás-táblázat, mely azt jelenti, hogy egy zsákot akármelyik modellel hogyan kell telerakni: melyik méretből hány párat tartalmazzon. Így a rendelés is arról szól, hogy milyen cipővel megrakott melyik zsákból hányat kérnek. Az adatbázis száll_ levél modell zsák modell modell méret méret száll_levél zsák bolt MODELL KÉSZLET ELOSZLÁS SZ_FEJ SZ_TÉTEL BOLT elnevezés készlet hány_pár kelt hány_zsák név típus ár bolt cím jelleg tel

Megszorítások kulcsok: a feladatban adottak; NOT NULL további egyedi kulcsok: nincsenek külső kulcsok:

készlet.modell (NOT NULL és létező modell.modell) sz_tétel.modell (NOT NULL és létező modell.modell) sz_tétel.száll_levél (NOT NULL és létező sz_fej.száll_levél) sz_fej.bolt (NOT NULL és létező bolt.bolt)

további másodlagos tulajdonságok kitöltése: kötelező

kivéve: elnevezés tulajdonságokra vonatkozó korlátozások: • típus lehet „FI”/”NŐ”/„GY” • méret 18 és 48 közötti egész • ár>0 • készlet>=0 • zsák „A” és „Z” közötti betű • hány_pár>0 • kelt=rendszerdátum • hány_zsák>0 több tulajdonságot vagy több táblát érintő megszorítás: • sz_tétel.zsák létezik az eloszlás.zsák-ok között • sz_tétel-ben a modell és a zsák csak olyan lehet, amely zsákhoz

tartozó összes méretre igaz, hogy az adott modellből van készleten • hány_zsák∗hány_pár <= a hozzá tartozó készlet további szabályok lehetnek: • 1 zsákba összesen 12 pár modell kerülhet pl. • jogosultsággal történik az eloszlás felvitele • az ár megváltoztatása tilos (amíg nincs árváltozás tábla) Mintasorok alapján válaszoljuk meg a feltett lekérdezéseket! Megjegyzés: Az ilyen lekérdezéseket a legegyszerűbben és legpontosabban SQL-ben lehet megválaszolni. Tekintsük a jelen küszködést jogos vágyakozásnak az SQL felé!

FELADATTÁR Ezekben az ellenőrző feladatsorokban – nyolcféle adatbázisra 1-1 minta-vizsgasorral – adott normalizált adatbázisra vonatkozó kérdések fordulnak elő, az alábbi csoportosításban: • elméleti alapfogalmak, • mintasorok készítése. Tudnivalók a vizsgáról: • rendelkezésre álló idő: 50 perc • elérhető pontszám: 12+8 pont • elégtelen: 50 % alatt. A felhasználható segédletekről a vizsgáztató ad tájékoztatást. Sok sikert kíván a szerző.

Pontverseny 1 Adott matematikai szaklap havonta megjelenő számában középiskolások részére pontverseny folyik évfolyamonként. Folyó iskolaévben nyilvántartjuk minden feladat szövegét és pontszámát; az összes beküldött megoldásra adott pontszámot az odaítélt plusz pontszámmal együtt. Az adatbázis:

hónap hónap kód évfolyam isk kód sorszám sorszám ISKOLA DIÁK EREDMÉNY FELADAT elnevezés név kap_pont szöveg cím évfolyam plusz max_pont isk

Alapfogalmak:

1. Adja meg a külső kulcsokat a fenti adatbázisban! (4 pont) 2. Mi valósít kapcsolatot a FELADAT és a DIÁK között? (2 pont) 3. Milyen a DIÁK : EREDMÉNY kapcsolat? (2 pont) 4. Indokolja meg, hogy igaz-e az alábbi egyértelmű meghatározás:

{kód, hónap}→{kap_pont, plusz} (2 pont) 5. Mi a feltétele egy Eredmény felvitelének? (2 pont)

Készítsen mintasorokat, melyek az adatbázisban rögzítik a következő eseményt:

„Novemberben Kiss Béla és Nagy Pál (másodikos diákok ugyanabból az iskolából) teljesen egyformán teljesített, mindkét feladat megoldására 3 pontot kaptak a maximálisan adható 6-ból.” (8 pont)

Értékelés: Maximális pontszám: 20 pont

0 – 10 pont: elégtelen (1) 11 – 13 pont: elégséges (2) 14 – 16 pont: közepes (3) 17 – 18 pont: jó (4) 19 – 20 pont: jeles (5)

Pontverseny 2 Adott matematikai szaklap havonta megjelenő számában középiskolások részére pontverseny folyik az egyes évfolyamokon belül. Folyó iskolaévben nyilvántartjuk minden feladat szövegét, pontszámát és ötletadó tanárát, a benevezett diákok által beküldött összes feladat megoldására adott pontszámot. Az adatbázis:

hónap hónap kód évfolyam kód sorszám sorszám azon DIÁK EREDMÉNY FELADAT TANÁR név kap_pont szöveg neve évfolyam max_pont címe iskola azon isk_cím

Alapfogalmak: 1. Adja meg a külső kulcsokat a fenti adatbázisban! (4 pont) 2. Mi valósít kapcsolatot a DIÁK és EREDMÉNY között? (2 pont) 3. Milyen a TANÁR : DIÁK kapcsolat? (2 pont) 4. Indokolja meg, hogy igaz-e az alábbi egyértelmű meghatározás:

{kód, hónap, sorszám}→{neve, címe} (2 pont) 5. Mi a feltétele egy Tanár törlésének? (2 pont)

Készítsen mintasorokat, melyek az adatbázisban rögzítik a következő eseményt:

„Novemberben Kiss Péter, másodikos diák egy szegedi iskolából, mindkét kitűzött feladat megoldására megkapta a maximálisan adható 6 pontot.” (8 pont)

Értékelés: Maximális pontszám: 20 pont

0 – 10 pont: elégtelen (1) 11 – 13 pont: elégséges (2) 14 – 16 pont: közepes (3) 17 – 18 pont: jó (4) 19 – 20 pont: jeles (5)

Órarend Adott középiskola diákjai és tanárai idén az alábbiak szerint kerültek egymással kapcsolatba. (Az osztály 9c alakú; a nap és óra sorszámozott. A tantárgy kódja 4 karakteres rövidnév.)

Az adatbázis:

nap tant óra azon kód osztály tant osztály DIÁK TANÁR TANÍT TANTÁRGY ÓRAREND név neve kód elnevezés tant osztály belép_éve heti_óraszám

Alapfogalmak: 1. Adja meg a külső kulcsokat a fenti adatbázisban! (4 pont) 2. Mi valósít kapcsolatot a TANÁR és a TANÍT között? (2 pont) 3. Milyen az alábbi kapcsolat: TANÍT : ÓRAREND (2 pont) 4. Indokolja meg, hogy igaz-e az alábbi egyértelmű meghatározás:

{nap, óra, osztály}→{elnevezés} (2 pont) 5. Mi a feltétele egy Tanít törlésének? (2 pont)

Bővítse az adatbázis-mintasorokkal, hogy azok az alábbi eseményt rögzítsék:

„Az elsősöknek a pályakezdő Kiss László tart informatikát (az 1A osztálynak szerdánként a 3. és 4. órában; az 1B osztálynak péntekenként az első 2 órában).”(8 pont)

Értékelés: Maximális pontszám: 20 pont

0 – 10 pont: elégtelen (1) 11 – 13 pont: elégséges (2) 14 – 16 pont: közepes (3) 17 – 18 pont: jó (4) 19 – 20 pont: jeles (5)

Patika 1 Adott patika vényeinek nyilvántartásáról van szó. A gyógyszerek különböző kiszerelésben kaphatók, tehát a konkrét kiszerelésű gyógyszernek van azonosító száma. Egy vényen – mely a felvitelkor azonosítót kap – egy konkrét gyógyszer szerepel a felírt mennyiségben, de tartalmazza az orvos kódját és a beteg TAJ-számát is. (Az orvos-kód ellenőrzésre, de a beteg TAJ-száma csak rögzítésre kerül a patikában.) A gyógyszerért fizetendő ár: a támogatás százalékával csökkentett egységár. Az adatbázis:

kiszerel gy_szám azonosító kód KISZERELÉS GYÓGYSZER VÉNY ORVOS leírás elnevezés kelt név tartalom kiszerel kód szak támogatás taj_sz egys_ár gy_szám készlet mennyi

Alapfogalmak: 1. Adja meg a külső kulcsokat a fenti adatbázisban! (4 pont) 2. Mi valósít kapcsolatot a GYÓGYSZER és a KISZERELÉS között? (2 pont) 3. Milyen a GYÓGYSZER : VÉNY kapcsolat? (2 pont) 4. Indokolja meg, igaz-e az alábbi egyértelmű meghatározás:

{azonosító} → {elnevezés, egys_ár} (2 pont) 5. Mi a feltétele egy Vény felvitelének? (2 pont)

Készítsen mintasorokat, mely rögzíti az adatbázisban a következő eseményt:

„Ma ugyanattól a gyermekorvostól 2 beteg is hozott Augmentinről szóló receptet, de az egyiknek 1 üveg kanalast, a másiknak 2 doboz kapszulásat kell kapnia.” (8 pont)

Értékelés: Maximális pontszám: 20 pont

0 – 10 pont: elégtelen (1) 11 – 13 pont: elégséges (2) 14 – 16 pont: közepes (3) 17 – 18 pont: jó (4) 19 – 20 pont: jeles (5)

Patika 2 Adott patika vényeinek nyilvántartásáról van szó. A konkrét kiszerelésben kapható gyógyszernek van azonosító száma és fajtája (leírása pl. lázcsillapító, antibiotikum…). Egy vényen – mely a felvitelkor azonosítót kap – egy konkrét gyógyszer szerepel a felírt mennyiségben, de tartalmazza az orvos kódját és a beteg TAJ-számát is. (Az orvos-kód ellenőrzésre, de a beteg TAJ-száma csak rögzítésre kerül a patikában.)

Az adatbázis:

fajta gy_szám azonosító kód FAJTA GYÓGYSZER VÉNY ORVOS leírás elnevezés kelt név fajta kód szak egys_ár taj_sz készlet gy_szám mennyi

Alapfogalmak: 1. Adja meg a külső kulcsokat a fenti adatbázisban! (4 pont) 2. Mi valósít kapcsolatot a GYÓGYSZER és a VÉNY között? (2 pont) 3. Milyen a GYÓGYSZER : FAJTA kapcsolat? (2 pont) 4. Indokolja meg, igaz-e az alábbi egyértelmű meghatározás:

{azonosító} → {leírás} (2 pont) 5. Mi a feltétele egy Gyógyszer törlésének? (2 pont)

Készítsen mintasorokat, mely rögzíti az adatbázisban a következő eseményt:

„Dr. Méz gyermekorvostól ma 2 beteg is hozott „Panadol” lázcsillapítóról szóló receptet, de az egyiknek Fluimucil köptetővel együtt írta fel.”(8 pont)

Értékelés: Maximális pontszám: 20 pont

0 – 10 pont: elégtelen (1) 11 – 13 pont: elégséges (2) 14 – 16 pont: közepes (3) 17 – 18 pont: jó (4) 19 – 20 pont: jeles (5)

Szálloda Adott szálloda foglalásait tartjuk nyilván. Az egyes szobákat a szobaszámukkal, a megrendelőket (magánszemélyeket vagy cégeket) pedig generált kóddal azonosítjuk. Minden megrendelési bizonylat egyedi iktatószámot kap. Az ár szobánként és éjszakánként értendő, a dátumtól az érkezés, a dátumig a távozás napja.

Az adatbázis:

ikt_szám típus sz_szám sz_szám ikt_szám kód TÍPUS SZOBA FOGLALÁS BIZONYLAT MEGRENDELŐ leírás típus dátumtól kód elnevezés ár dátumig kelt cím ágy

Alapfogalmak: 1. Adja meg a külső kulcsokat a fenti adatbázisban! (4 pont) 2. Mi valósít kapcsolatot a SZOBA és a MEGRENDELŐ között? (2 pont) 3. Milyen az alábbi kapcsolat: FOGLALÁS : SZOBA (2 pont) 4. Indokolja meg, igaz-e az alábbi egyértelmű meghatározás:

{ikt_szám, sz_szám} → {cím} (2 pont) 5. Mi a feltétele egy Bizonylat módosításának? (2 pont)

Bővítse az adatbázist azokkal a mintasorokkal, melyek a következő eseményt tükrözik:

„A SZÁMALK Oktatási Rt. mai megrendelésére 2 három ágyas, zuhanyzós és 1 egy ágyas fürdőszobás szobát foglaltunk le 2003.10.11-től 2003.10.15-ig.” (8 pont)

Értékelés: Maximális pontszám: 20 pont

0 – 10 pont: elégtelen (1) 11 – 13 pont: elégséges (2) 14 – 16 pont: közepes (3) 17 – 18 pont: jó (4) 19 – 20 pont: jeles (5)

Márkabolt Egy márkabolt eladásait tartjuk nyilván. Az egyes cikkekből (mint adott márkájú TV-készülék, mosógép, stb.) konkrét gyártási számú darabo(ka)t vesz a vevő, és számla alapján fizet. Az adatbázis:

cikkszam cikkszam gyart_szam szlaszam v_kod CIKK SZ_TETEL SZ_FEJ VEVO elnevezes szlaszam kelt nev egys_ar v_kod cím keszlet vegosszeg

Alapfogalmak: 1. Adja meg a külső kulcsokat a fenti adatbázisban! (4 pont) 2. Mi valósít kapcsolatot a CIKK és a SZ_TETEL között? (2 pont) 3. Milyen az alábbi kapcsolat: SZ_ TETEL: SZ_ FEJ (2 pont) 4. Indokolja meg, hogy fennáll-e az alábbi egyértelmű meghatározás:

{cikkszam, gyart_szam}→{nev, cim} (2 pont) 5. Mi a feltétele egy Számla felvitelének? (2 pont)

Írjon mintasorokat az adatbázisba, melyek az alábbi eseményt tükrözik: „Kovácsék ma egy számlára vettek 1 vasalót és 2 egyforma hajszárítót.” (8 pont(

Értékelés: Maximális pontszám: 20 pont

0 – 10 pont: elégtelen (1) 11 – 13 pont: elégséges (2) 14 – 16 pont: közepes (3) 17 – 18 pont: jó (4) 19 – 20 pont: jeles (5)

Kiállítás Adott egyesület kiállítótermének programjait tartjuk nyilván. Egy időben (a megnyitástól a bezárásig) egy kiállítás látogatható, de az állapota jelzi 1 karakteren, hogy éppen Tervezett/Látogatható/Befejezett/Storno. Az egyes kiállítások egy vagy több művész alkotásaiból állnak. Az alkotásoknak valamilyen jellege (pl. festmény, fotó, kisplasztika,...) van.

Az adatbázis:

k_szám k_szám azonosító azonosító kód jelleg KIÁLLÍTÁS KIÁLL_TÉTEL ALKOTÁS MÛVÉSZ JELLEG nyitás kód név elnevezés zárás év sz_dátum cím jelleg nemzet állapot

Alapfogalmak: 1. Adja meg a külső kulcsokat a fenti adatbázisban! (4 pont) 2. Mi valósít kapcsolatot a KIÁLLÍTÁS és a MŰVÉSZ között? (2 pont) 3. Milyen az alábbi kapcsolat: KIÁLL_TÉTEL : ALKOTÁS (2 pont) 4. Indokolja meg, hogy igaz-e az alábbi egyértelmű meghatározás:

{nyitás}→{zárás} (2 pont) 5. Mi a feltétele egy Alkotás törlésének? (2 pont)

Írjon mintasorokat az adatbázisba, melyek az alábbi eseményt tükrözik: „Kupcsik Adrián 3 festménye vett részt a ma záró Kortárs művészek c. kiállításon.” (8 pont)

Értékelés: Maximális pontszám: 20 pont

0 – 10 pont: elégtelen (1) 11 – 13 pont: elégséges (2) 14 – 16 pont: közepes (3) 17 – 18 pont: jó (4) 19 – 20 pont: jeles (5)

FOGALOMTÁR 1NF: a reláció 1. normálformájú, ha minden másodlagos tulajdonság funkcionálisan függ a kulcstól. 2NF: a reláció 2. normálformájú, ha 1-es normálformában van, és minden másodlagos attribútuma a reláció bármely kulcsától teljesen függ. 3NF: a reláció 3. normálformájú, ha 2-es normálformában van, és egyetlen másodlagos attribútuma sem függ tranzitíven valamely kulcstól. adatbázis: véges sok egyedelőfordulásnak, azok véges sok tulajdonságértékének és kapcsolat-előfordulásának az adatmodell szerint szervezett együttese. adatbázis bővítése: a meglévő adatbázis szerkezetének átalakítása valamely újabb ügyviteli igény érdekében. adatbázis-specifikáció : önálló fejezete a rendszerfejlesztés bármely szakaszában elkészítendő dokumentációnak; tartalmazza az adatbázis részletes leírását, kapcsolatokkal és megszorításokkal, valamint az ügyviteli funkciók adatfolyamatait. adatbázisbeli szabályok: az adatbázisokat ellentmondásmentes ügyvitel szerint kell működtetnünk, ezért az adatokra és az eseményekre vonatkozó szabályokat érvényesíteni kell az adatbázisban. adatfolyamatok: az adatbázishoz tartozó ügyviteli pontokban történő adatmozgások mezőszinten részletezve. adatmodell: véges sok egyednek, azok véges számú tulajdonságainak és kapcsolataiknak a halmaza. adatmodellek fajtái: hálós, hierarchikus, relációs, objektumos, objektum-relációs. egyed: minden olyan dolog (objektum), ami minden más dologtól (objektumtól) megkülönböztethető. egyszerű kulcs: egyetlen attribútumból álló kulcs. funkcionális függőség: P funkcionálisan meghatározza Q-t (vagy Q funkcionálisan függ P-től), ha abból, hogy a reláció valamely két sora megegyezik a P halmazon, következik, hogy a két sor értékei megegyeznek a Q halmazon is. Jele: P→Q (P és Q egy reláció attribútumhalmazának részhalmazai.)

funkcionális függőségek származtatása reflexivitás: Ha Q ⊆P ⊆A, akkor P → Q bővítés: Ha P → Q és S ⊆A, akkor P ∪S → Q ∪S tranzitivitás: Ha P → Q, Q → S, akkor P → S egyesítési szabály: Ha P → Q, P → S, akkor P → Q ∪S pszeudotranzitivitási szabály: Ha P → Q,T ∪Q → S, akkor P ∪T → S dekompozíciós szabály: Ha P → Q és S ⊆Q, akkor P → S idegen kulcs:ld. külső kulcs. információ: kijelentés a valós világ összetevőiről, képzetes mennyiségeiről, valamint fogalmairól. Legkisebb egységei a szavak (adat-előfordulások). Az adatok csak más adatokkal együtt képeznek értelmes kijelentéseket. Minden adat lehetséges értelmezését annak típusa határozza meg, értéke pedig az adat pillanatnyi állapota. információtárolás: szövegszerű (rendezettség nélküli) vagy állományi (valamilyen fokú rendezettséggel bír). kapcsolat: az egyed külső szerkezete, a kapcsolat az egyedek közötti viszony. kapcsolat-fajták: 1:1, 1:N, N:M kapcsolatok jelölése a relációs adatbázisban: vonalas, Chen-féle, varjúlábas, egyértelmű. kulcsszerepű tulajdonság: olyan tulajdonság, amely része a kulcsnak. külső kulcs: az a tulajdonság (vagy több tulajdonság együttese), amely egy másik relációnak a kulcsa. másodlagos tulajdonság: olyan tulajdonság, amely nem része a kulcsnak. megszorítások: azért, hogy semmilyen adatkezelési esemény ne vezessen az adatok következetlenné válásához, az összes előírást és korlátozást be kell építeni az adatbázisba. A beépítésre került szabályt megszorításnak nevezzük. A megszorítások lényege a hivatkozási épség és az adatösszefüggések felügyelete minden adatkezelés alkalmával. mintasorok készítése: az adatbázis épségének megőrzésével viszünk fel olyan sorokat az egyes táblákba, amelyek egy megadott eseményt tükröznek, vagy csak példaként szolgálnak az adatbázis tartalmának elképzeléséhez. Az adatbázis szerkezetének megfelelően töltjük ki a sorokban az oszlopokat

értékekkel, mégpedig a megszorítások figyelembevételével (kulcs, külső kulcs, értékre vonatkozó korlátozás, előírt szabály, stb). normalizálás: a táblán belüli részleges és tranzitív függőségek megszüntetése a redundáns adattárolás megszüntetése céljából a funkcionális függőségek megőrzése mellett. NULL-érték: adattípustól független ismeretlen érték. összetett kulcs: legalább két tulajdonságból álló kulcs. redundancia: ugyanaz az adat feleslegesen többször van tárolva az adatbázisban. redundáns adattárolás: amikor ugyanazt az adatot feleslegesen többször tároljuk, tárolási és karbantartási káoszt okoz. reláció: a tulajdonsághalmazok Descartes-szorzatának részhalmaza. reláció kulcsa: az A attribútumhalmaz egy K részhalmaza kulcs, ha az a tulajdonságok olyan legszűkebb halmaza, melynek értékei az R reláció mindegyik sorát egyértelműen meghatározzák. reláció szabványos megadása: R {A1, A2, ..., An}, ahol R a reláció neve, Ai pedig az i. attribútum. relációs adatbázis: olyan adatbázis, ahol az egyedek táblázatok, a táblázat oszlopai pedig a tulajdonságok. részleges függőség: a nem teljes függőség. SQL (STRUCTURED QUERY LANGUAGE): jelentése alapján lekérdező nyelv, de valójában adatséma leíró, adatfelvivő, -módosító és -törlő feladatokat is elvégez. táblák közti kapcsolat: két reláció csak akkor áll kapcsolatban egymással, ha az egyik külső kulcsként tartalmazza a másik kulcsát. táblák megadása a relációs adatbázisban: egy oszlopban jelennek meg a tulajdonságok; felül a kulcsszerepűek, alul a másodlagosak, köztük a tábla neve. teljes függőség: Q funkcionálisan teljesen függ P-től, ha Q a P egyetlen részhalmazától sem függ. Ellenkező esetben részleges a függőség.

tranzitív függőség: az S tranzitíven függ P-től, ha létezik olyan Q ⊆A, hogy P → Q, Q → S, de visszafelé nem igazak a függőségek. tulajdonság: az egyed belső szerkezete, az egyedeket tulajdonságokkal (attribútumokkal) írjuk le.

MEGOLDÁSOK Pontverseny 1 Megoldások: 1. DIÁKban az isk

EREDMÉNYben a kód 2. Nincs kapcsolat köztük 3. 1:több 4. Nem igaz, mert egy diák egy adott hónapban több,

különböző sorszámú feladatra kap pontokat. 5. Létező diák kódhoz csak olyan hónap és sorszám vihető fel,

amelyek a diák évfolyamával a Feladatban már szerepelnek; kap_pont<=max_pont; plusz>=0

Pontverseny 2 Megoldások: 1. EREDMÉNY.kód

FELADAT.azon 2. EREDMÉNY.kód 3. Nincs kapcsolat közöttük 4. Igaz, mert

{kód}→{évfolyam} és {évfolyam, hónap, sorszám}→{azon}→{ neve, címe} 5. Ha nem szerepel a Feladatban,

vagy ha igen és még nem érkezett rá Eredmény (akkor onnan is törölni kell)

Órarend Megoldások: 1. TANÍT.tant

TANÍT.kód ÓRAREND.tant + ÓRAREND.osztály ÓRAREND.tant

2. TANÍT.kód 3. 1:N 4. Igaz, mert {nap, óra, osztály}→{tant}→{elnevezés} 5. Tanít-sor törlése akkor lehetséges, ha még nincs hozzá Órarend,

vagy az osztálynak ezen tantárgyát az Órarendben előbb ismeretlenre módosítjuk.

Patika 1 Megoldások: 1. GYÓGYSZERben {kiszerel}

VÉNYben {kód} VÉNYben {gy_szám}

2. GYÓGYSZER.kiszerel 3. 1:n 4. Igaz, mivel {azonosító} → {gy_szám} → {elnevezés, egys_ár}

5. Új azonosítót a rögzítés dátumával, létező orvossal, szabályos TAJ-számmal és létező gyógyszerszámmal lehet felvenni nullánál nagyobb, de legfeljebb az aktuális készletnek megfelelő mennyiségben.

Patika 2 Megoldások: 1. GYÓGYSZERben {fajta}

VÉNYben {kód} VÉNYben {gy_szám}

2. VÉNY.gy_szám 3. N:1 4. Igaz, mivel {azonosító} → {gy_szám} → {fajta} → {leírás} 5. Gyógyszert törölni akkor lehet, ha még nem szerepelt egy vényen sem

és a készlete valójában 0.

Szálloda Megoldások: 1. SZOBAban { típus}

FOGLALÁSban {sz_szám} FOGLALÁSban { ikt_szám} BIZONYLATban {kód}

2. Nincs kapcsolat köztük 3. több:1 4. Igaz, mivel {ikt_szám, sz_szám} → {ikt_szám} → {kód} → {cím} 5. Bizonylatot módosítani csak akkor lehet, ha a hozzá tartozó foglalások

még nem kezdődtek el. Valójában törölni kell a módosítandót a foglalásaival együtt, és mint új felvitelt, rögzíteni a módosított adatokat.

Márkabolt Megoldások: 1. SZ_TETELben a { cikkszam}

és a {szlaszam} SZ_FEJben { v_kod}

2. SZ_TETEL.cikkszam 3. sok : 1 4. Igaz, mivel {cikkszam, gyart_szam}→{szlaszam}→{v_kod}→{nev, cim}

5. 1 Számlát felvenni annyit jelent, hogy a felvitel dátumával és létező vevőkóddal új számlaszámot viszünk fel, nullánál nagyobb végösszegűt, de legalább 1 tételt is fel kell hozzá venni.

Kiállítás Megoldások: 1. KIÁLL_TÉTELben a { k_szám} és az {azonosító}

ALKOTÁSban a { kód} és a {jelleg} 2. Nincs kapcsolat köztük 3. N:1 4. Nem, mert csak a k_szám határozza meg egyérteműen a zárást.

(előfordulhat, hogy egy storno-zott kiállítással egyidőben egy másikat tervezünk)

5. Alkotás csak akkor törölhető, ha egyetlen kiállítás tételeként sem szerepelt

még eddig. Ha a jövőben tervezett, akkor a kiállítás tételei közül töröljük előbb.

IRODALOMJEGYZÉK

1. Ensor – Stevenson: Oracle-tervezés, Kossuth Kiadó, Budapest, 2000.

2. Halassy Béla: Az adatbázis-tervezés alapjai és titkai. IDG, Budapest, 1994.

3. Halassy Béla: Ember – információ – rendszer. IDG, Budapest, 1996.

4. J. D. Ullman – J. Widom: Adatbázisrendszerek, Panem Kiadó,

Budapest,1998.

5. Knuth, D.E.: A számítógép-programozás művészete 1 – 3, Műszaki

Könyvkiadó, Budapest, 1987-88.

6. Kupcsikné Fitus Ilona: Adatbázis-kezelés prezentációs készlet, GDF,

Budapest.

7. Stolniczki Gyula: SQL kézikönyv, ComputerBooks, Budapest, 1995.

8. Stonier, T.: Információ és az univerzum belső szerkezete, Springer

Hungarica, Budapest, 1993.

9. Timár és társai: Építsünk könnyen és lassan adatmodellt! Veszprém, 1996.

10. Wirth, N.: Algoritmusok + Adatstruktúrák = Programok, Műszaki

Könyvkiadó, Budapest, 1982.