Egy megfelelően tervezett adatbázis naprakész, pontos információkhoz juttatja felhasználóját. Mivel a megfelelő tervezés létfontosságú az adatbázissal végzett munka céljának elérésében, a jó tervezés alapelveit megtanulni hasznos befektetés. A folyamat végén így jó eséllyel az igényeinek megfelelő adatbázis fog rendelkezésére állni, amelyben a szükséges módosításokat könnyen elvégezheti.
Ez a cikk útmutatóul szolgál az asztali adatbázisok tervezéséhez. Bemutatja, hogyan döntheti el, milyen információkra van szüksége, hogyan oszthatja a szükséges információkat megfelelő táblákra és oszlopokra, és hogyan kapcsolhatja össze a táblákat. Érdemes elolvasni a cikket még az első asztali adatbázis létrehozása előtt.
Tartalom
Adatbázisokkal kapcsolatos terminológia
Az Accesstáblákban tárolja az információt – sorokra és oszlopokra osztott listákban, amelyek egy könyvelő jegyzettömbjére vagy egy számolótáblára emlékeztetnek. Egy egyszerű adatbázisban előfordulhat, hogy csak egy tábla található. A legtöbb adatbázis azonban több táblát igényel. Egy tábla például a termékek adatait tárolja , egy másik a megrendelők adatait, egy harmadik pedig a vevők adatait.
A sorok szakszerű megnevezése rekord, az oszlopoké pedig mező. Rekordok használatával releváns információkat tárolhat következetesen egy adott témában. A mező egyetlen adatot tárol – egy elemtípust, amely minden rekordban megjelenik. A Termékek táblában például minden sor vagy rekord egy termékről hordoz információt. Minden hasáb vagy mező az adott termékről tárol információt, például a nevét vagy az árát.
Milyen a jó adatbázisterv?
Az adatbázis tervezését bizonyos alapelvek szerint kell végezni. Az első alapelv, hogy az ismétlődő információ (redundáns adat) rossz, mivel helyet pazarol, és növeli a hibák és az ellentmondások előfordulásának esélyét. A második alapelv, hogy az információ helyessége és teljessége fontos. Ha az adatbázis helytelen információkat tartalmaz, az adatbázis alapján készült jelentések is helytelenek lesznek. Az ilyen jelentések alapján hozott döntések tehát téves információkon alapulnak.
A jól megtervezett adatbázisra ezért a következők jellemzőek:
-
Az információkat tematikus táblákba rendezi, így csökken az adatok ismétlődése.
-
A táblákban található információk szükség szerinti egyesítéséhez szükséges információk az Access rendelkezésére állnak.
-
Segíti az információ pontosságának és épségének megőrzését.
-
Megfelel az adatfeldolgozási és a jelentési igényeknek.
A tervezési folyamat
A tervezés az alábbi lépésekből áll:
-
Az adatbázis céljának meghatározása
Ez felkészíti a további lépésekre.
-
A szükséges információk megkeresése és rendszerezése
Gyűjtsön össze minden információt, amelyet rögzíteni szeretne az adatbázisban, például a termékek nevét és rendelési számát.
-
Az információk táblákra osztása
Az információt ossza fel nagyobb entitásokra vagy témákra (például Termékek és Rendelések). Ezután minden témából tábla lesz.
-
Információs elemek oszlopokká alakítása
Döntse el, milyen információkat szeretne tárolni az egyes táblákban. Minden elem mezővé alakul, és a táblában oszlopként fog megjelenni. Egy Alkalmazottak nevű táblában például a Vezetéknév és a Felvétel dátuma mezők szerepelhetnek.
-
Elsődleges kulcsok megadása
Határozza meg az egyes táblák elsődleges kulcsát. Az elsődleges kulcsok az egyes sorokat egyedileg azonosító oszlop. Elsődleges kulcs lehet például a Termékazonosító vagy a Rendelésazonosító mező.
-
Táblakapcsolatok beállítása
A táblákat áttekintve döntse el, hogyan kapcsolódnak az egyes táblák adatai a többi tábla adataihoz. Ha egyértelművé szeretné tenni a táblák kapcsolatát, létrehozhat új mezőket a táblákban, vagy létrehozhat új táblákat.
-
A terv finomítása
Győződjön meg róla, hogy hibáktól mentes a terv. Hozza létre a táblákat, és adjon hozzá néhány rekordnyi mintaadatot. Ellenőrizze, hogy a táblák a kívánt eredményeket adják-e. Szükség esetén módosítsa a tervet.
-
A normalizációs szabályok alkalmazása
Az adatnormalizációs szabályokat alkalmazva ellenőrizze, hogy a táblák szerkezete megfelelő-e. Módosítsa a táblákat, ha szükséges.
Az adatbázis céljának meghatározása
Célszerű írásba foglalni az adatbázis célját – a rendeltetését, hogyan szeretné használni, illetve hogy ki fogja használni. Kisebb vállalkozások adatbázisának célját például a következőképpen határozhatja meg: „A vevőadatbázis a vevőkkel kapcsolatos információkat tárolja, levelezéshez és jelentések létrehozásához.” Ha az adatbázis összetettebb, és sokan használják, ami gyakran előfordul egy nagyobb cégnél, az adatbázis céljának megfogalmazása lehet akár egy bekezdés hosszúságú is, vagy még több, és tartalmazhatja azt is, ki, mikor és hogyan fogja használni az adatbázist. A lényeg, hogy egy konkrét feladatmeghatározás álljon rendelkezésére, amelyhez a folyamat során mindvégig visszatérhet. Egy ilyen meghatározás döntéshozatalkor segít szem előtt tartani a célokat
A szükséges információk megkeresése és rendszerezése
A szükséges információk megkeresését és rendszerezését kezdje a meglévő információkkal. Előfordulhat például, hogy a megrendeléseket egy főkönyvben vezeti, a vevők információit pedig iratszekrényben, űrlapokon tárolja. Gyűjtse össze ezeket a dokumentumokat, és készítsen egy listát a bennük található információtípusokról (például űrlapokon megadandó adatokat). Ha nincsenek űrlapjai, képzelje el, hogy egy olyan űrlapot tervez, amelyben a vevők adatait tárolja. Milyen információkra kérdezne rá az űrlapon? Milyen kitöltendő mezőket hozna létre? Határozza meg és sorolja fel ezeket az elemeket. Tegyük fel, hogy a vevők adatait jelenleg kartotéklapokon tárolja. A lapokat áttekintve láthatja, hogy minden egyes lapon egy vevőre vonatkozó név, cím, város, megye, irányítószám és telefonszám adat szerepel. Minden ilyen adat egy-egy oszlop lehet a táblában.
A lista készítésekor nem kell amiatt aggódni, hogy elsőre nem lesz tökéletes. Csak írjon le mindent, ami az eszébe jut. Ha mások is használják majd az adatbázist, kérdezze meg őket is. Később még finomíthatja a listát.
Ezután gondolja át, milyen jelentéseket hozna létre, vagy milyen levelezést folytatna az adatbázis alapján. Előfordulhat például, hogy egy eladási jelentést szeretne létrehozni, amely területenként összesíti az eladásait, vagy egy leltár-összefoglalót, amely az aktuális leltárkészletet mutatja. Létrehozhat ezenkívül formaleveleket is, amelyekkel értesítheti a vevőket akciókról, vagy felajánlhat egy kedvezményt. Gondolatban tervezze meg a jelentést, képzelje el, hogyan nézne ki. Milyen információkat foglalna a jelentésbe? Sorolja fel őket. Tegye meg ugyanezt a formalevelekkel, és bármilyen jelentéssel, amelyre szüksége lehet.
A jelentések és a levelezés megtervezése segíthet meghatározni az adatbázisban tárolni kívánt adatok körét. Tegyük fel, hogy van rendszeres, e-mail útján küldött hírlevele, amelyre a vásárlók fel- és leiratkozhatnak, és szeretne egy listát nyomtatni a feliratkozottakról. Ezt az információt egy „E-mail küldése” oszlopban tárolhatja a vevők adatait tartalmazó táblában. Az egyes vevők esetében ebben a mezőben Igen vagy Nem értéket állíthat be.
Az e-mailek küldéséhez egy újabb mezőre lesz szükség a rekordokban. Ha a vevő szeretne e-maileket kapni Öntől, ismerni kell a vevő e-mail címét. Minden vevő e-mail-címét rögzíteni kell tehát.
Érdemes minden jelentés vagy kimeneti lista prototípusát összeállítani, és átgondolni, hogy milyen elemekre lesz szüksége a jelentés elkészítéséhez. Egy űrlaplevél vizsgálatakor például felmerülhet néhány dolog. Ha megfelelő megszólítást szeretne hozzáadni – például a "Mr.", "Mrs." vagy "Ms." sztringet, amely üdvözlést indít el, létre kell hoznia egy megszólítási elemet. Emellett általában a "Kedves Mr. Smith" betűvel kezdi a levelet, nem pedig a "Kedves. Mr. Sylvester Smith". Ez azt sugallja, hogy általában az utónévtől elkülönítve szeretné tárolni a vezetéknevet.
Fontos megjegyezni, hogy minden információt érdemes annak legkisebb használható részeire bontani. A név esetében ahhoz, hogy a vezeték- és az utónév is azonnal rendelkezésére álljon, két részre kell bontani a nevet – Vezetéknév és Keresztnév oszlopokra. Ha a vezetéknév szerint szeretne rendezni egy jelentést, akkor jó, ha a vezetéknév külön van tárolva. Általánosságban elmondható, hogy ha valamilyen adat alapján szeretne rendezni, keresni, számításokat végezni vagy jelentést készíteni, azt az adatot külön mezőben kell tárolnia.
Gondolja végig, mely kérdésekre szeretne választ kapni az adatbázisból. Például mennyit adott el a múlt hónapban a kiemelt termékből? Hol élnek a legjobb ügyfelei ? Ki a beszállítója a legkeresettebb termékének? Az ilyen kérdések figyelembe vétele segíthet meghatározni, milyen további adatokat rögzítsen.
Az információk begyűjtése után készen áll a következő lépésre.
Az információk táblákra osztása
Az információk táblákra történő felosztásához válassza ki a nagyobb entitásokat vagy témákat. Egy termékértékesítési adatbázis információinak begyűjtése és rendszerezése után például az előzetes lista a következőképp nézhet ki:
A nagyobb entitások itt a termékek, a szállítók, a vevők és a megrendelések. Logikus tehát ezzel a négy táblával kezdeni: az egyik a termékek, a másik a szállítók, a harmadik a vevők, a negyedik pedig a megrendelések adatait tartalmazza. Ez ugyan nem a teljes lista, de jó kiindulási pont. Ezt a listát később tovább finomíthatja, amíg egy jól működő tervet nem kap.
Amikor először tekinti át az előzetes listát, egyszerűbbnek tűnhet az adatokat egyetlen táblában elhelyezni, a fentebb leírt négy helyett. Rögvest megtudhatja, hogy ez miért rossz ötlet. Képzeljen el például egy ilyen táblát:
Ebben az esetben minden sor tartalmazza a termék és a szállító adatait is. Mivel egy szállító több terméket is szállíthat, a szállító neve és címe sokszor ismétlődik. Ezzel lemezterületet pazarol. Érdemes inkább külön Szállítók táblában rögzíteni a szállítók információit, majd erre a táblára hivatkozni a Termékek táblából.
A fenti terv második problémája akkor merül fel, ha meg szeretné változtatni egy szállító adatait. Tegyük fel, hogy meg kell változtatnia egy szállító címét. Mivel a cím több helyen jelenik meg, ezért előfordulhat, hogy az egyik helyen módosítja a címet, egy másik helyen viszont elfelejti megtenni. Ha a szállító címét egyetlen helyen tárolja, a probléma megoldódik.
Próbálja meg úgy tervezni az adatbázist, hogy minden adatot csak egyszer kelljen rögzíteni. Ha azt veszi észre, hogy ugyanazt az adatot egynél több helyen adja meg, akkor a szóban forgó adatot helyezze külön táblába.
Végül tegyük fel, hogy az egyik borgazdaság csak egy terméket szállít, és Ön szeretné törölni a terméket, de a szállító nevét és címét meg szeretné tartani. Hogyan törölheti egy termék rekordját a szállító adatainak elvesztése nélkül? A fenti táblában ezt nem teheti meg. Mivel minden rekord az adott termékkel kapcsolatos adatok mellett a szállító adatait is tartalmazza, nem törölheti az egyiket a másik törlése nélkül. Ha külön tárolná az adatokat, a táblát ketté kell osztania: egy tábla tárolja a termékek adatait, egy másik a szállítókét. Így ha törli egy termék rekordját, akkor csak a termék adatait törli, a szállító adatait nem.
Miután kiválasztotta egy tábla témáját, ügyeljen arra, hogy a tábla oszlopai csak a tábla témájával kapcsolatos adatokat tároljanak. Egy Termékek tábla például csak a termékek adatait tárolja. Mivel a szállító címe a szállítóval kapcsolatos, nem a termékkel, ezért az a Szállítók táblába tartozik.
Információs elemek oszlopokká alakítása
A tábla oszlopainak meghatározásához döntse el, milyen információkat szeretne nyilvántartani a tábla témájával kapcsolatban. Egy Vevők táblában például a Név, Cím, Város/Irányítószám, E-mail küldése, E-mail-cím oszlopok kezdetnek megfelelnek. A táblában minden rekord ugyanazokból az oszlopokból áll, tehát minden cím esetében mentheti a Név, Cím, Város/Irányítószám, E-mail küldése, E-mail-cím információkat. A Cím oszlop például a vevők címét tartalmazza. Minden rekord egy vevő adatait tartalmazza, és a Cím mező az adott vevő címét tartalmazza.
Ha meghatározta az egyes táblák kezdeti oszlopait, tovább finomíthatja azokat. Tanácsos lehet például a vevő nevét két külön oszlopban, vezeték- és utónévként tárolni, hogy külön ezek alapján is rendezhesse, kereshesse vagy indexelhesse a rekordokat. Ugyanígy a címet is felbonthatja öt külön összetevőre: ország/régió, megye, irányítószám, város, cím – ezeket is érdemes lehet külön oszlopokban tárolni. Ha például a megye alapján szeretne keresni, szűrni vagy rendezni, ezt az információt külön oszlopban kell tárolnia.
Gondolja át azt is, hogy az adatbázis csak hazai adatokat fog tartalmazni, vagy előfordulhatnak külföldi adatok is. Ha például külföldi címeket szeretne tárolni, célszerű a Megye helyett Régió mezőt használni, mert ez a mező tárolhatja más országok vagy régiók közigazgatási egységeit is. Ugyanígy a ZIP-kód helyett az Irányítószám jobb választás, ha külföldi címeket szeretne tárolni.
Az alábbi lista segítséget nyújthat az oszlopok meghatározásában.
-
Ne adjon hozzá számított adatokat
A legtöbb esetben nem érdemes számítások eredményét táblákban tárolni. Amikor szükség van a számításokra, az Access majd elvégzi őket. Tegyük fel, hogy van egy Megrendelt termékek jelentése, amely megmutatja, hogy hány darabot rendeltek meg az adatbázisban szereplő egyes termékkategóriákból. Ugyanakkor egyik táblában sincs Megrendelt mennyiség nevű, részösszeget megjelenítő oszlop. Ehelyett a Termékek táblában található egy Megrendelt mennyiség oszlop, amely minden termék esetében megmutatja, hogy mennyit rendeltek az adott termékből. Ezeket az adatokat felhasználva az Access kiszámolja a részösszegeket minden alkalommal, amikor kinyomtatja a jelentést. A részösszegeket ne tárolja táblában.
-
Az információkat a legkisebb logikus egységekben tárolja
Előfordulhat, hogy egyszerűbbnek tűnik a személyek teljes nevét tárolni egy mezőben, vagy a termékek nevét együtt tárolni azok leírásával. Ha azonban két külön információt egyesít egy mezőben, később nehéz lesz visszanyerni a külön adatokat. Próbálja logikus részekre bontani az információkat, például tárolja külön mezőben a vezeték- és utóneveket, vagy a termékek nevét, kategóriáját és leírását.
Ha kidolgozta az összes tábla adatoszlopait, készen áll meghatározni az egyes táblák elsődleges kulcsát.
Elsődleges kulcsok megadása
Ideális esetben minden táblában van egy oszlop vagy több oszlop kombinációja, amelynek alapján a tábla összes sora egyedileg azonosítható. Ez gyakran egy egyedi azonosítószám, például egy alkalmazott azonosítószáma vagy egy sorozatszám. Az adatbázis-kezelés terminológiája ezt az információt a tábla elsődleges kulcsának nevezi. Az Access az elsődlegeskulcs-mezők alapján gyorsan egymáshoz tudja társítani a különböző táblákban tárolt adatokat.
Ha már van egy egyedi azonosítója egy táblában, például egy termékszám, amely egyedileg azonosítja a katalógusban szereplő összes terméket, ezt az azonosítót használhatja elsődleges kulcsként – de csak akkor, ha biztos, hogy az oszlop értékei mindig, minden rekord esetében különbözőek lesznek. Az elsődlegeskulcs-mezőben nem ismétlődhetnek az értékek. Ezért nem érdemes példáué emberek nevét használni elsődleges kulcsként, mivel a nevek nem egyediek. Könnyen előfordulhat, hogy két azonos nevű ember szerepel a táblában.
Az elsődleges kulcsnak mindig kell hogy legyen értéke. Ha előfordulhat, hogy egy oszlop értéke hozzárendelés nélküli vagy ismeretlen (hiányzó érték) lesz, nem használhatja elsődleges kulcs létrehozásához.
Mindig érdemes olyan elsődleges kulcsot választani, amelynek értéke nem fog megváltozni. Egynél több táblát használó adatbázisban egy tábla elsődleges kulcsát hivatkozásként használhatja más táblákban. Ha az elsődleges kulcs megváltozik, a módosítást mindenhol alkalmazni kell, ahol a kulcsra hivatkozik. Ha olyan elsődleges kulcsot használ, amelynek értéke nem fog változni, akkor csökken az esélye annak, hogy az elsődleges kulcs nincs szinkronban a többi, rá hivatkozó táblával.
Gyakran egy tetszőleges egyedi számot használnak elsődleges kulcsként. Minden megrendeléshez hozzárendelhet például egy egyedi megrendelésszámot. Ennek a számnak az egyetlen rendeltetése a megrendelés azonosítása. Ha ezt megadta, az értéke sosem fog megváltozni.
Ha nem tud olyan oszlopról vagy oszlopok kombinációjáról, amely jó elsődleges kulcs lenne, célszerű egy Számláló adattípusú mezőt használni. A Számláló adattípusú mezőkben az Access automatikusan meghatároz egy értéket. Az ilyen azonosító nem tartalmaz az általa képviselt rekordhoz tartozó tényleges információt. Az információt nem hordozó azonosítók ideálisak az elsődleges kulcs szerepre, mert sosem változnak. A tényleges információt tartalmazó elsődleges kulcsok – például egy ügyfél neve vagy telefonszáma – értékei megváltozhatnak, amikor a tényleges információ is változik.
1. Egy Számláló adattípusú oszlop gyakran jól használható elsődleges kulcsként. Nincs két azonos termékazonosító.
Bizonyos esetekben előfordulhat, hogy két vagy több mező együtt szolgáltatja egy tábla elsődleges kulcsát. A Rendelés részletei tábla például, amely megrendelések adatait tartalmazza, két oszlopot használhat az elsődleges kulcsban: Rendelésazonosító és Termékazonosító. Ha egy elsődleges kulcs egynél több oszlopot használ, összetett kulcsnak is nevezzük.
A termékértékesítési adatbázisban minden táblában létrehozhat egy Számláló típusú mezőt, hogy elsődleges kulcsként használja: a Termékek táblában Termékazonosító, a Rendelések táblában Rendelésazonosító, a Vevők táblában Vevőazonosító és a Szállítók táblában Szállítóazonosító.
Táblakapcsolatok létrehozása
Miután az adatokat táblákra osztotta, újra össze kell rendeznie ezeket az adatokat értelmezhető információkká. Az itt látható űrlap adatai például több táblából származnak.
1. Az űrlap adatai a Vevők táblából...
2. ...az Alkalmazottak táblából...
3. ...a Rendelések táblából...
4. ...a Termékek táblából...
5. ...és a Rendelés részletei táblából származnak.
Az Access relációsadatbázis-kezelő rendszer. Relációs adatbázisokban az információt külön, tematikus táblákba rendezik. Az információkat ezután táblakapcsolatokkal szükség szerint össze tudják rendezni.
Egy-a-többhöz kapcsolat létrehozása
Vegyük a következő példát: a termékértékesítési adatbázisban van két tábla, a Szállítók és a Termékek. Egy szállító tetszőleges számú terméket szállíthat. Ennek megfelelően a Szállítók tábla egy szállítójához több terméket is társíthat a Termékek táblában. A Szállítók és a Termékek tábla között tehát egy-a-többhöz kapcsolat áll fenn.
Az adatbázisban úgy jeleníthet meg egy-a-többhöz kapcsolatot, hogy a kapcsolat „egy” oldalán található elsődleges kulcsot új oszlopként (vagy oszlopokként) hozzáadja a kapcsolat „több” oldalán található táblához. Ebben az esetben például a Szállítók tábla Szállítóazonosító oszlopát adja hozzá a Termékek táblához. Az Access a Termékek táblában található szállítóazonosító segítségével azonosítja az egyes termékek szállítóját.
A Termékek tábla Szállítóazonosító oszlopát idegen kulcsnak nevezik. Az idegen kulcs egy másik tábla elsődleges kulcsa. A Termékek tábla Szállítóazonosító oszlopa azért idegen kulcs, mert egyben a Szállítók tábla elsődleges kulcsa is.
A kapcsolódó táblák egyesítésének alapját az elsődleges és idegen kulcsok párosítása adja. Ha nem biztos abban, hogy mely táblákban kellene közös oszlopoknak lenniük, egy egy-a-többhöz kapcsolat létrehozásával biztosíthatja, hogy a két táblának szüksége legyen egy közös oszlopra.
Több-a-többhöz kapcsolat létrehozása
Vegyük például a Termékek és a Rendelések tábla közötti kapcsolatot.
Egyetlen megrendelés több termékre is szólhat. Ugyanakkor egy termék több megrendelésben is szerepelhet. Ezért a Rendelések tábla egyes rekordjaihoz több rekord is kapcsolódhat a Termékek táblában. Ugyanígy a Termékek tábla egyes rekordjaihoz a Rendelések tábla több rekordja is kapcsolódhat. Az ilyen típusú kapcsolatot több-a-többhöz kapcsolatnak nevezik, mert egy termékre több megrendelés is szólhat, és egy megrendelés több termékre is szólhat. Jegyezze meg, hogy a több-a-többhöz kapcsolatok csak úgy ismerhetők fel, ha mindkét oldalukat megvizsgálja.
A két tábla tárgya – megrendelések és termékek – egymással több-a-többhöz kapcsolatban áll. Ez azonban gondot okoz. A probléma megértéséhez képzelje el, mi történne, ha megpróbálná létrehozni a két tábla közötti kapcsolatot úgy, hogy a Termékazonosító mezőt hozzáadja a Rendelések táblához. Ha megrendelésenként több terméket szeretne rögzíteni, egy megrendeléshez több rekordra lenne szükség a Megrendelések táblában. Több sorban kellene ismételnie egyetlen megrendeléshez tartozó adatokat – az adatbázisa nem lenne hatékony, és pontatlan adatok jelenhetnének meg benne. Ugyanez a probléma jelenne meg, ha a Rendelésazonosító mezőt adná hozzá a Termékek táblához – egy termékhez több rekord tartozna a Termékek táblában. Hogyan orvosolható a probléma?
A megoldás egy harmadik tábla (úgynevezett illesztőtábla) létrehozása, amely a több-a-többhöz kapcsolatot két egy-a-többhöz kapcsolatra bontja le. Mindkét tábla elsődleges kulcsát el kell helyezni a harmadik táblában. Így a harmadik tábla rögzíti a kapcsolat minden előfordulását (példányát).
A Rendelés részletei tábla minden egyes rekordja egy megrendelés egy tételét jeleníti meg. A Rendelés részletei tábla elsődleges kulcsa két mezőből áll – a Rendelések és a Termékek tábla idegen kulcsából. A Rendelésazonosító egyedül nem lenne használható a tábla elsődleges kulcsaként, mert egy megrendelés több tételből állhat. A Rendelésazonosító egy megrendelés minden tételénél ugyanaz, így a mező nem egyedi értékeket tartalmaz. A Termékazonosító sem használható önmagában, mivel egy termék több különböző megrendelésben is szerepelhet. De a két mező együtt minden rekordban egyedi értéket alkot.
A termékértékesítési adatbázisban a Rendelések és a Termékek tábla nem állnak közvetlen kapcsolatban egymással. A Rendelés részletei táblán keresztül azonban közvetetten kapcsolatban állnak. A megrendelések és a termékek közötti több-a-többhöz kapcsolat az adatbázisban két egy-a-többhöz kapcsolatként jelenik meg:
-
A Rendelések tábla és a Rendelés részletei tábla egy-a-többhöz kapcsolatban áll egymással. Az egyes megrendelések egynél több tételt tartalmazhatnak, de minden tétel csak egy megrendeléshez tartozik.
-
A Termékek tábla és a Rendelés részletei tábla egy-a-többhöz kapcsolatban állnak. Minden termékhez több tétel van társítva, de minden tétel csak egy termékre vonatkozik.
A Rendelés részletei táblában egy bizonyos megrendelésben szereplő összes terméket azonosítani tudja. Ugyanígy azonosíthatja egy bizonyos termékre vonatkozó összes megrendelést.
A Rendelés részletei tábla bevezetése után a táblák és mezők listája így nézhet ki:
Egy-az-egyhez kapcsolat létrehozása
A kapcsolatok egy másik típusa az egy-az-egyhez kapcsolat. Tegyük fel, hogy valamilyen kiegészítő termékinformációt szeretne tárolni, amelyre csak ritkán van szükség, vagy csak néhány termékre vonatkozik. Mivel ritkán van szüksége az információra, és mivel ha a Termékek táblában tárolná az információt, akkor minden olyan terméknél, amelyre nem vonatkozik ilyen információ, üres mező jönne létre, ezért ezt az információt külön táblában tárolja. Ahogyan a Termékek táblában, itt is a Termékazonosító mezőt használja elsődleges kulcsként. A kiegészítő tábla és a Termékek tábla között egy-az-egyhez kapcsolat áll fenn. A Termékek tábla minden egyes rekordjához egyetlen megegyező rekord létezik a kiegészítő táblában. Ha egy ilyen kapcsolatot azonosít, a két táblában lennie kell egy közös mezőnek.
Ha úgy látja, hogy az adatbázisában egy-az-egyhez kapcsolat létrehozására van szükség, gondolja át, hogy lehetséges-e a két táblában szereplő információt egy táblában egyesíteni. Ha ezt nem szeretné megtenni, például mert sok üres helyet eredményezne, az alábbi lista bemutatja, hogyan kell a kapcsolatot megvalósítani az adatbázisban:
-
Ha a két tábla témája ugyanaz, valószínűleg megvalósíthatja a kapcsolatot úgy, hogy a két táblában ugyanazt az elsődleges kulcsot használja.
-
Ha a két tábla témája és elsődleges kulcsa különbözik, válassza ki az egyik táblát a kettő közül, és szúrja be a másik tábla elsődleges kulcsát idegen kulcsként.
A táblák közötti kapcsolat meghatározásával ellenőrizheti, hogy a megfelelő táblák és oszlopok szerepelnek-e az adatbázisban. Egy-az-egyhez vagy egy-a-többhöz kapcsolat esetében a kapcsolatban szereplő táblákban egy közös oszlopnak (vagy oszlopoknak) kell szerepelnie. Több-a-többhöz kapcsolat esetében egy harmadik táblának kell rögzítenie a kapcsolatot.
A terv finomítása
Ha létrehozta a szükséges táblákat, mezőket és kapcsolatokat, töltse fel a tábláit mintaadatokkal, és próbáljon dolgozni az információkkal: hozzon létre lekérdezéseket, vegyen fel új rekordokat stb. Így felfedezheti a lehetséges problémákat – létrehozhat például egy új oszlopot, amelyről megfeledkezett a tervezés során, vagy észreveheti, ha egy táblát ketté kell osztani, hogy megszüntesse az adatok ismétlődését.
Ellenőrizze, hogy az adatbázis választ ad-e a felmerülő kérdésekre. Készítse el az űrlapok és a jelentések vázlatos terveit, hogy megállapíthassa, a várt adatokat mutatják-e. Keressen felesleges adatismétlődéseket, és ha talál ilyet, módosítsa a tervet.
Az új adatbázis kipróbálása közben valószínűleg észre fog venni hiányosságokat. Íme néhány dolog, amit érdemes ellenőrizni:
-
Nem hagyott ki oszlopokat? Ha igen, az adatok a meglévő táblákba tartoznak? Ha valami mással kapcsolatos az információ, új táblára lehet szükség. Hozzon létre minden nyilvántartani kívánt adat számára egy oszlopot. Ha az információt nem lehet más oszlopokból kiszámítani, valószínűleg új oszlopra lesz szüksége.
-
Vannak felesleges oszlopok, amelyeket más meglévő mezőkből is ki lehet számítani? Ha egy adatot ki tud számolni meglévő oszlopokból – például a kedvezményes árat az eredeti árból –, általában jobb kiszámítani, mint új oszlopot létrehozni.
-
Van olyan tábla, amelyben ismétlődő információkat kell beírnia? Ha igen, azt a táblát valószínűleg fel kell osztani két táblára, és egy-a-többhöz kapcsolatot kell létrehozni köztük.
-
Van olyan táblája, amelyben sok mező van, kevés rekord, és sok üres mező az egyes rekordokban? Ha igen, próbálja meg áttervezni a táblát, hogy kevesebb mezőből és több rekordból álljon.
-
Minden információegységet lebontott annak legkisebb használható részeire? Minden olyan adatot, amely alapján rendezni, keresni, számítani vagy jelenteni szeretne, tároljon külön oszlopban.
-
A táblák minden oszlopa az adott tábla témájával kapcsolatos információt tárol? Ha egy oszlop olyan információt tartalmaz, amely nem kapcsolatos a tábla témájával, az oszlop egy másik táblába tartozik.
-
A táblák közötti összes kapcsolat képviselve van közös mezővel vagy egy harmadik táblával? Az egy-az-egyhez és az egy-a-többhöz kapcsolatok közös oszlopokat igényelnek. A több-a-többhöz kapcsolatok harmadik táblát igényelnek.
A Termékek tábla finomítása
Tegyük fel, hogy a termékértékesítési adatbázis minden terméke egy általános kategóriába tartozik (például üdítőitalok, fűszerek vagy halak). A Termékek tábla tartalmazhat egy mezőt, amely megjeleníti az egyes termékek kategóriáját.
Tegyük fel, hogy az adatbázis tervének vizsgálata és finomítása után úgy dönt, hogy a kategória nevével együtt tárolja a leírását is. Ha hozzáad egy Kategórialeírás mezőt a Termékek táblához, minden, adott kategóriába tartozó termék esetén meg kell ismételnie a kategória leírását – ez nem jó megoldás.
Jobb megoldás, ha a Kategóriákat az adatbázis tárgyává teszi, saját táblával és elsődleges kulccsal. Ezután a Kategóriák tábla elsődleges kulcsát idegen kulcsként hozzáadhatja a Termékek táblához.
A Kategóriák és a Termékek táblák egy-a-többhöz kapcsolatban állnak: egy kategória több termékre vonatkozhat, de minden termékre csak egy kategória vonatkozik.
Amikor áttekinti a táblastruktúráit, keressen ismétlődő csoportokat. Képzeljen el például egy táblát, amely a következő oszlopokat tartalmazza:
-
Termékazonosító
-
Név
-
Termékazonosító1
-
Név1
-
Termékazonosító2
-
Név2
-
Termékazonosító3
-
Név3
Itt minden termék ismétlődő oszlopcsoportokból áll, amelyek csak annyiban különböznek, hogy egy számot adott hozzá az oszlop nevéhez. Ha ilyen módon számozott oszlopokat lát, nézze át újra az adatbázis tervét.
Az ilyen terv több hibát tartalmaz. Először is, ez az adatbázis határt szab a termékek számának. Amint eléri ezt a határt, új oszlopcsoportot kell hozzáadni a táblához, ami komoly adminisztratív feladat.
Egy másik probléma, hogy azok a szállítók, amelyek a maximálisnál kevesebb terméket szállítanak, helyet pazarolnak, mivel a fennmaradó oszlopok üresen maradnak. Az ilyen terv legsúlyosabb hibája, hogy megnehezíti sok feladat elvégzését, például a tábla rendezését vagy indexelését termékazonosító vagy név szerint.
Ha ismétlődő csoportokat lát, nézze át jól a tervet, különös tekintettel a tábla kettéosztásának lehetőségére. A fenti példában a legjobb megoldás két táblát használni, egyet a szállítók és egyet a termékek számára, és a szállítóazonosítóval összekapcsolni őket.
A normalizációs szabályok alkalmazása
A tervezés következő lépéseként alkalmazhatja az adatnormalizációs szabályokat (vagy egyszerűen normalizációs szabályok). Ezeket a szabályokat alkalmazva ellenőrizze, hogy a táblák szerkezete megfelelő-e. A folyamatot, amely során a szabályokat az adatbázisra alkalmazzák, az adatbázis normalizálásának (vagy egyszerűen normalizálásnak) nevezik.
A normalizálás akkor a hasznos igazán, ha már megoldotta az összes adat tárolását, és eljutott egy elsődleges adatbázistervhez. Az eljárás lényege, hogy meggyőződjön róla, az adatokat megfelelően felosztotta az egyes táblákban. A normalizálás azonban nem garantálja, hogy a megfelelő adatokat tárolja.
A szabályokat egymás után alkalmazza, hogy minden lépésben a megfelelő „normálformát” érje el. Általában öt normálformát különböztetnek meg – az elsőtől az ötödikig. Ez a cikk csak az első hárommal foglalkozik, mivel a legtöbb adatbázisterv esetében csak ezekre van szükség.
Első normálforma
Az első normálforma meghatározása, hogy minden sor és oszlop kereszteződésében csak egyetlen érték található, sosem egy értéklista. Egy Ár mezőben például nem tárolhat egynél több árat. Ha az egyes sorok és oszlopok kereszteződésére cellaként gondol, akkor minden cellában csak egy érték szerepelhet.
Második normálforma
A második normálforma követelménye, hogy minden olyan mező, amely nem kulcs, csak a teljes elsődleges kulcsoktól függhet, annak egy részétől nem. Ez a szabály azokra a táblákra vonatkozik, amelyek elsődleges kulcsa egynél több oszlopból áll. Tegyük fel, hogy egy tábla a következő oszlopokat tartalmazza (a Rendelésazonosító és a Termékazonosító együtt alkotja az elsődleges kulcsot):
-
Rendelésazonosító (elsődleges kulcs)
-
Termékazonosító (elsődleges kulcs)
-
Terméknév
Ez a tábla nem felel meg a második normálformának, mivel a Terméknév a Termékazonosítótól függ, a Rendelésazonosítótól nem, így nem a teljes elsődleges kulcstól függ. A Terméknév oszlopot ezért el kell távolítani a táblából. Az oszlop egy másik táblához (Termékek) tartozik.
Harmadik normálforma
A harmadik normálforma nem csak azt követeli meg, hogy a nem kulcsmezők a teljes elsődleges kulcstól függjenek, de azt is, hogy egymástól függetlenek legyenek.
Úgy is fogalmazhatnánk, hogy minden nem kulcsoszlop az elsődleges kulcstól és csak az elsődleges kulcstól függ. Tegyük fel, hogy egy tábla az alábbi oszlopokat tartalmazza:
-
Termékazonosító (elsődleges kulcs)
-
Név
-
Javasolt ár
-
Kedvezményes ár
Tegyük fel, hogy a Kedvezményes ár a javasolt ártól függ. Ez a tábla nem felel meg a harmadik normálformának, mivel egy nem kulcsmező, a Kedvezményes ár, egy másik nem kulcsmezőtől, a Javasolt ártól függ. Az oszlopok függetlensége azt jelenti, hogy bármelyik nem kulcsmező értékét megváltoztathatja anélkül, hogy bármely másik oszlop értékére ez hatással volna. Ha a Javasolt ár mező értékét megváltoztatja, a Kedvezményes ár értéke is ennek megfelelően változik, így megszegi a szabályt. Ebben az esetben a Kedvezményes ár mezőt át kell helyeznie egy másik táblába, amelynek a Javasolt ár az elsődleges kulcsa.
