Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

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




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

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

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. Аномалії видалення. Зворотна проблема виникає при необхідності видалення всіх продуктів, що поставляються даним постачальником або всіх блюд, що використовують ці продукти. При таких видаленнях будуть втрачені відомості про такого постачальника.

 

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

 

 


 

Блюдо Вид Рецепт Порций Дата Р Продукт Калор. Вес (г) Поставщик Город Страна Вес (кг) Цена ($) Дата П
Лобио Закуска Лом.   1/9/94 Фасоль     "Хуанхэ" Пекин Китай   0.37 24/8/94
          Лук     "Наталка" Киев Украина   0.52 27/8/94
          Масло     "Лайма" Рига Латвия   1.55 30/8/94
          Зелень     "Даугава" Рига Латвия   0.99 30/8/94
Харчо Суп ...   1/9/94 Мясо     "Наталка" Киев Украина   2.18 27/8/94
          Лук     "Наталка" Киев Украина   0.52 27/8/94
          Томаты     "Полесье" Киев Украина   0.45 27/8/94
          Рис     "Хуанхэ" Пекин Китай   0.44 24/8/94
          Масло     "Полесье" Киев Украина   1.62 27/8/94
          Зелень     "Наталка" Киев Украина   0.88 27/8/94
Шашлык Горячее ...   1/9/94 Мясо     "Юрмала" Рига Латвия   2.05 30/8/94
          Лук     "Полесье" Киев Украина   0.61 27/8/94
          Томаты     "Полесье" Киев Украина   0.45 27/8/94
          Зелень     "Даугава" Рига Латвия   0.99 30/8/94
Кофе Десерт ...   1/9/94 Кофе     "Хуанхэ" Пекин Китай   2.87 24/8/94

 

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

 

Блюдо Вид Рецепт Порций Дата Р Продукт Калор. Вес (г) Поставщик Город Страна Вес (кг) Цена ($) Дата П
Лобио Закуска Лом.   1/9/94 Фасоль     "Хуанхэ" Пекин Китай   0.37 24/8/94
Лобио Закуска Лом   1/9/94 Лук     "Наталка" Киев Украина   0.52 27/8/94
Лобио Закуска Лом   1/9/94 Масло     "Лайма" Рига Латвия   1.55 30/8/94
Лобио Закуска Лом   1/9/94 Зелень     "Даугава" Рига Латвия   0.99 30/8/94
Харчо Суп Лом   1/9/94 Мясо     "Наталка" Киев Украина   2.18 27/8/94
Харчо Суп Лом   1/9/94 Лук     "Наталка" Киев Украина   0.52 27/8/94
Харчо Суп Лом   1/9/94 Томаты     "Полесье" Киев Украина   0.45 27/8/94
Харчо Суп Лом   1/9/94 Рис     "Хуанхэ" Пекин Китай   0.44 24/8/94
Харчо Суп Лом   1/9/94 Масло     "Полесье" Киев Украина   1.62 27/8/94
Харчо Суп Лом   1/9/94 Зелень     "Наталка" Киев Украина   0.88 27/8/94
Шашлык Горячее Лом   1/9/94 Мясо     "Юрмала" Рига Латвия   2.05 30/8/94
Шашлык Горячее Лом   1/9/94 Лук     "Полесье" Киев Украина   0.61 27/8/94
Шашлык Горячее Лом   1/9/94 Томаты     "Полесье" Киев Украина   0.45 27/8/94
Шашлык Горячее Лом   1/9/94 Зелень     "Даугава" Рига Латвия   0.99 30/8/94
Кофе Десерт Лом   1/9/94 Кофе     "Хуанхэ" Пекин Китай   2.87 24/8/94

 

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





Поделиться с друзьями:


Дата добавления: 2013-12-12; Просмотров: 247; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.012 сек.