A normalizálás egy adatbázis-tervezési technika, amelyet egy relációs adatbázis-tábla tervezésére használnak egy magasabb normál formáig. A folyamat progresszív, és az adatbázis magasabb szintű normalizálása csak akkor érhető el, ha a korábbi szinteket teljesítették.
Ez azt jelenti, hogy az adatok nem normális formában (a legkevésbé normalizáltak) és a legmagasabb érték elérésére irányulnak. A normalizálás szintje az első lépés az első normál forma betartásának biztosítása, a második lépés a második normális forma teljesülésének biztosítása, és így tovább a fent említett sorrendben, amíg az adatok nem felelnek meg a hatodik normál formának.
Érdemes azonban megjegyezni, hogy a 4NF-n felüli normál formák elsősorban akadémiai érdeklődésre tartanak számot, mivel a problémák, amelyek megoldására léteznek, a gyakorlatban ritkán jelentkeznek. szándékosan úgy tervezték, hogy ellentmondjon a normális formák többségének. A való életben teljesen lehetséges, hogy kihagyhatunk néhány normalizálási lépést, mert a táblázat nem tartalmaz semmit, ami ellentmondana az adott normális formának. Gyakran előfordul az is, hogy egy normál forma megsértésének kijavítása egy magasabb rendes forma megsértését is kijavítja a folyamat során. Szintén minden táblázatban egy táblázatot választottak a normalizáláshoz, ami azt jelenti, hogy a példa folyamatának végén még mindig lehetnek olyan táblák, amelyek nem felelnek meg a legmagasabb normál formának.
Initial dataEdit
Hagyjon egy adatbázistáblát a következő felépítéssel:
| Cím | Szerző | Szerző Nemzetisége | Formátum | Ár | Tárgy | Oldalak | Vastagság | Kiadó | Kiadó országa | Kiadvány típusa | Műfaj azonosítója | Műfaj neve |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MySQL adatbázis-tervezés és optimalizálás kezdete | Chad Russell | amerikai | keménytáblás | 49.99 | MySQL,
adatbázis, tervezés |
520 | Vastag | Apress | USA | E-könyv | 1 | oktatóanyag |
Ebben a példában feltételezzük, hogy minden könyvnek csak egy szerzője van.
1NFEdit kielégítése
Az 1NF kielégítéséhez a táblázat minden oszlopában szereplő értékeknek atomnak kell lenniük. A kezdeti táblázatban a Subject tartalmaz egy sor tárgyértéket, vagyis nem felel meg.
Az 1NF elérésének egyik módja az lenne, ha a párhuzamosságokat több oszlopra osztaná ismétlődő Subject csoportokkal:
| Cím | Formátum | Szerző | Szerző nemzetisége | Ár | 1. tárgy | 2. tárgy | 3. tárgy | oldal | Vastagság | Kiadó | Kiadó országa | Műfajazonosító | Műfaj neve |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MySQL adatbázis-tervezés és optimalizálás kezdete | Keménytáblás | Chad Russell | amerikai | 49.99 | MySQL | adatbázis | Tervezés | 520 | Vastag | Apress | USA | 1 | oktatóanyag |
Bár most a táblázat formálisan megfelel az 1NF-nek (atomi), a probléma ezzel a megoldással nyilvánvaló – ha egy könyvnek háromnál több tárgya van, ezért nem lehet hozzáadni az adatbázishoz anélkül, hogy megváltoztatná annak szerkezetét. saját táblázataikba. Ebben az esetben ez a Könyv, Tárgy és Kiadó táblákat eredményezné:
| Cím | Formátum | Szerző | Szerző Nemzetisége | Ár | Oldalak | Vastagság | Műfajazonosító | Műfaj neve | Kiadói azonosító |
|---|---|---|---|---|---|---|---|---|---|
| MySQL kezdete Adatbázis-tervezés és optimalizálás | keménytáblás | Chad Russell | amerikai | 49.99 | 520 | Vastag | 1 | Oktatóanyag | 1 |
|
|
A kezdeti adatok egyszerű táblákra történő szétválasztása megszakítaná az adatok közötti kapcsolatot. Ez azt jelenti, hogy meg kell határozni az újonnan bevezetett táblák közötti kapcsolatokat. Figyelje meg, hogy a Könyv táblázat Kiadóazonosító oszlopa egy idegen kulcs, amely felismeri a könyv és a kiadó közötti sokoldalú kapcsolatot.
A könyv sok tantárgyhoz illeszkedhet, valamint egy tantárgy is sok könyvnek felel meg. Ez azt is jelenti, hogy meg kell határozni a sok-sok kapcsolatot, amelyet el kell érni egy linktábla létrehozásával:
|
Egy nem normál formájú táblázat helyett most 4 tábla van, amely megfelel az 1NF-nek.
A 2NFEdit kielégítése
A Book táblának egy jelölt kulcsa van (ami tehát az elsődleges kulcs), a {Title, Format} összetett kulcs. Vegye figyelembe a következő táblázatrészletet:
| Title | Formátum | Szerző | Szerző Nemzetiség | Ár | Oldalak | Vastagság | Műfajazonosító | Műfaj neve | Kiadói azonosító |
|---|---|---|---|---|---|---|---|---|---|
| MySQL adatbázis tervezés és optimalizálás kezdete | keménytáblás | Chad Russell | amerikai | 49.99 | 520 | vastag | 1 | oktatóanyag | 1 |
| MySQL adatbázis tervezés és optimalizálás kezdete | E-könyv | Chad Russell | amerikai | 22.34 | 520 | Vastag | 1 | Oktatóanyag | 1 |
| Az adatbázis-kezelés relációs modellje: 2. verzió | E-könyv | EFCodd | brit | 13.88 | 538 | Vastag | 2 | Népszerű tudomány | 2 |
| Az adatbázis relációs modellje nagement: 2. verzió | Puhakötés | EFCodd | brit | 39.99 | 538 | Vastag | 2 | Népszerű tudomány | 2 |
Az összes attribútum, amely nem része a jelölt kulcsnak, a címetől függ, de csak az ár függ a formátumtól. A 2NF megfeleléséhez és az ismétlődések eltávolításához minden nem jelölt kulcs attribútumnak a teljes jelölt kulcstól kell függenie, nem csak annak egy részétől.
A táblázat normalizálásához tegye a (z) {Title} (egyszerű) jelölt kulcsot (az elsődleges kulcs) úgy, hogy minden nem jelölt kulcs attribútum a teljes jelölt kulcstól függ, és távolítsa el az Árat egy külön táblába, hogy megőrizhető legyen a formátumtól való függősége:
|
|
Most, a Book táblázat megfelel a 2NF-nek.
A 3NFEdit kielégítése
A Book táblázat továbbra is tranzitív funkcionális függőséggel rendelkezik (a {Author Nationality} a {Author} függvénye, amely a {Title függvénye) }). Hasonló megsértés létezik a műfajok esetében is (a {Műfaj neve} a {Műfajazonosító} függvénye, amely a {Cím} függvénye). Ezért a Könyv táblázat nem a 3NF-ben található. A 3NF-ben való elkészítéséhez használjuk a következő táblázati struktúrát, ezzel kiküszöbölve a tranzitív funkcionális függőségeket azáltal, hogy a {Author Nationality} és a {Genre Name} elemeket saját táblázataikba helyezzük:
| Cím | Szerző | Oldalak | Vastagság | Műfajazonosító | Kiadói azonosító |
|---|---|---|---|---|---|
| MySQL adatbázis-tervezés kezdete és Optimalizálás | Chad Russell | 520 | Vastag | 1 | 1 |
| Az adatbázis-kezelés relációs modellje: 2. verzió | EFCodd | 538 | Vastag | 2 | 2 |
|
| Szerző | Szerző nemzetisége |
|---|---|
| Chad Russell | amerikai |
| EFCodd | brit |
| Gen re ID | Műfaj neve |
|---|---|
| 1 | Oktatóanyag |
| 2 | Népszerű tudomány |
Az EKNFEdit kielégítése
Az alap kulcs normál alakja (EKNF) szigorúan a 3NF és a BCNF közé esik, és az irodalomban nemigen tárgyalták. Célja “mind a 3NF, mind a BCNF kiemelkedő tulajdonságainak megragadása”, elkerülve mindkettő problémáját (nevezetesen, hogy a 3NF “túl megbocsátó”, és a BCNF “hajlamos a számítási bonyolultságra”). Mivel az irodalomban ritkán említik, ez nem szerepel ebben a példában.
A 4NFEdit kielégítése
Tegyük fel, hogy az adatbázis egy könyvkereskedő franchise tulajdonában van, amelynek több franchise-tulajdonos rendelkezik, amelyek különböző helyeken üzletekkel rendelkeznek.Ezért a kiskereskedő úgy döntött, hogy hozzáad egy táblázatot, amely tartalmazza a könyvek különböző helyeken való elérhetőségét:
| Franchise-azonosító | Cím | Hely |
|---|---|---|
| 1 | MySQL adatbázis tervezés és optimalizálás kezdete | Kalifornia |
| 1 | MySQL adatbázis tervezés és optimalizálás kezdete | Florida |
| 1 | MySQL adatbázis tervezés és optimalizálás kezdete | Texas |
| 1 | Az adatbázis-kezelés relációs modellje: 2. verzió | Kalifornia |
| 1 | Az adatbázis-kezelés relációs modellje: 2. verzió | Florida |
| 1 | Az adatbázis-kezelés relációs modellje: verzió 2 | Texas |
| 2 | MySQL adatbázis tervezés és optimalizálás kezdete | Kalifornia |
| 2 | A MySQL adatbázis tervezésének és optimalizálásának kezdete | Florida |
| 2 | MySQL adatbázistervezés és optimalizálás kezdete | Texas |
| 2 | Az adatbázis-kezelés relációs modellje: 2. verzió | Kalifornia |
| 2 | Az adatbázis-kezelés relációs modellje: 2. verzió | Florida |
| 2 | Az adatbázis-kezelés relációs modellje: 2. verzió | Texas |
| 3 | MySQL adatbázis-tervezés és optimalizálás kezdete | Texas |
Mivel ez a táblaszerkezet egy összetett elsődleges kulcsból áll, nem tartalmaz semmilyen nem kulcs attribútumot, és már szerepel a BCNF-ben (és ezért kielégíti az összes előző normál formát is). Ha azonban feltételezzük, hogy az összes rendelkezésre álló könyvet az egyes területeken kínálják, akkor észrevehetjük, hogy a cím nincs egyértelműen kötve egy bizonyos helyhez, ezért a táblázat nem felel meg a 4NF-nek.
Ez azt jelenti, a negyedik normál forma kielégítéséhez ezt a táblázatot is le kell bontani:
|
|
||||||||||||
| Franchise-vevő azonosítója | Hely | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Kalifornia | ||||||||||||
| 1 | Florida | ||||||||||||
| 1 | Texas | ||||||||||||
| 2 | Kalifornia | ||||||||||||
| 2 | Florida | ||||||||||||
| 2 | Texas | ||||||||||||
| 3 | Texas |
Most minden rekordot egy szuperkulcs egyértelműen azonosít, ezért a 4NF meg van elégedve. h3>
Tegyük fel, hogy a franchise-osok különféle beszállítóktól is rendelhetnek könyveket. A relációra a következő korlátozás is vonatkozhat:
- Ha egy bizonyos szállító bizonyos címet ad meg
- és a címet a franchise-vevő kapja meg
- és a franchise-vevőt a szállító látja el,
- akkor a szállító eljuttatja a jogt a franchise-vevőhöz.
| Szállítói azonosító | cím | Franchise-azonosító |
|---|---|---|
| 1 | MySQL adatbázis tervezés és optimalizálás kezdete | 1 |
| 2 | Az adatbázis-kezelés relációs modellje: 2. verzió | 2 |
| 3 | SQL megtanulása | 3 |
Ez a táblázat 4NF formátumban található, de a Szállítóazonosító megegyezik a vetületeinek összekapcsolásával: {{{Szállítói azonosító, könyv}, {Könyv, Franchise-azonosító}, {Franchise-azonosító, szállító ID}}.Ennek a csatlakozási függőségnek egyetlen összetevője sem szuperkulcs (az egyetlen szuperkulcs a teljes fejléc), ezért a táblázat nem felel meg az ETNF-nek, és tovább bontható: div id = “035d43819b”>
| Szállítóazonosító | Cím |
|---|---|
| 1 | MySQL adatbázis tervezés és optimalizálás kezdete |
| 2 | Az adatbázis-kezelés relációs modellje: 2. verzió |
| 3 | SQL tanulása |
| Title | Franchise-azonosító |
|---|---|
| MySQL adatbázis-tervezés és optimalizálás kezdete | 1 |
| Az adatbázis-kezelés relációs modellje: 2. verzió | 2 |
| SQL tanulása | 3 |
| Beszállítói azonosító | Franchise-vevő azonosító |
|---|---|
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
A bontás előidézi az ETNF megfelelőségét.
Az 5NFEdit kielégítése
Az 5NF-nek nem megfelelő tábla észleléséhez általában az adatok alapos megvizsgálásához szükséges. Tegyük fel, hogy a 4NF példa táblázata az adatok kis módosításával, és vizsgáljuk meg, kielégíti-e az 5NF-et:
| Franchise-azonosító | Cím | Hely |
|---|---|---|
| 1 | MySQL adatbázis-tervezés és optimalizálás kezdete | Kalifornia |
| 1 | SQL megtanulása | Kalifornia |
| 1 | Az adatbázis-kezelés relációs modellje: 2. verzió | Texas |
| 2 | Az adatbázis-kezelés relációs modellje: 2. verzió | Kalifornia |
Ha lebontjuk ezt a táblázatot, csökkentjük az elbocsátásokat, és a következő két táblázatot kapjuk:
|
|
Mi történik, ha megpróbálunk csatlakozni ezekhez a táblákhoz? A lekérdezés a következő adatokat adja vissza:
| Franchise-azonosító | Cím | Hely |
|---|---|---|
| 1 | MySQL adatbázistervezés kezdete és Optimalizálás | Kalifornia |
| 1 | SQL tanulása | Kalifornia |
| 1 | Az adatbázis-kezelés relációs modellje: 2. verzió | Kalifornia |
| 1 | Az adatbázis-kezelés relációs modellje: 2. verzió | Texas |
| 1 | SQL tanulása | Texas |
| 1 | MySQL adatbázis-tervezés és optimalizálás kezdete | Texas |
| 2 | Az adatbázis-kezelés relációs modellje: 2. verzió | Kalifornia |
Nyilvánvaló, hogy a JOIN három további sort ad vissza, mint kellene – próbáljuk meg hozzáadni az anót táblázat a kapcsolat tisztázására.Három különálló táblázat jön létre:
|
|
|
Mit jelent most a JOIN? Valójában nem lehet csatlakozni ehhez a három asztalhoz. Ez azt jelenti, hogy a Franchise-vevő és a könyv helyét nem lehetett bontani adatvesztés nélkül, ezért a táblázat már kielégíti az 5NF-et.
A CJ Date azzal érvelt, hogy az 5NF-ben csak egy adatbázis valóban “normalizált”.
A DKNFEdit kielégítése
Vessünk egy pillantást az előző példák Book táblájára, és nézzük meg, hogy kielégíti-e a tartománykulcs normál formáját:
| Cím | Oldalak | Vastagság | Műfajazonosító | Kiadói azonosító | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MySQL adatbázis tervezés és optimalizálás kezdete | 520 | Vastag | 1 | 1 | ||||||||||||||||||||||||||
| Az adatbázis-kezelés relációs modellje: 2. verzió | 538 | Vastag | 2 | 2 | ||||||||||||||||||||||||||
| SQL tanulása | 338 | Karcsú | 1 | 3 | ||||||||||||||||||||||||||
| SQL szakácskönyv | 636 | Vastag | 1 | 3 |
|
|
Így kiküszöbölték a tartomány integritásának megsértését, és a táblázat DKNF-ben található.
A 6NFEdit kielégítése
A hatodik normál forma egyszerű és intuitív meghatározása az, hogy “egy tábla 6NF-ben van, amikor a sor tartalmazza az elsődleges kulcsot, és legfeljebb egy másik attribútumot”.
Ez azt jelenti, hogy például az 1NF létrehozása során megtervezett Publisher táblázat
| Publisher_ID | Név | Ország |
|---|---|---|
| 1 | Apress | USA |
tovább kell két táblára bomlik:
|
|
A 6NF nyilvánvaló hátránya, hogy az egy entitás információinak megjelenítéséhez szükséges táblázatok sokasága van. Ha egy 5NF-ben lévő táblának egy elsődleges kulcsoszlopa és N attribútuma van, akkor ugyanazt az információt a 6NF-ben képviselve N táblára van szükség; egyetlen fogalmi rekord több mezõs frissítéséhez több tábla frissítése szükséges; és a beszúrások és törlések hasonlóan több tábla közötti műveleteket igényelnek. Ezért az online tranzakciófeldolgozási igényeket kiszolgáló adatbázisokban a 6NF-et nem szabad használni.
Azonban olyan adattárházakban, amelyek nem engedélyezik az interaktív frissítéseket, és amelyek nagy adatkötetek gyors lekérdezésére specializálódtak. , bizonyos DBMS-ek belső 6NF reprezentációt használnak – oszlopos adattároló néven. Azokban a helyzetekben, amikor az oszlop egyedi értékeinek száma jóval kevesebb, mint a táblázat sorainak száma, az oszlop-orientált tárolás jelentős helymegtakarítást tesz lehetővé az adatok tömörítésével. Az oszlopos tárolás lehetővé teszi a tartomány lekérdezések gyors végrehajtását (pl. Mutasson meg minden rekordot, ahol egy adott oszlop X és Y között van, vagy kevesebb, mint X.)
Mindezekben az esetekben azonban az adatbázis-tervező nem manuálisan kell végrehajtani a 6NF normalizálást külön táblák létrehozásával. Egyes, a raktározásra szakosodott DBMS-k, például a Sybase IQ, alapértelmezés szerint oszlopos tárolást használnak, de a tervező továbbra is csak egyetlen többoszlopos táblázatot lát. Más DBMS-ek, például a Microsoft SQL Server 2012 és újabb, lehetővé teszik az “oszlopok tárolójának indexét” egy adott tábla megadásához.
