Inleiding tot database normalisatie

Database normalisatie is een proces dat wordt gebruikt om een database in tabellen en kolommen te organiseren. Het belangrijkste idee hierbij is dat een tabel over een specifiek onderwerp moet gaan en alleen ondersteunende onderwerpen moet bevatten. Neem een spreadsheet met de informatie als voorbeeld, waarbij de gegevens verkopers en klanten bevatten die verschillende doelen dienen:

• Identificeer verkopers in uw organisatie
• Maak een lijst van alle klanten die uw bedrijf bezoekt om een product te verkopen
• Bepaal welke verkopers een beroep doen op specifieke klanten.

Door een tabel te beperken tot één doel, vermindert u het aantal dubbele gegevens in uw database. Dit elimineert enkele problemen die voortkomen uit wijzigingen in de database.

Om deze doelstellingen te bereiken, zullen we een aantal vastgestelde regels gebruiken. Terwijl u deze regels toepast, worden er nieuwe tabellen gevormd. De voortgang van weerbarstig naar geoptimaliseerd verloopt via verschillende normale vormen.

Er zijn drie normale vormen die de meeste databases gebruiken. Aangezien tabellen voldoen aan elk opeenvolgend normalisatieformulier voor databases, worden ze minder vatbaar voor afwijkingen in de database-aanpassing en meer gericht op een enkel doel of onderwerp. Voordat we verder gaan, zorg ervoor dat u de definitie van een databasetabel begrijpt.

Redenen voor databasenormalisatie

Er zijn drie hoofdredenen om een databank te normaliseren. De eerste is om dubbele gegevens te minimaliseren, de tweede is om problemen met gegevenswijzigingen te minimaliseren of te vermijden, en de derde is om zoekopdrachten te vereenvoudigen.

Terwijl we de verschillende standen van normalisatie doorlopen, zullen we bespreken hoe elk formulier deze problemen aanpakt. Laten we om te beginnen eens kijken naar enkele gegevens die niet genormaliseerd zijn en enkele mogelijke valkuilen bespreken.

Ik denk dat als je eenmaal de problemen begrijpt, je normalisatie beter op prijs stelt. Beschouw de volgende tabel:

Het eerste dat opvalt is dat deze tabel vele doelen dient, waaronder:

1. Het identificeren van de verkopers van de organisatie
2. Het vermelden van de verkopen kantoren en telefoonnummers
3. Een verkoper associëren met een verkoopkantoor
4. De klanten van elke verkoper tonen

Als DBA roept dit een rode vlag op. Over het algemeen zie ik graag tabellen die maar één doel hebben. Door de tafel voor vele doeleinden te dienen, worden veel van de uitdagingen geïntroduceerd; namelijk gegevensduplicatie, problemen met gegevensupdates en verhoogde inspanningen om gegevens op te vragen.

Gegevensduplicatie en afwijkingen aan wijzigingen

Merk op dat we voor elke verkoopmedewerker zowel het verkoopkantoor als het kantoornummer hebben vermeld. Er zijn dubbele verkopersgegevens. Dubbele informatie levert twee problemen op:

1. Het verhoogt de opslag en vermindert de prestaties.
2. Het wordt moeilijker om gegevenswijzigingen bij te houden.

Bijvoorbeeld:

Overweeg of we het kantoor in Chicago verhuizen naar Evanston, IL. Om dit goed weer te geven in onze tabel, moeten we de vermeldingen bijwerken voor alle SalesPersons die momenteel in Chicago zijn. Onze tabel is een klein voorbeeld, maar u kunt zien of deze groter was, dat dit mogelijk honderden updates met zich meebrengt.

Deze situaties zijn afwijkingen van wijzigingen. Database normalisatie lost ze op. Er zijn drie afwijkingen bij wijzigingen die kunnen optreden:

Afwijking invoegen

Er zijn feiten die we pas kunnen registreren als we informatie voor de hele rij kennen. In ons voorbeeld kunnen we pas een nieuw verkoopkantoor opnemen als we ook de verkoper kennen. Waarom? Omdat we een primaire sleutel moeten opgeven om het record te maken. In ons geval is dit de EmployeeID.

Anomalie bijwerken

In dit geval hebben we dezelfde informatie in verschillende rijen. Als het kantoornummer bijvoorbeeld verandert, zijn er meerdere updates die moeten worden doorgevoerd. Als we niet alle rijen bijwerken, verschijnen er inconsistenties.

Afwijkingsafwijking

Het verwijderen van een rij veroorzaakt het verwijderen van meer dan één set feiten. Als John Hunt bijvoorbeeld met pensioen gaat, zorgt het verwijderen van die rij ervoor dat we informatie over het kantoor in New York verliezen.

Problemen met zoeken en sorteren

De laatste reden die we overwegen, is om het zoeken en sorteren van uw gegevens gemakkelijker te maken. Als u in de SalesStaff-tabel wilt zoeken naar een specifieke klant, zoals Ford, moet u een zoekopdracht schrijven als

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

Het is duidelijk dat als de klant op de een of andere manier in één kolom zou onze vraag eenvoudiger zijn. Overweeg ook of u een zoekopdracht wilt uitvoeren en sorteer op klant.

Onze huidige tabel maakt dit moeilijk. U zou drie afzonderlijke UNION-query’s moeten gebruiken!U kunt deze anomalieën elimineren of verminderen door de gegevens in verschillende tabellen te scheiden. Dit plaatst de gegevens in tabellen die maar één doel dienen.

Het proces om de tabel opnieuw te ontwerpen is databasestandaardisatie.

Definitie van database normalisatie

Er zijn drie algemene vormen van database normalisatie: 1e, 2e en 3e normaalvorm. Ze worden ook afgekort als respectievelijk 1NF, 2NF en 3NF.

Er zijn verschillende aanvullende vormen, zoals BCNF, maar ik beschouw deze als gevorderd en niet te noodzakelijk om in het begin te leren.

De vormen zijn progressief, wat betekent dat om in aanmerking te komen voor de 3e normaalvorm, een tafel eerst moet voldoen aan de regels voor de 2e normaalvorm, en de 2e normaalvorm moet voldoen aan die voor de 1e normaalvorm. Voordat we de verschillende vormen en regels in detail bespreken, zullen we de verschillende vormen samenvatten:

• Eerste normale vorm – De informatie wordt opgeslagen in een relationele tabel, waarbij elke kolom atomaire waarden bevat. Er zijn geen herhalende groepen kolommen.
• Tweede normale vorm – De tabel heeft de eerste normale vorm en alle kolommen zijn afhankelijk van de primaire sleutel van de tabel.
• Derde normale vorm – de tabel is in de tweede normale vorm en al zijn kolommen zijn niet transitief afhankelijk van de primaire sleutel.

Maak je geen zorgen als de regels niet al te logisch zijn. Ik heb een link naar een artikel gemaakt om u te helpen ze te begrijpen.

Voor nu is het belangrijk om te begrijpen dat er drie regels zijn voor databasenormalisatie die op elkaar van toepassing zijn. Sommige mensen maken dat databasestandaardisatie ingewikkeld lijkt.

maar dat hoeft niet zo te zijn, en als je het eenmaal begrijpt, wordt het intuïtief.