Szerkesztő:LegTomi/Adatbázis normalizálás
Az adatbázis-normalizálása, általában az adatbázis, egy relációs adatbázis struktúra,normál űrlapok sorozatának megfelelően, célja az adatok redundanciájának csökkentése és az adatok integritásának javítása érdekében. Ezt először Edgar F. Codd javasolta relációs modelljének részeként.
A normalizálás magában foglalja az adatbázis oszlopainak (attribútumainak) és tábláinak (relációinak) rendezését annak biztosítása érdekében, hogy függőségeiket az adatbázis integritásának korlátai megfelelően érvényesítsék. Néhány formális szabály alkalmazásával megvalósítható szintézis (új adatbázis-terv létrehozása) vagy bontás (meglévő adatbázis-tervezés javítása) segítségével.
Célkitűzések szerkesztés
A Codd által 1970-ben meghatározott első normál forma alapvető célja az volt, hogy lehetővé tegye az adatok lekérdezését és manipulálását az "elsőrendű logika " alapján megalapozott "univerzális adatnyelv" segítségével.[1] (Az SQL egy példa egy ilyen adatnyelvre, bár Codd ezt súlyos hibának tartotta.[2])
Az 1NF (első normál forma) normalizálási célkitűzéseit Codd a következőképpen fogalmazta meg:
- A relációgyűjtemény megszabadítása a nem kívánt beillesztési, frissítési és törlési függőségektől.
- Csökkenteni a kapcsolatok átszervezésének szükségességét, mivel új típusú adatokat vezetnek be, ezáltal megnöveli az alkalmazási programok élettartamát.
- A relációs modell informatívabbá tétele a felhasználók számára.
- A kapcsolatok gyűjtése semleges a lekérdezés statisztikájával szemben, ahol ezek a statisztikák az idő előre haladtával változhatnak.
- E.F. Codd, "Further Normalisation of the Data Base Relational Model"
Amikor egy reláció módosítására (frissítésére, beillesztésére vagy törlésére) kísérletet tesznek, a következő nemkívánatos mellékhatások merülhetnek fel a nem megfelelően normalizált kapcsolatokban:
- Frissítési anomália: Ugyanaz az információ több sorban is kifejezhető; ezért a reláció frissítése logikai következetlenségeket eredményezhet. Például az "Alkalmazottak készségei (Employees' Skills)" reláció minden rekordja tartalmazhat munkavállalói azonosítót (Employee ID), alkalmazotti címet (Employee Address) és készséget (Skill); így előfordulhat, hogy egy adott munkavállaló címének megváltoztatását több rekordra kell alkalmazni (minden készséghez egyet). Ha a frissítés csak részben sikeres - az alkalmazottak címe egyes rekordokon frissül, másokon nem -, akkor a kapcsolat inkonzisztens állapotban marad. Pontosabban, a kapcsolat ellentmondásos válaszokat ad arra a kérdésre, hogy mi az adott alkalmazott címe. Ezt a jelenséget frissítési anomáliának nevezik.
- Beszúrási anomália. Vannak olyan esetek, amikor bizonyos információk egyáltalán nem lehet rögzíthetők. Például a "Kar és tanfolyamaik (Faculty and Their Courses)" reláció minden rekordja tartalmazhatja a kar azonosítóját (Faculty ID), a kar nevét (Faculty Name), a kar bérleti dátumát (Faculty Hire Date) és a tanfolyam kódját (Course Code). Ezért rögzíthetünk minden olyan oktató adatait, akik legalább egy kurzust oktatnak, de nem vehetünk fel olyan újonnan felvett oktatókat, akiket még nem jelöltek ki tanfolyamok oktatására, kivéve, ha a tanfolyam kódját nullára állítottuk . Ezt a jelenséget beszúrási anomáliának nevezik.
- Törlési anomália. Bizonyos körülmények között a bizonyos tényeket képviselő adatok törlése teljesen más tényeket képviselő adatok törlését igényli. Az előző példában leírt "Kar és tanfolyamok (Faculty and Their Courses)" reláció ilyen típusú rendellenességektől szenved, mert ha egy oktató ideiglenesen megszűnik kijelölni bármelyik kurzust, akkor az utolsó olyan rekordot kell törölnünk, amelyen az oktató szerepel. a tanári tag törlése is, hacsak nem állítjuk nullára a tanfolyam kódját. Ezt a jelenséget törlési anomáliának nevezik.
Újratervezés minimalizálása kiterjesztett adatbázis felépítése során szerkesztés
A teljesen normalizált adatbázis lehetővé teszi a struktúra kibővítését új típusú adatok befogadására a meglévő struktúra túlzott megváltoztatása nélkül. Ennek eredményeként az adatbázissal kölcsönhatásban lévő alkalmazások minimálisan vannak.
A normalizált kapcsolatok, valamint az egyik normalizált kapcsolat és a másik viszonya tükrözi a valós világ fogalmait és azok összefüggéseit.
Normális formák szerkesztés
Codd 1970-ben vezette be a normalizálás fogalmát és az úgynevezett első normál formát (1NF). [3] Codd 1971-ben meghatározta a második normál formát (2NF) és a harmadik normál formát (3NF), [4] Codd és Raymond F. Boyce pedig a Boyce – Codd normál formát 1974-ben. [5]
Informálisan egy relációs adatbázis relációt gyakran "normalizáltnak" neveznek, ha megfelel a harmadik normális formának. [6] A legtöbb 3NF kapcsolat mentes a beillesztési, frissítési és törlési rendellenességektől.
A normál formák (a legkevésbé normalizálttól a leginkább normalizáltig): · UNF: Normalizálatlan forma · 1NF: Első normál forma
· 2NF: Második normál forma
· 3NF: Harmadik normál forma
· EKNF: Elemi kulcs normál forma
· BCNF: Boyce-Codd normál forma
· 4NF: Negyedik normál forma
· ETNF: Alapvető normál forma
· 5NF: Ötödik normál forma
· DKNF: Domainkulcs normálforma
· 6NF: Hatodik normál forma
| UNF (1970) |
1NF (1970) |
2NF (1971) |
3NF (1971) |
EKNF (1982) |
BCNF (1974) |
4NF (1977) |
ETNF (2012) |
5NF (1979) |
DKNF (1981) |
6NF (2003) | |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Elsődleges kulcs (nincs ismétlődés)[3] | Sablon:MaybeCheck | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya |
| Atomoszlopok (cellák nem lehetnek tábla értékeként)[4] | Sablon:Na | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya |
| Minden nem triviális funkcionális függőség vagy nem egy jelölt kulcs megfelelő részhalmazával kezdődik, vagy pedig egy elsődleges attribútummal végződik (nincsenek részleges funkcionális függőségek a nem elsődleges attribútumoktól a jelölt kulcsokon) | Sablon:Na | Sablon:Na | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya |
| Minden nem triviális funkcionális függőség vagy egy szuperkulccsal kezdődik, vagy pedig egy elsődleges attribútummal végződik (a nem elsődleges attribútumok transzitív funkcionális függőségei nincsenek a jelölt kulcsokon) | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya |
| Minden nem triviális funkcionális függőség vagy egy szuperkulccsal kezdődik, vagy egy elemi prím attribútummal végződik | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | — |
| Minden nem triviális funkcionális függőség egy szuperkulccsal kezdődik | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | — |
| Minden nem triviális többértékű függőség szuperkulccsal kezdődik | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Ya | Sablon:Ya | Sablon:Ya | Sablon:Ya | — |
| Ø Minden csatlakozási függőségnek van egy szuperkulcs-összetevője | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Ya | Sablon:Ya | Sablon:Ya | — |
| Minden csatlakozási függőség csak szuperkulcs-összetevőket tartalmaz | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Ya | Sablon:Ya | — |
| Minden kényszer a tartományi kényszer és a kulcs kényszer következménye | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Ya | Sablon:Na |
| Minden csatlakozási függőség triviális | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Na | Sablon:Ya |
Példa a lépésenkénti normalizálásra szerkesztés
A normalizálás egy adatbázis-tervezési technika, amelyet egy relációs adatbázis-tábla tervezésére használnak magasabb normál formáig. [7] 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. [8]
Ez azt jelenti, hogy az adatok normalizálatlan formában (a legkevésbé normalizáltak) és a legmagasabb normalizálási szint elérésére törekedve az első lépés az első normál formának való megfelelés biztosítása, a második lépés pedig 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 túlmutató normál formák főként tudományos érdeklődésre tartanak számot, mivel azok a problémák, amelyek megoldására léteznek, ritkán jelennek meg a gyakorlatban. [9]
Felhívjuk figyelmét, hogy az alábbi példában szereplő adatok szándékosan lettek kialakítva, hogy ellentmondjanak a szokásos formák többségének. A való életben nagyon is 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 végén még lehet, hogy vannak olyan táblák, amelyek nem felelnek meg a legmagasabb normál formának.
Kiindulási adatok szerkesztés
Legyen egy adatbázis-tábla a következő felépítéssel: [8]
| Cím | Szerző | Szerző nemzetisége | Formátum | Ár | Tartalom | Oldalak | Vastagság | Kiadó | Kiadó országa | Publikáció típusa | Műfaj azonosítója | Műfaj neve | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| A MySQL adatbázis tervezésének és optimalizálásának kezdete | Chad Russell | Amerikai | Keménykötésű | 49.99 |
|
520 | Vastag | Apress | USA | E-könyv | 1 | Bemutató |
Ebben a példában feltételezzük, hogy minden könyvnek csak egy szerzője van.
A relációs modellnek való megfelelés előfeltételeként a táblának rendelkeznie kell elsődleges kulccsal, amely egyedileg azonosítja a sort. Két könyvnek ugyanaz a címe, de egy ISBN-szám egyedülállóan azonosítja a könyvet, ezért ezt használhatjuk elsődleges kulcsként:
| ISBN # | Cím | Szerző | Szerző nemzetisége | Formátum | Ár | Tartalom | Oldalak | Vastagság | Kiadó | Kiadó országa | Publikáció típusa | Műfaj azonosítója | Műfaj neve | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1590593324 | A MySQL adatbázis tervezésének és optimalizálásának kezdete | Chad Russell | Amerikai | Keménykötésű | 49.99 |
|
520 | Vastag | Apress | USA | E-könyv | 1 | Bemutató |
1NF kielégítése szerkesztés
Az első normál forma kielégítéséhez a táblázat minden oszlopának egyetlen értékkel kell rendelkeznie. Az értékeket vagy beágyazott rekordokat tartalmazó oszlopok nem engedélyezettek.
A kezdeti táblázatban a Tartalom egy sor tartalmi értéket tartalmaz, vagyis nem felel meg.
A probléma megoldása érdekében a tartalmat külön Tartalom táblázatba helyezzük: [8]
| ISBN # | Cím | Formátum | Szerző | Szerző nemzetisége | Ár | Oldalak | Vastagság | Kiadó | A kiadó országa | Műfaj azonosítója | Műfaj neve |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1590593324 | A MySQL adatbázis tervezésének és optimalizálásának kezdete | Keménykötésű | Chad Russell | Amerikai | 49.99 | 520 | Vastag | Apress | USA | 1 | Bemutató |
Hozzáadunk egy idegen kulcs oszlopot a Tartalom-táblához, amely annak a sornak az elsődleges kulcsára utal, ahonnan kivontuk az alanyot. Ezért ugyanazt az információt képviselik, de nem egyszerű domainek használata nélkül. Egy normálatlan formában, lévő táblázat helyett most két tábla van, amely megfelel az 1NF-nek. 2NF kielégítése szerkesztésA Könyv táblának van egy jelölt kulcsa (ami tehát az elsődleges kulcs),a {Cím, Formátum} összetett kulcs. Vegye figyelembe a következő táblázat részletet:
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-nek való megfeleléshez és a párhuzamosságok 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 készítsen {Cím} (egyszerű) jelölt kulcsot (elsődleges kulcsot) úgy, hogy minden nem jelölt kulcs attribútum az egész jelölt kulcstól függjön, és távolítsa el az Árat egy külön táblába, hogy a Formátumtól való függősége konzervált:
Most a Könyv (Book) táblázat megfelel a 2NF-nek. 3NF kielégítése szerkesztésA Book táblázat továbbra is tranzitív funkcionális függőséggel rendelkezik (a {Szerző nemzetisége} a {Szerző} függvénye, amely a {Cím} 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ázatszerkezetet, ezzel kiküszöbölve a tranzitív funkcionális függőségeket azáltal, hogy a {Szerző nemzetisége} és a {Kiadó neve} elemeket saját táblázataikba helyezzük:
EKNF kielégítése szerkesztésAz elemi kulcs normál forma (EKNF) szigorúan a 3NF és a BCNF közé esik, és az irodalomban nem sokat tárgyalnak róla. Célja, hogy „megragadja mind a 3NF, mind a BCNF kiemelkedő tulajdonságait”, elkerülve mindkettő problémáit (nevezetesen, hogy a 3NF „túl megbocsátó”, és a BCNF „hajlamos a számítási bonyolultságra”). Mivel az irodalom ritkán említi, ebben a példában nem szerepel. 4NF kielégítése szerkesztésTegyük fel, hogy az adatbázis egy könyvkereskedő franchise tulajdonában van, amelynek több olyan franchise-tulajdonosa van, akik különböző helyeken üzletekkel rendelkeznek. Ezért a kiskereskedő úgy döntött, hogy hozzáad egy táblázatot, amely adatokat tartalmaz a könyvek különböző helyeken való elérhetőségéről:
Mivel ez a táblaszerkezet összetett elsődleges kulcsból áll, nem tartalmaz nem kulcs attribútumokat, és már a BCNF-ben van (és ezért az összes korábbi normál formát is kielégíti). Ha azonban feltételezzük, hogy az összes rendelkezésre álló könyvet az egyes területeken kínálják, észrevehetjük, hogy a cím nincs egyértelműen kötve egy bizonyos helyhez, és ezért a táblázat nem felel meg a 4NF-nek. Ez azt jelenti, hogy a negyedik normál forma teljesítéséhez ezt a táblázatot is le kell bontani:
Most minden rekordot egyértelműen azonosít egy szuperkulcs, ezért a 4NF kielégített..[10] ETNF kielégítése szerkesztésTegyük fel, hogy a franchise-tulajdonosok könyveket is rendelhetnek különböző beszállítóktól. Legyen a reláció a következő korlátozásnak is alávetve:
Ez a táblázat 4NF-ben van, de a Szállító azonosító megegyezik a vetületeinek összekapcsolásával: {{Szállítói ID, könyv}, {Könyv, Franchise-ID}, {Franchise-ID, szállítói ID}}. Ennek a csatlakozási függőségnek egyetlen összetevője sem szuperkulcs (az egyetlen szuperkulcs a teljes fejléc), így a táblázat nem felel meg az ETNF-nek, és tovább bontható:
A bontás elősegíti az ETNF megfelelőségét. 5NF kielégítése szerkesztésAz 5NF-nek,nem megfelelő táblázat észleléséhez általában alaposan meg kell vizsgálni az adatokat. Tegyük fel, hogy a táblázat a 4NFpéldából áll, az adatok kis módosításával, és vizsgáljuk meg, hogy kielégíti-e az 5NF-et:
Ha lebontjuk ezt a táblázatot, csökkentjük az redundanciáját, és a következő két táblázatot kapjuk:
Mi történik, ha megpróbálunk csatlakozni ezekhez az táblákhoz? A lekérdezés a következő adatokat adja vissza:
Nyilvánvaló, hogy a JOIN három további sort ad vissza, mint kellene - próbáljunk meg egy másik táblázatot hozzáadni a kapcsolat tisztázásához. Végül három külön táblázat található:
Mit ad vissza most a JOIN? Valójában nem lehet csatlakozni ehhez a három táblához. Ez azt jelenti, hogy a Franchise-vevő helyének elbontása adatvesztés nélkül nem volt lehetséges, ezért a táblázat már kielégíti az 5NF-et. C. J. Date azzal érvelt, hogy az 5NF-ben csak egy adatbázis valóban "normalizált".[12] DKNF kielégítése szerkesztésVessünk egy pillantást az előző példák Book táblájára, és nézzük meg, hogy megfelel-e a Domain-kulcs normál formának:
Logikailag a vastagságot az oldalak száma határozza meg. Ez azt jelenti, hogy az Pages-től függ, ami nem kulcs. Vegyünk egy példát arra, hogy egy 350 oldalig terjedő könyvet "karcsúnak", a 350 oldalnál pedig "vastagnak" tekintünk. Ez a megegyezés technikailag korlátozás, de nem tartományi és nem is kulcskorlát; ezért nem támaszkodhatunk tartományi és kulcsfontosságú korlátozásokra az adatok integritásának megőrzése érdekében. Más szavakkal - semmi sem akadályoz bennünket abban, hogy például "Vastag" -ot tegyünk egy mindössze 50 oldalas könyvhöz - és ez a táblát megsérti a DKNF-et. Ennek megoldására létrehozhatunk egy táblázatot, amely felsorolja a vastagságot, és eltávolítja az oszlopot az eredeti táblából
Így megszűnt a tartomány integritásának megsértése, és a táblázat DKNF-ben található. 6NF kielégítése szerkesztésA hatodik normál forma is that "egyszerű és intuitív meghatározása az, hogy "egy tábla 6NF-ben van, ha a sor tartalmazza az elsődleges kulcsot és legfeljebb egy másik attribútumot"..[13] Ez azt jelenti, hogy például 1NF létrehozása során megtervezett Publisher tábla látható:
két táblára kell tovább bontani:
A 6NF nyilvánvaló hátránya, hogy az egy entitás információinak ábrázolásához 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ábla szükséges; 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ények kielégítésére szolgáló adatbázisokban a 6NF nem használható. Azokban az adattárházakban, amelyek nem engedélyezik az interaktív frissítéseket, és amelyek a nagy adatmennyiségek gyors lekérdezésére specializálódtak, bizonyos DBMS-ek belső 6NF ábrázolást használnak - oszlopos adattároló néven. Olyan 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 (például az összes olyan rekord megjelenítése, ahol egy adott oszlop X és Y között van, vagy kevesebb, mint X.) Mindezekben az esetekben azonban az adatbázis-tervezőnek nem kell manuálisan végrehajtania a 6NF normalizálást külön táblák létrehozásával. Egyes, a raktározásra szakosodott DBMS-k, mint például a Sybase IQ, ualapé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-k, például a Microsoft SQL Server 2012 és újabb, lehetővé teszik az "oszloptár-index" megadását egy adott táblához. Lásd még szerkesztés
Megjegyzések és hivatkozások szerkesztés
További irodalom szerkesztés
Külső hivatkozások szerkesztés
|
- ↑ "The adoption of a relational model of data ... permits the development of a universal data sub-language based on an applied predicate calculus. A first-order predicate calculus suffices if the collection of relations is in first normal form. Such a language would provide a yardstick of linguistic power for all other proposed data languages, and would itself be a strong candidate for embedding (with appropriate syntactic modification) in a variety of host languages (programming, command- or problem-oriented)." Codd, "A Relational Model of Data for Large Shared Data Banks" Archiválva 2007. június 12-i dátummal a Wayback Machine-ben., p. 381
- ↑ Codd, E.F. Chapter 23, "Serious Flaws in SQL", in The Relational Model for Database Management: Version 2. Addison-Wesley (1990), pp. 371–389
- ↑ a b Codd (1970. június 1.). „A Relational Model of Data for Large Shared Data Banks”. Communications of the ACM 13 (6), 377–387. o. [2007. június 12-i dátummal az eredetiből archiválva]. DOI:10.1145/362384.362685. (Hozzáférés: 2005. augusztus 25.)
- ↑ a b Codd, E. F. "Further Normalization of the Data Base Relational Model". (Presented at Courant Computer Science Symposia Series 6, "Data Base Systems", New York City, May 24–25, 1971.) IBM Research Report RJ909 (August 31, 1971). Republished in Randall J. Rustin (ed.), Data Base Systems: Courant Computer Science Symposia Series 6. Prentice-Hall, 1972.
- ↑ Codd, E. F. "Recent Investigations into Relational Data Base Systems". IBM Research Report RJ1385 (April 23, 1974). Republished in Proc. 1974 Congress (Stockholm, Sweden, 1974), N.Y.: North-Holland (1974).
- ↑ Date, C. J.. An Introduction to Database Systems. Addison-Wesley, 290. o. (1999)
- ↑ Kumar, Kunal. Database normalization design pattern. IEEE. DOI: 10.1109/upcon.2017.8251067 (2017. október 1.). ISBN 9781538630044
- ↑ a b c Database normalization in MySQL: Four quick and easy steps (angol nyelven). ComputerWeekly.com. [2017. augusztus 30-i dátummal az eredetiből archiválva]. (Hozzáférés: 2021. március 23.)
- ↑ Database Normalization: 5th Normal Form and Beyond. MariaDB KnowledgeBase. (Hozzáférés: 2019. január 23.)
- ↑ Normalizace databáze, <https://cs.wikipedia.org/w/index.php?title=Normalizace_datab%C3%A1ze&oldid=16615346>. Hozzáférés ideje: 2019-01-22
- ↑ Date, C. J.. The New Relational Database Dictionary: Terms, Concepts, and Examples (angol nyelven). "O'Reilly Media, Inc.", 138. o. (2015. december 21.). ISBN 9781491951699
- ↑ Date, C. J.. The New Relational Database Dictionary: Terms, Concepts, and Examples (angol nyelven). "O'Reilly Media, Inc.", 163. o. (2015. december 21.). ISBN 9781491951699
- ↑ normalization - Would like to Understand 6NF with an Example. Stack Overflow. (Hozzáférés: 2019. január 23.)