DBMS-normalisatie: 1NF, 2NF, 3NF databasevoorbeeld

Wat is databasenormalisatie?

Normalisatie is een databaseontwerptechniek die gegevensredundantie vermindert en ongewenste kenmerken zoals anomalieën bij het invoegen, bijwerken en verwijderen elimineert. Normalisatieregels verdelen grotere tabellen in kleinere tabellen en koppelen deze met behulp van relaties. Het doel van Normalisatie in SQL is om overtollige (repetitieve) gegevens te elimineren en ervoor te zorgen dat gegevens logisch worden opgeslagen.

De uitvinder van de relationeel model Edgar Codd stelde de theorie van normalisatie van gegevens voor met de introductie van de Eerste Normaalvorm, en hij bleef de theorie uitbreiden met de Tweede en Derde Normaalvorm. Later hij sloot zich aan bij Raymond F. Boyce om de theorie van de Boyce-Codd-normaalvorm te ontwikkelen.

Soorten normale formulieren in DBMS

Hier is een lijst met normale formulieren in SQL:

• 1NF (Eerste normale vorm): Zorgt ervoor dat de databasetabel zo is georganiseerd dat elke kolom atomaire (ondeelbare) waarden bevat en elk record uniek is. Dit elimineert herhalende groepen en structureert zo gegevens in tabellen en kolommen.
• 2NF (tweede normaalvorm): Bouwt voort op 1NF door We moeten overtollige gegevens verwijderen uit een tabel die op meerdere rijen wordt toegepast. en plaats ze in aparte tabellen. Het vereist dat alle niet-sleutelattributen volledig functioneel zijn op de primaire sleutel.
• 3NF (derde normale vorm): Breidt 2NF uit door ervoor te zorgen dat alle niet-sleutelattributen niet alleen volledig functioneel zijn op de primaire sleutel, maar ook onafhankelijk van elkaar. Dit elimineert transitieve afhankelijkheid.
• BCNF (Boyce-Codd normale vorm): Een verfijning van 3NF die afwijkingen aanpakt die niet door 3NF worden afgehandeld. Het vereist dat elke determinant een kandidaat-sleutel is, waardoor een nog striktere naleving van de normalisatieregels wordt gegarandeerd.
• 4NF (vierde normaalvorm): Adressen afhankelijkheden met meerdere waarden. Het zorgt ervoor dat er geen meerdere onafhankelijke feiten met meerdere waarden over een entiteit in een record voorkomen.
• 5NF (vijfde normaalvorm): Ook bekend als "Projection-Join Normal Form" (PJNF). Het heeft betrekking op de reconstructie van informatie uit kleinere, anders gerangschikte gegevensstukken.
• 6NF (zesde normaalvorm): Theoretisch en niet op grote schaal geïmplementeerd. Het behandelt temporele gegevens (het omgaan met veranderingen in de loop van de tijd) door tabellen verder te ontbinden om alle niet-tijdelijke redundantie te elimineren.

De theorie van datanormalisatie in MySQL server wordt nog verder ontwikkeld. Er zijn bijvoorbeeld zelfs discussies over 6^th Normale vorm. In de meeste praktische toepassingen bereikt normalisatie echter het beste in 3^rd Normale vorm. De evolutie van normalisatie in SQL-theorieën wordt hieronder geïllustreerd:

Hier zie je De kolom Films gehuurd heeft meerdere waarden. Laten we nu naar de eerste normaalvormen gaan:

Eerste normale vorm (1NF)

• Elke tabelcel moet één enkele waarde bevatten.
• Elk record moet uniek zijn.

De bovenstaande tabel in 1NF-

1NF-voorbeeld

Een primaire waarde is een waarde uit één kolom die wordt gebruikt om een ​​databaserecord op unieke wijze te identificeren.

Het heeft de volgende kenmerken

• A hoofdsleutel Kan niet nul zijn
• Een primaire sleutelwaarde moet uniek zijn
• De primaire sleutelwaarden mogen zelden worden gewijzigd
• Bij het invoegen van een nieuw record moet de primaire sleutel een waarde krijgen.

Wat is samengestelde sleutel?

Een samengestelde sleutel is een primaire sleutel die bestaat uit meerdere kolommen en wordt gebruikt om een ​​record uniek te identificeren

In onze database hebben we twee mensen met dezelfde naam Robert Phil, maar ze wonen op verschillende plaatsen.

Daarom hebben we zowel de volledige naam als het adres nodig om een ​​record uniek te identificeren. Dat is een samengestelde sleutel.

Laten we naar de tweede normaalvorm 2NF gaan

Tweede normale vorm (2NF)

• Regel 1 - Wees in 1NF
• Regel 2 - Primaire sleutel met één kolom die functioneel niet afhankelijk is van een subset van de kandidaat-sleutelrelatie

Het is duidelijk dat we niet verder kunnen gaan met het maken van onze eenvoudige database in 2^nd Normalisatieformulier, tenzij we de bovenstaande tabel verdelen.

We hebben onze 1NF-tabel in twee tabellen verdeeld, namelijk Tabel 1 en Tabel 2. Tabel 1 bevat ledeninformatie. Tabel 2 bevat informatie over gehuurde films.

We hebben een nieuwe kolom geïntroduceerd met de naam Membership_id, die de primaire sleutel is voor tabel 1. Records kunnen uniek worden geïdentificeerd in Tabel 1 met behulp van lidmaatschaps-ID

Database – Vreemde sleutel

In Tabel 2 is Membership_ID de externe sleutel

Foreign Key verwijst naar de primaire sleutel van een andere tabel! Het helpt uw ​​tabellen met elkaar te verbinden

• Een externe sleutel kan een andere naam hebben dan de primaire sleutel
• Het zorgt ervoor dat rijen in de ene tabel overeenkomstige rijen in een andere tabel hebben
• In tegenstelling tot de primaire sleutel hoeven ze niet uniek te zijn. Meestal zijn ze dat niet
• Externe sleutels kunnen nul zijn, ook al zijn primaire sleutels dat niet

Waarom heb je een externe sleutel nodig?

Stel dat een beginneling een record in tabel B invoegt, zoals

U kunt alleen waarden in uw refererende sleutel invoegen die bestaan ​​in de unieke sleutel in de bovenliggende tabel. Dit helpt bij referentiële integriteit.

Het bovenstaande probleem kan worden opgelost door het lidmaatschaps-ID uit Tabel2 te declareren als de externe sleutel van het lidmaatschaps-ID uit Tabel1

Als iemand nu een waarde in het lidmaatschaps-ID-veld probeert in te voegen die niet bestaat in de bovenliggende tabel, wordt er een foutmelding weergegeven!

Wat zijn transitieve functionele afhankelijkheden?

Een transitief functionele afhankelijkheid is bij het wijzigen van een niet-sleutelkolom, kan ertoe leiden dat een van de andere niet-sleutelkolommen verandert

Bekijk tabel 1. Als u de niet-sleutelkolom Volledige naam wijzigt, kan de aanhef veranderen.

Laten we naar 3NF gaan

Derde normale vorm (3NF)

• Regel 1 - Wees in 2NF
• Regel 2- Heeft geen transitieve functionele afhankelijkheden

Om onze 2NF-tabel naar 3NF te verplaatsen, moeten we onze tabel opnieuw verdelen.

3NF-voorbeeld

Hieronder ziet u een 3NF-voorbeeld in de SQL-database:

Boyce-Codd normale vorm (BCNF)

Voordelen van normale vorm

• Verbeter de consistentie van gegevens: Normalisatie zorgt ervoor dat elk stukje gegevens op slechts één plek wordt opgeslagen, waardoor de kans op inconsistente gegevens wordt verkleind. Wanneer gegevens worden bijgewerkt, hoeven deze slechts op één plaats te worden bijgewerkt, waardoor consistentie wordt gegarandeerd.
• Verminder gegevensredundantie: Normalisatie helpt dubbele gegevens te elimineren door deze in meerdere, gerelateerde tabellen te verdelen. Dit kan opslagruimte besparen en de database ook efficiënter maken.
• Verbeter de queryprestaties: Genormaliseerde databases zijn vaak gemakkelijker te doorzoeken. Omdat gegevens logisch zijn georganiseerd, kunnen query's worden geoptimaliseerd om sneller te worden uitgevoerd.
• Maak gegevens betekenisvoller: Normalisatie houdt in dat gegevens worden gegroepeerd op een manier die logisch en intuïtief is. Dit kan de database gemakkelijker te begrijpen en te gebruiken maken, vooral voor mensen die de database niet hebben ontworpen.
• Verklein de kans op afwijkingen: Afwijkingen zijn problemen die kunnen optreden bij het toevoegen, bijwerken of verwijderen van gegevens. Normalisatie kan de kans op deze afwijkingen verkleinen door ervoor te zorgen dat gegevens logisch zijn georganiseerd.

Nadelen van normalisatie

• Verhoogde complexiteit: Normalisatie kan leiden tot complexe relaties. Een groot aantal tabellen met vreemde sleutels kan moeilijk te beheren zijn, wat leidt tot verwarring.
• Verminderde flexibiliteit: Vanwege de strikte regels voor normalisatie is er mogelijk minder flexibiliteit bij het opslaan van gegevens die niet aan deze regels voldoen.
• Verhoogde opslagvereisten: Hoewel normalisatie de redundantie vermindert, kan het nodig zijn om meer opslagruimte toe te wijzen om plaats te bieden aan de extra tabellen en indices.
• Prestaties overheadkosten: Het samenvoegen van meerdere tabellen kan kostbaar zijn in termen van prestaties. Hoe meer genormaliseerd de gegevens, hoe meer joins er nodig zijn, wat de ophaaltijden van gegevens kan vertragen.
• Verlies van gegevenscontext: Normalisatie splitst gegevens op in afzonderlijke tabellen, wat kan leiden tot verlies van bedrijfscontext. Het onderzoeken van gerelateerde tabellen is noodzakelijk om de context van een gegeven te begrijpen.
• Behoefte aan deskundige kennis: Het implementeren van een genormaliseerde database vereist een diepgaand begrip van de gegevens, de relaties tussen gegevens en de normalisatieregels. Dit vereist specialistische kennis en kan tijdrovend zijn.

Dat is alles voor SQL-normalisatie!!!

Conclusie

• Ontwerpen van databases is van cruciaal belang voor de succesvolle implementatie van een databasebeheersysteem dat voldoet aan de gegevensvereisten van een bedrijfssysteem.
• Normalisatie in DBMS is een proces dat helpt databasesystemen te produceren die kosteneffectief zijn en betere beveiligingsmodellen hebben.
• Functionele afhankelijkheden zijn een zeer belangrijk onderdeel van het normalisatieproces van gegevens
• De meeste databasesystemen zijn genormaliseerde databases tot aan de derde normaalvorm in DBMS.
• Een primaire sleutel identificeert op unieke wijze een record in een tabel en kan niet nul zijn
• Een externe sleutel helpt bij het verbinden van de tabel en verwijst naar een primaire sleutel