Hier is je tafel.
Shirt
id product color size stock
---------------------------------------------
1 Nike Shirt black M 5
2 Nike Shirt white L 10
3 Nike Shirt blue M 2
4 Nike Shirt blue XL 3
....
Je ziet hoe je de productnaam "Nike Shirt" en de kleur "blauw" hebt gekopieerd. In een genormaliseerde relationele database willen we geen informatie dupliceren. Wat denk je dat er zou gebeuren als iemand per ongeluk 'Nike Shirt' in 'Nike Skirt' zou veranderen in rij 4?
Dus laten we normaliseren uw tafel.
We beginnen met een producttabel.
Product
id product
------ ------------
0 Nike Shirt
Over het algemeen beginnen database-ID-nummers met nul, niet met één.
Laten we vervolgens een kleurentabel maken.
Color
id color
------ -------
0 black
1 white
2 blue
Laten we vervolgens een maattabel maken.
Size
id size
------ -----
0 XS
1 S
2 M
3 L
4 XL
5 XXL
Ok, nu hebben we 3 aparte objecttabellen. Hoe stellen we ze samen zodat we kunnen zien wat er op voorraad is?
Je had het juiste idee met je originele tafel.
Stock
id product color size stock
---------------------------------------------
0 0 0 2 5
1 0 1 3 10
2 0 2 2 2
3 0 2 4 3
De product-, kleur- en maatnummers zijn refererende sleutels terug naar de Product-, Kleur- en Maattabellen. De reden dat we dit doen, is om dubbele informatie te voorkomen. U kunt zien dat elk stukje informatie op één plaats en slechts op één plaats wordt opgeslagen.
De id is niet nodig in de Stock-tabel. Het product, de kleur en de maat moeten uniek zijn, dus die 3 velden kunnen een samengestelde sleutel vormen voor de voorraadtabel.
In een echte winkel kan een product veel verschillende kenmerken hebben. De attributen zouden waarschijnlijk worden opgeslagen in een sleutel/waarde-tabel . Voor uw eenvoudige tabel kunnen we de tabel opsplitsen in genormaliseerde relationele tabellen.