Adatbázis Rendszerek Budapesti Műszaki és Gazdaságtudományi Egyetem Fotogrammetria és Térinformatika Tanszék 2011 Dr. Alhusain Othman oalhusain@gmail.com 1 4.1. Definíciók: 4.1.1. Adatbázis 4.1.1. A modell általános koncepciója 4.1.3. Adatmodell 4.2. Adat modellek 4.2.1. Hierarchikus modell 4.2.2. Hálós modell 4.2.3. Relációs modell 4.2.4. Objektum modell 4.3. Adat modellek lebontása 4.4. Relációs adat struktúra 4.5. Relációs adatok integritása 4.6. Az adatok strukturális formai 4.7. Táblák tervezése (szempontok) 4.8. Táblák az adatbázisban 4.9. Egy táblás adatbázisok 4.10. Több táblás adatbázisok 4.1. Definíciók: 4.1.1. Adatbázis: Egy információ gyűjteménye tárolva egy számítógépen. A set of information held in a computer. Oxford English Dictionary Egy vagy több, nagy strukturált tartós adat gyűjtemények, gyakran párosulnak szoftverrel az adatok frissítése és keresése céljából. One or more large structured sets of persistent data, usually associated with software to update and query the data. Free On-Line Dictionary of Computing Az adatbázis lehet definiálni, mint adatok és a köztük lévő összefüggések (kapcsolatok) egy helyen tárolt rendszere. Vagy röviden fogalmazva, egy adatbázis a fontos adatok szervezett együttese. 4.1. Definíciók: 4.1.1. Adatbázis: Felhasználók adatbázis Alkalmazói program rendszer Adatbázis-kezelő rendszer (DBMS) A lekérdezéseket kezelő szoftver komponens A tárolt adatokat kezelő szoftver komponens Operációs rendszer metaadatok tárolt adatok 4.1. Definíciók: 4.1.2. A modell általános koncepciója: A különböző modellek a környező világ megértésében, leképzésében és átalakításában alapvető szerepet játszanak. A A modellek lehetővé teszik hogy, a lényeg kiemelését és szemléltetését. A modell, egyrészt jelenthet olyan rendszert, amely a valóság egy vizsgált szeletével struktúrában vagy viselkedésben megegyezik (vagy hasonló jelleget mutat). Ebben az esetben a modellalkotás célja, hogy vizsgálatán keresztül a valóság állapotára, viselkedésre vonatkozó következtetéseket vonhatunk le. Másrészt a modell kifejezéssel jelöljük azon eszközrendszert is, amellyel az előző értelemben vett modell leírható, megadható. Tehát a modell egyrészt egy jelölésrendszert, másrészt egy elkészült leírást is jelölhet. 4.1. Definíciók: 4.1.3. Adatmodell: Olyan koncepciók gyűjteménye amelyek egyértelműen leírják egy adatbázis szerkezetét. 1
4.2.1. Hierarchikus adatmodell: A hierarchikus adatmodell az adatokat egy hierarchikus szerkezetben tárolja. A legjobban reprezentálható a fa (gráf) szerkezet. Mindegyik csomópont egy rekordtípusnak felel meg. Nincs olyan erős elméleti megalapozottsága, viszont jól felel meg a gyakorlati alkalmazásoknak. A modellben rekordorientált adat-megközelítést alkalmaznak. Ha z adatbázist irányított gráfként, fastruktúrában ábrázoljuk; a gráf csúcsai az objektumokat, az ágai pedig az objektumok közötti kapcsolatokat jelölik. 4.2.1. Hierarchikus adatmodell: A modell grafikon formában: A következő példában lehet mutatni a hierarchikus modell praktikus megvalósítását. A példa sorozza a történelmi biblikus Terrah és több generációs származottait fa szerkezeti formában. A Származottság reláció (logikai hierarchikus modell) Ábrahám Terach Nachor Hárán Izsák Izmael Kemuel Betuel Lót A család szerkezet hierarchikus struktúrája van családfa. A szervezetek (vállalatok) is gyakran hierarchikus struktúrájúk (Igazgató, igazgatóhelyettesek, osztályvezetők, stb.). Zsidók Arabok Áramiták Lótok 7 8 4.2.1. Hierarchikus adatmodell: A modell előnyei: A modell előnye, hogy a hierarchikus szerkezet egyszerűen leírható és tárolása a mágnesszalagos tárolási formához is jól illeszkedik. A modell hátrányai: Abban a modellben bonyolultabb kapcsolatok ábrázolása csak kerülőutakon lehetséges, így mondható hogy annak az adatmodell képzésnek (ábrázolásnak) az a hátránya, hogy nem minden fajta kapcsolatot tud ábrázolni (például a sok-sok kapcsolatot nem tudja). 4.2.1. Hierarchikus adatmodell: A példa elemzése: Az adatokat hierarchikus faszerkezetben ábrázolja, amelyben a különböző szinten levő csomópontok (rekordok) között hierarchikus, szülő-gyermek kapcsolat van. Az adatfeldolgozási műveletek fa-struktúrák (gráfok) bejárását jelentik. Például az alábbi fa nyilak szerinti bejárásával megtudhatjuk, hogy: Ábrahám Terach gyereke, de ugyanakkor szülője Izsáknak és Izmaelnek. Az adatstruktúra elemei lényegében rekordok, amelyek nemcsak logikai, hanem a mutatókon keresztül fizikai kapcsolatban is vannak egymással. 9 10 4.2.2. Hálós adatmodell: A hálós adatmodell a hierarchikus modell továbbfejlesztése, mely jobban illeszkedik a bonyolultabb kapcsolatok ábrázolásához. Az adatokat mutatókon keresztül érhetjük el és ugyanígy reprezentálhatjuk a köztük levő kapcsolatokat is. Ebben a modellben az egyedek között tetszőleges kapcsolatrendszer, egy kapcsolatháló alakítható ki. Az adatszerkezet leírása, mivel a háló tetszőlegesen nagy lehet, nem egy adategységgel, hanem több kisebb, hierarchikus felépítésű adategységgel történik. Ez a modell is rekordorientált adat-megközelítési koncepciót alkalmaz. A hálós modellen alapuló rendszerek igen elterjedtek nagygépes környezetben (hiszen ez a modell nagy adatmennyiségek viszonylag gyors feldolgozását teszi lehetővé). 4.2.2. Hálós adatmodell: A modell grafikon formában: A következő példában lehet mutatni a hálós adatmodell praktikus megvalósítását. A példa sorozza ugyanaz a történelmi biblikus Terrah és több generációs származottait halmaz (set) gyűrű formában (kapcsolt rekordok hálózataként ábrázolja). Izsák Ábrahám Ábrahám Gyermekei SET Izmael Terach Terach Gyermekei SET Nachor Nachor Gyermekei SET Kemuel Betuel Hárán Hárán Gyermekei SET Lót 11 12 2
4.2.2. Hálós adatmodell: A modell előnyei: Képes kezelni a bonyolult adatszerkezeteket. A modell hátrányai: A viszonylag merevebb szerkezete és a kezelőnyelv bonyolultsága, sokszor gátolja szélesebb körben történő elterjedését. 4.2.2. Hálós adatmodell: A példa elemzése: Az ún. tag rekordok (members) körülveszik a tulajdonos- rekordot ot (owner). a lekérdezési műveletek a rekordok hálózatán értelmezett navigálási műveletekből állnak. A fizikai mutatók segítségével, megfelelő stratégiával gyorsan eljuthatunk a keresett rekordhoz. 13 14 4.2.3. Relációs adatmodell: A relációs adatmodell a 70-es évektől kezdve terjedt el, és ma már szinte minden rendszer ezt támogatja. Jelölésrendszere táblázatokból áll, így alapvetően az egy modell amely teljes mértékben táblázatokra támaszkodik. A RELÁCIÓ: Nem más, mint egy kétdimenziós tábla, a tábla soraiban tárolt adatokkal együtt, a relációs adatbázis pedig ezen relációk összessége. A kapcsolatok leírására bonyolult matematikai apparátusokat és relációkat használ. Az SQL nyelv működésében feltételezi a relációs adatmodell. A táblázatok (relációk) közötti kapcsolat logikai összefüggései. 4.2.3. Relációs adatmodell: A modell logikai összefüggései: A táblázatok (relációk) közötti kapcsolat a következő logikai összefüggéseknek megfelel: Az oszlopok száma: fokszám Sorok száma: kardinalitás Elsődleges kulcs (a sorok egyértelmű azonosítása) Idegen kulcs (hivatkozni tudunk egy másik táblára ill. annak adataira) Összetett elsődleges kulcs (a komponensek száma minimális legyen) Alternatív kulcs A modell előnyei: A kezelőnyelve bár bonyolult de nagyon hatékony. A modell hátrányai: Az adatkezelés nagy mértékben lelassul bonyolult adatszerkezeteknél. 15 16 4.2.3. Relációs adatmodell: A relációk tulajdonságai: Minden relációnak egyedi neve van. Egy sor és oszlop kereszteződésében egyetlen érték szerepel. Minden sor egyedi, nincs két egyforma sor. Minden oszlopnak egyedi neve van a reláción belül, de más relációk tartalmazhatnak azonos nevű oszlopokat. Az oszlopok sorrendje lényegtelen. A A sorok sorrendje lényegtelen. A A relációk oszlopaiban azonos mennyiségre vonatkozó adatok jelennek meg. A A reláció soraiban tároljuk a logikailag összetartozó adatokat. 4.2.3. Relációs adatmodell: A relációk tulajdonságai: A A relációs adatmodellben a relációkból történő információ kinyerése biztos elméleti alapokon nyugszik. Gyakran egyes definiált adatlekérdező műveletcsoportot összefoglalóan relációs algebrának nevezik. A A relációs algebra az alapja a ma már szabványként elfogadott és leginkább elterjed adatlekérdező relációs parancsnyelvnek, az SQL-nek is. Az SQL nyelv egyik fő jellemzője, hogy hiányoznak belőle a procedurális (eljárásos) elemek. Ennek következtében nem lehet pusztán SQL utasításokra építve komplett alkalmazásokat készíteni, hiszen az SQL nem tartalmaz elágazási, ciklusvezérlési, vagy éppen terminál felület működését leíró nyelvi elemeket. 17 18 3
4.2.3. Relációs adatmodell: A modell grafikon formában: 1 2 3 4 Azonosító Név Hapci B. Kuka K. Vidor B. Hófehér T. bm va fkód Cím Erdő u. 3. Bánya u. 11. Kőomlás u. 1. Boszorka u. 2. Bányamérnök Vájár bm va va bm foglalkózás fkód 4.2.4. Objektum orientált adatmodell: A 90-es évek közepétől kezdet ismertéé a fogalom. Fejlődésben még nincs elfogadott szabványa. Az objektum orientált modell célja az objektum orientáltság szemléletmódjának alkalmazásával minél valósághű_bb adatmodell megalkotása. Az adatbázis lehet tervezni un. objektum-relációs formákban, ez egy eljárás amelyben az adatbázis kiegészül bizonyos elemekkel, amelyek lehetővé teszik különböző objektumok integrálását az adatbázisban. Az egyedek ugyanis sokkal szemléletesebben írhatók le az objektumokkal, mint a relációs modellben szereplő rekordokkal. A megvalósult rendszerekben az objektum orientáltság lehet részleges vagy teljes. Az ilyen rendszerek elterjedését gátolja az egységes elméleti alapok hiánya és az implementációs nehézségek fékezik. 19 20 4.3. Adat modellek lebontása: 4.3. Adat modellek lebontása: Bontási célok: Adatmodellek áttekinthetősége Sémák egyszerűizése Bontási stratégia: A kívánt modell meghatározása Lebontási eljárás meghatározása Bontási példa: 21 22 4.4. Relációs adat struktúra: 4.4. Relációs adat struktúra: Séma és attributum - Az adatok tárolandók relációkban (táblákban). - Minden relációnak van egy sémája (scheme, heading). - A séma definiálja a relációnak az attribútumait (oszlopok). - Az adatok sorok (rekordok...tuples) formában tárolódnak. Előbb Utóbb Attributumok Név Attributumok Kor Séma(Scheme) Rekordok (Tuples) 1 2 Csak az oszlopok száma Rekordok (Tuples) Név Kor Séma(Scheme) Rekordok (Tuples) 24 4
4.4. Relációs adat struktúra: Névtelen és neves rekordok Az első rekord <János, 23> 1 2 Csak az oszlopok száma Rekordok (Tuples) Az első rekord {(Név, János), (Kor,23)} Név Attributumok Kor Séma(Scheme) Rekordok (Tuples) 4.4. Relációs adat struktúra: Névtelen és neves rekordok Nincs alapvető különbség a névtelen és neves rekordok a relációra. Lehetet kifejezni az <a,b,c> rekordokat páros szettek formájában [(1,a), (2,b), (3,c)]. Egyetlen egy dolgot kell tudni azaz milyen sorrendben kifejeződik a számolást. Páros szettekkel kifejezve a rekordok bár milyen sorrendben már lehet kifejezni, pld. [(3,c), (2,b), (1,a)]. 25 26 4.4. Relációs adat struktúra: Így formálisan lehet összegezni: A séma egy fajta attribútum halmaz A rekord egy értéket rendel minden attribútumhoz a sémájában. A reláció egy rekordok halmaza amely egy azonos sémához tartozik. Név Kor { { (Név, János), (Kor, 23) }, { (Név, Mária), (Kor, 20) }, { (Név, Mark), (Kor, 18) }, { (Név, Anna), (Kor, 21) } } 4.4. Relációs adat struktúra: Összegezve Séma {Azon., Név, Fizetés, Osztály} Attribútumok: Azon., Név, Fizetés, és Osztály Fokozat: 4 Azon. Név Fizetés Osztály M139 Kovács János 18,000 Marketing M140 Muller Mária 22,000 Marketing A368 Kovács Anna 22,000 Accounts P222 Fehér Mark 24,000 Personnel A367 David Károly 20,000 Accounts Rekordok: { (Azon., A368), (Név, Kovács Anna), (Fizetés, 22,000), (Osztály, Accounts) } Kardinálitás: 5 27 28 4.5. Relációs adatok integritása: Az adat integritás kontrolálja az adat milyenségét egy relációban. Tartományok korlátozzák a lehetséges értékek amelyek a rekord tud adni minden attribútumnak. Jelölt és elsődleges kulcsok azonosítják a rekordok egy relációban. Idegen kulcsok összekötik a relációk egymáshoz. 4.5. Relációs adatok integritása: Attribútumok és tartományok (Domains) Példák: A kor attribútumot lehet korlátozni igaz számokra (integer) 0 és 150 között. Az osztály jöhet egy adott betű láncolat (sztring) listából. A megfelelő mezőkhöz lehet rendelni tetszőleges betű láncolatot (sztringet), noteszek formajaban. 29 30 5
4.5. Relációs adatok integritása: Jelölt kulcsok Egy attribútumok halmazara lehet hivatkozni mint jelölt kulcs ha és csak ha a következő állítások igazak: Minden rekordnak van egyedi értéke az attribútumok halmazara nézve (egyediség). Nem létezik álhalmaz a halmazból amely egyediséggel rendelkezik (minimálity). Azon. Családi Kereszt S139 Kovács jános S140 Muller Mária S141 Feher Mark S142 Kovács Anna Jelölt kulcs: {Azon.}; {Családi, Kereszt} Jónak mondható de problémás ha vannak azonos nevűek! {Azon., Családi}, {Azon., Kereszt} és {Azon., Családi, Kereszt} Megfelel az egyediség elvnek, de nem felel meg a minimálitás elvnek. {Családi} és {Kereszt} nem biztosit 4.5. Relációs adatok integritása: Jelölt Kulcsok: Elsősorban kell figyelni az adatok struktúráját és nem konkrét értékét. Ha a reláció egyetlen egy rekordot tartalmaz akkor bár melyik attribútum megfelel. Kell választani valami egyedi attribútum amely tartósan maradandó a relációban. egyedi jelölés minden sornak. 31 32 4.5. Relációs adatok integritása: Elsődleges kulcs: Valamelyik jelölt kulcs lesz az elsődleges kulcs Elsősorban. A legtöbb esetben valami sorrendes attribútum kell hogy megfeleljen. 4.5. Relációs adatok integritása: Elsődleges kulcs és a Null érték: A hiányzó adatokat lehet reprezentálni a Null értékkel. Egyed integritás: Elsődleges kulcsok nem tartalmazhatnak Null értéket. 33 34 4.5. Relációs adatok integritása: Idegen kulcs: 4.5. Relációs adatok integritása: Idegen kulcs: Példa Az idegen kulcsokat hasznosak az adatok összekötésében két különböző relációban. Attribútumok egy halmaza az első (referáló) relációban idegen kulcs lesz ha az értéke mindig: -Egyenlő a jelölt kulcs értékével a második (referált) relációban, vagy, -Teljesen Null. Egy koncepció amely refrenciális integritásnak hívják (referencial integrity) Osztály OAzon. ONév 13 Marketing 14 Accounts 15 Personnel {OAzon.} jelölt kulcs az Osztálynak - Minden rekordnak van egyedi értéke az OAzon.-nak AAzon. ANév OAzon. 15 Kovács János 13 16 Muller Mária 14 17 Feher Mark 13 18 Kovács Anna NULL {OAzon.} Idegen kulcs az relációban- mert minden i OAzon. érték vagy Null vagy azonos egy rekorddal az Osztály relációban, így minden legfeljebb egy Osztályhoz. 35 36 6
4.5. Relációs adatok integritása: Idegen kulcs: Példa Azon. Név Manager A1496 Kovács János A1499 A1497 Muller Mária A1498 A1498 Feher Mark A1499 A1499 Kovács Anna NULL {Azon.} Jelölt kulcs az Relációban, és a Manager idegen kulcs amely mutat azonos relációra- Minden rekordnak a Manager értéke vagy Null vagy azonos az Azon. értéknek. 37 4.5. Relációs adatok integritása: Referenciális integritás Frissítésnél a referenciális integritás gyakran szenved hátrányt. Általában ez a hátrány történik amikor a referált rekord frissítjük vagy töröljük. Ilyenkor több lehetőség közül tudunk választani: RESTRICT Korlátozz: Ne engedj végrehajtanistop the user from doing it CASCADE Kaszkádolj: Engedj a változások kaszkádolását let the changes flow on NULLIFY Nulláz: Adj Null értéket make values NULL 38 4.5. Relációs adatok integritása: Referenciális integritás-példa Mit történik ha: Marketing-es OAzon. változik 16 ra. Az Accounts nevú rekordot eltörölték az Osztáy relációból. Osztály OAzon. ONév 13 Marketing 14 Accounts 15 Personnel AAzon. Anév OAzon. 15 Kovács János 13 16 Muller Mária 14 17 Feher Mark 13 18 Kovács Anna NULL 4.5. Relációs adatok integritása: Referenciális integritás- Restrict (Korlátozz) RESTRICT (Korlátozz): nem enged bármilyen tevékenység amely ütközik az integritás elvével! Így a Marketing és Acounts nem lehet törölni se frisstani A Personnel lehet változtatni mert nincsen referálva. Osztály OAzon. ONév 13 Marketing 14 Accounts 15 Personnel AAzon. Anév OAzon. 15 Kovács János 13 16 Muller Mária 14 17 Feher Mark 13 18 Kovács Anna NULL 39 40 4.5. Relációs adatok integritása: Referenciális integritás- Cascade (Kaszkádolj) CASCADE (Kaszkádolj): Engedi a változások kaszkádolását Ha a Marketing-es OAzon. változik 16 ra az Osztályban, akkor OAzon. Kovács Jánosnek és Feher Marknak is változik. Ha töröljük az Accounts, akkor Muller Mária is törlődik. Osztály OAzon. ONév 13 16 Marketing 14 Accounts 15 Personnel AAzon. ANév OAzon. 15 Kovács János 13 16 16 Muller Mária 14 17 Feher Mark 13 16 18 Kovács Anna NULL 4.5. Relációs adatok integritása: Referenciális integritás- Nullify (Nullázz) NULLIFY (Nullázz): Nullát hozza rendel a problémás értékekhez Ha Marketing-es OAzon. változik, akkor Kovács Jánosnak OAzon.-je és Feher Mark OAzon._je vesznek null értéket. Ha töröljük az Accounts rekordot, akkor Muller Mária OAzon.-je null értéke lesz. Osztály OAzon. ONév 13 16 Marketing 14 Accounts 15 Personnel AAzon. Anév OAzon. 15 Kovács János 13 NULL 16 Muller Mária 14 NULL 17 Feher Mark 13 NULL 18 Kovács Anna NULL 41 42 7
4.5. Relációs adatok integritása: Név jelölési konvenciók Név jelölési konvenciók: Konzisztens nevezési eljárás lehetőséget ad az adatok struktúrája hatékony kezelésében. Minden relációt célszerű ellátni egyedi és indikatív névvel és prefix, pld stunév, stb. Kulcs név jelölés: Egyedi számozással ellátni az elsődleges kulcsot nagyon hasznos lehet. Ha a reláció prefix-je abc például, akkor a kulcs neve lehet abcazon.. És akkor az idegen kulcs lehet abcazon.. 4.5. Relációs adatok integritása: Név jelölési konvenciók Példa: Hallgató halazon. halnév Ezek az attributomok a Hallgato tablahoz tartoznak Kurzus halazon. modazon. Module modazon. Ezek az attributomok a Kurzus tablahoz tartoznak modnév 43 44 4.6. Az adatok strukturális formai: Rendezetlen: Szövegszerű rendszerek: A szövegszerű tárolásnál a dokumentumok, könyvek, cikkek alkotják a legkisebb elérési egységet, s a dokumentum belső struktúra nélkül, ömlesztve tartalmazza az információt. Rendezet: Finoman strukturált rendszerek: Az adatszerű tárolásnál sokkal kisebb adatelemek, egyedek tulajdonságai is elérhetők és kezelhetők. Ekkor rákérdezhetünk például egy ember nevére, lakcímére, azaz minden egyedi tulajdonságára is. A feldolgozandó témáink az adatszerű, strukturált adattároláshoz fognak csatlakozni. 4.7. Táblák tervezése: Tervezési megfontolások: Milyen típusú adatokat fog tartalmazni a tábla? Milyen oszlopok szükségesek a táblában, és milyen lesz ezek adattípusa (és hossza, ha szükséges)? Mely oszlopokban megengedett a Null érték? Kell-e e korlátozásokat használni, és ha igen, akkor hol? Milyen típusú indexek szükségesek, hol kell használni ezeket, és mely oszlopok alkotják az elsődleges és az idegen kulcsot? 45 46 4.8. Táblák az adatbázisban: Tábla tervező nézetben: Oszlopok: Mezőnvek Adattipusok Leirások Mezőtulajdonságok 4.8. Táblák az adatbázisban: Tábla tervező nézetben: Oszlopok: Mezőnvek Adattipusok Leirások Mezőtulajdonságok 47 48 8
4.8. Táblák az adatbázisban: Tábla normál nézetben: Oszlopok: Mezők Sorok: Rekordok Cellák: Cella érték 4.9. Struktúra amely több problémát hordoz: Anomáliák Redundanciák Sor (Rekord) Oszlop (Mező) Cella érték 49 50 4.9. 4.9.1..1. Redundanciák: A redundanciáról akkor beszélünk, ha valamely tényt vagy a többi adatból levezethető mennyiséget ismételten. (többszörösen) tároljuk az adatbázisban. Felesleges adattárolás. Komplikált adatbázis frissítési és karbantartási műveletekhez vezet. Okozhat adatbázis inkonzisztenciáját. 4.9. 4.9.2..2. Anomáliák: Bővítési anomáliák. Módosítási anomáliák. Törlési anomáliák. Megoldás: Több táblás adatbázis. Megoldás: Normálizáció Relációs modellezés és tervezés Strukturált tervezés Logikai tervezés Több táblás tervezés 51 52 4.9. 4.9.2..2. Anomáliák: Bővítési anomáliák: 4.9. 4.9.2..2. Anomáliák: Törlési anomáliák: 53 54 9
2.9. 4.9.2..2. Anomáliák: Módosítási anomáliák: 4.10. Több táblás adatbázisok: 4.10.1. Struktúra: Több táblából áll az adatbázis, ezek a táblák kell hogy strukturális kapcsolat álljon köztűk. fkód bm va ag foglalkózás Bányamérnök Vájár Agrármérnök 55 56 10