Az adatbázisok relációsak. A relációs adatbázis fogalma

A számítógépes technológia megjelenése korunk információs forradalmat jelentett az emberi tevékenység minden területén. De annak biztosítása érdekében, hogy az összes információ ne váljon szükségtelen szemetet a globális interneten, feltérképezött egy adatbázisrendszert, amelyben az anyagokat rendszerezték és szisztematizálták, aminek következtében könnyen megtalálhatók és később feldolgozhatók. Három fő típus létezik - adatbázisok hozzárendelése relációs, hierarchikus, hálózathoz.

Alapvető modellek

Visszatérve az adatbázisok eredetére, érdemes megemlíteni, hogy ez a folyamat meglehetősen bonyolult volt, a programozható információfeldolgozó berendezések fejlesztéséből származik. Ezért nem meglepő, hogy jelenleg a modellek száma több mint 50, de a legfontosabb hierarchikus, relációs és hálózati, amelyek még mindig széles körben használatosak a gyakorlatban. Mi az?

A hierarchikus adatbázisnak fa szerkezete van, és különböző szintű adatokból áll össze, amelyek között vannak linkek. Az adatbázis hálózati modellje összetettebb sablon. A struktúrája egy hierarchikus struktúrához hasonlít, és a rendszer bővül és finomítható. A különbség az, hogy a hierarchikus modell örökletes adatait csak egy őse társíthatja, és a hálózatnak több is lehet. A relációs adatbázis szerkezete sokkal bonyolultabb. Ezért részletesebben kell szétszerelni.

A relációs adatbázis alapfogalma

Ezt a modellt az 1970-es években fejlesztette ki Dr. Edgar Codd. Ez egy logikailag strukturált tábla, ahol az adatokat leíró területek, egymás közötti kapcsolataik, a rájuk végzett műveletek, és legfontosabbak azok a szabályok, amelyek garantálják az integritását. Miért van relációs modell? Ez az adatok közötti kapcsolatokon alapul (a latin relatio-tól). Az ilyen típusú adatbázisok számos definícióval rendelkeznek . Az információkkal kapcsolatos relációs táblázatok sokkal egyszerűbbek a feldolgozáshoz és a feldolgozáshoz, nem pedig hálózathoz vagy hierarchikus modellhez. Hogyan lehet ezt tenni? Elég, ha ismerjük a relációs táblázatok jellemzőit, modellstruktúráját és tulajdonságait.

Az alapelemek modellezése és összeállítása

A saját DBMS létrehozásához használnia kell az egyik modellezési eszközt, gondolnia kell arra, hogy milyen adatokkal kell dolgoznia, tervezési táblázatokkal és relációs egy- és többszörös kapcsolatokkal kell rendelkeznie az adatok között, ki kell töltenie az entitáscellákat és meg kell adnia az elsődleges, külföldi kulcsokat.

A modellezési táblák és a relációs adatbázisok tervezése ingyenes eszközökkel történik, mint például a Workbench, a PhpMyAdmin, a Case Studio, a dbForge Studio. A részletes tervezés után mentse el a grafikusan kész relációs modellt, és fordítsa le a kész SQL-kódba. Ebben a szakaszban elkezdheti dolgozni az adatok rendezésével, feldolgozásával és rendszerezésével.

A relációs modellhez kapcsolódó jellemzők, struktúra és kifejezések

Minden forrás saját elemeit írja le elemeire, így kevésbé zavartan szeretnék kis jelzést adni:

• Relációs címke = entitás;
• Layout = attributes = field names = az entitások oszlopainak címe;
• Entity instance = tuple = record = címsor;
• Attribútum értéke = entitás cell = mező.

A relációs adatbázis tulajdonságainak megismeréséhez meg kell tudni, hogy mely alapvető összetevőkből áll, és mire szolgálnak.

1. A lényeg. A relációs adatbázis táblája lehet egy, és lehet egy egész táblázatcsoport, amely a tárolt adatoknak köszönhetően jellemzi a leírt objektumokat. Rögzített számú mezőt és változó számú rekordot tartalmaznak. A relációs adatbázis modelltábla sorokat, attribútumokat és elrendezést tartalmaz.
2. A rekord változó számú sor, amely a leírt objektumot jellemző adatokat jeleníti meg. A nyilvántartásokat a rendszer automatikusan számozza.
3. Az attribútumok olyan adatok, amelyek az entitás oszlopainak leírását mutatják.
4. Field. Egy entitások oszlopát képviseli. Számuk egy rögzített érték, amelyet a táblázat létrehozásakor vagy módosításakor állítanak be.

Most, tudva a táblázat alkotóelemeit, megkeresheti a relációs modell-adatbázis tulajdonságait:

• A relációs DB egységei kétdimenziósak. Ennek köszönhetően könnyű elvégezni a különböző logikai és matematikai műveleteket.
• A relációs táblázatban az attribútumok és rekordok értékeinek sorrendje önkényes lehet.
• Egy relációs táblán belüli oszlopnak saját névvel kell rendelkeznie.
• Az entitás oszlopban lévő összes adat határozott hosszúságú és azonos típusú.
• Bármely bejegyzés lényegében egy adatelemnek tekintendő.
• A vonalak alkotóelemei jellegüknél fogva egyediek. A relációs entitásban nincsenek azonos sorok.

A relációs DBMS tulajdonságai alapján nyilvánvaló, hogy az attribútumértékeknek ugyanolyan típusúnak és hossznak kell lenniük. Vegyük fontolóra az attribútumok értékeinek jellemzőit.

A relációs adatbázis mezők fő jellemzői

A mezők nevének egyedinek kell lennie egy entitáson belül. Az attribútumtípusok vagy a relációs adatbázis mezők leírják, hogy mely kategóriák adatait tárolja az entitások mezőiben. A relációs adatbázis mezőnek rögzített méretűnek kell lennie, karakterekkel számolva. Az attribútumértékek paraméterei és formátuma meghatározza az adatok kijavításának módját. Még mindig létezik olyan koncepció, mint a "maszk" vagy a "beviteli sablon". Célja, hogy meghatározza az adatbevitel konfigurációját az attribútumértékre. Elengedhetetlen, hogy hibaüzenet jelenjen meg a mezőben, amikor hibás adattípus van írva. Emellett bizonyos korlátozásokat írnak elő a mezőelemekre - az adatbevitel pontosságának és pontosságának ellenőrzésére. Az attribútumnak van néhány kötelező értéke, amelyet egyértelműen meg kell adni az adatokkal. Egyes attribútum sorok NULL értékekkel tölthetők meg. A mező attribútumaiban üres adatokat adhat meg. A hibaüzenethez hasonlóan vannak olyan értékek, amelyeket a rendszer automatikusan betöltött - ez az alapértelmezett adat. Az adatok keresésének felgyorsítása érdekében indexelt mezőt célszerű használni.

Kétdimenziós relációs adatbázis-séma

Az SQL-t használó modellmenedzsment- rendszer részletes megértése érdekében a legjobb példa a rendszer példáján keresztül történő megfontolására. Már tudjuk, mi a relációs adatbázis. A rekord minden táblázatban egy adatelem. Az adatok redundanciájának megakadályozása érdekében normalizálási műveleteket kell végrehajtani.

Alapvető szabályok a relációs entitás normalizálására

1. A relációs táblának a mező nevének egyedinak, egyedinak kell lennie (az első normál forma 1NF).

2. Egy olyan táblázathoz, amely már csökkent 1NF-re, minden nem azonosító oszlop neve függ a táblázat egyedi azonosítójától (2NF).

3. A teljes táblázatban, amely már szerepel a 2NF-ben, minden egyes nem azonosított mező nem függhet egy másik, nem azonosított érték elemétől (3NF entitás).

Adatbázisok: a táblák közötti relációs kapcsolatok

A relációs táblák között két fő kapcsolat létezik :

• „Egy-sok”. Ha az 1. táblázat egyik kulcsbejegyzése megegyezik a második entitás több példányával. A vonal egyik végén lévő kulcs ikon azt jelzi, hogy az entitás az "egyik" oldalán van, a vonal második végét gyakran a végtelen szimbólum jelöli.

• "Többszörös" kapcsolat alakul ki, ha látszik egy logikai interakció egy entitás több sorának, egy másik táblában lévő rekordsorral.
• Ha egy entitás összekapcsolása két entitás között van, akkor azt jelenti, hogy egy tábla kulcsazonosítója jelen van a másik entitásban, akkor az egyik táblát el kell távolítani, felesleges. De néha biztonsági okokból a programozók szándékosan osztják a két entitást. Ezért hipotetikusan létezik egy egy-egy kapcsolat.

A relációs adatbázisban lévő kulcsok létezése

Az elsődleges és másodlagos kulcsok határozzák meg az adatbázis potenciális kapcsolatát. A relációs adatmodell kommunikációnak csak egy lehetséges kulcsa lehet, ez az elsődleges kulcs. Mit képvisel? Az elsődleges kulcs egy entitás oszlop vagy attribútumkészlet, amelyen keresztül elérheti egy adott sor adatait. Egyedülállónak, egyedinek kell lennie, és mezői nem tartalmazhatnak üres értékeket. Ha az elsődleges kulcs csak egy attribútumból áll, akkor egyszerűnek nevezhető, egyébként komponens lesz.

Az elsődleges kulcson kívül van egy külső kulcs is. Sokan nem értik a köztük lévő különbséget. Elemezzük részletesebben a példákat. Így van két asztal: "Dean irodája" és "Diákok". A "Deanery" lényege a következőket tartalmazza: "Student ID", "Name" és "Group". A "Diákok" tábla olyan attribútumértékekkel rendelkezik, mint a "Név", "Csoport" és "Átlagérték". Mivel a hallgatói azonosító nem lehet több diák számára, ez a mező lesz az elsődleges kulcs. A "Diákok" táblázat "Név" és "Csoportja" ugyanaz lehet több ember számára, de a diák azonosító számát a "Deccan" entitásról, így idegen kulcsként is használhatók.

Példa egy relációs adatbázis modellre

Az egyértelműség érdekében egy egyszerű példát adunk egy relációs adatbázis modellre, amely két entitást tartalmaz. Van egy "Deccan" nevű tábla.

Kapcsolatokat kell létesítenie ahhoz, hogy teljes relációs adatbázist kapjon. Az "IN-41" rekord, mint például az "IN-72", többször is jelen lehet a decanter lemezen, de a diákok vezetékneve, utóneve és patronymikája ritkán is egybeeshet, ezért ezek a mezők semmilyen módon nem válhatnak elsődleges kulcsokká. Mutassuk meg a "diákok" lényegét.

Mint látható, a relációs adatbázis mezők típusai teljesen más. Mind digitális, mind szimbolikus bejegyzések vannak. Ezért az attribútum beállításaiban meg kell adni az egész, a char, a vachar, a dátum és mások értékeit. A "Deccan" táblában csak a hallgatói azonosító egyedi érték. Ez a mező az elsődleges kulcs. A "Diákok" szervezet nevét, csoportját és telefonszámát a diák azonosítójára hivatkozó idegen kulcsként lehet venni. A kommunikáció létrejött. Ez egy példa az egy-egy modellre. Hipotetikusan az egyik táblázat felesleges, könnyen összekapcsolható egy entitásba. A diákok azonosítószámai nem váltak általánosan ismertté, valójában két asztal létezik.