Az adatbázis kezelés alapjai Dr. Nehéz Károly egyetemi adjunktus Miskolci Egyetem Alkalmazott Informatikai Tanszék 2004.

Az előadások a következő témára: "Az adatbázis kezelés alapjai Dr. Nehéz Károly egyetemi adjunktus Miskolci Egyetem Alkalmazott Informatikai Tanszék 2004."— Előadás másolata:

1 Az adatbázis kezelés alapjai Dr. Nehéz Károly egyetemi adjunktus Miskolci Egyetem Alkalmazott Informatikai Tanszék 2004

2 Adatbázisok Adatbázis fogalma (database): –logikailag összetartozó adatok adatmodell szerint rendezett összessége, mely értékek és kapcsolatok mellett az integritásőrzéshez és a biztonsághoz kapcsolódó metaadatokat is tárolja –Adatbázis kezelők típusai: hierarchikus hálós relációs – (Oracle, IBM DB2, Microsoft SQL, Sybase, PostgreSQL, Informix, MySQL) objektum orientált

3 SQL Mi nem SQL? nem adatbázis-kezelő rendszer nem adatmodell nem programozási nyelv Története E. F. Codd (1970) IBM, „A Relational Modell of Data for Large Shared Data Banks” – adatfeldolgozás és a tárolás relációs szemléletének kialakítása IBM 1974, System/R rendszer (prototípus relációs adatbázis- kezelő) IBM 1976, Definiálták a System/R több felhasználós, kétdimenziós táblázatokba szervezett adatokat lekérdező nyelvét: SEQUEL (Structured Query Language) 1979 – Oracle rendszer, az első kereskedelmi forgalomban is kapható adatbázis-kezelő rendszer, SQL (Structured Query Language) a lekérdezőnyelv 1980 Ingres relációs adatbázis-kezelő QUEL nyelvvel

4 1983 IBM, SQL/Data System – DB2 rendszer bemutatása. E rendszer nyelve lett a SQL szabvány alapja 1986, Ingres is áttért az SQL-re 1986 ANSI (American National Standards Institute) elfogadta az első SQL szabványt 1989 újabb SQL szabvány, amely az előfordítók és a dinamikus SQL ajánlásokra is kitért 1992 újabb SQL szabvány: –Szabványosították: »a programozó által definiált adattípusokat »megszorító szabályok megadási lehetőségei »kulcsdefiníciók, kulcsvizsgálatok »tárolt eljárások

5 SQL utasítások csoportjai lekérdezés –SELECT adatkezelés (új adatok bevitele, módosítása, törlése) –INSERT, UPDATE, DELETE adatstruktúra felépítés –CREATE, DROP, ALTER védelem, tranzakció kezelés –GRANT, REVOKE, COMMIT, ROLLBACK

6 SELECT példák tulajtiprszar N.KFiatabc-1231231232 a.) összes adat: SELECT * FROM AUTO; b.) projekció SELECT rsz,tip FROM AUTO; c.) szelekció „Lada” típusú autók SELECT * FROM AUTO WHERE tip=‘Lada’; d.) szelekció, melyek ára 300000 és 400000 között van SELECT * FROM AUTO WHERE ar BETWEEN 300000 AND 400000; e.) szelekció, minden Lada altípus … WHERE tip LIKE ‘LADA%’; f.) szelekció, minden halmazban lévő elem … WHERE tip IN (‘Citroen’,’Fiat’,’Ford’) AUTO

7 Normalizálás az adatok logikai szintjén történik normalizálásnak több szintje van többlépéses eljárás, amely a józan észre hagyatkozva is elvégezhető, –de a normalizálási szabályok ismerete megőriz az ad-hoc optimálástól, hibáktól. megfelelően normált rendszer esetén felléphetnek hatékonysági problémák –ilyenkor kompromisszumra kényszerülünk: megelégszünk egy alacsonyabb normalizáltsági, de nagyobb hatékonyságú szinttel. Összefoglalóan - a jó normalizáció következtében: –Az adatok tárolóigénye kevesebb lesz –Az elemi adatokat gyorsabban és kevesebb hibalehetőséggel változtathatjuk meg –Az adatbázis logikai áttekinthetősége növekedik

8 Függőségek Definíció: ha egy R relációban az egyik attribútum (X), a független változó értéke egyértelműen meghatározza egy másik attribútum (Y), a függő változó értékét, akkor azt mondjuk, hogy Y funkcionálisan függ X-től az R relációban. XY Z A független attribútumból nyíl mutat a tőle függő felé. Az Y és Z funkcionálisan függ X-től. Z pedig funkcionálisan függ X és Y-tól. Def:Egy adott R relációban az Y oszlop akkor és csak akkor függ X- től, ha bármely két olyan sorában amelyikben X értéke azonos, azokban Y is azonos. De fordítva nem igaz. »pl: egy AUTO táblában a (GYÁRTMÁNY és TÍPUS) -> (ŰRTARTALOM). (azaz az űrtartalom funkcionálisan függ az autó gyártmányától és típusától.) Minden (GYÁRTMÁNY és TIPUS) ugyanaz az ŰRTALTALOM érték tartozik. Egy űrtartalom értékhez azonban több (GYÁRTMÁNY, TIPUS) tartozhat.

9 Első normálforma A probléma bemutatása egy példa alapján: –hallgatói nyilvántartást kell készíteni a TDK-s hallgatókról az egyetemen. Minden hallgatónál szükségünk van a következő adatokra: - hallgatói azonosító szám (HSZ) - vezetéknév (VEZNEV) - keresztnév (KERESZTNEV) - szakirány kódja (SZAKKOD) - szakirány megnevezése (SZAKNEV) - TDK téma kódja (TDKKOD) - TDK téma megnevezése (TDKTEMA) - szabadidejének hány %-ában dolgozik a témán (%) - témavezető kódja (TVKOD) - témavezető neve (FONOK)

10 A feladat további elemzése során megállapításra került: –a hallgatói azonosító szám egyedi –a szakirány kódja és a szakirány megnevezése egyedi, a kettő között egyértelmű kapcsolat áll fenn –a TDK téma kódja és megnevezése ugyanilyen mint az előző –egy hallgató csak egy szakirányhoz tartozhat, de dolgozhat több TDK témán is –témák és szakirányok között nincs kapcsolat A következő lépés a táblázat (reláció) készítés

11 SZAKKODSZAKNEV HSZ VEZNEVKERESZT NEV TDKKODTDKTEMA%TVKODFONOK SZ123ÁRAML323KissAntal12345Téma12034NEKAR SZ345GÉPTER V 212NagyBéla23456Téma24043TTIB SZ345GÉPTER V 212NagyBéla12945Téma31023HOROL SZ348MANAGE R 345LakatosImre23455Téma48523HOROL Hallgatók TDK témái – 1NF-ben Általánosságban azt mondhatjuk, hogy egy táblázat adatai 1NF-ben (normál formában) vannak, azaz relációt alkotnak, ha teljesülnek a következő feltételek: -minden oszlop egy, és csakis egy attribútumot jelent, -minden sor különbözik, -az attribútumok sorrendje minden sorban ugyanaz, -nincsenek ismétlődő sorok, -minden sorhoz tartozik (legalább) egy egyedi kulcs, amelytől az többi attribútum függ. (a fenti táblában a HSZ és TDKKOD attributumok.

12 Második normálforma (2NF) változtatási anomáliák: –beírási anomália: ha új szakirányt indítunk, vagy új hallgató jön és még nincs témája, akkor nem tudjuk a táblázathoz rendelni. Mindkét esetben az elsődleges kulcs (része) nincs megadva. –törlési anomália: ha valaki kiiratkozik, akkor a sorával együtt a téma is törlődik, a vezetőjével és a szakiránya is ha csak egyedül volt. –módosítási anomália: ha egy lány hallgató férjhez megy, ha megváltozik egy téma vezetője akkor több sort is módosítani kell. SZAKKODSZAKNEV VEZNEV KERESZTNEV TDKKOD HSZ % TDKTEMA FONOKTVKOD

13 Def: Második normálformában akkor és csak akkor van a reláció, ha első normálformában van és az összes nem kulcs attribútum funkcionálisan teljesen függ az elsődleges kulcstól. Jelen példában az összetett kulcstól csak a százalékos megoszlás függ, a többi csak részben függ a kulcstól. A táblák szétbontása a megoldás: –R(A,B,C,D) Elsődleges kulcs (A,B) R.A->R.D akkor R relációt a következőképpen kell felbontani R 1 (A,D)R 2 (A,B,C) Elsődleges kulcs (A)Elsődleges kulcs (A,B) Idegen kulcs (A), hivatkozik R 1 -re Az idegen kulcsra azért van szükség hogy a R 1 JOIN R 2 = R teljesüljön! Tehát a JOIN (összekapcsolás) előállítsa az R összes sorát.

14 SZAKKODSZAKNEV VEZNEV KERESZTNEV TDKKOD HSZ % TDKTEMA FONOKTVKOD SZAKKODVEZNEVKERESZTNEVSZAKNEVHSZ SZ123KissAntalÁRAML323 SZ345NagyBélaGÉPTERV 212 SZ348LakatosImreMANAGER 345 HSZTDKKOD% 3231234520 2122345640 2121294510 3452345585 TDKTEMATVKODFONOKTDKKOD Téma134NEKAR12345 Téma243TTIB23456 Téma323HOROL12945 Téma423HOROL23455 Az 1NF reláció felbontása 2NF relációkra

15 Harmadik normálforma A példában még mindig marad redundancia ami anomáliákhoz vezet. Keressük meg melyek ezek? Def: Egy reláció akkor és csak akkor van 3NF-ben, ha 2NF-ben van, és az elsődleges kulcshoz nem tartozó attribútumai csak az elsődleges kulcstól függnek funkcionálisan. Másként fogalmazva: funkcionális függés csak az elsődleges kulcsokból indulhat ki. Szét kell bontani a problémás táblát két részre: TDKTEMATVKODFONOKTDKKOD Téma134NEKAR12345 Téma243TTIB23456 Téma323HOROL12945 Téma423HOROL23455 FONOKTVKOD NEKAR34 TTIB43 HOROL23 TDKTEMATDKKODTVKOD Téma11234534 Téma22345643 Téma31294523 Téma42345523

16 ACCESS mintapélda Egy vállalat termékeinek és megrendelőinek nyilvántartó rendszere: (első közelítés, hányadik normálforma?) –MEGRENDELŐ {megrendelő_kod, név, cím} –RENDELÉSFEJ {rend_szám, megrendelő_kód, rendelés_dátum} –RENDELÉS {rend_szám, kód, darab, kész} –TERMÉK {kód, név, ár} Elemzési fázis: –Minden rendelésfej-sor egy megrendelőt és egy rendelésszámot azonosít. –Egy megrendelő rendelhet többször is –Egy termék több rendelésben is lehet. –A rendelés és a megrendelő között a rendelésfej teremt kapcsolatot. –stb…

17 A modell továbbfejlesztése: Egy termék több alkatrészből (jelen esetben csak monolit alkatrészek) épülhet fel. T1 T2 T3 TermékAlkatrész A1 A2 A3 Egy termék több alkatrészből épül fel. Egy alkatrész többféle terméke is beépülhet. Ez a tény a Termékek és Alkatrészek között M:N kapcsolatot jelent. Az N:M kapcsolatot relációs adatbázis szemlélet nem tudja kezelni. Ezért egy kapcsolótábla használata szükséges. Ami Termékek és Alkatrészeket összerendeli.

18 TermékAlkatrész T1 T2 T3 A1 A2 A3 T1_A2 T2_A3 T3_A2 T3_A1 Szerelvény A szerelvény egy eleme pontosan meghatároz pontosan egy alkatrészt és pontosan egy terméket. A termék halmaz minden egyes eleméhez tartozik egy, nulla vagy több szerelvény halmazelem. Az alkatrész halmaz minden egyes eleméhez tartozik egy, nulla vagy több szerelvény halmazelem. Termékek - Szerelvény1:N Szerelvény - AlkatrészekN:1 A szerelvény táblában a beépített mennyiség is tárolható.

19 Megszorítások, szabályok: mezőnévszabály árpénznem, 0 tizedesjegy azonosító>=100 AND <1000dátum készletszám, rögzített, beviteli maszk: 0000 kód3 karakter, szöveg, beviteli maszk >LL0

20 Megszorítások, szabályok: (folytatás) mezőnévszabály mértékegység2 karakter, érvényességi szabály: IN(”kg”; ”m”; ”db”) rendelés_szám7 karakteres szöveg, 1 nagybetű + 1 kisbetű + ”-” + 4 számjegy

21 Feladatok Írassuk ki azon anyagok azonosítóját, melyek 2-vel kezdődnek –SELECT Alkatrész.azonosító FROM Alkatrész WHERE Alkatrész.azonosító > 200; –SELECT Alkatrész.azonosító FROM Alkatrész WHERE Alkatrész.azonosító BETWEEN 200 AND 299; Írassuk ki azon anyagok azonosítóját, amelynek mértékegysége m (és/vagy) kg. –SELECT Alkatrész.azonosító FROM Alkatrész WHERE Alkatrész.mértékegység="cm" OR Alkatrész.mértékegység ="kg"; –SELECT Alkatrész.azonosító FROM Alkatrész WHERE Alkatrész.mértékegység="cm" AND Alkatrész.mértékegység ="kg"; Tábla sorainak a száma –SELECT COUNT(*) FROM Alkatrész; Tábla különböző sorainak kiírása: –SELECT DISTINCT mértékegység FROM Anyag;

22 Feladatok Különböző mértékegységek száma (Access nem támogatja) –SELECT COUNT(DISTINCT mértékegység) FROM Anyag; Számoljuk meg, hogy az anyagokból melyikből van 15 egységnél kevesebb –SELECT COUNT(*) FROM Anyag GROUP BY készlet < 15; Van e B betűvel kezdődő termék az adatbázisban: –SELECT név FROM termék WHERE név LIKE ‘A*’;