Bevezetés az adatbázis-normalizálásba

Az adatbázis-normalizálás az adatbázis táblákba és oszlopokba rendezésére szolgáló folyamat. A fő gondolat ezzel az, hogy egy táblázatnak egy adott témáról kell szólnia, és csak a támogató témákat kell tartalmaznia. Vegyünk példaként egy táblázatot, amely tartalmazza az információkat, ahol az adatok értékesítőket és ügyfeleket tartalmaznak, amelyek több célt szolgálnak:

• Azonosítson értékesítőket a szervezetében
• Sorolja fel az összes ügyfelet, akit a cége hív termék eladása
• Azonosítsa, mely értékesítők hívják meg az adott ügyfeleket.

Azáltal, hogy egy táblázatot egyetlen célra korlátoz, csökkenti az adatbázisban található ismétlődő adatok számát. Ez kiküszöböli az adatbázis-módosításokból adódó néhány kérdést.

E célok eléréséhez néhány kialakított szabályt fogunk használni. A szabályok alkalmazásával új táblák jönnek létre. A rakoncátlanból az optimalizált felé haladás több normál formán halad át.

Három normál forma létezik, amelyeket a legtöbb adatbázis betart. Mivel a táblázatok kielégítik az adatbázisok egymást követő normalizálási formáit, kevésbé hajlamosak az adatbázis-módosítási rendellenességekre, és jobban összpontosítanak egyetlen cél vagy téma felé. Mielőtt továbblépnénk, győződjön meg róla, hogy megérti az adatbázis-táblázat definícióját.

Az adatbázis-normalizálás okai

Az adatbázis normalizálásának három fő oka van. Az első a duplikált adatok minimalizálása, a második az adatmódosítással kapcsolatos problémák minimalizálása vagy elkerülése, a harmadik pedig a lekérdezések egyszerűsítése.

A normalizálás különböző állapotainak átélésekor megvitatjuk, hogy az egyes űrlapok miként kezelik ezeket a problémákat, de kezdetként nézzünk meg néhány olyan adatot, amelyet nem normalizáltunk, és megvitassunk néhány lehetséges buktatót.

Azt hiszem, miután megértette a problémákat, jobban értékeli a normalizálást. Vegye figyelembe a következő táblázatot:

Először észre kell venni, hogy ez a táblázat sok célt szolgál, többek között:

1. A szervezet értékesítőinek azonosítása
2. Az értékesítések felsorolása irodák és telefonszámok
3. Értékesítő társítása értékesítési irodával
4. Minden eladó értékesítésének bemutatása

DBA-ként ez piros zászlót emel. Általában szeretnék olyan táblázatokat látni, amelyeknek egyetlen célja van. Ha az asztal sok célt szolgál, sok kihívást jelent; mégpedig adatmásolás, adatfrissítési problémák és fokozott erőfeszítés az adatok lekérdezésére.

Adatmásolás és módosítási rendellenességek

Vegye figyelembe, hogy minden SalesPerson esetében felsoroltuk a SalesOffice és az OfficeNumber számokat is. Ismétlődő adatok vannak az értékesítőkről. A sokszorosított információ két problémát vet fel:

1. növeli a tárolást és csökkenti a teljesítményt.
2. Nehezebb fenntartani az adatváltozásokat.

Például:

Fontolja meg, ha a chicagói irodát átköltöztetjük Evanstonba, IL. Ahhoz, hogy ezt megfelelően tükrözzük a táblázatunkban, frissítenünk kell a Chicagóban lévő összes SalesPerson bejegyzését. Táblázatunk egy kicsi példa, de láthatja, hogy nagyobb-e, hogy ez potenciálisan több száz frissítést tartalmazhat.

Ezek a helyzetek módosítási rendellenességek. Az adatbázis normalizálása kijavítja őket. Három módosítási rendellenesség fordulhat elő:

Anomália beszúrása

Vannak tények, amelyeket addig nem rögzíthetünk, amíg nem ismerünk információkat a teljes sorról. Példánkban nem rögzíthetünk új értékesítési irodát, amíg nem ismerjük az értékesítőt sem. Miért? Mivel a rekord létrehozásához elsődleges kulcsot kell megadnunk. Esetünkben ez az EmployeeID.

Anomália frissítése

Ebben az esetben ugyanazon információ áll rendelkezésünkre több sorban. Például, ha az irodaszám megváltozik, akkor több frissítést kell végrehajtani. Ha nem frissítjük az összes sort, akkor inkonzisztenciák jelennek meg.

Anomália törlés

Egy sor törlése több tényhalmaz eltávolítását eredményezi. Például, ha John Hunt visszavonul, akkor a sor törlésével elveszítjük az információkat a New York-i irodáról.

Keresési és rendezési problémák

Az utolsó ok, amelyet megfontolunk, megkönnyíti az adatok keresését és rendezését. Ha a SalesStaff táblában egy adott ügyfelet szeretne keresni, például a Fordot, akkor egy olyan lekérdezést kell írnia, mint

SELECT SalesOfficeFROM SalesStaffWHERE Customer1 = ‘Ford’ OR Customer2 = ‘Ford’ OR Customer3 = ‘Ford’

Nyilvánvaló, hogy az ügyfél valahogy egy oszlopban a lekérdezésünk egyszerűbb lenne. Fontolja meg azt is, hogy szeretne-e futtatni egy lekérdezést és rendezni ügyfél szerint.

A jelenlegi táblázatunk ezt megnehezíti. Három különálló UNION lekérdezést kell használnia!Ezeket az anomáliákat kiküszöbölheti vagy csökkentheti, ha az adatokat külön táblákra osztja. Ez az adatokat egyetlen célt szolgáló táblákba helyezi.

A tábla újratervezésének folyamata az adatbázis normalizálása.

Az adatbázis-normalizálás meghatározása

Az adatbázis-normalizálásnak három általános formája van: 1., 2. és 3. normál forma. Rövidítésként 1NF, 2NF és 3NF.

Számos további forma létezik, mint például a BCNF, de ezeket fejlettnek tartom, és az elején nem túl szükséges megtanulni.

A formák progresszívak, ami azt jelenti, hogy a 3. normál forma megszerzéséhez egy táblának először meg kell felelnie a 2. normál forma szabályainak, a 2. normál formának pedig be kell tartania az 1. normál forma formáit. Mielőtt a különféle formákat és szabályokat részletesen megvitatnánk, foglaljuk össze a különféle formákat:

• Első normál forma – Az információkat egy relációs táblázatban tároljuk, minden oszlopban atomértékeket tartalmazva. Nincs ismétlődő oszlopcsoport.
• Második normál forma – A tábla első normál formában van, és az összes oszlop a tábla elsődleges kulcsától függ.
• Harmadik normál forma – a tábla második normál formában van, és minden oszlopa nem függ átmenetileg az elsődleges kulcstól

Ha a szabályoknak nincs túl sok értelme, ne aggódjon. A cikkhez linkeltem, hogy jobban megértsem őket.

Most fontos megérteni, hogy az adatbázis-normalizálásnak három szabálya van. Vannak, akik bonyolultnak tűnnek az adatbázis normalizálásában.

de ennek nem kell lennie, és amint megértette, intuitívvá válik.