Gyakorlati alapok III.
SQL (adatbázis)
A relációs adatbázis alapjellemzői
Ebben a fejezetben részletezzük a relációs adatbázis azon jellemzőit, amelyek megértése feltétlenül szükséges a JDBC (vele az SQL) hatékony működtetéséhez, kódolásához.
A reláció fogalma az
előző
fejezetben voltaképpen már tisztázásra került. Itt más kiegészítő
adatokkal a fogalmat újradefiniáljuk, hogy belőle további következtetéseket
vonjunk le. Elöljáróban megjegyezném, hogy lehetséges a relációhoz
halmazelmélettel, tágabb értelemben matematikával is közelíteni, amelyet annak
túl specifikus volta miatt most nem teszünk meg.
Adott 3 személy a maguk alapadataikkal:
-
Kiss Sándor – 1954.01.23. - Apró Jolán
-
Fellegi Tamás – 1985.12.04. - Fekete Margit
-
Nagy Tibor – 1990.04.30. - Demeter Zsófia
Nem nehéz felfedeznünk az adatok
mögött meghúzódó általánosításokat (tulajdonnév, születési idő, anyja neve).
Ez a néhány alapadat azonban senkit nem érdekel, talán csak magukat a
személyeket és akkor is csak a sajátjuk. Ha azonban ez a 3 személy része
ugyanazon dolgozói kollektivának, akkor munkáltatójuknak már kifejezett érdeke
lehet, hogy ezen és más, számára lényeges adatok általánosításaiból olyan
adatbázist alkosson, amelyik hűen, naprakészen tükrözi a cég belső és külső
állapotait. Ebből következően ez a 3 személy már egy relációs adatbázist
alkot, mert közöttük van legalább 1 olyan kapcsolati pont, amelyet relációnak
minősíthetjük, ez pedig 1 cégnél lévő közös, dolgozói státusz. (Természetesen
a 3 személy között további kapcsolódási pontok is vannak, például magyarok,
férfiak, élőlények, stb., ezt szándéktól függően más, adatbázist építő
entitások szintén felhasználhatják.)
Nézzük meg tehát ezt az egyszerű dolgozói adatbázist:
NYILVÁNTARTÁS
|
Tulajdonnév |
Születési idő |
Anyja neve |
| Kiss Sándor | 1954.01.23. | Apró Jolán |
| Fellegi Tamás | 1985.12.04. | Fekete Margit |
| Nagy Tibor | 1990.04.30. | Demeter Zsófia |
Amint látható, a relációs adatbázis mindig tábla (vagy más elnevezésben
táblázat) szerkezetű (table) és mint ilyen, oszlopokból és sorokból
áll.
A tábla oszlopai alkotják az adatbázis attribútumait. Az attribútum olyan jellemző, amelyre éppen szükségünk van a való világ vagy helyzet pontos modellezéséhez (itt dolgozói jogviszonyhoz szükséges általánosítások).
Természetesen a fenti 3 személynek további attribútumai is léteznek, ám ezek most nem lényegesek.
Az attribútumot szokták még oszlopnévként, illetve mezőként is definiálni.
Az attribútumok (oszlopok) számát a reláció fokának, a sorok számát pedig a
reláció számosságának nevezzük.
Az attribútumok sokaságát, amelyekből a konkrét atttribútomokat kiválasztjuk,
tartományoknak (domain) nevezzük. Ilyen például a Név tartomány.
Igen sokféle neve lehet a dolgoknak, ám itt most számunkra csakis a
tulajdonnév fontos, amely fogalmakat tehát a Név tartományból hasítunk
ki az adatbázis számára.
Vegyük észre, hogy már ez az egyetlen, egyszerű tábla is relációs adatbázist
alkot, hiszen további oszlopokkal és sorokkal bővítve alapjában véve megfelelő
egy cég adatbázisának. Azonban a gyakorlat mást mutat: már egy viszonylag
egyszerű adatbázisnál is attribútumok sokasága keletkezik, olyannyira, hogy
érdemes őket külön táblázatokba rendezni. Gondoljunk például a dolgozók
prémiumának könyvelésére! Vajon ésszerű volna-e ezt a fenti táblába tenni?
Valójában nem, hiszen 1 dolgozó kaphat többször is prémiumot, amit egyetlen
tábla esetén így volnánk kénytelenek könyvelni:
NYILVÁNTARTÁS
|
Tulajdonnév |
Születési idő |
Anyja neve |
Prémium |
| Kiss Sándor | 1954.01.23. | Apró Jolán | |
| Fellegi Tamás | 1985.12.04. | Fekete Margit | 50000, 10000 |
| Nagy Tibor | 1990.04.30. | Demeter Zsófia | 5000 |
Láthatóan ekkor a Prémium attribútum alá 1 sorba 2 érték is kerül, ami
az adatbázis tervezése szempontjából nem optimális. (Ezt a tervezői folyamatot
nevezzük az adatbázis normalizálásának, másnéven normálformára hozásnak; a
jelen jegyzet -a fenti példát kivéve-, a normalizálási lépésekkel nem
foglalkozik.)
Az optimális lépés tehát 1 külön, PRÉMIUM nevű tábla létrehozása:
PRÉMIUM
|
Tulajdonnév |
Összeg |
Dátum |
| Fellegi Tamás | 50000 | 2015.04.23. |
| Fellegi Tamás | 10000 | 2017.05.01. |
| Nagy Tibor | 5000 | 2016.10.30. |
Ez a különálló tábla tehát az optimális lépésnek tűnik, de semmi értelme
nincs, ha nincs kapcsolata az előző, NYILVÁNTARTÁS nevű táblával. A kötelező
kapcsolatot most a Tulajdonnév attribútum biztosítja. De vajon ez
egyértelműen azonosítja a kapcsolatot? Azt gondolhatnánk, hogy igen, egészen
addig, amíg a sors különös fintoraként a cég nem venne fel még egy Fellegi
Tamás nevű munkavállalót. Láthatjuk tehát, hogy már a NYILVÁNTARTÁS nevű tábla
sem optimális...
|
Tulajdonnév |
Születési idő |
Anyja neve |
| Kiss Sándor | 1954.01.23. | Apró Jolán |
| Fellegi Tamás | 1985.12.04. | Fekete Margit |
| Nagy Tibor | 1990.04.30. | Demeter Zsófia |
...mert egyik attribútum sem azonosítja egyértelműen az entitást (bár lehetséges, hogy több már igen).
A megoldás egy olyan attribútum bevezetése, amelyik mindig egyértelmű azonosítást képes biztosítani. Az ilyen attribútumot kulcsnak nevezzük.
Egészítsük tehát alaptáblánkat egy kulccsal (Dolg.azonosító):
NYILVÁNTARTÁS
|
Dolg.azonosító |
Tulajdonnév |
Születési idő |
Anyja neve |
| 0001 | Kiss Sándor | 1954.01.23. | Apró Jolán |
| 0002 | Fellegi Tamás | 1985.12.04. | Fekete Margit |
| 0003 | Nagy Tibor | 1990.04.30. | Demeter Zsófia |
Kulcsot nemcsak 1, hanem több attribútum is alkothat. Az előbbi esetet
egyszerű kulcsnak, az utóbbit összetett kulcsnak hívjuk. Sőt, a tábla összes
attribútuma szolgálhat kulcsként, amint a NYILVÁNTARTÁS táblában a kezdeti 3
oszlop (Tulajdonnév, Születési idő, Anyja neve)
egyértelműsíti a dolgozót. Egy táblának (relációnak) több kulcsa is lehet.
Ezután nincs más dolgunk, mint a NYILVÁNTARTÁS tábla kulcsát a PRÉMIUM táblába
illeszteni:
PRÉMIUM
|
Dolg.azonosító |
Összeg |
Dátum |
| 0002 | 50000 | 2015.04.23. |
| 0002 | 10000 | 2017.05.01. |
| 0003 | 5000 | 2016.10.30. |
Azt a kulcsot, amelyik egy másik táblában szintén kulcsot alkot, idegen vagy külső kulcsnak (foreign key) hívjuk.
Vegyük észre, hogy milyen lényeges lépés volt ez, hiszen enélkül:
-
vagy nem lett volna kapcsolat a 2 tábla között,
-
vagy az adatbázis nem lett volna normalizálva.
Általánosságban kijelenthetjük, hogy a relációs adatbázisok táblái közti (kulcsfontosságú) kapcsolatokat az egyedi attribútumok (kulcsok) jelentik. Ezek nélkül a legtöbbször több táblás adatbázisok nem válnak koherens egésszé, a táblák kapcsolat szempontjából egymástól függetlenek maradnak, azaz rajtuk komplex, több táblás lekérdezéseket, szűréseket sem lehet futtatni.
Pénzes László