Page 128 - 4505

Ріс), представляється не за допомогою покажчиків, а завдяки існуванню в таблиці "Склад"
рядка, в якому номер блюда дорівнює 2, а номер продукту - 7.
6. При виконанні операцій з таблицею її рядка і стовпці можна обробляти у будь-якому
порядку безвідносно до їх інформаційного змісту. Цьому сприяє наявність імен таблиць і їх
стовпців, а також можливість виділення будь-якого їх рядка або будь-якого набору рядків з
вказаними ознаками (наприклад, рейсів з пунктом призначення "Париж" і часом прибуття до 12
годин).
5.3.3 Поняття універсального відношення
Припустимо, що проектування бази даних "Живлення" починається з виявлення атрибутів
і підбору даних, зразок яких (частина блюд виготовлених і реалізованих 1/9/94 р.) показаний на
рис. 3.2.
Цей варіант таблиці "Живлення" не є відношенням, оскільки більшість її рядків не
атомарни. Атомарними є лише значення полів Блюдо, Вигляд, Рецепт (хоча він і великий),
Порцій і Дата_р решта полів таблиці рис. 3.2- же множинна. Для додання таким даним форми
відношення необхідно реконструювати таблицю. Найпростіше це зробити за допомогою
простого процесу вставки, результат якої показаний на рис. 3.3. Проте таке перетворення
приводить до виникнення великого об'єму надмірних даних.
Таблиця на рис. 3.3 є екземпляром коректного відношення. Його називають універсальним
відношенням проектованої БД. У одне універсальне відношення включаються всі атрибути, що
представляють інтерес, і воно може містити всі дані, які передбачається розміщувати в БД в
майбутньому. Для малих БД (що включають не більше 15 атрибутів) універсальне відношення
може використовуватися як відправна крапка при проектуванні БД.
При використанні універсального відношення виникає декілька проблем:
1. Надмірність. Дані практично всіх стовпців багато разів повторюються.
Повторюються і деякі набори даних (Блюдо-Вид-рецепт, Продукт-Калорійність, Поставщик-
Город-страна). Небажане повторення рецептів, деякі з яких набагато більше рецепту "Лобіо". І
вже зовсім погано, що всі дані про блюдо (включаючи рецепт) повторюються кожного разу,
коли це блюдо включається в меню.
2. Потенційна суперечність (аномалії оновлення). Унаслідок надмірності можна
відновити адресу постачальника в одному рядку, залишаючи його незмінним в інших. Якщо
постачальник каві повідомив про свій переїзд до Харбіну і був оновлений рядок з продуктом
кави, то у постачальника "Хуанхе" з'являється дві адреси, один з яких не актуальний. Отже, при
оновленнях необхідно проглядати всю таблицю для знаходження і зміни всіх відповідних
рядків.
3. Аномалії включення. У БД не може бути записаний новий постачальник
("Нярінга", Вільнюс, Литва), якщо продукт (Огірки), що поставляється ним, не
використовується ні в одному блюді. Можна, звичайно, помістити невизначені значення в
стовпці Блюдо, Вигляд, Порцій і Вес (г) для цього постачальника. Але якщо з'явиться блюдо, в
якому використовується цей продукт, чи не забудемо ми видалити рядок з невизначеними
значеннями?
По аналогічних причинах не можна ввести і новий продукт (наприклад, Баклажани),
який пропонує існуючий постачальник (наприклад, "Полісся"). А як ввести нове блюдо, якщо в
нім використовується новий продукт (Краби)?
4. Аномалії видалення. Зворотна проблема виникає при необхідності видалення всіх
продуктів, що поставляються даним постачальником або всіх блюд, що використовують ці
продукти. При таких видаленнях будуть втрачені відомості про такого постачальника.

Багато проблем цього прикладу зникнуть, якщо виділити в окремі таблиці відомості про
блюда, рецепти, витрату блюд, продукти і їх постачальників, а також створити таблиці, що
пов'язують, "Склад" і "Постачання".

126