Основы проектирования реляционных баз данных. Учебное пособие

Почему проект БД может быть плохим?


Начинающий проектировщик будет использовать отношение "Питание" (рис. ) в качестве завершенной БД. Действительно, зачем разбивать отношение "Питание" на несколько более мелких отношений (см. например, рис. ), если оно заключает в себе все данные? А разбивать надо потому, что при использовании универсального отношения возникает несколько проблем:

1. Избыточность. Данные практически всех столбцов многократно повторяются. Повторяются и некоторые наборы данных (Блюдо-Вид-Рецепт, Продукт-Калорийность, Поставщик-Город-Страна). Нежелательно повторение рецептов, некоторые из которых намного больше рецепта "Лобио" (см. рис. ). И уж совсем плохо, что все данные о блюде (включая рецепт) повторяются каждый раз, когда это блюдо включается в меню.

2. Потенциальная противоречивость (аномалии обновления). Вследствие избыточности можно обновить адрес поставщика в одной строке, оставляя его неизменным в других. Если поставщик кофе сообщил о своем переезде в Харбин и была обновлена строка с продуктом кофе, то у поставщика "Хуанхэ" появляется два адреса, один из которых не актуален. Следовательно, при обновлениях необходимо просматривать всю таблицу для нахождения и изменения всех подходящих строк.

3. Аномалии включения. В БД не может быть записан новый поставщик ("Няринга", Вильнюс, Литва), если поставляемый им продукт (Огурцы) не используется ни в одном блюде. Можно, конечно, поместить неопределенные значения в столбцы Блюдо, Вид, Порций и Вес (г) для этого поставщика. Но если появится блюдо, в котором используется этот продукт, не забудем ли мы удалить строку с неопределенными значениями?

По аналогичным причинам нельзя ввести и новый продукт (например, Баклажаны), который предлагает существующий поставщик (например, "Полесье"). А как ввести новое блюдо, если в нем используется новый продукт (Крабы)?

4. Аномалии удаления. Обратная проблема возникает при необходимости удаления всех продуктов, поставляемых данным поставщиком или всех блюд, использующих эти продукты.
При таких удалениях будут утрачены сведения о таком поставщике.

Многие проблемы этого примера исчезнут, если выделить в отдельные таблицы сведения о блюдах, рецептах, расходе блюд, продуктах и их поставщиках, а также создать связующие таблицы "Состав" и "Поставки" (рис. 4.3).

Блюда БлюдоВид

ЛобиоЗакуска
ХарчоСуп
ШашлыкГорячее
КофеДесерт
......
Рецепты БлюдоРецепт
ЛобиоЛоманую очищ
......
Расход БлюдоПорцийДата_Р
Лобио1581/9/94
Харчо1441/9/94
Шашлык2071/9/94
Кофе2351/9/94
.........
Продукты ПродуктКалор.
Фасоль3070
Лук450
Масло7420
Зелень180
Мясо1660
......
Состав БлюдоПродуктВес (г)
ЛобиоФасоль200
ЛобиоЛук40
ЛобиоМасло30
ЛобиоЗелень10
ХарчоМясо80
.........
Поставщики ПоставщикГородСтрана
"Полесье"КиевУкраина
"Наталка"КиевУкраина
"Хуанхэ"ПекинКитай
"Лайма"РигаЛатвия
"Юрмала"РигаЛатвия
.........
Поставки ПоставщикГородПродуктВес (кг)Цена ($)Дата_П
"Полесье"КиевТоматы1200.4527/8/94
"Полесье"КиевМасло501.6227/8/94
"Полесье"КиевЛук500.6127/8/94
"Наталка"КиевЛук1000.5227/8/94
..................
Рис. 4.3. Преобразование универсального отношения "Питание" (первый вариант)

Включение. Простым добавлением строк (Поставщики; "Няринга", Вильнюс, Литва) и (Поставки; "Няринга", Вильнюс, Огурцы, 40) можно ввести информацию о новом поставщике. Аналогично можно ввести данные о новом продукте (Продукты; Баклажаны, 240) и (Поставки; "Полесье", Киев, Баклажаны, 50).

Удаление. Удаление сведений о некоторых поставках или блюдах не приводит к потере сведений о поставщиках.

Обновление. В таблицах рис. 4.3 все еще много повторяющихся данных, находящихся в связующих таблицах (Состав и Поставки). Следовательно, в данном варианте БД сохранилась потенциальная противоречивость: для изменения названия поставщика с "Полесье" на "Днепро" придется изменять не только строку таблицы Поставщики, но и множество строк таблицы Поставки.


При этом не исключено, что в БД будут одновременно храниться: "Полесье", "Палесье", "Днепро", "Днипро" и другие варианты названий.

Кроме того, повторяющиеся текстовые данные (такие как название блюда "Рулет из телячей грудинки с сосисками и гарниром из разноцветного пюре" или продукта "Колбаса московская сырокопченая") существенно увеличивают объем хранимых данных.

Для исключения ссылок на длинные текстовые значения последние обычно нумеруют: нумеруют блюда в больших кулинарных книгах, товары (продукты) в каталогах и т.д. Воспользуемся этим приемом для исключения избыточного дублирования данных и появления ошибок при копировании длинных текстовых значений (рис. 4.4). Теперь при изменении названия поставщика "Полесье" на "Днепро" исправляется единственное значение в таблице Поставщики. И даже если оно вводится с ошибкой ("Днипро"), то это не может повлиять на связь между поставщиками и продуктами (в связующей таблице Поставки используются номера поставщиков и продуктов, а не их названия).

Блюда БЛБлюдоВид
1ЛобиоЗакуска
2ХарчоСуп
3ШашлыкГорячее
4КофеДесерт
.........
Рецепты БлюдоРецепт
ЛобиоЛоманую очищ
......
Расход БлюдоПорцийДата_Р
Лобио1581/9/94
Харчо1441/9/94
Шашлык2071/9/94
Кофе2351/9/94
.........
Продукты ПРПродуктКалор.
1Фасоль3070
2Лук450
3Масло7420
4Зелень180
5Мясо1660
.........
Состав БЛПРВес (г)
11200
1240
1330
1410
2580
.........
Поставщики ПОСПоставщикГородСтрана
1"Полесье"КиевУкраина
2"Наталка"КиевУкраина
3"Хуанхэ"ПекинКитай
4"Лайма"РигаЛатвия
5"Юрмала"РигаЛатвия
............
Поставки ПОСПРВес (кг)Цена ($)Дата_П
161200.4527/8/94
13501.6227/8/94
12500.6127/8/94
221000.5227/8/94
...............
Рис. 4.4. Преобразование универсального отношения "Питание" (второй вариант)

[] [] []


Содержание раздела