Programozás. Adatbázis-kezelés (alapok) Fodor Attila

Programozás Adatbázis-kezelés (alapok)

Fodor Attila Pannon Egyetem Műszaki Informatikai Kar Villamosmérnöki és Információs Rendszerek Tanszék [email protected]

2010. április 22.

Adatbáziskezelés

Bevezetés

Bevezetés

Adatbázisok csoportosítása Tény-adatbázis Meghatározott formában tárolt adatokat tartalmaz Adatok között kapcsolat áll fenn

Dokumentum típusú adatbázist Szöveges információk vagy digitálisan archivált adatok halmaza Adatok között nincsen kapcsolat

Fodor A. (Pannon Egyetem)

Programozás

2010. április 22.

2 / 19

Adatbáziskezelés

Bevezetés

Adatbázis-kezelő rendszerek előnyei az adatok strukturált "szabványos" tárolása az adatok közötti komplex kapcsolatok ábrázolása egyszerű használat eltérő forrásokból származó adatok összekapcsolhatósága adatbevitel ellenőrzése, adateredet naplózása felhasználói programoktól való függetlenség fejlesztői nyelvektől való függetlenség felhasználói jogosultság, hozzáférés-kezelés konkurens hozzáférés erőforrásokhoz való konfigurálhatóság szabványos felhasználói, lekérdező felületek adatvédelem, titkosság redundancia mentes tárolás adatbázis-konzisztencia biztosítása külső rendszerekkel való kapcsolattartás hibakezelés-, hibajavítás; Fodor A. (Pannon Egyetem)

Programozás

2010. április 22.

3 / 19

Adatbáziskezelés

Bevezetés

Hátrányok, fontosabb fogalmak Az adatbázis-kezelő rendszerek hátrányai Adatkezelés speciális szakértelmet kíván Megbízható rendszerek általában relatíve drágák A végfelhasználó a hagyományostól eltérő adatkezelésre kényszerül Adatokkal való visszaélés veszélye fokozottan jelentkezik Adatok könnyen megsérülhetnek (megbízható adatkezelési, archiválási rendszer szükséges)

Adatbázisokkal kapcsolatos fontosabb fogalmak DDL - Data Definition Language Adatszerkezetet leró nyelv SDL - Storage Description Language Fizikai szerkezetet megvalósító nyelv DML - Data Manipulation Language Adatok visszakeresését és módósítását támogató nyelv DBML - Data Base Management System Adat leíró és adatkezelő nyelvet magába foglaló rendszer SQL (Structured Query Language) Szabványos adatokat lekérdező nyelv Fodor A. (Pannon Egyetem)

Programozás

2010. április 22.

4 / 19

Adatbáziskezelés

Kapcsolatok, DB modellek

Objektumok közötti kapcsolatok, DB modell szintjei A két elem független, közöttük lévő kapcsolatokról nem tárolunk információt A két elem között kölcsönösen egyértelmű kapcsolat áll fenn. 1:1 Elemek egyértelmű összekapcsolása minden modellben kezelhető. Az egyik irányban egyértelmű, a másik irányban többértelmű a kapcsolat. 1:N A kapcsolatok egymásra épülnek egyszerű hierarchikus kapcsolat alakul ki. Minden modellben használható. Minkét irányban többértelmű kapcsolat. M:N Csak hálós és relációs modellek tudják kezelni. Adatbázis modell szintjei Külső szint Középső (koncepcionális) szint Belső (fizikai) Fodor A. (Pannon Egyetem)

Programozás

2010. április 22.

5 / 19

Adatbáziskezelés


Adatbázis modellek Adatbázis modellek Hierarchikus adatbázis modell Hálózatos adatbázis modell Relációs adatbázis modell Objektum-relációs modell

SQL (Structured Query Language) (Szabványos lekérdező nyelv) Szükséges egy olyan nyelv, amely több rendszerben is használható Lehetséges elemek szintaktikai elemek objektumok utasítások kifejezések és műveletek NULL érték katalógus adatbázisok eljárásjellegű elemi


Programozás

2010. április 22.

6 / 19

Adatbáziskezelés


Fontosabb SQL utasítások

Adatdefiníciós utasítások CREATE ALTER DROP

Adatkezelési utasítások SELECT INSERT UPDATE DELETE

Adatbiztonsági utasítások GRANT REVOKE


Programozás

2010. április 22.

7 / 19

Adatbáziskezelés

Relációs adatbázis


Codd (1970) adatmodell kidolgozása Előnyök Egyszerűen értelmezhető adatszerkezet (Felhasználó - Fejlesztő) Más meglévő nem relációs adatbázispól könnyen átvihetőek az adatok relációs adatbázisba Tervezése nem különbözik a többi adatbázis tervezési elveitől

Relációk és alapfogalmak A reláció egy táblázatként értelmezhető A táblázatok tartalmazzák az adatokat A relációs adatbázis = relációk összessége Oszlopok elnevezésének egyedinek kell lenni


Programozás

2010. április 22.

8 / 19

Adatbáziskezelés


Elterjedt relációs adatbázis-kezelő rendszerek

Kereskedelmi Oracle IBM DB2 MS SQL Server Informix

Nyílt forráskóddal rendelkezők MySQL SQLite PostgreSQL


Programozás

2010. április 22.

9 / 19

Adatbáziskezelés


Adattábla (példa)


Programozás

2010. április 22.

10 / 19

Adatbáziskezelés

Adatbázistervezés

Adatbázistervezés

Lépései Rendszer/Feladat elemzése Tárolandó adatok kiválasztása Adatok közötti kapcsolat(ok) meghatározása Adatbázissal szemben támasztott követemények felmérése (Conceptual schema - Fogalmi séma)

Rendszer megtervezése (nem csak az adatbázis) Logikai adatmodell megtervezése

Fizikai megvalósítás HW/SW függő Logikai adatmodell implementálása Adatokkal való feltöltés


Programozás

2010. április 22.

11 / 19

Adatbáziskezelés

Adatbázistervezés

Tervezéssel kapcsolatos fogalmak Funkcionális kapcsolat Egy vagy több adat konkrét értékéből más adatok egyértelműen következik Példa: Neptun kód → Név Személyi szám → Név Igazolvány szám → Név Neptun kód → Személyi szám Személyi szám → Neptun kód Fordítva nem feltétlenül igaz Kölcsönös függőség: Példa: Személyi szám ↔ Neptun kód Egy adatot több attribútum is definiálhat Példa: Szak, Átlag → Ösztöndíj Fodor A. (Pannon Egyetem)

Programozás

2010. április 22.

12 / 19

Adatbáziskezelés

Adatbázistervezés

Tervezéssel kapcsolatos fogalmak

Funkcionális kapcsolat Teljes funkcionális függőség A kapcsolat bal oldalán nem szerepel felesleges adat Példa: Szak, Átlag → Ösztöndíj (teljes) Neptun kód, Szak, Átlag → Ösztöndíj (nem teljes) Fontos a funkcionális kapcsolat HELYES felismerése HELYTELEN Funkcionális kapcsolat esetében nem kapunk helyes/hatékony működést Matematikai megadás: relacio_neve=({attributum(ok)},{funkcionalis_fuggosegek})


Programozás

2010. április 22.

13 / 19

Adatbáziskezelés

Adatbázistervezés

Tervezéssel kapcsolatos fogalmak Többértékű függőség Nem minden kapcsolat fejez ki egyértelmű függőséget Példa: Neptun kód −− Név (Egy hallgató több szakon is tanulhat) Ha valami nem írható le funkcionális függőséggel akkor szabad csak használni.

Reláció kulcsa Egyértelműen azonosítja a reláció egy sorát Kulccsal szemben támasztott feltételek: Olyan atribiutum(ok) melyek egy sort azonosítanak (egyértelműség) Nincsen(ek) felesleges atribiutum(ok) a kulcsban (egyetlen részhalmaza sem alkot kulcsot) attribútum(ok) értéke nem lehet definiálatlan (NULL) érték

Összetett kulcsok Több attributummal állítható össze a kulcs Példa: vizsga=({neptun_kód, tantárgy, dátum, vizsgajegy}) Fodor A. (Pannon Egyetem)

Programozás

2010. április 22.

14 / 19

Adatbáziskezelés

Adatbázistervezés

Tervezéssel kapcsolatos fogalmak

Redundancia Valamely információ többszörösen van eltárolva Valamely információ más tényekből meghatározható Redundancia veszélyei/hátrányai Növekvő helyfoglalás Növeli az inkonzisztencia veszélyét (Inkonzisztens DB egymásnak ellentmondó tényeket tartalmaz) Bonyolult adatfrissítés/karbantartás

Logikai tervezésnél kell kiküszöbölni Példa: Tantárgy neve, Oktató, Heti óraszám, Féléves óraszám Felesleges a "Féléves óraszám" eltárolása Gyorsítás érdekében szoktak redundanciát használni Fizikai tervezés


Programozás

2010. április 22.

15 / 19

Adatbáziskezelés

Adatbázistervezés

Reláció normál alakja (Normal Form) Feladat: redundancia megszüntetése Normál formák egymásra épülnek Elsődleges attribútum: Legalább egy reláció kulcsban szerepelnek 1NF - Első normál forma Minden attribútuma egyszerű, nem összetett adat Példa: órarend=({tantárgy, időpont, terem, terem_kapacitasa})

2NF - Második normál forma Nem tartalmazhat tényeket a reláció kulcs egy részére vonatkozóan Reláció minden nem elsődleges attribútuma teljes funkcionális függőségben van az összes reláció kulccsal órarend=({tantárgy, időpont, terem}) termek=({terem, terem_kapacitasa})


Programozás

2010. április 22.

16 / 19

Adatbáziskezelés

Adatbázistervezés

Reláció normál alakja (Normal Form) 3NF - Harmadik normál forma Probléma: A második normál forma ellenére lehetnek ismétlődő tények Példa: órarend=({tantárgy kód, oktató neptun kód, oktató neve})

Példa: (megoldás) órarend=({tantárgy kód, oktató neptun kód}) oktatók=({oktató neptun kód, oktató neve})

Boyce/Codd normál forma (BCNF) A 3NF szigorítása, a redundanciák kiküszöbölése érdekében Feltételei: A reláció 3NF-ban van Elsődleges attribútum(ok) teljes funkcionális függőségben van azokkal a kulcsokkal, melyeknek nem része


Programozás

2010. április 22.

17 / 19

Adatbáziskezelés

Adatbázistervezés

Reláció normál alakja (Normal Form) 4NF - Negyedik normál forma Probléma: A Boyce/Codd normál forma (BCNF) ellenére is lehetnek ismétlődő tények Feltételei: A reláció 3NF-ban van A többértelmű függőségben (X − − Y ) X és Y megtalálható atributum Példa: hallg_evf_koll=({hallgató , évfolyamtárs, kollégium szoba})

Példa: (megoldás) evfolyamtars=(hallgató, évfolyamtárs) kollegiumszoba=(hallgató, kollégium szoba)


Programozás

2010. április 22.

18 / 19

Adatbáziskezelés

Adatbázistervezés

Reláció normál alakja (Normal Form)

5NF - Ötödik normál forma Probléma: A 4NF ellenére is lehetnek ismétlődő tények Példa: (4NF-ban) tanár_óra=({tantárgy kód, oktató neptun kód}) oktató_hely=({oktató neptun kód, kampus}) óra_hely=({tantárgy kód, kampus})

Példa: (megoldás) órarend=(tantárgy kód, kampus, oktató neptun kód) oktatók=(oktató neptun kód, oktató neve)


Programozás

2010. április 22.

19 / 19

Programozás. Adatbázis-kezelés (alapok) Fodor Attila

Recommend Documents