Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

ADATBÁZISOK ELŐADÁS Dr Quittner Pál Baksa-Haskó Gabriella.

Hasonló előadás


Az előadások a következő témára: "ADATBÁZISOK ELŐADÁS Dr Quittner Pál Baksa-Haskó Gabriella."— Előadás másolata:

1 ADATBÁZISOK ELŐADÁS Dr Quittner Pál Baksa-Haskó Gabriella

2 Témakörök  Adatbázis-kezelő rendszerek  Adattárolás, adatszervezés  Adatmodellek  Relációs modell  Katalógus, adatszótár  Gyakorlati problémák és megoldásuk  Adattárházak

3 Adatbázisok Információs infrastruktúra Adatfeldolgozás Vezetői információ Telekommunikáció Központi és egyedi automatizált irodai szolgáltatások Cél:Információs technológia alkalmazásával növelje a szervezetben dolgozó emberek teljesítményét.

4 Az információs rendszer részei  Adatok,  Hardver (eszközök),  Szoftverek,  Felhasználók Az információs rendszer adatokat tárol a hardveren, melyről az eszközök és a szoftver segítségével a felhasználók információkat kaphatnak

5 Adatbázis  Tartalmazza az adatokat, az adatok ábrázolási módját, az adatok közti összefüggéseket, kapcsolatokat, az adatokhoz való hozzáférés ellenőrzési módját.  Működni kell rajta egy olyan adatbázis- kezelő rendszernek, mely lehetővé teszi az adatokból a bennük lévő információk előállítását. (Data Base Management System, DBMS)

6 Adatbázis  Két főtípusuk: Tény adatbázis Szöveges információ visszakereső rendszerek.  A kettő között a határvonal nem éles.  Az Oracle az első csoportba tartozik.

7 Tény-adatbázisok csoportosítása  Tranzakció orientált adatbázisok: a szervezet napi feladatait támogatják tranzakciók folyamatos feldolgozását végzik el.  Adattárházak: vezetői döntések támogatására szolgáló igen nagy, statikus adatbázisok lekérdezések és elemzések végrehajtására szolgálnak

8 Leggyakrabban használt adatbázis- kezelő rendszerek  ORACLE  IBM Universal DataBase (régebben DB2)  Microsoft SQL Server  Microsoft Access

9 A (tény)adatbázis-kezelő rendszereknek biztosítani kell:  Különféle igények hatékony kielégítését  Adatfüggetlenséget  Adatok közti komplex kapcsolatok ábrázolását  Redundancia mentességet illetve annak ellenőrzését  Egyszerű használatot  Az adatok védelmét, nehogy illetéktelenek hozzáférhessenek  Az adatok integritását, hogy a hozzáférésre jogosultak se ronthassák el lehetőleg az adatbázist

10 A (tény)adatbázis-kezelő rendszereknek biztosítani kell:  Helyreállíthatóságot, hogy bármely esetleges hiba esetén az eredeti állapotot vissza lehessen állítani  Több felhasználós adatbázisoknál az egyidejű hozzáférést, illetve annak ellenőrzését  Osztott adatbázisoknál ezenfelül lehetővé kell tenni az adatok szétosztását és megtalálását a különböző helyekről, az egyidejű hozzáférés ellenőrzését és az adatforgalom optimalizációját is

11 Az adatbázis-architektúra három szintje  Belső vagy fizikai szint A tényleges fizikai tárolási és elérési módot írja le.  Külső szint Miként látják az egyes felhasználók az adatbázist.  Koncepcionális szint Logikailag egységbe ötvözve hogyan néz ki ténylegesen az adatbázis. Ennek különböző vetületeit látják a külső szinten a különböző felhasználók. Ez képződik le tárolási és elérési struktúraként a belső szinten.

12 Az Oracle-ben elsősorban a koncepcionális és a külső szintet határozzuk meg. A belső szintet csak bizonyos határok között tudjuk befolyásolni Az adatbázis-architektúra három szintje

13 Komponensek  Kapcsolattartó  Feladatkonvertáló  A DBMS nyelvén megfogalmazott utasításokat értékeli, elemzi és ha végrehajthatók, meghatározza ennek optimális módját.  Elérés meghatározó  Átfordítja az operációs rendszer számára érthető parancsokká. Elindítja, majd értékeli végrehajtásukat.

14 Működési elv

15 1Adat kérése az adatbázisból (Alkalmazási program) 2Kérés értelmezése, elemzése (Adatbázis- kezelő rendszer) (szintaktika, létezés, jogosultság) 3aVégrehajtható → operációs rendszerhez 3bNem hajtható végre → programhoz 4Kapcsolat a külsö tárolóhoz (operációs rendszer) 5Kért adat átvitele (op rendszer, tárolóból pufferbe) 6Adatok átadása, visszajelzés programnak 7Adatok átvétele programba.

16 Hozzáférés szabályozása

17 Követelmények  Egy korszerű adatbáziskezelő szoftvertől megkövetelhető, hogy a következő szolgáltatásokat megfelelő szinten biztosítsa:  Valamennyire tudják használni csekély számítástechnikai ismeretekkel rendelkezők is,  Legyen felhasználóbarát lekérdező nyelve és jelentés készítője (report generátor),  Biztosítsa a rendszer legfontosabb jellemzőinek automatikus dokumentálását,  Képernyőhasználat egyszerű legyen,  Párbeszédesen (interaktív módon) lehessen használni,  Egyszerűen lehessen az adatbázis-kezelő utasításokból (magas szintű) programnyelvi utasításokat generálni.

18 Szoftver rétegek  Operációs rendszer  Adatbázis-kezelő rendszer  Alkalmazási programok Az Oracle különböző operációs rendszerek alatt tud futni. Az alkalmazási feladatokat az SQL nyelven interaktívan, vagy programba építve fogalmazhatjuk meg.

19 A DBMS nyelv funkciói  Adatleíró nyelv (Data Definition Language) adatok és a köztük lévő kapcsolatok leírása,  Adatkezelő nyelv (Data Manipulation Language) adatok visszanyerésére, beírására, módosítására, törlésére.  Tranzakció vezérlő nyelv (Data Control Language) tranzakciós folyamatok vezérlése :

20 Alkalmazási lehetőségek  önálló, interaktív (Self Contained System),  programnyelvbe beépíthető (Host Language System). Alapjuk a szabványos SQL nyelv (Structured Query Language). A felhasználó csak azt mondja meg, mit akar csinálni. A „hogyan”-t a DBMS határozza meg.

21 Adatbázis felügyelő fő feladatai  Az adatbázis megszervezése. Ez rendszerint magában foglalja az adatmodell kialakítását, az adatbázis leírását, a definiált adatok elnevezését, amennyiben mód van rá, a keresési stratégiák megválasztását, a hozzáférési jogok meghatározását és az adatbázis betöltését;  Az adatbázist használók segítése;  Az adatbázisba bevitt adatok helyességének ellenőrzése, illetve segítségnyújtás az erre kijelölt felhasználóknak az ellenőrzés elvégzéséhez;  Az adatbázis adatainak rendszeres kimentése, hogy esetleges hibák után az eredeti helyes állapotot vissza tudjuk állítani;  Az adatbázis használatának állandó figyelése, a hatásfok jelentős csökkenése esetén az adatbázis újraszervezése;  A felhasználók igényei alapján az adatbázis struktúrájának módosítása.

22  Az adatbázis-felügyelő munkája azért is igen bonyolult, mert az adatbázis létrehozásakor és karbantartásakor igen sok, egymással gyakran ellentétes szempontot és érdeket kell figyelembe venni. Ráadásul az egyes szempontok rangsorolása sem mindig egyértelmű, és az idők folyamán változhat is.  Jó DBMS önmagában nem elegendő. Az adatbázist jól kell megtervezni és jól is kell tudni használni.  Különben csak egy bonyolultabb, lassabb, drágább, nagyobb erőforrás igényű módszert használhatunk Adatbázis felügyelő fő feladatai

23 Gyakori tervezési hibák  Nyílt logikai átfedés: ugyanaz az adattípus azonos névvel több állományban is szerepel;  Rejtett logikai átfedés: ugyanaz az adattípus különböző elnevezéssel bár, de több állományban is szerepel;  Látszólagos logikai átfedés: ugyanaz az elnevezés különböző adatállományokban más adattípust jelent;  Fizikai átfedés: ugyanazon adatokat többszörösen tároljuk;  Logikai átfedés hiánya: a különböző adatállományok között a megfelelő logikai kapcsolatot nem tudjuk létrehozni. (Pl. az árucikkekről és a raktárakról is egyedenként külön-külön minden adatunk megvan, de azt nem tudjuk ebből megállapítani, hogy melyik raktárban milyen cikkek vannak.):  Eltérő kódolás: ugyanannak a fogalomnak az azonosítására többfajta kódrendszert használunk.

24 A kilencvenes évektől az adatbázisokat jellegük szerint három nagy csoportba oszthatjuk:  személyi számítógépen megvalósított egy személy vagy csoport információs igényeit kielégítő adatbázis, melyhez egy időben csak egy felhasználó férhet hozzá,  nagy számítógépen (mainframe), vagy megfelelő hozzáférési védelemmel rendelkező személyi számítógép hálózaton levő, egy központi helyre telepített integrált adatbázis, melynek a legkülönbözőbb személyek és csoportok különféle igényeit kell egyidejűleg, és egymástól függetlenül kielégítenie,  nagy- és/vagy személyi számítógépek hálózatára alapozott integrált, de megosztott adatbázis, melyben a leginkább helyileg igényelt adatok a felhasználás helyén vannak, ahol a hálózat bármelyik másik pontjáról is elérhetőek. A mindenki által használt adatok tárolása, és annak nyilvántartása, hogy az elosztott adatok melyik adatbázisban találhatók, viszont centralizáltan, vagy legalább is központi felügyelet alatt történik.

25 A főhangsúlyt olyan adatbázisok létrehozásának és működtetésének ismertetésére helyezzük, melyekben  igen sok (több száz) különböző típusú rekord van  a különböző típusú rekordok között igen sokféle kapcsolat áll fenn  a rekordok össz száma milliótól több százmillióig is terjedhet  naponta akár több ezer műveletet (lekérdezés, módosítás) is végeznek az adatbázisban  egyszerre több tucat, sőt több száz terminálról is elérhető és használható az adatbázis interaktív módon  az adatok védelmét, biztonságát, helyreállíthatóságát a rendszer biztosítja

26  Mindegy, hogy milyen gépen, milyen szoftverrel dolgozunk, általános érvényű a szabály, hogy bizonyos adatmennyiségig, és/vagy tranzakciószámig nem kell törődnünk a hatékonysággal; egy adott küszöb fölött viszont már nem árt, ha gondolunk rá; míg egy meghatározott szint fölött már okvetlenül tekintetbe kell vennünk, ha működőképes rendszert akarunk létrehozni.  Az, hogy ezek a szintek ezer vagy százezer rekordnál, 1 vagy 100 tranzakció/percnél vannak, az már a rendelkezésünkre álló hardvertől, az alkalmazott operációs rendszertől, és nem csekély mértékben az adatbáziskezelő szoftvertő, az adatbáziskezelő rendszer hatékonyságától függ.

27 Tárolás és elérés Az adatmodell belső, fizikai szintje  Feladat Szerkezet kialakítása Adatok elérése  Ellentétes szempontok  Létrehozási idő csak egyszeri feladat

28

29 Adatszervezési szempontok  Milyen adatokra lesz leggyakrabban szükségünk  Milyen hardveren tároljuk az adatokat  Mekkora az adatmennyiség  Mekkora adatmennyiséget kell meghatározott sorrendben elérni  Milyen mezők alapján kell keresni  Véletlen keresésnél hány rekordot találunk  Csak olvasunk, vagy változtatunk is  Növekedhet-e a rekordhossz  Hány új adatot írunk be, mennyit törlünk és milyen gyakorisággal

30  Belső szint átlagos felhasználó előtt elvileg rejtve marad  Gyakorlatban fontos  Elérési idő nagyságrendekkel megnövekedhet  Okok: Nem megfelelő adatszerkezet Adatok rossz eloszlása Adatszerkezet nem felel meg a feldolgozás logikájának Adatszervezési szempontok

31 Lemezek  Mágneslemez akárhányszor írható és olvasható  CD/DVD csak olvasható egyszer irható akárhányszor írható és olvasható

32 Lemez felépítése  blokk (lap)  sáv  cilinder Író/olvasó fej  fizikai olvasás blokkonként történik  logikai olvasás rekordonként történik

33 Lemez hozzáférési idő minmax  Fejmozgatás02-50 ms  Fejkiválasztás0mikrosec  Forgási idő010-25ms  Adatátvitel1100 Mbyte/sec  Hozzáférési idő Átlagosan: ms Optimális: 0

34 Mágneslemezek jellemzői Felületek száma20 Cilinderek száma200 – 400 Sávok kapacitása kB Lapméret1 -32kB Teljes tároló kapacitás100 MB – 500GB

35 Címzés  Lapcím: Lemezegység Cilinder Felület Sáv blokk  Abszolút  Relatív  Szimbolikus Lapcím + relatív cím a lap címtáblázatában

36 Címzés

37 Szervezési és elérési módok  Lineáris Soros (fizikai sorrend) Szekvenciális (logikai sorrend)  Közvetlen Indexelt Hashing  Hierarchikus  Particionált

38 Soros szervezés/elérés  A rekordok helye és keresési kulcsa között semmilyen összefüggés nem áll fenn.  Az adatokat fizikai elhelyezésük alapján, sorban egymás után dolgozzuk fel.  Minden adatállományon automatikusan megvalósul.  Karbantartása egyszerű.  Sok adat beolvasásakor igen gyors.  Egy egyedi kulcsértékkel rendelkező rekord megtalálásához átlagosan a tároló helyek felét végig kell vizsgálnunk.  Ha több rekord is rendelkezhet a keresett értékkel és mindegyiket meg kell találnunk, vagy annak megállapítására, hogy az adott kulcsú rekord nincs bent az állományban, mindig végig kell olvasnunk az állomány tárolására szolgáló egész területet.  Mindig alkalmazható

39 Szekvenciális szervezés/elérés  Szekvenciális szervezésnél az egymást követő rekordok keresési kulcsa között egyértelmű logikai kapcsolat van. Növekvő sorrendnél mindegyik rekord kulcsa nagyobb (vagy egyenlő, ha duplikátumok is lehetnek) a közvetlenül előtte lévő rekord kulcsánál, csökkenő sorrendnél kisebb, vagy egyenlő.  Bármely rekord után csak a közvetlenül utána következőt tudjuk elérni (egyes szerkezetekben még a közvetlenül előtte lévőt is).  Szekvenciális elérést ugyanazokon az adatokon többféle szempont szerint is létrehozhatunk.

40 Lista szerkezet  A listaszerkezetben a fizikai és a logikai sorrend között semmiféle kapcsolat sem kell legyen.  A szekvenciális sorrendben álló, a logikailag egymás után következő rekordokat pointerek kapcsolják össze.  Minden adatrekord két részből tevődik össze: a tényleges adatmezőkből álló adatrészből a pointer mezőből, mely a hozzá logikailag közvetlenül kapcsolódó rekord(ok) címét tartalmazza. Ezt az adatbázis kezelő rendszer kezeli, a felhasználó számára rejtve van.  Az elérési idő minimalizálása érdekében célszerű, ha az adatok fizikai elhelyezésének a sorrendje megegyezik, vagy legalább is nem túl sok, a sorból kilógó rekord kivételével majdnem megegyezik a logikai sorrenddel.

41 Lista

42 Lista szerkezetek

43 Változtatás listában

44 Lista és soros szerkezet  Lista szerkezet előnyei Módosítás, beszúrás egyszerűbb Szekvenciális feldolgozáshoz nem kell rendezés Többféle szekvencialitás is megvalósítható Kevesebb adatot kell végigvizsgálni Más adatszerkezet is megvalósítható (pl hierarchikus)  Lista szerkezet hátrányai Törlés, beszúrás lassabb Ha nincs sűrűsödés, sokkal lassabb a keresés Pointerek miatt nagyobb tárolóigény Bonyolultabb programozás (nem igazi hátrány)

45 Közvetlen elérés A keresett adatokhoz azonnal hozzá tudunk férni (gyakorlatilag 1 – 4 lépéssel) indexek hashing

46 Indexek  Meggyorsítják az indexelt oszlopra a közvetlen és a szekvenciális hozzáférést.  Karbantartásuk automatikus.  Lassítja a változtatást.  Helyet foglalnak el.  Bármikor létrehozható, törölhető.

47 Indexek  Indextáblázat tartalmazza indexértékeket, hozzátartozó rekord címét.  Index lehet egyedi illetve duplikált, növekvő illetve csökkenő, elemi illetve összetett Szelektív illetve nem szelektív  Megvalósítás B+ fa (szelektív) bitmap (nem szelektív)

48 Index tábla

49 Index terület Tároló feloszlása:  a tényleges adatokat tartalmazó adatterületkb. 2/3  az indexeket és az indexekben való gyors keresést lehetővé tevő egyéb szerkezeteket tartalmazó indexterület kb. 1/3

50 B+ fa

51 B+ fa módosítás

52 Bitmap index  Duplikált indexekre célszerű definiálni, ha az index nem nagyon szelektív. ROW-ID-1ROW-ID-2ROW-ID-3... Ind-ért-1011 Ind-ért-2100 Ind-ért-3000  Ha a bitmap-ben a bit értéke 1, akkor az adott sorban a mező értéke a megfelelő index értéke.  Párhuzamos tranzakcióknál módosításkor kevésbé hatékony, de nagyon jó lehet adattárházaknál (Date Warehouse).

53 Bittérkép példa

54 Keresés több kulcs szerint Alapeset: SQL utasításban WHERE oszlop1=érték1 AND oszlop2=érték2 WHERE oszlop1=érték1 OR oszlop2=érték2 Elegendő (lehet) az egyik feltétel kielégítése. SQL optimalizáló határozza meg a kiértékelés  módját soros szekvenciális (melyik index) direkt (melyik index)  sorrendjét Ez az elérési út (Access Path)

55 ÉS/VAGY feltétel - 1

56 ÉS/VAGY feltétel - 2 Két feltétel összekapcsolása bit- térkép segítségével.  ÉVFOLYAM = 2 VAGY SZÜLETÉSI ÉV = 1998 feltételnek az 1112 és az 5212 rekordok  ÉVFOLYAM = 2 ÉS SZÜLETÉSI ÉV = 1998 feltételnek csak az 1112 rekord felel meg

57 Keresési példa Feladat:  rekord egyenletes eloszlásban 10 rekord/lap  3 kulcs (életkor, végzettség, szakképesítés) 10 – 10 különböző értékkel egyenletes eloszlásban  Indexek 100 rekord/lap Keresés: Együttesen a 3 kulcs kombinációja alapján A feltételnek 100 rekord fog megfelelni!

58 Keresési példa - Helyigény  Adatok lap  Egy tulajdonságra index1 000 lap  Mindhárom tulajdonságra index3 000 lap  Hármas index1 000 lap  Minimális helyigény lap  Maximális helyigény lap

59 1.Összes adat beolvasása, ellenőrzés (pl. nincsenek indexek) soros lapolvasás. 2.Valamelyik kulcson végigmenve (a kulcshoz tartozik index), másik két érték ellenőrzése index, 100 indexlap soros beolvasása lap beolvasása és ellenőrzése  nem sűrűsödő (majdnem) rekord/lap direkt beolvasása. Rosszabb!!!  sűrűsödő rekord, 1000 lap soros beolvesása soros beolvasás Keresési példa - Lehetőségek

60 3.Végigmenni a három indexen, kiválasztani a közös rekordokat 3* index, 300 indexlap soros beolvasása 100 rekord/lap direkt beolvasása 4.Új index a három tulajdonságra együttesen 1 indexlap direkt beolvasása 100 rekord/lap direkt beolvasása  (Ha sűrűsödik, akkor soros) Időnyereség 1 -2 nagyságrend!!!

61 Hashing - 1  Jól kiválasztott algoritmus segítségével a keresési kulcs és a rekord tárolási címe között egy „majdnem egyértelmű” kapcsolatot hozunk létre.  Olyan leképezést alkalmazunk a kulcsok és a címek között, amely különböző kulcsokhoz optimálisan mindig, gyakorlatilag csaknem mindig különböző címeket rendel hozzá.  A leképezés által azonos címhez rendelt, de különböző kulcsú elemeket szinonimáknak nevezzük.  A szinonimák címét leggyakrabban egy pointerrel, több szinonima esetén egy pointer- lánccal csatoljuk az eredetileg kijelölt címhez.

62 Hashing - 2  A hash-algoritmus kiválasztási szempontjai ne pazaroljunk el túl sok helyet minél kevesebb szinonim rekordunk legyen  Algoritmus pl. primszámmal osztás maradéka  Észszerű kompromisszum: 80-85%-os kitöltöttség mellett nem eredményez 20%-nál több szinonimát. Ez azt jelent, hogy az adatokat durván 1,2 lépéssel tudjuk elérni.

63 A relációs modell  Az adatmodellben leírjuk a különböző típusú adatokat, a köztük fennálló kapcsolatokat, összefüggéseket, valamint a velük kapcsolatos adatvédelmi eljárásokat is.  A logikailag összetartozó adatokat összegyűjtjük önálló egyedtípusokba, entitásokba. Meghatározzuk, hogy az egyes entitásokat mivel tudjuk egyértelműen azonosítani, és ezen kívül milyen további tulajdonságokkal rendelkeznek (attribútumok).

64 Főbb modellek  hierarchikus(pl. IMS)  hálós(pl. IDMS)  relációs(pl. Oracle, DB2)  objektum orientált Ma a gyakorlatban használatos rendszerek zöme a relációs modellen alapul.

65 Kapcsolat  Lehet két entitás típus között, vagy ugyanazon entitás különböző attribútumai között.  A relációs modellben általában a különböző entitások közti kapcsolat a fontos.  Az entitáson belüli kapcsolatokat rendszerint kiküszöböljük.

66 Kapcsolattípusok  A két elem független egymástól;  Kölcsönösen egyértelmű kapcsolat (pl. jó kódrendszerben a kód és a megnevezés között);  Egyik irányba egy, a másikba többértelmű (1: N) kapcsolat (Pl. szülőanya és gyerekei);  Több-több (M:N) kapcsolat (pl. férfiak és nők). Az egyes kapcsolatok egymásra is épülhetnek.

67 1:1 Kapcsolat

68 1:N Kapcsolat

69 N:M Kapcsolat

70 Relációs ábrázolási mód  Egyedeket relációkban (speciális táblázatok) ábrázolja.  Ezek írják le a valós világ különböző egyedeit (entitásait) és azok tulajdonságait.  Egyedek közti kapcsolatokat is ábrázolhat relációkban.  Adatkezelés relációs műveletekkel valósul meg.

71 Előnyök és hátrányok Előnyök:  Nagyon közel áll a mindennapi szemlélethez;  Igen rugalmasan módosítható;  Jól elkülöníthető, függetleníthető a három szint. Hátrányok:  Gépi megvalósítás kevésbé hatékony;  Ma már ez nem olyan nagy baj.

72 A relációk tulajdonságai  Egyértelmű relációnév az adatbázisban;  Sorok jellemzik az egyedeket, oszlopok az egyes tulajdonságokat;  Minden sorban azonos számú oszlop van;  Oszlopoknak a reláción belül egyértelmű neve van;  Bármely oszlop egy sorban legfeljebb egy értéket vehet fel.  Ha nincs értéke, akkor NULL;  Oszlopok sorrendje tetszőleges;  Nincs két teljesen azonos sor;  Létezik az oszlopoknak legalább egy olyan kombinációja, amelyik egyértelműen azonosítja a sort. Ez az elsődleges kulcs.  Bármely adatot azonosít: relációnév + oszlopnév + elsődleges kulcs értéke.

73 Táblázatok, nézetek Nem tároljuk minden egyed minden tulajdonságának értékét fizikailag.  Alap vagy bázis reláció. Táblázat, tábla Fizikailag tárolt.  Virtuális reláció. Nézet, view Nem tartalmaz adatokat. Táblázatokból állítjuk elő relációs műveletekkel.  Materialitált nézet. Táblázatokból állítjuk elő relációs űveletekkel. Fizikailag tárolt. Változik, ha változnak az alaptáblázatok  Pillanatfelvétel, snapshot Táblázatok, nézetek adatai egy meghatározott pillanatban. Fizikailag tárolt.  Lekérdezések, kiválasztások eredménye Nem igazi reláció és csak ideiglenesen létezik.  Közbenső táblázatok Ideiglenesen kellenek adott műveletekhez, feladatokhoz.

74 Kulcsok Adatok integritását, relációk ellentmondás mentességét biztosítják. A rendszer automatikusan ellenőrzi  elsődleges kulcs  idegen kulcs (relációk közti kapcsolat, pl. megrendelésben levő áruk kódjai között),

75 Elsődleges kulcs PRIMARY KEY  Egyértelműen azonosítja egy reláció sorait.  Az elsődleges kulcs (vagy annak része) nem lehet (vagy ne legyen) null érték, és ne tartalmazzon fölösleges oszlopokat.  Fontos eldönteni, mi legyen az elsődleges kulcs, ha több lehetőségünk van. Pl. periódusos rendszerben: elem neve, rendszáma, vagy vegyjele

76 További integritási lehetőségek  Egyedi index definiálása (ez az oszlop sem vehet fel azonos értéket két sorban)  Adott mezőre meghatározott feltételnek kell teljesülnie (pl. ellenőrző szám, adott érték lehet csak)

77 Idegen kulcs FOREIGN KEY  Hivatkozó relációban egy oszlop (kombináció) csak olyan értéket vehet fel, amelyik vagy a NULL-érték, vagy a hivatkozott táblázat elsődleges kulcsértékeinek valamelyikével egyenlő.  Relációk között hoz létre 1: N kapcsolatot. Érvényesnek kell maradnia minden változtatásnál, bevitelnél, törlésnél.

78 Példák idegen kulcs kapcsolatra  Nem lehet megrendelni nem létező árut  Nem lehet felvenni nem létező tantárgyat  Csak létező témára/osztályba lehet a dolgozókat beosztani

79 Idegen kulcs módosítása Bevitel  Hivatkozottba: bármelyik helyes elsődleges kulcs  Hivatkozóba: csak olyan érték, amilyen elsődleges kulcs van a hivatkozottban, vagy NULL-érték.

80 Idegen kulcs módosítása Törlés  Hivatkozóból: korlátozás nélkül  Hivatkozottból: Ha egy értékre nincs hivatkozás, korlátozás nélkül Ha van  korlátozott (restricted, nem törölhető)  null értékre állítás (set null, a hivatkozó táblázat idegen kulcsa NULL-érték lesz)  tovagyűrűző (cascade, a hivatkozó megfelelő sora is törlődik )

81 Idegen kulcs módosítása Módosítás  Hivatkozóból: lásd bevitelt  Hivatkozottból: lásd törlést, de a cascade a hivatkozóban az új értékre való módosítást jelenti.

82 Idegen kulcs kapcsolat

83

84

85 Indexek  Meggyorsítják az indexelt oszlopra a közvetlen és a szekvenciális hozzáférést.  Karbantartásuk automatikus.  Lassítja a változtatást.  Helyet foglalnak el.  Bármikor létrehozható, törölhető

86 Indexek Indextáblázat (B+ fa) tartalmazza  indexértékeket,  hozzátartozó rekord címét. Index lehet  egyedi illetve duplikált,  növekvő illetve csökkenő,  elemi illetve összetett.

87 Entity-Relationship modell  Adatbázis tervezésének egyik módja.  Top-down tervezés.  Meghatározzuk az entitásokat és a köztük fennálló kapcsolatokat

88 A koncepcionális szint kialakítása  Meghatározzuk az egyes entitásokat, azok elsődleges kulcsát és attribútumait;  Az 1:N kapcsolatokat idegen kulccsal biztosítjuk;  Az N:M kapcsolatokat fölbontjuk 1:N kapcsolatra egy új reláció közbeiktatásával. Ennek elsődleges kulcsa a két reláció elsődleges kulcsának konkatenációja, oszlopai, amelyek mindkét reláció kulcsától együttesen függenek;  Normalizálással, ha kell, tovább bontjuk a relációkat;  Kiszűrjük a redundanciát. (Minden attribútum, ami nem kulcs, csak egyszer szerepelhet.)

89 E-R diagram

90 Gépjármű reláció RENDSZÁMGYÁRTMÁNYTÍPUSSZÍNŰRTAR- TALOM EGYÉB CYX462MitsubishiColt GLFehér1298 … DY9680FordSierra LEzüst1598 … ABC017DaihatsuCharadeKék980 … V24034FordEscortPiros1199 … CZ9404VolkswagenFastback TLZöld1596 … HHU561MitsubishiCarismaKék1790 …

91 Tulajdonos reláció NÉVLAKCÍMJOGOSÍTVÁNYFOGLAL- KOZÁS EGYÉB Kiss János 1Budapest I. Fő u. 1. CX162233autószerelő … Quittner PálBudapest V. Markó u. 1/b. CC23456adatbázis szakértő … Lakinger BélaAbádszalók, Hős u. 69. ABC4321tengerész … Kiss János 2Pécs, Anna u. 16 tanár … Computer KftGyőr, Rába köz 1/b …

92 G&T reláció RENDSZÁMTULAJDONOSTULAJDONJOG KEZDETE TULAJDONJOG VÉGE CYX462Quittner DY9680PálKiss János DY9680Lakinger Béla ABC017Computer Kft Y24034Lakinger Béla ABC017Kovács Imre HHU561Quittner Pál

93 Relációs műveletek A relációs modell legfőbb előnye az, hogy a különféle feltételeknek megfelelő fizikailag is létező egyedeit vagy ezekből logikai úton előállítható, vagy csak ideiglenes egyedeit, könnyen, egyszerűen megtudjuk határozni, azonosíthatjuk, kiválaszthatjuk, definiálhatjuk őket.

94 A relációs műveleteket az alábbi feladatok elvégzésére használjuk:  A kereséskor kiválasztandó adatok meghatározása;  A módosítandó, törlendő adatok kiválasztása;  A beviendő adatok meghatározása;  Virtuális adatok definiálása. Ezek lehetnek az adatmodellnek állandó, névvel azonosított relációi (nézetek, pillanatfelvételek) vagy csak ideiglenesen létezők, melyek az adott feladat megoldásához szükségesek és utána automatikusan megszűnnek  A fentieken kívül felhasználjuk még a relációs műveleteket az adatbázishoz való hozzáférési jogok meghatározásánál és integritási feltételek megadásánál is, amikor is ezek segítségével jelöljük ki a védelemmel rendelkező, lezárandó illetve egymással kapcsolatban álló objektumok, relációk körét.

95 Legfontosabb műveletek  A rendszer zárt a műveletekre. Az eredmény újra reláció lesz.  Megkülönböztethetünk egy és két (több) operandus műveleteket.  átnevezés (RENAME)  korlátozás vagy restrikció (RESTRICT)  vetület vagy projekció (PROJECT)  keresztszorzat (TIMES)  unio (UNION)  metszet (INTERSECT)  különbség (DIFFERENCE)  egyesítés (JOIN)  egyesítés alapértelmezéssel (külső v. OUTER JOIN)  bővítés (EXTEND)  csoportfüggvény képzés (SUMMARIZE)  kijelölés.

96 Egy relációs műveletek

97 Keresztszorzat

98 Union  A két reláció minden sorát tartalmazza  Az azonos sorok csak egyszer szerepelnek benne.  A relációknak unió kompatibilisnek kell lenniük. (Azonos számú, azonos sorrendben lévő, azonos adattípust tartalmazó oszlopokból állnak).  UNION ALL  A duplikált sorok duplikálva szerepelnek benne.  Gyorsabb. Ha tudjuk, hogy a két reláció biztosan különböző sorokból áll, akkor ezt használjuk

99 Union példa

100 Intersection (metszet)  A két táblázat közös sorait tartalmazza.  A táblázatok unió kompatibilisek

101 Minus (különbség)  R – S azokat a sorokat tartalmazza, amik bent vannak R- ben, de nincsenek bent S-ben.  A táblázatok unió kompatibilisek

102 JOIN (Egyesítés)  A művelet két táblázat keresztszorzatának (Descartes szorzat) választja ki meghatározott sorait a JOIN feltétel alapján. Ez a gyakorlatban a két objektum meghatározott oszlopainak (join oszlopok) páronkénti összehasonlítását jelenti.  A táblázatok/nézetek sorainak összekapcsolása szerint megkülönböztetünk Természetes vagy belső egyesítést (natural vagy inner join). Ha nem teszünk hozzá kiegészítést, akkor a join műveleten általában ezt értjük. Külső egyesítést (outer join).

103 Természetes (belső) JOIN A természetes (belső) join eredménye csak azokat a sorokat tartalmazza, amelyekben mindkét join táblázat soraira érvényes a join feltétel. A természetes join szimmetrikus, a join objektumok megadásának sorrendje lényegtelen.

104 JOIN példa Az egyes személyek tulajdonában levő gépkocsik gyártmánya a (GÉPJÁRMŰ és G&T táblázatokból) RESTRICT G&T WHERE TULAJDONJOG VÉGE IS NULL) JOIN GÉPJÁRMŰ (RENDSZÁM)) PROJECT (TULAJDONOS, RENDSZÁM, GYÁRTMÁNY) RENDSZÁMGYÁRTMÁNY CYX462Mitsubishi DY9680Ford ABC017Daihatsu V24034Ford TULAJDONOSRENDSZÁM Quittner PálCYX462 Kiss János 1DY9680 Kiss János 2ABC017 Lakinger BélaV24034 GÉPJÁRMŰG&T

105 JOIN példa

106 Külső (outer) JOIN  A külső join eredménye nem csak azokat a sorokat tartalmazza, amelyekben mindkét join táblázat soraira érvényes a join feltétel, hanem azokat is, amelyek a join bal oldalán levő táblázatban/nézetben szerepelnek, de a jobboldaliban nincs olyan sor, amelyik a join feltételnek megfelel. Az eredményben ennek oszlopai a NULL Értéket veszik fel. Ez a LEFT OUTER JOIN vagy röviden LEFT JOIN, egyesítés balról. Igy az előző példából szerepelnének azok a tulajdonosok is, akiknek jelenleg nincsen gépkocsijuk.

107 Külső (outer) JOIN a join jobb oldalán levő táblázatban/nézetben szerepelnek, de a bal oldaliban nincs olyan sor, amelyik a join feltételnek megfelel. Az eredményben ennek oszlopai a NULL Értéket veszik fel. Ez a RIGHT OUTER JOIN vagy röviden RIGHT JOIN, egyesítés jobbról a join bármelyik táblázatban/nézetben szerepelnek. Ez a FULL OUTER JOIN vagy röviden FULL JOIN, teljes egyesítés. Az eredmény a két join komponens left outer join-jának és right outer join-jának unió-ja lesz. Tartalmazza mindazon sorokat, melyek vagy a balról vagy a jobbról való egyesítésben szerepelnek. Azok a sorok, amelyek mindkettőben benne vannak, csak egyszer jelennek meg a végeredményben.

108 Normalizáció  A tervezés előző lépéseiként kapott entitásokat jól kezelhető, szabványos alakra hozza.  Algoritmizálható.  Eredményeképpen Az adatok tárlóigénye kisebb lesz; Az elemi adatokat gyorsabban és kevesebb hibalehetőséggel változtathatjuk meg; Az adatbázis logikailag áttekinthetőbb lesz.

109 Funkcionális függés  Bármely relációban egyes attribútumok értékei függnek más attribútumok értékeitől.  Ha az 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.  Természetesen ez az egyértelmű kapcsolat nem csak R éppen aktuális tartalmára érvényes, hanem időtől független, az egész adatbázis létezésének időtartamára fennálló megszorítás.  Mind az X, mind az Y attribútum lehet összetett, azaz állhat több oszlopból is.  A funkcionális függőség szokásos jelölése R.X  R.Y  Lehet ezt még funkcionális diagrammban, más névvel függőségi ábrában is ábrázolni.

110 Funkcionális függés ábrázolása.  A független attribútumból nyíl mutat a függő attribútumra.  Az ábrán Y és Z is függ funkcionálisan X- től, Z pedig Y-tól is.

111 Teljes funkcionális függés  Általánosan megfogalmazva, az R relációban az Y attribútum funkcionálisan akkor és csak akkor függ teljesen az X (összetett) attribútumtól, ha funkcionálisan függ X-től, de nem függ X-nek egyetlen egy valódi összetevőjétől sem.  Ha X nem összetett, akkor a funkcionális és a teljes funkcionális függőség ugyanazt jelenti.

112 Példa teljes függésre  Példa funkcionális függőségre, de nem teljes függőségre egy több tételes szállítólevél, amely többek között tartalmazza a szállítólevél számát, az áru kódját (a kettő együttesen alkotja az elsődleges kulcsot), az áru nevét, mennyiségét, árát, és a szállítási dátumot.  Itt a mennyiség funkcionálisan teljesen függ az elsődleges kulcstól, míg a dátum, az áru neve és ára nem. A dátumot a szállítólevél száma, a másik kettőt az áru kódja is egyértelműen meghatározza már.

113 Normalizáció (1)  A különböző relációk közötti függőségeket az adatbázis-kezelő rendszer az idegen kulcsok definiálásával automatikusan szavatolni tudja. Ugyanazon reláció oszlopai közti függőségek betartására azonban ilyen automatizmus nem létezik. Ezt vagy programmal kellene mindig ellenőrizni, vagy ellentmondás keletkezhet egy reláción belül.  A normalizációval, mint látni fogjuk, ezeket a függőségeket küszöböljük ki. Így a helyesen normalizált adatbázisba nem kerülhetnek ellentmondásban lévő adatok.

114 Normalizációs példa  Dolgozói nyilvántartást kell készítenünk a vállalatnál.  Minden dolgozónál szükségünk van a következő adatokra (zárójelben az oszlop neve): személyi azonosító szám (SZEMSZ) vezetéknév (VEZ-NÉV) keresztnév (KER-NÉV) osztály kódja, ahol dolgozik (OSZT) osztály megnevezése (OSZT-NÉV) téma kódja, amelyen dolgozik (TKÓD) téma megnevezése (TÉMA) munkaidejének hány százalékában dolgozik a témán (MEGOSZL) születésének éve (SZÜL-ÉV) osztálya főnökének személyi azonosító száma (FŐNÖK)

115 Normalizációs példa  A vállalati feltételek további elemzése alapján megállapítjuk, hogy a személyi azonosítószám egyedi, az osztályok kódja és megnevezése egyedi, a kettő között egyértelmű kapcsolat áll fenn, ugyanez érvényes a témára és témakódra is, egy dolgozó csak egy osztályhoz tartozhat, de több témán is dolgozhat, a témák és osztályok között nem kell kapcsolatot teremtenünk, nem kell automatikusan ellenőriznünk, hogy a témák összességére fordított idő a dolgozó teljes munkaideje-e (100%).

116 Az adatokat osztályonként gyűjtik be. Így az induló táblázatunk osztályonként egy-egy rekordot, „sort” tartalmaz, melynek első mezője az osztály kódja, második az osztály neve, utána annyiszor jönnek az egyes dolgozók fent sorolt adatai, ahány dolgozó van az osztályon. Végül az utolsó mező az osztály vezetőjének azonosító száma. Normalizációs példa

117 Bejövő adatok szerkezete MEZŐK: OSZT OSZT-NÉV SZEMSZ VEZ-NÉV KER-NÉV TKÓD TÉMA MEGOSZL SZÜL-ÉV FŐNÖK ISMÉTLŐDÉSEK: SZEMSZ VEZ-NÉV KER-NÉV TKÓD TÉMA MEGOSZL SZÜL-ÉV Ismétlődik annyiszor, ahány dolgozó van az osztályon TKÓD TÉMA MEGOSZL minden dolgozónál ismétlődik, annyiszor, ahány témán doldozik. NEM RELÁCIÓ!

118 Bejövő adatok P01 Pénzügy Andrásfai Béla B1 Bér 40 O2 Oktatás Bártfai Tóth Csilla E1 Ellenőrzés Tarnay Gyula T2 Tervezés T01 Titkárság Mohácsi Győző T2 Tervezés Tojásos Kristóf U2 Utazások

119 Ismétlődés megszüntetése Nem reláció, ismétlődő mezőket tartalmaz. Ezek kiküszöbölése: Eredeti:abc1,c2,c3,... d Átalakított: abc1d abc2d abc3d...

120 Első normál forma  Első normál formában (INF) van az a reláció, amelyikben minden oszlop egy, és csak egy attribútumot jelent, minden sor különbözik, az attribútumok sorrendje minden sorban ugyanaz, nincsenek ismétlődő mezők, minden sorhoz tartozik (legalább) egy egyedi kulcs, melytől az összes többi attribútum funkcionálisan függ.

121 Minden relációs adatbázis-kezelő rendszer megköveteli, hogy az adatok legalább első normál formában (1NF) legyenek. Bár ezen a normalizáltsági szinten még sok probléma fölmerülhet, ennél magasabb fok már nem szükséges, de mint a későbbiekben látni fogjuk, általában javasolt. Első normál forma

122 Alkalmazottak 1 NF PK

123 Anomáliák Látható a sok redundancia (pl. osztály és témanév). Rejtett hibalehetőségek (változtatási anomáliák):  Törlési anomália: Andrásfai Béla vagy Vigécz Jenő kilép, megszűnik az O2 téma, illetve E01 Eladási osztály.  Módosítási anomália: Tóth Csilla férjhez megy, vagy a P01 osztályra új főnök kerül. Sok helyen kell módosítani, nem biztos, hogy ez mindenhol megtörténik.  Beírási anomália: Új dolgozót csak akkor vihetünk be, ha van már témája, új osztályt, témát, ha van dolgozója. (Elsődleges kulcs része nem lehet NULL-érték.)

124 Függőségi diagram

125 Második normál forma  Második normál formában (2NF) akkor, és csak akkor van egy reláció, ha 1NF-ben van, és az összes nem kulcs attribútum funkcionálisan teljesen függ az elsődleges kulcstól.  Elemi elsődleges kulcsú 1NF relációk automatikusan 2NF-ben is vannak. Összetett kulcsú relációkat azonban a változtatási anomáliák megszüntetése érdekében 2NF-re kell hoznunk. (Ez nem biztos, hogy megszünteti az összes anomáliát, de jelentősen csökkentheti számukat.) Ezt nevezzük a relációk szétbontásának vagy dekompozíciónak.  A szétbontás úgy történik, hogy az 1NF relációból projekcióval olyan 2 NF relációkat állítunk elő, melyeknek elsődleges kulcsai az eredeti reláció elsődleges kulcsa, illetve annak részei, oszlopai pedig azok és csak azok, amelyek az új elsődleges kulcstól funkcionálisan teljesen függenek.

126 Dekompozició (1NF  2 NF)  R(A,B,C,D) Szétbontás előtt (1NF) ELSŐDLEGES KULCS (A,B) R.A  R.D  Szétbontás után (2NF) R1(A,D) ELSŐDLEGES KULCS (A) és R2(A,B,C) ELSŐDLEGES KULCS (A,B) IDEGEN KULCS (A), HIVATKOZIK R1-RE

127 Szétbontás 2 NF relációkra

128

129  Ezzel a szétbontással a változtatási anomáliák egy részét kiküszöböltük.  Például: Andrásfai Béla kilépésével nem szűnik meg az „Oktatás” téma és az O2  Oktatás kapcsolat sem (törlési anomália) Új dolgozót is felvehetünk anélkül, hogy témát adnánk neki (beírási anomália)  A többi probléma azonban még továbbra is fennmarad. Azokat a harmadik normál formába való szétbontás küszöböli csak ki. Szétbontás 2 NF relációkra

130  Ez a szétbontás teljes.  Az összes olyan információt tartalmazza, ami az eredeti relációban benne volt.  De ezen kívül több is van benne, t.i. az, hogy az O2 témakód megnevezése Oktatás, az E01 osztályé pedig „Eladás”, míg az eredeti reláció ezeket csak addig tartalmazza, amíg van legalább egy olyan dolgozó az adatbázisban, aki ezen a témán, illetve ezen az osztályon dolgozik. Szétbontás 2 NF relációkra

131  A 2NF-be hozott relációkban az ALKALMAZOTTAK-2NF-ben nyilvánvaló redundáns osztálynevek mellett még mindig megmaradtak az alábbi változtatási anomáliák: Vigécz Jenő kilépésével (törlésével) megszűnnek az eladási osztályra vonatkozó információink. Ha a P01 (vagy a T01) osztálynak új főnöke lesz (módosítás), akkor azt továbbra is több helyen kell végigvezetni. Továbbra sem tudunk új osztályt addig fölvenni (beírás), amíg nincsen legalább egy új dolgozója. Szétbontás 2 NF relációkra

132

133 Harmadik normál forma  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üggenek funkcionálisan.  Másképpen fogalmazva a 3NF azt jelenti, hogy funkcionális függés csak az elsődleges és az alternatív kulcsokból indulhat ki.  Az ALKALMAZOTTAK-2NF reláció nincs 3NF- ben, mert pl. az osztály (OSZT) nem elsődleges vagy alternatív kulcs, és más oszlopok (OSZT-NÉV), FŐNÖK) funkcionálisan függnek tőle.

134 Szétbontás 2 NF  3 NF A szétbontás úgy történik, hogy a 2 NF relációnak vesszük azt a projekcióját, amelyik csak azokat az attribútumokat tartalmazza, amelyek kizárólag az elsődleges kulcstól függenek. Ennek elsődleges kulcsa ugyanaz marad. A másik új reláció (vagy relációk, ha több összefüggés van) elsődleges kulcsa a szétbontott reláció független attribútuma, oszlopai pedig a tőle függő attribútumok.

135  Általánosan megfogalmazva, ha az A,B,C,D oszlopokkal (bármelyik lehet összetett is) rendelkező 2 NF relációban R(A,B,C,D)  ELSŐDLEGES KULCS (A)  R.B  R.C  akkor a 3NF-re való szétbontás a következő relációk létrehozását jelenti: R1(B,C)  ELSŐDLEGES KULCS (B) és R2(A,B,D)  ELSŐDLEGES KULCS (A)  IDEGEN KULCS (B), HIVATKOZIK R1-RE  Az R relációt bármikor egyértelműen vissza tudjuk állítani R1 és R2 egyesítéséből (B-re). Lényeges azonban, hogy a szétbontás a fent megadott elv szerint történjen. Szétbontás 2 NF  3 NF

136  Nem mindig célszerű a 3NF alak (pl. cím és irányítószám).  A legtöbb adatbázis-kezelő rendszernek elég az 1 NF, sőt, még elsődleges kulcs sem kötelező!!! 3 NF relációk

137

138

139 Nézetek definiálása  Igen nehézkesen dolgoznánk, ha csak a normalizált relációkat használhatnánk. Pl: Rendszeres kérdés: „Egy adott dolgozó milyen nevű osztályon, témán és az utóbbiakon milyen megoszlásban dolgozik?” Négy táblázatot kellene egyesíteni. Ehelyett definiálhatunk egy VÁLASZ nézetet, mely ezeket az adatokat előállítja relációs műveletekkel. A „kérem a VÁLASZ adott dolgozójú sorait” megadja a feleletet.

140 VÁLASZ = PROJECT DOLGOZÓ (VEZ-NÉV,KER-NÉV) JOIN [SZEMSZÁM] PROJECT MIT-CSINÁL (MEGOSZL) JOIN [TKÓD] PROJECT TÉMÁK (TMEGNEV) JOIN [OSZT] PROJECT OSZTÁLYOK (OSZTNÉV) Nézetek definiálása

141 A tervezés főbb lépései  A szükséges adatok kiválasztása.  Az összetartozó adatok, az entitások meghatározása, adatok csoportosítása.  Az entitások közti kapcsolatok meghatározása.  A több-több kapcsolatok felbontása új relációk segítségével.  A relációk létrehozása, adatok (legalább) első normalizált formákba való csoportosítása.  Idegen kulcsok meghatározása a relációk közti kapcsolatok biztosítására.

142 A tervezés főbb lépései  A szükséges magasabb fokú normalizáció elvégzése.  Táblázatok létrehozása a normalizált relációk alapján.  A várható feladatok adatait együttesen, egyben tartalmazó relációk meghatározása.  Az így kapott relációk állandó nézetként való létrehozása.  Adatok betöltése, műveletek az adatokkal.  Szükség esetén az adatbázis szerkezetének módosítása, új táblázatok, nézetek létrehozása egy 1-10-ben leírtak szerint.

143 Tervezési gyakorlat (1)  Vannak: áruk, vevők, szállítások.  Ehhez tartozik: árukód, árumegnevezés, ár- és leszállított mennyiség az egyes vevőknek, vevőkód, vevő név, telephely és kedvezmény, mely a telephelytől függ. Építsünk fel egy nem normalizált, és különböző szinten normalizált modelleket ezek leírására.  Milyen – a valóságban nem megvalósuló – egyszerűsítéseket tettünk?  Milyen adatokkal kell kibővítenünk az adatbázist, hogy a realizálásoknak eleget tevő modellt kapjunk?

144 Megrendelés – E–R diagram

145

146 Tervezési gyakorlat (1)  Árak változnak Új táblázat: ÁRVÁLTOZÁS  Egy vevő több árut rendel meg Új táblázat: Megrendelés Ehhez kapcsolódik : TÉTEL Feltétel: Egy megrendelésben ugyanaz az áru csak egyszer szerepelhet.  Teljesítést is bevesszük Új mező tételben Feltétel: Egy tételt egyben szállítunk  Probléma marad: Egy vevőnek több telephelye van

147 Árváltozás

148 Megrendelés

149 Megrendelés – E–R diagram

150 Tervezési gyakorlat (2)  Készítse el egy vállalat dolgozói nyilvántartásának Entity-relationship diagrammját, definiálja az egyes relációk oszlopait és kulcsait!  Minden dolgozónál szükségünk van a következő adatokra (zárójelben az oszlop neve): személyi azonosító szám (SZEMSZ) név (NÉV) osztály kódja, ahol dolgozik (O-KÓD) osztály megnevezése (O-NÉV) téma kódja, amelyen dolgozik (T-KÓD) téma megnevezése (T-NÉV) munkaidejének hány százalékában dolgozik a témán (MEGOSZL) beosztása (BEOSZT) a beosztásához tartozó maximális és minimális fizetés (MAX-FIZ, MIN-FIZ) osztálya főnökének személyi azonosító száma (FŐNÖK)

151  A vállalati feltételek további elemzése alapján megállapítjuk, hogy a személyi azonosítószám egyedi, az osztályok kódja és megnevezése egyedi, a kettő között egyértelmű kapcsolat áll fenn, ugyanez érvényes a témára és témakódra is, a beosztás egyértelműen meghatározza a hozzátartozó maximális és minimális fizetést egy dolgozó több osztályhoz is tartozhat és több témán is dolgozhat, egy dolgozó egy adott osztályon csak egy beosztásban dolgozhat, a különböző osztályokon azonban más lehet a beosztása a témák, beosztások és osztályok között nem kell kapcsolatot teremtenünk, nem kell automatikusan ellenőriznünk, hogy a témák összességére fordított idő a dolgozó teljes munkaideje-e (100%). Tervezési gyakorlat (2)

152 E–R diagram, alkalmazottak

153

154  OSZTÁLYOK, MIT_CSINÁL, TÉMÁK: ugyanaz  ALKALMAZOTTAK: oszt kikerül belőle  HOL_DOLGOZIK szemszámPK, FK osztPK, FK beosztás max_fiz min_fiz  Nem 3NF, beosztástól függ max_fiz és min_fiz Tervezési gyakorlat (2)

155

156 Hatékony munka  Egy adatbázisban sokan dolgozhatnak egyszerre, egymással párhuzamosan. A hatékony munkához a felhasználóknak az alkalmazásaikat úgy kell elkészíteniük, hogy azok A lehető leggyorsabb módon érjék el és dolgozzák fel az adatokat, optimalizálják a saját alkalmazásukat. Ezt hatékony programok tervezésével és az adatszerkezet és az adatelérési módok megfelelő megválasztásával érhetjük el. Minél kevésbé zavarják, hátráltassák mások munkáját az adatbázisban (és természetesen, viszonzásul, a többiek se akadályozzák az ő munkájukat). Ez időnként csak saját munkájuk hatékonyságának rovására valósítható meg. Mivel nem mindenkitől várható el ilyen erős közösségi elkötelezettség, a jó adatbázis-kezelő rendszerek automatikusan rákényszerítik a felhasználókat a közös munka alapszabályainak betartására.

157 Hibalehetőségek párhuzamos munkánál A párhuzamos feldolgozásból eleve adódnak a következő hibalehetőségek:  elveszett módosítás  nem véglegesített adatok feldolgozása  munka inkonzisztens adatokkal  patthelyzet

158 Elveszett módosítás

159 Nem véglegesített adatok feldolgozása

160 Munka inkonzisztens adatokkal

161 Zárak Az adatbázisban használt zárakra jellemző  a zár mérete  a zár erőssége  a zár időtartama

162 Zárak mérete  Database (Adatbázis)  Tablespace  Table (Táblázat)  Page (Lap)  Row (Sor)

163 Zárak erőssége  Osztott (Share)  Kizárólagos (Exclusive)  (Update)

164 Zárak kompatibilitása SU X Sxx- Ux-- X---

165 Várakozás Amikor egy tranzakció egy olyan erősségű új zárat kíván elhelyezni, amelyik nem kompatibilis a rekordon már rajta lévő(k)vel, akkor ez a tranzakció  vár addig, amíg az inkompatibilis zár meg nem szűnik.  vár a rendszer paraméterei által meghatározott ideig (általában 30 – 120 másodpercig). Ha ez alatt az idő alatt az inkompatibilitást okozó zár megszűnik, akkor ráteszi a saját zárát. Ha az inkompatibilitás fennmarad, akkor hibajelzést ad (és ennek eredményeként általában ROLLBACK- kel befejeződik).  Azonnal hibajelzést ad (és ennek eredményeként általában ROLLBACK-kel befejeződik

166 Zár mechanizmus

167 Patthelyzet

168 Adattárház  Hagyományos adatbázis: Lekérdezések Tranzakciók Dinamikus Elsősorban az aktuális állapotot tükrözi  Adattárház (Data Warehouse): Lekérdezések igen nagy statikus adatmennyiségből Időbeli változásokat mutatja Adatok elemzésére szolgál  Adatbányászat (Data Mining): Az adattárház adatai közt fennálló (rejtett) összefüggésekre derít fényt

169 Adattárház jellemzői  Témaorientált Eladások adattárháza: Kik voltak az utóbbi időszakban a legjobb vevők  Integrált Különböző forrásokból gyűjti össze az adott témához tartozó adatokat és azokat egységes formában tárolja  Statikus Az egyszer bevitt adatok nem változnak már. Annak elemzésére szolgál, hogy mi történt Az adatok időbeli változását mutatja hosszú időre visszamenőleg

170 Komponensek  Relációs adatbázis  Adatkiválasztó  Adattranszformáló (egységesítő)  Adatbevivő  On-line analitikus elemző (On-Line Analytical Prosessing)  Felhasználói analizáló eszközök  Speciális alkalmazások

171 Összehasonlítás Tranzakció feldolgozásra orientált adatbázis Adattárház Komplex adatszerkezet, 3NF relációk AdatszerkezetMultidimenzionál is adatszerkezet Nem túl sokIndexekIgen sok Minimális (3NF dominál) RedundanciaJelentős (1NF, 2NF, 3NF) RitkánSzármaztatott adatok, aggregátumok tárolása Rendszeresen

172 Követelmények Tranzakció feldolgozásra orientált adatbázis Adattárház Adott feladatokra optimalizált lekérdezések FeladatokAd hoc jellegű lekérdezések Bármikor lehetségesAdatok változtatása Új adatok meghatá- rozott intervallumokban Normalizált (3NF)AdatmodellRészben normalizált (csillag), lekérdezésre optimalizált Néhány rekord kiválasztása, beolvasása Tipikus műveletek Sok millió rekord beolvasása Aktuális, vagy csak rövid időre visszamenőleges Adatok időbeli változásának tárolása Hosszú időre visszamenőleges

173 Adattárház felépítése

174 Csillag elrendezés

175 Dátum dimenzió

176 Eladás tény-táblázat

177 Eladási hely dimenzió

178 Adatbányászat  Célja, miként lehet nagy adatbázisokban rejtett tudást, új összefüggéseket, eddig nem ismert szabályokat, nem várt mintákat felfedezni  Ha pontosan tudjuk, hogy mit keresünk, akkor használhatjuk az SQL nyelvet is

179 Adatbányászati kérdések  Melyek a legfontosabb ügyfél típusok?  Melyek a legfontosabb ügyfélvásárlási szokások?  Miért maradnak vagy lépnek ki a dolgozók a vállalattól?  Mikor és milyen áron érdemes egy új terméket a piacra dobni?


Letölteni ppt "ADATBÁZISOK ELŐADÁS Dr Quittner Pál Baksa-Haskó Gabriella."

Hasonló előadás


Google Hirdetések