Adatmodell, mezőtulajdonságok, adattípusok, elsődleges kulcs és index (#27) – OK

Miről szól ez a cikk?
Most egy lépést teszünk az adatbázis belső felépítése felé, még mindig elméleti síkon mozogva – felsoroljuk a mezők jellemzőit, lehetséges típusaikat, megnézzük, mitől különlegesek, miért meghatározók egy adatbázis tábla életében. Megismerkedünk egy fontos mezőtípussal, az elsődleges kulccsal, és megértjük, hogyan gyorsítható fel a rekordok sorba rendezése és az adatok visszakeresése és szűrése indexeléssel. Röviden körbejárjuk az adatmodell fogalmát is.

1. A tervtől az adatmodellig

Korábban volt arról szó, hogy egy táblában egy objektumhoz vagy egyedhez kapcsolódó adatot tárolunk, illetve a mezőkben az egyedek tulajdonságait, attribútumait tároljuk: minden mezőben egy adatot.

Például, ha egy szervezet bútorleltárát tervezzük elkészíteni, akkor a legegyszerűbb esetben az adatokat egy adatbázis egy táblájában helyezzük majd el. Ebben a táblában kizárólag a bútorokkal kapcsolatos adatokat fogjuk elhelyezni, tehát a személyzeti adatoknak ebben a táblában semmi keresnivalójuk nem lesz. Így fog megvalósulni az az elv, hogy egy táblában csak egy objektum- vagy egyedtípushoz kapcsolódó adatot tárolunk.

A bútorleltár táblájában minden rekord egy-egy egyed, vagyis bútor adatait fogja tartalmazni. Nincs, nem lehet a táblában két vagy több rekord ugyanarról a bútorról. Előzetesen meghatározzuk, hogy a bútorokról milyen adatokat fogunk nyilvántartani a rekordokban, vagyis, hogy milyen mezőkre lesz szükségünk. A mezőknek nevet fogunk adni, és meghatározzuk adattípusukat és egyéb feltételeiket is, amelyekről később lesz szó. Egy mezőnek tehát minimum van neve és adattípusa. Ez egyben azt is jelenti, hogy egy mezőben kizárólag egy darab elemi adat lehet, amely a bútor egy adott tulajdonsága.

A táblában tehát minden rekordnak ugyanannyi mezője van, a mezők sorrendje ugyanaz, és minden mezőben egy darab adat van.

Mindezeket, az adatbázis és a tábla nevét, a mezőneveket, azok adattípusait és egyéb jellemzőit előre, az adatbázis tervezésekor kell meghatározni és elkészíteni. Az adatbázis tervezésekor valójában annak adatmodelljét készítjük el. Miután az adatmodellt megadjuk az adatbázis-kezelő alkalmazásban, ezt követően tudjuk menteni, vagyis hozzuk létre az adatbázis fájlt a háttértárolón, és ezt követően kezdhetjük meg feltölteni adatokkal az adatbázist.

Álljunk meg egy szóra!
Az adatmodell fogalommal egy másik cikkben is találkozni fogunk, amely egy kicsit mélyebben, de még mindig kezdő szinten járja körbe ezt és a mai adatbázis-kezelő rendszerekkel kapcsolatos további fogalmakat. Az adatmodellezésnek könyvtárnyi szakirodalma van, és kutatási területnek is számít. Külön szakma, akiknek képviselői széles skálán dolgoznak a fentebb említett leltárlistától a vállalatok, cégek, intézmények számára tervezett sok-sok táblából, rekordból és mezőből álló gigantikus adatbázisokig. Egy nemzetközi bank sokezernyi fiókja, vagy egy repülőtársaság világszerte megtalálható jegyértékesítő pontjai, valamint ezek webes megjelenése között hatalmas, sokmilliós rekordszámú, megosztott, elosztott, folyamatosan szinkronizált adatbázisok teremtik meg a kapcsolatot, szolgálják ki percnyi pontossággal a munkatársak és az ügyfelek igényeit, időzónákat áthidalva, a nap 24 órájában. El lehet képzelni, mennyire fontos és precíz munkát igényel az ilyen adatbázisok modellezése, megtervezése.

2. A mező tulajdonságai és lehetséges adattípusai

Most, hogy már van elképzelésünk a tábla felépítéséről, lépjünk megint közelebb, és ismerkedjünk meg a mezők tulajdonságaival!

Az elmúlt évtizedekben igen gyors volt az adatbázis-kezeléssel kapcsolatos elmélet és gyakorlat fejlődése, így mára letisztultak azok az elvek, amelyek meghatározzák a mezők lehetséges adattípusait és egyéb jellemzőit. Így kijelenthetjük, hogy egy olyan, mai általános vásárlói, irodai igényeket kielégítő adatbázis-kezelő rendszer, mint az Access 2016 az alább felsorolt mezőtulajdonságokkal rendelkezik.

A mező két legfontosabb tulajdonsága a név és az adattípus:

  • Egy mező neve legfeljebb 64 karakterből állhat.
    Tartalmazhatja bármilyen kombinációját kis- és nagybetűknek, számoknak, szóközöknek és egyes speciális karaktereknek. Nem tartalmazhat pontot, felkiáltójelet, aposztrófot és szögletes zárójelet. Például érvényes mezőnevek a következők: VevőTelepülés, Bútor01, Személyi igazolványszám.
    Tehát tartalmazhat szóközt, de a gyakorlatban nem ajánlott alkalmazása. Helyette az aláhúzás jelet (_) használjuk, például Vevő_neve.
    Arra is ügyelnünk kell, hogy szóközzel nem kezdhetünk mezőnevet. Ebben az esetben is inkább az aláhúzás jelet alkalmazzuk.
    A névadáskor célszerű minél rövidebb, értelmes szavakat, vagy elterjedt rövidítéseket alkalmazni, egybeírás esetén nagy kezdőbetűvel és/vagy aláhúzás jellel tagolva. Az adatbázis-kezelő alkalmazások minden esetben hibaüzenettel jeleznek, ha nem a szabályoknak megfelelő nevet adunk meg.
    Egy táblában nem lehet két azonos nevű mező, de egy adatbázis különböző tábláiban igen. Tehát két különböző tábla is tartalmazhatja például a VevőKód mezőnevet.
  • Az adattípus határozza meg, hogy a mező milyen jellegű és tulajdonságú adatot képes befogadni, tárolni. Az adattípus előírásával egyrészt kényelmi szolgáltatást kapunk (például automatikus sorszámozás), másrészt egyfajta ellenőrzési és megjelenítési lehetőséget is biztosít számunkra. Egy újabb előnye, hogy az adattípushoz számos tulajdonság tartozik, amelyekkel szabályozhatjuk a mező tartalmát (Általános) és megjelenését (Megjelenítés).

Jegyezzük meg, hogy ha a tábla rekordokkal, adatokkal feltöltött, akkor már nem szerencsés a mezők tulajdonságain változtatni, mert adatvesztés léphet fel. Tehát az adatbázis tervezésénél kell eljárnunk minél nagyobb gondossággal, hogy erre ne kerülhessen sor.

A lehetséges adattípusok az Access 2013 és ennél újabb kiadású asztali adatbázis-kezelő alkalmazásokban a következők lehetnek:

  • Rövid szöveg: legfeljebb 255 alfanumerikus karakter tárolására használjuk.
  • Hosszú szöveg: hosszabb szövegek tárolására használható adattípus, amelynek mérete kb. 1GB lehet. Formázott, vagyis RTF formátumú szöveget is tartalmazhat.
  • Szám: numerikus adatok tárolására használjuk. A tárolandó szám értékkészletétől (nagyságától) függően választhatunk 1, 2, 4, 8 és 16 bájton tárolható pozitív és negatív egész, illetve törtszámokat. Elnevezés szerint lehet Bájt, Egész, Hosszú egész, Egyszeres, Dupla, Replikációs azonosító és Decimális.
    Az ábrázolható számtartomány, vagyis az értékkészlet
    hatványalakban: -231-tól 231-1-ig,
    számjegyként: -2 147 483 648-tól 2 147 483 647-ig,
    kiolvasva: kettőmilliárd-egyszáznegyvenhétmillió-négyszáznyolcvanháromezer-hatszáznegyvennyolctól kettőmilliárd-egyszáznegyvenhétmillió-négyszáznyolcvanháromezer-hatszáznegyvenhétig terjed.
  • Nagy szám: segítségével csillagászati értékeket tudunk rögzíteni 8 bájton. Alkalmazása speciális beállítást követel. Az értékkészlet egészen elképesztő,
    hatványalakban: -263-tól 263-1-ig,
    számjegyként: -9 223 372 036 854 775 808-tól 9 223 372 036 854 775 807-ig,
    kiolvasva:  kilenckvadrillió-kettőszázhuszonháromtrillió-háromszázhetvenkettőbillió-harminchatmilliárd-nyolcszázötvennégymillió-hétszázhetvenötezer-nyolcszáznyolctól kilenckvadrillió-kettőszázhuszonháromtrillió-háromszázhetvenkettőbillió-harminchatmilliárd-nyolcszázötvennégymillió-hétszázhetvenötezer-nyolcszázhétig terjed.
  • Dátum/idő: adattípussal dátum és/vagy időpont rögzíthető a mezőben. Az adat tárolására 8 bájt áll rendelkezésre. A válaszható formátumok és mindegyikhez egy-egy példa (a megjelenítés formátuma függ az operációs rendszer dátum és idő beállításától):
    Általános dátum: 2018. 11. 05. 18:25:37
    Hosszú dátum: 2018 november 05., hétfő
    Egyszerű dátum: 18. nov., 05.
    Rövid dátum: 2018. 11. 05.
    Hosszú idő: 18:25:37
    Közepes idő: 6:25 du.
    Rövid idő: 18:25
  • Pénznem: adattípus 4 tizedes pontossággal 8 bájton tárolva pénzügyi adatok tárolására használható. Ez az adattípus a következő megjelenítési lehetőségekkel bír:
    Általános szám: 1234,5678
    Pénznem: 1 234,56 Ft
    Euró: 1 234,56 €
    Rögzített: 1234,56
    Normál: 1 234,56
    Százalék: 123%
    Tudományos: 123E+4
  • Számláló: adattípust elsődleges kulcs mezőhöz jelöljük ki, az alkalmazásra bízva új rekord rögzítésénél a minden más rekordtól eltérő érték megadását. Hosszú egész számokat választva 4 bájtnyi helyet igényel. Ekkor megválaszthatjuk, hogy véletlenszámokkal, vagy folyamatosan növekvő értékekkel töltse fel a mezőt.
    Ha a 4 bájt nem elég, akkor választhatjuk a 16 bájtos replikációs azonosítót.
  • Igen/Nem: adattípust használjuk a logikai típusú adatok rögzítésére. Az Access a logikai hamis értékhez a 0-t, a logikai igaz értékhez a -1-et rendeli. A -1/0 megjelenítése helyett ugyanakkor választhatjuk az Igaz/Hamis, Igen/Nem és Be/Ki értékeket.
  • OLE objektum: adattípus ~2GB méretű speciális objektum (kép, diagram, videó stb.) tárolását teszi lehetővé. (Az OLE és a vele rokon objektumkezelő eljárásokról egy másik cikkben írunk.)
  • Hivatkozás: URL helyi vagy webcím tárolására használható adattípus. A mező legfeljebb 8KBájton képe tárolni a linket.
  • Melléklet: adattípussal tetszőleges számú, egyenként legfeljebb 2GB méretű fájlt csatolhatunk a mezőhöz. A csatolmányok összmérete az adatbázisban legfeljebb akkora lehet, mint az adott fájlrendszerben tárolható legnagyobb méretű fájl. Ha nincs fájlméret korlát, akkor a tárkapacitás a határ.
  • Számított: adattípus a tábla egyéb mezői alapján számított értéket tárolhat. Adattípusa igazodik a számolt mezők adattípusához. Például készíthetünk egy olyan Számított adattípusú mezőt egy táblában, amely a vásárolt darabáru és annak nettó ára alapján kiszámolja a bruttó árat (DB-szám, Nettó-Pénznem, ÁFA-Szám), így a mező adattípusa Pénznem lesz.
  • Keresés varázsló: speciális adattípus, amely a választéklisták összeállításához és a bennük lévő értékek könnyebb rögzítéséhez nyújt segítséget. Jól jöhet például, ha a hét napjait vagy a hónapok neveit akarjuk felkínálni a mezőben, de lehetőség van egy másik táblában tárolt és szűrt tetszőleges számú értéket felkínáló listát is megjeleníteni a segítségével.

Az adattípusok számos általános és megjelenítéssel kapcsolatos egyéb tulajdonsággal is rendelkez(het)nek, amelyek közül egyesek alapértelmezetten beállítottak, másokat nekünk kell vagy lehet megadnunk. Ilyenek például a most még nem túl érthető funkciójú Mezőméret, Beviteli maszk, Formátum, Érvényességi szabály, Kötelező, Nulla hosszúság engedélyezése, Indexelt, Alapértelmezett érték, Cím stb.

Nyilván a fentieket igazán a gyakorlatban fogjuk tudni alkalmazni. Most viszont térjünk át egy speciális mezőtulajdonságra, amivel minden tábla készítésekor foglalkoznunk kell.

3. Az elsődleges kulcs

Az elsődleges kulcs (primary key) szerepe, hogy legalább egy mező alapján egymástól egyértelműen megkülönböztethetők, azonosíthatók legyenek az egyes rekordok egy táblán belül. Tehát az elsődleges kulcs biztosítja, hogy véletlenül se lehessen két egyforma rekord egy táblában.

Ez egyben azt is jelenti, hogy az elsődleges kulcsként megjelölni kívánt mezőben nem lehet két egyforma, ugyanazon értéket tartalmazó érték a rekordokat tartalmazó táblában. Erre gondolva minden táblában létre szoktunk hozni egy olyan mezőt, amelynek nevében utalunk az azonosító, egyedi jellegre, például nevében feltüntetve az ID (identifier = azonosító) rövidítést – persze megadhatunk bármilyen mezőnevet. Ha így járunk el, akkor a minden adatbázis-kezelő által erre szolgáló adattípust szoktuk a mezőhöz rendelni (Számláló), így mentesülünk az egyedi értékek minden új rekordban történő megadásától. Természetesen, ha van olyan mező a táblában, amely alkalmas elsődleges kulcsnak, akkor célszerű azt kijelölni.

Az elsődleges kulcs másik szerepét a kapcsolt, relációs tábláknál tölti be: két tábla között a kapcsolatot, vagyis a relációt két azonos mező között ezekkel a mezőkkel teremtjük meg. Ilyenkor az első táblában a mező neve elsődleges kulcs, a másik táblában lévő ugyanezen mező neve idegen kulcs. A relációs adatbázis fogalmát egy másik cikkben ismertetjük.

Az elsődleges kulcs a tábla rekordjainak alapértelmezett rendezettségét is megadhatja abban az esetben, ha a mező tartalma alapján a tábla rekordjai az eredeti sorrendnek megfelelően lekérdezhetők. Például, ha az elsődleges kulcsként szolgáló mező a természetes számokat tartalmazza 1-től kezdve, és minden új rekordhoz a következő számot rendeljük, akkor ezen mező alapján egy emelkedő sorrendű rendezés a rekordok felviteli, vagyis eredeti sorrendjét fogja eredményezni.

4. A fizikai és a logikai sorrend, a tárolt index

Amikor egy táblát tartalommal töltünk meg, az a rekordok egymás után történő felvitelét jelenti. Ez a rekordok rögzítési vagy fizikai sorrendje. A kezdő vagy az Excel táblázatkezelőn nevelkedett felhasználó általában egy mező segítségével beszámozza a rekordjait vagy valami más egyéb egyedi azonosítónak használható mezőt alkalmaz a fizikai sorrend rögzítésére, ami akár lehet elsődleges kulcs is – tehát nem haszontalan eljárás ez.

Az adatbázis-kezelő rendszerek megengedik a fizikai sorrend módosítását, vagyis a rekordok tényleges átrendezését. A fizikai sorrend változhat akkor is, ha rekordot fizikailag törlünk, vagy rekordot a meglévők közé szúrunk be.

Ugyanakkor fontos tudatosítani magunkban, hogy a rekordok fizikai sorrendjével az adatbázis kezelése közben soha nem kell foglalkoznunk, vagyis az adatbázis-kezelés szempontjából érdektelen a rekordok fizikai sorrendje.

Miért? Mert az adatbázis kezelése során az adott feladatnak megfelelően majdnem mindig feladatunk lesz a rekordok sorba rendezése, tehát a rekordok valamilyen szempont szerinti rendezett megjelenítése, listázása, nyomtatása – és ilyenkor érdektelen, hogy milyen volt az eredeti sorrend, sőt nem kell foglalkoznunk az eredeti, vagyis a fizikai sorrend helyreállításával sem – ami egy Excel listában szükséges lehet.

Tehát a rekordok valamilyen szempont szerinti ideiglenes sorba rendezését logikai sorba rendezésnek, idegen szóval indexelésnek, a rendezett állapotot röviden indexnek nevezzük.

Az indexelés során egy vagy több mező tartalma alapján kérjük le, láttatjuk a rekordokat, például egy ügyféllistát az ügyfelek vezetékneve szerint ábécé sorrendbe rendezve.Azonban a sorba rendezés során nem változik meg a rekordok fizikai sorrendje a táblában, nem cserélődnek fel a rekordok a táblában az új rendezési szemponthoz igazodva. Ez egy jelentős különbség például egy Excel és egy Access lista között.

Fogalmazhatunk úgy is, hogy az adatbázisnak csupán egy fizikai sorrendje van, és az többnyire változatlan, míg logikai sorrendje bármennyi lehet.

Mivel a sorba rendezés gyakori és ismétlődő művelet, a mai adatbázis-kezelő rendszerek képesek az indexeket a későbbi felhasználáshoz névvel azonosítani és tárolni az adatbázisban – aha, tehát nem csak táblák lehetnek egy adatbázisban! A névvel tárolt index csupán a megadott szempontok szerinti rekordsorrendet rögzíti az adatbázisban.

A tárolható indexek száma, illetve az indexenként megadható mezők és táblák száma elvileg korlátlan a legtöbb mai adatbázis-kezelőben.

A tárolt indexekben az a jó, hogy az adatbázis-kezelő rendszerek ezeket a háttérben automatikusan karbantartják, frissítik, aktualizálják a tábla minden módosulását követően. Így, ha a felhasználó egy tárolt index alapján lekérdezést (sorba rendezést) kér, annak eredményét, vagyis a sorba rendezett rekordok listáját nagyon gyorsan megkapja.

Erre nagyon jó példa a hatalmas árukészlettel rendelkező webshopok mögött álló adatbázis-kezelő rendszer. Képzeljük el, micsoda kiszolgálást végez az a rendszer, amely a világ minden tájáról minden másodpercben milliós nagyságrendben kap lekérdezéseket a felhasználóktól, akik a terméklistára szűrve keresik ki a megvásárolni kívánt terméket! Gondoljunk csak az olyan gigacégek webshopjaira mint az Amazon, az eBay, vagy a kínai kereskedelmi óriások! Meddig működhetnének ezek a cégek adatbázisaik indexelési képességei nélkül, ha percekig kellene várni minden lekérdezésre!

Miről szólt ez a cikk?
Valószínűleg bedobtuk a nyájas olvasót a mélyvízbe. Pedig ez még mindig az alapozás, de a javával végeztünk. Nagyon fontos volt megismernünk az adatmodell, index, elsődleges kulcs fogalmakat, valamint az Access adattípusait. Ezek megértése nélkül nincs adatbázis-kezelés.