Database Normalisering: Forskelle mellem versioner
Bar (diskussion | bidrag) Oprettede siden med "<ref>[https://onecompiler.com/mysql onecompiler.com] har et afsnit med MySQL-sproget, som kan sætte en database op, lægge data i og trække dem ud igen</ref> ==Referencer== <references /> Kategori:Database" |
Bar (diskussion | bidrag) Ingen redigeringsopsummering |
||
| Linje 1: | Linje 1: | ||
Det at sikre sig at en database er opbygget så den er effektiv og god at bruge kaldes at normalisere en database. | |||
Hvis en database ikke er normaliseret, så vil man opleve, at det er svært at bruge databasen, altså at kunne trække de ting og sammenhænge ud af databasen som man ønsker. | |||
For at normalisere en database skal man igennem 3 punkter efter hinanden. | |||
==1. Normalform== | |||
Det første man gør er at sikre at man ikke har felter (attributter) i sin database, der indeholder flere oplysninger, det kunne fx være dommerne ved er idrætsstævne. Her må man ikke oprette en attribut der hedder dommere, hvor man så ville skrive dommernavnene til det aktuelle stævne. Man skal i stedet lave en tabel med dommerne, så hver dommer har sin egen post, og så kan man lave relationer til stævnet | |||
==2. Normalform== | |||
Når man har lavet 1. normalform, skal man sikre at hver enkelt post har en unik attribut, så man altid kan henvise til en post ved hjælp af denne attribut - den vil man betegne som den primære nøgle i tabellen. | |||
Hvis man ikke umiddelbart har en egenskab i tabellen, som er egnet til at være primær nøgle, så kan man oprette en attribut der hedder ID, som blot er et fortløbende nummer. | |||
Den primære nøgle vil normalt være et heltal (det er mest effektivt i en database). | |||
==3. Normalform== | |||
Det sidste der skal gøres er at undgå redundans. | |||
Redundans er der hvor oplysninger bliver gentaget, ved at man skriver oplysningerne ind igen. | |||
Hvis man fx skriver alle kundens oplysninger ind i fakturatabellen, så skal man skrive alle oplysninger om kunden hver gang man opretter en ordre. Der er to ulemper ved det: dels at man kommer til at spilde plads, fordi det blot er gentagelser og dels at man risikerer at oplysningerne bliver forskellige. I stedet skal man i fakturatabellen henvise til en kunde i en kunde-tabel. Her indsætter man en fremmed nøgle i fakturatabellen (kundenummer) som henviser til den primære nøgle i kundetabellen (kundenummer). På den måde kommer alle kundens oplysninger kun til at ligge én gang i database, uanset hvor mange fakturaer der oprettes til kunden. | |||
==Mere information== | |||
Der er mere at læse i systimes bøger (kræver et login). | |||
Normalformer er gennemgået på: [https://informatik.systime.dk/?id=1139 Normalformer] | |||
<ref>[https://informatik.systime.dk/?id=1139 Systimes bog Informatik C] om Normalformer</ref> | |||
Normalisering er gennemgået under: [https://informatikbeux.systime.dk/?id=1056 Normalisering] | |||
<ref>[https://informatikbeux.systime.dk/?id=1056 Systimes bog Informatik B til EUX] om Normalisering af databaser</ref> | |||
==Referencer== | ==Referencer== | ||
Versionen fra 1. nov. 2025, 12:42
Det at sikre sig at en database er opbygget så den er effektiv og god at bruge kaldes at normalisere en database.
Hvis en database ikke er normaliseret, så vil man opleve, at det er svært at bruge databasen, altså at kunne trække de ting og sammenhænge ud af databasen som man ønsker.
For at normalisere en database skal man igennem 3 punkter efter hinanden.
1. Normalform
Det første man gør er at sikre at man ikke har felter (attributter) i sin database, der indeholder flere oplysninger, det kunne fx være dommerne ved er idrætsstævne. Her må man ikke oprette en attribut der hedder dommere, hvor man så ville skrive dommernavnene til det aktuelle stævne. Man skal i stedet lave en tabel med dommerne, så hver dommer har sin egen post, og så kan man lave relationer til stævnet
2. Normalform
Når man har lavet 1. normalform, skal man sikre at hver enkelt post har en unik attribut, så man altid kan henvise til en post ved hjælp af denne attribut - den vil man betegne som den primære nøgle i tabellen.
Hvis man ikke umiddelbart har en egenskab i tabellen, som er egnet til at være primær nøgle, så kan man oprette en attribut der hedder ID, som blot er et fortløbende nummer. Den primære nøgle vil normalt være et heltal (det er mest effektivt i en database).
3. Normalform
Det sidste der skal gøres er at undgå redundans.
Redundans er der hvor oplysninger bliver gentaget, ved at man skriver oplysningerne ind igen.
Hvis man fx skriver alle kundens oplysninger ind i fakturatabellen, så skal man skrive alle oplysninger om kunden hver gang man opretter en ordre. Der er to ulemper ved det: dels at man kommer til at spilde plads, fordi det blot er gentagelser og dels at man risikerer at oplysningerne bliver forskellige. I stedet skal man i fakturatabellen henvise til en kunde i en kunde-tabel. Her indsætter man en fremmed nøgle i fakturatabellen (kundenummer) som henviser til den primære nøgle i kundetabellen (kundenummer). På den måde kommer alle kundens oplysninger kun til at ligge én gang i database, uanset hvor mange fakturaer der oprettes til kunden.
Mere information
Der er mere at læse i systimes bøger (kræver et login).
Normalformer er gennemgået på: Normalformer [1]
Normalisering er gennemgået under: Normalisering [2]
Referencer
- ↑ Systimes bog Informatik C om Normalformer
- ↑ Systimes bog Informatik B til EUX om Normalisering af databaser