Adatbázis-kezelés tananyag

• Szerző: Sallai András
• Copyright © 2011, Sallai András
• Szerkesztve: 2011-2021
• Licenc: CC BY-SA 4.0
• Web: https://szit.hu

Mit nevezünk adatbázisnak?

Ha abból indulunk ki, hogy maga a szó adat és bázis szavakból alkotott összetett szó, akkor valamilyen adathalmazra gondolhatunk, mint akár egy papírkupac. Ez alapján azt mondhatnánk, az adatbázis adatok gyűjteménye.

Persze, mi sokkal inkább a rendezett adathalmazokat tekintjük adatbázisnak, úgy mint egy könyvtár. Ha rendezettség igényét fenntartjuk, akkor adatbázis fogalmunkat továbbfejleszthetjük, és azt mondhatjuk az adatbázis az adatok rendszerezett gyűjteménye.

Az adatbázis fogalom kialakításánál figyelembe szoktuk venni a célokat is. Milyen céllal jött létre az adatbázis. Ezek után a végső adatbázis fogalmunk így néz ki:

Itt most, elektronikus adatbázissal foglalkozunk. Nézzük meg, mik a hátrányai a hagyományos, nem elektronikus adatbázisoknak.

Hátrányok:

• nagy helyigény
• nagy karbantartási igény

Itt most kifejezetten az elektronikus adatbázisokkal foglalkozunk. Az adatbázisoknak többféle modellje létezik.

Adat modellek:

• hierarchikus
• hálós
• relációs
• objektumorientált – újabb
• objektumrelációs – újabb

Ezekből mi, a relációs adatbázissal foglalkozunk.

1969-ben Dr. Edgar F. Codd, az IBM kutatója leírja a relációs adatbázis elvét.

Néhány adatbáziskezelő rendszer:

• System R – IBM
• INGRES (Interactive Graphics Retrieval System) – University of California
• Oracle – Oracle Corporation
• DB2 – IBM
• dBase – Ashton Tete – fájl alapú
• FoxPro – Fox Software – fájl alapú
• R:BASE – Microrim
• Paradox – Ansa sowtware

Az adatbázisainkban bizonyos dolgokról tartunk információkat. Egy-egy konkrét dolgot, amiről adatot tárolunk egyednek is szokás nevezni. Idegen szóval entitás.

entitás ≡ egyed

Egy tábla az egyedek leírásait tartalmazza soronként. A táblázat minden sorban egy egyedet ír le.

A tábláinknak mindig nevet kell adni. A tábla neve általában lehet többes számban, mivel több egyedet tartunk benne. De ne legyen rövidítés, legyen egyetlen szó, ha lehet.

A táblákban tárolunk:

• objektumokat
• eseményeket

Egy példány leírása, tulajdonképpen, annak tulajdonságai. Egy táblázatban ezek a vízszintes sorok.

Egy rekord, a példa kedvéért, leírhatja egy jármű tulajdonságait, úgymint egy jármű rendszáma, márkája, színe, évjárata stb.

Egyetlen tulajdonság, amit a táblázatban az oszlopok testesítenek meg.

Olyan mező, amely egy példányt, azaz egy rekordot egyértelműen azonosít.

Az azonosítóval szemben támasztott követelmények:

• nem változhat az értéke a példány teljes élettartama alatt
• egyedi legyen valamennyi rekordban
• értéke nem lehet NULL

Nézzük meg a járművek táblát. A márka, a szín vagy az évjárat nem lehet egyedi azonosító, mivel szó szerint nem egyediek. Másként szólva ismétlődhet, vagyis lehet két járműnek azonos márkája, színe vagy évjárata.

A rendszám esetleg alkalmas lehet, bár egy járművet a forgalomból kivonva újra forgalomba lehet helyezni. Az azonosító mezőt, kulcs mezőnek is hívjuk, illetve elsődleges kulcsnak.

Megjegyzések:

Személyek esetén a személyi szám alkalmas lehet egyéni azonosítónak, a személyigazolvány szám viszont nem, hiszen egy embernek időnként új igazolványt kap.

Az adott táblában nem elsődleges kulcs. Az idegen kulcs egy másik táblában szerepel elsődleges kulcsként. A másik tábla elsődleges kulcsa és az aktuális tábla idegen kulcsa alapján kötjük össze a táblákat. Az idegenkulcsok ebben a formában a táblák közötti kapcsolatot jelölik.

Vegyünk példaként egy olyan klubbot, amelynek tagjai szeretnénk a űrutazást tenni, a jegyet pedig jó előre megváltották. Egyik táblában nyilván tartjuk kik a klub tagjai, a másikban pedig ki az aki már vásárolt jegyet, mikorra szól a jegy stb. A két táblánk valahogy így nézhet ki:

A jegyek táblában, az Utas mezőben, azt tartjuk nyilván mi az azonosítója a másik táblában annak a klubtagnak, aki vásárolta a jegyet. Az Utas mező tehát egy speciális mező, amelyben más táblák elsődleges kulcsai szereplenek. Ezért az Utas mező a Jegyek táblában az idegenkulcs.

Az azonosító két vagy több mezőből áll.

Akkor használjuk, ha nincs olyan mező, amely alkalmas egyedi azonosítónak és valamiért nem szeretnénk ilyen mezőt létrehozni sem.

Nézzük meg mit tanultunk a táblákról.

A tábláknak vannak neveik, azokban mezők és rekordok vannak.

Angolosan surrogate key.

Legyen egy egyszerű szemelyek tábla:

A személyi számot nem tekinthetem egyértelmű azonosítónak, ha nyilvántartás az egész földre kiterjed (vagy több országra), mivel más országokban is lehet valakinek ilyen személyi száma. Az egyik lehetőség, hogy összetett kulcsnak használom a személyi számot és az országkódot.

A másik lehetőség pótkulcs bevezetése:

Az „az” mező értékei nem következnek a személyek adataiból, csak pótkulcsnak vettük fel.

Adatbázis-kezelő rendszer - Database Management System - DBMS

Adatbázis-kezelő rendszerek

• MS Access
• MS SQL
• MySQL
• MariaDB
• PostgreSQL
• H2DB
• MongoDB
• Redis

Ha egy adatbázis-rendszer relációs, akkor használjuk vele kapcsolatban a RDBMS rövidítést is, amely angolul: Relational DataBase Management System.

Típusok:

  gráf
  oszlop
  dokumentum
  kulcs-érték

A NoSQL adatbázisokat nem azért találták ki, hogy leváltsák az SQL-t. Az SQL öszetett feladatokban nagyon is jól teljesít. A NoSQL adatbázisokat akkor használunk, ha nincs szükség komplex lekérdezésekre.

A heterogén DBMS rendszerek között az adatcsere egyik lehetséges megoldása az XML.

A relációs adatszerkezet igyekszik úgy megjeleníteni számunkra az adatokat, hogy az a legszemléletesebb legyen.

Jellemzői:

• táblákkal dolgozunk
• a táblák között kapcsolatok vannak (relációk)
• minden táblának van neve
• minden mező egyedi a táblázatban
• minden egyedről ugyanazt tartjuk nyilván
• egy táblázatnak nincs két azonos sora

Ezek után megalkothatjuk a relációs adatbázis fogalmát:

Fentebb már beszéltünk az azonosítóról és most is erről lesz szó. A relációs adatbázisban az azonosítókat „Elsődleges kulcs” néven szokás említeni.

Ismételjük át az eddig tanultakat:

Egy táblázatban nem lehet két ugyanolyan sor. Ha két sor ugyanazt az egyedet szimbolizálná, akkor feleslegesen tároljuk két helyen. Ha az ismétlődő rekord egy másik egyedet ír le, akkor nem tudjuk melyik rekord melyik egyedhez tartozik. Ezért mindig szükség van egy olyan mezőre, amely biztosan nem ismétlődik, amely alapján egyértelműen azonosítható minden egyed. Nézzük meg a mezőket, melyik alkalmas erre a célra. Az így megjelölt mezőt elsődleges kulcsnak nevezzük.

A fenti jármű példában, (nem szigorúan véve) elsődleges kulcs lehet például a rendszám, mert biztosan nem lesz két olyan kocsi, amelynek rendszáma egyezik.

Az adatainkat általában több táblában tároljuk. Ezért meg kell határoznunk a táblák között milyen kapcsolatok vannak.

Például egy tulajdonosnak több kocsija is lehet. Az emberek és a kocsik között kapcsolat van. Mivel egy tulajdonosnak több kocsija is lehet, de egy kocsinak csak egy tulajdonosa lehet, ezért egy a többhöz kapcsolat van közöttük.

Azt néznénk meg ki vezeti a kocsit, akkor a személyek és a kocsik között már több a többhöz kapcsolat van. Hiszen egy kocsit több ember is vezethet, és egy ember több kocsit is vezethet.

Lehetséges kapcsolatok:

• egy a többhöz
• több a többhöz
• egy az egyhez

• logikai tervezés
  • cél meghatározása
  • miről szeretnénk adatokat tárolni - egyedek (entitások) megkeresése
  • milyen tulajdonságokat tárolunk
  • egyedi azonosítók meghatározása
  • normalizálás
  • tulajdonságok típusainak meghatározása
• fizikai tervezés

A célok meghatározása talán feleslegesnek tűnhet. Sokszor láttam már azonban, amint valaki adatbázis terveinél felesleges dolgoknak készített volna táblát, vagy mezőt. A célok meghatározása segíti a következő lépésben, ahol meg kell határozni milyen tulajdonságokat szeretnénk tárolni.

Ezért mindig fogalmazzuk meg, milyen célból hozzuk létre az adatbázist.

Fontos, hogy adatokat tartalmazó tábláinknak, azok mezőinek megfelelő neveik legyenek.

Nézzük meg a következő két táblát:

Az első táblában igen nehéz megállapítani mit is tárolunk, miről van szó. Ugyanaz a második táblában.

Nézzünk egy újabb adatbázist, ahol a CD lemezeinkről szeretnénk adatokat tárolni. Elsőre egy a következőhöz hasonló adatbázist állíthatunk össze:

A tábla tulajdonképpen mindent tartalmaz amire szükségünk lesz. A számok közötti keresés, azok karbantartása azonban nem egyszerű. Ha szeretnénk a számok hosszát is tárolni, az megint nehézkes. Probléma az is, hogy többször szerepel a táblázatban az Edda mint előadó és a Magneoton mint kiadó. Ha módosítani kell valamelyik nevet, akkor azt nagyon sok helyen kellene megtennünk.

A tervezés célja a fenti problémák megszüntetése. A zeneszámok nyilvántartása kezelhetetlen. Az előadókat és a kiadókat feleslegesen tároljuk többször. Úgy mondjuk: redundánsan tároljuk. A redundancia azt jelenti felesleg. Azt is mondjuk: az adatbázisunk redundáns.

A redundanciát mindig meg kell szüntetni. Az adatbázisunkat normálisabb állapotba kell hozzuk. A redundancia megszüntetése a normalizálás folyamata.

A fogalmi résznél már volt szó az egyedekről. Fogalmazzuk meg a tervezés szempontjából mi számunkra az egyed.

Az egyed egy olyan dolog vagy objektum, amiről adatokat szeretnék tárolni, mert számunkra jelentőséggel bír.

A tulajdonságokról (attribútumok) is volt fentebb szó. A tervezés során nekünk egyelőre az fontos, hogy a tulajdonság az egyeddel kapcsolatos információkat ír le.

Az adatmodell az adatbázis tervét szemléltető ábra. Nagyon megkönnyíti az adatbázis tervezést, ha tábláinkat lerajzoljuk. Az relációs adatmodell táblák és azok mezőinek rajzolatát értjük.

Általában egy téglalap egy táblát szemléltet, a téglalapot felosztjuk vízszintesen több részre, ezek lesznek a táblázat mezői (azon tulajdonságok amiket el szeretnénk tárolni).

Egy táblázat létrehozása úgy történik, hogy feltesszük a kérdést:

• Miről szeretnénk adatokat tárolni?

Vagyis meghatározzuk az egyedet.

Lehetséges válasz például: „járművek”

Ekkor létrehozunk egy táblát:

Az egyednek milyen tulajdonságait szeretnénk eltárolni?

Ezeket felírjuk a téglalapban a jármű alatt.

Szeretnénk eltárolni például a rendszám, szín, gyártmány, évjárat, hengerűrtalom.

Az adatmodellt rajzolhatjuk papír helyett Inkscape vektorgrafikus programmal.

Weboldal:

• http://inkscape.org

Adatbázismodell készítéshez program:

• http://dia-installer.de (Dia - diagramszerkesztő)

Az adatbázismodell készítéséhez a Dia programban a kiegészítő eszköztár választó legördülő listadobozban válasszuk a „Más lapok …” menüpontot. Az előugró almenüben válasszuk az „Adatbázis” menüpontot. Három eszköz jelenik meg a kiegészítő eszköztáron.

• Tábla
• Hivatkozás
• Összetett attribútumelem

A táblát létrehozhatunk két kattintással, de hogyan lesznek benne mezők? A táblán kattintunk jobb egérgombbal, amikor az ki van jelölve. A „Tulajdonságok” menüpontot választom. Az előugró ablak Attribútum fülén tudok mezőket felvenni értelemszerűen.

A Dia programban megadhatjuk az egyes mezők típusait is. Megjelölhetjük az elsődleges kulcsokat

A Demolition egy járműbontó, amely járművek eladásával is foglalkozik. Adatbázisuk demolition.

A normalizálás a redundancia megszüntetése.

Van egy redundáns CD adatbázisunk, nézzük meg, hogyan normalizálnánk.

Az adatbázis normalizálásnak jól meghatározott szintjei vannak. Úgyis mondjuk normálformákkal dolgozunk. Van első normál forma, második, harmadik stb.

Ha minden attribútumnak csak egy értéke van, és van elsődleges kulcsmező.

Ha már első normál formán van, és minden nem azonosító attribútum funkcionálisan függő viszonyban van az azonosító attribútummal.

A nem azonosító attribútumok tehát alá vannak rendelve az azonosító attribútumnak.

Ha már második normálformában van, és a nem azonosító attribútumok tranzitíven nem függnek más nem azonosító attribútumtól.

Másként: Minden nem azonosító attribútum nincs teljesen alárendelve más nem azonosító attribútumnak.

Ha egy új rekord beszúrása miatt egy már korábban beszúrt rekordot meg kell változtatni.

A törlés anomália esetén olyan adatok is törlődnek, ami nem volt célunk.

Módosítási anomália, ha egy adatot több helyen kell módosítani.

A normalizálást az adatmodellen legegyszerűbb elvégezni.

Ezért az adatmodellen keresztül mutatom be.

Mint láttuk az adatmodell elkészítésénél egyedeket keresünk, amelyekről információt akarunk tárolni.

Emlékeztetőül lássuk az eredeti adatbázist:

Fel kell tegyük tehát a kérdést. Miről akarunk információt tárolni. Jelen esetben az első válaszunk ez lehet: CD-ről.

Ezek szerint a CD egy egyed. Ennek megfelelően megrajzoljuk a jelenlegi adatbázismodult.

Az egyed nevét beírjuk téglalapunk tetejére. Az ábrán látható felsorolásjeleket a Dia program tette be, azokat nem kötelező berajzolni papíron.

Most írjuk be milyen tulajdonságokat akarunk tárolni.

Ha a tulajdonságok között nincs olyan ami egyértelműen azonosít egy egyedet, akkor létre kell hozni egy olyan tulajdonságot amely ezt megteszi. Létrehozunk ezért egy sorszám tulajdonságot, amelyet cdAz néven veszek fel:

Ha hozzáadunk a táblánkhoz egy egyedi azonosítót, akkor identity, vagy magyarul azonosító nevet adhatjuk neki. De lehet ezek rövid változata is.

Esetleg a tábl nevét a rövidítés elé tesszük:

A zeneszámAz több adatot is tartalmaz. Ez nem felel meg az első normálformának, ezért tennünk kell vele valamit. Újabb egyedet keresek. Megint feltesszük a kérdés, mit szeretnénk ebben a zeneszámAz tulajdonságban tárolni? Zeneszámokat. Ha valamiről információt szeretnénk tárolni, akkor az egyed lesz, vagyis külön táblába tehetjük.

Ebben a formában már a zeneszámok hossza is gond nélkül tárolható.

Most rajzoljuk be milyen kapcsolat van a két tábla között.

Az eredmény tartalommal együtt

Az előadók nincs teljesen függő viszonyban a CD tábla azonosítójával.

Amit tehetünk

• megkeressük az attribútum melyik egyedhez (táblához) tartozik
• VAGY újabb egyedet (táblát) hozunk létre

Külön táblába tesszük az előadókat

Berajzoljuk a kapcsolatokat:

Az Előadó és a CD tábla között több a többhöz kapcsolat van. A több a többhöz kapcsolatokat mindig meg kell szüntetni. A cél egy a többhöz kapcsolatok létrehozása.

Jelen esetben a táblák átrendezésével megoldhatjuk a kapcsolatok problémáját:

Ha nem tudjuk átrendezni a táblát, akkor létrehozhatunk egy kapcsolótáblát:

A CD tábla maradéka:

Külön táblába tesszük a kiadókat is.

Ami maradt a CD táblában:

Tegyük fel, hogy a kiadóról több információt szeretnénk tárolni.

Az ország és az országkód között tranzitív függőség van. Ezért külön táblába tesszük.

Az eredmény:

Ha azt is figyelembe vesszük, hogy egy zeneszám több CD-én is szerepelhet, akkor a Zeneszám és a CD tábla között több a többhöz kapcsolattal kell számolnunk. Erre megoldás lehet egy kapcsolótábla:

Elsőként néhány szabályt vezetünk be.

Szabályok:

1. minden egyed egy tábla
2. minden tulajdonság egy mező
3. minden egyedi azonosító elsődleges kulcs
4. minden kapcsolat egy idegen kulcs
5. táblanevekben és mezőnevekben az ékezetek és a szóközök eltűnnek

Az idegenkulcsot mindig a többesoldalon lévő táblába kell beilleszteni.

• szám
  • egész
  • valós
  • automatikus növelés
• szöveg
  • variálható hosszúság
  • fix hosszúság
• dátum
• logikai
• NULL

A NULL nem egyenlő a 0 szám értékkel. A 0 mennyiséget jelent, a NULL viszont azt jelenti nincs adatunk. Nem tudjuk milyen értéke van.

MySQL adatbázis-kezelő rendszerben a következő típusokat kell beállítanunk:

A típusok adatmodellben ábrázolva:

A típusok táblázatban:

Az adatok biztonsága két szempontból lehet kérdéses:

• Mi van, ha tönkre megy az adattároló és elvesznek az adatok?
• Mi van, ha illetéktelenek férnek az adatokhoz?

A modern adatbázis-kezelők mindkét problémához nyújtanak segítséget.

Az adatok elvesztése miatt az adatok exportálható, importálhatók. Az illetéktelen hozzáférés miatt az adatokhoz a hozzáférés, több szinten állítható felhasználókhoz köthető.

• EK
  • EK modell: Egyed-kapcsolat modell
  • ER model: Entity-relationship model
• Bachman-diagram
• Grafikus jelölés
• Szöveges leírás (relációséma)

• 1NF
• 2NF
• 3NF
• 4NF
• 5NF
• Byce-Codd
• tartomány-kulcs

• George Reese, Randy Jay Yarger, Tim King: A MySQL kezelése és használata (Kossuth, 2003)
• Michael J. Hernandez: Adatbázis-tervezés
• http://www.tankonyvtar.hu/hu (2017)
  • Szabó Bálint: Adatbázis fejlesztés és üzemeltetés I.
    • Böngészés → Könyvek → Alkalmazott tudományok →
    • Számítástechnika. Informatika.Adatbázisok. Térinformatika →
    • 4. oldal
  • Adatbázis fejlesztés és üzemeltetés
• Informatika (2017)
• http://vassanyi.ginf.hu/ab/tervezes/Video.htm (2017)
• http://www.agr.unideb.hu/ebook/szamitogephasznalat/adatbzis_adatmodellek.html (2017)

• A normalizálás CD adatbázison keresztül való bemutatásának ötlete a „A MySQL kezelése és használata” című könyvből van.