Adatbázis tanfolyam 1. Adatbázis tervezés. Modellezés, példák

Átírás

1 Adatbázis tanfolyam 1. Adatbázis tervezés Modellezés, példák 145/1 B ITv: MAN

2 Rólam 145/2 Szűcs Miklós Alias: BitMan Mesteroktató ME. Informatika épület, 108-as szoba bitman.uw.hu users.iit.uni-miskolc.hu/~szucs/ Szakterület: Programozás Adatbázisok

3 Adatbázis tervezés Alkalmazás tervezés Adatbázistól függő feladatok Adatbázistól független feladatok Minivilág Miről szól a tanfolyam? Követelmények összegyűjtése, elemzése Adatok Funkcionális követelmények Fogalmi tervezés Funkcionális elemzés Koncepcionális adatmodell Funkcionális terv Logikai tervezés Adatbázis adatmodell Program tervezése Fizikai tervezés Tranzakciók elkészítése 145/3 Adatbázis Alkalmazói program

4 Minivilág Határozzuk meg azokat az adatokat, amiket tárolni akarunk Ehhez szükséges tudnunk az adatbázis célját, vagyis azokat a feladatokat, amikre az adatokat használni akarjuk 145/4 Pl. termékek előállítása, kereskedelme termékek alkatrészei, építőelemei, azok készletei beszállítók adatai, megrendelések, beszállítások gyártási folyamatok szükségletei, ütemezései késztermékek aktuális mennyiségei megrendelések, megrendelők, kiszállítások milyen munkahelyen milyen lekérdezésekre lesz szükség kinek milyen folyamatokhoz lesz köze, mire lesz joga, szüksége Szükséges rögzíteni az összes információt, körülményt, és mindent egyeztetni a fejlesztőknek a megrendelőkkel!

5 Adatok Adatgyűjtés: egyszerűnek hangzik, de nagyon összetett feladat. Ha vannak olyan nyomtatványok, táblázatok, amiket most használnak az adatok tárolására, továbbítására (pl. megrendelések, számlák, szállítólevelek), akkor ezeket össze kell gyűjteni. Az összes olyan folyamatot, ami adatokat használ (megrendelés, beszállítás, havi jelentés ) össze kell gyűjteni, a felhasznált adataikkal, funkciójukkal, kapcsolataikkal együtt. A használt eljárásokat, bevett szokásokat, módszereket is le kell írni az egyes folyamatok mellé (orgware). Pl. színkódokat használnak a raktárban (milyen színt, mikor, mire alkalmaznak) Az összegyűjtött adatokat, folyamatokat, eljárásokat csoportosítani, rendszerezni kell. Ez lesz az alapja az adatbázis fogalmi modelljének. Az adatbázis céljától eltérő adatokat meg kell próbálni kizárni! 145/5

6 Adatmodell Az összegyűjtött adatokat egy jól megválasztott adatmodell segítségével kell rögzíteni. Ez egyelőre egy koncepcionális modell, ami független a konkrét adatbázistól. Az adatmodellek általában nem írják le teljesen és abszolút pontosan a modellezett rendszert, sajnos kompromisszumokra kényszerülünk. A modellezés folyamán az egyes adatokból egyedeket (tárolási egységeket) alakítunk ki, és meghatározzuk az egyedek közötti kapcsolatokat. E modell ismeretében lehet kiválasztani az adatbázis elkészítéséhez, üzemeltetéséhez leginkább megfelelő adatbáziskezelő rendszert. A valós világhoz képest az adatmodellek tartalmaznak bizonyos megszorításokat és egyszerűsítéseket, sőt, még a modellező személyétől függő vonásokat is. 145/6

7 Logikai tervezés A koncepcionális modell ismeretében kiválasztjuk a megfelelő adatbázis-kezelő rendszert (ABKR). A logikai tervezés egy konverziós folyamat, melynek bemenete a koncepcionális modell, kimenete pedig a kiválasztott ABKR-nek megfelelő adatbázis adatmodell. Itt képezzük le az egyedeket táblákká, meghatározzuk az egyes mezők adattípusát, megszorításait. Meghatározzuk a táblák azonosítóit, a táblák közötti kapcsolatokat, a tábla szintű megszorításokat. (Normalizálás, denormalizálás, ) Ez a modell sokkal több információt tartalmaz, mint a koncepcionális modell, pontos megalkotásához elengedhetetlenek az összegyűjtött és rendszerezett adatok, módszerek, elemzések. Egy helyesen megalkotott adatbázis adatmodell alapján pontosan, és egyszerűen (de nem 100%-ban!) elkészíthetők az adatbázis táblái, kapcsolatai. 145/7

8 Fizikai tervezés Az adatbázis tényleges elkészítése előtti fázis, ahol az ABKR-nek megfelelő módszerekkel pontosítjuk az adatbázis tervét. Pl. az adatmodell csak annyit ír elő, hogy numerikus kulcsmező legyen az ID a táblában, mi pedig eldöntjük, hogy automatikus sorszámozást fogunk alkalmazni, melynek megoldása a különböző ABKR-ekben: MySQL: id int not null auto_increment 145/8 Oracle: create sequence seq_id SQL Server: id int identity(1,1) primary key Ekkor pontosítjuk az egyes mezők típusát, megszorításait, meghatározzuk a szükséges index táblákat, nézet táblákat Bizonyos műveleteket célszerű tárolt eljárásokkal megvalósítani, szükségesek lehetnek a működést segítő triggerek, kialakíthatunk naplózó rendszert, sokfelhasználós környezetben kialakítjuk a szükséges tranzakciókat, A terv alapján 100%-ban elkészíthető a tényleges adatbázis.

9 A tervezés folyamata A folyamat természetesen nem egzakt, és szinte minden lépése külön arra specializálódott szakembert igényel. Az egyes lépések között magától értetődő visszacsatolások vannak, ha valami nem megfelelő, vissza kell lépni egy szintet, bizonyos esetekben egyes rész-műveleteket a legelejéről kell kezdeni. Minél jobban ismerik a tervezők az adatbázis használatának a módját, a használat napi, heti feladatait, annál pontosabb tervet tudnak készíteni. A tervezés egészére fordított idő, és az adatbázis elkészítésének az ideje kb. 75% - 25% viszonyban van egymással! A tervezés egy hosszú, összetett feladat, melyet sok-sok projektben való részvétellel, évek alatt lehet elsajátítani! Az alkalmazás megtervezéséről majd később esik szó. 145/9

10 Adatmodell 145/10

11 Az adatbázis fogalma Hétköznapi értelemben: valamilyen szempont szerint összegyűjtött, rendezetten tárolt adatok összessége. Nemcsak az adatok rendezett tárolását, hanem azok kezelését is lehetővé teszi. Az adatbázis adott célból összeállított adatok rendezett szerkezete, mely lehetővé teszi az adatok tárolását és visszanyerését. Adatbázis Database (DB) Az adatbázis egy integrált adatrendszer, mely több különböző egyed előfordulásainak adatait adatmodell szerinti struktúrában, perzisztens (tartós, állandósult) módon tárolja a kapcsolat leíró elemek mellett a meta adatokkal együtt, melyek a hatékonyság, integritásőrzés, az adatvédelem biztosítását szolgálják. 145/11

12 Az adatbázis fogalma Feladat: tároljuk le a cég autóinak rendszámát, típusát, színét, férőhelyét, és az autót használó dolgozó nevét, telefonját. Aki a papír alapú, vagy az Excel alapú adatkezeléshez szokott, az vesz egy "kockás papírt", és készít egy táblázatot. Aki találkozott már adatbázissal, az valószínű másként fog gondolkodni, és készít több táblázatot. 145/12

13 Fogalmak Ha egy adatot több helyen is tárolunk, redundáns lesz az adathalmazunk. A redundancia a szükséges minimális adatmennyiségen felüli fölösleges többlet adatok tárolását jelenti. Pl. Kiss Ernő telefonszáma redundáns adat. A redundancia miatt nagy az inkonzisztencia (ellentmondás, következetlenség) veszélye, ha az egyik helyen véletlenül Kis Ernőt írunk, oda az adataink hihetősége! 145/13

14 Fogalmak Ez a felosztás nem redundáns. Ettől már alkalmas az adatok tárolására? Nem! Ezen felosztás alapján elkezdhetjük megtervezni az adatbázis fogalmi modelljét, ami az adatbázis általános logikai struktúráját adja meg, amely független bármilyen szoftvertől (adatbáziskezelő rendszertől) vagy tárolási struktúrától. Az adatbázis létrehozását mindig egy tervezési fázis előzi meg. Az adatbázis teljes elkészítési idejét figyelembe véve a tervezésre fordított idő kb. 75 %! Alapos tervezés nélkül a rendszer átláthatatlan lesz, nagyon nehéz lesz a későbbiekben módosítani! Az adatok jellegének vizsgálata és a köztük levő kapcsolatok alapos elemzése után következhet az adatmodell létrehozása. 145/14

15 Adatmodell Az adatmodell megalkotása az adatbázis tervezésének egy korszerű eszköze. Egy jól megalkotott adatmodell alapján könnyen és pontosan elkészíthetők az adatbázis táblái, és egyszerűen definiálhatók a táblák közötti kapcsolatok. Az adatmodell a valóság egy szeletének a leképezését jelenti. Az adatmodellek általában nem írják le teljesen és abszolút pontosan a modellezett rendszerben található adatokat és azok kapcsolatait, sajnos kompromisszumokat kell kötnünk. A valós világhoz képest az adatmodellek tartalmaznak bizonyos megszorításokat és egyszerűsítéseket, sőt, még a modellező személyétől függő vonásokat is. 145/15

16 Adatmodell Egy kielégítő modellnek teljesítenie kell a következő feltételeket: átfogónak kell lennie, azaz minden lehetséges adatot és minden lehetséges kapcsolatot tudnia kell ábrázolni és kezelni, le kell tudnia írni a valóság általános, lényeges és tartós összefüggéseit, redundanciamentesnek kell lennie, azaz minden adatot lehetőleg csak egyszer tartalmazhat, következetesnek kell lennie; valamint az alkalmazott hardverrel és szoftverrel összhangban levőnek kell lennie 145/16

17 Adatmodellek komponensei Strukturális rész: az adatbázis logikai felépítése (adatok, tulajdonságok, kapcsolatok leírása) Integritási rész: az adatokra, a kapcsolatokra és a műveletekre vonatkozó előírások, megszorítások Műveleti rész: milyen műveletek végezhetők az adatokon, és hogyan A szemantikai adatmodellek csak a strukturális rész leírására szolgálnak Az adatbázis adatmodellek mindhárom komponenst megvalósítják 145/17

18 Az adatmodell strukturális elemei Egy adatmodell a következő elemeket tartalmazza: egyed, tulajdonság, kapcsolat. Egyed: az a "dolog", amiről adatokat (információkat) fogunk letárolni. Az egyedek konkrét előfordulásai egy ún. egyedtípust alkotnak. Pl. egyedtípus egy autó, melynek egy előfordulás az ABC-123 rendszámú példány. Tulajdonság: azok a jellemzők, amivel leírjuk az egyedet. Pl. az autó rendszáma, típusa, színe Kapcsolat: két egyed közötti viszony, összefüggés. Pl. az autó és a dolgozó közötti viszony azt jelenti, hogy az adott autót az adott dolgozó használja 145/18

19 Adatmodellek típusai Szemantikai adatmodellek: emberközeli, lényeget emelik ki, pontatlan ER, EER, IFO, UML Név Versenyautók Versenyzők Lóerő Név Autó Pilóta Autó Adatbázis adatmodellek: gépközeli, megadja a részleteket, teljes 145/19 Hierarchikus, Hálós, Relációs, Objektum-orientált Szín Autó Lóerő Szín RedBull 650 sárga Mercedes 710 zöld Renault 680 piros Kor Pilóta Autó Kor Miki RedBull 30 Niki Mercedes 23 Riki Renault 26

20 Az ER (Entity Relationship) modell Egyed Kapcsolat modell Kidolgozója: Peter Pin-Shan Chen (1976) Egyszerűsített szemantikai adatmodell Csak strukturális részt és elemi statikus integritási részt tartalmaz Egyszerű grafikus jelölésrendszert alkalmaz Nem teljes adatmodell, de egyszerűsége révén elterjedt, és ma is széles körben használatos Tervezési segédeszköz a relációs adatbázis tervezéséhez 145/20

21 Egy ER modell Kód Név VID Név Vásárlás Termék Vásárló Kor Ár Méret Dátum Darab Lakcím Szül.Idő IrSz. Város Utca Házszám 145/21

22 ER modell 3 fő komponens: Egyed Kapcsolat Tulajdonságok E_név K Tulajd. Téglalap, benne az egyedtípus neve Rombusz, benne a kapcsolat neve, melyből nyilak mutatnak az összekapcsolt egyedekre Ellipszis, a tulajdonság nevével. Vonal kapcsolja az egyedhez. Kód Név NKód Név Tankör Tagja Tanuló 145/22 Leírás Év Lakcím Szül.Idő

23 Egyed elem az ER modellben Egyed Egyed: A külvilág többi részétől egyértelműen megkülönböztetett, önálló léttel bíró dolog, amiről az információkat tárolni kívánjuk. Az adatbázisban nem adatként, hanem az összetartozó adatokat összefogó tárolóként (adatszerkezetként) jelenik meg Típusai: Erős (normál) egyed: önmagában egyértelműen azonosítható, pl. dolgozó (dolgozó azonosító), autó (rendszám) Gyenge egyed nincs olyan saját azonosító kulcsa, mely egyértelműen meghatározza (csak részleges kulcsuk van), ezért más egyedhez való kapcsolatán keresztül azonosított. Pl. könyv fejezete, rendelés egyik tétele 145/23 Egyed neve Erős egyed jelölése Egyed neve Gyenge egyed jelölése

24 Tulajdonság elem az ER modellben Tulajd. Tulajdonság: Az egyedeket, kapcsolatokat jellemző mennyiség, mely a letárolandó információelemeket tartalmazza (ezek lesznek az egyedekről letárolt adatok) Jelölése: ellipszis, benne a tulajdonság Dkód Név elnevezése. A rajzon vonallal kapcsolódik a jellemzett egyedhez Dolgozó Cím Kor Irsz Város U.hsz 145/24 Típusai: Kulcs (azonosító) tulajdonság Minden egyednél más értékű, értéke tehát nem ismétlődhet Kötelező megadni minden előfordulásban Jelölése: az elnevezés aláhúzásával Általában egyetlen tulajdonság, de lehet összetett is

25 Tulajdonság elem az ER modellben Tulajd. Dkód Név Dolgozó Cím Kor Irsz Város U.hsz 145/25 Normál tulajdonság Egyértékű Több egyed előfordulásban is lehet ugyanaz (pl. szín: fekete) Sima felirat az ellipszisben Összetett tulajdonság Több normál tulajdonságból áll Egy összefogó tulajdonság tartja egyben az elemi tulajdonságokat Származtatott tulajdonság Más tulajdonságokból előállítható Pl. a kor az aktuális dátumból, és a születési időből Jele: szaggatott körvonalú ellipszis

26 Tulajdonság elem az ER modellben Tulajd. Dkód Dolgozó Nyelv Név Többértékű tulajdonság Egy egyed előforduláshoz több érték is tartozhat Pl. nyelvismeret, vagy egy termék tárolási helye a raktárban Jele: dupla körvonalú ellipszis A tulajdonságok jellege Lehet kötelező, vagy opcionális Ebben a modellben ez nem jelölhető 145/26

27 Kapcsolat elem az ER modellben 1. K Kapcsolat: Két (vagy több) egyedtípus egyedei között fennálló viszony. Pl. Dolgozó -> dolgozik <- Részleg A kapcsolat jele egy rombusz, amit nyilak kapcsolnak a viszonyban álló egyedekhez Dolgozó dolgozik Részleg Van olyan jelölésmód is, amiben csak vonalakkal kapcsoljuk össze az egyedeket A kapcsolatok jellemzői: Kötelező vagy sem, Az összekapcsolt egyed előfordulások száma (számosság) 145/27

28 Kapcsolat elem az ER modellben 2. K Kötelező jelleg szerinti típusok: Opcionális: létezik olyan egyed-előfordulás, mely nem vesz részt a kapcsolatban Jele szimpla szárú nyíl Könyv olvas Pl. személy <-> útlevél Nevezik részleges kapcsolatnak is Kötelező: minden egyed-előfordulás részt vesz a kapcsolatban Jele dupla szárú nyíl azon az oldalon, ahol kötelező a részvétel Rendelés Pl. Megye <-> Település rendel Olvasó Nevezik teljes, vagy totális kapcsolatnak is (Egy rendeléshez kötelező árunak tartoznia, de egy árunak nem kötelező részt vennie rendelésben) Áru 145/28

29 Kapcsolat elem az ER modellben 3. K Az összekapcsolt egyed-előfordulások száma szerint: 1:1 Az egyik egyedtípus egyedelőfordulásai a másik egyedtípus legfeljebb egy egyed-előfordulásával létesítenek kapcsolatot. Ország Főváros 1:N (egy-több) Az egyik egyedtípus egyedelőfordulásai a másik egyedtípus legfeljebb egy egyed-előfordulásával létesítenek kapcsolatot. A dupla nyíl a többes oldalra kerül! Tulaj Autó N:M (több-több) Mindkét egyedtípus egyed-előfordulásai a másik egyedtípus több egyed-előfordulásához kapcsolódhatnak. Mindkét oldalon dupla nyíl. 145/29 Könyv Olvasó

30 Kapcsolat elem az ER modellben 4. K Specialitások: A kapcsolatoknak is lehetnek tulajdonságai: Dolgozó dolgozik Feladat Mettől Meddig Nemcsak bináris (két egyed közötti) kapcsolatok léteznek: támogat ID Verseny Versenyző Kód Összeg A szponzor egy adott versenyen egy konkrét versenyzőt 145/30 támogat! Szponzor Sz.Az

31 Kapcsolat elem az ER modellben 5. K Létezik rekurzív (önmagára visszautaló) kapcsolat is Dkód Dnév Dolgozó Főnök felettes Egy beosztott dolgozóhoz 1 felettes tartozhat beosztott Egy feletteshez több beosztott dolgozó tartozhat 145/31

32 típus szín cím szín rendszám név kód évjárat 145/32

33 145/33 Feladat

34 ER modellezési feladat 1. Készítse el egy ruha nagykereskedés adatbázisát, az alábbiak betartásával: Tartsa nyilván a termékeket, a vásárlókat és a vásárlásokat. A vásárlásoknál tartsa nyilván a dátumot, a vásárolt darabszámot, és a vásárlás összegét. 145/34

35 ER modellezési feladat 1. Kód Név VID Név Vásárlás Termék Vásárló Ár Méret Dátum Darab Lakcím FizMód Összeg IrSz. Város Utca Házszám 145/35

36 ER modellezési feladat Értelmezze! Tkód Név Mennyiség Rhkód Rkód Leírás TermékR Készlet Raktárhely Rh-R Raktár MEgység BeDátum LejárDát Aktív Aktív 145/36

37 ER modellezési feladat Értelmezze! Dkód Dnév Tkód Téma Okód Onév Dolgozó Képzés Tanfolyam T-O Oktató Végzettség Dátum Hely 145/37

38 ER modellezési feladat Értelmezze! Dkód Név Ekód Enév Hkód Hnév Dolgozó Használ Eszköz E-H Helyszín NyelvIsm Cím IrSz. Város UHsz E-K Knév Epkód H-E Epnév Kkód Kategória Leírás Épület 145/38

39 ER modellezési feladat Értelmezze! Dkód Dolgozó Dnév D-R Kkód Leírás Rszám HatárId. Bkód Bnév Kategória Rendelés R-B Beszállító K-T Össz.Menny. R-T Dátum Cím Telsz. Tkód IrSz. Város U-Hsz Termék TR-T Tétel Tnév 145/39 MEgys. Sorszám Menny.

40 ER modellezési feladat Rajzoljon egy olyan ER modellt, melyben az A-nevű egyednek B a kulcstulajdonsága, C egy normál tulajdonsága, D pedig összetett tulajdonsága (D1, D2, D3). Az E-nevű egyednek F a kulcstulajdonsága, G és H normál tulajdonságok, I pedig többértékű tulajdonság. Egy A-egyedhez több E-egyed is tartozhat, de egy E- egyedhez csak egy A-egyed. A kapcsolatnak J egy normál, és K egy származtatott tulajdonsága. A rajzoláshoz használjon szerkesztő programot. 145/40

41 ER modellezési feladat Megoldás B C F G A A-E E D J K H I D1 D2 D3 145/41

42 ER modellezési feladat Ön a Klassz Tó Vízibicikli Kölcsönzőt vezeti (csónakokat és vízibicikliket kölcsönöz). Tervezzen és rajzoljon ER modellt, melyben a kölcsönző adatbázisát modellezi. Fontos: tárolható legyen, hogy: ki, mikor, melyik eszközt kölcsönözte ki, mikor kell visszahoznia, legyen értesítési lehetőség, ha letelt az idő. A rajzoláshoz használjon szerkesztő programot. 145/42

43 ER modellezési feladat Eszköz egyed: azonosító (1-5-ig csónak, 6-10-ig bicikli) név (piros csónak) működőképes (igen-nem) kölcsönzési díj (óránként) 145/43

44 ER modellezési feladat Kölcsönző személy egyed: azonosító (szám, egyesével növekszik) név telefonszám cím (hirdetés elküldése v. számlázás miatt) cím (irányítószám, település, utca-házszám) számlázási név számlázási cím (irányítószám, település, utcaházszám) 145/44

45 ER modellezési feladat Kölcsönzés (kapcsolat) mikortól (időpont) meddig (időpont) fizetve eszköz kölcsönző Fizetett összeg 145/45

46 ER modellezési feladat Megoldás ID Név Tól Ig KID Név Sz.név Eszköz Kölcsönzés Személy Tsz Jó Díj Fizetve Összeg Cím Sz.cím Irsz Telep UHsz Irsz Telep UHsz 145/46

47 UML szerű logikai adatmodell Eszköz ID (pk) Név Működőképes Kölcsönzési díj Tulajdonságok Kapcsolatok jelölése: Kapcsolat Egyed Kölcsönzés Mikortól Meddig Fizetve Összeg Telefon SzemélyID Telefonszám Személy SzemélyID (pk) SzemélyNév Cím Irányítószám Település Utca_házszám CégNév CégCím 1 típusú, nem kötelező kapcsolat Belül: Kívül: 1, opcionális, kötelező N N típusú, kötelező kapcsolat *UML: 145/47 (Unified Modeling Language) szabványos, általános célú modellező nyelv

48 145/48A relációs adatmodell

49 Relációs adatmodell 1960-as évek: A hierarchikus adatmodell nagyon kevés feladat megoldására alkalmas A hálós adatmodell nagyon bonyolult, nehezen programozható, lassú a kezelése, költséges Próbálkozások új adatmodellek kialakítására Ötlet: kockás papír Kód Autó Rendszám Típus Szín GBC-765 Opel Fehér JED-123 Nissan Ezüst AKT-392 Trabant Kék 145/49

50 Relációs adatmodell Edgar Frank Codd: A Relational Model of Data for Large Shared Data Banks (1970) A relációs modell fő erősségei: Egyszerű struktúra, Rugalmas kapcsolati rendszer, Hatékony műveleti rész, Egyszerű lekérdező nyelv SQL, Tetszőlegesen megadható integritási elemek. 145/50

51 Relációs adatbázis-kezelők története 1970 Codd javaslata Structured English Query Language System-R Sequel Oracle Ingres Informix DB2 RDB dbase Sybase Postgre SQL mysql SQLServer Clipper VFP SQL86 SQL89 SQL /51 Oracle Informix MS SQL Postgre MySQL SQLite mongodb TITAN cassandra SQL1999 SQL2006 SQL2008 BSQL2011 IT MAN SQL2017

52 A relációs adatmodell komponensei Relációs adatstruktúra Relációs integritási feltételek Az adatok érvényességét, megbízhatóságát, helyességét biztosítják Relációs műveletek Az adatok (lekérdezését) visszakeresését hogyan lehet megvalósítani Feltételek megfogalmazása Több reláció összekapcsolása 145/52

53 Relációs adatmodell A relációs adatbázis relációk összessége. Az egyes relációkat egyedi névvel látjuk el. A reláció egymáshoz hasonló egyedek bizonyos tulajdonságait leíró táblázat (egyed-előfordulások halmaza) A reláció egy sora egy egyedet reprezentál, az egyes oszlopokba az adott egyed tulajdonságai szerepelnek. A reláció helyett a tábla vagy táblázat, a sor helyett a rekord, az oszlop helyett pedig a tulajdonság elnevezés használatos. Egy elemi adatot mezőnek nevezünk. 145/53

54 Relációs adatmodell 2. Építő elemek: MEZŐ REKORD RELÁCIÓ ADATBÁZIS Kód Név A3 Kovács B 14 S1 Dolgozó Munkakör Munkaidő Szupercég 145/54

55 Relációs adatmodell (példa) Tábla neve: Dolgozó tulajdonság Név Szül.idő Lakcím Adószám Nagy Géza Miskolc, Új u Kis Jenő Miskolc, Ág u Kerek Béla Szeged, Cső u Vad Tamás Győr, Zár u rekord mező 145/55

56 A mezők jellemzése Domain (mezőtípus): értelmezési tartomány, mely megadja az elemhez tartozó értékkészletet, és meghatározza a végrehajtható műveletek körét. Alapvető domainek (mezőtípusok): Char(n) karakteres; C(20), Number(n,m) numerikus; N(8,2), Date dátum. Mező: az adatbázis struktúra azon egysége, melyből a rekordok felépülnek. A mező a legkisebb DB struktúra egység (egyértékű, atomi). A mezők megadásánál meg kell adni a domain-t (típust) és az integritási feltételeket. 145/56

57 A rekordok jellemzése Rekord: adatbázis struktúra elem, mely a logikailag összetartozó, és egységként kezelhető elemi adatértékek (mezők) együttesét jelöli. A rekordszerkezet leírását az ún. séma tartalmazza: Tábla neve, Mezők neve, típusa, integritási feltételei. A rekordon belül bizonyos mezők speciális szerepet töltenek be: kulcsmező, kapcsoló mezők, index mezők, ezek paramétereit is meg kell adni a sémában. A rekordhoz integritási feltételek köthetők. Kód C4,PK Autó Rendszám C7,UN Típus C20,NN Kor N2,C>0 145/57

58 A relációk jellemzői A relációk rekordjaiban tároljuk a logikailag összetartozó adatokat A relációban tárolt rekordok számát a reláció egyedszámának nevezzük. A relációk tulajdonságaiban (oszlopaiban) az azonos tulajdonságokra vonatkozó adatok jelennek meg. Egy tábla nem tartalmazhat két azonos nevű oszlopot. Az oszlopok (attribútumok) számát a reláció fokának nevezzük. Négyfokú reláció Egyedszám: kettő Azonosító Név Évfolyam Osztály 001 Kati 11 A 002 Tibi 12 B 145/58

59 A relációk jellemzői 2. Egy relációra vonatkozó követelmények: A tulajdonságok sorrendje tetszőleges lehet, de a tábla kialakítása után a mezősorrend nem változhat, így minden rekord mezőszerkezete azonos Nem tartalmazhat két azonos nevű tulajdonság oszlopot Nem lehet két teljesen egyforma rekord a táblázatban A rekordok sorrendje tetszőleges (halmazként értelmezzük) Egy cellába csak egy érték kerülhet, így a modellben közvetlenül nem tárolhatók az összetett és a többértékű tulajdonságok. 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. 145/59

60 Kapcsolatok 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. 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. Útnyilvántartás Autó Sorszám Rszám Dátum Útvonal Km Rendszám Típus Fogyaszt Kapcsoló kulcs Elsődleges kulcs 145/60

61 Kapcsolatok 2. Ha a kapcsoló kulcsot nem kötelező megadni, akkor olyan 1:1 kapcsolatot hozhatunk létre a két tábla között, amelyben nem minden rekordnak van párja a kapcsolt táblában. Útnyilvántartás Autó Sorszám Rszám Dátum Útvonal Km Rendszám Típus Fogyaszt Nem mindegyik autóhoz tartozik útnyilvántartás! Sorszám Rszám Dátum 1 ABC Rendszám Típus Fogyaszt ABC-123 Opel 8,5 FFF-663 Renault 7,2 EIS-104 Lada 12,4 DCT-432 Suzuki 6,4 145/61

62 Kapcsolatok 3. Ha a kapcsoló kulcsot kötelező megadni, és nem ismétlődhet az értéke, akkor olyan 1:1 kapcsolat van a két tábla között, amelyben minden rekordnak van párja a kapcsolt táblában. Útnyilvántartás Autó Sorszám Rszám Dátum Útvonal Km Rendszám Típus Fogyaszt Az útnyilvántartásnak autóhoz kell tartoznia! Sorszám Rszám Dátum 1 ABC EIS Rendszám Típus Fogyaszt ABC-123 Opel 8,5 FFF-663 Renault 7,2 EIS-104 Lada 12,4 DCT-432 Suzuki 6,4 145/62

63 Kapcsolatok 4. Ha a kapcsoló kulcsot kötelező megadni, és ismétlődhet az értéke, akkor 1:N kapcsolat van a két tábla között, vagyis minden rekordhoz több rekord is kapcsolódhat a kapcsolt táblában. Az ilyen típusú kapcsoló kulcsot nevezik általában idegen kulcsnak. Útnyilvántartás Autó Sorszám Rszám Dátum Útvonal Km Rendszám Típus Fogyaszt Az útnyilvántartásnak autóhoz kell tartoznia, de egy autóhoz több útnyilvántartás is tartozhat. Sorszám Rszám Dátum 1 ABC ABC /63 Rendszám Típus Fogyaszt ABC-123 Opel 8,5 FFF-663 Renault 7,2 EIS-104 Lada 12,4 DCT-432 Suzuki 6,4

64 Kapcsolatok 5. Ha a két tábla között N:M típusú kapcsolat van, akkor a kapcsolatot külön táblával (kapcsolótábla) valósítjuk meg. Termék Vásárlás Vásárló TKód TNév Ár TKód VKód VKód Név Cím TKód TNév Ár VKód Név Cím T01 Tej 220 V01 Rozi Kő u 11 T02 Vaj 210 T03 Tea 550 T04 Só 145 TKód T01 T04 VKód V01 V01 V02 Peti Só u 32 V03 Miki Bő u 17 V04 Évi Lé u 46 T02 V03 T04 V01 T03 V04 145/64 T02 V04

65 Index kulcsok A táblák rekordjai fizikailag abban a sorrendben helyezkednek el a merevlemezen, amilyen sorrendben begépelték őket Az adatok rendezése (főleg nagy adathalmazok esetén) rendkívül erőforrás igényes feladat, általában nagyon lassan hajtható végre Ha sorba rendezett adatokat kérünk az adatbázistól, az index kulcsok meggyorsítják az adatok előállítását Az index létrehozása egy új táblát eredményez, melynek egyik oszlopában az indexelt mező elemei szerepelnek rendezetten, a másik oszlopában a rekordok elsődleges kulcsa található 145/65

66 Index kulcsok 2. Index tábla Rendszám Kód ABC123 A04 BER666 A01 CDR420 A06 DGZ531 A03 LEM597 A05 RTW285 A02 Autó tábla Kód Rendszám Típus Szín A01 BER666 Fiat zöld A02 RTW285 Opel kék A03 DGZ531 Suzuki kék A04 ABC123 Mercedes fekete A05 LEM597 Opel fehér A06 CDR420 Nissan piros Ha bizonyos feltételnek eleget tevő, rendszám szerint rendezett listát kérünk, a rendszer kiválogatja a feltételnek megfelelő rekordokat, és nem rendezi azokat, hanem az index táblán végig haladva, ellenőrzi, hogy az adott kódú rekord benne van-e az eredményhalmazban, és ha igen, akkor kiírja azt. 145/66

67 A relációk megadása Bachman-diagram: Az adatbázis kapcsolati ábrája. A táblákat téglalapok jelölik. A tábla nevét nagy betűvel írjuk. Legfelül adjuk meg aláhúzva a kulcsot. A név alatt a másodlagos mezők vannak. A kapcsolatot nyilak jelzik. TERMÉK Kód Név Ár Méret VÁSÁRLÁS T_Kód V_Azon Dátum Darab VÁSÁRLÓ Azonosító Név Fiz_mód Lakcím 145/67

68 A relációk megadása 2. Séma leírás: Termék [ Kód, Név, Ár, Méret ] Vásárlás [ T_Kód, V_Azon, Dátum, Darab ] Vásárló [ Azonosító, Név, Fiz_mód, Lakcím ] 145/68

69 A relációk megadása 3. Struktúra ábrával, mely a mezőket, azok típusát, és a kapcsolatokat is ábrázolja. Alap adattípusok: C karakteres, N numerikus, D - dátum Termék Vásárlás Tkód C5 Név C25 Ár N6 Méret C30 T_Kód C5 Dátum D Darab N6 V_Azon C5 Vásárló Azonosító C5 Név C25 FizMód C15 Lakcím C50 145/69

70 A relációk megadása 4. UML diagrammal Eszköz TKód (pk, char(5)) Név (char(25) Ár number(6) Méret (char(30) Kölcsönzés Tkód (char(5)) Dátum (date) Darab (number(6) V_azon (char(5)) Személy Azonosító (pk char(5)) Név (char(25)) Fizmód (char(15)) Lakcím (char(50)) 145/70

71 Adatintegritás Az adatintegritás az adatok érvényességét, jóságát jelenti. Hitelesség, megbízhatóság, pontosság, ellentmondás mentesség. Hibás adatok: 2 azonos kulcs, elírt érték, szám helyett szöveg Elkerülése: Ellenőrzött adatbevitel, Kulcsértékek figyelése, Hivatkozások figyelése 145/71

72 Az adatintegritás szintjei Mező szintű megszorítások Rekord szintű megkötések Reláció szintű előírások Adatbázis szintű ellenőrzések Kód Név A3 Kovács B 14 S1 Dolgozó Munkakör Munkaidő Szupercég 145/72

73 Mező szintű megkötések A3 Kovács B 14 S1 Egy mezőre vonatkozó érvényes érték előfordulások körét lehet megadni: A megkötés lehet logikai kifejezés, amely minden lehetséges értékre igaz vagy hamis értéket ad vissza Check Kor>0 A megkötés vonatkozhat arra, hogy a mezőben tárolt érték nem lehet üres (kötelező megadni) Kód Not Null Előírható egy sablon, mely az adat külalakjára vonatkozik Rendszámban 3 betű, aztán kötelező, végül 3 számjegy Az adatbázisba csak olyan mezőértékek vihetők be, melyek a megadott szabályoknak eleget tesznek. 145/73

74 Rekord szintű megkötések A3 Kovács B 14 S1 Egy teljes rekord elfogadhatóságát kell eldönteni Az ellenőrzési feltételben a reláció sémájában szereplő mezők szerepelhetnek Az integritási feltétel célja az egy rekordon belül egymáshoz kapcsolódó mezők értékeinek vizsgálata Ha a végzettség középfokú, a fizetés > Ft. Ha a kategória élelmiszer, az áfa 10 vagy 15 % lehet. Ha a kód A vagy B betűvel kezdődik, a tárolási hely a E vagy az F rekesz lehet. 145/74

75 Reláció és adatbázis szint Reláció szint A teljes relációt, vagyis az összes rekord előfordulást át kell vizsgálni 145/75 Az adott mezőben ugyanaz az érték nem fordulhat elő többször a relációban (egyediség) Kód Unique Elsődleges kulcs mező (mezők) Kód Primary key Adatbázis szint A feltétel több relációban, szétszórtan elhelyezkedő mezőkre vonatkozik, az ellenőrzéshez több reláció adatait is át kell olvasni Idegen kulcs mező (csak egy másik táblában szereplő értékeket vehet fel) Ha az A táblában a kód A7, a B táblában az érték csak 10 és 20 között lehet

76 Egyed integritási szabály Minden relációban legyen egyedi értékű kulcs (mező vagy mezőcsoport), ami egyértelműen meghatározza a rekord előfordulásokat. A kulcs mező (mezők) értékét kötelező kitölteni, vagyis a kulcs nem lehet üres. A kulcs lehet egyszerű (egy mező, pl. autó rendszáma vagy személy adószáma) vagy összetett (több mező, pl. tanfolyam címe és időpontja, repülőjárat száma és a dátum). Hivatkozás integritási szabály Minden kapcsolókulcs mező értéke vagy üres, vagy egy létező, hivatkozott táblabéli elsődleges kulcsértékre mutat. 145/76

77 Témakörök Adatbázis-kezelő rendszerek Adatmodellek Adatbázis adatmodellek Adatbázis tervezés Ellenőrző kérdések 145/77

78 Adatbázis tervezés A tervezés lépései: 1. Minivilág megalkotása 2. Követelmények összegyűjtése, elemzése 3. Koncepcionális (szemantikai) modell elkészítése 4. ABKR rendszer kiválasztása 5. A Koncepcionális modell átkonvertálása adatbázis adatmodellre 6. A fizikai adatmodell megtervezése 7. Adatbázis implementálása 145/78

79 Minivilág megalkotása Jól körül kell határolni a valós világ azon darabkáját, amelyet az adatbázisban ábrázolni akarunk. Termékek adatai Raktárhelyek, és hogy azokon mi van Kiszállítások adatai Dolgozók adatai Rendelések: termék, darabszám, dátum Beszállítók adatai Színkódok a raktárban: - először mindig "Fehér" 145/79

80 Követelmények összegyűjtése, elemzése Részlet: A dolgozók adatai: kód, név, jogosultságok, jelszó A jogosultságok szintjei: 145/80 Adminisztrátor: teljes jogosultság mindenre Rendelés ügyintéző: új rendelés felvitele, véglegesítés előtti módosítása Rendelés feldolgozó: rendelések olvasása, véglegesítése Rendelés főnök: rendelések listázása, statisztikák A dolgozók jelszavát, jogosultságait az adminisztrátor módosíthatja Az adminisztrátor ténykedésének teljes naplózása Napló kódok: U új dolgozó, P jelszó módosítás, J jogosultság módosítás

81 Koncepcionális modell megalkotása A modell megalkotásának folyamata: Követelmények Egyedek meghatározása Kapcsolatok meghatározása Tulajdonságok meghatározása Követelmények ellenőrzése 145/81

82 ABKR kiválasztása Általában relációs ABKR-t használunk Kiválasztási szempont lehet: ingyenesség, az adatbázis várható mérete, az adatbázis várható terhelése, a szervereken futó operációs rendszer, skálázhatóság, költség tényezők, megszokások. Nagyok: Oracle SQL server Kicsik: 145/82 Informix Postgre MySQL SQLite mongodb TITAN cassandra

83 Adatbázis modell megalkotása A táblák szerkezetének kialakítása Milyen táblákra lesz szükségünk? A tárolt adatok számok, vagy szöveges adatok? Ha számok, milyen intervallumok között kaphatnak értéket? Ha szövegek, hány karakter szükséges a tároláshoz? Milyen egyéb típusokra lesz szükség? (dátum, fotó, grafika) dolgozo id nev n(4) c(40) mkor c(60) szulido d szemsz c(13) 145/83

84 Adatbázis modell megalkotása 2. A táblák oszlopai közötti összefüggések meghatározása A táblákban tárolt egyedek közötti összefüggések jelentik az adatok elérésének és kezelésének alapját. A táblák közötti kapcsolatokat a speciális oszlopok segítségével valósítjuk meg. Két tábla között akkor van kapcsolat, ha egyik tábla soraihoz egy másik tábla sorait hozzárendelhetjük. Ezt nevezzük a két tábla közötti kapcsolatnak. Fontos jellemző, hogy az egyik tábla egy rekordjával a másik tábla hány rekordja áll kapcsolatban. (A kapcsolat foka) dolgozó id nev n(4) c(40) mkor c(60) szülidő d szemsz c(13) telefonszám id mobil n(4) c(9) 145/84

85 Adatbázis modell megalkotása 3. Elsődleges kulcs: Minden táblában kell lenni egy (vagy több) mezőnek, amelynek tartalmával hivatkozhatunk a rekordokra, azonosíthatjuk, megkülönböztethetjük azokat. Ezt a mezőt nevezzük elsődleges kulcsnak. (azonosítónak) Az elsődleges kulcsnak minden rekordban értékkel kell rendelkeznie, és nem ismétlődhet a táblában. Az elsődleges kulcs szerepet játszik a táblák összekapcsolásában is. dolgozo id nev n(4) c(40) mkor c(60) szulido d szemsz c(13) 145/85

86 Adatbázis modell megalkotása 4. Az elsődleges kulcs kiválasztása: Név Szül.idő Lakcím Adószám Nagy Géza Miskolc, Új u Kis Jenő Miskolc, Ág u Kerek Béla Szeged, Cső u Bak Tamás Győr, Zár u lakásos társasház: Név 500 fős cég: Név+Szül.idő Kisváros: Adószám Általános esetben: Kód mező használata 145/86

87 Adatbázis modell megalkotása 5. Kapcsoló kulcs: A kapcsolt táblában az elsődleges kulcsot tartalmazó tábla mezőjére hivatkozó egy vagy több mező. A kapcsoló kulcs a táblák kapcsolatát jelzi és biztosítja. Funkciója: a kapcsoló kulcsként működő oszlop mezői csak olyan értéket vehetnek fel, amik egy másik tábla hivatkozott oszlopában szerepelnek. Típusai: Kötelező Nem kötelező Ismétlődő Nem ismétlődő értékű 145/87

88 Adatbázis modell megalkotása 6. A kapcsoló kulcs Autó Színek Rendszám Szín Szín ABC-123 CCD-666 JBO-007 VAU-195 Kék Zöld Fekete Lila Kék Zöld Fekete Piros 145/88 Elsődleges kulcs Hibás érték! Kapcsoló kulcs Elsődleges kulcs

89 A modellalkotás folyamata A valóság egy darabja ER modell Relációs modell kenyér sajt 3526 H Ft 400 db 250 g 450 Ft tej ,5 kg 180 Ft Kis Béla bankkártya C db Nagy Éva készpénz g Bazi Joe Kód Név Termék Ár Leírás Méret Dat TV Az Név Vásárló Db Lcím Fizm Irsz Tel Usz Termék Vásárlás Méret Vásárló 145/89

90 ER konverziója relációs modellre ER elemek Egyed Normál Gyenge Tulajdonság Elemi Kulcs Összetett Többértékű Származtatott Kapcsolatok 1:1 1:N N:M kötelező 145/90 Relációs elemek Reláció reláció kulcs mezővel reláció kulcs mező nélkül Mező mező kulcs mező több mezőre bontjuk szét külön relációba kerül csak a képletet tároljuk Kapcsolatok egyedi kapcsoló kulcs kapcsoló kulcs kapcsoló tábla nem üres kapcsoló kulcs

91 Erős egyedek leképzése A Az ER séma erős egyedéből egy relációt képzünk. Minden normál tulajdonságból egy-egy mező lesz Az összetett tulajdonságokból csak az összetevőket adjuk a relációhoz, ezekből egy-egy mező lesz, az összefogó tulajdonság kimarad (az összetett tulajdonságból csak az egyszerű tulajdonságok kerülnek át a relációba) A kulcs tulajdonságból lesz a reláció kulcsmezője Dolgozó Dolgozó Dkód Név Irsz Város U.hsz 145/91

92 Gyenge egyedek leképzése A Az ER séma gyenge egyedéből szintén egy relációt képzünk, az erős egyedhez hasonlóan, de: Az így képzett relációnak nem lesz teljes meghatározást adó kulcsmezője, ezért ki kell egészíteni egy kulcsmezővel A kulcsmező a gyenge egyedet meghatározó erős egyednek a kulcsmezője lesz A gyenge egyedet egy erős egyedhez kapcsoló ún. meghatározó kapcsolat jele: kettős vonalú rombusz Számla R-T ST Tétel 145/92

93 Gyenge egyedek leképzése A SzSzám Tkód Számla R-T ST Tétel TT Termék Sorszám Menny. Tnév Számla Tétel Termék SzSzám Sorszám Menny. SzSzám Tkód Tkód 145/93

94 Egy érthető példa gyenge egyedekről A KID Tartalmaz FID Könyv R-T Fejezet Tétel Cím Cím Könyv Fejezet KID Cím FID Cím kid 145/94

95 Tulajdonságok leképzése Tulajd. A kulcs tulajdonságból lesz a reláció kulcsmezője Minden normál tulajdonságból egy-egy mező lesz Az összetett tulajdonságból csak az egyszerű tulajdonságok kerülnek át a relációba A származtatott tulajdonságok nem kerülnek át a relációba, ezek értéke a hozzájuk tartozó képlet alapján, a letárolt többi adatból bármikor kiszámítható Dkód Név Dolgozó Dolgozó Dkód Név Irsz Város U.hsz Cím Kor Irsz 145/95 Város U.hsz

96 Tulajdonságok leképzése Tulajd. Az összetett tulajdonságok esetén mindig minden elemi mezőt szerepeltetni kell a relációban? Nem feltétlenül. Abban az esetben, ha az egyes mezőket szeretnénk önállóan feldolgozni, pl. városok szerinti statisztikák elkészítése, akkor igen. Ha viszont nincsenek ilyen szándékaink, akkor egyetlen mezőbe összevonva is tárolhatjuk az összetett tulajdonságot. Dkód Név Dolgozó Dolgozó Cím Dkód Név Lakcím + + Irsz Város U.hsz 145/96

97 Tulajdonságok leképzése Tulajd. Minden egyes többértékű tulajdonságból egy-egy új reláció lesz. A relációba bekerül a tulajdonságnak megfelelő mező A reláció mindig kiegészül egy kulcsmezővel, mely az egyes tulajdonságok azonosítója lesz Az egyedből készült relációba szükséges betenni egy kapcsoló kulcs mezőt, mely a többértékű tulajdonságból készült reláció kulcsmezőjével lesz kapcsolatban Dkód Dolgozó Név Dolgozó Dkód Név Nyelvtudás Dkód nyelv Nyelv 145/97

98 Tulajdonságok leképzése Tulajd. Dolgozó Nyelv Dolgozó Nyelvtudás Dkód Név Dkód nyelv Ha végig gondoljuk: ennél a megoldásnál egy nyelvet többször is be kell vinni, így nagy a hibalehetőség. Tökéletes megoldás a következő: Dolgozó Nyelvismeret Nyelvtudás Dkód Név Dkód Nykód Nykód nyelv A dolgozókat és a nyelveket is csak egyszer kell felvinni, kisebb a hibalehetőség. 145/98

99 Kapcsolatok leképzése K Az 1:1 kapcsolatok leképzésére általában azt a megoldást alkalmazzuk, hogy az egyik táblában elhelyezünk egy kapcsoló kulcsot, mely a másik tábla elsődleges kulcsára mutat. Akód Autó Tulajdonos Tkód Autó Tulajdonos Akód tkód tkód név Melyik táblába kerüljön a kapcsoló kulcs? 145/99 Általában abba, amelyiknek az összes egyede részt vesz a kapcsolatban (totális résztvevő)

100 Kapcsolatok leképzése K Akód Autó Tulajdonos Tkód Ha 1:1 típusú a a kapcsolat, miért nem kerülnek egy egy táblába? Mert az adatok száma eltérhet az egyes táblákban, és így szerkeszthető a kapcsolat. Tkód Név Akód Rendszám Tkód T1 Kiss A A1 ABC-123 T5 T2 Nagy B A2 FFF-663 T2 T3 Jó Tóni A3 DCT-432 T4 Kék Zoli T5 Kő Jani 145/100

101 Kapcsolatok leképzése K Az 1:1 kapcsolatok esetén néha előfordulhat, hogy a két táblában lévő adatok számossága megegyezik. Ekkor a két egyedet egyetlen relációba is összevonhatjuk. Ukód Akód Autó Útnyilvántartás mikor Autó km Akód mikor km Szükséges mindkét kulcsmező? Nem, amelyik táblát elhagyjuk, annak a kulcsmezője is eltűnik. 145/101

102 Kapcsolatok leképzése K Az 1:N kapcsolatok az N számosságú oldalon elhelyezünk egy kapcsoló kulcsot, mely a másik tábla elsődleges kulcsára mutat. Akód Autó N 1 Tulajdonos Tkód Autó Akód Rendszám Tkód A1 ABC-123 T1 A2 FFF-663 T2 A3 DCT-432 T2 Tulajdonos Tkód Név T1 Kiss A T2 Nagy B T3 Jó Tóni T4 Kő Jani 145/102 Kapcsoló kulcs (idegen kulcs)

103 Kapcsoló kulcs vs. idegen kulcs Kapcsoló kulcs: olyan mező, amelynek értékei kapcsolatot tudnak teremteni egy másik tábla egy mezőjébe írt értékekkel. Akód Rendszám Kód A1 ABC A2 FFF A3 DCT Tkód Név Darab 1 Kiss A 2 2 Nagy B 4 3 Jó Tóni 2 4 Kék Zoli 9 5 Kő Jani 5 145/103

104 Kapcsoló kulcs vs. idegen kulcs Idegen kulcs (külső kulcs): olyan kapcsoló kulcs, amely: 145/104 Dedikált kapcsolatot teremt két tábla között (meg kell mondani, hogy az egyik tábla adott mezőjét összeköti a másik tábla elsődleges kulcs mezőjével). Csak olyan értékeket vehet fel az idegen kulcs mező, ami a kapcsolt tábla elsődleges kulcs mezőjében megtalálható, vagy NULL értéket. Akód Rendszám Kód A1 ABC A2 FFF A3 DCT Idegen kulcs esetén a 9 nem megengedett érték! Tkód Név Darab 1 Kiss A 2 2 Nagy B 4 3 Jó Tóni 2 4 Kék Zoli 9 5 Kő Jani 5

105 Kapcsolatok leképzése K Az N:M kapcsolatok esetén megoldható a kapcsolat egy kapcsoló kulccsal? Akód Autó Tulajdonos Tkód Autó Akód Rendszám Tkód A1 ABC-123 T1 A2 FFF-663 T2,T4 A3 DCT-432 T2 Tulajdonos Tkód Név T1 Kiss A T2 Nagy B T3 Jó Tóni T4 Kő Jani Nem! 145/105 Sérül az a szabály, hogy egy mezőbe csak egy adat kerülhet!

106 Kapcsolatok leképzése K Az N:M kapcsolatokat mindig egy új kapcsoló reláció létrehozásával képezzük le a relációs modellben. Akód Autó Tulajdonos Tkód Autó Akód A1 A2 A3 Rendszám ABC-123 FFF-663 DCT-432 Autó Akód A1 A2 A2 A3 Tkód T1 T2 T4 T2 Tulajdonos Tkód Név T1 Kiss A T2 Nagy B T3 Jó Tóni T4 Kő Jani 145/106 Kapcsoló reláció két idegen kulccsal

107 Kapcsolatok leképzése K Az n.-fokú kapcsolatokat mindig egy olyan kapcsoló reláció létrehozásával képezzük le, melybe minden összekapcsolt egyedhez kerül egy-egy kapcsoló kulcs ID Verseny támogat Versenyző Kód A szponzor egy adott versenyen egy konkrét versenyzőt támogat! Szponzor Összeg Sz.Az Verseny Versenyző Támogat Szponzor ID Kód Kód ID Sz.Az Összeg Sz.Az 145/107

108 Kapcsolatok leképzése K Rekurzív (önmagával kapcsolódó) kapcsolat leképzése Dkód Dnév Dolgozó Főnök felettes beosztott Egy dolgozóhoz 1 felettes tartozhat Egy feletteshez több beosztott tartozhat Hogyan jelöljük ezt a relációs modellben? Dolgozó Dkód Dnév Főnök 145/108

109 Integritás az ER modellben Csak elemi statikus integritási részt tartalmaz Egyediség kulcsmező Kötelezőség kapcsolatnál Pl.: Egy vállalatnál a dolgozóknak kötelező valamelyik részleghez tartoznia Számossága: 1:N Jellege: dolgozó oldalon kötelező, részleg oldalon opcionális Dolgozó N dolgozik 1 Részleg Hová, milyen nyíl kerüljön? 145/109

110 Az integritás konvertálása Dkód Dnév Dolgozó N dolgozik 1 Részleg Rkód Rnév Mi lesz a kapcsolatból a relációs modellben? Melyik oldalra kerül a kapcsolókulcs? Idegen kulcs Mindig az N oldalra Mit jelent az idegen kulcs? Az adott mezőbe csak olyan értékek kerülhetnek, amit a kapcsolt mezőben megtalálhatók Hogyan néz ki a relációs modell? Dolgozó Dkód Dnév Rkód Részleg Rkód Rnév NN Már kötelező a kapcsolat? 145/110 Még nem. Attól lesz kötelező, hogy előírjuk a kapcsolókulcsra, hogy nem lehet üres (Not Null)

111 Integritás a relációs modellben Dolgozó Dkód Dnév Rkód UQ Részleg Rkód Rnév Milyen kapcsolatot jelez az ábra? (1:1, 1:N, N:M) 1:N Lehet a kapcsolatból 1:1 kapcsolatot csinálni? Igen. Előírjuk, hogy a kapcsolómezőbe nem kerülhetnek egyforma értékek (Unique) Fontos: a relációs modellben az elsődleges kulcsmezőre automatikusan érvényes az Unique és a Not Null előírás (nem kell megadni). A kapcsolókulcsokra viszont nem! Az Unique előírással maximum hány darab rekordja lehet a Dolgozó táblának? 145/111 Ahány rekord van a Részleg táblában!

112 145/112

113 Gyakorló feladat Konvertálja az alábbi ER modellt relációs modellé! Kód Név Azonosító Név Vásárlás Termék Vásárló Kor Ár Méret Dátum Darab Lakcím Szül.idő IrSz. Város U-Hsz 145/113

114 Gyakorló feladat Kód Név Termék Termék Kód C5 Név C25 Ár N6 Ár Leírás Méret Kapcsoló kulcs (idegen kulcs) Méretek Tkód C5 Méret C25 145/114 A Méretek tábla Tkód mezője csak olyan értéket vehet fel, ami a Termék tábla Kód mezőjében megtalálható!

115 Gyakorló feladat Azonosító Név Kor Vásárló Vásárló Azonosító C5 Név C25 IrSz C4 Város C40 U-Hsz C30 Szül.idő D Lakcím Szül.idő IrSz. Város U-Hsz Az összefogó tulajdonság kimarad! A származtatott tulajdonság kimarad! 145/115

116 Gyakorló feladat Kód Azonosító Termék Vásárlás Vásárló Vásárlás Kód C5 Dátum D Darab N6 Azon C5 Dátum Darab A táblába kerülő adatok: - Idegen kulcsok a kapcsolt táblák elsődleges kulcsaira - A kapcsolat saját mezői 145/116

117 Gyakorló feladat Méret Termék Vásárlás Vásárló Termék Méretek Kód C5 Név C25 Ár N6 Mkód C5 Tkód C5 Méret C25 Vásárlás Vásárló Kód C5 Dátum D Darab N6 Azon C5 Azonosító C5 Név C25 IrSz C4 Város C40 U-Hsz C30 Szül.idő D 145/117

118 145/118

119 Gyakorló feladat Eszközök Konvertálja az alábbi ER modellt relációs modellé! Dkód Dnév Ekód Enév Hkód Hnév Dolgozó Iroda Kor Használ Eszköz E-H N M N 1 N Helyszín N Épület Szoba E-K M Knév Epkód H-E 1 Epnév Kkód Kategória Doksi Épület 145/119

120 Gyakorló feladat Eszközök Mi történik konvertáláskor a megadott elemmel? Dkód Dnév Dkód Dnév Dkód Dnév Dolgozó Dolgozó Dolgozó Iroda Kor Iroda Kor Iroda Kor Épület Szoba Épület Szoba Épület Szoba Milyen mezők lesznek a Dolgozó táblában? 145/120 Dolgozó Dkód Dnév Épület Szoba

121 Gyakorló feladat Eszközök Mi történik konvertáláskor a megadott elemmel? Dkód Ekód Ekód Enév Eszköz Dolgozó N Használ M Eszköz 4 5 Eszköz Ekód Enév Mi lesz a kapcsolatból? Hány mező lesz a kapcsoló táblában? 145/121 Használ Dkód Ekód Mely mezők kerülnek a kapcsoló táblába?

122 Gyakorló feladat Eszközök Mi történik konvertáláskor a megadott elemmel? Ekód Hkód Hnév Hkód Helyszín Hnév Eszköz E-H Helyszín N Mi lesz a kapcsolatból? Melyik táblába kerül a kapcsoló kulcs? Eszköz Helyszín 145/122 Ekód Hkód Hkód Hnév

123 Gyakorló feladat Eszközök Mi történik konvertáláskor a megadott elemmel? Helyszín N Hkód Hnév Kkód Kategória Doksi H-E Épület Epkód Epnév Mi lesz a tulajdonságból? Hány mező lesz a táblában? Mi lesz a kapcsolatból? Melyik táblába kerül a kapcsoló kulcs? Helyszín Épület Hkód Hnév 145/123 Epkód Epkód Epnév Milyen mezők lesznek a táblában? Dokumentumok Kkód Doksi

124 Gyakorló feladat Eszközök Mi történik konvertáláskor a megadott elemmel? Eszköz E-H Helyszín N 1 Hkód Hnév N Hány darab mező lesz a Helyszín táblában? 10 H-E 1 Helyszín Hkód Hnév Epkód Épület Epkód Epnév Épület Epkód Epnév 145/124

125 Gyakorló feladat Eszközök Mi történik konvertáláskor a megadott elemmel? Ekód Enév Dolgozó Használ Eszköz E-H N M N 1 N Helyszín 11 E-K Hány darab mező lesz az Eszköz táblában? M Kategória E-K Használ Eszköz Helyszín Ekód Kkód Dkód Ekód Ekód Enév Hkód Hkód Hnév Epkód 145/125

126 Gyakorló feladat Eszközök Mi történik konvertáláskor a megadott elemmel? Knév Kkód Kategória Doksi 12 Hány mező lesz a Kategória táblában? Dokumentumok Kkód Doksi Kategória Kkód Knév 145/126

127 Gyakorló feladat Eszközök Hány darab tábla keletkezik az ER Relációs konvertáláskor? Dkód Dnév Ekód Enév Hkód Hnév Dolgozó Iroda Kor Használ Eszköz E-H N M N 1 N Helyszín N Épület Szoba E-K M Knév Epkód H-E 1 Epnév Kkód Kategória Doksi Épület 5 db 6 db 7 db 8 db 9 db 10 db 145/127

128 145/128

129 Autó útnyilvántartás Útnyilvántartás U-A Autó Fogyaszt Sorsz. Km Rendsz Típus Dátum Útvonal Útnyilvántartás Autó Sorszám Rszám Dátum Útvonal Km Rendszám Típus Fogyaszt Autó [Rendszám, Típus, Fogyaszt ] Útnyilvántartás [ Sorszám, Rendszám, Dátum, Útvonal, Km ] 145/129

130 Tkód Tnév Menny. Rhkód Rkód Leírás TermékR Készlet Raktárhely R-R Raktár MEgys. BeDat LeDat Aktív Aktív Termékek a raktárban Termék Tkód Tnév MEgys Készlet Raktárhely Raktár Tkód Menny Bedat Ledat Rhkód Rhkód Aktív Rkód Rkód Leírás Aktív NN 145/130

131 Dkód Dnév Tkód Téma Okód Onév Dolgozó Képzés Tanfolyam T-O Oktató Végzettség Dátum Hely IrSz. Cím Tanfolyamok Város UHsz Dolgozó Képzés Tanfolyam T-O Dkód Dnév Dkód Dátum Hely Tkód Tkód Téma Tkód Okód Végzettségek Dkód Végzettség Oktató Okód Onév IrSz Város UHsz 145/131

132 Számlázási rendszer 145/132

133 Akciós újság Ukód Újság Régió Dátum U-O Tkód Tnév Fkód Termék T-O Oldal O-F Fotó MEgys. EgysÁr Oszám Szöveg Termék Fálj Termék T-O Oldal O-F Fotó Tkód Tnév MEgys EgysÁr Tkód Oszám Oszám Szöveg Oszám Fkód Fkód Újság Ukód Dátum Régió U-O Ukód Oszám Termék Tkód Fkód Fájl Fkód Fájlnév 145/133

134 Átszállítás boltba Rhkód Aszám KDátum Dkód Dnév Raktárhely Átszállítás A-D Dolgozó Menny. R-T A-T Tkód Tkód Tnév TermékR TR-T Tétel T-TB TermékB Tnév MEgys. Sorszám Menny. TDátum Menny. MEgys. 145/134

135 Átszállítás boltba Átszállítás Aszám KDátum Dkód Dolgozó Dkód Dnév Raktárhely Rhkód Tétel Aszám Sorszám Tkód Menny Dkód KDátum R-T TermékR TermékB Rhkód 145/135 Tkód Tkód Tnév MEgys Tkód Tnév Menny MEgys

136 Fizikai tervezés 145/136

137 SQL server adattípusok Egész típusok 145/137

138 SQL server adattípusok Valós típusok Dátum és idő típusok 145/138

139 SQL server adattípusok Karakteres és unicode típusok 145/139

140 SQL server specialitások Identity: Azonosító adattípus tulajdonság identity [seed, increment] seed: kezdőérték increment: növekmény Nem önálló típus, hanem a növekedést bizosító tulajdonság Vagy mindkét értéket meg kell adni, vagy egyiket sem Kezdőértéke (1,1) A create table és az alter table utasításokban használható 145/140 create table employees ( id int IDENTITY(1,1), ename varchar (20), gender char(1) ); insert into employees (ename, gender) values ('Kiss Béla', 'M');

141 SQL server specialitások Identity: Azonosító adattípus tulajdonság Minden egyes beszúráskor új érték keletkezik Sikertelen beszúrások esetén elveszik az érték, emiatt nem garantált, hogy egymás utáni értékek lesznek a táblában Ez a tulajdonság nem garantálja az értékek egyediségét, pl. adat kijavításakor megadható egy már meglévő érték Az ilyen mezők egyediségét a primary key vagy az unique megszorítás előírásával lehet biztosítani 145/141

142 SQL server specialitások Elnevezések Elvileg használhatók a magyar ékezetes karakterek az egyes objektumok (táblák, mezők ) nevének megadására, de ne használjuk őket. Bizonyos parancsokban az ékezetes objektumnevek helytelenül működnek! Még veszélyesebb a szóközök használata az objektumok elnevezésében. Sajnos az SQL Server lehetővé teszi használatukat, de álljunk ellent a csábításnak. Ugyanígy kerüljük a kulcsszavak használatát objektumok elnevezésében! Létrehozhatunk pl. egy select nevű 145/142

143 További kényelmi eszközök Olyan aktív elemek, amelyek segítik az adatok kezelését tárolt eljárások: a szerveren tárolt nevesített rutinok, melyek Transact-SQL programnyelven íródtak, tehát program utasításokat (ciklusok, feltételek ) és SQL parancsokat is tartalmazhatnak (pl. havi jelentés lefuttatása egyetlen parancsra) triggerek: adatmanipulációkor (pl. beszúrás) automatikusan elinduló műveletsorozatok (pl. adatellenőrzés, naplózás ) tranzakciók: több összefüggő művelet összefogása egy végrehajtási láncba, azért, hogy vagy minden művelet lefusson, vagy egyik sem (pl. termék átrakása egyik helyről a másikra: nincs elég termék, nincs elég hely ) 145/143

144 145/144 Gratulálok! Ön átvette a tananyagot, és letesztelte a tudását!

145 VÉGE VÉGE 145/145