KURZUS: Informatikai rendszerek alapjai
MODUL: Adatbázis-kezelés
1. lecke: Bevezetés az adatbázis-kezelésbe
Cél: Az első leckében az adatkezelési alapfogalmakat tekintjük át, és az adatkezeléssel kapcsolatos elképzeléseinket, elvárásainkat fogalmazzuk meg. Megismerjük a legáltalánosabban használt adatmodellt és az ehhez kapcsolódó alapfogalmakat. | |||||||
Követelmények: Ön akkor sajátította el megfelelően a tananyagot, ha | |||||||
| |||||||
Időszükséglet: A tananyag elsajátításához (a feladatok megoldásával együtt) hozzávetőlegesen 5 órára lesz szüksége. | |||||||
Kulcsfogalmak | |||||||
| |||||||
Hétköznapi életünkben is észrevehetjük, hogy egyre több adat, információ vesz körbe bennünket. Időjárás, árfolyam, benzinár. A következő vizsga kódja, dátuma, időpontja. A bankkártyánk PIN kódja. Jelszavaink. A focibajnokság eredményei. Adószám, TAJ szám, Neptun kód. Ahogy az utóbbi évtizedekben minden munkahelyre és háztartásba belopózott a számítógép, úgy lett egyre természetesebb, hogy adatainkat számítógépen tároljuk. A számítógép segít az adatok tárolásában, de az adatok tárolásának mikéntjét nekünk kell meghatározni. | |||||||
Adatkezelési alapfogalmak | |||||||
Érdemes tisztáznunk az adat szó jelentését. Adaton valamely tény reprezentálását értjük. Ezek a tények mindenki számára egyértelmű, objektív események, történések, állapotok. Úgy is mondhatjuk, az adat valamely dolog valamely tulajdonságának az értéke. Az adatokat természetesen valamely adathordozó tárolja, de ez az adathordozó független az adattól. Adatok tárolhatók sokféleképpen, mi természetesen számítógépen tárolt adatokkal foglalkozunk a későbbiekben. | |||||||
Az információt ezzel szemben egy hasznos közlésnek, egy jelentéssel bíró adatnak tekinthetjük. Nap, mint nap sok-sok információhoz jutunk. Információ például egy hír a zárthelyi dolgozat várható feladattípusairól. Az információhoz szorosan kapcsolódik | |||||||
| |||||||
A fentiek miatt az információ mindig szubjektív fogalom, mert függ a feldolgozótól. Aki nem vette fel az adott tárgyat, annak számára a zárthelyi tartalma vajmi kevés információval bír, máshogy értékeli a hallottakat az is, aki már harmadik alkalommal igyekszik aláírást szerezni. | |||||||
A szubjektivitás mellett vegyük észre, hogy a hétköznapi életben is azokat a dolgokat találjuk érdekesnek, amelyeknek bekövetkeztére kevésbé számítunk. Mindenki hallotta már, hogy nem az a hír, ha a kutya megharapja a postást, hanem az, hogyha ez fordítva történik - mert ilyet ritkábban hallunk. A zárthelyi dolgozat kérdései is azok számára a legizgalmasabb hírek, akik nem jártak órára, ezért alig tudják, mire kell a számonkérésnél számítani. Mindezt úgy is megfogalmazhatjuk, hogy egy adat információtartalma fordítottan arányos a valószínűséggel. | |||||||
Az adat és információ kapcsolata ezek alapján már egészen világos: azok a számok vagy egyéb tényszerű dolgok, amiket a számítógépen tárolunk, az adatok. Ezen adatokból mindenki a számára fontosakat használja fel a saját szubjektív szempontjai alapján, így nyerünk az adatfeldolgozás során információt. | |||||||
Adattárolás számítógépen | |||||||
A számítógépen történő adattárolás sokféleképpen megvalósítható. Tárolhatjuk adatainkat szövegek vagy fotók formájában. A fájlokba történő rendezés és a mapparendszer teljesen hétköznapi megoldás. Mégis érezzük, hogy nagyon sokféle adatkezeléshez nem ez a megfelelő megoldás. Furcsállnánk, ha a tranzakcióinkat úgy tartaná nyilván a bank, hogy mondjuk egy alkalmazott egy szövegfájlba minden alkalommal beírja az aktuális pénzmozgás adatait, ami aztán formázva hónap végén bankszámla-kivonatként nyomtatható is lenne. Azt is furcsállnánk, ha az aláírás mintánk mapparendszerben, képfájlokban lenne tárolva. | |||||||
A számítógépes adatkezelés a számítógépekkel egyidős, és rég felmerült az igény egy egységes, strukturált adatkezelési módszerre. | |||||||
Adatkezelési elvárások | |||||||
Vegyük sorra, milyen követelményeket fogalmazhatunk meg egy általános célra megfelelő adatkezelő rendszerrel kapcsolatban. | |||||||
Nagy mennyiségű adatok hatékony kezelése | |||||||
Elsőként fogalmazzuk meg, hogy az adatkezelő rendszerektől gyakorlatilag "korlátlan" mennyiségű adat megfelelő kezelését várjuk el. A korlátlanságot természetesen a gyakorlati, ésszerű határokon belül értjük, ott viszont komolyan is vesszük: senki nem fogadná el, ha egyik évben nem lehetne újabb hallgatókat felvenni az egyetemre, mert "betelt" a Neptun rendszer és "nem fér bele" újabb hallgató. Holott, biztosan van fizikai határa a lehetséges hallgatói létszámnak, csak ez olyan nagy, hogy a gyakorlatban soha nem fogjuk elérni. A Google keresőjétől pedig azt vesszük természetesnek, hogy nem lassabb, mint 10 éve, pedig ennyi idő alatt a fellelhető webes tartalom a sokszorosára duzzadt. | |||||||
A nagy adatmennyiség mellett is vannak elvárásaink a programok válaszidejére. Az elvárt válaszidő függ az adott alkalmazástól. Legtöbb esetben, ha egy gomb lenyomása után 1-2 másodpercig nem kapunk választ vagy eredményt, akkor a programot már rossznak ítéljük - ilyenkor a tapasztalatlanok elkezdenek türelmetlenül tovább kattintgatni, mert úgy látják, "lefagyott" a program... Az interaktív programokat jellemzően úgy kell elkészíteni, hogy másodpercen belül reagáljanak a legtöbb akcióra. Egyes esetekben, ha a felhasználót egyértelműen tájékoztatjuk a munka készültségi fokáról (pl. százalékos kijelzés, vagy grafikus folyamatjelző [angolul progress bar]), elfogadható egy maximum 20-30 másodperces várakozás is. Egy gyár termelésütemező rendszerében azonban, amikor a következő havi termelés paramétereit számoltatják ki a szoftverrel, valószínűleg teljesen elfogadható egy 8 órás futási idő. | |||||||
A nagy adatmennyiség velejárója a nagy helyszükséglet. Ezzel kapcsolatban vegyük észre (a későbbiekben részletesen foglalkozni fogunk a témával), hogy a különböző funkciók gyorsításához sok esetben további, redundáns adatok tárolására van szükség. Azt is könnyű belátni, hogy tömörített tárolással helyet takaríthatunk meg, azonban a rendszer használata lassabbá válik. Így egyensúlyt kell teremteni az adatkezelő rendszer által felhasznált tárterület és a felhasználó számára elfogadható válaszidők között is. Az autóba szerelt GPS navigáció használatakor 5-10 másodperc útvonal-tervezési időt talán még elfogadhatónak tartunk, miközben a teljes Európa-térkép elfér a 4 GB-os belső memórián. Biztosan nem aratna nagy sikert egy olyan, nehezebb és sokkal drágább berendezés, ami ezt az időt 2 másodpercre szorítja olyan áron, hogy egy 500 GB méretű háttértárat kellene csatlakoztatni, amin minden település-pár közötti útvonal tárolva lenne, amit így csak be kell tölteni. | |||||||
Konkurens hozzáférés támogatása | |||||||
Az adatkezelő rendszerek jellemzően nem személyes használatra készülnek. Természetes igény, hogy minden felhasználó elvárja, hogy a rendszert bárki más munkájától függetlenül tudja használni. Az egy időben ugyanazokon az adatokon dolgozó programokat, illetve felhasználókat a "konkurens" szóval jellemezzük. | |||||||
Az egyes felhasználók műveleteinek - az ésszerű határokon belül - egymástól függetleneknek kell maradniuk. Az olvasási műveletekkel nincs különösebb gond, legfeljebb jelentéktelen mértékű lassulást tapasztalhatunk. Az írási műveleteknél a konkurens hozzáférések biztosítása, illetve működése nem triviális. Azt kell mindenképpen rendszerszinten biztosítani, hogy az egyidejű írási műveletek ne vezethessenek hibákhoz. Ennek egyik tipikus példája az ún. "elveszett módosítás" (angolul lost update) jelenség: képzeljünk el egy vállalatot, ahol a dolgozók 10% béremelést kapnak, az egyik kiváló dolgozó pedig emellett 50 ezer forint egyszeri jutalomban is részesül. A két feladatot két ügyintéző hajtja végre. Nézzük, milyen feladatokat lát el az első ügyintéző (természetesen a béreket nyilvántartó programja segítségével): | |||||||
| |||||||
Ezt a műveletet természetesen a vállalat összes dolgozója esetében el kell végezni. | |||||||
Nézzük, mit csinál eközben a másik ügyintéző a megjutalmazott kolléga bérével: | |||||||
| |||||||
Tekintsük az 1. ábrát: | |||||||
| |||||||
Az első ügyintéző programja az 1-es (A) időpontban olvassa ki a béremelést kapó kolléga adatait, kiszámolja a fizetésemelés alapján az új bért és igen rövid, de mégis nullánál hosszabb idő múlva (D) időpontban visszaírja az adatot. Ha a másik ügyintéző éppen ez alatt (B időpontban) olvassa ki az adott dolgozó fizetését, még természetesen az eredeti értéket látja. Valami oknál fogva hamarabb végez a számítással és C időpontban be is tudja írni az ötvenezer forinttal megnövelt összeget. Ahogy az ábráról leolvasható, ez az összeg azonban pillanatokkal később (D időpontban) felülíródik a másik értékkel. Így, bár mindkét ügyintéző jól dolgozott, egy kolléga mégsem kapta meg az ötvenezer forintos jutalmat, az egyik módosítás a konkurens módosítások nem megfelelő kezelése miatt elveszett. Még csak hibaüzenet sem érkezett róla (hiszen hiba végül is nem történt), így talán az illető dolgozó sosem tudja meg, hogy főnöke meg akarta jutalmazni... | |||||||
Ez a szituáció elkerülhető úgy, hogy az adatkezelő rendszer B időpontban nem engedi kiolvasni az adatot, hiszen tudja, hogy azt egy másik folyamat A időpontban már kiolvasta (és zárolta). D időpontban megtörténik az új érték beírása és a zárolás feloldódik. Ekkor már a második folyamat is megkaphatja a kért adatot és dolgozhat rajta. A második folyamatnak ez egy észrevehetetlenül kicsi, D-B időveszteséget okoz, cserébe a program a módosítások az elvárt módon történnek meg. | |||||||
Találjon két másik olyan szituációt, ahol a lost update jelenség felmerülhet és problémát jelent. | |||||||
Adatintegritás | |||||||
Egy jó adatkezelő rendszer nagyon sok rutinmunkát és felelősséget levesz a használója válláról, hogy előre megadott szabályok alapján folyamatosan ellenőrizni tudja az adatokat és nem engedi, hogy a feltételeknek ellentmondó adatok a rendszerbe kerüljenek. A feltételek sokrétűek lehetnek és különböző komplexitásban vizsgálhatók. A legegyszerűbb ellenőrzések közé tartozik, hogy a raktárkészlet nemnegatív egész szám, az adószám megfelel az adóhatóság által megadott formátumnak, személyeknél a név mező pedig nem lehet üres. | |||||||
Bonyolultabb, több adat összekapcsolásával is megfogalmazhatók integritási kritériumok: ha egy személy beltag egy betéti társaságban, akkor másik Bt-ben már nem tölthet be ugyanilyen tisztséget. Azzal is sok további kényelmetlenség elkerülhető, ezért jogos elvárás az adatkezelő rendszertől, ha egy olyan autó tulajdonosi viszonyait nem lehet átírni az önkormányzatnál, ami szerepel a lopott gépjárművek rendőrségi nyilvántartásában. Az integritási feltételekről részletesebben az Integritási feltételek című szakaszban lesz szó. | |||||||
Adatvédelem (Safety + Security) | |||||||
A biztonság szónak angolul két, eltérő jelentésű megfelelője van: a safety és a security. | |||||||
Safety: adatvesztés lehetőségének minimalizálása, kizárása | |||||||
A safety olyan fajta biztonságot takar, amikor az adatvesztés lehetőségét próbáljuk kizárni, vagy ha ez nem sikerül, legalább minimális, elfogadható szinten tartjuk. Ennek különböző megoldásai lehetségesek, egy megbízható hardveren futó megbízható szoftver adatait is érdemes rendszeresen menteni és tervezett ideig megőrizni. A fizikailag elkülönített tárolásról sose feledkezzünk meg: tűz esetén mit sem ér, ha a gondosan, napi rendszerességgel elkészített biztonsági másolatokat a szerver tetején tároljuk egy dobozban. A biztonsági mentések készítésének módja természetesen az adott alkalmazástól függ: egy bank saját ingatlanjainak nyilvántartását lehet, hogy elég naponta vagy hetente menteni, de a pénzügyi tranzakciók esetében az utolsó 5 perc átutalásainak (nem magának az átutalt pénznek!) az elvesztése is katasztrofális lenne. | |||||||
Security: jogosulatlan hozzáférések megakadályozása | |||||||
A biztonság másik vonatkozását az angol security szó írja le a legmegfelelőbben. Az információs társadalomban egyre jobban megtanuljuk, hogy az információ érték. Adatainkat mindig védeni kell az illetéktelen hozzáféréstől, legyen az akár olvasási vagy írási jellegű. Alapvető védelmi megoldás a felhasználók névvel és jelszóval történő azonosítása. Az adatkezelő rendszereknél, mint azt említettük már, alapvető feltétel a több felhasználós működés, ami szinte azonnal feltételezi azt is, hogy a rendszer hálózaton elérhető. Ez pedig biztonsági kérdéseket is azonnal felvet, hiszen egy hálózatba kötött gépet komoly szakértelemmel kell megvédeni a lehetséges támadásoktól, ami sokkal komolyabb munka, mint a fizikai védelem, amit sok esetben egyetlen zárt ajtó is megfelelően biztosít. A jelszavas azonosítás mellett jellemző védelmi megoldás az is, ha az egyes felhasználók a saját belépési azonosítójuk birtokában is csak kijelölt helyekről férhetnek hozzá a rendszerhez. Például, az igazgató jogosultságával csak az igazgatói irodából lehessen a rendszerhez férni, a közeli nyilvános könyvtárból ne. | |||||||
Szabványosság | |||||||
Egyre természetesebb elvárás, hogy az egyébként egyre bonyolultabbá váló eszközeinket mégis egyre egységesebben, egyszerűbben tudjuk kezelni. Mobiltelefon vagy televízió vásárlása után azonnal használni szeretnénk az eszközöket. Valószínűleg akkor is haza tudjuk vinni az új autónkat, ha a kereskedés előtt nem olvassuk végig alaposan az egyébként sok hasznos részletet leíró vaskos kézikönyvet. Ugyanezt várjuk el szoftvereinkkel kapcsolatban: aki bérszámfejtő munkakörben jól megfelelt az egyik cégnél, nem akar munkahely-változtatás után újabb hónapokat tölteni egy hasonló, de merőben más logikával működő másik rendszer megismerésével. Ez a szoftvertervezés terén egyrészt a kvázi szabványos, ergonomikus felhasználói felületeknek köszönhető, másrészt annak, hogy a mai szoftvermérnökök a fejlesztett rendszereik "belsejében" is szabványos megoldásokra törekszenek. Az adatkezelő rendszereknél ez különösen fontos elvárás, hiszen sokszor kell különböző adatkezelő rendszerek közötti adatcserét megvalósítani. | |||||||
Szabványos adatkezelő rendszereken tehát a fejlesztés, illetve a felhasználók betanítása, majd a későbbi munkájuk sokkal gyorsabb (azaz olcsóbb), kényelmesebb. | |||||||
Kényelem | |||||||
Ez az elvárás valójában nem új fogalmat takar, inkább az előzőek összevonásának tekinthető. | |||||||
Az adatainkat kényelmesen, bármikor, bárhonnan el akarjuk érni úgy, hogy a rugalmas rendszer egyébként minden felhasználói hibát akadályozzon meg és az adataink csak a jogosultaknak legyenek hozzáférhetők. Mindezt persze gyorsan, olcsón és minimális erőforrásigénnyel... | |||||||
Túlzóan optimistának tűnik ez az elvárás, mégis erre törekszünk és elmondhatjuk, hogy a mai modern adatkezelő rendszerek egészen jól teljesítik is ezeket a követelményeket. A továbbiakban vizsgáljuk meg részleteiben, hogyan működnek a legelterjedtebb rendszerek. | |||||||
Relációs adatmodell |
Modell: A valóság olyan matematikai vagy tárgyi leképezése, ami a modellalkotó számára fontos tulajdonságokban egyezést mutat a valósággal. |
A modell fogalmat (elsősorban nem a tárgyi modellre gondolunk) a tudományos életben, kutatásban igen gyakran használják, hiszen a jól megválasztott, matematikailag kidolgozott fogalmak, eszközök segítségével áttekinthetően és rugalmasan leírható a valóság vizsgált részlete. Mi az adatkezelés módját is egy modellel, az ún. relációs adatmodellel fogjuk leírni. Ehhez a modellhez természetesen sok-sok kísérletezés útján sikerült eljutni, a korábbi és későbbi, kevésbé elterjedt adatmodellekkel pedig nem foglalkozunk. | |||||||
A relációs adatmodell alapjait az IBM-nél dolgozó Codd fektette le 1970 nyarán egy cikkében (E. F. Codd 1970). A cikk első gondolata az volt, hogy az adatbankok használatánál a belső, fizikai tárolással ne kelljen törődni, így felvázolt egy logikai tárolási, adatelérési módot. Az egész átlátható, és egyszerű volt, így gyorsan népszerűvé vált. Az elméleti megalapozottság, a precíz matematikai háttér pedig a kutatók szimpátiáját is kiváltotta. Mindennek következtében az adatmodellt hamar több különböző implementációban is megvalósították, és hamar jelentősen háttérbe szorított minden más hasonló próbálkozást. | |||||||
A relációs adatmodell egyrészt leírja az adatok tárolási struktúráját, másrészt a ezeken a struktúrákon végzendő műveleteket. Emellett van egy harmadik fontos komponense is, az integritási feltételek. Ez nem része sem a strukturális, sem a műveleti komponensnek, hanem magukat az adatértékeket, illetve az értékek közötti kapcsolatokat, szabályszerűségeket szabályozza. | |||||||
A relációs adatmodell tehát az alábbi három komponensből tevődik össze: | |||||||
| |||||||
A relációs adatmodellben az adott feladathoz tartozó összes adatot tekintjük egy adatbázisnak. (Így beszélhetünk a kórház betegnyilvántartó adatbázisáról, vagy az iskolai könyvtár adatbázisáról.) | |||||||
Reláció, mező, rekord |
Reláció = azonos típusú rekord-előfordulások összessége. |
Az azonos típusú adatokat relációkba szervezzük. A reláció legegyszerűbb esetben egy táblázat, vagy ahogy inkább nevezni szokták, tábla. Az iskolai könyvtárban egyik táblában tárolhatjuk a könyvek adatait, hiszen minden könyvnek hasonló típusú adatai vannak (cím, szerző, oldalszám) egy másikban pedig a kölcsönző személyek adatait. | |||
A relációk (táblák) meghatározott tulajdonságokat tartalmazhatnak, ezeket mezőknek hívjuk. Mint említettük, mező lehet a könyv címe, szerzője és oldalszáma. | |||
Amikor a tábla mezőit meghatároztuk (ezek vizuálisan egy tényleges táblázat fejlécei lehetnek), alá soronként egy-egy konkrét adat-előfordulást írhatunk: | |||
| |||
Egy ilyen sort rekordnak is szokás nevezni, a 2. ábra táblája tehát 2 rekordot tartalmaz. | |||
A reláció nem csak tábla lehet, hanem több táblából is összeállhat. Egyszerű (és ritkább) esetben két teljesen megegyező felépítésű tábla összeillesztéséből is kaphatunk egy ugyanolyan felépítésű, de természetesen nagyobb rekordszámú relációt. | |||
Descartes szorzat, halmazok | |||
Gyakran szükséges, hogy két logikailag összefüggő, de különböző felépítésű relációból (táblából) állítsunk elő egy újabb relációt. Ehhez meg kell ismerkednünk egy matematikai, azon belül pedig halmazelméleti fogalommal, a Descartes-szorzattal. |
Az A és B halmaz Descartes-szorzatán azt a halmazt értjük, melynek azon rendezett párok az elemei, amiknek első eleme A-beli, második eleme pedig B-beli és a szorzat minden lehetséges párt tartalmaz. |
Tegyünk még hozzá annyit, hogy a definíció értelemszerűen kibővíthető kettőnél több halmazra is. Továbbá, az esetek döntő többségében a Descartes-szorzatnak nem használjuk minden párosítását (az eredmény minden sorát), hanem csak azokat, amelyek valamely összetartozási feltételnek megfelelnek. A 3. ábrán példaként autók és emberek adatait rendezzük párokba. Ezek közül nincs értelme minden párosításnak, mi most a döntésünk alapján olyan párokat képzünk, ahol az egyes autók a hozzájuk rendezett emberek tulajdonát képezik. Ezeket a megfelelő sorokat (a személy azonosítója = az autó tábla tulajdonos mezője) 3. ábrán sárga színnel jelöltük. | |||
Vegyük észre, hogy a Descartes-szorzat minden sora azonos típusú, tehát reláció nemcsak tábla, hanem táblák Descartes-szorzata is lehet. | |||
Nagyon fontos megérteni, hogy két nagy tábla Descartes-szorzata hatalmas adatmennyiséget eredményez, ami az esetek jelentős részében valószínűleg szükségtelen is. A 3. ábrán is csak a sárga színnel kiemelt, összetartozó rekordokra van szükség. Az ilyen párosításokat az adatbázis-kezelők hatékonyabban is elő tudják állítani, nincs szükség a teljes Descartes-szorzat kifejtésére, sőt, valójában általában el kell kerülnünk, hogy nagy táblák esetén a Descartes-szorzat előállításra kerüljön. Ebben segítséget nyújthat az adatbázis-kezelő optimalizálója, de a lekérdezések készítőjének mindenképpen kell erre gondolkodnia. | |||
| |||
Próbálja meg értelmezni a 3. ábra adatait: hány autója lehet Ádámnak? | |||
A Descartes-szorzat kapcsán említettük a halmazokat. A relációs modell valójában mindig, mindenhol halmazokban gondolkodik. A halmazelméleti megközelítés mélyen benne van a modellben, és erősíti az elméleti gondolkodásmódot. A fizikai tárolásból azonban lista következik. Felhasználói igény is van a listák használatára, hiszen nagyon sok esetben számít a sorrend. A kinyert adatokat például eleve nem lehet halmazként, sorrendiség nélkül kinyomtatni, és legtöbbször nem "összevissza" sorrendben kapjuk a megfelelő eredményt, hanem meghatározunk egy bizonyos sorrendet (pl. a nevek ábécérendje szerint). Ezzel a lépéssel pedig a halmazból egy listát csináltunk. | |||
Ennek ellenére értenünk kell, hogy a relációs adatbázis logikai szinten halmazokkal, halmazműveletekkel dolgozik. | |||
Vegyük észre, hogy az adatmodell logikai szinten gondolkodik, és nem foglalkozik a fizikai tárolás problémáival. | |||
A relációs adatmodellt megvalósító adatbázisokat RDBMS-nek (Relational DataBase Management System) nevezik. | |||
Kulcs | |||
A relációs modell szerint az adataink a táblák soraiban (rekordjaiban) vannak tárolva. Nagyon fontos, hogy két rekordot mindig meg tudjuk egymástól különböztetni. |
Azon mezőt vagy mezőcsoportot, amik egyértelműen azonosítják egy reláció egyetlen sorát, kulcsnak nevezzük. |
A kulcs tehát minden rekordra (sorra) egyedi és állhat egyetlen tulajdonságból, ilyenkor egyszerű kulcsról beszélünk (pl. személyi szám) de lehet összetett is, például gyártó és cikkszám. A felesleges redundancia elkerülése miatt fontos, hogy a jó kulcsnak nincs olyan részhalmaza, ami kulcsként használható lenne. Ez azt jelenti, hogy ha összetett kulcsból akármit elveszünk, már nem lehet kulcs. Példánkban például a cikkszám nem elegendő kulcsnak, mert nem lehetünk biztosak abban, hogy a 4B0905594H cikkszámot az Audin kívül más gyártó is használja-e, a gyártó megadásával azonban már biztos, hogy egyedi, ezért azonosításra alkalmas. | ||
Másik példaként említsük meg a Matematika és Számítástudomány Tanszéket, ami szintén nem lehet kulcs, mert bármely más egyetemen is lehet azonos nevű tanszék. Így a tanszékek nyilvántartásában a tanszék neve + az egyetem neve lehet (összetett) kulcs. | ||
Keressünk konkrét példákat, milyen adatok lennének használhatóak az egyetem tanszékeinek egyedi azonosítására. | ||
Fontos, hogy a kulcs amellett, hogy minimális elemszámú, minimális méretű is legyen: az előző példában a tanszék és egyetem neve együtt bár lehet kulcs, de nem praktikus, mert igen hosszú és sok helyet foglal. Jobb megoldás például beszámozni az egyetemeket és a tanszékeket, és ezeket az egyedi azonosító számokat használni kulcsnak. | ||
A kulcsérték egyediségének betartását a jól tervezett adatbázis is megköveteli. Az egyediségből következik, hogy a kulcsértéket minden esetben ki kell tölteni. | ||
Ha minden rekordot tudunk azonosítani annak kulcsértékével, a kulcsok segítségével könnyűszerrel hivatkozhatunk egy tábla egyik rekordjára egy másik tábla valamely rekordjából. |
Az idegen kulcs olyan mező, - amiben táblák összekapcsolása céljából - egy másik tábla kulcsértéke szerepel. |
Az idegen vagy kapcsoló kulcsnak (angolul foreign key) a következő feltételeket kell teljesítenie: | |||
| |||
Ezt a szabályt hivatkozási integritási szabálynak nevezzük. | |||
A táblák közötti kapcsolatokat, az idegen kulcsok meglétét jelezni is lehet az adatbázisnak. | |||
A kulcs ugyanis felfogható egyfajta integritási feltételnek is (lásd Integritási feltételek című szakasz). Ha nem tesszük meg, akkor is működőképes lehet a rendszer, de nem várhatunk el integritásőrző (lásd ugyanott) és kényelmi automatizmusokat. | |||
Kapcsolatok | |||
A relációs adatmodell szerint a táblák közötti kapcsolatok adatértékeken keresztül valósulnak meg. Ez azt jelenti, hogy valamely tábla megfelelő mezőjébe egy másik tábla kulcsát írjuk, ami a kapcsolatot így egyértelműen leírja. (Erre vezettük be a Kulcs című szakaszban az idegen kulcs fogalmát.) | |||
A kapcsolatok leírásánál, tárolásánál nagyon fontos tudni az összekapcsolandó elemek számosságát. Általában nem is a pontos szám a fontos, hanem annak eldöntése, hogy pontosan 1 (vagy más nagyon kicsi egész számú) kapcsolódó elem lehetséges-e, vagy akár több is. Egy autónak például egyetlen alvázszáma lehet. Ez fordítva is igaz, egy alvázszám egyetlen autóhoz tartozhat. Ez a kapcsolat olyan közvetlen, hogy az alvázszám mező betehető az autó táblába az autó egyéb tulajdonságai közé (valójában csak ilyenek tehetők oda), és az ilyen típusú összerendeléseket, bár nevezhetnénk pl. 1:1 megfeleltetésnek, általában nem is szoktuk a kapcsolatok között tárgyalni. Ha mégis, akkor az 1:1 kapcsolat is kezelhető az Egy-több kapcsolat című szakaszban leírt egy-több kapcsolathoz hasonló módon is. | |||
A továbbiakban megnézzük, hogy a különböző számosságú, bonyolultabb kapcsolatok hogyan kezelhetők. | |||
Egy-több kapcsolat | |||
A személyek tábla megtervezésekor, ha az anya-gyerek kapcsolatokat is tárolni szeretnénk, tudhatjuk, hogy mindenkinek pontosan egy anyja van, de a gyerekek számát nem tudjuk előre, a rendszert pedig e változó számú kapcsolat kezelésére kell felkészítenünk. Fontos észrevenni, hogy a kapcsolatban csak az egyik oldal (a gyerekek) száma változhat, a másik oldal (az anya) egyetlen elemből állhat. Az ilyen kapcsolatot egy-több vagy 1:N kapcsolatnak nevezzük. | |||
| |||
Figyeljük meg 4. ábra példáján, hogy a kapcsolatok adatértékek által valósulnak meg. Ebben a kapcsolattípusban abba a táblába, amelyből több elem is kapcsolódhat a másikba, egyszerűen beírjuk a másik tábla megfelelő kulcsát. | |||
Több-több kapcsolat | |||
Gyakori az olyan kapcsolat is, amikor az összekapcsolt elemek számosságáról azt mondhatjuk, hogy bármilyen kapcsolat lehetséges. Ilyen a vállalatok és személyek kapcsolata: egy cégnek akárhány alkalmazottja lehet, egy ember pedig több cégnél is dolgozhat. Az ilyen kapcsolatoknál nem tudjuk a kapcsolatokat közvetlenül a két adattáblában tárolni, egy segédtábla szükséges. Ebben a táblában a kapcsolatban álló előfordulások (rekordok) kulcsmezőit tároljuk. | |||
| |||
Olvassuk le az 5. ábráról, hogy mely cégeknek mely személyek az alkalmazottai! | |||
Gondolkozzunk el azon, hogy az 5. ábra példáján mi lehet az Alkalmazott tábla kulcsa, illetve miért nincs külön létrehozott kulcsmező. | |||
Ahogy a Kulcs című szakaszban már említettük, e példa kapcsán is érdemes megfigyelni, milyen fontos, hogy a kulcsok lehetőleg kisméretűek legyenek. A kapcsolótábla méretét (és ezáltal használatának sebességét) a kulcsok nagymértékben befolyásolják. | |||
Index | |||
Ha egy fájlban tárolt adatot meg akarunk találni, annak alapvető módja, hogy a fájlt végigolvassuk, így előbb-utóbb eljutunk a keresett adatig. Ennek hétköznapi analógiája, hogyha egy tartalomjegyzék és tárgymutató nélküli könyvben akarunk valamit megtalálni: végig kell olvasnunk mindent, a keresett információ kinyerési ideje gyakorlatilag csak a szerencsénktől függ: attól, hogy a könyv mely részén helyezkedett el. Nem nehéz belátni, hogy a keresési idő egyenesen arányos a könyv méretével: kétszer akkora könyvben átlagosan dupla annyi ideig tartana így valamit megtalálni. Ha különböző keresési lehetőségeket készítettek a könyvbe (tartalomjegyzék, névmutató, tárgymutató, ábrajegyzék, hivatkozások jegyzéke, táblázatok jegyzéke), akkor sokkal gyorsabban megtaláljuk, amit keresünk. |
Az index az egyes táblákhoz kapcsolódó, a gyors keresést lehetővé tevő, az adatbázis-kezelő rendszer által automatikusan használt segédtáblázat. |
Az indexelés épp ezt valósítja meg az adatbázisban. Az egyébként (hogyan máshogy?) sorosan letárolt adatok mellé általunk meghatározott meta-adatok gyors keresést tesznek lehetővé az adatokon. A hatékonyság miatt az indexek létrehozása nem automatikus, nekünk kell megmondani, milyen szempontok szerint fogunk keresni az adatbázisban. Egy történelmi könyvben bizonyára van értelme az évszámokhoz kapcsolódó mutatóknak, egy gyógyszerészeti kézikönyvben kevésbé. Ott inkább a hatóanyagokat érdemes kigyűjteni, hogy melyikről hol olvashatunk. Ezek a listák jellemzően nem az eredeti előfordulás sorrendjében, hanem rendezetten, ábécésorrendben vagy szám szerint növekvően tárolják a kigyűjtött adatokat. | ||
Említettük, hogy az index létrehozása nem automatikus. Azonban ha egyszer definiáltuk, utána már az: az adatbázis-kezelő minden szükséges esetben aktualizálni fogja a benne lévő adatokat és a keresési műveleteknél szintén automatikusan használni is fogja azokat. Ez azt jelenti, hogy egy indexet egyszer létre kell hoznunk, onnan kezdve pedig gyakorlatilag nem kell törődnünk vele: szükség esetén segíteni fogja a munkánkat, észrevétlenül. | ||
A könyves analógiát annyiban kell módosítanunk, hogy amíg ott például egy tárgymutatóba a szerkesztő egyedi döntése, hogy mely szavak kerüljenek bele, ha itt egy vagy több mezőre létrehozunk egy indexet, akkor a tábla minden egyes rekordjának megfelelő adata automatikusan bele fog kerülni. | ||
Az index létrehozásával gyakorlatilag azt jelezzük az adatbázis-kezelő rendszer számára, hogy később milyen tipikus keresésekkel fogunk az adatbázishoz fordulni, így a szoftvernek lehetősége van ezekre a tipikus keresésekre a megfelelő listák előállításával felkészülni. | ||
Nem szabad megfeledkeznünk arról, hogy az indexeknek - az elemszámtól és a kulcstól függően - jelentős helyfoglalása lehet és ebből adódóan plusz terhelést jelent a használata (nem csupán kereséskor, hanem beszúráskor, módosításkor, törléskor is). Az indexeket akkor érdemes használni, amikor ezek a hátrányok ellensúlyozni tudják a használatából adódó előnyöket. | ||
Soroljunk példákat, milyen típusú könyvekbe szokás névmutatót tenni, és milyenekbe nem? Miért? | ||
Később látni fogjuk, hogy előny nem csak a sebességnövekedés lehet, hanem indexek segítségével integritási feltételeket is megfogalmazhatunk. Egy személyi nyilvántartásban sok indexet érdemes létrehozni, köztük valószínűleg érdemes lesz külön leindexelni a személyi számot. Mivel ez minden személy esetében egyedi, és ezt jelezzük is az index létrehozásakor (UNIQUE kulcsszóval), akkor ezt a szabályt az adatbázis-kezelő a későbbiekben minden esetben be fogja tartatni, természetesen automatikusan, és semmilyen körülmények között nem fogunk tudni tévedésből két embert felvinni ugyanazzal a személyi számmal. Hasonlóan azt is jelezhetjük az index létrehozásánál, ha egy adott mezőt mindenképpen ki kell tölteni (NOT NULL). | ||
Az indexek létrehozását a DDL című szakaszban tárgyaljuk. | ||
Adattípusok | ||
Attól függően, hogy az adatbázisunk tábláinak mezőiben miféle adatot szeretnénk tárolni, meg kell adnunk az egyes mezők típusát. Az alaptípusok eldöntése az első lépés, de ezen gondolkodni sem igen kell: számot szám típusban, szöveges adatot szöveges típusban, stb. tárolunk. Ezeknek a csoportoknak is sok-sok precízebben megfogalmazott altípusa van: ezek célja a minél hatékonyabb adattárolás. Fontos tehát jól választani, ehhez pedig ismerni kell a választékot. Egy igen-nem értéknek elegendő 1 bit, vagy ha a 2,536 számot karakterláncként, "2,536" formában tárolunk, akkor körülményesebb vele matematikai műveleteket végezni. Az már ordítóan rossz példa lenne, ha ezt a számot "Kettő egész ötszázharminchat ezred" formában tárolnánk: maga a tárolás megvalósulna, de a tárolt adattal végzendő műveletek nehézkesek lennének. | ||
Adatbázis-kezelőtől függően más és más adattípusok vannak, de ezek között természetesen sok az azonosság és nagy a hasonlóság. Konkrétumokért minden esetben az egyes adatbázis-kezelők dokumentációját kell átolvasnunk. Tipikus példák: | ||
| ||
A NULL érték | ||
Nagyon gyakori, hogy megengedhető, illetve nem elkerülhető, hogy egy mező kitöltetlen maradjon. (Például, ilyen lehet a férfiak esetében a leánykori név, vagy megtörténhet, hogy egy régi könyv esetén nem kideríthető a kiadás éve.) | ||
Ilyen esetben a mező NULL értéket vesz fel. Ez egy olyan különleges érték, ami nincsen benne semmilyen értéktartományban. Nem azonos a 0-val és nem azonos a "NULL" karakterlánccal sem. A NULL értékkel bármely műveletet vagy összehasonlítást akarunk végezni az eredmény NULL lesz. Ezek alapján a NULL érték egy ún. "harmadik igazságértéknek" tekinthető, hiszen logikai adataink a NULL révén az IGAZ és HAMIS mellett egy "nem definiált", vagy más szóval "ismeretlen" értéket is felvehetnek. Ezt nevezzük háromértékű logikának (3 Value Logic, 3VL). A szokásos Boole-algebrai műveleteket tehát ennek fényében kell értelmeznünk, bár nagyon egyszerű dolgunk van, hiszen bármely esetben, ahol legalább az egyik operandus NULL, az eredmény is az lesz. | ||
Érdekesség: A fentiek alapján egyszerű összehasonlítással (pl. IF mezo=NULL) nem lehet eldönteni egy adatról, hogy NULL értékű-e, hiszen annak a műveletnek az eredménye is mindig NULL érték lenne. A probléma megoldását a későbbiekben, az adatbázis-kezelő nyelv tárgyalásakor meg fogjuk mutatni. | ||
Integritási feltételek | ||
Az adatbázis működéséhez az adatoknak sokféle feltételnek kell megfelelnie, ahogyan azt az Integritásőrzés című szakaszban megfogalmaztuk az elvárásaink között. Az integritási szabályok célja az adat-előfordulások megengedett körének a behatárolása. Ezeket a feltételeket különböző szinteken lehet megfogalmazni: | ||
| ||
Mezőszinten minden mástól függetlenül szabályozhatjuk az adott mező értékét. Például, a testmagasság>=0, az adószám pedig pontosan 12 számjegyből áll. Ilyenkor a mező tartalmára állított megkötéseket nagyobb összefüggéseiben nem vizsgáljuk. | ||
Rekordszinten egy rekord elfogadhatóságáról döntünk. Személyi adatoknál rekordszintű feltétel lehet, hogy bizonyos életkorok alatt a különböző iskolai végzettségeket nem engedjük beállítani, hiszen egy 5 éves gyereknél az egyetemi végzettség nyilvánvaló adatbeviteli tévedésre utal, holott az egyes mezők egyenként megfelelőnek látszó értékeket tartalmazhatnak. A házastárs rovat pedig ne tartalmazhasson adatot, ha a családi állapot mező "nőtlen/hajadon" tartalmú. | ||
A táblaszintű ellenőrzéshez a tábla összes rekordját figyelembe véve kell a táblát megvizsgálni. Alapvető feltétel lehet, hogy egy mezőnek egyedinek, tehát az adott rekordnak megkülönböztethetőnek kell lennie - a kulcsmező eleve ilyen, és sok példát tudunk rá mondani: egy autó-nyilvántartásban a rendszámnak, alvázszámnak és ugyanazon banknál a biztosítás kötvényszámának biztosan egyedinek kell lennie. | ||
Táblaszinten más jellegű feltételek is megfogalmazhatók, például egy cég szabályzata alapján megfogalmazható, hogy az autói átlagéletkora a vásárlásuk pillanatában nem lehet több 6 évnél. | ||
Az adatbázisszintű megkötések esetében az integritási feltételt több táblában elhelyezkedő mezőkkel fogalmazzuk meg. Itt fogalmazhatók meg a táblák közötti kapcsolatok, függőségek. Tipikus példa, hogy egy autó-nyilvántartásba csak ismert, létező típuskódú autó kerülhet be, azaz a kérdéses kódnak a típusokat tartalmazó táblában szerepelnie kell. | ||
Az integritási feltételek adatbázisban történő beállítása "nem kötelező". Ezek a feltételek a kliens programokba is beépíthetők, például az adatfelviteli és adatmódosító űrlapok mögé. Ott azonban sokkal több munka lenne megvalósítani ezeket, és mivel ugyanazokon az adatokon többféle kliens is dolgozhat, sosem tudhatjuk, hogy pontosan ugyanazokat a feltételeket valósítja-e meg minden kliens - összességében egy kevésbé megbízható eredményre jutunk, sokkal több munkával. Ezért az integritási feltétek adatbázis-szinten történő megfogalmazása mindenképpen ajánlatos. | ||
Az integritási feltételek megadásának módját az adatbázis-kezelő nyelvének ismeretében a Integritási feltételek megadása című pontban fogjuk tárgyalni. | ||
Redundancia |
A redundancia (terjengősség) a felesleges (és/vagy kiszámítható) adatok mértéke. |
A redundancia, bár sokaknak talán idegenül hangzik, egészen hétköznapi fogalom. Azt fejezzük ki vele, hogy valamely információ mennyire szűkszavúan, vagy épp ellenkezőleg, mennyire terjengősen van megfogalmazva. Mindnyájunknak van tapasztalata abban, hogy ugyanazt a mondanivalót egyszer hosszan elnyújtva kell kifejtenünk, például azért, hogy a minimális oldalszámot elérjük, máskor pedig tömören kell fogalmaznunk (például, mikor SMS-t írunk). | |||
Az emberi nyelvek általában kimondottan terjengősek, ebben jelentős különbség van a nyelvek között, a magyar nyelv egyike a legkifinomultabbaknak, így szójátékok végtelen sorát kínálja, többek között a redundancia megfigyelésére. Ismerős gyerekkori játék csupán magánhangzókkal beszélni és kitalálni, mit mondott a beszélő. A dolog fordítva is meglepően jól működik: a magyar nyelvben a magánhangzók alig hordoznak jelentést: | |||
Érdekesség: Akar falyamatasan as lahat magyaral baszalna, i misik migyir migis migirti, higy mit is ikirink möndönö ö mösök mögyörnök. (Kiss Dénes nyomán). | |||
Tekintsük a következő mondatot: Szóljatok már nekik, hogy majd hívjanak meg engemet. Próbáljuk meg lefordítani az általunk ismert nyelvekre! Utána pedig fogalmazzuk meg ezt kicsit tömörebben, magyarul: meghívattathatnátok. Fordítsuk le ezt is! | |||
Próbáljuk meg megérteni, milyen előnyökkel és hátrányokkal jár a terjengősség: | |||
Az biztos, hogy ha a fenti mondatot egy zajos telefonvonalon mondjuk ki, a beszélgető partnerünk sokkal könnyebben megérti, és kisebb eséllyel érti félre, mintha az azt helyettesítő egyetlen szót mondanánk ki. Az egyetlen szóból álló változatból ha csak egy töredéknyi rész is elvész, a hallgató már biztosan nem érti meg a kérésünket. Ha jól hall minket, akkor is bizonyára gyorsabban, biztosabban felfogja a kívánságunkat, mintha az egyébként frappánsan megfogalmazott egyetlen szót mondtuk volna ki. Az tény azonban, hogy az üzenet hosszában jelentős különbség van. | |||
Tekintsük a 6. ábrát, amin a jövő heti lottószámokat súgta meg nekünk valaki. Kár, hogy a papír úgy elmaszatolódott, hogy alig olvasható. Szerencsénkre azonban ugyanaz az adat kétféleképpen is a papíron volt: számjegyekkel és szövegesen. A két sor információtartama pontosan megegyezett, de jól látszik, hogy a hosszabb, redundánsabb adattárolási mód nagy segítségünkre van abban, hogy a sérült adatokat mégis értelmezni tudjuk. | |||
| |||
Az előző példákból talán úgy tűnik, hogy a redundancia egy előnyös dolog. Ez az esetek egy jelentős részében így is van. Ha valamely értékes adatunk elvész, például az iskolában felejtjük a jegyzetünket, felbecsülhetetlen érték, ha volt belőle másolat (fénymásolat). | |||
Sok esetben azonban hátrányt jelenthet: senki nem szereti a sokat fecsegő embereket. | |||
Az adatbázisunkban tárolt adatok redundanciájára kissé másféleképpen kell tekintenünk. Az adatbázis néhány fájlban tárolja összes adatát, és olyan típusú adatvesztés, mint ami egy elmosódó kézírásnál vagy zajos telefonbeszélgetésnél megtörténhet, a számítógépes környezetben nem fordulhat elő. Ezért nem is ilyen típusú redundanciában kell gondolkodnunk, ha az adataink visszanyerhetőségén gondolkodunk. Arra az lesz a jó megoldás, hogy például mentést, másolatot készítünk a teljes adatbázisról, így hiba esetén sem veszhetnek el az adataink. A napi szinten használt adatbázisunkban a redundancia azonban sok esetben csak nehézségeket okoz, ezért tanuljuk meg a redundanciát jól kézben tartani és számunkra hasznosítani. | |||
Tekintsük 7. ábrát, amin egy több szempontból rosszul tervezett táblát mutatunk be. Fogalmazzunk meg minél több konkrét problémát a táblaszerkezettel kapcsolatosan! | |||
| |||
A 7. ábrán például a következő problémákat találhatjuk: | |||
| |||
A továbbiakban azzal foglalkozunk, milyen szisztematikus módszerrel lehet elkerülni, illetve javítani az itt bemutatott adatbázis-tervezési hibákat. | |||
Normalizálás | |||
Ugyanarra a feladatra több, egymástól kisebb vagy nagyobb mértékben különböző adatmodell tervezhető. Ezek a modellek nem egyformán "jók": különböző hatékonyságúak és tartalmazhatnak bizonyos logikátlanságokat, (szépség)hibákat, amelyek a működés hatékonyságát csökkenthetik. A relációs modell megtervezésekor a fizikai megvalósítás hatékonyságára illetve a kezelés hibalehetőségeire, hatékonyságára is gondolni kell. |
A normalizálás az az adatbázis-tervezési folyamat, ami során a relációs adatmodellnek jól megfelelő, optimálisnak tekinthető táblaszerkezetet hozunk létre. |
A normalizálás célját úgy is megfogalmazhatjuk, hogy olyan táblákat hozzunk létre, amikben csak a kulcsra vonatkozó tényeket tárolunk. | |||
A normalizálás eredménye: áttekinthető, praktikusan használható, redundancia-mentes táblák. A redundancia megszüntetését általában táblák (több táblára történő) felbontásával érjük el (dekompozíció). A normalizálás többlépcsős, egymásra épülő folyamat, és fontos észrevenni, hogy az ajánlásokat, bár az esetek nagy többségében javítják az adatbázis minőségét, "nem kötelező" minden esetben maradéktalanul elfogadni: lehetnek speciális esetek, amikor tudatosan úgy döntünk, hogy mégis egy redundáns, valamely normálformának ellentmondó megoldás mellett maradunk. Emiatt is, és a normalizálási lépések maradéktalan betartása esetén is több különböző, de egyformán jó megoldás is születhet, nincs "legjobb" megoldás. | |||
Több normálforma ismert, a tananyagban a három legegyszerűbbel foglalkozunk. | |||
Első normálforma | |||
Tekintsük a 8. ábrát. Könyvek szerzőjét és címét tároljuk a táblában. | |||
| |||
Mielőtt tovább olvasnánk, próbáljuk magunk megfogalmazni, mi a baj ezzel a táblaszerkezettel! | |||
A tábla, ha így próbálnánk meg használni, sokféle problémát felvet: semmiképp nem praktikus, hogy több különböző (összesen háromféle) adatelem egyetlen mezőben szerepel - Például, hogyan fogunk tudni a szerző nevére keresni? Egyszerű szóelőfordulás-kereséssel megtalálnánk a címben a szerző nevét tartalmazó, épp róla szóló könyveket is. Hasonlóan az eredeti és magyarra fordított cím is összekeveredhet - a használt kettőspont és a zárójelezés sem megoldás, mert ezek bármelyike szerepelhet magában a címben is. Ezekre a problémákra javasol triviális megoldást az első normálformának nevezett szabály: ne használjunk olyan mezőt, amiben több érték szerepel egymás mellett. |
Első normálformában van a tábla, ha teljesül, hogy minden mezője elemi értéket hordoz. |
Ezen egyszerű szabály alapján a 9. ábrán látható táblát alakíthatjuk ki: új mezők létrehozásával elemi értékek tárolására való mezőket hoztunk létre. Figyeljük meg, hogy az elemiség megítélése szubjektív és feladatfüggő: más jó megoldás is lehetett volna, mi most ezt választottuk. | |||
Mielőtt tovább olvasna, találjon ki másik megoldást is és fogalmazza meg, annak milyen előnye van a bemutatottal szemben! | |||
Másik módja lehet az elemi mezők kialakításának, ha a szerzők neveivel sokat foglalkozunk a feladatunkban, valószínűleg érdemes a vezetéknevet és keresztnevet külön mezőbe rendezni. Így sokkal könnyebb lesz a névre vonatkozó kereséseket, vagy a szerzők vezetékneve szerinti ábécésorrendben történő listázást megoldani. Gondolnunk kell azonban mindenre: ha külön tárolunk kereszt- és vezetéknevet, meg kell terveznünk, mit csinálunk a kettőnél több szóból álló szerzőnevekkel, és fontos, hogy a nevek eredeti írási sorrendjét is tároljuk (mint köztudott, különböző nemzetek különböző sorrendben használják családi és utóneveiket). | |||
| |||
9. ábra | |||
A következőkben tekintsünk egy bonyolultabb példát: az egyetemi teremfoglalás rendszeréhez (teremórarend) tervezzük meg az adatmodellt. Tegyük fel, korábban egy Excel táblázatban tárolt lista jelentette a nyilvántartást, tekintsük most ezt kiindulópontnak (10. ábra). | |||
| |||
10. ábra | |||
Az előzőek alapján az egy mezőben tárolt, de önmagában is jelentéssel bíró adatokat külön mezőkbe rendezzük, ahogyan az a 11. ábrán látható. Ezzel teljesítettük is az első normálformát. | |||
| |||
11. ábra | |||
Második normálforma | |||
A normalizálás következő lépésében már az egyes mezők kulcs-szerepét is figyelembe kell vennünk. Határozzuk meg tehát, mi lehet kulcs ebben a táblában: teremfoglalásról lévén szó, kulcs a terem és az időpont azonosítója együttesen. (Az előző ábrákon az időpont jelölése még nem is szerepelt, ezentúl jelöljük, a példán látható K5 pedig kedd 5. órát jelenti.) A kulcsmezőket a továbbiakban vastagított mezőnévvel jelöljük. A táblánk, kicsit átalakítva jelenleg tehát a 12. ábra szerint néz ki: | |||
|
Második normálformában van a tábla, ha az első normálforma teljesül és minden nem-kulcs mező függ a teljes kulcstól. |
A mezők tartalma már elemi, de a nem-kulcs mezők több esetben is nem a teljes kulcstól függenek. Például, a teremméret, mint nem-kulcs mező, nem a teljes kulcstól (Előadóterem + Időpont) függ, hanem a kulcsnak csak egy részétől - ezeket az állapotokat kell most megszüntetnünk. Erre a kézenfekvő megoldás a több táblára bontás (idegen szóval dekompozíció), amivel könnyen elérhetjük, hogy minden tábla minden nem-kulcs mezője valóban csak a kulcsmezőtől (vagy kulcsmezőktől) függjön. Ezt láthatjuk a 13. ábrán. | |||
| |||
Harmadik normálforma |
Harmadik normálformában van a tábla, ha a második normálforma teljesül és nincs függőség a nem-kulcs mezők között. |
A 13. ábra második táblázatán épp ezt a függőséget látjuk! A tantárgyak neve és kódja között természetesen van összefüggés, a tárgy neve függ a tárgykódtól. A kézenfekvő megoldás ismét a több táblára bontás, mégpedig úgy, hogy az eredeti táblában idegen kulcsként az új tábla kulcsát helyezzük el (14. ábra). | ||
| ||
14. ábra | ||
További bonyolultabb esetekkel és az azok problémáit kiküszöbölő normálformákkal nem foglalkozunk. Jegyezzük meg, hogy az első három normálformát 1NF, 2NF és 3NF formában szokták rövidíteni. |
Leckezáró kérdések, feladatok | |||||||||||||
1. Melyik kijelentés igaz a több-több kapcsolatra?
![]() | |||||||||||||
2. Melyik kijelentés igaz a Descartes szorzatra?
![]() | |||||||||||||
3. Mely adattípus való szöveges adat tárolására?
![]() | |||||||||||||
4. Mi jellemző az elsődleges kulcsra?
![]() | |||||||||||||
5. Mi jellemző az indexre?
![]() | |||||||||||||
6. Mely kijelentés igaz az adatbázis NULL értékére?
![]() | |||||||||||||
7. Mi a logikai IGAZ/HAMIS értékek tárolására szolgáló típus neve? ![]() | |||||||||||||
8. Jelölje meg, melyik állítás igaz!
![]() | |||||||||||||
9. Minimálisan hány mezője kell, hogy legyen egy táblának? ![]() | |||||||||||||
10. Jelölje be az igaz állításokat:
![]() |