Універсальне відношення як основа реляційного представлення даних
У реляційній моделі даних як дані, так і їх зв'язки представляються за допомогою відношень. Відношення зручно представляти у вигляді таблиць. Рядки таблиць відповідають кортежам. Кожний рядок фактично являє собою опис одного об'єкта реального світу, характеристики якого містяться в стовпцях. Іменована множина пар "ім'я атрибута - ім'я домену" називається схемою відношення. Потужність цієї множини називають ступенем чи "арністью" відношення. Набір іменованих схем відношень представляє із себе схему бази даних.
Припустимо, що проектування бази даних "Харчування" починається з виявлення атрибутів і добору даних, зразок яких (частина блюд виготовлених і реалізованих 1/9/04 р.) показаний на рис. 1. Цей варіант таблиці "Харчування" не є відношенням, тому що більшість її рядків не атомарні (тобто є багатозначні атрибути, значення яких фактично представлене масивами). Атомарними є лише значення полів Блюдо, Вид, Рецепт (хоча він і великий), Порцій і Дата_Р; інші ж поля таблиці рис. 1 – множинні. Для надання таким даним форми відношеня необхідно реконструювати таблицю. Найбільше просто це зробити за допомогою простого процесу вставки, результат якої показаний на рис. 2. Однак таке перетворення приводить до виникнення великого обсягу надлишкових даних.
Таблиця на рис. 2 являє собою екземпляр коректного відношення, у якому виконана умова атомарності атрибутів. Його називають універсальним відношенням проектованої БД. В одне універсальне відношення включаються всі атрибути, варті уваги, і воно може містити всі дані, що передбачається розміщати в БД у майбутньому. Для малих БД (не більш 15атрибутів) універсальне відношення може використовуватися як відправну точку при проектуванні БД.
|
|
|
Рис. 1. Дані, необхідні для створення бази даних "Харчування"
Рис. 2. Универсальне відношення "Харчування"
При спробі застосування універсального відношення в якості завершеної БД виникне кілька проблем:
1. Надлишковість. Дані практично всіх стовпців багаторазово повторюються. Повторюються і деякі набори даних (Блюдо-Вид-Рецепт, Продукт-Калорійність, Постачальник-Місто-Країна). І вже зовсім погано, що всі дані про блюдо (включаючи рецепт) повторюються щоразу, коли це блюдо включається в меню.
2. Потенційна суперечливість. Унаслідок надмірності можна обновити адресу постачальника в одному рядку, залишаючи її незмінною в інших. Якщо постачальник кави повідомив про свій переїзд у Харбін і був оновлений рядок із продуктом кава, то в постачальника "Хуанхэ" з'являється дві адреси, один із яких не актуальна. Отже, при оновленнях необхідно переглядати всю таблицю для знаходження і зміни всіх придатних рядків.
|
|
|
3. Різні аномалії зміни даних. У БД не може бути записаний новий постачальник ("Няринга", Вільнюс, Литва), якщо продукт, що поставляється їм, (Огірки) не використовується в жодному блюді. З аналогічних причин не можна ввести і новий продукт (наприклад, Баклажани), що пропонує існуючий постачальник (наприклад, "Полісся"). А як увести нове блюдо, якщо в ньому використовується новий продукт (Краби)? Зворотна проблема виникає при необхідності видалення всіх продуктів, що поставляються даним постачальником чи усіх блюд, що використовують ці продукти. При таких видаленнях будуть втрачені відомості про такого постачальника.
Дата добавления: 2016-01-05; просмотров: 19; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!