1. oldal Adatbázis tervezés Az adatbázis tervezés az adatokat kezelő alkalmazások fejlesztésének a legelső és egyben a legmeghatározóbb lépése. Komolyabb alkalmazásoknál általában igen sok adat kerül tárolásra, illetve feldolgozásra. Az adatok nem önmagukban, hanem egymáshoz való viszonyukkal, kapcsolódási rendszerükkel, és integritási (formai, tartalmi, hivatkozási, függőségi előírások) megkötéseikkel együtt kezeljük, ezért az adatbázisokat úgy kell megtervezni, hogy az adatok közötti kapcsolatok megmaradjanak, de az egyes adatok lehetőleg csak egyszer szerepeljenek, vagyis minimális legyen a redundancia. A tervezés két nagy fázisra bontható: Logikai tervezés: amely a logikai összetartozásuk alapján kialakítja az adatok csoportjait (az egyedeket), majd meghatározza a csoportok közötti kapcsolatokat. Fizikai tervezés: amely a logikai modell alapján megtervezi a fizikailag is megvalósítható adatbázist, ahol a választott adatbázis-kezelő rendszernek megfelelően jelennek meg az adatbázis egyes elemei. Az ER modell Az ER Entity Relationship (Egyed Kapcsolat) modell az adatbázisban található elemek logikai struktúrájának modellezésére szolgál. Grafikus jelölő rendszert használ, melynek elemei a következők: Egyed: Azonosítóval ellátott, összetartozó adat csoport, amelyről információt tárolunk az adatbázisban. Jele egy téglalap, melybe beleírjuk az egyed nevét (azonosítóját). A gyenge egyedet, melyet saját tulajdonságai nem határoznak meg egyértelműen, emiatt a vele kapcsolatban lévő másik egyeddel együtt azonosítjuk, dupla vonalas téglalappal ábrázoljuk. Kapcsolat: Az egyedek egymáshoz való viszonyát leíró összefüggés. Jele egy rombusz, amelybe általában beleírjuk a két egyed közötti viszony fogalmát. A kapcsolatokat nyilakkal kötjük az egyedekhez. A nyilak alakja is információkat hordoz, a dupla vonal a kötelező jelleget, a dupla nyílfej többes kapcsolatot jelenti. A dupla vonal mindig annak az egyednek az oldalán van, amely kötelezően vesz részt a kapcsolatban. Egy raktárhely kötelezően egy raktárhoz tartozik, de egy raktárban több raktárhely is lehet. A gyenge egyed kapcsolatát dupla vonalas rombusszal jelöljük. Az alábbi ábra azt jelzi, hogy egy tételt úgy tudunk egyértelműen azonosítani, ha megnevezzük a számlát is, amelyhez tartozik. Tulajdonság: Egyedekhez vagy kapcsolatokhoz tartozó adatok, amelyek jellemzik azt. Jelük ellipszis, benne a tulajdonság nevével. Az ellipsziseket egyszerű vonalakkal
2. oldal kapcsoljuk ahhoz az egyedhez vagy kapcsolathoz, amelyet jellemez. A név aláhúzásával jelöljük a kulcs tulajdonságot, a származtatott tulajdonság ellipszise szaggatott körvonalú. A többértékű tulajdonságot dupla vonallal jelöljük, az összetett tulajdonság több elemi tulajdonságból áll. Az ER modell ábrázolására nincs teljesen egységes szabvány, az itt bemutatott Chen féle jelölési módtól bizonyos dokumentumokban kisebb-nagyobb mértékben eltérhetnek. 1.1 ER modell készítése 1.1.1 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég raktárának ER modelljét. A cég külön raktárakban tárolja a fagyasztott, a hűtött élelmiszereket, az italokat, a zöldségeket, és többi terméket. Minden termék külön vonalkóddal rendelkezik, egy termékből több raktárhelyen is lehet készlet (pl. más-más lejárati dátummal), és az egyes raktárhelyeken többféle termék is lehet. Az egyértelmű azonosíthatóság miatt az egyes raktárakban nem lehetnek egyforma kódú raktárhelyek, és raktárhelyet csak raktárban lehet kialakítani. Előfordulhat olyan eset, amikor néhány raktárhely vagy akár a teljes raktár nem használható, pl. ha elromlik a fagyasztó. A statisztikák miatt szükség lehet az egyes raktárakban lévő, és az egy adott napon betárolt termékek listájára. A termékek mennyiségén kívül tárolni kell a mennyiségi egységet is (darab, kg, liter ). 1.1.1 Feladat megoldása 1.1.2 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég számlázási rendszerének ER modelljét. A számlákon legyen egyedi azonosító, dátum, a pénztár és a pénztáros kódja, a vevő adatai, a vásárolt tételek adatai (terméknév, mennyiség, mennyiségi egység, egységár, tétel összege), és az összár. A vevők adatait tároljuk le. 1.1.2 Feladat megoldása
3. oldal 1.1.3 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég raktári megrendeléseinek ER modelljét. Minden termék külön vonalkóddal rendelkezik, de kategóriákat alkotnak, pl. többféle tej és sajt lehet a tejtermék kategóriában. A rendelésben szerepeljen a rendelésszám, a kiállítás dátuma, a megrendelés határideje, a beszállító adatai, a rendelést készítő dolgozó adatai, és minden megrendelt tételnél a termék neve, mennyiségi egysége és mennyisége. Egy rendelés az egy beszállítótól igényelt termékeket tartalmazza. 1.1.3 Feladat megoldása
4. oldal 1.1.4 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég raktári beszállításainak ER modelljét. Az egyes beszállítások mindig egy beszállítótól érkeznek, a beszállított árukat valamelyik raktáros veszi át. Minden tétel esetén tárolni kell a mennyiséget és az egységárat is. A tételek átvétel és betárolás után növelik a raktári készletet. 1.1.4 Feladat megoldása 1.1.5 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég dolgozói adatbázisának ER modelljét. Vannak fix munkakört betöltő dolgozók, és olyanok is, akik többféle munkakörben is dolgozhatnak. A tervezett és a tényleges munkabeosztást tárolni kell. Vannak olyan dolgozók, akik fix havibért kapnak (alapbér), több munkakörben viszont az alapbéren felül a ledolgozott órákkal arányos juttatás is jár (órabér alapján). Szinte minden dolgozónak van céges telefonja, a telefonnak csak a típusát tartják nyilván. Akik céges autót használnak útnyilvántartást vezetnek, az autóknál nyilván kell tartani, hogy mikor melyik autót ki vezette. 1.1.5 Feladat megoldása 1.1.6 Feladat
5. oldal Tervezze meg a VaKer élelmiszerekkel kereskedő cég webáruházának ER modelljét. Tárolni kell a megrendelők adatait, a rendelések dátumát, határidejét, tételeit, a rendelést összekészítő és a kiszállító végző dolgozó azonosítóját. A könnyebb eligazodás miatt a weblapon a termékek kategóriákba vannak sorolva. A rendelést összekészítő dolgozó mindig kiállít egy számlát is, a megrendelő adatai alapján. 1.1.6 Feladat megoldása 1.1.7 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég bolti átszállításának egyszerűsített ER modelljét. Az átszállítási feladatról tárolni kell, hogy ki mikor kezdeményezte, és melyik tételt melyik dolgozó mikor teljesítette. A raktárból kikerült áruk mennyisége a bolti áruk mennyiségét növeli. 1.1.7 Feladat megoldása
6. oldal 1.2 EER modellezés Az objektum orientált szemléletmód a számára nélkülözhetetlen öröklődési kapcsolatok megjelenítésére alakította ki az EER Extended ER (Kibővített ER) modellt, melyben a főtípus és az altípus közötti viszony leírására két új kapcsolattípust vezettek be: Tartalmazás: Az altípus a főtípusnak egy része, a főtípus minden egyes egyed előfordulása tartalmazza az altípus egy-egy egyed előfordulását. Jele egy HAS ( van ) feliratot tartalmazó nyíl a két egyed között, amely a főtípus felől az altípus felé mutat. Minden autóhoz tartozik egy útnyilvántartás. Specializáció: Az altípus a főtípus minden tulajdonságát örökli, de saját tulajdonságai is lehetnek. Jele egy ISA (is a az egy ) feliratot tartalmazó nyíl, amely az altípustól a főtípus felé mutat. A pénztáros az egy olyan dolgozó, akinek a pénztárakhoz is van kódja. 1.2.1 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég raktárának EER modelljét. A cég külön raktárakban tárolja a fagyasztott és a hűtött élelmiszereket, van egy többszintes raklapos raktár, és polcos, amelynek egy részén kenyereket, másik részén dobozos árukat, harmadik részében zöldségféléket tárolnak. Minden termék külön vonalkóddal rendelkezik, egy termékből több raktárhelyen is lehet készlet (pl. más-más lejárati dátummal), és az egyes raktárhelyeken többféle termék is lehet. Az egyértelmű azonosíthatóság miatt az egyes raktárakban nem lehetnek egyforma kódú raktárhelyek, és raktárhelyet csak raktárban lehet
7. oldal kialakítani. Előfordulhat olyan eset, amikor néhány raktárhely vagy akár a teljes raktár nem használható, pl. ha elromlik a fagyasztó. A statisztikák miatt szükség lehet az egyes raktárakban lévő, és az egy adott napon betárolt termékek listájára. A termékek mennyiségén kívül tárolni kell a mennyiségi egységet is (darab, kg, liter ). 1.2.1 Feladat megoldása 1.2.2 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég dolgozói adatbázisának EER modelljét. Vannak fix munkakört betöltő dolgozók, és olyanok is, akik többféle munkakörben is dolgozhatnak. A tervezett és a tényleges munkabeosztást tárolni kell. Minden dolgozónak van havi alapbére, több munkakörben viszont az alapbéren felül a ledolgozott órákkal arányos juttatás is jár (órabér alapján). Akik céges autót használnak, azoknak vezetni kell az autóhoz tartozó útnyilvántartást. 1.2.2 Feladat megoldása
8. oldal 1.2.3 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég számlázási rendszerének EER modelljét. A számlákon legyen egyedi azonosító, dátum, a pénztár és a pénztáros kódja, a vásárolt tételek adatai (terméknév, mennyiség, mennyiségi egység, egységár, tétel összege), és az összár. A cég 3 féle számlát használ: 1. Egyszerű bolti eladáskor nem kerülnek a vevő személyes adatai a számlára. 2. Áfás számla esetén a bolti vevők adatai rákerülnek a számlára. 3. Webes rendelés esetén a megrendelő által regisztrált név és cím kerül a számlára. 1.2.2 Feladat megoldása 1.3 A hierarchikus adatmodell A hierarchikus adatmodell kétféle alkotóelemből építkezik: Rekord: Az egy egyedhez tartozó tulajdonságok összessége. Az azonos típusú rekordok csoportjai rekordtípusokat alkotnak, melyeket a hozzájuk rendelt azonosítóval különböztetünk meg. A rekordtípust egy téglalappal adjuk meg, fejrészében az azonosító, testében az egyes tulajdonságok, a kulcs tulajdonságot aláhúzással jelezzük. PCR Parent Child Relationship (szülő-gyerek kapcsolat): Két rekordtípus közötti 1:N típusú kapcsolat, melyben egy szülőhöz több gyerek rekord is kapcsolódhat, de egy gyereknek csak egy szülője lehet. Többszintű, azaz a gyerek lehet egy következő PCR-ben a szülő. A kapcsolat jele egy nyíl, amely a szülőből mutat a gyerek felé. A modell szerkezetileg egy fa típusú gráf, a csomópontok a rekordtípusok, az élek a PCR-ek. Egy nagyobb méretű adatbázisban több előfordulási fa is található (pl. dolgozók, áruk, számlák ), de ezek önállóak, nincs köztük kapcsolat. A klasszikus modellben a rekordokat az elfoglalt pozíciójuknak megfelelően, ún. hierarchikus rekord formában tárolták, ami a fa elemeinek a bejárási sorrend alapján képzett lineáris sorozata. Ha egy rekordtípus többször is előfordult (pl. készlet az adott termékből, az adott helyen), akkor azt többször is letárolták.
9. oldal A kapcsolatokat adó PCR-eket külön elemként tárolta a modell, minden PCR egy-egy lista volt, amelyben pontosan leírták, hogy a szülő egyedtípus egy-egy konkrét előfordulásához a gyerek rekordtípus mely előfordulásai tartoznak. A PCR-ben tehát egy szülőhöz több gyerek is tartozhat, de alkalmatlan arra, hogy egy gyerek rekord más szülőhöz is kapcsolódjon, vagyis nem alkalmas az N:M kapcsolat leírására. A probléma megoldására a fejlettebb változatban bevezették a virtuális rekordtípust, melynek minden rekordja tartalmaz egy mutatót (pointer), ami egy másik szinten lévő rekordra mutat, ez kapcsolja össze a gyereket a szülővel. Az így létrehozott mesterséges kapcsolat elnevezése VPCR Virtual Parent Child Relationship (virtuális szülő-gyerek kapcsolat), melynek segítségével a hierarchikus modellben redundancia nélkül megvalósíthatók az N:M típusú kapcsolatok. A VPCR-hez tartozó listát a PCR-hez hasonlóan szintén külön elemként tárolja a modell, jele egy szaggatott vonalas nyíl, amely a gyerekből mutat a szülő felé. A raktári készlet nyilvántartása a klasszikus és a fejlettebb hierarchikus modellben 1.3.1 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég dolgozói adatbázisának hierarchikus modelljét. Bizonyos munkakörökhöz autót biztosít a cég, az autó mindig a munkakört betöltő személynél van, akinek útnyilvántartást kell vezetnie. A dolgozóknál nyilván kell tartani a munkaidőt, és szinte minden dolgozónak van céges telefonja. 1.3.1 Feladat megoldása
10. oldal 1.3.2 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég hierarchikus adatmodelljét. 1.3.2 Feladat megoldása 1.3.3 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég raktári beszállításainak hierarchikus modelljét. Az egyes beszállítások mindig egy beszállítótól érkeznek, az egyes tételek esetén tárolni kell a mennyiséget és az egységárat is. A termékek kategóriákba vannak sorolva, minden termék egy-egy kategóriába tartozik.
11. oldal 1.3.3 Feladat megoldása 1.4 Konvertálás ER modellről hierarchikusra Az egyedeknek a hierarchikus modellben a rekordtípusok felelnek meg. Az 1:1 és 1:N típusú kapcsolatok PCR-ként ábrázolhatók, az N:M típusú kapcsolatokat két kapcsolatra kell bontani, az így keletkezett új rekord az egyik szülőhöz PCR-el, a másik szülőhöz VPCR-el fog kapcsolódni. Az összetett tulajdonságok esetén elhagyjuk az összefogó tulajdonságot, és csak a komponenseket tároljuk a rekordban. A többértékű tulajdonság nem ábrázolható közvetlenül a hierarchikus modellben, ezért a tulajdonságot külön rekordba helyezzük el, és PCR-el kapcsoljuk a szülőhöz. 1.4.1 Feladat Alakítsa át az alábbi ER modellt hierarchikus modellé! Készítse el mind a klasszikus mind a fejlettebb változat modelljét.
12. oldal 1.4.1 Feladat megoldása
13. oldal 1.4.2 Feladat Alakítsa át az alábbi ER modellt hierarchikus modellé! Készítse el mind a klasszikus mind a fejlettebb változat modelljét.
14. oldal
15. oldal 1.5 A hálós adatmodell A hierarchikus modell továbbfejlesztése, mely támogatja az N:M típusú kapcsolatokat, és rekord szerkezetével megvalósíthatók az összetett és a többértékű tulajdonságok. Legfőbb újítás a SET, mely az azonos rekordból kiinduló PCR elemeket fogja össze. A set a szülőről (owner), vagyis a gyökér rekordról van elnevezve, ez a rekord a set tulajdonosa, a gyerek rekordtípusok a setben a tagok (member). Egy rekordtípus több setben is szerepelhet, így tetszőleges kapcsolatok leírhatók. A setek kialakításának szabályrendszerét a CODASYL szabályok írják le. Az alábbi példában az adatmodell két setből áll, a képzés rekordtípus mindkét set tagja. A dolgozó rekordokban a végzettség többértékű (ezt a [*] jelöli), az oktató rekordban a lakcím több mezőből álló összetett tulajdonság. Az összevethetőség miatt megadom a hálós modellnek megfelelő ER modellt is. 1.5.1 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég raktárának hálós adatmodelljét. A cég külön raktárakban tárolja a fagyasztott és a hűtött élelmiszereket, a raklapos és a dobozos árukat. Minden termék külön vonalkóddal rendelkezik, egy termékből több raktárhelyen is lehet készlet (pl. más-más lejárati dátummal), és az egyes raktárhelyeken többféle termék is lehet. Az egyértelmű azonosíthatóság miatt az egyes raktárakban nem lehetnek egyforma kódú raktárhelyek. A termékek kategóriákba vannak sorolva, minden termék egy-egy kategóriába tartozik. 1.5.1 Feladat megoldása
16. oldal 1.5.2 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég számlázási rendszerének hálós modelljét. A számlákon legyen egyedi azonosító, dátum, a pénztáros kódja, a vevő adatai, a vásárolt tételek adatai (terméknév, mennyiség, mennyiségi egység, egységár, tétel összege), és az összár. A dolgozóknál több telefonszám is lehet, a vevő címe összetett érték. 1.5.2 Feladat megoldása 1.5.3 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég autóflotta nyilvántartási rendszerének hálós modelljét. Az autókhoz különböző események tartoznak (kötelező szerviz, hibajavítás, gumicsere), mely munkálatokat különböző szervizekben szoktak elvégeztetni. A kötelező szervizek esedékességét a vezetett útnyilvántartásokból lehet kideríteni. Az útnyilvántartást havonta adják le a sofőrök, de közben nemcsak egy, hanem több autót is használhatnak. 1.5.3 Feladat megoldása
17. oldal 1.6 Konvertálás ER modellről hálósra Az egyedeknek a hálós modellben a rekordtípusok felelnek meg. Átalakítás nélkül ábrázolhatók az összetett és a többértékű tulajdonságok, az 1:1 és az 1:N kapcsolatokból set lesz, az N:M kapcsolatok megvalósításához kapcsoló rekordokat használunk, a kapcsoló rekord mindig két setben lesz a tag, a setek tulajdonosai pedig az összekapcsolt egyedeknek megfelelő rekordtípusok lesznek. 1.6.1 Feladat Alakítsa át az alábbi ER modellt hálós modellé! 1.6.1 Feladat megoldása 1.6.2 Feladat Alakítsa át az alábbi ER modellt hálós modellé!
18. oldal 1.6.2 Feladat megoldása 1.7 A relációs adatmodell A relációs adatmodellben a statikus tárolási szerkezet mellett a tárolt adatokra és azok tartalmára, az értékekre vonatkozó integritási szabályok is megadhatók. A tárolási szerkezet rendkívül egyszerű, az egyedeket relációkban tároljuk, ezekből a relációkból épül fel az adatbázis. A reláció leegyszerűsítve egy táblázat (tábla), melynek minden egyes cellájában egy-egy elemi érték tárolódik. Egy vízszintes irányú cellasort rekordnak nevezünk, ez egy konkrét egyed előfordulás, az egyes cellákban lévő értékek pedig az egyed tulajdonságai. A függőleges irányú cella-oszlopot mezőnek nevezzük, ezek sorrendje minden rekordban kötelezően azonos. Mivel egy cellába csak egy érték kerülhet, a modellben közvetlenül nem tárolhatók az összetett és a többértékű tulajdonságok. A modell nem tárolja külön elemként a kapcsolatokat, hanem az egymással összefüggésben lévő relációkban megismétli valamelyik mezőt, és a kapcsolatot a mezőbe beírt adatok értékegyezősége adja. Az integritási szabályok az adatokba kerülő értékekre, és az egyes adatok viszonyára vonatkoznak. Előírható egyszerű érték ellenőrzés, mely egy mezőre (pl. nem hagyható üresen
19. oldal a mező) vagy egy rekordra vonatkozik (egy konkrét beírt városnévhez csak bizonyos irányítószámok megengedettek). Az adatok viszonyára vonatkozó legfontosabb megkötés az elsődleges kulcs, amellyel a reláción belüli rekordok egyértelműen megkülönböztethetők egymástól. Két reláció között értelmezett a kapcsoló (idegen) kulcs, amely olyan értékeket tartalmaz, amely egy másik tábla elsődleges kulcsával megegyezik, így megvalósítva a két tábla közötti kapcsolatot. A példában a Sorszám és a Rendszám mező elsődleges kulcs, ezt az aláhúzás jelzi. Az Rszám mező idegen kulcs, ezt szaggatott aláhúzás jelöli, kötelező kitöltését pedig a sötét háttér jelzi. Jelentése: a mezőbe csak olyan érték írható, mely az autó táblában Rendszámként már megtalálható. A nyíl a két reláció közötti adatkapcsolatot jelzi, iránya mindig az idegen kulcs felől a hivatkozott elsődleges kulcs felé mutat. A rajz helyett alkalmazható a séma leírás is, melyben megadjuk a relációk nevét, és felsoroljuk azok mezőit. Az elsődleges kulcsot aláhúzással, az idegen kulcsot szaggatott aláhúzással jelöljük. Az egyértelműség miatt, az egymással kapcsolatot tartó mezők elnevezésénél használjuk ugyanazokat a mezőneveket (Rendszám)! Autó [ Rendszám, Típus, Fogyaszt ] Útnyilvántartás [ Sorszám, Rendszám, Dátum, Útvonal, Km ] 1.7.1 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég tanfolyamainak relációs adatmodelljét. A dolgozóknál kódjukon és nevükön kívül tároljuk a végzettségeiket is. A tanfolyamokat több témában tartják, egy-egy témából különböző időpontokban és általában más helyszínen többet is. Egy tanfolyamot általában több oktató tart, bizonyos oktatók több tanfolyamban is részt vesznek. Az oktatóknál nevükön és kódjukon kívül tároljuk címüket is, ami összetett tulajdonság. Adja meg a relációk sémáját is. 1.7.1 Feladat megoldása Dolgozó [ Dkód, Dnév ] Végzettség [ Dkód, Leírás ] Tanfolyam [ Tkód, Téma ] Képzés [ Dkód, Dátum, Hely, Tkód ] Oktató [ Okód, Onév, IrSz, Város, UHsz ] T-O [ Tkód, Okód ]
20. oldal 1.7.2 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég raktárának relációs adatmodelljét. A cég külön raktárakban tárolja a fagyasztott és a hűtött élelmiszereket, a raklapos és a dobozos árukat. Minden termék külön vonalkóddal rendelkezik, egy termékből több raktárhelyen is lehet készlet (pl. más-más lejárati dátummal), és az egyes raktárhelyeken többféle termék is lehet. Az egyértelmű azonosíthatóság miatt az egyes raktárakban nem lehetnek egyforma kódú raktárhelyek. A termékek kategóriákba vannak sorolva, minden termék egy-egy kategóriába tartozik. A készlet mellett tárolni kell a betárolási és a lejárati dátumot. Adja meg a relációk sémáját is. 1.7.2 Feladat megoldása Kategória [ Kkód, Leírás ] Termék [ Tkód, Tnév, MEgys, Kkód ] Raktár [ Rkód, Leírás, Aktív ] Raktárhely [ Rhkód, Aktív, Rkód ] Készlet [ Tkód, Menny, Bedat, Ledat, Rhkód ] 1.7.3 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég számlázási rendszerének relációs adatmodelljét. A számlákon legyen egyedi azonosító, dátum, a pénztáros kódja, a vevő adatai, a vásárolt tételek adatai (terméknév, mennyiség, mennyiségi egység, egységár, tétel összege), és az összár. Adja meg a relációk sémáját is. 1.7.3 Feladat megoldása Vevő [ Vkód, Vnév, IrSz, Város, UHsz ] Dolgozó [ Dkód, Dnév ] Számla [ SzSzám, Dkód, Dátum, Összár, Vkód ] Termék [ Tkód, Tnév, MEgys, EgysÁr ] Tétel [ SzSzám, Sorszám, Tkód, Menny, Összeg ]
21. oldal 1.7.4 Feladat Tervezze meg a VaKer élelmiszerekkel kereskedő cég raktári megrendeléseinek relációs adatmodelljét. Minden termék külön vonalkóddal rendelkezik, de kategóriákat alkotnak, pl. többféle tej és sajt lehet a tejtermék kategóriában. A rendelésben szerepeljen a rendelésszám, a kiállítás dátuma, a megrendelés határideje, a beszállító adatai, a rendelést készítő dolgozó adatai, és minden megrendelt tételnél a termék neve, mennyiségi egysége és mennyisége. Egy rendelésben több beszállító is részt vehet. 1.7.4 Feladat megoldása 1.8 Konvertálás ER modellről relációsra Az egyedeknek a relációs modellben a relációk felelnek meg, az egyértékű tulajdonságokból lesznek a mezők, az összetett tulajdonságok esetén elhagyjuk az összefogó tulajdonságot, és csak a komponenseket tároljuk a relációban. A többértékű tulajdonság nem ábrázolható közvetlenül, ezért a tulajdonságot egy új relációba helyezzük el, melyet kibővítünk egy idegen kulcs mezővel, és ezen keresztül teremtjük meg a kapcsolatot az eredeti reláció elsődleges kulcsával. Az 1:1 és az 1:N kapcsolatokat szintén idegen kulcs mező beszúrásával alakítjuk át, az N:M kapcsolatokat pedig egy új kapcsoló reláció kialakításával realizáljuk. 1.8.1 Feladat Alakítsa át az alábbi ER modellt relációs modellé! 1.8.1 Feladat megoldása
22. oldal 1.8.2 Feladat Alakítsa át az alábbi ER modellt relációs modellé! 1.8.2 Feladat megoldása 1.8.3 Feladat Alakítsa át az alábbi ER modellt relációs modellé! 1.8.3 Feladat megoldása
23. oldal 1.9. Normalizálás A normalizálás az adatbázis belső szerkezetének ellenőrzése, lépésenkénti átalakítása oly módon, hogy az adatbázis minden egyes lépésben egy-egy újabb kritériumnak, egymásra épülő normálformának feleljen meg. A műveletsorozat célja a redundancia- és anomáliamentes adatbázisok kialakítása. Nézzük az alábbi példát, egy bolti számlát: SzSzám Dátum Vnév Vcím Dkód Dnév Tkód Tnév Menny EgysÁr Összeg Összár 112 2010. Kis Mc. Jég 14 Hó Ida A673 Izzósor 2 2500 5000 12.23 Éva u.1 C193 Gyertya 4 500 2000 F003 Fenyő 2,5 3000 7500 14500 Egy vevő általában több terméket vásárol, emiatt a Tkód..Összeg mezők többértékűek. Írjuk fel a mezők közötti összefüggéseket: FD Functional Dependency, funkcionális függőség. SzSzám Dátum, Vnév, Vcím, Dkód, Dnév, Összár SzSzám, Tkód Tnév, Menny, EgysÁr, Összeg Induljon a normalizálás: 1NF Első normálforma: Egy reláció 1NF-ben van, ha minden attribútum egyértékű, és a relációban van kulcs. (A kulcs miatt a sorok különböznek egymástól.) Ha az FD-knek megfelelően az eredeti relációt két új relációra bontjuk, akkor egy olyan adatbázist kapunk, amely 1NF-ben van: R1 [SzSzám, Dátum, Vnév, Vcím, Dkód, Dnév, Összár] R2 [SzSzám, Tkód, Tnév, Menny, EgysÁr, Összeg] 2NF Második normálforma: Egy reláció 2NF-ben van, ha 1NF teljesül, és minden attribútum a teljes kulcstól függ. Ha a kulcs egyetlen mező, a 2NF automatikusan teljesül! Vizsgáljuk az R2 relációt, hiszen ott összetett a kulcs. Keressünk FD-ket! Tkód Tnév, EgysÁr SzSzám, Tkód Menny, Összeg
24. oldal A termékkódtól függ a terméknév és az egységár. A vásárolt mennyiséget és az adott mennyiségért fizetett összeget továbbra is a számlaszám-termékkód kulcs határozza meg. Most már minden a kiválasztott kulcsoktól függ, így az ennek megfelelően felbontott relációk 2NF-ben lévő adatbázist adnak. R1 [SzSzám, Dátum, Vnév, Vcím, Dkód, Dnév, Összár] R2 [Tkód, Tnév, EgysÁr] R3 [SzSzám, Tkód, Menny, Összeg] 3NF Harmadik normálforma: Egy reláció 3NF-ben van, ha 2NF teljesül, és a nem kulcs attribútumok nem függnek tranzitíven a kulcstól. Ez azt jelenti, hogy a nem kulcs attribútumok között nem találunk FD-t! Keressünk a relációkban a mezők között összefüggéseket! Vnév Vcím Dkód Dnév A vevő neve egyértelműen meghatározza a vevő címét! A dolgozó kódja egyértelműen meghatározza a dolgozó nevét! A megtalált FD-knek megfelelően újból átalakítjuk a relációkat, és így egy 3NF-ben lévő adatbázishoz jutunk. Számla [SzSzám, Dátum, Vnév, Dkód, Összár] Vevő [Vnév, Vcím] Dolgozó [Dkód, Dnév] Termék [Tkód, Tnév, EgysÁr] Tétel [SzSzám, Tkód, Menny, Összeg] A relációknak megfelelő ER modell: BCNF Boyce-Codd normálforma: Egy reláció BCNF-ben van, ha minden függőség csak jelölt kulcsból indul ki. Tételezzük fel, hogy a vevőknél tárolnánk az adószám mezőt is: R2 [Vnév, Vcím, Adószám] Ebben az esetben találnánk egy (Adószám Vnév, Vcím) FD-t, és az R2 reláció nem teljesítené a 3NF kritériumot, vagyis tovább kellene bontani két relációra. Ennek viszont semmi értelme nem lenne, hiszen olyan függőséget szüntetnénk meg, amely nem okoz ismétlődést, az adószám ugyanis éppúgy egyedi mező, mint a Vnév. Vagyis ha az R2
25. oldal relációban az adószám is jelölt kulcs, akkor az adatbázis bár nem 3NF, de redundancia mentes BCNF, és ez tökéletesen megfelel a normalizálás céljának: R2 [Vnév, Vcím, Adószám] Most nézzünk egy általános normalizálási példát: normalizáljuk az alábbi sémát 3NF-ig, alkalmazzuk a tanult szabályokat és axiómákat: R(A,B,C,D,E,F) ahol A C, C E, (A,B) F, B D. Armstrong 1. axiómája alapján (az egész meghatározza a részét): (A,B) A és (A,B) B Armstrong 3. axiómája alapján (a függőségek tranzitívek): (A,B) A és A C (A,B) C (A,B) C és C E (A,B) E (A,B) B és B D (A,B) D A fentiekből következik, hogy (A,B) meghatározza az összes többi attribútumot, így 1NF-ben ez lesz a kulcs: 1NF: R(A,B,C,D,E,F) 2N-hez úgy daraboljuk a relációkat, hogy a relációban maradó teljes kulcstól függjenek: A C, C E R1(A,C,E) (A,B) F R2(A,B,F) B D R3(B,D) Vagyis 2NF: R1(A,C,E) R2(A,B,F) R3(B,D) 3NF-hez nem kulcsból kiinduló FD-ket keresünk (most: C E), és ezek alapján daraboljuk az adott relációkat, vagyis: R1(A,C,E) R1(A,C) R2(C,E) Vagyis 3NF: R1(A,C) R2(C,E) R3(A,B,F) R4(B,D) Feladatok: 1.9.1. Normalizálja az alábbi sémát 3NF-ig: R(X,Y,Z,Q,W) ahol Y W, X (Q,Z), Z Y. 1.9.1 Feladat megoldása: Normalizálja az alábbi sémát 3NF-ig: R(X,Y,Z,Q,W) ahol Y W, X (Q,Z), Z Y. A szétvághatósági szabály alapján: X (Q,Z) X Q és X Z Armstrong 3. axiómája alapján: X Z és Z Y X Y X Y és Y W X W A mezők atomiságát feltételezve: 1NF: R(X,Y,Z,Q,W) 2NF: = 1NF 3NF: R1(X,Q,Z) R2(Z,Y) R3(Y,W)
26. oldal 1.9.2. Normalizálja az alábbi sémát BCNF-ig: R(A,B,C,D,E) ahol C E, A D, E B, (A,E) A. 1.9.2 Feladat megoldása: Normalizálja az alábbi sémát BCNF-ig: R(A,B,C,D,E) ahol C E, A D, E B, (A,E) A. Armstrong 1. axiómája alapján: Armstrong 3. axiómája alapján: A mezők atomiságát feltételezve: 1NF: R(A,C,B,D,E) 2NF: R1(A,C) R2(A,D) R3(C,E,B) 3NF: R1(A,C) R2(A,D) R3(C,E) R4(E,B) BCNF: = 3NF (A,E) A és (A,E) E (A,E) A és A D (A,E) D (A,E) E és E B (A,E) B De C E, ezért (A,C) a kulcs. 1.9.3. Normalizálja az alábbi sémát BCNF-ig: R(X,Y,Z,Q,R,S) ahol (Y,Q) Y, Q Z, Y S, (Y,Q) R, S X. 1.9.3 Feladat megoldása: Normalizálja az alábbi sémát BCNF-ig: R(X,Y,Z,Q,R,S) ahol (Y,Q) Y, Q Z, Y S, (Y,Q) R, S X. Armstrong 1. axiómája alapján: (Y,Q) Y és (Y,Q) Q Armstrong 2. axiómája alapján: Q Z (Y,Q) (Y,Z) A szétvághatósági szabály alapján: (Y,Q) (Y,Z) (Y,Q) (Y) és (Y,Q) (Z) Armstrong 3. axiómája alapján: (Y,Q) Y és Y S (Y,Q) S (Y,Q) S és S X (Y,Q) X A mezők atomiságát feltételezve: 1NF: R(Y,Q,X,Z,R,S) 2NF: R1(Y,Q,R) R2(Y,S,X) R3(Q,Z) 3NF: R1(Y,Q,R) R2(Y,S) R3(S,X) R4(Q,Z) BCNF: = 3NF 1.9. 4. Normalizálja az alábbi sémát BCNF-ig: R(A,B,C,D,E,F) ahol A C, E B, C (F,C), (A,E) D. 1.9.4 Feladat megoldása: Normalizálja az alábbi sémát BCNF-ig: R(A,B,C,D,E,F) ahol A C, E B, C (F,C), (A,E) D. Armstrong 1. axiómája alapján: (A,E) A és (A,E) E A szétvághatósági szabály alapján: C (F,C) C (F) és C (C) Armstrong 3. axiómája alapján: (A,E) A és A C (A,E) C (A,E) C és C F (A,E) F (A,E) E és E B (A,E) B
27. oldal A mezők atomiságát feltételezve: 1NF: R(A,E,B,C,D,F) 2NF: R1(A,E,D) R2(A,C,F) R3(E,B) 3NF: R1(A,E,D) R2(A,C) R3(C,F) R4(E,B) BCNF: = 3NF 1.9. 5. Normalizálja az alábbi sémát BCNF-ig: R(A,B,C,D,E) ahol A B, A C, B A, B C, C D, D E. 1.9.5 Feladat megoldása: Normalizálja az alábbi sémát BCNF-ig: R(A,B,C,D,E) ahol A B, A C, B A, B C, C D, D E. Armstrong 3. axiómája alapján: B C és C D B D B D és D E B E De A B, tehát A vagy B lehet a kulcs. A mezők atomiságát feltételezve: 1NF: R(B,A,C,D,E) 2NF: = 1NF 3NF: R1(B,A) R2(A,C) R3(C,D) R4(D,E) BCNF: R1(B,A,C) R2(C,D) R3(D,E) 1.10. Lekérdezési feladatok a hálós adatmodellben Az NDQL (Network Data Query Language) rekordorientált, navigációs jellegű lekérdező nyelv, amelyben úgy kell mozgatni a rekord pointereket, hogy a kívánt rekord előfordulás kerüljön a gazdanyelv és az adatbázis által is látott osztott memória területre. Az értelmezett műveletek: p 1 feltétel (rekord): A megadott rekordtípuson belül az első olyan rekord előfordulásra áll rá, mely teljesíti a paraméterként megadott feltételt. p n feltétel (rekord): o (set, rekord): Pozícionálás a feltételnek eleget tevő következő rekord előfordulásra. Pozícionálás a megadott setben a megadott rekordtípushoz tartozó tulajdonos rekord előfordulásra. m 1 feltétel (set, rekord): Pozícionálás a megadott setben a megadott rekordtípushoz tartozó, feltételnek eleget tevő első tag rekord előfordulásra. m n feltétel (set, rekord): Pozícionálás a megadott setben a megadott rekordtípushoz tartozó, feltételnek eleget tevő következő tag rekord előfordulásra. Használjunk C szerű gazdanyelvet, a kiírásra alkalmazzuk a print utasítást, a navigációs lépések sikeres elvégzését pedig a db_status változó jelezze. Adott a következő hálós adatmodell, a feladatokat ezen oldjuk meg!
28. oldal Az A40-es raktárhelyen lévő termékek neve, mennyisége: p 1 Rhkód= A40 (Raktárhely) while (db_status = = 0) { m 1 (Rh, Készlet) while (db_status = = 0) { o (Tk, Készlet) print(tnév, Menny) m n (Rh, Készlet) } p n Rhkód= A40 (Raktárhely) } Összesen mekkora mennyiség van a Gumikolbász nevű termékből? szum=0 p 1 Tnév= Gumikolbász (Termék) while (db_status = = 0) { m 1 (Tk, Készlet) szum=szum+menny m n (Tk, Készlet) } print(szum) } 1.10.1 Feladat: Mely raktárhelyeken van 10000 Ft-nál drágább termék? 1.10.1 Feladat megoldása: p 1 EgysÁr>10000 (Termék) while (db_status = = 0) { m 1 (Tk, Készlet) while (db_status = = 0) { o (Rh, Készlet) print(rhkód) m n (Tk, Készlet) } p n EgysÁr>10000 (Termék) }
29. oldal 1.10.2 Feladat: Mely raktárhelyeken mekkora mennyiség van a Gumikolbász nevű termékből? 1.10.2 Feladat megoldása: p 1 Tnév= Gumikolbász (Termék) while (db_status = = 0) { m 1 (Tk, Készlet) while (db_status = = 0) { o (Rh, Készlet) print(rhkód, Menny) m n (Tk, Készlet) } pn 1 Tnév= Gumikolbász (Termék) } 1.10.3 Feladat: Hányféle termék van az A40-es raktárhelyen? 1.10.3 Feladat megoldása: db=0 p 1 Rhkód= A40 (Raktárhely) while (db_status = = 0) { m 1 (Rh, Készlet) db=db+1 m n (Rh, Készlet) } print(db) } 1.10.4 Feladat: Mekkora értékű készlet van az A40-es raktárhelyen? 1.10.4 Feladat megoldása: Érték=0 p 1 Rhkód= A40 (Raktárhely) while (db_status = = 0) { m 1 (Rh, Készlet) while (db_status = = 0) { o (Tk, Készlet) Érték=Érték+Menny*EgysÁr m n (Rh, Készlet) } print(érték) }
30. oldal 1.11. Relációs algebra Olyan lekérdező nyelv, mely a matematika halmazelméletén alapul. Csak lekérdezésekre használható, az eredmény mindig egy új reláció. Műveletek, jelük, jelentésük: Szelekció: feltétel (R) feltételes rekordkiválogatás Projekció: mezőlista (R) mezőlista szűkítés Join: R1 R2 relációk összekapcsolása Alap join: R1x R2 relációk teljes összekapcsolása Szelekciós join: R1 feltétel R2 a feltételnek megfelelő rekordpárosok Equijoin: R1 = R2 az azonos elnevezésű mezők rekordpárosai Natural join: R1 * R2 az azonos elnevezésű mezők rekordpárosai, ismétlődés nélkül Outer join: R1 + feltétel R2 a feltételnek megfelelő rekordpárosok, és az illeszkedő pár nélküli rekordok, a túloldalon üres étékekkel kiegészítve (left, right, full típusok) Kiterjesztés: mezőlista (R) reláció kibővítése származtatott mezőkkel Aggregáció: aggregációs-lista (R) összesítő érték előállítása Sum, Halmazműveletek: unió R1 R2, metszet R1 R2, különbség R1 \ R2, hányados R1 R2 Adott a következő relációs modell, a feladatokat ezen kell megoldani. Magyarázat: a projektek egy havi időtartamúak, általában minden hónapban újraindulnak, így a dátum mindig az adott hónap első napja. A projektben a Tbér az egy havi teljesítménybér. 1.11.1. Feladatsor 1. Adja meg az osztályok nevét! 2. Adja meg a könyvelés dolgozóinak nevét, alapbérét! 3. Hány Osztály van? 4. Hányan dolgoznak a könyvelésen? 5. Kik vettek részt a 2010 májusi raktártakarítás projektben? 6. Adja meg a legnagyobb teljesítménybérű projektben részt vevők nevét! 7. Kik nem vettek még részt projektben? 8. Összesen mennyibe került már a fásítás projekt? 9. Hányan vettek részt a 2010 májusi projektekben projektenként? 10. Ki vett részt már legalább ötször projektekben? 1.11.1. Feladatsor megoldása: 1. П Onév (Osztály) 2. П Dnév, Alapbér (σ Onév= könyvelés (Dolgozó * Osztály)) 3. Γ count(*) (Osztály) Azt írja ki, hány darab rekord van az Osztály relációban.
31. oldal 4. Γ count(*) (σ Onév= könyvelés (Dolgozó * Osztály)) A dolgozó és az osztály rekordpárosaiban hányszor fordul elő olyan rekord, ahol az osztálynév könyvelés. 5. П Dnév, (σ Pnév= raktártakarítás AND Dátum= 2010.05.01 ((Dolgozó * Részt vesz) * Projekt )) 6. П Dnév, (σ Tbér= Γ max(tbér) (Projekt) ((Dolgozó * Résztvesz) * Projekt )) 7. П Dnév (Dolgozó) \ П Dnév (Dolgozó * Résztvesz) Az összes dolgozó nevéből kivonjuk a projektekben részt vettek nevét. 8. Γ sum(tbér) ( σ Pnév= fásítás (Résztvesz * Projekt )) 9. Γ Pnév Pnév, count(*) (σ Dátum= 2010.05.01 (Résztvesz * Projekt )) 10. П Dnév (σ db>=5 (Γ Dnév Dnév, count(*) db (Dolgozó * Résztvesz))) 1.11.2. Feladatsor A relációk ugyanazok, de a mezőnevek megváltoztak! 1. Adja meg a könyvelés dolgozóinak nevét, alapbérét! 2. A pénztárosok mely projektekben vettek részt 2010 májusában? 3. Mennyi volt a fizetése Kiss Dezsőnek 2010 májusában? 4. Az egyes osztályokon hány miskolci dolgozó van? 5. Az egyes projekteken dolgozóknak mennyi az átlagéletkora? 6. Van olyan projekt, amelynek neve megegyezik egy osztály nevével? 7. Ki (név és osztály) és mikor vett részt fásítás projekten? 8. A projekteken részt vettek közül kinek a legmagasabb az alapbére? 9. Ki hány projekten vett már részt? 10. Adja meg annak a dolgozónak a nevét, aki 2010 májusában az alapbére felénél több jövedelmet szerzett projektekből! 1.11.2. Feladatsor megoldása: 1. П Dolgozó.Név, Alapbér (σ Osztály.Név= könyvelés (Dolgozó Oszt=Osztály.Kód Osztály)) 2. Megoldás az alap join felhasználásával: П Projekt.Név (σ Dátum= 2010.05.01 AND Beosztás= pénztáros AND Dolgozó.Kód=Résztvesz.Dolg AND Résztvesz.Proj=Projekt.Kód (Dolgozó x Résztvesz x Projekt )) 2. Megoldás szelekciós joinnal: П Projekt.Név (σ Dátum= 2010.05.01 AND Beosztás= pénztáros ((Dolgozó Dolgozó.Kód=Résztvesz.Dolg Résztvesz) Résztvesz.Proj=Projekt.Kód Projekt )) 3. Alapbér+ Γ sum(tbér) (σ Dátum= 2010.05.01 AND Dolgozó.Név= Kiss Dezső ((Dolgozó Dolgozó.Kód=Résztvesz.Dolg Résztvesz) Résztvesz.Proj=Projekt.Kód Projekt )) 4. Γ Osztály.Név Osztály.név, count(*) (σ Város= Miskolc (Dolgozó Oszt=Osztály.Kód Osztály)) 5. Γ Projekt.Név Projekt.név, avg(kor) ((Dolgozó Dolgozó.Kód=Résztvesz.Dolg Résztvesz) Résztvesz.Proj=Projekt.Kód Projekt )) 6. П Osztály.Név (σ Osztály.Név=Projekt.Név (((Osztály Osztály.Kód=Oszt Dolgozó) Dolgozó.Kód=Résztvesz.Dolg Résztvesz) Résztvesz.Proj=Projekt.Kód Projekt ))
32. oldal 7. П Osztály.Név, Dolgozó.Név, Dátum ( σ Projekt.Név= fásítás (((Osztály Osztály.Kód=Oszt Dolgozó) Dolgozó.Kód=Résztvesz.Dolg Résztvesz) Résztvesz.Proj=Projekt.Kód Projekt )) 8. П Dolgozó.Név, Alapbér ( σ Alapbér= Γ max(alapbér) (Dolgozó Dolgozó.Kód=Résztvesz.Dolg Résztvesz) Dolgozó) 9. Γ Dolgozó.Név DolgozóNév, count(*) (Dolgozó Dolgozó.Kód=Résztvesz.Dolg Résztvesz) 10. П Dolgozó.Név ( σ Dátum= 2010.05.01 AND Alapbér/2< Γ sum(tbér) (σ D.kód=Dolg (Résztvesz) Résztvesz.Proj=Projekt.Kód Projekt ) Dolgozó D ) 2. SQL feladatok Structured Query Language az adatbázis kezelő rendszerek szabványosított nyelve. Utasításai négy nagy csoportba sorolhatók: 1. Data Definition Language adat meghatározó nyelv: Create létrehozás: create table táblanév(mezőnév típus integritási feltételek, ); Alter módosítás: alter table táblanév add modify (mév tip intfelt, ); Drop törlés: drop table táblanév; 2. Data Manipulation Language adatkezelő nyelv: Insert adat felvitel: insert into táblanév(érték, ); Delete adat törlés: delete from táblanév feltétel; Update adat módosítás: update táblanév set mezőnév=érték feltétel; 3. Data Query Language adat lekérdező nyelv: Select adat kiválasztás: select mezőnevek from táblanév feltétel; 4. Data Control Language adat felügyelő nyelv (felhasználói jogosultságok): Grant jogosultság adás: grant művelet on táblanév to felhasználó; Revoke jogosultság visszavonás: revoke on táblanév from felhasználó; Deny jogosultság megtagadás: deny művelet on táblanév to felhasználó; 2.1. Feladatsor A feladatokat az alábbi modellnek megfelelően kell megoldani. Magyarázat: a projektek egy havi időtartamúak, általában minden hónapban újraindulnak, így a dátum mindig az adott hónap első napja. A projektben a Tbér az egy havi teljesítménybér, az aktív mező értéke I vagy N lehet. Ha I, akkor fel lehet iratkozni rá. 2.1.1. Feladat: hozza létre a táblákat! A projekt táblában a tbér értéke nem érheti el a 30000 Ft-ot, az aktív mezőbe pedig csak az I és az N betűket lehessen bevinni. A Dolgozó táblában a kor 18 és 62 év közötti lehet, az alapbér pedig nem lehet 85000-nél kevesebb. A Résztvesz táblában írjuk elő, hogy egy dolgozó egy projektre egy adott hónapban csak egyszer jelentkezhessen.
33. oldal 2.1.1. Feladat megoldása: Az egyes feladatoknál az SQL92-nek megfelelő elvi megoldást adom meg, de ettől az egyes adatbázis kezelő rendszerek az implementációban, a konkrét megvalósításban eltérhetnek. A jegyzetben található konkrét megoldásokhoz a Microsoft SQL Server 2005-ös rendszerében implementált SQL nyelvet használtam. Create table Osztály( Kód char(3) primary key, Név char(20)); Create table Projekt( Kód char(3) primary key, Név char(20), Tbér numeric(5) check (Tbér<30000), Aktív char(1) check (Aktív in('i','n'))); Create table Dolgozó( Kód char(3) primary key, Név char(20), Város char(20), Beosztás char(20), Kor numeric(2) check (Kor between 18 and 62), Alapbér numeric(6) check (Alapbér>85000), Oszt char(3) not null references Osztály); Create table Résztvesz( Dolg char(3) not null references Dolgozó, Dátum date, Proj char(3) not null references Projekt, unique (Dolg, Dátum, Proj)); Az unique előírás így megadva azt jelenti, hogy az adott mezőket együtt figyelve nem lehet ismétlődés, vagyis egy dolgozókód egy adott dátummal az adott projekt mellett csak egyszer fordulhat elő. 2.1.2. Feladat Utasítás: ne a dátumot tároljunk a Résztvesz táblában, hanem számként az évet és a hónapot. Törljük a táblát, és hozzuk létre ennek megfelelően. Alakítsuk úgy ki a hónap mezőt, hogy csak a hónapoknak megfelelő számok kerülhessenek bele. 2.1.2. Feladat megoldása:
34. oldal Drop table Résztvesz; Create table Résztvesz( Dolg char(3) not null references Dolgozó, Év numeric(4), Hónap numeric(2) check (Hónap between 1 and 12), Proj char(3) not null references Projekt, unique (Dolg, Év, Hónap, Proj)); 2.1.3. Feladat: Írjunk elő olyan megszorítást, hogy az év 2011 és 2020 között lehessen! Miután megoldottuk, újabb utasítás: az év inkább 2010 és 2020 között lehessen! 2.1.3. Feladat megoldása: alter table Résztvesz add constraint évellenőr check (Év between 2011 and 2020) alter table Résztvesz drop constraint évellenőr alter table Résztvesz add constraint évellenőr check (Év between 2010 and 2020) 2.1.4. Feladat: Írjon elő olyan feltételt, hogy egy projektre maximum négyen jelentkezhessenek. Írja elő azt a feltételt is, hogy csak aktív projektre lehessen jelentkezni! 2.1.4. Feladat megoldása: Create assertion maxlétszám check (SELECT count(dolg) from Résztvesz group by Év, Hónap, Proj having count(dolg)>4)=0; Jelentése:azon csoportok száma, ahol a projekten 4-nél többen dolgoznak nulla kell legyen! Create assertion aktívprojekt check (SELECT count(*) from résztvesz, projekt where proj=kód and aktív='n')=0 Azon rekordok száma a résztvesz táblában, ahol a projekt nem aktív, nulla kell legyen! Az előírások elvileg működnek, gyakorlatilag az assertion parancsot a nagyobb adatbázis kezelő rendszerek nem implementálták. Ehelyett használhatók olyan triggerek, amelyek adatbeszúráskor ellenőrzik az előírt feltételeket, és ha nem teljesednek, akkor visszavonják a kiadott insert utasítást. (Ez a rollback parancs, bővebben később!) CREATE TRIGGER maxlétszám ON résztvesz FOR INSERT AS IF (SELECT count(dolg) from Résztvesz group by Év, Hónap, Proj having count(dolg)>4) >0 ROLLBACK; CREATE TRIGGER aktívprojekt ON résztvesz FOR INSERT AS IF (SELECT count(*) from résztvesz, projekt where proj=kód and aktív='n')>0 ROLLBACK; 2.2.1. Feladat: vigye fel az alábbi adatokat az osztály táblába:
35. oldal b01-bolt, b02-bérügy, s01-számlázás, s02-szállítás, r01-raktár. 2.2.1. Feladat megoldása: Az első rekordot beszúró parancs: insert into Osztály values('b01', 'Bolt'); - a többi parancs ugyailyen szintaktikájú. 2.2.2. Mi az eredménye a következő parancsoknak? Működnek? Hibásak? Miért? a) insert into Osztály values('b01', 'Beszerzés'); b) insert into Osztály values('b03'); c) insert into Osztály values('b03', ); d) insert into Osztály values('b03', null); e) insert into Osztály (Kód) values('b04'); 2.2.2. Feladat megoldása: a) A parancs hibás, mert van már b01 kódú rekord, és az elsődleges kulcs előírás egyben egyediséget is jelent. b) Hibás, a values után minden értéket meg kell adni, itt kimaradt az osztály neve. c) Hibás, így nem lehet üres értéket megadni. d) Működik, így kell az üres értéket megadni. e) Működik, így lehet nem teljes adatsort felvinni. 2.2.3. Feladat: Vigyen be minden táblába néhány rekordot! 2.2.3. Feladat megoldása: insert into Dolgozó values('d44', 'Kék Alma', 'Miskolc', 'számlázó', 31, 180000, 's01'); insert into Dolgozó values('d09', 'Zöld Galamb', null, 'eladó', 27, 85000, 'b01'); insert into Dolgozó values('d16', 'Fekete Farkas', 'Eger', 'raktáros', null, 160000, 'r01'); insert into projekt values('fas', 'Fásítás', 10000, 'I') insert into projekt values('bt2', 'Bolt takarítás', 29000, 'N') insert into projekt values('rt1', 'Raktár takarítás', 10000, 'I') insert into résztvesz values ('d12', 2010, 9, 'fas') insert into résztvesz values ('d33', 2010, 10, 'rt1') insert into résztvesz values ('d04', 2010, 12, 'rt1') 2.2.4. Kiadjuk egymás után a következő három parancsot: 1. insert into Dolgozó values('d66', 'Barna Barna', null, 'számlázó', 31, 180000, 's01'); 2. insert into Dolgozó (Kód, Név, Beosztás, Kor, Alapbér, Oszt) values('d67', 'Fehér Hannibál', 'számlázó', 31, 180000, 's01'); 3. update dolgozó set Város='Miskolc' where Város is null; Kérdések: a) Az update parancs hatására mindkét rekordban megváltozik a város Miskolcra? b) Hogyan lehet a d25 és a d32 közötti kódú rekordokban kijavítani a várost Miskolcra? c) Hogyan lehet kitörölni Kék Alma rekordjából a várost? d) Hogyan lehet évváltáskor mindekinél a kort megnövelni 1-el? e) Mindig, minden rekordra működik az előző parancs?
36. oldal f) Hogyan lehet kitörölni Kék Alma rekordját? g) Bármikor ki lehet törölni Kék Almát? 2.2.4. Feladat megoldása: a) Igen, a nem megadott és a null-ként bevitt érték egyformán viselkedik. b) update dolgozó set Város='Miskolc' where Kód between 'd25' and 'd32'; c) update dolgozó set Város=null where Név='Kék Alma'; d) update dolgozó set Kor=Kor+1; e) Nem, az előző parancs csak akkor módosítja a rekordot, ha a kor módosítás után nem éri el a 62-t, erről gondoskodik a korra előírt check feltétel. f) delete from dolgozó where Név='Kék Alma'; g) Nem lehet bármikor törölni a rekordot: ha Kék Alma kódja szerepel a résztvesz táblában mivel ott idegen kulcs a rekord a dolgozó táblából nem törölhető. 2.3.1. Adja meg a következő lekérdezéseket megvalósító SQL parancsokat! a) A nem Béla keresztnevű raktárosok vagy eladók neve b) Hány olyan dolgózó van, akinek a kódjában a középső karakter 2-es? c) A 2010 3. negyedévében futó projektek neve (egy név csak egyszer szerepeljen!) d) Osztályok és dolgozóik neve, abc sorrendben e) A 04-re vagy 07-re végződő kódú 30-as korú dolgozók neve, alapbére, alapbér szerinti csökkenő sorrendben 2.3.1. Feladat megoldása: a) Select név from dolgozó where név not like '% Béla' and beosztás ='eladó' or név not like '% Béla' and beosztás='raktáros'; b) select count(*) from dolgozó where kód like '_2_'; c) Select distinct név from projekt, résztvesz where proj=kód and év=2010 and hónap in (7, 8, 9); A distinct kulcsszó biztosítja az egyediséget, ezért egy név csak egyszer íródik ki. d) Select osztály.név, dolgozó.név from osztály, dolgozó where oszt=osztály.kód order by osztály.név, dolgozó.név; e) Select név, alapbér from dolgozó where kód like '_04' and kor like '3_' or kód like '_07' and kor like '3_' order by alapbér desc; 2.3.2. Adja meg a következő lekérdezéseket megvalósító SQL parancsokat! a) A bérügy dolgozóinak neve, éves alapfizetése b) Az összes különböző beosztás kiírása (csak létező beosztások!) c) A raktáros beosztásúak átlag alapbére d) A nem miskolci dolgozók száma, városonként csoportosítva e) A legmagasabb alapbérű dolgozó(k) neve, alapbére 2.3.2. Feladat megoldása: a) Select dolgozó.név, 12*alapbér Éves_alapfizetés from osztály, dolgozó where oszt=osztály.kód and osztály.név='bérügy'; b) Select distinct beosztás from dolgozó where beosztás is not null; c) Select avg(alapbér) from dolgozó where beosztás='raktáros'; d) Select város, count(*) from dolgozó where város!= 'Miskolc' group by város; e) Select név, alapbér from dolgozó where alapbér = (select max(alapbér) from dolgozó);
37. oldal 2.3.3. Feladat. Mi az eredménye a következő SQL parancsoknak? a) Select osztály.név, avg(alapbér) from osztály, dolgozó where oszt=osztály.kód group by osztály.név order by avg(alapbér); b) select dolgozó.név from dolgozó, résztvesz, projekt where dolg=dolgozó.kód and proj=projekt.kód and projekt.név='fásítás'; c) select név from dolgozó where név not in(select dolgozó.név from dolgozó, résztvesz, projekt where dolg=dolgozó.kód and proj=projekt.kód and projekt.név='fásítás'); d) select osztály.név, projekt.név from osztály, dolgozó, résztvesz, projekt where oszt=osztály.kód and dolg=dolgozó.kód and proj=projekt.kód and év=2010 and hónap=12 group by osztály.név, projekt.név; e) Select dolgozó.név, sum(tbér)+sum(alapbér)/count(alapbér) from dolgozó, résztvesz, projekt where dolg=dolgozó.kód and proj=projekt.kód and év=2010 and hónap=12 group by dolgozó.név; 2.3.3. Feladat megoldása: a) Osztályok szerinti átlagfizetés, átlagfizetés szerinti növekvő sorrendben b) Azok neve, akik dolgoztak már a fásítás projektben c) Azok neve, akik nem dolgoztak még a fásítás projektben d) 2010 decemberében mely osztályok, milyen projektekben vettek részt e) A 2010, decemberi fizetések: alapbér és a projektek után járó teljesítménybér. 2.3.4. Adja meg a következő lekérdezéseket megvalósító SQL parancsokat! a) Azon osztályok neve és létszáma, ahol 10-nél kevesebben dolgoznak b) A legmagasabb átlagos alapbérű osztály neve, és átlag alapbére c) Az egyes osztályokon hány 300000 Ft-nál többet kereső személy van d) Az egyes projektekre hányszor jelentkeztek (kellenek azok a projektek is, amelyekre még sosem jelentkeztek!) e) Kék Alma az egyes projektekre hányszor jelentkezett (kellenek azok a projektek is, amelyekre még sosem jelentkezett!) f) Ki hány projektekre jelentkezett már (azok neve is kell, akik még nem jelentkeztek sosem projektre!) g) Az egyes osztályokról hányszor jelentkeztek már projektre (azon osztályok neve is kell, ahonnan még sosem jelentkeztek projektre!) 2.3.4. Feladat megoldása: a) Select osztály.név, count(oszt) from osztály, dolgozó where oszt=osztály.kód group by osztály.név having count(oszt) <10; b) create view osztatlagfiz as select oszt, avg(alapbér) átlag from dolgozó group by oszt; select oszt, átlag from osztatlagfiz where átlag=(select max(átlag) from osztatlagfiz); Ha már nem kell: drop view osztatlagfiz; c) select osztály.név, count(*) from osztály join dolgozó on oszt=osztály.kód where alapbér>300000 group by osztály.név; d) select projekt.név, count(proj) from projekt left outer join résztvesz on projekt.kód=proj group by projekt.név; e) select projekt.név, count(proj) from projekt left outer join résztvesz on projekt.kód=proj left outer join dolgozó on dolg=dolgozó.kód and dolgozó.név='kék Alma' group by projekt.név; f) select név, count(dolg) from dolgozó left outer join résztvesz on dolgozó.kód=dolg group by név;
38. oldal g) select osztály.név, count(dolg) from osztály left outer join dolgozó on osztály.kód=oszt left outer join résztvesz on dolgozó.kód=dolg group by osztály.név; 2.4. Adja meg a szükséges SQL parancsokat! a) Engedélyezze Péter5-nek, hogy lekérdezzen a dolgozó táblából. b) Engedélyezze mindenkinek a lekérdezést a dolgozó táblából. c) Engedélyezze a beszúrást és a módosítást Péter5-nek a projekt és a résztvesz táblára. d) Vonja vissza a beszúrás jogot a projekt tábla esetén Péter5-től. e) Tiltsa le Péter5 minden jogát a résztvesz táblával kapcsolatban. f) Engedélyezze Péter5-nek, hogy lekérdezzen a résztvesz táblából. 2.4. Feladat megoldása: a) Grant select on dolgozó to Péter5; b) Grant select on dolgozó to public; c) Grant insert, update on projekt, résztvesz to Péter5; d) Revoke insert on projekt from Péter5; e) Dany all on résztvesz to Péter5; f) Először meg kell szüntetni a Dany hatását: Revoke all on résztvesz to Péter5; ezután engedélyezni a lekérdezést: Grant select on résztvesz to Péter5;