Ето вашата маса.
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
....
Виждате как сте дублирали името на продукта "Nike Shirt" и цвета "blue". В нормализирана релационна база данни не искаме да дублираме никаква информация. Какво мислите, че би се случило, ако някой случайно промени „Риза Nike“ на „Пола Nike“ в ред 4?
И така, нека нормализираме вашата маса.
Ще започнем с таблица с продукти.
Product
id product
------ ------------
0 Nike Shirt
Обикновено идентификационните номера на базата данни започват с нула, а не с единица.
След това нека създадем таблица с цветове.
Color
id color
------ -------
0 black
1 white
2 blue
След това нека създадем таблица с размери.
Size
id size
------ -----
0 XS
1 S
2 M
3 L
4 XL
5 XXL
Добре, сега имаме 3 отделни таблици с обекти. Как да ги сглобим, за да можем да видим какво има на склад?
Имахте правилната идея с оригиналната си маса.
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
Номерата на продукта, цвета и размера са външни ключове обратно към таблиците Продукт, Цвят и Размер. Причината да правим това е да премахнем дублирането на информацията. Можете да видите, че всяка част от информацията се съхранява на едно място и само на едно място.
Идентификационният номер не е необходим в таблицата със запаси. Продуктът, цветът и размерът трябва да са уникални, така че тези 3 полета могат да съставляват комбиниран ключ към таблицата със запаси.
В действителен магазин за търговия на дребно продуктът може да има много различни атрибути. Атрибутите вероятно ще се съхраняват в таблица ключ/стойност . За вашата проста таблица можем да разделим таблицата на нормализирани релационни таблици.