Az adatbázis normalizálásának alapjainak leírása

Megjegyzés

Az Office 365 ProPlus átnevezésre került Microsoft 365 Vállalati alkalmazásokra. A változásról további információért olvassa el ezt a blogbejegyzést.

Eredeti KB-szám:   283878

Ez a cikk ismerteti az adatbázis normalizálási terminológiáját kezdőknek. Ennek a terminológiának az alapvető ismerete hasznos a relációs adatbázis tervezésének megvitatása során.

A normalizálás leírása

A normalizálás az adatbázisban lévő adatok rendszerezésének folyamata. Ez magában foglalja a táblák létrehozását és a táblák közötti kapcsolatok létrehozását olyan szabályok szerint, amelyek célja az adatok védelme és az adatbázis rugalmasabbá tétele a redundancia és az inkonzisztens függőség kiküszöbölésével.

A redundáns adatok lemezterületet pazarolnak el, és karbantartási problémákat okoznak. Ha egynél több helyen létező adatokat kell módosítani, az adatokat pontosan ugyanúgy kell módosítani minden helyen. Az ügyfélcím módosítása sokkal egyszerűbb, ha az adatok at csak a Vevők táblában tárolják, és sehol máshol az adatbázisban.

Mi az az "inkonzisztens függőség"? Bár a felhasználó számára intuitív, hogy egy adott ügyfél címét keresse a Vevők táblában, előfordulhat, hogy nincs értelme ott keresni az adott ügyfelet meghívó alkalmazott fizetését. Az alkalmazott fizetése az alkalmazotthoz kapcsolódik, vagy attól függ, ezért át kell helyezni az Alkalmazottak táblába. Az inkonzisztens függőségek megnehezíthetik az adatok elérését, mivel az adatok megtalálásának elérési útja hiányzik vagy megszakad.

Az adatbázis normalizálására néhány szabály vonatkozik. Minden szabályt "normál űrlapnak" nevezünk. Ha az első szabályt betartják, az adatbázis "első normál formában" van. Ha az első három szabályt betartják, az adatbázis "harmadik normál formában" van megtekintve. Bár a normalizálás más szintjei is lehetségesek, a harmadik normál forma a legtöbb alkalmazáshoz szükséges legmagasabb szintnek számít.

Mint sok hivatalos szabályok és előírások, valós forgatókönyvek nem mindig teszik lehetővé a tökéletes megfelelést. Általánosságban elmondható, hogy a normalizálás további táblákat igényel, és néhány ügyfél ezt nehézkesnek találja. Ha úgy dönt, hogy megsérti a normalizálás első három szabályának egyikét, győződjön meg arról, hogy az alkalmazás előre jelzi az esetlegesen előforduló problémákat, például a redundáns adatokat és az inkonzisztens függőségeket.

Az alábbi leírások példákat tartalmaznak.

Első normál forma

  • Távolítsuk el az ismétlődő csoportokat az egyes táblázatokban.
  • Hozzon létre külön táblát a kapcsolódó adatok minden egyes készletéhez.
  • Azonosítsa a kapcsolódó adatok minden egyes készletét egy elsődleges kulccsal.

Ne használjon több mezőt egyetlen táblában hasonló adatok tárolására. Ha például két lehetséges forrásból származó készletcikket szeretne nyomon követni, a készletrekord tartalmazhat az 1-es szállítói kód és a szállítói kód 2 mezőit.

Mi történik, ha hozzáad egy harmadik szállítót? A mező hozzáadása nem megoldás; program- és táblamódosításokat igényel, és nem fogadja el zökkenőmentesen a szállítók dinamikus számát. Ehelyett helyezze az összes szállítói információt egy szállítók nevű külön táblába, amelyet Szállítóknak neveznek, majd csatolja a készletet a cikkszámkulccsal rendelkező szállítókhoz, vagy a szállítókat a szállítói kódkulccsal rendelkező szállítókhoz.

Második normál forma

  • Hozzon létre külön táblákat a több rekordra vonatkozó értékkészletekhez.
  • Ezeket a táblákat egy idegen kulccsal kapcsolja össze.

A rekordok nem függhetnek mástól, mint a tábla elsődleges kulcsától (szükség esetén összetett kulcstól). Vegyük például egy vevő címét egy könyvelési rendszerben. A címet a Vevők táblára, de a Rendelések, a Szállítás, a Számlák, a Kinnlevőségek és a Beszedések táblákhoz is szükség van. Ahelyett, hogy a vevő címét külön bejegyzésként tárolna az egyes táblákban, tárolja azt egy helyen, akár a Vevők táblában, akár egy külön Címek táblában.

Harmadik normál forma

  • Távolítsuk el azokat a mezőket, amelyek nem függnek a kulcstól.

A rekord olyan értékei, amelyek nem részei a rekord kulcsának, nem tartoznak a táblába. Általánosságban elmondható, hogy ha egy mezőcsoport tartalma a táblában szereplő több rekordra is vonatkozik, fontolja meg, hogy ezeket a mezőket külön táblába helyezi.

Az Alkalmazotttoborzás táblában például szerepelhet egy jelölt egyetemi neve és címe. De szükséged van egy teljes listára az egyetemekről a csoportos levelekhez. Ha az egyetemi adatokat a Jelöltek táblázatban tárolják, nincs mód arra, hogy felsorolják azokat az egyetemeket, ahol nincsenek jelenlegi jelöltek. Hozzon létre egy külön Egyetemek táblát, és csatolja a Jelöltek táblához egy egyetemi kódkulccsal.

KIVÉTEL: A harmadik normál forma betartása, bár elméletileg kívánatos, nem mindig praktikus. Ha van Vevők táblája, és ki szeretné zárni az összes lehetséges mezőfüggőséget, külön táblákat kell létrehoznia a városokhoz, az irányítószámokhoz, az értékesítési képviselőkhöz, a vevőosztályokhoz és minden más tényezőhöz, amely több rekordban is megkettőzhető. Elméletben a normalizálást érdemes megtisztítani. Sok kis tábla azonban ronthatja a teljesítményt, vagy meghaladhatja a megnyitott fájl- és memóriakapacitást.

Lehetséges, hogy a harmadik normál formát csak a gyakran változó adatokra lehet alkalmazni. Ha néhány függő mező megmarad, tervezze meg úgy az alkalmazást, hogy a felhasználónak ellenőriznie kell az összes kapcsolódó mezőt, ha bármelyiket módosítja.

Egyéb normalizálási formák

Negyedik normál formában, más néven Boyce Codd Normal Form (BCNF), és az ötödik normál formában léteznek, de ritkán tekinthető a gyakorlati design. Ezeknek a szabályoknak a figyelmen kívül hagyása a tökéletesnél kevesebb adatbázis-kialakítást eredményezhet, de nem befolyásolhatja a működést.

Példatábla normalizálása

Ezek a lépések egy fiktív tanulói tábla normalizálásának folyamatát mutatják be.

  1. Nem normalizált táblázat:

    Diák # Tanácsadó Adv-szoba 1. osztály 2. osztály 3. osztály
    1022 Jones 412 101-07 143-01 159-02
    4123 Smith 216 201-01 211-02 214-01
  2. Első normál forma: Nincs ismétlődő csoport

    A tábláknak csak két dimenzióval kell rendelkezniük. Mivel az egyik tanulónak több osztálya van, ezeket az osztályokat külön táblázatban kell felsorolni. Fields Class1, Class2 és Class3 a fenti rekordok jelzi a tervezési baj.

    A számolótáblák gyakran a harmadik dimenziót használják, de a táblázatoknem. Egy másik módja annak, hogy nézd meg ezt a problémát egy-a-többhöz kapcsolat, ne tegye az egyik oldalon, és a sok oldalon ugyanabban a táblázatban. Ehelyett hozzon létre egy másik táblázatot az első normál formában az ismétlődő csoport (Class#) eltávolításával, az alábbiak szerint:

    Diák # Tanácsadó Adv-szoba Osztály #
    1022 Jones 412 101-07
    1022 Jones 412 143-01
    1022 Jones 412 159-02
    4123 Smith 216 201-01
    4123 Smith 216 211-02
    4123 Smith 216 214-01
  3. Második normál forma: A redundáns adatok kiküszöbölése

    Figyelje meg a több Class# értékeket minden Student# értékhez a fenti táblázatban. Class# funkcionálisan nem függ a Student# (elsődleges kulcs) től, így ez a kapcsolat nem a második normál formában van.

    A következő két táblázat a második normál formát mutatja be:

    Diákok:

    Diák # Tanácsadó Adv-szoba
    1022 Jones 412
    4123 Smith 216

    Regisztráció:

    Diák # Osztály #
    1022 101-07
    1022 143-01
    1022 159-02
    4123 201-01
    4123 211-02
    4123 214-01
  4. Harmadik normál forma: A kulcstól nem függő adatok kiküszöbölése

    Az utolsó példában az Adv-Room (a tanácsadó irodaszáma) funkcionálisan az Advisor attribútumtól függ. A megoldás az, hogy ezt az attribútumot a Diákok táblából a Kar táblázatba helyezze át, az alábbiak szerint:

    Diákok:

    Diák # Tanácsadó
    1022 Jones
    4123 Smith

    Kar:

    Name (Név) Szoba Dept
    Jones 412 42
    Smith 216 42