Введение в проектирование реляционных баз данных
|
|
|
|
|
|
Зелень
|
180
|
20
|
"Даугава"
|
Рига
|
Латвия
|
15
|
0.99
|
30/8/94
|
|
Кофе
|
Десерт
|
...
|
235
|
1/9/94
|
Кофе
|
2750
|
8
|
"Хуанхэ"
|
Пекин
|
Китай
|
40
|
2.87
|
24/8/94
|
Рис. 4.1. Данные, необходимые для создания базы данных "Питание"
Таблица на рис. 4.2 представляет собой экземпляр корректного отношения. Его называют универсальным отношением проектируемой БД. В одно универсальное
отношение включаются все представляющие интерес атрибуты, и оно может содержать все данные, которые предполагается размещать в БД в будущем. Для малых БД
(включающих не более 15 атрибутов) универсальное отношение может использоваться в качестве отправной точки при проектировании БД.
|
Блюдо
|
Вид
|
Рецепт
|
Порций
|
Дата Р
|
Продукт
|
Калорийность
|
Вес (г)
|
Поставщик
|
Город
|
Страна
|
Вес (кг)
|
Цена ($)
|
Дата П
|
|
Лобио
|
Закуска
|
Лом.
|
158
|
1/9/94
|
Фасоль
|
3070
|
200
|
"Хуанхэ"
|
Пекин
|
Китай
|
250
|
0.37
|
24/8/94
|
|
Лобио
|
Закуска
|
Лом
|
108
|
1/9/94
|
Лук
|
450
|
40
|
"Наталка"
|
Киев
|
Украина
|
100
|
0.52
|
27/8/94
|
|
Лобио
|
Закуска
|
Лом
|
108
|
1/9/94
|
Масло
|
7420
|
30
|
"Лайма"
|
Рига
|
Латвия
|
70
|
1.55
|
30/8/94
|
|
Лобио
|
Закуска
|
Лом
|
108
|
1/9/94
|
Зелень
|
180
|
10
|
"Даугава"
|
Рига
|
Латвия
|
15
|
0.99
|
30/8/94
|
|
Харчо
|
Суп
|
...
|
144
|
1/9/94
|
Мясо
|
1660
|
80
|
"Наталка"
|
Киев
|
Украина
|
100
|
2.18
|
27/8/94
|
|
Харчо
|
Суп
|
...
|
144
|
1/9/94
|
Лук
|
450
|
30
|
"Наталка"
|
Киев
|
Украина
|
100
|
0.52
|
27/8/94
|
|
Харчо
|
Суп
|
...
|
144
|
1/9/94
|
Томаты
|
240
|
40
|
"Полесье"
|
Киев
|
Украина
|
120
|
0.45
|
27/8/94
|
|
Харчо
|
Суп
|
...
|
144
|
1/9/94
|
Рис
|
3340
|
50
|
"Хуанхэ"
|
Пекин
|
Китай
|
75
|
0.44
|
24/8/94
|
|
Харчо
|
Суп
|
...
|
144
|
1/9/94
|
Масло
|
7420
|
15
|
"Полесье"
|
Киев
|
Украина
|
50
|
1.62
|
27/8/94
|
|
Харчо
|
Суп
|
...
|
144
|
1/9/94
|
Зелень
|
180
|
15
|
"Наталка"
|
Киев
|
Украина
|
10
|
0.88
|
27/8/94
|
|
Шашлык
|
Горячее
|
...
|
207
|
1/9/94
|
Мясо
|
1660
|
180
|
"Юрмала"
|
Рига
|
Латвия
|
200
|
2.05
|
30/8/94
|
|
Шашлык
|
Горячее
|
...
|
207
|
1/9/94
|
Лук
|
450
|
40
|
"Полесье"
|
Киев
|
Украина
|
50
|
0.61
|
27/8/94
|
|
Шашлык
|
Горячее
|
...
|
207
|
1/9/94
|
Томаты
|
240
|
100
|
"Полесье"
|
Киев
|
Украина
|
120
|
0.45
|
27/8/94
|
|
Шашлык
|
Горячее
|
...
|
207
|
1/9/94
|
Зелень
|
180
|
20
|
"Даугава"
|
Рига
|
Латвия
|
15
|
0.99
|
30/8/94
|
|
Кофе
|
Десерт
|
...
|
235
|
1/9/94
|
Кофе
|
2750
|
8
|
"Хуанхэ"
|
Пекин
|
Китай
|
40
|
2.87
|
24/8/94
|
Рис. 4.2. Универсальное отношение "Питание"
Почему проект БД может быть плохим?
Начинающий проектировщик будет использовать отношение "Питание" (рис. 4.2)
в качестве завершенной БД. Действительно, зачем разбивать отношение "Питание" на несколько более мелких отношений (см. например, рис. 3.2),
если оно заключает в себе все данные? А разбивать надо потому, что при использовании универсального отношения возникает несколько проблем:
1. Избыточность. Данные практически всех столбцов многократно повторяются. Повторяются и некоторые наборы данных (Блюдо-Вид-Рецепт,
Продукт-Калорийность, Поставщик-Город-Страна). Нежелательно повторение рецептов, некоторые из которых намного больше рецепта "Лобио" (см.
рис. 2.3).
И уж совсем плохо, что все данные о блюде (включая рецепт) повторяются каждый раз, когда это блюдо включается в меню.
2. Потенциальная противоречивость (аномалии обновления). Вследствие избыточности можно обновить адрес поставщика в одной строке, оставляя его
неизменным в других. Если поставщик кофе сообщил о своем переезде в Харбин и была обновлена строка с продуктом кофе, то