RELÁCIÓS ADATBÁZIS MODELL: ELEMEK, HOGYAN KELL CSINÁLNI, PÉLDA - TECHNOLÓGIA - 2026

A relációs adatbázismodell egy módszer az adatok strukturálására relációk felhasználásával, rácsszerű struktúrák felhasználásával, oszlopokból és sorokból állva. Ez a relációs adatbázisok fogalmi alapelve. Edgar F. Codd 1969-ben javasolta.

Azóta az üzleti alkalmazások domináns adatbázis-modelljévé vált, összehasonlítva más adatbázismodellekkel, például a hierarchikus, a hálózati és az objektummal.

Forrás: pixabay.com

Codd nem tudta, milyen rendkívül létfontosságú és befolyásoló legyen a relációs adatbázisok platformjaként végzett munkája. A legtöbb ember nagyon ismeri a kapcsolat fizikai kifejezését egy adatbázisban: a táblázatot.

A relációs modellt az az adatbázis határozza meg, amely lehetővé teszi adatelemeinek egy vagy több független táblába csoportosítását, amelyek összekapcsolhatók egymással az egyes kapcsolódó táblák közös mezőinek használatával.

Adatbázis-kezelés

Az adatbázis-tábla hasonló egy táblázathoz. A táblák között létrehozható kapcsolatok azonban lehetővé teszik, hogy a relációs adatbázis nagy mennyiségű adatot hatékonyan tároljon, amely hatékonyan visszakereshető.

A relációs modell célja deklaratív módszer biztosítása az adatok és a lekérdezések meghatározására: a felhasználók közvetlenül deklarálják, hogy az adatbázis mely információkat tartalmaz, és milyen információt akarnak tőle.

Másrészt az adatbázis-kezelő rendszer szoftverére bízza a tárolásra szolgáló adatszerkezetek és a lekérdezések megválaszolására szolgáló visszakeresési eljárás leírását.

A legtöbb relációs adatbázis az SQL nyelvet használja az adatok lekérdezéséhez és meghatározásához. Jelenleg számos relációs adatbázis-kezelő rendszer vagy RDBMS (relacionális adatbázis-kezelő rendszer) létezik, mint például az Oracle, az IBM DB2 és a Microsoft SQL Server.

Jellemzők és elemek

- Az összes adat fogalmi szempontból az adatok rendezett sorba rendezése sorokban és oszlopokban, relációnak vagy táblának nevezve.

- Minden táblázatnak fejlécgel és törzstel kell rendelkeznie. A fejléc egyszerűen az oszlopok listája. A törzs az adatokat kitölti, a táblát kitölti, sorokba rendezve.

- Minden érték skalár. Vagyis a táblázat bármely adott sorában / oszlopában csak egyetlen érték van.

-Méret

Az alábbi ábra egy táblázatot mutat annak alapelemeinek nevével, amelyek a teljes szerkezetet alkotják.

tuple

Minden adatsor egy adatrész, más néven rekord. Mindegyik sor n-es puple, de az "n-" általában elvetésre kerül.

Oszlop

A sablon minden oszlopát attribútumnak vagy mezőnek nevezzük. Az oszlop az adott attribútumhoz tartozó értékhalmazt ábrázolja.

Kulcs

Mindegyik sorban van egy vagy több oszlop, amelyet tábla kulcsnak neveznek. Ez az együttes érték a táblázat összes sorának egyedi. Ezzel a gombbal minden egyes elem egyedileg azonosítható. Vagyis a kulcsot nem lehet lemásolni. Elsődleges kulcsnak hívják.

Másrészt egy idegen vagy másodlagos kulcs a tábla mezője, amely egy másik tábla elsődleges kulcsára utal. Az elsődleges táblázat hivatkozására szolgál.

- Az integritás szabályai

A relációs modell tervezésekor meghatározza az adatbázisban bizonyos feltételeket, amelyeket integritási szabályoknak hívnak.

A kulcs integritása

Az elsődleges kulcsnak egyedinak kell lennie az összes elemre, és nem lehet null (NULL). Ellenkező esetben nem lesz képes egyértelműen azonosítani a sort.

Több oszlopos kulcs esetén ezen oszlopok egyike sem tartalmazhatja a NULL értéket.

Referencia integritása

Minden idegen kulcs értékének meg kell egyeznie a hivatkozott vagy elsődleges táblázat elsődleges kulcsának értékével.

Egy idegen kulcsot tartalmazó sor csak akkor illeszthető be a másodlagos táblába, ha ez az érték létezik egy elsődleges táblában.

Ha a kulcs értéke az elsődleges táblában megváltozik a sor frissítése vagy törlése miatt, akkor a másodlagos táblák összes sorát ezzel az idegen kulcsmal frissíteni kell, vagy törölni kell.

Hogyan lehet relációs modellt készíteni?

-Adatgyűjtés

Az adatbázisban történő tároláshoz össze kell gyűjteni a szükséges adatokat. Ezeket az adatokat különféle táblákra osztják.

Minden oszlophoz meg kell választani a megfelelő adattípust. Például: egész számok, lebegőpontos számok, szöveg, dátum stb.

- Az elsődleges kulcsok meghatározása

Minden táblázathoz oszlopot (vagy néhány oszlopot) kell választani elsődleges kulcsként, amely egyedileg azonosítja a táblázat minden sorát. Az elsődleges kulcsot más táblákra is hivatkozni kell.

- Hozzon létre kapcsolatokat a táblák között

A független, független táblázatokból álló adatbázis kevés célt szolgál.

A relációs adatbázis tervezésénél a legfontosabb szempont a táblák közötti kapcsolatok azonosítása. A kapcsolat típusai:

Egy a sokhoz

Az „Osztálylista” adatbázisban a tanár nullát vagy annál több osztályt taníthat, míg az osztályt egyetlen tanár tanítja. Az ilyen típusú kapcsolatokat egy-egynek nevezik.

Ez a kapcsolat nem ábrázolható egyetlen táblában. Az «Osztályok listája» adatbázisban lehet Tanárok nevû táblázat, amely a tanárokkal kapcsolatos információkat tárolja.

Az egyes tanárok által tanított osztályok tárolásához további oszlopokat hozhat létre, de problémával szembesül: hány oszlopot kell létrehozni.

Másrészt, ha van egy Osztályok nevű táblája, amely egy osztályra vonatkozó információkat tárol, akkor további oszlopokat hozhat létre a tanárral kapcsolatos információk tárolására.

Mivel azonban a tanár sok osztályt taníthat, adatait az Osztályok táblázat számos sorában megismételjük.

Tervezze meg a két táblát

Ezért két táblát kell megterveznie: egy Osztálytáblát az osztályokra vonatkozó információk tárolására, amelynek elsődleges kulcsa a Class_Id, és a Tanárok táblát a tanárokkal kapcsolatos információk tárolására, a Teacher_Id mint elsődleges kulcs.

Az egy-egyhez viszony azután létrehozható, ha az elsődleges kulcsot a Mester táblázatból (Master_Id) tároljuk az Osztályok táblában, az alább látható módon.

Az Osztályok táblázat Master_Id oszlopát idegen kulcsnak vagy másodlagos kulcsnak nevezzük.

A Mester táblázat minden Master_Id értékéhez nulla vagy több sor lehet az Osztályok táblában. Az Osztályok táblázat minden Class_Id értékéhez csak egy sor van a Tanárok táblában.

Sok-sok

A "Termék eladó" adatbázisban az ügyfél megrendelése több terméket tartalmazhat, és egy termék több megrendelésben is megjelenhet. Az ilyen típusú kapcsolatok sokak számára ismertek.

A „Termékértékesítés” adatbázist két táblával indíthatja el: Termékek és Megrendelések. A Termékek táblázat információkat tartalmaz a termékekről, a termék azonosítója az elsődleges kulcs.

Másrészt a Megrendelések táblázat tartalmazza az ügyfél megrendeléseit, az elsődleges kulcs a orderID.

A megrendelt termékeket nem lehet a Megrendelések táblában tárolni, mivel nem tudja, hány oszlopot kell a termékekre fenntartani. Ugyanezen okból a megrendeléseket sem lehet a Termékek táblában tárolni.

A sok-sok kapcsolat támogatásához el kell készítenie egy harmadik táblát, az úgynevezett összekapcsolási táblázatot (OrderDetails), ahol minden sor egy adott sorrendben egy elemet ábrázol.

A OrderDetails táblában az elsődleges kulcs két oszlopból áll: orderID és productID, amelyek minden sort egyedileg azonosítanak.

A OrderDetails táblázat rendelésiID és termékazonosító oszlopai hivatkoznak a Rendelések és termékek táblázatokra. Ezért ők is idegen kulcsok a OrderDetails táblában.

Egyenként

A „Termékek eladása” adatbázisban a terméknek opcionális információkkal is rendelkezhet, például kiegészítő leírás és annak képe. Ha azt a Termékek táblában tartja, sok üres helyet generál.

Ezért egy másik táblát (ProductExtras) lehet létrehozni az opcionális adatok tárolására. Csak egy rekord kerül létrehozásra az opcionális adatokkal rendelkező termékek számára.

A két táblázat, a Termékek és a ProductExtras, egy-egy kapcsolattal rendelkezik. A Termékek táblázat minden sorában legfeljebb egy sor található a ProductExtras táblában. Ugyanazt a termékazonosítót kell használni mindkét tábla elsődleges kulcsaként.

Előny

Szerkezeti függetlenség

A relációs adatbázis modelljében az adatbázis szerkezetének változásai nem befolyásolják az adatokhoz való hozzáférést.

Ha lehetőség van az adatbázis szerkezetének megváltoztatására anélkül, hogy befolyásolnánk a DBMS adatelekhez való hozzáférésének képességét, akkor azt lehet mondani, hogy a szerkezeti függetlenség megtörtént.

Fogalmi egyszerűség

A relációs adatbázis modell fogalmilag még egyszerűbb, mint a hierarchikus vagy hálózati adatbázis modell.

Mivel a relációs adatbázis modell mentesíti a tervezőt az adatok fizikai tárolásának részleteiről, a tervezők az adatbázis logikai nézetére összpontosíthatnak.

Könnyű a tervezés, kivitelezés, karbantartás és használat

A relációs adatbázis modell elérheti az adatok függetlenségét és a szerkezet függetlenségét, ami sokkal könnyebbé teszi az adatbázis megtervezését, karbantartását, kezelését és használatát, mint a többi modellnél.

Ad-hoc lekérdezési kapacitás

A relációs adatbázis-modell óriási népszerűségének egyik fő oka a nagyon erős, rugalmas és könnyen használható lekérdezési képesség jelenléte.

A relációs adatbázismodell lekérdezési nyelve, amelyet strukturált lekérdezési nyelvnek vagy SQL-nek hívnak, valósággá teszi az ad-hoc lekérdezéseket. Az SQL negyedik generációs nyelv (4GL).

A 4GL lehetővé teszi a felhasználó számára, hogy meghatározza, mit kell tennie, anélkül, hogy meghatározná, hogyan kell tennie. Így az SQL segítségével a felhasználók megadhatják, hogy milyen információt szeretnének, és elhagyhatják az információk adatbázisba jutásának részleteit.

hátrányok

Hardver költségek

A relációs adatbázis-modell elrejti annak megvalósításának bonyolultságát és a felhasználói adatok fizikai tárolásának részleteit.

Ehhez a relációs adatbázisrendszerekhez nagyobb teljesítményű hardverekkel és adattároló eszközökkel rendelkező számítógépekre van szükség.

Ezért az RDBMS-nek nagy teljesítményű gépekre van szüksége a zökkenőmentes működéshez. Mivel azonban a modern számítógépek feldolgozási teljesítménye exponenciálisan növekszik, a mai forgatókönyvben a nagyobb feldolgozási teljesítmény igénye már nem nagyon nagy probléma.

A könnyű tervezés rossz tervezést eredményezhet

A relációs adatbázist könnyű megtervezni és használni. A felhasználóknak nem kell tudniuk az adatok fizikai tárolásának komplex részleteit. A hozzáféréshez nem kell tudniuk, hogy az adatok hogyan tárolódnak.

A könnyű tervezés és használat a rosszul megtervezett adatbázis-kezelési rendszerek fejlesztését és megvalósítását eredményezheti. Mivel az adatbázis hatékony, ezek a tervezési hiányosságok nem merülnek fel az adatbázis megtervezésekor és ha csak kevés adat áll rendelkezésre.

Az adatbázis növekedésével a rosszul megtervezett adatbázis lelassítja a rendszert, és a teljesítmény romlásához és az adatok sérüléséhez vezet.

Az «információs szigetek» jelensége

Mint korábban említettük, a relációs adatbázisrendszereket könnyű megvalósítani és használni. Ez olyan helyzetet teremt, amikor túl sok ember vagy részleg hozza létre saját adatbázisát és alkalmazását.

Ezek az információs szigetek megakadályozzák az információk integrációját, ami elengedhetetlen a szervezet zökkenőmentes és hatékony működéséhez.

Ezek az egyedi adatbázisok olyan problémákat is felvetnek, mint az adatok következetlensége, az adatok sokszorosítása, az adatok redundanciája stb.

Példa

Tegyük fel, hogy egy adatbázis található a Szállítók, alkatrészek és szállítmányok tábláiból. A táblázatok és néhány mintarekord felépítése a következő:

A Szállítók táblázat minden sorát egyedi szállítószámmal (SNo) azonosítják, és a táblázat minden sorát egyedileg azonosítják. Hasonlóképpen, minden alkatrész egyedi alkatrészszámmal (PNo) rendelkezik.

Ezenkívül egy szállító / alkatrész kombinációnál nem lehet egynél több szállítás a Szállítmányok táblában, mivel ez a kombináció a szállítmányok elsődleges kulcsa, amely unióstáblának szolgál, mivel sok-sok kapcsolat.

Az Alkatrész- és Szállítmánytáblák közötti kapcsolatot az adja, hogy a PNo mező (cikkszám) közös, és a Szállítók és a Szállítások közötti kapcsolat akkor merül fel, ha az SNo (szállítószám) mező közös.

A szállítmánytáblázat elemzésével információkat szerezhetünk arról, hogy összesen 500 diót küldünk a Suneet és az Ankit szállítóktól, mindegyik 250-et.

Hasonlóképpen összesen 1100 csavart szállítottak három különböző szállítótól. 500 kék csavart szállítottak a Suneet szállítójától. Nincsenek vörös csavarok küldeményei.

Irodalom

1. Wikipedia, a szabad enciklopédia (2019). Relációs modell. Forrás: en.wikipedia.org.
2. Techopedia (2019). Relációs modell. Feltöltve: roofpedia.com.
3. Dinesh Thakur (2019). Relációs modell. Számítógépes megjegyzések. Forrás: ecomputernotes.com.
4. Geeks Geeks számára (2019). Relációs modell. Feltöltve: geeksforgeeks.org.
5. Nanyang Technológiai Egyetem (2019). Gyors üzembe helyezési útmutató a relációs adatbázis-tervezéshez. Feltöltve: ntu.edu.sg.
6. Watt Adrienne (2019). 7. fejezet A relációs adatmodell. BC Nyílt tankönyvek. Feltöltve: opentextbc.ca.
7. Toppr (2019). Relációs adatbázisok és sémák. Forrás: toppr.com.