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

 Frissítve: 2021 október 3.

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 – körbejárjuk az adatmodell fogalmát, felsoroljuk a mezők jellemzőit, a lehetséges adattípusokat, 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, megértjük, hogyan gyorsítható fel a rekordok sorba rendezése és az adatok visszakeresése és szűrése indexeléssel és mi ebben a szerepe a tárolt indexnek. 

Tartalomjegyzék

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 – ezt nevezzük elemi adatnak.

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, esetünkben bútor adatait fogja tartalmazni. Nincs, nem lehet a táblában két vagy több rekord ugyanarról a bútorról. Eldöntjük, hogy a bútorokról milyen adatokat fogunk nyilvántartani a rekordokban, vagyis, hogy milyen mezőkre lesz szükségünk. Előfordulhat, hogy az egyik bútor tulajdonsága nem jelenik meg egy másik bútornál. Tehát minden tulajdonságot összeírva, a táblában lesznek, lehetnek üresen hagyott mezők, ami nem hiba. Minden mezőnek nevet fogunk adni. 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. A korábban tanultaknak szerint 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. Az adatmodellt megtervezve az adatbázis-kezelő rendszerben létrehozhatjuk az adatbázist, abban a szükséges számú táblát, abban vagy azokban a mezőket, megadjuk azok tulajdonságait, végül háttértárra mentjük adatbázis fájlként. Ezt követően hozzákezdhetünk az adatbázis adatokkal való feltöltéséhez.

Á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 egy adatbázis tábla felépítéséről, lépjünk még 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 a Microsoft Office irodai csomag részét képező Access, az alább felsorolt mezőtulajdonságokkal rendelkezik.

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

Álljunk meg egy szóra!
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.

Nézzük meg például a Microsoft Access asztali adatbázis-kezelő alkalmazás adattípusait:

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. Az elsődleges kulcs biztosítja, hogy véletlenül se lehessen két egyforma, minden mezőjében azonos tartalommal bíró 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 rögzítéskori 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, más szóval fizikai, vagyis eredeti sorrendjét fogja eredményezni. A rekordok fizikai és egyéb sorrendjéről érdemes többet tudni…

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 új 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 szerint 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.

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 rendezzük át, kérjük le, láttatjuk a rekordokat, például egy ügyféllistát az ügyfelek vezetékneve szerint ábécé sorrendbe rendezve. Az indexelés során a rekordok fizikai sorrendje nem változik meg 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.

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

A tárolt indexek nagy előnye, 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án mindenféle szempont szerint lekérdezéseket indítva, szűrve keresik ki, rendelik meg és fizetik ki a megvásárolni kívánt terméket! 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!

5. Összefoglalás

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 fogalmával, a mezők tulajdonságaival, a felhasználható adattípusokkal, az elsődleges kulcs szerepével, a fizikai és a logikai sorrend közötti különbséggel, valamint az index fogalmával. Ezek megértése nélkül nincs adatbázis-kezelés.

VÉGE.

Infopanel
Készült: 2019 szeptember 21.
Szint: kezdő, ECDL modul/tanmenet: Adatbázis-kezelés/S6/1.2
Kategória: Adatbázis-kezelés → Az adatbázis ismerete → Adatbázis elrendezése

Mennyire találtad hasznosnak ezt a cikket?

Válassz egy csillagot!

Szavazatszám: 0, Átlag: 0

Még nem szavazott senki! Legyél az első, aki értékeli ezt a bejegyzést!

Sajnálom, hogy ez a cikk nem volt hasznos számodra!

Segíts nekem, hogy jobb legyen ez a cikk!

Írd le, mit hiányolsz ebből a cikkből!

Email
Twitter
Facebook
Nyomtat