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. Adatbázis fogalma Adatbázison köznapi értelemben adatok valamely célszerűen rendezett tárolását értjük. Az adatbázis esetén nem az adatok.

Hasonló előadás


Az előadások a következő témára: "Adatbázisok. Adatbázis fogalma Adatbázison köznapi értelemben adatok valamely célszerűen rendezett tárolását értjük. Az adatbázis esetén nem az adatok."— Előadás másolata:

1 Adatbázisok

2 Adatbázis fogalma Adatbázison köznapi értelemben adatok valamely célszerűen rendezett tárolását értjük. Az adatbázis esetén nem az adatok nagy számán van a hangsúly, hanem a célszerű rendezettségen. Az adathalmaz csak akkor válik adatbázissá, ha az valamilyen rend szerint épül fel, mely lehetővé teszi az adatok értelmes kezelését. Az adatbázisok mellé egy adatbáziskezelő rendszer (DBMS) is járul, mely az adatbázis vagy adatbázisok üzemeltetését biztosítja.

3 Történelmi áttekintés Ókorban - kőtáblákra vagy papirusz tekercsekre írás. Az adatbázisok fejlettebb formái később a kartoték rendszerek lettek 50-es 60-as években az adatok tárolása még lyukszalagon, lyukkártyán történt, az adatok közvetlenül nem voltak elérhetők a számítógép számára. A mágneses háttértárolók elterjedésével az adatok tárolása egyszerűbbé, elérésük hatékonyabbá vált. Ezekben az időkben még nem léteztek univerzális módszerek illetve rendszerek, melyek segítségével az adatbázisokkal kapcsolatos problémák nagy része általánosan megoldható lett volna.

4 Történelmi áttekintés A számítógépek fejlődésével együtt fejlődtek a programozói lehetőségek is. Az első számítógépeken csak a gépi kód (a bináris formában kiadott utasítások a mikroprocesszornak) állt rendelkezésre. Ezt első generációs programnyelvnek nevezzük. Ezt követték a második generációs (assembler) nyelvek, melyekben a gépi kód helyett úgynevezett mnemonikok és szimbólumok alkalmazhatók. Az első illetve második generációs programnyelvekben még nem készültek komoly adatbáziskezelő alkalmazások. Ezekre egyrészt a magas szintű nyelvek (3. generációs program nyelvek) COBOL, FORTRAN stb., másrészről a lemezes operációs rendszerek kialakulásáig kellett várni. Ekkor már komoly adatbázis alkalmazások születtek, melyek egyedi problémák megoldására voltak alkalmasak. Az adatbáziskezelés általános formában történő megfogalmazására jöttek létre az adatbázis kezelő rendszerek (DBMS) és a negyedik generációs nyelvek (4GL). Az objektum orientált programozási nyelvek térhódításával az adatbázis kezelő rendszerekkel kapcsolatos kutatások is az objektum orientált megközelítés irányába nyitott.

5 1. generációs nyelvekGépi kódú programozás 2. generációs nyelvekAssembler nyelvek 3. generációs nyelvek Imperatív nyelvek: Algol (1960), FORTRAN (1954), C (1973), Pascal (1970), Basic (1964) 4. generációs nyelvek)SQL (1970), PL/SQL (1991), PL/pgSQL, MATLAB ( generációs nyelvekLogikai programozási nyelvek: Prolog (1970), Lisp (1960) Objektum orientált nyelvekSmallTalk (1972), C++ (1981), Java (1994), Visual Basic Script nyelvekPerl (1987), Python (1991), PHP (1995), JavaScript (1995)

6 Adatbáziskezelők szerepe, célja Manapság nem elégszünk meg egy adatbázissal, mely az adatokat rendszerezve tárolja, hanem az adatok kezeléséhez szükséges eszközöket is az adatbázis mellé képzeljük. Az így kialakult program rendszert adatbázis kezelő rendszernek (DBMS Database Management System) nevezzük. A DBMS-ek megváltoztatták a végfelhasználók adatnyerési lehetőségeit az egyszerű lekérdezési nyelvek bevezetésével. A lekérdező nyelvek lehetőséget nyújtanak a nem számítógépes szakemberek számára is tetszőleges lekérdezés gyors végrehajtására. A programozási eszközök mellett az operációs rendszerek illetve azoknak a háttértárakat kezelő része is komoly fejlődésen ment keresztül. –Nem volt már szükség a fizikai fájlszerkezet pontos ismeretére, ezt az operációs rendszer illetve az adatbáziskezelő rendszer elfedte a felhasználó és a programozó elől is. –Az adatbázisokban gyakran előfordulnak olyan típusú adatok, melyeket az operációs rendszer vagy a harmadik generációs programnyelvek közvetlenül nem kezelnek, például dátum, időpont, pénzegység stb.

7 Az adatbáziskezelők három alapvető feladata Függetlenség az aktuális hardver konfigurációtól –a fejlesztőnek ne kelljen törődnie a fizikai szintű adattárolással, ne kelljen közvetlenül lemez blokkokra, cilinderekre hivatkoznia. Függetlenség az adatelérés módjától –Az egyes operációs rendszerek a fájlokra többfajta adatelérési módot (szekvenciális, indexelt, véletlen) kínálnak az alkalmazások készítőinek. Függetlenség az adatstruktúráktól –Az adatbázisok szerkezetében beálló változások minél kevesebb módosítást okozzanak az alkalmazásokban.

8 Különböző adatbázis modellek Az adatbáziskezelők fejlődése során többfajta logikai modell alakult ki, melyek főként az adatok közötti kapcsolatok tárolásában térnek el egymástól. Hierarchikus, Hálós, Relációs, Objektum relációs és az objektum orientált modell. Ezek közül manapság a Windows illetve UNIX operációs rendszerekben döntően a relációs modellre épülő adatbáziskezelőket használnak.

9 Hierarchikus adatbázis modell A hierarchikus modell az 1960-s évek végén alakult ki és az 1970.s évek végéig használták. IBM IMS Szerkezetét gráffal adjuk meg: –Az adatbázis több egymástól független fából állhat. A fa csomópontjaiban és leveleiben helyezkednek el az adatok. A közöttük levő kapcsolat, szülő gyermek kapcsolatnak felel meg.

10 Hálós adatbázis modell A hálós adatmodell esetén az egyes azonos vagy különböző összetételű adategységek (rekordok) között a kapcsolat egy gráffal írható le. A gráf csomópontok és ezeket összekötő élek rendszere, melyben tetszőleges két csomópont között akkor van adatkapcsolat, ha őket él köti össze egymással. Egy csomópontból tetszőleges számú él indulhat ki, de egy él csak két csomópontot köthet össze.

11 Relációs adatbázis modell A relációs az egyik legáttekinhetőbb és a 80-as évektől kezdve a legelterjedtebb adatmodell. Kidolgozása E. F. Codd ( ) nevéhez fűződik, 1970-ben jelent meg alapvető műve a ""A Relational Model Data Large Shared Data Banks". A relációs modellben az adatokat táblázatok soraiban képezzük le. A legfontosabb eltérés az előzőekben bemutatott két modellhez képest az, hogy itt nincsenek előre definiált kapcsolatok az egyes adategységek között, hanem a kapcsolatok létrehozásához szükséges adatokat tároljuk többszörösen. Ezzel egy sokkal rugalmasabb és általánosabb szerkezetet kapunk.

12 Az egyedet táblázattal adjuk meg, a táblázat oszlopai a tulajdonságok, sorai pedig az egyed előfordulási (értékei). A táblázat egy-egy sorát a tulajdonságok konkrét értékei adják. A táblázat maga az egyedhalmaz. Relációs adatmodell

13 Objektum-relációs adatbázis modell Az objektum relációs adatmodell a relációs adatmodell bővítésével állt elő. Egyrészt az objektum orientált megközelítésben használt osztály, objektum, öröklődés fogalmakat alkalmazza az relációs adatbázis táblákra és a lekérdező nyelvet is ez irányba bővíti. Másrészt pedig támogatja az adatmodell bővítését saját adattípusokkal és azokat kezelő beépített függvényekkel.

14 Relációs adatbázisok - részletesebben A relációs adatszerkezet egyszerűen értelmezhető a felhasználók és az alkalmazás készítők számára is, így ez lehet közöttük a kommunikáció eszköze. A logikai adatmodell relációi egy relációs adatbáziskezelő rendszerbe módosítások nélkül átvihetők. A relációs modellben az adatbázistervezés a normál formák bevezetésével egzakt módon elvégezhető

15 Néhány relációs adatbázis- kezelő Oracle MS SQL Server IBM DB2 PostgreSQL MySQL SQLite

16 Relációs adatbázisok, alapfogalmak A reláció nem más mint egy táblázat, a táblázat soraiban tárolt adatokkal együtt. –Az oszlopok névvel rendelkeznek, melyeknek a reláción belül egyedieknek kell lenniük –A reláció soraiban tároljuk a logikailag összetartozó adatokat.

17 Adatbázistervezés Az adatbázistervezés egy folyamat, mely több lépésből tevődik össze. –Először az adatbázisban leképezendő rendszert elemzésnek vetjük alá és meghatározzuk a tárolandó adatok körét, azok egymás közötti kapcsolatait és az adatbázissal szemben felmerülő igényeket –Ezután következik a rendszer tervezés, melynek eredménye az adatbázis logikai modellje. –Végül fizikai szinten képezzük le a logikai adatbázis modellt az alkalmazott szoftver és hardver függvényében.

18 Adatbázistervezés A tényleges tervezés ismertetése előtt néhány újabb fogalmat kell bevezetni -funkcionális függőség, -reláció kulcs, -redundancia,

19 Adatok közötti funkcionális kapcsolat Adatok között akkor áll fenn funkcionális kapcsolat, ha egy vagy több adat konkrét értékéből más adatok egyértelműen következnek –A funkcionális függőség bal oldalát a függőség meghatározójának nevezzük. A jobb oldalon levő egy, csak egy értéket határoz meg a funkcionális függőség. –Nem áll fenn funkcionális függőség akkor, ha a meghatározó egy értékét több attribútum értékkel hozhatjuk kapcsolatba. Például a NÉV -> SZÜLETÉSI_ÉV

20 Teljes funkcionális függőség A funkcionális függőségek speciális esete a teljes funkcionális függőség. Erről akkor beszélhetünk, ha a meghatározó oldalon nincsen felesleges attribútum.

21 Adatok közötti többértékű függőség Az adatok között fennálló kapcsolatok közül nem mindegyik fejezhető ki a funkcionális függőség segítségével. Például minden embernek lehet több szakmája, illetve ugyanazzal a szakmával több ember is rendelkezhet. Ebben az esetben egyik irányban sincs egyértelmű függőség. Ez egy többértékű függőség, az egyik attribútumhoz egy másik attribútum csoportja, halmaza kapcsolódik. A többértékű függőség ábrázolására a dupla nyilat használjuk.

22 Egyedtípuson belüli kapcsolatok fajtái: Funkcionális függés (egyirányú): Egy egyedtípuson belül az azonosító egyértelműen meghatározza a tulajdonságtípus értékét. (személyi szám  név) Kölcsönös funkcionális függés: Az azonosító egyértelműen meghatározza a tulajdonságtípus értékét, és a tulajdonságtípus is az azonosítót. (szem.szám   adószám) Ezek a tulajdonságtípusok lehetnek azonosítók. Funkcionális függetlenség: Az azonosító nem határozza meg egyértelműen a tulajdonságtípus értékét. (személyi szám  X  tanult tantárgy) Fordított funkcionális függés: Az azonosító nem határozza meg egyértelműen a tulajdonságtípus értékét, de a tulajdonságtípus egyértelműen meghatározza az azonosítót. (anya személyi száma   /  gyermek személyi száma)

23 Reláció kulcs fogalma A reláció kulcs a reláció egy sorát azonosítja egyértelműen. (A reláció - definíció szerint- nem tartalmazhat két azonos sort, ezért minden relációban létezik kulcs.) A reláció kulcsnak a következő feltételeket kell teljesítenie –az attribútumok egy olyan csoportja, melyek csak egy sort azonosítanak (egyértelműség) –a kulcsban szereplő attribútumok egyetlen részhalmaza sem alkot kulcsot –a kulcsban szereplő attribútumok értéke nem lehet definiálatlan (NULL)

24 Redundancia fogalma A logikai adatbázis tervezés egyik fő célja a redundanciák megszüntetése. 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. A redundancia, a szükségtelen tároló terület lefoglalása mellett, komplikált adatbázis frissítési és karbantartási műveletekhez vezet, melyek könnyen az adatbázis inkonzisztenciáját okozhatják. Egy adatbázis akkor inkonzisztens, ha egymásnak ellentmondó tényeket tartalmaz.

25 Adatmodellezés Az adatmodellezés segítséget nyújt a környező világ megértésében és leképezésében, a lényeges jellemzők kiemelésében. Az adatmodell az adatok és az azok közötti összefüggések leírására szolgál. A modell olyan mesterséges rendszer, amely felépítésében és viselkedésében megegyezik a vizsgált létező rendszerrel Adatmodellnek nevezzük az adatok struktúrájának (felépítésének) leírására szolgáló modelleket.

26 Egyed-tulajdonság-kapcsolat Az adatmodell a fenti három fogalom együttese Egyed-nek nevezzük az információs rendszert felépítő személyeket, tárgyakat, eseményeket Az egyedeket a tulajdonság-aik jellemzik A tulajdonság egy érték, amelynek tulajdonságtípusa van. pl: név  tulajdonságtípus János  tulajdonság

27 Egyed-tulajdonság-kapcsolat A tulajdonság lehet:  Azonosító, mely minden egyednél különböző értéket vesz fel, az egyedek közt nem ismétlődhet pl: személyi szám ( )  Leíró tulajdonság, mely az egyed egy jellemzőjét írja le, több egyednél is előfordulhat pl: név (Kovács János)  Gyengén jellemző tulajdonság, mely az előzőhöz hasonló, de nem kötelező megadni (üres is lehet) pl: kedvenc sportága (úszás)  Kapcsoló tulajdonság, mely egyik egyedben leíró,a másikban azonosító funkciót tölt be  Pl: születési hely (Siófok)

28 Egyed-tulajdonság-kapcsolat Egy rendszerben az egyedek nem elszigetelten vannak jelen, hanem kapcsolatban állnak más egyedekkel és objektumokkal. A kapcsolatrendszer többszintű, bonyolult struktúra, melyben több rendszer is kapcsolatban állhat egymással. Az ETK (egyed- tulajdonság- kapcsolat) modellben két egyedtípus egyedei közötti viszonyt kapcsolat-nak nevezzük

29 Kapcsolatok típusai: „egy-az-egyhez” (1-1) egy egyedtípus egy egyedéhez egy másik egyedtípus csak egyetlen egyede kapcsolódhat és fordítva is igaz (osztály- osztályfőnök) „egy-a-többhöz” (1-N) egy egyedtípus egy egyedéhez egy másik egyedtípus több egyede is kapcsolódhat de fordítva nem igaz (osztály- tanuló) „több-a-többhöz” (N-M) egy egyedtípus egy egyedéhez egy másik egyedtípus több egyede is kapcsolódhat de fordítva is igaz (osztály-tanár) Az adatbázis fogalma a kapcsolatok alapján: Az adatbázis véges számú egyedek, azok egyenként is véges számú tulajdonságainak és kapcsolatainak adatmodell szerinti szervezett együttese.

30 Normalizálás Az adatbázis tervezése során a legfontosabb feladat a logikai adatmodell kialakítása, mely azt jelenti, hogy: az adatok laza halmazából egy jól felépített, átlátható logikai adatstruktúrát hozunk létre. Ezt a folyamatot nevezzük NORMALIZÁLÁS-nak.

31 Normalizálás lépései Az egyedeken belüli kapcsolatok meghatározása (Az egyedeket tulajdonságaikkal jellemezzük) Egyedtípusok meghatározása: Azokat az egyedeket, amelyeket azonos tulajdonságokkal írhatunk le, egyedtípusoknak nevezünk. Azonosító meghatározása: A tulajdonságtípusok közül kiemelhető, az egyedre kizárólagosan jellemző tulajdonságtípus az azonosító. Egyedtípuson belüli kapcsolatok meghatározása: Egy egyed azonosítója és egy tulajdonsága közti kapcsolatot egyértelműen meg tudjuk-e határozni?

32 Normálformák Az adatmodellek létrehozásakor jól meghatározott és egyértelmű kapcsolatokkal rendelkező egyedtípusokat kell kialakítani. Ehhez meg kell határoznunk az egyedtípus normálformáját. Egyedtípus nulladik normálformája: Ha egy egyedtípuson belül van olyan tulajdonságtípus, amely funkcionálisan független az azonosítótól. Feladatunk a funkcionális függetlenség feloldása. Összetett azonosítóval javítható lenne, de ez adatismétlődéssel jár.  Redundancia  Inkonzisztencia

33 Normálformák Első normálforma: Egy egyedtípuson belül minden tulajdonságtípus funkcionális függésben áll az összetett azonosítóval, de van olyan tulajdonságtípus, amely az összetett azonosítónak csak egy részétől függ. Ez részleges funkcionális függés, tovább kell normalizálni, pl. új egyedtípus bevezetésével.

34 Az adatbázis tervezése Egy relációs adatbázis valamilyen fokon normalizált, más szóval valamilyen normálformában van, ha eleget tesz meghatározott korlátozásoknak. Célja a redundancia csökkentése. 1. normálforma: Egy reláció 1. normálformában (1NF) van, ha minden oszlopban csak egy attribútum jelenhet meg, az oszlopok sorrendje ugyanaz, nincs oszlopismétlődés és minden sora legalább egy összetevőjében különbözik bármely másiktól.

35 Normálformák Második normálforma: Ha egy egyedtípuson belül minden tulajdonságtípus csak az azonosítóval áll funkcionális függésben, de van olyan tulajdonságtípus, amely függ egy másik leíró jellegű tulajdonságtípustól is. Ennek oka a „tranzitív függés”, ami azt jelenti, hogy az egyedtípusnak van olyan tulajdonságtípusa, amely függ egy másik leíró jellegű tulajdonságtípustól.

36 Az adatbázis tervezése Egy relációs adatbázis valamilyen fokon normalizált, más szóval valamilyen normálformában van, ha eleget tesz meghatározott korlátozásoknak. Célja a redundancia csökkentése. 2. normálforma: Egy reláció 2. normálformában (2NF) van, ha 1NF-ben van és csak a kulcsértékektől függenek a nem-kulcs mezők értékei. Ezt az állapotot legtöbbször a reláció szétbontásával (dekompozíció) érhetjük el.

37 Normálformák Harmadik normálforma: Ha egy egyedtípuson belül valamennyi tulajdonságtípus kizárólag az azonosítótól függ funkcionálisan. Létezik negyedik és ötödik normálforma is, de általában a harmadik normálforma elérése elegendő.

38 Az adatbázis tervezése Egy relációs adatbázis valamilyen fokon normalizált, más szóval valamilyen normálformában van, ha eleget tesz meghatározott korlátozásoknak. Célja a redundancia csökkentése. 3. normálforma: Egy reláció 3. normálformában (3NF) van, ha 2NF-ben van és nincsenek elsődleges kulcstól áttételesen (tranzitíven) függő értékek. Ezt az állapotot legtöbbször a reláció szétbontásával (dekompozíció) érhetjük el.

39 Normálformák 1.Normál forma (Nf): Egy R relációról azt mondjuk, hogy 1 Nf-ban van, ha minden sorában pontosan 1 attributum érték áll. Az egyed típus egyetlen tulajdonság(mező)típusának függenie kell az azonosítótól. 2.Normál forma: A tulajdonságsorban nem lehet olyan tulajdonság(mező)típus, amely az összetett azonosítónak csak az egyik részétől függ.(A 2 Nf-át csak az összetett azonosító megléte estén vesszük figyelembe!) 3.Normál forma: egyed típus egyetlen tulajdonság(mező)típusa sem függhet más leíró (ami nem kulcs) tulajdonságtípustól. 4.Normál forma: Az összetett azonosító egyik része sem függhet a másiktól, csak az összetett azonosító egészétől.(A Nf teljesüléséhez itt is szükséges az összetett kulcs!) 5.Normál forma: Az összetett azonosító nem okozhat pszeudotranzitív funkcionális függést.relációrólegyedösszetettegyed pszeudotranzitív

40

41

42 Anomáliák Az adatbázis használata során nem kívánatos mellékhatások fordulhatnak elő. Kiküszöbölésük a magasabb normálformákra hozással történhet. Módosítási anomália: csak úgy lehet bizonyos attribútumok értékét megváltoztatni, hogy a táblázaton belül minden rekordot (sort) tételesen megvizsgálunk. Törlési anomália: csak adatvesztés árán lehet pillanatnyilag szükségtelen tételeket eltávolítani. Bővítési anomália: ha egy új tételt képtelenek vagyunk felvenni (például hiányzó adata miatt).

43 Osztott rendszerek A logikailag egységes, fizikailag azonban különböző -egymással összekapcsolt számítógép rendszereken megvalósított adatbázist osztott adatbázisnak nevezünk (a távolság nem számít). A nagygép tehermentesítése céljából megosztották a feladatokat. Az adatok fogadása a frontend- en, a feldolgozás a host-on, az adatok tárolása a backend-en történik.

44 A backend-el kapcsolatos követelmények: -Nagy kapacitású, gyors elérésú háttértár -Az adatbázis rendszertől független legyen. A backend előnyei: -gazdaságosabb (frontend host kissebb proci elég) -Egyszerűbb a host cseréje. -Hosszabb az élettartama. A backend hátrányai: -Fizikai karbantartási problémák. -Kihasználtság.

45 Osztott rendszerek tervezési kérdései: 1. Valamilyen elv alapján részekre bontjuk az elemezendő adathalmazt. 2. Alrészekre fogalmi adatmodellt dolgozunk ki. Úgy, hogy külön-külön normalizáltak legyenek. 3. Összefüggések elemzésével két részmodellből közös normalizált modellt állítunk elő. 4. A közös és egy másik normalizált részmodellel újabb közös normalizált részmodellt hozunk létre. És addig ismételjük, amíg egy modellt nem kapunk.

46 Adatvédelem fajtái, módszerei Centralizálás Analóg jellegű adatok digitális tárolása Adatáramlás titkosítással

47 Adatvédelmi módszerek a következők lehetnek: 1. Tárolási hozzáférhetetlenség - például jelszavas védelem. A jelszó hosszúságával arányosan nő a megfejthetőség nehézségi foka (laikus próbálkozások ellen véd). Rejtjelzett tárolás. Lehetséges algoritmusokkal, vagy véletlenszám generálással. Hardware kulcsok. 2. Adatátviteli utak védelme: Paritáskódos hibajelzést alkalmaznak. 3. A kezelt (tárolt, továbbított) dokumentumok hitelességének vizsgálata. Járulékos információkat kódolnak hozzá az adatokhoz.

48 Adatvédelem Kapcsolt listák. Fa struktúra: Különböző adatok között herarchikus (link) struktúra esetén. Egymástól elkülöníthető részek. Így egy hálózat nagyszerűen alakalmas adatvédelemre (Adatbiztonság).

49 Adatbázis felügyelő, tervezési kérdések Az adatbázis felügyelet egy szerteágazó és igen sokoldalú felkészültséget kívánó tevékenység. Egyetlen szakember szinte biztos nem tudja ellátni, ezért szét kell osztani. Tervezés: Célja: A Konziszetencia,a redundancia elkerülése.Konziszetenciaredundancia

50 Menete: 1.Milyen adatokat akarunk tárolni (információgyűjtés,döntés). 2.Adatbázis tábláinak meghatározása. 3.Normalizálás (finomítás) -> teszt -> működőképesség. 4.Kapcsolatok létrehozása. 5.Próbaadatok. 6.Tesztelés. 7.Lekérdezések. 8.Képernyőtervek. 9.Listatervek. 10.Segédprogramok. 11.FeltöltésNormalizálásKapcsolatLekérdezések


Letölteni ppt "Adatbázisok. Adatbázis fogalma Adatbázison köznapi értelemben adatok valamely célszerűen rendezett tárolását értjük. Az adatbázis esetén nem az adatok."

Hasonló előadás


Google Hirdetések