DBMS normalizálás: 1NF, 2NF, 3NF adatbázis példa

Normalizálás dióhéjban

A normalizálás az adatbázis strukturálásának folyamata a redundancia csökkentése és a konzisztencia javítása érdekében. Egyszerűen fogalmazva, a nagy, rendezetlen táblázatokat kisebb, jól szervezett táblázatokra bontja. Ez biztosítja az adatok logikus tárolását, így az adatbázisok hatékonyak, könnyen karbantarthatók, és mentesek a duplikációtól vagy hibáktól.

Mi az adatbázis normalizálás?

Adatbázis normalizálása egy adatbázis-tervezési technika, amely csökkenti az adatredundanciát, és kiküszöböli az olyan nemkívánatos jellemzőket, mint a beszúrási, frissítési és törlési anomáliák. A normalizálási szabályok a nagyobb táblákat kisebb táblákra osztják, és kapcsolatok segítségével összekapcsolják őket. Az SQL-ben a normalizálás célja a redundáns (ismétlődő) adatok kiküszöbölése és az adatok logikai tárolásának biztosítása.

A feltaláló a relációs modell Edgar Codd az első normálforma bevezetésével javasolta az adatok normalizálásának elméletét, és folytatta az elmélet kiterjesztését a második és harmadik normálformával. Later csatlakozott Raymond F. Boyce-hoz, hogy kidolgozza a Boyce-Codd normálforma elméletét.

Miért van szükségünk normalizációra?

Normalizálás nélkül az adatbázisok gyorsan inkonzisztenssé és redundánssá válnak. Problémák, mint például behelyezési rendellenességek (hiányos rekordok nem adhatók hozzá), frissítési anomáliák (az egyik helyen bekövetkező változások nem tükröződnek mindenhol), és deléciós anomáliák (az adatok véletlen eltávolítása értékes információkat töröl) gyakran előfordul. A normalizálás kiküszöböli ezeket a problémákat, biztosítva az adatok integritását, csökkentve a duplikációt és egyszerűsítve az adatbázis-kezelést.

Milyen típusú normálformák vannak a DBMS-ben?

Íme az SQL normál űrlapjainak listája:

• 1NF (első normál forma): Biztosítja, hogy az adatbázistábla úgy legyen megszervezve, hogy minden oszlop atomi (oszthatatlan) értékeket tartalmazzon, és minden rekord egyedi legyen. Ez kiküszöböli az ismétlődő csoportokat, így az adatokat táblázatokba és oszlopokba rendezi.
• 2NF (második normál forma): Az 1NF-re építve El kell távolítanunk a redundáns adatokat egy olyan táblából, amelyet több sorra alkalmazunk. és külön táblázatokba helyezve őket. Megköveteli, hogy az összes nem kulcs attribútum teljes mértékben működjön az elsődleges kulcson.
• 3NF (harmadik normál forma): Kibővíti a 2NF-et azáltal, hogy biztosítja, hogy az összes nem kulcs attribútum ne csak teljesen működőképes legyen az elsődleges kulcson, hanem független is legyen egymástól. Ez kiküszöböli a tranzitív függőséget.
• BCNF (Boyce-Codd normál forma): A 3NF finomítása, amely a 3NF által nem kezelt anomáliákat kezeli. Ez megköveteli, hogy minden meghatározó kulcs jelölt legyen, biztosítva a normalizálási szabályok még szigorúbb betartását.
• 4NF (negyedik normál forma): A többértékű függőségek kezelése. Gondoskodik arról, hogy egy rekordban ne legyen több független, többértékű tény egy entitásról.
• 5NF (ötödik normál forma): Más néven „Projekciós csatlakozási normálforma” (PJNF), ez az információ rekonstrukciója kisebb, eltérően elrendezett adatdarabokból.
• 6NF (hatodik normál forma): Elméleti és nem széles körben alkalmazott. Az időbeli adatokkal foglalkozik (az időbeli változások kezelése) a táblák további bontásával, hogy kiküszöböljön minden nem időbeli redundanciát.

Az adatnormalizálás elmélete in MySQL a szerver még fejlesztés alatt áll. Például még a 6-on is vannak viták^th Normál forma. A legtöbb gyakorlati alkalmazásban azonban a normalizálás a 3-ban éri el a legjobbat^rd Normál forma. Az alábbiakban bemutatjuk a normalizálás fejlődését az SQL elméletekben.

Adatbázis normalizálás példákkal

adatbázis Normalizálási példa esettanulmány segítségével könnyen megérthető. Tegyük fel, hogy egy videokönyvtár adatbázist tart fenn a kikölcsönzött filmekről. Az adatbázis normalizálása nélkül az összes információt egy táblázatban tároljuk, az alábbiak szerint. Értsük meg a normalizálási adatbázist normalizálási példával és megoldással:

Itt látod Filmek Kölcsönözve oszlop több értékkel rendelkezik. Most térjünk át az 1. normál formákra:

Első normál forma (1NF)

• A táblázat minden cellájának egyetlen értéket kell tartalmaznia.
• Minden rekordnak egyedinek kell lennie.

A fenti táblázat az 1NF-ben

1NF példa

Mielőtt továbblépnénk, értsünk meg néhány dolgot:

Mi az a KULCS az SQL-ben

A KEY SQL-ben A tábla rekordjainak egyedi azonosítására használt érték. Az SQL KEY egyetlen oszlop vagy több oszlop kombinációja, amely a tábla sorainak vagy sorainak egyedi azonosítására szolgál. Az SQL-kulcs az ismétlődő információk azonosítására szolgál, és segít kapcsolatot létesíteni az adatbázisban lévő több tábla között.

Megjegyzés: A táblázat azon oszlopait, amelyek NEM a rekord egyedi azonosítására szolgálnak, nem kulcs oszlopoknak nevezzük.

Mi az elsődleges kulcs?

Az elsődleges egy oszlopos érték, amely az adatbázisrekord egyedi azonosítására szolgál.

A következő attribútumokkal rendelkezik

• A elsődleges kulcs nem lehet NULL
• Az elsődleges kulcs értékének egyedinek kell lennie
• Az elsődleges kulcs értékeit ritkán kell megváltoztatni
• Új rekord beszúrásakor az elsődleges kulcsnak értéket kell adni.

Mi az az összetett kulcs?

Az összetett kulcs egy több oszlopból álló elsődleges kulcs, amely a rekord egyedi azonosítására szolgál

Adatbázisunkban két Robert Phil nevű személy szerepel, de ők különböző helyeken élnek.

Ezért a rekord egyedi azonosításához a teljes név és a cím megadására is szükségünk van. Ez egy összetett kulcs.

Térjünk át a 2NF második normálformára

Második normál forma (2NF)

• 1. szabály – Légy az 1NF-ben
• 2. szabály – Egyoszlopos elsődleges kulcs, amely funkcionálisan nem függ a jelölt kulcskapcsolatok egyik részhalmazától sem

Nyilvánvaló, hogy nem léphetünk előre, hogy egyszerű adatbázisunkat 2-ben készítsük el^nd Normalizálási forma, hacsak nem particionáljuk a fenti táblázatot.

Az 1NF táblázatunkat két táblázatra osztottuk, ti. 1. és 2. táblázat. Az 1. táblázat a tagok adatait tartalmazza. A 2. táblázat a kölcsönzött filmekkel kapcsolatos információkat tartalmaz.

Új oszlopot vezettünk be Membership_id néven, amely az 1. tábla elsődleges kulcsa. A rekordok egyedileg azonosíthatók az 1. táblázatban a tagsági azonosító segítségével

Adatbázis – Idegen kulcs

A 2. táblázatban a Tagsági_azonosító az idegen kulcs

Az idegen kulcs egy másik tábla elsődleges kulcsára hivatkozik! Segít összekapcsolni a táblázatokat

• Az idegen kulcs neve eltérhet az elsődleges kulcsától
• Biztosítja, hogy az egyik tábla soraiban a másikban is legyenek megfelelő sorok
• Az elsődleges kulccsal ellentétben nem kell egyedinek lenniük. Leggyakrabban nem
• Az idegen kulcsok nullák lehetnek, még akkor is, ha az elsődleges kulcsok nem

Miért van szüksége idegen kulcsra?

Tegyük fel, hogy egy kezdő beszúr egy rekordot a B táblázatba, mint pl

Csak olyan értékeket illeszthet be az idegen kulcsba, amelyek a szülőtábla egyedi kulcsában vannak. Ez segíti a hivatkozási integritást.

A fenti probléma megoldható, ha a 2. táblázat tagsági azonosítóját az 1. tábla tagsági azonosítójának idegen kulcsaként deklaráljuk.

Most, ha valaki olyan értéket próbál beszúrni a tagsági azonosító mezőbe, amely nem létezik a szülőtáblában, hibaüzenet jelenik meg!

Mik azok a tranzitív funkcionális függőségek?

Egy tranzitív funkcionális függőség Ha nem kulcsfontosságú oszlopot módosít, a többi nem kulcs oszlop megváltozását okozhatja

Tekintsük az 1. táblázatot. A nem kulcsfontosságú Teljes név oszlop megváltoztatása megváltoztathatja az Üdvözlet értéket.

Térjünk át a 3NF-re

Harmadik normál forma (3NF)

• 1. szabály – Légy az 2NF-ben
• 2. szabály – Nincs tranzitív funkcionális függősége

Ahhoz, hogy a 2NF-táblánkat 3NF-be helyezzük, ismét fel kell osztanunk az asztalunkat.

3NF példa

Az alábbiakban egy 3NF-példa látható az SQL adatbázisban:

Ismét felosztottuk az asztalainkat, és létrehoztunk egy új táblázatot, amely az üdvözléseket tárolja.

Nincsenek tranzitív funkcionális függőségek, ezért a táblázatunk 3NF-ben van

A 3. táblázatban az üdvözlő azonosító az elsődleges kulcs, az 1. táblázatban pedig az üdvözlés azonosítója idegen a 3. táblázatban szereplő elsődleges kulcstól.

A mi kis példánk most olyan szinten van, amelyet nem lehet tovább bontani, hogy magasabb normál formájú normalizálást érjünk el a DBMS-ben. Valójában már magasabb normalizációs formákban van. Az összetett adatbázisokban általában külön erőfeszítésekre van szükség az adatok normalizálásának következő szintjeire való átlépéshez. A következőkben azonban röviden tárgyaljuk a DBMS normalizálásának következő szintjeit.

Boyce-Codd normál forma (BCNF)

Még akkor is, ha egy adatbázis a 3-ban van^rd Normál forma, mégis előfordulnának anomáliák, ha egynél több van Jelölt Kulcs.

Néha a BCNF-et más néven is említik 3.5 Normál forma.

Negyedik normál forma (4NF)

Ha egyetlen adatbázistábla-példány sem tartalmaz két vagy több független és többértékű adatot, amelyek leírják a releváns entitást, akkor ez a 4.^th Normál forma.

Ötödik normál forma (5NF)

5-ben van egy táblázat^th Normál Form csak akkor, ha 4NF-ben van, és nem bontható fel számtalan kisebb táblára adatvesztés nélkül.

Hatodik normál forma (6NF) javasolt

6^th A Normal Form nem szabványosított, de az adatbázis-szakértők már egy ideje tárgyalnak róla. Remélhetőleg egyértelmű és szabványosított definíciónk lesz a 6-ra^th Normál forma a közeljövőben…

Milyen előnyei vannak a normalizálásnak?

• Az adatok konzisztenciájának javítása: A normalizálás biztosítja, hogy minden adat csak egy helyen kerül tárolásra, csökkentve az inkonzisztens adatok esélyét. Az adatok frissítése során csak egy helyen kell frissíteni, biztosítva a következetességet.
• Adatredundancia csökkentése: A normalizálás segít kiküszöbölni az ismétlődő adatokat azáltal, hogy több, egymáshoz kapcsolódó táblázatra osztja fel azokat. Ez tárhelyet takaríthat meg, és hatékonyabbá teheti az adatbázist.
• A lekérdezés teljesítményének javítása: A normalizált adatbázisok gyakran könnyebben lekérdezhetők. Mivel az adatok logikusan vannak rendszerezve, a lekérdezések optimalizálhatók, hogy gyorsabban futhassanak.
• Az adatok értelmesebbé tétele: A normalizálás magában foglalja az adatok értelmes és intuitív módon történő csoportosítását. Ez megkönnyítheti az adatbázis megértését és használatát, különösen azok számára, akik nem tervezték az adatbázist.
• Csökkentse az anomáliák esélyét: Az anomáliák olyan problémák, amelyek adatok hozzáadása, frissítése vagy törlése során fordulhatnak elő. A normalizálás csökkentheti ezeknek az anomáliáknak az esélyét azáltal, hogy biztosítja az adatok logikus rendszerezését.

Mik a normalizálás hátrányai?

• Fokozott összetettség: A normalizálás összetett kapcsolatokhoz vezethet. Az idegen kulcsokkal rendelkező táblák nagy száma nehezen kezelhető, ami zavart okozhat.
• Csökkentett rugalmasság: A szigorú normalizálási szabályok miatt előfordulhat, hogy kevésbé rugalmasan tárolják azokat az adatokat, amelyek nem felelnek meg ezeknek a szabályoknak.
• Megnövekedett tárolási igény: Míg a normalizálás csökkenti a redundanciát, előfordulhat, hogy több tárhelyet kell lefoglalni a további táblák és indexek elhelyezéséhez.
• Teljesítmény rezsi: Több asztal összekapcsolása költséges lehet a teljesítmény szempontjából. Minél normalizáltabbak az adatok, annál több csatlakozásra van szükség, ami lelassíthatja az adatok visszakeresési idejét.
• Adatvesztés kontextus: A normalizálás az adatokat külön táblákra bontja, ami az üzleti környezet elvesztéséhez vezethet. A kapcsolódó táblák vizsgálata szükséges egy adat kontextusának megértéséhez.
• Szakértői tudás szükséges: A normalizált adatbázis megvalósítása megköveteli az adatok, az adatok közötti kapcsolatok és a normalizálási szabályok mély megértését. Ez szaktudást igényel, és időigényes lehet.

Ennyi az SQL normalizálása!!!

GYIK

Összegzésként