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

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

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.

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

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)

Adatbázis Két főtípusuk: A kettő között a határvonal nem éles. 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.

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

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

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

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

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.

Az adatbázis-architektúra három szintje 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

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.

Működési elv

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

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

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.

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.

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 :

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.

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.

Adatbázis felügyelő fő feladatai 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

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.

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.

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

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.

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

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

Adatszervezési szempontok 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

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

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

Lemez hozzáférési idő min max Fejmozgatás 0 2-50 ms Fejkiválasztás 0 mikrosec Forgási idő 0 10-25ms Adatátvitel 1 100 Mbyte/sec Hozzáférési idő Átlagosan: 5 -30 ms Optimális: 0

Mágneslemezek jellemzői Felületek száma 20 Cilinderek száma 200 – 400 Sávok kapacitása 40 -100 kB Lapméret 1 -32 kB Teljes tároló kapacitás 100 MB – 500 GB

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

Címzés

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

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ó

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.

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.

Lista

Lista szerkezetek

Változtatás listában

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)

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

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ő.

Indexek Indextáblázat tartalmazza Index lehet Megvalósítás 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)

Index tábla

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

B+ fa

B+ fa módosítás

Bitmap index Duplikált indexekre célszerű definiálni, ha az index nem nagyon szelektív. ROW-ID-1 ROW-ID-2 ROW-ID-3 . . . Ind-ért-1 0 1 1 Ind-ért-2 1 0 0 Ind-ért-3 0 0 0 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).

Bittérkép példa

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)

ÉS/VAGY feltétel - 1

É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

Keresési példa 10 rekord/lap Feladat: 100 000 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!

Keresési példa - Helyigény Adatok 10 000 lap Egy tulajdonságra index 1 000 lap Mindhárom tulajdonságra index 3 000 lap Hármas index 1 000 lap Minimális helyigény 10 000 lap Maximális helyigény 14 000 lap

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

Keresési példa - Lehetőségek 3. Végigmenni a három indexen, kiválasztani a közös rekordokat 3*10 000 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 (Ha sűrűsödik, akkor soros) Időnyereség 1 -2 nagyságrend!!!

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.

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.

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).

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.

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.

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.

1:1 Kapcsolat

1:N Kapcsolat

N:M Kapcsolat

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.

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.

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.

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.

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),

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

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)

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.

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

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.

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)

Idegen kulcs módosítása 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.

Idegen kulcs kapcsolat

Idegen kulcs kapcsolat

Idegen kulcs kapcsolat

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ő

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.

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

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.)

E-R diagram

Gépjármű reláció … RENDSZÁM GYÁRTMÁNY TÍPUS SZÍN ŰRTAR-TALOM EGYÉB CYX462 Mitsubishi Colt GL Fehér 1298 … DY9680 Ford Sierra L Ezüst 1598 ABC017 Daihatsu Charade Kék 980 V24034 Escort Piros 1199 CZ9404 Volkswagen Fastback TL Zöld 1596 HHU561 Carisma 1790

Tulajdonos reláció … NÉV LAKCÍM JOGOSÍTVÁNY FOGLAL-KOZÁS EGYÉB Kiss János 1 Budapest I. Fő u. 1. CX162233 autószerelő … Quittner Pál Budapest V. Markó u. 1/b. CC23456 adatbázis szakértő Lakinger Béla Abádszalók, Hős u. 69. ABC4321 tengerész Kiss János 2 Pécs, Anna u. 16 tanár Computer Kft Győr, Rába köz 1/b

G&T reláció RENDSZÁM TULAJDONOS TULAJDONJOG KEZDETE TULAJDONJOG VÉGE CYX462 Quittner 2002-3-1 DY9680 PálKiss János 1 1999.12.13 2004-2-3 Lakinger Béla ABC017 Computer Kft 2000-11-12 2006-2-13 Y24034 2006-2-1 Kovács Imre HHU561 Quittner Pál 2006-5-4

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.

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.

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.

Egy relációs műveletek

Keresztszorzat

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

Union példa

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

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

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).

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.

JOIN példa G&T GÉPJÁRMŰ RENDSZÁM GYÁRTMÁNY CYX462 Mitsubishi DY9680 Ford ABC017 Daihatsu V24034 TULAJDONOS RENDSZÁM Quittner Pál CYX462 Kiss János 1 DY9680 Kiss János 2 ABC017 Lakinger Béla V24034 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)

JOIN példa

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.

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.

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.

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.

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.

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.

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.

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.

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)

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%).

Normalizációs példa 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.

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Ó!

Bejövő adatok P01 Pénzügy 11111 Andrásfai Béla B1 Bér 40 O2 Oktatás 60 1934 11211 Bártfai . . . . . . Tóth Csilla E1 Ellenőrzés 70 1969 91526 Tarnay Gyula T2 Tervezés 100 1932 91562 T01 Titkárság 01526 Mohácsi Győző T2 Tervezés 100 1971 69690 . . . . . . 01492 Tojásos Kristóf U2 Utazások 80 1966 69690

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

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.

Első normál forma 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.

Alkalmazottak 1 NF PK PK

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.)

Függőségi diagram

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.

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) IDEGEN KULCS (A), HIVATKOZIK R1-RE

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

Szétbontás 2 NF relációkra 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 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 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.

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.

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.

Szétbontás 2 NF  3 NF Á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) 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.

3 NF relációk 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

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.

Nézetek definiálása 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)

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.

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.

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?

Megrendelés – E–R diagram

Megrendelés – E–R diagram

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

Árváltozás

Megrendelés

Megrendelés – E–R diagram

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)

Tervezési gyakorlat (2) 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%).

E–R diagram, alkalmazottak

E–R diagram, alkalmazottak

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

Tervezési gyakorlat (2)

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.

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

Elveszett módosítás

Nem véglegesített adatok feldolgozása

Munka inkonzisztens adatokkal

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

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

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

Zárak kompatibilitása S U X S x x - U x - - X - - -

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

Zár mechanizmus

Patthelyzet

Adattárház Hagyományos adatbázis: Adattárház (Data Warehouse): 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

Adattárház jellemzői Témaorientált Integrált Statikus 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

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

Tranzakció feldolgozásra orientált adatbázis Összehasonlítás Tranzakció feldolgozásra orientált adatbázis Adattárház Komplex adatszerkezet, 3NF relációk Adatszerkezet Multidimenzionális adatszerkezet Nem túl sok Indexek Igen sok Minimális (3NF dominál) Redundancia Jelentős (1NF, 2NF, 3NF) Ritkán Származtatott adatok, aggregátumok tárolása Rendszeresen

Tranzakció feldolgozásra orientált adatbázis Követelmények Tranzakció feldolgozásra orientált adatbázis Adattárház Adott feladatokra optimalizált lekérdezések Feladatok Ad hoc jellegű lekérdezések Bármikor lehetséges Adatok változtatása Új adatok meghatá-rozott intervallumokban Normalizált (3NF) Adatmodell Ré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

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

Csillag elrendezés

Dátum dimenzió

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

Eladási hely dimenzió

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

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?