Adatbáziskezelés

(Kiss Beáta 2025/2026)

1. Mi az adatbázis?

Az adatbázis az egymással kapcsolatban álló, összetartozó tárolt adatok összessége.
Az adatbázis célja, hogy hatékonyan tárolja, kezelje és szolgáltassa az adatokat különböző alkalmazások és felhasználók számára.

Jellemzői:

• Adattárolás: az adatokat strukturált formában tárolják - táblákban, rekordokban vagy fájlokban.
• Adatkezelés: az adatokat kezelik - frissítik, törlik, vagy új adatokat adnak hozzá.
• Adatlekérdezés: az adatokat lekérdezik, a felhasználók vagy alkalmazások igényeinek megfelelően.
• Adatvédelem: az adatokat védik - hozzáférés-szabályozással, titkosítással vagy más biztonsági intézkedésekkel.

Az adatok nem feltétlenül számítógépen kerülnek tárolásra, gondoljunk például a könyvtári kartoték rendszerekre. Az adatbázisok mellé egy adatbáziskezelő rendszer (DBMS - Database Management System) is társul, amely az adatbázis vagy adatbázisok üzemeltetését biztosítja. Elektronikus adatbázisok esetén ez valamsilyen szoftver.

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.

Ilyen modellek:

• Hierarchikus
  A hierarchikus modell volt a legelső az adatbáziskezelőkben. Az adatokat egy hierarchiában rendezni el, melynek szerkezete leginkább egy fastruktúrához hasonlít, amelyet gráffal adunk meg.
  Az adatbázis több egymástól független fából állhat, ahol a fa csomópontjaiban és leveleiben helyezkednek el az adatok. A közöttük lévő kapcsolat pedig szülő - gyermek kapcsolatnak felel meg. Így csak 1:n típusú kapcsolat képezhetők le segítségével. ( Az 1:n kapcsolat azt jelenti, hogy az adatszerkezet egyik típusú adata a hierarchiában alatta elhelyezkedő egy vagy több más adattal áll kapcsolatban.)
  A hierarchikus adatmodell alkalmazására jó példa a családfa vagy a főnök-beosztott viszonyok leírása.

• Hálós
  A hálós adatmodell szerkezetét is gráffal adjuk meg. A csomópontok az egyedeket, míg az élek az egyedek közötti kapcsolatokat jelentik. Egy csomópontból tetszőleges számú él indulhat ki, de egy él csak két csomópontot köthet össze. Minden adategység tetszőleges más adategységekkel lehet kapcsolatban, így n:m típusú adatkapcsolatok is leírhatók az 1:n típusúak mellett.
  

• Relációs
  A relációs adatmodell az egyik legáttekinthetőbb és a 80-as évektől kezdve a legelterjedtebb modell. Kidolgozása E. F. Codd (1923-2003) nevéhez fűződik. Az adatokat táblázatokban tároljuk, itt nincsenek előre definiált és tárolt kapcsolatok az egyes adategységek között, hanem csak a kapcsolatok létrehozásához szükséges adatokat tároljuk. Ezzel egy sokkal rugalmasabb és általánosabb szerkezetet kapunk.

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

2. Relációs adatbázisok alapfogalmai

A relációs modell előnyei:

• A relációs adatszerkezet egyszerűen értelmezhető a felhasználók és az alkalmazás készítők számára is.
• 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 egyértelműen és világosan elvégezhető.

Alapfogalmak

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

Tábla
Egy tábla az egyedek leírását tartalmazza soronként. A táblázat minden sorban egy egyedet ír le.
A táblákat mindig egyedi névvel látjuk el.
A táblák oszlopaiban azonos mennyiségre vonatkozó adatok jelennek meg. Az oszlopok névvel rendelkeznek, melyeknek a táblán belül egyedieknek kell lenniük, de más táblák tartalmazhatnak azonos nevű oszlopokat.
A tábla soraiban tároljuk a logikailag összetartozó adatokat. A tábla sorainak sorrendje közömbös, de nem tartalmazhat két azonos adatokkal kitöltött sort.

Relációs adatbázisok esetén a logikailag összetartozó adatokat egy táblában tároljuk. A táblában lévő oszlopokat attribútumoknak, a sorokat pedig rekordoknak nevezzük.

Mező
Egyetlen tulajdonság, egy sor és oszlop metszetében található táblázat elem. A mezők tartalmazzák az adatokat. A mezőkben oszloponként különböző típusú (numerikus, szöveges stb.) mennyiségek tárolhatók.

Azonosító
Olyan mező, amely egy példányt, vagyis 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 gyártmány vagy az évjárat nem lehet egyedi azonosító, mivel ismétlődhet, vagyis lehet két járműnek azonos márkája vagy évjárata.

A rendszám 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.

Idegen kulcs

Az idegen kulcs egy másik táblában szerepel elsődleges kulcsként. Az adott táblában nem elsődleges kulcs. 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 csoportot, amelynek tagjai szeretnének egy közös buszos kirándulást tenni, a jegyet pedig már előre megváltották. Egyik táblában nyilván tartjuk kik a csoport tagjai, a másikban pedig ki az aki már vásárolt jegyet, melyik ülést foglalta le stb.
A jegyek táblában, az Utas mezőben, azt tartjuk nyilván, hogy mi az azonosítója a másik táblában annak a csoport tagnak, aki vásárolta a jegyet. Az Utas mező tehát egy speciális mező, amelyben más táblák elsődleges kulcsai szerepelenek. Ezért az Utas mező a Jegyek táblában az idegenkulcs.

A két tábla valahogy így néz ki:

Csoport:

Jegyek:

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

A példában a név mező nem alkalmas egyedi azonosítónak, a Név és az Anyja neve mezők összetett kulcsként azonban be tudnak azonosítani egy konkrét rekordot.

Pótkulcs (surrogate key)

Az előző, összetett kulcsos példában a név nem tekinthető egyértelmű azonosítónak (mivel a név nem egyedi, másnak is lehet ilyen neve), ezért bevezettünk egy összetett kulcsot a név és az anyja neve mezőkre.

A másik lehetőség egy rekord azonosítására a pótkulcs bevezetése:

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

Néhány relációs adatbázis-kezelő:

Ha egy adatbázis-rendszer relációs, akkor használhatjuk a RDBMS (Relational Database Management System) rövidítést is.

NoSQL típusok:

A NoSQL adatbázisok olyan adatbázisok, amelyek nem a hagyományos relációs adatbázis modelleket használják, hanem inkább saját, speciális adatmodelleket.

A NoSQL adatbázisok típusai:

1. Dokumentum-orientált adatbázisok:
   JSON-szerű dokumentumokban tárolja az adatokat. (MongoDB, Couchbase, Firebase Firestore)
2. Kulcs-érték páros adatbázisok:
   Gyors és hatékony adattárolást biztosít. (Redis, Riak, DynamoDB)
3. Column-store adatbázisok:
   Nagy mennyiségű adatot tárol és gyors lekérdezéseket biztosít. (Cassandra, HBase, Bigtable)
4. Grafikus adatbázisok:
   Gráfokban tárolja az adatokat. (Neo4j, Amazon Neptune, ArangoDB)
5. Idősoros adatbázisok:
   Időbélyeggel ellátott adatokat tárol. (InfluxDB, OpenTSDB, TimescaleDB)
6. Objektum-orientált adatbázisok:
   Objektumokban tárolja az adatokat. (ObjectDB, OrientDB, Matisse)

Ezek csak néhány példa a NoSQL adatbázisok típusaira. Minden típusnak megvannak a saját előnyei és hátrányai és a választás függ a konkrét igényektől és követelményektől.

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

Heterogén DBMS rendszerek:
A heterogén DBMS rendszerek olyan hálózatok, amelyek több, különböző típusú adatbázist és rendszerkezelő rendszert integrálnak egy egységes, átfogó rendszerbe.
Ezek a rendszerek lehetővé teszik a különböző forrásokban tárolt adatok elérését és kezelését, beleértve a különféle operációs rendszereket, hálózati architektúrákat és adatbázis-típusokat is.

A heterogén rendszerek integrálják a különálló, eltérő technológiát használó adatbázisokat.

Főbb jellemzők:

• Támogatják a különböző típusú adatbázisok (pl. relációs, nem-relációs) összekapcsolását.
• Képesek adatokat cserélni különböző rendszerek között, például az XML formátum használatával.

Előnyök:
Lehetővé teszik a szervezet számára, hogy kihasználja a meglévő, különálló adatbázisok előnyeit, miközben egységes hozzáférést biztosítanak a teljes adathalmazhoz.

A relációs adatbázis

A relációs adatszerkezet számunkra a legszemléletesebben igyekszik megjeleníteni az adatokat.
Jellemzői:

• táblákkal dolgozzunk
• a táblák között kapcsolatok (relációk) vannak
• minden táblának van neve
• a táblában minden mező egyedi
• minden egyedről ugyanazt tartjuk nyilván
• egy táblában nincs két azonon sor

A fentiek alapján kimondható, hogy:
A relációs adatbázis olyan adatbázis, amelyben az adatok névvel ellátott táblákba vannak rendezve, és kapcsolatok révén állnak összeköttetésben egymással.

A relációs adatbázisban az azonosítókat elsődleges kulcsnak nevezik.
A fenti jármű példában elsődleges kulcs lehet a rendszám, mert biztosan nem lesz két olyan kocsi, aminek megegyezik a rendszáma.

Kapcsolatok:
Az adatokat általában több táblában tároljuk, ezért meg kell határoznunk, hogy a táblák között milyen kapcsolatok vannak.

Például egy anyának több gyereke is lehet. Mivel az anyának több gyereke is lehet, de egy gyereknek csak egy anyukája lehet, ezért 1:n-hez (egy a többhöz) kapcsolat van köztük.

Lehetséges kapcsolatok:

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

3. Adatbázistervezés

Az adatbázistervezés egy folyamat, amely több lépésből tevődik össze.

A tervezés lépései:

1. rendszer elemzés
2. rendszerterv
3. fizikai szint

Először meghatározzuk az adatbázissal szembeni igényeket, a tárolandó adatokat és az adatok közötti kapcsolatokat. Ezután következik a rendszer tervezése, melynek eredménye az adatbázis logikai modellje. Végül az adatbázis logikai modelljét leképezzük fizikai szinten.

Adatok közötti funkcionális kapcsolat

Funkcionális kapcsolatról akkor beszélünk, ha egy tábla egyik oszlopának (vagy oszlopainak) értéke meghatározza egy másik tábla egy másik oszlopának (vagy oszlopainak) értékét.

Például:

Egy Rendelés tábla és egy Ügyfél tábla között funkcionális kapcsolat van, ha a Rendelés tábla ÜgyfélID oszlopa hivatkozik az Ügyfél tábla ÜgyfélID oszlopára.

A funkcionális kapcsolatokat a következőképpen jelöljük:

• Egy-egy (1:1) kapcsolat: Egy sor az egyik táblában egy sorral van kapcsolatban a másik táblában.
• Egy-több (1:N) kapcsolat: Egy sor az egyik táblában több sorral van kapcsolatban a másik táblában.
• Több-több (N:M) kapcsolat: Egy tábla több sora van kapcsolatban egy másik tábla több sorával.

A funkcionális függőség (angolul: functional dependency) azt jelenti, hogy egy attribútum vagy attribútumcsoport függ egy másik attribútumtól vagy attribútumcsoporttól.

Formálisan:

Egy attribútum (B), funkcionálisan függ egy másik attribútumtól (A), ha:

• Minden A-hoz tartozó értékhez egyértelműen hozzárendelhető egy B érték
• Az A-ból következő B értékek között nincs redundancia

Jelölése: A → B

Például:

Tegyük fel, hogy van egy Ügyfél tábla a következő oszlopokkal:

ÜgyfélID, Név, Cím

Ebben az esetben a Név és Cím attribútumok funkcionálisan függnek az ÜgyfélID-től, mert az ÜgyfélID egyértelműen meghatározza a Név és Cím értékét.

A funkcionális függőség fontos az adatbázistervezésben, mert segít meghatározni a táblák szerkezetét és az attribútumok közötti kapcsolatokat.

A teljes funkcionális függőség (angolul: full functional dependency) azt jelenti, hogy egy attribútum vagy attribútumcsoport teljes mértékben függ egy másik attribútumtól vagy attribútumcsoporttól.

Formálisan:

Egy attribútum (B), teljes mértékben függ egy másik attribútumtól (A), ha:

• B függ A-tól (azaz A → B)
• A → B, és nincs olyan A részhalmaza, amelytől B függ

Például:

Tegyük fel, hogy van egy Rendelés tábla a következő oszlopokkal:

RendelésID, ÜgyfélID, TermékID, MegrendeltMennyiség

Ebben az esetben a MegrendeltMennyiség attribútum teljes mértékben függ a RendelésID, ÜgyfélID és TermékID attribútumoktól, mert a MegrendeltMennyiség értéke csak ezen attribútumok együttes értékétől függ.

Adatok közötti többértékű függőség

A többértékű függőség (angolul: multi-valued dependency) egy olyan függőségtípus, amely akkor fordul elő, ha egy tábla egyik oszlopának (vagy oszlopainak) értéke több értéket határoz meg egy másik oszlopban.

Ha egy táblában az A oszlop értéke meghatározza a B oszlop értékét, de a B oszlop értéke nem egyedi, hanem több értéket is tartalmazhat, akkor töbértékű függőségről beszélünk.

Jelölése: A →→ B

Például:

Tegyük fel, hogy van egy Termék tábla a következő oszlopokkal:

TermékID, TermékNév, Kategória

Ha egy terméknek több kategóriája is lehet (pl. egy termék lehet elektronikai cikk és ajándék is), akkor a TermékID →→ Kategória töbértékű függőség.

Tranzitív függőségnek nevezzük azt a helyzetet, amikor egy tábla egyik oszlopának (vagy oszlopainak) értéke függ egy másik oszlop értékétől, amely viszont függ egy harmadik oszlop értékétől.

Formálisan:

Ha A → B és B → C, akkor A → C tranzitív függőség.

Például:

Tegyük fel, hogy van egy Rendelés tábla a következő oszlopokkal:

RendelésID, ÜgyfélID, ÜgyfélNév

Ebben az esetben az ÜgyfélID → ÜgyfélNév függőség tranzitív, mert az ÜgyfélNév valójában az ÜgyfélID-től függ, nem közvetlenül a RendelésID-től.

A függőségek problémája az, hogy redundanciát és inkonzisztenciát okozhatnak az adatokban. Ezért az adatbázistervezés során törekszünk arra, hogy a függőségeket megszüntessük, vagyis a táblákat úgy tervezzük, hogy ne tartalmazzanak függőségeket. A függőségek megszüntetését a táblák normalizálással érhetjük el.

Relációk

Általános formája:

reláció_név = ({attribútumok},{funkcionális függőségek listája}) 

A reláció táblázatos megadása:

Matematikai jelöléssel a következő formában írható le a funkcionális függőségekkel együtt (feltételezve, hogy mindenkinek csak egy munkahelye van):

SZEMELYEK = ({SZEMELYI_SZAM, NEV, MUNKAHELY}, {SZEMELYI_SZAM -> NEV, SZEMELYI_SZAM -> MUNKAHELY})

Reláció kulcs

A reláció kulcs a reláció egy sorát egyértelműen azonosítja. A reláció 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

• csak egy sort azonosítanak (egyértelműség)
• a kulcsban szereplő attribútumok egyetlen részhalmaza sem alkot kulcsot
• értéke nem lehet definiálatlan (NULL)

A kulcsok nem önkényes döntések alapján alakulnak ki, hanem az adatok természetéből következnek, mint a funkcionális vagy a többértékű függőség.

A relációban külső kulcsot vagy kulcsokat is megkülönböztetünk. Ezek az attribútumok nem az adott relációban (táblában), hanem az adatbázis másik relációjában alkotnak kulcsot.

Például ha a SZAKKOR relációban a DIÁK azonosítására a személyi számot alkalmazzuk, akkor ez egy külső kulcs a személyi adatokat nyilvántartó relációhoz.

Redundancia

A redundancia azt jelenti, hogy egy adat több helyen is tárolásra kerül az adatbázisban. Ez történhet szándékosan vagy szándékolatlanul. A szándékos redundancia esetén a tervező szándékosan duplikálja az adatokat, hogy bizonyos helyzetekben javítsa a teljesítményt vagy a megbízhatóságot. A szándékolatlan redundancia viszont általában a tervezési hibákból adódik, és problémákat okozhat, például az adatok inkonzisztenciáját. Az adatok inkonzisztenciája azt jelenti, hogy az adatok között ellentmondások vagy eltérések vannak.

A redundancia típusai:

• Adat duplikáció: Az adatok ismétlődnek az adatbázis különböző részein.
• Funkcionális függőség: Egy attribútum vagy attribútumok egy másik attribútumtól függnek.

A redundancia milyen problémákat okozhat?:

• Adatintegritási problémák: Az adatok módosításakor nehézségekbe ütközhet a konzisztencia fenntartása.
  Az adatintegritás az adatbázis tervezésben azt jelenti, hogy az adatok pontosak, következetesek és megbízhatóak. Ez magában foglalja az adatok helyességét, teljességét, valamint az adatok közötti kapcsolatok konzisztenciáját.
• Tárolási kapacitás pazarlása: A redundáns adatok több helyet foglalnak el.

Példa redundanciára:

A fenti relációban a tantárgyak össz óraszámát annyiszor tároljuk, ahány tanár tanítja az adott tantárgyat. A példában feltételezzük, hogy egy tantárgyat több tanár is tanít. A redundancia a következő hátrányokkal jár:

• Több helyen kell módosítani a relációban, ha egy tantárgy össz óraszáma megváltozik.
• Ha bekerül egy új tanár a relációba, ugyanannak a tantárgynak az előző soraiból kell kivenni az össz óraszám adatot.

Vizsgáljuk meg a következő példát:

A táblázat a termék oszlopban többször tartalmazza a nyomtató és számítógép adatokat. Ez azonban nem okoz redundanciát, mivel egy termék több alkatrészből is állhat, így nem ugyanannak az adatnak a többszörös tárolásáról van szó, hanem egy másik adatot fejezünk ki, melyhez elengedhetetlen a duplikált tárolás. A duplikált és a redundáns adatok között a funkcionális függőségek vizsgálatával tehetünk különbséget.

Normalizálás

Az adatbázistervezésben a cél általában a redundancia minimalizálása és az adatok integritásának biztosítása. Ezt normalizálással érik el, amely magában foglalja az adatok szervezését és a táblák közötti kapcsolatok kialakítását úgy, hogy minimalizálják a redundanciát és biztosítsák az adatok konzisztenciáját.

A normalizálás során az adatbázist több lépésben alakítják át, hogy az adatok szervezése megfeleljen bizonyos szabályoknak.
Ezek a szabályok biztosítják, hogy az adatok:

• Egyértelműen azonosíthatók legyenek: Minden adatnak egyértelmű azonosítója legyen.
• Ne tartalmazzanak redundanciát: Az adatok ne ismétlődjenek.
• Könnyen frissíthetők legyenek: Az adatok könnyen frissíthetők legyenek anélkül, hogy más adatok módosítására lenne szükség.

A normalizálás hátrányai:

• Összetettebb táblakapcsolatok: A normalizálás során a táblák közötti kapcsolatok összetettebbek lehetnek.
• Több tábla: A normalizálás során több tábla keletkezhet.

A leggyakrabban használt normalizálási formák:

1. Első normál forma (1NF)

   Egy tábla akkor van első normál formában, ha minden sorában csak egyszerű értékek vannak, azaz nem lehetnek összetett értékek vagy táblák.
   

   Példa:

   Tábla, amely nincs 1NF-ben:

   ID	Név	Telefon számok
   1	Kovács	123-456-7890, 987-654-3210

   Tábla, 1NF-ben:

   ID	Név	Telefon szám
   1	Kovács	123-456-7890
   1	Kovács	987-654-3210

2. Második normál forma (2NF)

   Egy tábla akkor van második normál formában, ha a tábla 1NF-en van és minden attribútum függ az elsődleges kulcstól.

   Példa:

   Tábla, amely nincs 2NF-ben:

   ID	Név	Cím	Város
   1	Kovács	123 Main St	Budapest

   Tábla, amely 2NF-ben van:

   ID	Név
   1	Kovács

   Cím ID	Cím	Város
   1	123 Main St	Budapest

3. Harmadik normál forma (3NF)

   Egy tábla akkor van harmadik normál formában, ha nincs tranzitív függőség és a tábla 2NF-ben van.

   Példa:

   Tábla, amely nincs 3NF-ben:

   ID	Név	Város	Ország
   1	Kovács	Budapest	Magyarország

   Tábla, amely 3NF-ben van:

   ID	Név	Város ID
   1	Kovács	1

   Város ID	Város	Ország
   1	Budapest	Magyarország

A normalizálási formák biztosítják, hogy az adatok szervezése megfeleljen bizonyos követelményeknek, és segítenek abban, hogy az adatbázis hatékonyan és megbízhatóan működjön.

További normál formák:

4. Boyce-Codd normál forma (BCNF)

   Egy tábla akkor van Boyce-Codd normál formában, ha minden attribútum függ az elsődleges kulcstól, és nincs tranzitív függőség, továbbá a tábla 3NF-ben van.

   A BCNF szigorúbb követelményeket támaszt, mint a 3NF, és biztosítja, hogy az adatok szervezése még hatékonyabb legyen.

   Példa:

   Tábla, amely nincs BCNF-ben:

   ID	Név	Osztály	Osztályvezető
   1	Kovács	Matematika	Smith
   2	Szabó	Fizika	Johnson

   Ebben a táblában az Osztályvezető attribútum függ az Osztály attribútumtól, nem pedig az ID vagy Név attribútumtól. Ez tranzitív függőséget jelent.

   Tábla, amely BCNF-ben van:

   ID	Név	Osztály
   1	Kovács	Matematika
   2	Szabó	Fizika

   Osztály	Osztályvezető
   Matematika	Smith
   Fizika	Johnson

   Ebben a példában a táblákat szétbontottuk úgy, hogy az Osztályvezető attribútum csak az Osztály attribútumtól függjön, és ne legyen tranzitív függőség. Így a tábla BCNF-ben van.

5. Negyedik normál forma (4NF)

   Egy tábla akkor van negyedik normál formában, ha nincs többértékű függőség és a tábla BCNF-ben van.

   Példa:

   Tábla, amely nincs 4NF-ben:

   ID	Név	Színek
   1	Kovács	piros, kék

   Tábla, amely 4NF-ben van:

   ID	Név
   1	Kovács

   ID	Szín
   1	piros
   1	kék

Források:

• http://www.agt.bme.hu/

• https://centroszet.hu/tananyag/adatbazis/

• https://szit.hu/doku.php?id=oktatas:adatbazis-kezeles:tananyag
• https://webiskola.hu/sql-ismeretek/az-adatbazis-kezeles-alapjai/
• https://www.guru99.com/hu/mysql-tutorial.html
• https://www.w3schools.in/mysql/