Hier ist dein Tisch.
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
....
Sie sehen, wie Sie den Produktnamen „Nike Shirt“ und die Farbe „Blau“ dupliziert haben. In einer normalisierten relationalen Datenbank möchten wir keine Informationen duplizieren. Was würde Ihrer Meinung nach passieren, wenn jemand in Reihe 4 versehentlich „Nike Shirt“ in „Nike Skirt“ ändern würde?
Lassen Sie uns also normalisieren Ihr Tisch.
Wir beginnen mit einer Produkttabelle.
Product
id product
------ ------------
0 Nike Shirt
Im Allgemeinen beginnen Datenbank-ID-Nummern mit Null, nicht mit Eins.
Als nächstes erstellen wir eine Farbtabelle.
Color
id color
------ -------
0 black
1 white
2 blue
Als nächstes erstellen wir eine Größentabelle.
Size
id size
------ -----
0 XS
1 S
2 M
3 L
4 XL
5 XXL
Ok, jetzt haben wir 3 separate Objekttabellen. Wie stellen wir sie zusammen, damit wir sehen können, was auf Lager ist?
Mit Ihrem Originaltisch hatten Sie die richtige Idee.
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
Die Produkt-, Farb- und Größennummern sind Fremdschlüssel zurück zu den Produkt-, Farb- und Größentabellen. Wir tun dies, um eine Duplizierung der Informationen zu vermeiden. Sie können sehen, dass alle Informationen an einem Ort und nur an einem Ort gespeichert werden.
Die ID ist in der Stock-Tabelle nicht erforderlich. Das Produkt, die Farbe und die Größe sollten eindeutig sein, sodass diese 3 Felder einen zusammengesetzten Schlüssel für die Bestandstabelle bilden könnten.
In einem tatsächlichen Einzelhandelsgeschäft kann ein Produkt viele verschiedene Attribute haben. Die Attribute würden wahrscheinlich in einer Schlüssel/Wert-Tabelle gespeichert . Für Ihre einfache Tabelle können wir die Tabelle in normalisierte relationale Tabellen aufteilen.