< Adatbázis-kezelés

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

Az adatbázis

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:

Az adatbázis az adatok rendszerezett gyűjteménye, amely valamilyen céllal történik.

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

Az adatbázisok osztályozása

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.

Történet

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

A relációs adatbázisok alapfogalmai

Egyed

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

Tábla

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.

Jármű
Rendszám	Gyártmány	Szín	Évjárat
ZBC-123	Opel	piros	2013
GAB-363	Ford	kék	2013
DBC-343	Fiat	fekete	2013
RBC-223	Opel	zöld	2013
SDC-243	Opel	fekete	2013

A táblákban tárolunk:

objektumokat

eseményeket

Rekord

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.

ABC-123	Opel	piros	2013

Mező

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

Márka
Opel
Ford
Fiat
Opel
Opel

Azonosító

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.

Rendszám	Márka	Szín	Évjárat
ZBC-123	Opel	piros	2013
GAB-363	Ford	kék	2013
DBC-343	Fiat	fekete	2010
RBC-223	Opel	zöld	2010
SDC-243	Opel	fekete	2013

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.

Idegen kulcs

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.

Összetett kulcs

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.

Táblák áttekintése

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

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

Pótkulcs

Angolosan surrogate key.

Legyen egy egyszerű szemelyek tábla:

szemelyek
szemelyiSzam	orszagKod	nev	foglalkozas
1199501081001	hu	Nagy János	kőműves
1197010051002	hu	Fizet Géza	pék
2198501081003	hu	Rol Antal	festő
1199501081004	hu	Badar Péter	rendőr
1198503301005	hu	Csipi Gergő	munkanélküli
1198801281006	hu	Erős István	pincér

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:

szemelyek
az	szemelyiSzam	orszagKod	nev	foglalkozas
1	1199501081001	hu	Nagy János	kőműves
2	1197010051002	hu	Fizet Géza	pék
3	2198501081003	hu	Rol Antal	festő
4	1199501081004	hu	Badar Péter	rendőr
5	1198503301005	hu	Csipi Gergő	munkanélküli
6	1198801281006	hu	Erős István	pincér

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

DBMS

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.

NoSQL

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.

Heterogén DBMS rendszerek

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

A relációs adatbázis

A relációs adatszerkezet

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:

A relációs adatbázis olyan speciális adatbázis, amelyben az adatok névvel ellátott táblákban vannak, amik kapcsolatok révén összeköttetésben állnak egymással.

Elsődleges kulcs

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.

Kapcsolatok

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

Tervezés

Lépések

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él meghatározása

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.

Elnevezések

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.

Példa adatbázis

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

Adatmodell

Egyed

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.

Tulajdonság

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.

A relációs adatmodellről

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:

<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="150" height="150"> <rect width="120" height="140" style="fill:none; stroke-width:2; stroke:rgb(0,0,80)"/> <polyline points="0,20 120,20" style="fill:none;stroke:rgb(0,0,80);stroke-width:2" /> <text x="25" y="15" style="">Jármű</text> </svg>

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.

<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="150" height="150"> <rect width="120" height="140" style="fill:none; stroke-width:2; stroke:rgb(0,0,80)"/> <polyline points="0,20 120,20" style="fill:none;stroke:rgb(0,0,80);stroke-width:2" /> <text x="35" y="15" style="font-weight: bold;">Jármű</text> <polyline points="0,40 120,40" style="fill:none;stroke:rgb(0,0,80);stroke-width:2" /> <text x="5" y="35" style="">Rendszám</text> <polyline points="0,60 120,60" style="fill:none;stroke:rgb(0,0,80);stroke-width:2" /> <text x="5" y="55" style="">Szín</text> <polyline points="0,80 120,80" style="fill:none;stroke:rgb(0,0,80);stroke-width:2" /> <text x="5" y="75" style="">Gyártmány</text> <polyline points="0,100 120,100" style="fill:none;stroke:rgb(0,0,80);stroke-width:2" /> <text x="5" y="95" style="">Évjárat</text> <polyline points="0,120 120,120" style="fill:none;stroke:rgb(0,0,80);stroke-width:2" /> <text x="5" y="115" style="">Hengerűrtartalom</text> </svg>

Kapcsolat ábrázolása az adatmodellben

Kapcsolatok vonalakkal

Konkrét példákban kapcsolat

Inkscape

Az adatmodellt rajzolhatjuk papír helyett Inkscape vektorgrafikus programmal.

Weboldal:

http://inkscape.org

Dia

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.

Kapcsolatok a Dia programmal

Egyéb lehetőség a Dia programmal

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

Demolition

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

Normalizálás

A normalizálásról

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.

Első normál forma

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

Második normálforma

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.

Harmadik normálforma

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.

Anomália

Beszúrási anomália

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

Törlési anomália

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

Módosításai anomália

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

A CD albumok adatbázis normalizálása

Kezdés

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:

Előadó	CD_cím	Kiadó	Zeneszám
Edda	Edda Blues	Warner Music	Minden sarkon álltam már, Egek felé kiáltottam, Ahová eljutok, A fémszívű fiú, Álom, Ahogy élsz, Elhagyom a várost
Edda	Best Of Edda '80-'90	Magneoton	A szellemvilág, Bűszke Sas Sirály, Egy álom elég, Száguldás, Megint egy balhé, Utolsó érintés
Deep Purple	Rapture of the Deep	Record Express	Money Talks, Girls Like That, Wrong Man
Sex Action	Jöhet bármi	Magneoton	Kicsit durva, A szerelem kell, Mennyit érsz, Napszemüveg

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.

ID	IDENTITY	AZ	AZONOSÍTÓ

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

cdAz	zeneszámAz	járműAz	személyAz	alkalomAz

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

CD
cdAz	előadó	cdcím	kiadó
1	Edda	Edda Blues	Warner Music
2	Edda	Best Of Edda '80-'90	Magneoton
3	Deep Purple	Rapture of the Deep	Record Express
4	Sex Action	Jöhet bármi	Magneoton
Zeneszám
zeneszámAz	zeneszámNév	zeneszámHossz	cdAz
1	Minden sarkon álltam már	00:04:35	1
2	Egek felé kiáltottam	00:03:52	1
3	Ahová eljutok	00:04:02	1
4	A fémszívű fiú	00:03:48	1
5	Álom	00:04:22	1
6	Ahogy élsz	00:03:48	1
7	Elhagyom a várost	00:04:05	1
8	A szellemvilág	00:05:01	2
9	Bűszke Sas	00:04:35	2
10	Sirály	00:04:27	2
11	Egy álom elég	00:04:42	2
12	Száguldás	00:04:25	2
13	Megint egy balhé	00:04:12	2
14	Utolsó érintés	00:03:48	2
15	Money Talks	00:03:52	3
16	Girls Like That	00:03:42	3
17	Wrong Man	00:04:02	3
18	Kicsit durva	00:04:01	4
19	A szerelem kell	00:03:29	4
20	Mennyit érsz	00:03:55	4
21	Napszemüveg	00:04:22	4

Második normálforma

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:

CD
cdAz	cdCím	kiadó
1	Edda Blues	Warner Music
2	Best Of Edda '80-'90	Magneoton
3	Rapture of the Deep	Record Express
4	Jöhet bármi	Magneoton

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

Ami maradt a CD táblában:

CD
cdAz	cdCím
1	Edda Blues
2	Best Of Edda '80-'90
3	Rapture of the Deep
4	Jöhet bármi

Harmadik normálforma

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:

Egy zeneszám több CD-én

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:

Fizikai tervezés

Szabályok bevezetése

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

Szabályok:

minden egyed egy tábla

minden tulajdonság egy mező

minden egyedi azonosító elsődleges kulcs

minden kapcsolat egy idegen kulcs

táblanevekben és mezőnevekben az ékezetek és a szóközök eltűnnek

Idegen kulcsok felvétele

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

Eredmény adatmodellben

A táblák típusairól általában

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

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.

A CD adatbázis MySQL-ben

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:

Táblanév	Mezőnév	Típus	Kulcs
Eloado	eloadoAz	int	elsődleges kulcs
eloadoNev	varchar(50)
Táblanév	Mezőnév	Típus	Kulcs
Zeneszam	zeneszamAz	int	elsődleges kulcs
zeneszamCim	varchar(50)
zeneszamHossz	time
eloadoAz	int	idegen kulcs
Táblanév	Mezőnév	Típus	Kulcs
Zeneszam_CD	zeneszamAz	int	idegen kulcs
cdAz	int	idegen kulcs
Táblanév	Mezőnév	Típus	Kulcs
CD	cdAz	int	elsődleges kulcs
cdCim	varchar(50)
kiadoAz	int	idegen kulcs
Táblanév	Mezőnév	Típus	Kulcs
Kiado	kiadoAz	int	elsődleges kulcs
koadoNev	varchar(50)

Eredmény tartalommal

CD
cdAz	cdCim	kiadoAz
1	Edda Blues	1
2	Best Of Edda '80-'90	2
3	Rapture of the Deep	3
4	Jöhet bármi	2
Eloadok
eloadoAz	eloadoNev
1	Edda
2	Deep Purple
3	Sex Action
Kiadok
kiadoAz	kiadoAz
1	Warner Music
2	Magneoton
3	Record Express
Zeneszam
zeneszamAz	zeneszamNev	zeneszamHossz	cdAz	eloadAz
1	Minden sarkon álltam már	00:04:35	1	1
2	Egek felé kiáltottam	00:03:52	1	1
3	Ahová eljutok	00:04:02	1	1
4	A fémszívű fiú	00:03:48	1	1
5	Álom	00:04:22	1	1
6	Ahogy élsz	00:03:48	1	1
7	Elhagyom a várost	00:04:05	1	1
8	A szellemvilág	00:05:01	2	1
9	Bűszke Sas	00:04:35	2	1
10	Sirály	00:04:27	2	1
11	Egy álom elég	00:04:42	2	1
12	Száguldás	00:04:25	2	1
13	Megint egy balhé	00:04:12	2	1
14	Utolsó érintés	00:03:48	2	1
15	Money Talks	00:03:52	3	2
16	Girls Like That	00:03:42	3	2
17	Wrong Man	00:04:02	3	2
18	Kicsit durva	00:04:01	4	3
19	A szerelem kell	00:03:29	4	3
20	Mennyit érsz	00:03:55	4	3
21	Napszemüveg	00:04:22	4	3

Adatvédelem

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

Függelék

Adatbázismodellező módszerek

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)

Normálformák

1NF

2NF

3NF

4NF

5NF

Byce-Codd

tartomány-kulcs

Irodalom

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)

Forrás

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.