• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Поняття універсального відношення

Правила побудови реляційних баз даних

Розглянемо основні правила побудови реляційних баз даних:

1. Кожна таблиця складається з однотипних рядків і має унікальне ім'я.

2. Рядки мають фіксоване число полів (стовпців) і значень (множинні поля і групи, що повторюються, недопустимі). Інакше кажучи, в кожній позиції таблиці на перетині рядка і стовпця завжди є в точності одне значення або нічого.

3. Рядки таблиці обов'язково відрізняються один від одного хоч би єдиним значенням, що дозволяє однозначно ідентифікувати будь-який рядок такої таблиці.

4. Стовпцям таблиці однозначно привласнюються імена, і в кожному з них розміщуються однорідні значення даних (дати, прізвища, цілі числа або грошові суми).

5. Повний інформаційний зміст бази даних представляється у вигляді явних значень даних і такий метод уявлення є єдиним. Зокрема, не існує яких-небудь спеціальних "зв'язків" або покажчиків, що сполучають одну таблицю з іншою. Так, зв'язки між рядком з БЛ = 2 таблиці "Блюда" на рис. 3.1 і рядком з ПР = 7 таблиць продукти (для приготування Харчо потрібний Ріс), представляється не за допомогою покажчиків, а завдяки існуванню в таблиці "Склад" рядка, в якому номер блюда дорівнює 2, а номер продукту - 7.

6. При виконанні операцій з таблицею її рядка і стовпці можна обробляти у будь-якому порядку безвідносно до їх інформаційного змісту. Цьому сприяє наявність імен таблиць і їх стовпців, а також можливість виділення будь-якого їх рядка або будь-якого набору рядків з вказаними ознаками (наприклад, рейсів з пунктом призначення "Париж" і часом прибуття до 12 годин).

Припустимо, що проектування бази даних "Живлення" починається з виявлення атрибутів і підбору даних, зразок яких (частина блюд виготовлених і реалізованих 1/9/94 р.) показаний на рис. 3.2.

Цей варіант таблиці "Живлення" не є відношенням, оскільки більшість її рядків не атомарни. Атомарними є лише значення полів Блюдо, Вигляд, Рецепт (хоча він і великий), Порцій і Дата_р решта полів таблиці рис. 3.2- же множинна. Для додання таким даним форми відношення необхідно реконструювати таблицю. Найпростіше це зробити за допомогою простого процесу вставки, результат якої показаний на рис. 3.3. Проте таке перетворення приводить до виникнення великого об'єму надмірних даних.

Таблиця на рис. 3.3 є екземпляром коректного відношення. Його називають універсальним відношенням проектованої БД. У одне універсальне відношення включаються всі атрибути, що представляють інтерес, і воно може містити всі дані, які передбачається розміщувати в БД в майбутньому. Для малих БД (що включають не більше 15 атрибутів) універсальне відношення може використовуватися як відправна крапка при проектуванні БД.

При використанні універсального відношення виникає декілька проблем:

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

2. Потенційна суперечність (аномалії оновлення). Унаслідок надмірності можна відновити адресу постачальника в одному рядку, залишаючи його незмінним в інших. Якщо постачальник каві повідомив про свій переїзд до Харбіну і був оновлений рядок з продуктом кави, то у постачальника "Хуанхе" з'являється дві адреси, один з яких не актуальний. Отже, при оновленнях необхідно проглядати всю таблицю для знаходження і зміни всіх відповідних рядків.

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

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

4. Аномалії видалення. Зворотна проблема виникає при необхідності видалення всіх продуктів, що поставляються даним постачальником або всіх блюд, що використовують ці продукти. При таких видаленнях будуть втрачені відомості про такого постачальника.

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

Рис. 3.2 Дані, необхідні для створення бази даних "Живлення"

Рис.5.3.3 Універсальне відношення "Живлення"

Читайте також:

1. II. Поняття соціального процесу.
2. V. Поняття та ознаки (характеристики) злочинності
3. А/. Поняття про судовий процес.
4. Адміністративний проступок: поняття, ознаки, види.
5. Адміністративні провадження: поняття, класифікація, стадії
6. Акти застосування юридичних норм: поняття, ознаки, види.
7. Аналіз співвідношення активів із джерелами їх фінансування
8. Аналіз ступеня вільності механізму. Наведемо визначення механізму, враховуючи нові поняття.
9. Антонімічні відношення
10. АРХІВНЕ ОПИСУВАННЯ: ПОНЯТТЯ, ВИДИ, ПРИНЦИПИ І МЕТОДИ
11. Аудиторські докази: поняття та процедури отримання
12. Базове поняття земле оціночної діяльності.

Переглядів: 2551