Adatbázis létrehozása a második normál formában
Az elmúlt hónapban áttekintettük az adatbázistáblázat normalizálását. Először az adatbázis normalizálásának alapelveit vitattuk meg. Legutóbb az első normál formában (1NF) meghatározott alapvető követelményeket vizsgáltuk. Most folytassuk útjukat és fedjük le a második normál forma (2NF) elveit.
Emlékezzünk a 2NF általános követelményeire:
- Távolítsa el az asztal több sorát érintő adatok alcsoportjait, és helyezze őket külön táblázatokba.
- Hozzon létre kapcsolatokat az új táblák és elődeik között külföldi kulcsokkal.
Ezeket a szabályokat egy egyszerű utasításban lehet összefoglalni: a 2NF megpróbálja csökkenteni a redundáns adatok mennyiségét egy táblázatban, kibontva, új táblázatokba helyezve, és létrehozza a kapcsolatokat a táblák között.
Nézzünk egy példát. Képzeljen el egy olyan online áruházat, amely az ügyféladatokat az adatbázisban tárolja. Lehetséges, hogy az alábbi elemekkel rendelkező Ügyfelek egy táblázattal rendelkeznek:
- CustNum
- Keresztnév
- Vezetéknév
- Cím
- Város
- Állapot
- postai irányítószám
A táblázat rövid áttekintése kis mennyiségű redundáns adatot tár fel. A "Sea Cliff, NY 11579" és "Miami, FL 33157" bejegyzéseket kétszer tároljuk. Nos, ez nem feltétlenül túlságosan nagy mennyiségű tárhelynek tűnik a mi egyszerű példánkban, de képzeljük el az elpazarolt helyet, ha több ezer sor került a táblánkba. Ezenkívül, ha a Sea Cliff irányítószámát megváltoztatnánk, akkor az adatbázisban sok helyen meg kell változtatnunk a változást.
Egy 2NF-kompatibilis adatbázis-struktúrában ezt a felesleges információt kivonjuk és egy külön táblázatban tároljuk. Az új táblánk (a ZIP-oknak nevezzük) a következő mezőket tartalmazhatja:
- postai irányítószám
- Város
- Állapot
Ha szuperhatékonyak akarunk lenni, előzetesen kitölthetjük ezt a táblázatot - a posta minden könyvtárat és városi / állami kapcsolatát tartalmazza. Biztosan találkozott olyan helyzetben, ahol az ilyen típusú adatbázist használják. A megrendelést igénylő személy először megkérte az irányítószámot, majd ismerte a várost és az államot, ahonnan hívott. Ez az elrendezés csökkenti a kezelői hibát és növeli a hatékonyságot.
Most, hogy eltávolítottuk az ismétlődő adatokat az Ügyfelek táblából, megelégedettünk a második normál űrlap első szabályával. Még mindig külföldi kulcsot kell használnunk ahhoz, hogy összekapcsoljuk a két táblát. A kapcsolat létrehozásához a ZIP-kódot (az elsődleges kulcsot a ZIP-táblából) használjuk. Itt van az új ügyfelek táblázat:
- CustNum
- Keresztnév
- Vezetéknév
- Cím
- postai irányítószám
Most minimalizáltuk az adatbázisban tárolt redundáns információ mennyiségét, és szerkezetünk második normál formában van!
Ha szeretné biztosítani adatbázisának normalizálását, tanulmányozza a mi további cikkeinket ebben a sorozatban:
- Az adatbázis normalizálási alapjai
- Adatbázis behelyezése az első normál űrlapba
- Az adatbázis létrehozása a második normál űrlapon
- Az adatbázist harmadik normál űrlapba helyezve