Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Adatbáziskezelés

No description
by

Marancsics Tamás

on 30 September 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Adatbáziskezelés

Adatbázis - bevezetés
Az óra tartalma
Az adatbázisokról általánosan, eredetük.
adatmodell
Számítógépes adatbázis modellek
Adatbázis fogalma
Köznapi értelemben rendezett, valamilyen szisztéma szerint tárolt adatok együttese.
Lehetővé válik az adatok kezelése (keresés, szűrés)
Egyébként csak adathalmazról beszélnénk!
Szükség van egy adatbázis-kezelő rendszerre!
Személyzet
Szoftver
Például hagyományos irattár
Elektronikus adatbázis esetén
Adatbázisok eredete
Ókor: babilon, görög és római kereskedelmi kőtáblák, papiruszok
Később: kartoték rendszerek
Napjainkban: számítógépes adatbázis-kezelő rendszerek
Adatbázis-kezelők szerepe
Az adatok kezeléséhez szükséges eszközöket biztosítja a felhasználó számára. Ilyen eszköz a grafikus felület vagy a beépített lekérdező nyelv. Cél egy magasabb absztrakciójú, logikai szintű elérés.
Három alapvető elvárás:
Független a hardvertől: legyen független az adathordozó a megjelenítéstől, így legyen hordozható az alkalmazás!
Független az adatelérés módjától: a felhasználó csak a kérdés megfogalmazása és ne az eredmény előállításának módját kelljen leírnia!
Független az adatstruktúrától: az információ legyen független az adatokat tároló állomány felépítésétől!
Hierarchikus
Legelső, legősibb adatbázis modell. Az állományok egy hierarchikus, fa struktúrában kerülnek eltárolásra.
Nem ábrázolható benne n:m-es kapcsolatok.
Adatok elérése egyféle, a tárolás sorrendjében lehetséges.
Hálós modell
Az adatok közötti kapcsolat egy gráffal írható le, így lehetséges az n:m kapcsolatok tárolása.
A hierarchikushoz hasonlóan a bejárás csak a tárolt kapcsolatokon keresztül lehetséges.
Merev szerkezet, módosítása nehéz.
Relációs modell
Az adatok táblázatok soraiba képződnek. Itt nincsenek előre definiált kapcsolatok, hanem a kapcsolatok létrehozásához szükséges adatokat tároljuk többszörösen. Ezzel sokkal rugalmasabb és általánosabb szerkezetben lehetséges az adatok tárolása.
gyökér
levelek
Relációs modell
elemei

Adatbázis-kezelő
követelményei
Adatintegritás - adat- és kapcsolat helyesség biztosítása, ellentmondás mentesség
Rugalmasság - adatok egyszerű módosíthatósága
Hatékonyság - gyors keresés és módosítás a tárolt adatokban
Adatfüggetlenség - hardver- és szoftverfüggetlenség a felvitt adatoknál
Adatbiztonság - hardver- és szoftverhiba elleni védelem
Osztott hozzáférés - több felhasználó párhuzamos hozzáférésének biztosítása
Adatvédelem - felhasználói jogkezelés alkalmazása
Adatmodell
Modell: mesterséges rendszer, amely felépítésében, viselkedésében megegyezik a vizsgált létező rendszerrel.
Adatmodell: az adatok és az azok közötti összefüggések, az adatok struktúrájának leírására szolgáló modell.
Egyed - tulajdonság - kapcsolat
A fenti hármas alkotja a adatmodellt.
Egyed
A modellezni kívánt információs rendszer résztvevői.
Tulajdonságok jellemzik, ezek a különböztetik meg az egyes egyedeket.
Tulajdonság
Azonosító: kötelező, minden egyednél különböző érték, nem ismétlődhet. (Pl: személyi szám)
Leíró tulajdonság: kötelező, jellemző, de több egyednél is előfordulható tulajdonság (Pl: név)
Gyengén jellemző tulajdonság: nem kötelező leíró tulajdonság (Pl: kedvenc sport)
Kapcsolódó tulajdonság: Több egyedben szereplő tulajdonság, amely egyik egyedben leíró, másikban azonosító (Pl: születési hely)
Kapcsolat
Egy rendszerben az egyedek kapcsolatban állnak egymással, sőt, komplett rendszerek között is épülhet ki kapcsolat.
Kapcsolat fajtái:
Egy-az-egyhez (1-1): egy egyed egy időben csak egy másik egyedhez kapcsolódhat
Egy-a-többhöz (1-N): egy egyedtípus egy példányához több másik egyedtípus példánya kapcsolódhat
Több-a-többhöz (N-M): egy egyedtípus több egyede egy másik típus több egyedéhez is kapcsolódhat és fordítva
Adattábla / tábla
Egy táblázat, amely soraiban az adatok tárolódnak. A táblázat sorai a rekordok, oszlopai a tulajdonságok (attribútumok), cellái a mezők.
Példa
Marvel Hősök (forrás: Wikipedia)
Rekord
Logikailag összetartozó adatok.
A rekordokban azonos oszlopban azonos típusú adat szerepel.
Típusok
Numerikus: egész és tört számok
Karakteres: egy betű vagy szöveg
Logikai: az értéke igaz vagy hamis
Dátum
Adattábla jellemzői
A rekordok száma a reláció számossága (hány rekord van a táblában?)
A rekord tulajdonságainak száma a reláció foka
Egy tábla nem tartalmazhat két azonos nevű oszlopot
Egy tábla nem tartalmazhat két teljesen azonos rekordot
Minden rekord azonos felépítésű (oszlopok száma, típusai)
A rekordok és tulajdonságok sorrendje tetszőleges lehet
Normálformák!
1NF
2NF
3NF
Függések
Az adattábla egyes oszlopaiban tárolt tulajdonságok függhetnek egymástól (az egyik értékei egyér-telműen meghatározzák a másik értékeit, azaz az egyik tulajdonság minden értékéhez a másik tulaj-donság csakis egy értéke tartozik, de lehetnek függetlenek is.
Funkciónális függések
A tábla oszlopai közötti függéseket funkcionális függéseknek nevezzük. Ilyen függés van pl. a Brigád és a Brigádvezető között (az előbbi egyértelműen meghatározza az utóbbit, hiszen minden brigádnak csak egy brigádvezetője van). A Brigádvezető és a dolgozó Anyja neve funkcionálisan függetlenek, mert mindkettő különböző értékeihez tartozhatnak a másiknak azonos értékei (különböző embereknek lehet azonos nevű anyja, és azonos nevű brigádvezetője is).

Részleges függés
Ebben a táblában összetett kulcsot találunk, hiszen a Film és a Kölcsönző együtt határozzák meg egy kölcsönzés többi adatát (mindenki több filmet is elvihet, és egy film több kópiája létezik, amit más-más kölcsönözhet ki). A Rendező viszont nem függ funkcionálisan az egész kulcstól, csak egy részétől, a Filmtől. Ugyanígy a Kölcsönző címe is csak a kulcs egy részétől függ, a Kölcsönzőtől. A Rendező és a Kölcsönző címe függése részleges funkcionális függés (részleges függés). Ez a fogalom tehát csak összetett kulcs esetén szerepel, és azt jelenti, hogy valamely tulajdonság nem függ a teljes kulcstól, csak annak egy részétől.
Tranzitív függés
Ebben a példában a Beteg TB-száma az azonosító, mert ez egyedi (különböző betegeknek lehet azonos Neve). Ettől funkcionálisan függ a többi tulajdonság. A Tipikus gyógymód azonban nem csak a TB-számtól függ, hanem (sőt, szorosabban) a Betegségtől. Ebben az esetben egy tulajdonság egy másik leíró tulajdonságtól függ, és nem csak az elsődleges kulcstól. Ez a belső vagy tranzitív funkcionális függés (tranzitív függés).
0 NF
Egy feladat megoldása azzal kezdődik, hogy felvesszük egy adattáblába az összes tulajdonságot, ami a szöveg kapcsán felmerül.
Ha elkezdjük adatokkal feltölteni, nyilvánvalóvá válik, hogy tele lesz ismétlődésekkel, azaz sok tulajdonságot többször is rögzítenünk kell.

Az első lépésnek egy követelménye van: ne legyen két azonos sor (minden sor legalább egy tulaj-donságban térjen el egymástól).
Az ilyen, még nyers adatbázis 0. normálformában, azaz 0NF-ben van.

Kapcsolatok
Egy adatbázis általában nem egy, hanem több táblából áll. Ezek a táblák tremészetesen egymástól nem függetlenek, bizonyos összeköttetések jellemzik őket.
A táblák közötti ilyenfajta viszonyokat, összeköttetéseket kapcsolatoknak nevezzük.
Fontos, hogy csak olyan táblák között létesíthetünk kapcsolatot, amelyeknek van azonos értékű mezője (ezt nevezzük kapcsolómezőnek, ennek segítségével lehet az egyik táblából hivatkozni a másikra). Lehetséges olyan eset is, amikor a kapcsolómező nem egy, hanem több mező (pl. összetett kulcs esetén), de ezt kényelmetlen használni és kezelni, ezért kerülendő.
A kapcsolatoknak 3 fajtája van.
Minden országnak csak egy fővárosa van, és minden főváros csak egy országhoz tartozhat. Itt az ORSZÁGOK és FŐVÁROSOK között egy-egy kapcsolat áll fenn.
A kapcsolómezőket kiemeltük, a kapcsolat jelölése a példából látszik.
Ha a táblákat kitöltjük adatokkal, észrevehetjük, hogy a fővárosok neve mindkét táblában szerepel. Ez nem a lehető legkevesebb helyet használja fel: azt akkor érjük el, ha minden lényeges adatot csak egy példányban engedünk rözíteni. Ennek a módja: a FŐVÁROSOK táblában felveszünk egy Kód mezőt, és az ORSZÁGOKBAN erre hivatkozunk.
1-1 kapcsolat
1 - ∞
Minden tulajdonosnak több kutyája is lehet, viszont minden kutyának csak egy gazdája. A TULAJDONOSOK és a KUTYÁK között egy-több kapcsolat áll fenn: az egy oldal a TULAJDONOSOK, a több oldal a KUTYÁK.
Nagyon fontos, hogy mindig el tudjuk dönteni, melyik oldal az
egy
és melyik a
több
, ugyanis az adatbázis feltöltését mindig az egy oldallal kell kezdeni (olyan embert felvehetünk, akinek nincs kutyája, de olyan kutyát, aminek nem szerepel a gazdája, nem).

A filmet a Címe nem azonosítja egyértelműen (azonos Című filmek léteznek), de egy Rendező biztosan nem készít két ugyanolyan Című filmet. Így tehát a Cím-Rendező pár egy összetett kulcsot alkot.
Minden filmben sok színész szerepel ,és minden színész sok filmben szerepel. Tehát a FILMEK és SZÍNÉSZEK között több-több kapcsolat van.
∞ - ∞
Hiába választottuk ki mindkét táblában az elsődleges kulcsot, azok ismétlődnek, a többi adattal együtt. Tehát sérül az az elv, hogy a kulcs egyedi legyen.
Ha a FILMEKBE vesszük fel a Szepelőinek a nevét, akkor minden egyéb tulajdonságot annyiszor meg kellene ismételni, ahány szereplője van a filmnek:
Ha a SZÍNÉSZEKHEZ vesszük fel, hogy milyen filmekben játszottak, még rosszabb a helyzet, mert a film Címét és Rendezőjét is fel kell venni, és itt is annyiszor ismétlődnek az adatok, ahány filmben játszott a színész:
M-N kapcsolat problémái
A több-több kapcsolat nem megengedett egy jól megtervezett adatbázisban. Feloldása minden eset-ben egy kapcsoló jellegű harmadik tábla segítségével lehetséges. Ebbe a táblába a két, több-több kapcsolatban levő tábla azonosító tulajdonságait kell lemásolni, és mindkét irányba egy egy-több kapcsolatot létrehozni.
A példát rögtön úgy mutatjuk meg, hogy a FILMEKET és a SZÍNÉSZEKET is egy-egy kód azonosítja. Ez mindenképpen ajánlható, különösen ha egy összetett kulcs helyett vezetjük be (összetett kulcssal nagyon nehézkes a kapcsolatok kezelése).
A SZEREP táblában minden színész és minden film kódja a megfelelő számúszor van meg (minden filmszerephez -film/színész párhoz tartozik egy sor).
Nézzük a feltöltött adatbázist:
Kulcsnak az Ügyfél nevét választottuk.
Látható a probléma: az Ügyfél adatait annyiszor meg kell ismételnünk, ahány különböző Hitelt felvett.

A probléma oka, hogy a Hitel nem függ funkcionálisan az Ügyféltől, mint kulcstól (egy Ügyfélhez több Hitel is tartozik, azaz az Ügyfél mint kulcs nem határozza meg egyértelműen a Hitelt).

A funkcionális függetlenséget meg kell szüntetni.
Módja: ki kell emelni egy új táblába azt a mezőt, amely funkcionálisan független a kulcstól, és ebben az új táblában meg kell ismételni a kulcsot.

A két új tábla között egy-több kapcsolat van, hiszen minden ügyfél több hitelt is felvehet.
Eredmény:
Köszönöm
a figyelmeteket!

A táblában a Márka és a Típus együtt alkotja az összetett kulcsot, mert külön-külön egyik sem azonosít egy autófajtát. A Gyár információi azonban láthatóan nem függnek a Típustól, csak a Márkától (egy autóGyárban az adott Márka teljes Típusválasztékát gyártják).
A Gyár tulajdonságai tehát rész-leges függésben van az azonosító egy részétől (Márka). Ennek következménye a Gyár adatainak felesleges ismétlése.
A részleges függést úgy szüntetjük meg, hogy az érintett metőket kiemeljük egy új táblába, az azonosítórészt pedig megismételjük.
A két új tábla között egy-több kapcsolat van, hiszen egy gyárban több autótípust is előállítanak.
A részleges függés megszűnt.

Az az adatbázis, amely 1NF-ben van és amelynek tábláiban az összes tulajdonság funkcionálisan a teljes összetett kulcstól függ, 2. normálformában (2NF-ben) van.
A 2NF problémája természetesen csak összetett kulcsok esetén jön elő: egy 1NF-ben levő tábla, amelynek egyszerű kulcsa van, automatikusan 2NF-ben is van.
A termékeket a Leltári szám azonosítja.
A probléma: a Szállító adatai ismétlődnek (egy Szállító több áruval is foglalkozik).
A probléma oka: a Szállító címe és a Kapcsolattartó nem (csak) a Leltári számtól (mint elsődleges kulcstól) függ, hanem tranzitív függésben van a Szállítótól is.
A tranzitív függés megszüntetése:
a függőségben levő mezőket (Szállító címe, Kapcsolattartó) kiemeljük egy új táblába, és megismételjük azt a mezőt, amelytől függenek (Szállító).
A két új tábla között egy-több kapcsolat van, hiszen egy szállító több árut is szállíthat.
Ezzel a tranzitív függéseket megszüntettük.

Az az adatbázis, amely 2NF-ben van és amelynek tábláiban nincs tranzitív függés, 3. normálfor-mában (3NF-ben) van.

• 0NF, ha az adatbázissal még semmit se csináltunk;
• 1NF, ha minden adat funkcionálisan függ az azonosítótól;
• 2NF, ha minden adat funkcionálisan a teljes azonosítótól függ (nincs részleges függés);
• 3NF, ha minden adat funkcionálisan csak az azonosítótól függ (nincs tranzitív függés).

Összefoglalva a normálformákat
Érdemes a „kész” adatbázist abból a szempontból is megvizsgálni, hogy az azonosítók nem túl hoszszúak-e.

A táblák közötti kapcsolatok miatt egyes mezők kétszer tárolódnak (a kapcsoló tulajdonságok).

Nem érdemes ilyen mezőnek Nevet, Megnevezést, Címet stb. választani, mert a dupla tárolás tetemes helyigényt jelent.

Ezek helyett Kódokat vezessünk be, és ezek segítségével oldjuk meg a kapcsolatokat. Ezt az eljárást az adatbázis tömörítésének nevezhetjük.
Megjegyzendő!
Feladat 1.
Egy autókereskedő cégnek több telephelye van az országban. Minden telephelyen több márkát is forgalmaz.
Egy adott márkát mindig egy adott gyártól szerez be, a gyárak egy márka összes típusát gyártják.
A típusjelzések (pl. Ford Mondeo, Renault Mégane) védettek, tehát típusonként egyediek.
A cég kapcsolatot tart ügyfeleivel, akiknek több autójuk is lehet.
Minden autóhoz rendelhetők különböző extrák.
Az autótípusok jellemző tulajdonságait (fogyasztás, teljesítmény stb.) is rögzítjük.
Ebben az adatbázisban a Rendszám fogadható el legjobban azonosítónak (ez bármelyik telephelyen vásárolt bármilyen márkájú, típusú autóra egyedi).
Tranzitív függőségekek: a Telephely Címe és Vezetője csak a Telephely nevétől függ, A Gyár neve a márkától, a Gyár címe és a Kapcsolattartó neve a Gyár nevétől, az Alapár, Teljesítmény, Fogyasztás, Űrtartalom és Férőhelyek száma a Típustól, az Ügyfél címe az Ügyfél nevétől, valamint az Extra ára az Extra meg-nevezésétől.
Az Extra megnevezése „*”-gal van megjelölve: ez funkcionálisan független a kulcstól (egy adott Rendszámhoz több Extra is tartozhat).
Ezeknek az anomáliáknak (redundanciáknak) a megszüntetésére a táblát szét kell bontani a korábbiakban említett módszerek szerint
Van még valahol függés?
IGEN! :)
Az EXTRÁK táblában maradt még egy tranzitív függés: az Ár nem a Rendszámtól (mint kulcstól), hanem a Megnevezéstől függ. Ezért ezt a táblát még bontani kell (felismerhető a több-több kapcsolat is az AUTÓK és az EXTRÁK között, aminek a feloldásához minden esetben harmadik tábla kell).
Az utolsó lépés az adatbázis tömörítése lesz: azokat a mezőket, amik a kapcsolatok miatt ismétlődnek, kódokkal helyettesítjük (Telephely neve, Ügyfél neve, Extra megnevezése) (a Típust nem kell kóddal helyettesíteni, mert az maga is egy rövid azonosító szokott lenni)
Feldolgozás
Feladat 2.
Egy biztosítónak több fiókja van az országban. Bármely ügyfél bármely fióknál köthet különböző biztosításokat. A biztosításokat az egész cégen belül egyedi kötvényszám azonosítja. A biztosítás díja a típusától függ. Ha kár történik, tudni kell a káresemény időpontját, leírását, értékét, valamint, hogy melyik biztosításon belül történt.
Egy biztosításon belül több káresemény is történhet.
EZ ÍGY JÓÓÓÓ?
Sportklubokat tartunk nyilván. Minden klub több sportággal foglalkozik (de nem minddel). Minden sportágnak klubonként megvan az edzője, valamint tároljuk az adott sportágban játszók átlagjövedelmét klubonként, és azt a klubot, amelyik az adott sportágban jelenleg a legjobb. Feltehetjük, hogy egy klubon belül sportáganként csupa különböző nevek vannak. A kluboknak elnöke van; egy személy több klub elnöke is lehet. Egy sportoló csak egy klubban és egy sportágban szerepel.
3. feladat
Alakitsatok ki egy 0. normálformás modellt!
Feladat
majd alakítsátok 3. normálformára!
3. feladat megoldása
Full transcript