Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
ПРОЕКТУВАННЯ РЕЛЯЦІЙНОЇ БАЗИ ДАНИХ НА КОНЦЕПТУАЛЬНОМУ РІВНІ
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Управління інформацією
Кафедра:
Не вказано
Інформація про роботу
Рік:
2015
Тип роботи:
Методичні вказівки до лабораторної роботи
Предмет:
Інформаційні технології
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ “ЛЬВІВСЬКА ПОЛІТЕХНІКА”
ПРОЕКТУВАННЯ РЕЛЯЦІЙНОЇ БАЗИ ДАНИХ НА КОНЦЕПТУАЛЬНОМУ РІВНІ
МЕТОДИЧНІ ВКАЗІВКИ
до лабораторної роботи № 1
з курсу “Бази даних та знань”
для студентів базового напрямку
6.170102 «Системи технічного захисту інформації», 6.170103 «Управління інформаційною безпекою», 6.170101 «Безпека інформаційних технологій»
Затверджено
на засіданні кафедри
“Захист інформації” протокол № 16 від 11.06.2015 р.
Львів – 2015
Проектування реляційної бази даних на концептуальному рівні: Методичні вказівки до лабораторної роботи №1 з курсу “Бази даних та знань” для студентів базового напрямку 6.170102 «Системи технічного захисту інформації», 6.170103 «Управління інформаційною безпекою», 6.170101 «Безпека інформаційних технологій» / Укл. А.І. Партика, О.І. Гарасимчук. - Львів: НУЛП, 2015. – 25с.
Укладачі: Партика А.І, канд. техн. наук, асистент
Гарасимчук О.І., канд. техн. наук, доц.
Відповідальний за випуск: Дудикевич В.Б., проф., д.т.н, зав.каф. ЗІ
Рецензент:
Пархуць Л.Т., проф., д.т.н, проф. каф. ЗІ
Метою роботи є вивчення механізмів і принципів проектування реляційних баз даних на основі математичної теорії відношень, здобуття практичних навиків їх проектування та вивчення основних понять та визначень з теорії реляційних баз даних.
1. Теоретична частина
1.1. Базові концепції
Базу даних можна визначити як уніфіковану сукупність даних, що спільно використовується усім персоналом підприємства, банку або навчального закладу. Задача БД полягає у зберіганні всіх даних, які становлять інтерес для деякого підприємства в одному місці, причому у такий спосіб, який явно виключає їх надлишковість. Зберігання численних копій даних в різних місцях підприємства загрожує виникненням розузгоджень між імовірно ідентичними наборами даних. В добре спроектованій БД надлишковість даних виключається, і вірогідність збереження суперечливих даних мінімізується.
База даних (БД) — це сукупність взаємопов'язаних (звичайно складнострук-турованих) даних, яку можна спільно використовувати та керування якою здійснюється централізовано.
Основними властивостями БД:
допущення для даних такої мінімальної надлишковості, яка сприяє їхньому оптимальному використанню в кількох програмних застосуваннях;
незалежність даних від програм;
наявність засобів для підтримки цілісності бази даних та захисту від неавторизованого доступу.
На даний час для баз структурованих даних розрізняють три основних типи логічних моделей даних залежно від характеру підтримуваних ними зв'язків між елементами даних - мережну, ієрархічну й реляційну. Ознаками класифікації у цих моделях є: ступінь твердості (фіксації) зв'язку, математичне подання структури моделі й припустимих типів даних
Уникнути складності ієрархічної та мережної моделей вдалося в реляційній моделі даних, що у певному розумінні була поверненням до файлових структур.
Теоретичні основи реляційної моделі баз даних були закладені Е. Коддом на початку 70-х років XX століття. На відміну від поширених на той час систем з ієрархічними чи мережними типами структур даних, реляційний підхід запропонував спрощені структури даних — реляції, або таблиці, та розширив можливості мови маніпулювання даними. У науковій літературі, присвяченій реляційним базам даних, на означення того, що було названо вище реляцією або таблицею, часто застосовується термін відношення. Рядки _відношення називаються кортежами.
1.2. Визначення відношення
Математично відношення означається наступним чином:
Нехай дано "N" множин Dl, D2 ...,DN, тоді R є відношення над цими множинами, якщо R є множина впорядкованих n-кортежей виду <d1, d2, ..., dn>, де d1 - елемент з D1, d2 - елемент з D2... і dn - елемент з DN. Dl, D2 ..., DN називаються доменами відношення R.
Рис. 1. Відношення з математичної точки зору.
Значення даного визначення найбільш просто пояснити графічно (Рис. 1). Тут показано 4 домени. Домен D1 це множина цілих чисел; D2 символьних рядків, що є назвами предметів; D3 - символьних рядків, що є назвами кольорів; D4 ще одна множина цілих чисел. Відношення R складається з 6-ти кортежів. Кожен кортеж з 4 елементів, які вибираються кожен з свого домена. Важливим є порядок елементів в кортежі: перший елемент кожного кортежу вибраний з домена D1, другий елемент - з домена D2 і т.д.
Погляд на відношення з погляду обробки даних характеризує Рис. 2. Чотири домени, представлені на Рис. 1, співвідносяться з чотирма елементами реального світу: номером деталі, її назвою, кольором і вагою. Відношення приймає вигляд таблиці або файлу, де кортежі рядки таблиці або записи у файлі.
Рис. 2. Відношення з погляду обробки даних
Імена стовпців (з погляду обробки даних поля в записі) називаються атрибутами, а індивідуальні значення, що з'являються в окремих кортежах значеннями атрибутів. Таким чином, перший елемент першого кортежу має значення атрибута, рівне 101 і узяте з домена Дном.
Наступні набори термінів використовуватимуться по черзі:
1) відношення, таблиця і файл;
2) кортеж, рядок і запис;
3) атрибут, стовпець і поле;
аналогічно як і в більшій частині документації по БД.
Варто зауважити з приводу відмінності між математичним визначенням відношення і дійсним зберіганням відношень в мікрокомп'ютерних системах БД. За визначенням відношення не може мати двох ідентичних кортежів. Не дивлячись на те, що більшість великих СУБД не допускає зберігання ідентичних кортежів (записів) у відношенні (файлі), багато мікрокомп'ютерних СУБД це допускають (якщо не використовується спеціальна техніка програмування, що запобігає виникненню вказаної ситуації).
Слід згадати два додаткові терміни, що стосуються відношень. Число стовпців у відношенні називають ступенем. Поточне число кортежів у відношенні називається потужністю. Ступінь відношення звичайно не змінюється після створення відношення, але потужність коливатиметься у міру додавання нових і видалення старих кортежів.
1.3. Визначення реляційної БД
Реляційна БД є не що інше, як сукупність відношень, що містять всю інформацію, яка повинна зберігатися в БД. На Рис. 3 наведено приклад дуже маленької БД, названої Постачальник-Деталі.
Ця база містить три типи інформації про будівельну компанію:
1. Інформація про постачальників, що поставляють деталі підприємству. Сюди відносяться номер постачальника (передбачається унікальним), а також його прізвище, статус і місце проживання (не є унікальними). Ця інформація міститься у відношенні ПОСТАЧАЛЬНИК.
Деталь
Дном
Дназв
Колір
Вага
101
болт
чорний
3
102
муфта
синій
9
103
гвинт
червоний
11
104
гайка
зелений
4
105
муфта
червоний
13
106
болт
оранжевий
21
Постачальник
Пном
Пфам
Статус
Місто
П1
Сміт
20
Лондон
П2
Джонс
15
Детройт
ПЗ
Еддер
10
Чікаго
П4
Хаус
30
Париж
П5
Блейк
20
Париж
ПД
Пном
Дном
шт
П1
101
9
П1
102
4
П1
103
2
П1
106
3
П2
101
3
П2
102
8
П2
105
11
П2
106
9
ПЗ
101
7
ПЗ
102
13
ПЗ
103
6
ПЗ
104
1
ПЗ
105
2
ПЗ
106
5
П4
103
7
П4
106
13
П5
103
8
П5
104
9
Рис. 3. База даних Постачальник-Деталі.
2. Інформація про деталі, що використовуються на підприємстві. Сюди відносяться номер деталі, що є унікальним, назва, колір і вага, що не є унікальними. Ця інформація міститься у відношенні ДЕТАЛЬ.
3. Інформація про номери і кількість деталей від кожного постачальника. Ця інформація міститься у відношенні ПД.
Кожне відношення в БД зберігається в окремому файлі. Структура файлу, що використовується для зберігання відношення, досить проста, оскільки всі записи мають однаковий формат. У великих СУБД кожне відношення зберігається у вигляді індексованого файлу, де індекс є атрибутом або набором атрибутів, специфікованим при конструюванні відношення.
Набір атрибутів, що використовується як індекс, називається первинним ключем відношення. Первинний ключ визначається як такий атрибут, або набір атрибутів, який може бути використаний для однозначної ідентифікації конкретного кортежу. Первинний ключ не повинен мати додаткових атрибутів. Це значить, що якщо одиничний довільний атрибут виключити з первинного ключа, атрибутів, що залишилися, буде недостатньо для однозначної ідентифікації окремих кортежів. В БД Постачальник-Деталі первинними ключами є <Пном> для відношення ПОСТАЧАЛЬНИК, <Дном> для відношення ДЕТАЛЬ і пара атрибутів <Пном, Дном> для ПД.
Можна переконатися, що кожний первинний ключ є достатнім для однозначної ідентифікації кожного кортежу у відношенні. Наприклад, відносно ПД, якщо Пном - П1 і Дном - 101, можна знайти не більше одного кортежу з вказаними значеннями атрибутів. На Рис. 3 дані значення містить кортеж <П1, 101, 9>. Спроба зберегти інший кортеж з тим же первинним ключем, скажімо, <П1, 101, 11>, приводить до виникнення конфліктної ситуації, оскільки стає незрозумілим скільки деталей з номером 101 поставляє П1 - 9 або 11. В повністю розробленій СУБД при спробі користувача записати кортеж, що має первинний ключ, співпадаючий з первинним ключем іншого кортежу, вже включеного у відношення, генерується повідомлення про помилку. В багатьох реалізаціях СУБД, призначених для мікрокомп'ютерів, кортежі із співпадаючими первинними ключами і навіть повністю ідентичні кортежі можна занести у відношення, і це не приводить до виникнення помилки СУБД. У зв'язку з цим можуть виникнути деякі проблеми.
Число відношень в БД і конкретні атрибути, приписувані кожному відношенню, визначаються в процесі проектування, який може бути досить тривалим. Проте після завершення етапу проектування створення БД засобами СУБД можна виконати досить швидко. У разі БД Постачальник—Деталі структура її повністю специфікується коротким набором тверджень, приведеним на Рис. 4. Цей стислий опис називається концептуальною моделлю БД і містить всю інформацію, необхідну для створення повної структури БД незалежно від того, яка конкретно СУБД буде використана. Кожне з відношень в БД Постачальник-Деталі створюватиметься аналогічним чином. Варто зауважити, що вся інформація, необхідна для створення ПОСТАЧАЛЬНИК, міститься в концептуальній моделі.
Побудоване відношення є незаповненим, і його необхідно завантажити покортежно за допомогою відповідних команд запису.
Лістинг вмісту відношення або всіх відношень в БД, подібний до наведеного на Рис. 3 для БД Постачальник-Деталі, слід розглядати як “фотографію” стану відношень в деякий момент часу. Слід пам'ятати, що вміст всіх відношень динамічно змінюється, оскільки кортежі можуть бути додані, видалені або модифіковані протягом життєвого циклу відношень. Окремий лістинг деякого відношення в певний момент часу називається екземпляром цього відношення.
Назва БД: Постачальник_Деталі
Атрибути і тип:
Пном симв(3),
Пфам симв(6),
статус цілий,
місто симв(10),
Дном цілий,
Дназ симв(6),
колір симв(6),
вага цілий,
шт цілий.
Відношення і <Первинні ключі>:
Постачальник(Пном, Пфам, статус, місто)
<Пном>,
ПД(Пном, Дном, шт)
<Пном, Дном>,
Деталь(Дном, Дназв, колір, вага)
<Дном>.
Рис. 4. Концептуальна модель БД Постачальник-Деталі.
Первинний ключ, визначений для відношення, настільки важливий, що атрибути або набір атрибутів, що формують первинний ключ, як правило певним чином позначаються при математичній формі запису відношень. В даному випадку атрибути, що формують первинний ключ, підкреслюються. Наприклад, визначене на Рис. 4 відношення ПД буде записане, у вигляді ПД(Пном, Дном, шт). Це означає, що пара атрибутів <Пном, Дном> є первинним ключем для даного відношення.
1.4. Цілі проектування
Серед множини цілей, що стоять перед проектуванням, наступні видаються найважливішими:
1. Можливість зберігання всіх необхідних даних в БД.
2. Виключення надмірності даних.
3. Зведення числа збережених в БД відношень до мінімуму.
4. Нормалізація відношень для спрощення рішення проблем, пов'язаних з оновленням і видаленням даних.
Мета 1: Можливість зберігання всіх необхідних даних в БД. Ця мета здається очевидною, проте вона дуже важлива. Передбачається, що БД повинна містити всі дані, що представляють інтерес для підприємства, так що при проектуванні слід передбачити можливість розміщення в БД всіх необхідних даних. Першим кроком в процесі проектування є визначення всіх атрибутів, які згодом будуть поміщені в БД. Після визначення атрибутів проектувальник обдумує, скільки відношень необхідно і які атрибути включати у які відношення.
Мета 2: Виключення надлишковості даних. Сутність цієї мети зовсім не очевидна для проектувальника БД. Ключ до її розуміння полягає у з'ясуванні чіткої відмінності між дублюванням даних і надмірним дублюванням даних. Наприклад, звернемося до відношення С-Н, приведеного на Рис. 5(а). Відношення має два атрибути - Слжб# (табельний номер службовця) і Начк (начальник). У відношенні містяться дані, які вказують на безпосереднього начальника кожного службовця підприємства. Прізвища начальників можуть неодноразово з'являтися у відношенні. Насправді прізвище начальника з'являється один раз для кожного підлеглого йому службовця. Зверніть увагу, на те, що хоча "Мельник" і "Гірняк" з'являються двічі в екземплярі С-Н, наведеному в на Рис. 5(а), жодне з дубльованих прізвищ не є надмірним. Причина відсутності надмірності полягає в тому, що при видаленні одного з прізвищ з відношення буде загублена інформація. Наприклад, на Рис. 5(б) показано вигляд екземпляра відношення С-Н при видаленні дубльованих прізвищ. В цьому випадку немає можливості довідатися про прізвища начальників службовців з номерами #195 і #200.
На Рис. 6 (а) наведено приклад відношення з надмірним дублюванням даних. Відношення С-Н-Т схоже на відношення С-Н, але включає додатковий атрибут Нтел, що є номером телефону начальника. Передбачається, що кожний начальник має тільки один телефонний номер. В цьому екземплярі відношення номера телефонів Мельника і Гірняка з'являться більш ніж один раз і дубльована інформація про телефонні номери є надмірною. Причина надмірності в тому, що якщо, скажімо, видалити один з номерів Мельника, ця інформація може бути отримана з інших кортежів відношення. На Рис. 6(б) наведено приклад того, як виглядатиме відношення С-Н-Т у разі заміщення дубльованих телефонних номерів "нулями".
С-Н С-Н
Слжб#
Начк
Слжб#
Начк
125
Мельник
125
Мельник
138
Гірняк
138
Гірняк
195
Гірняк
195
200
Мельник
200
а) б)
Рис. 5. Дубльовані дані, що не є надмірними
Зрозуміло, що телефонні номери Мельника і Гірняка не загублені, оскільки кожний з них виявляється в одному з кортежів відношення.
С-Н-Т С-Н-Т
Слжб#
Начк
Нтел
Cлжб#-
Начк
Нтел
125
Мельник
3051
125
Мельник
3051
138
Гірняк
2222
138
Гірняк
2222
195
Гірняк
2222
195
Гірняк
200
Мельник
3051
(а) (б)
200
Мельник
С-Н
Слжб#
Начк
125
Мельник
138
Гірняк
195
Гірняк
200
Мельник
Н-Т
Начк
Нтел
Мельник
3051
Гірняк
2222
(в)
Рис. 6. Виключення надлишкових даних.
Даний метод управління надмірністю незадовільний з двох причин. По-перше, порожніх полів в БД слід уникати, оскільки необхідні додаткові зусилля при програмуванні, направлені на визначення реальних значень "нулів". В даному випадку читання третього кортежу <195,Гірняк,-> відношення не дозволяє встановити телефонний номер Гірняка. Користувач повинен уміти знаходити у відношенні інший кортеж, для якого значенням атрибута Начк є Гірняк, а значення атрибута Нтел не є нульовим. По-друге, що більш важливо, відношення, представлене на Рис. 6(б), має структуру, що загрожує виникненням серйозних проблем при видаленні інформації. Якщо службовець з номером Слжб# = 125 звільняється з підприємства і кортеж <125, Мельник, 3051> буде видалений з відношення при належній реєстрації факту звільнення, відбудеться втрата телефонного номера Мельника, оскільки ніде більше у відношенні він не представлений.
Рис. 6(в) показує кращий спосіб виключення надмірності телефонних номерів. Тут відношення С-Н-Т замінюється двома відношеннями, одне з яких містить інформацію про табельні номери службовців і прізвища керівників, а інше - інформацію про телефонні номери начальників. В наступному розділі буде показано, що розбиття відношень є стандартною процедурою проектування, яка повинна здійснюватися при дотриманні певних обмежень. Як випливає з Рис. 6(в), службовець з номером #125 тепер може бути видалений з відношення С-Н без втрати номера телефону колишнього начальника цього службовця, що зберігається у відношенні Н-Т.
Мета 3: Зведення числа відношень, які зберігаються в БД до мінімуму. Ця мета обумовлена тим, що розбиття одного відношення на два або більше менших відношень бажане з погляду виключення певних проблем, але це незручно для користувача. Таким чином, не можна допускати необмежене зростання числа відношень.
Мета 4: Нормалізація відношень. Для деяких відношень дуже важлива проблема видалення і оновлення (наприклад, втрата телефонного номера керівника, що обговорювалася вище в 2-й меті). Проектувальник повинен уміти знаходити ці потенційно небезпечні відношення і "нормалізувати їх" за допомогою розбиття належним чином. Нормалізація є розбиттям одного відношення на два або більше відповідно до спеціальної процедури визначення розбиття.
Мета 3 та мета 4 суперечать одна одній, тому тут потрібен взаємний компроміс.
1.5. Універсальне відношення
Припустімо, необхідно розробити невелику БД для консультанта університету. У консультанта є багато консультованих ним студентів, які живуть на території університетського містечка, причому всі ці студенти вчаться на основному факультеті.
Перший крок процесу проектування полягає у визначенні як всіх атрибутів, необхідних консультанту, так і зв'язків між атрибутами. Ця інформація виходить від консультанта у результаті ряду детальних обговорень, що не залишають сумнівів в тому, що він знає які дані повинні бути в БД, яким чином БД використовуватиметься і яку інформацію консультант планує одержувати від БД. Після декількох бесід з консультантом імена і умови, пов'язані з атрибутами, зберігання яких передбачається, були визначені таким чином:
Сном: Номер студента. Ціле значення, унікальне для кожного студента університету.
Спрізв: Прізвище студента. Кожний студент має тільки одне прізвище, але можливо, що одне прізвище носять декілька студентів.
Кном: Номер кімнати в гуртожитку містечка. Кожний студент живе на території містечка і має кімнату. В одній кімнаті може проживати більше одного студента.
Тном: Номер телефона студента. Кожна кімната гуртожитку має один телефон і ним користуються всі студенти, що проживають у цій кімнаті.
Курс: Номер курсу. Це ідентифікаційний номер курсу, відвідуваного студентом. Прикладом може служити номер МТН122. Консультант зберігатиме дані тільки про курси, завершені студентом.
Семестр: Університетський семестр. Є семестром, в якому даний курс був завершений студентом. Можливо, що студент вивчав один і той же курс в різних семестрах.
Оцінка: Оцінка за курс. Оцінка, отримана студентом за певний курс в даному семестрі.
На Рис. 7 представлено зразок даних, концептуалізованих консультантом для їх зберігання в БД. Хоча на малюнку наводиться приклад у вигляді таблиці даних, які можуть зберігатися в БД в деякий момент часу, вказана таблиця не є відношенням.
КОНСУЛЬТАНТ
Сном
Спрізв
Кном
Тном
Курс
Семестр
Оцінка
3215
Дзера Г.
120№5
2136
МАТ122
О84
1.6
ФІЛ120
О84
2.4
ФІЗ230
З85
2.1
МАТ122
З85
2.3
3462
Сушко А.
238№11
2344
МАТ122
З84
2.3
МАТ123
З85
3.5
БДЗ220
З85
3.7
3567
Хомин Д.
120№5
2136
ФІЛ239
З84
3.3
ЗІ171
О84
3.5
ФІЗ141
О84
1.8
4756
Антонюк В.
345№11
3321
КРП389
О83
4.0
Рис. 7. Дані, необхідні консультанту.
3215
Дзера Г.
120№5
2136
МАТ122
О84
1.6
ФІЛ120
О84
2.4
ФІЗ230
В85
2.1
МАТ122
З85
2.3
Рис. 8. Один "рядок" таблиці, наведеної на Рис. 7.
Для ілюстрації того, чому таблиця на Рис. 7 не є відношенням, виділимо один "рядок" з таблиці (Рис. 8). На цьому малюнку значення чотирьох полів Сном, Спрізв, Кном і Тном атомарні, тоді як значення в полях Курс, Семестр і Оцінка множинні. Даний "рядок" очевидним чином відрізняється формою від кортежів, представлених в простих відношеннях і розглянутих вище. Відмінність в тому, що не всі поля рядка містять атрибути, значення яких є атомарними. Для представлення даних, наведених на Рис. 7, у формі відношення необхідно реконструювати їх так, щоб кожний елемент кортежу мав атомарне значення.
КОНСУЛЬТАНТ
Сном
Спрізв
Кном
Тном
Курс
Семестр
Оцінка
3215
Дзера Г.
120№5
2136
МАТ122
О84
1.6
3215
Дзера Г.
120№5
2136
ФІЛ120
О84
2.4
3215
Дзера Г.
120№5
2136
ФІЗ230
З85
2.1
3215
Дзера Г.
120№5
2136
МАТ122
З85
2.3
3462
Сушко А.
238№11
2344
МАТ122
З84
2.3
3462
Сушко А.
238№11
2344
МАТ123
В85
3.5
3462
Сушко А.
238№11
2344
БДЗ220
В85
3.7
3567
Хомин Д.
120№5
2136
ФІЛ239
В84
3.3
3567
Хомин Д.
120№5
2136
ЗІ171
О84
3.5
3567
Хомин Д.
120№5
2136
ФІЗ141
О84
1.8
4756
Антонюк В.
345№11
3321
КРП389
О83
4.0
Рис. 9. Дані з таблиці, наведеної на Рис. 7, поміщені в коректне відношення
Звичайно це вдається зробити за допомогою простого процесу вставки (результат для даного випадку показаний на Рис. 9). В результаті цього процесу додається великий об'єм надлишкових даних – усунення надлишковості досягається на наступних етапах проектування.
Таблиця на Рис. 9 є екземпляром коректного відношення. Його називають універсальним відношенням проектованої БД. В одне універсальне відношення включаються всі атрибути, що становлять інтерес, і воно може містити всі дані, які передбачається розміщувати в БД в майбутньому. Для малих БД (що містять не більше 15 атрибутів) універсальне відношення може використовуватися як відправний пункт при їх проектуванні.
1.6. Проблеми, що виникають при використанні єдиного відношення
Проектувальник-початківець, намагатиметься застосовувати відношення КОНСУЛЬТАНТ (Рис. 9) як завершену БД. Це виглядає достатньо послідовним. Навіщо розбивати відношення КОНСУЛЬТАНТ на декілька більш дрібних відношень, якщо воно здатне містити в собі усі дані? Існує декілька причин, чому не слід використовувати дане відношення як єдине в БД. Це обумовлено тим, як використовуватиметься БД, і яку дію на дані у відношенні КОНСУЛЬТАНТ матимуть певні операції. Розрізняються три специфічні проблеми:
проблема, пов'язана з оновленням (модифікацією) даних в БД;
проблема, обумовлена необхідністю видалення кортежів;
проблема, обумовлена необхідністю включення нових кортежів.
Виділені проблеми звичайно називають аномаліями вставки, видалення і оновлення, маючи на увазі під аномалією відхилення від норми.
Проблема вставки
Якщо у консультанта з'являється новий консультований ним студент, що ще не закінчив курс, для нього необхідно включити в БД кортеж з нульовими (порожніми) значеннями атрибутів Курс, Семестр і Оцінка. Як вже не раз наголошувалося, нульових значень слід уникати. Отже, включення в БД нового студента неможливе аж до завершення ним курсу.
На Рис. 10 показано приклад того, як виглядатиме відношення КОНСУЛЬТАНТ у разі примусового включення в нього інформації про студента, що не завершив жодного курсу. Порожні символьні рядки представляються пробільними полями (Курс і Семестр), тоді як нульове чисельне значення в полі Оцінка інтерпретується СУБД як 0.0.
консультант
00001
3215
Дзера Г.
120№5
2136
МАТ122
О84
1.6
00002
3215
Дзера Г.
120№5
2136
ФІЛ120
О84
2.4
00003
3215
Дзера Г.
120№5
2136
ФІЗ230
З65
2.1
00004
3215
Дзера Г.
120№5
2136
МАТ122
З85
2.3
00005
3462
Сушко А.
238№11
2344
МАТ122
З84
2.3
00006
3462
Сушко А.
238№11
2344
МАТ123
З85
3.5
00007
3462
Сушко А.
238№11
2344
БДЗ220
З85
3.7
00008
3567
Хомин Д.
120№5
2136
ФІЛ239
В84
3.3
00009
3567
Хомин Д.
120№5
2136
ЗІ171
О84
3.5
00010
3567
Хомин Д.
120№5
2136
ФІЗ141
О84
1.8
00011
4756
Антонюк В.
345№11
3321
КРП389
О83
4.0
00012
7890
Хміль М.
121№11
7619
0.0
Рис. 10. Результат вставки запису з порожніми полями.
Проблема оновлення
У відношенні КОНСУЛЬТАНТ велике число надлишкових даних. Надлишковість даних завжди свідчить про можливість модифікації тільки частини необхідних даних за допомогою операції оновлення.
Відношення КОНСУЛЬТАНТ характеризується як явною, так і неявною надлишковістю. Явна надлишковість полягає в тому, що прізвище даного студента, номер кімнати і номер телефону можуть з'явитися у відношенні кілька разів. В екземплярі відношення КОНСУЛЬТАНТ, наведеному на Рис. 9, номер кімнати Г. Дзери вказується чотири рази. Якщо вона звернеться до свого консультанта і повідомить його про зміну номера її кімнати, то консультант буде вимушений прослідкувати за зміну цього номера у всіх чотирьох кортежах щоб уникнути суперечності даних.
Неявна надлишковість проявляється у тому, що один і той же номер телефону мають всі студенти, які живуть в одній кімнаті. На Рис. 9 телефонний номер для кімнати 120№5 з'являється у поєднанні з іменами Дзера Г. і Хомин Д. Припустимо, Г. Дзера сповістить свого консультанта про те, що її номер телефону змінений на 7777, забувши при цьому повідомити про подругу по кімнаті. Якщо консультант змінить телефонний номер тільки в тих кортежах, які містять номер телефону Г. Дзери, то правильний номер телефону, розташованого в кімнаті 120№5, буде фактично загублений, оскільки у відношенні будуть присутні два різні телефонні номери для однієї кімнати.
Проблеми видалення
В екземплярі відношення КОНСУЛЬТАНТ (Рис. 9) присутній тільки один кортеж, в якому Сном = 4756. Цей кортеж відповідає студенту з ім'ям Антонюк В. Припустимо, що консультант дізнається, що цей студент не закінчив курс КРП389, як це відзначено, і видаляє цей кортеж з відношення. Оскільки це єдиний кортеж з інформацією про цього студента, його видалення приведе до вилучення студента з БД. Якщо консультант слідом за даною операцією видалення зробить запит списку імен усіх консультованих, що містяться у відношенні КОНСУЛЬТАНТ, то імені Антонюк В. у цьому списку він не знайде.
1.7. Перша нормальна форма (1НФ)
Складовою частиною проектування реляційної БД є процес розбиття відношень з незадовільними властивостями (з погляду аномалій) на нові відношення. Для БД з числом атрибутів меншим 20 початковою точкою вказаної процедури може слугувати універсальне відношення. Це відношення містить всі атрибути, що становлять інтерес, і має структуру, в якій кожний кортеж складається з атомарних елементів. Це означає, що всі екземпляри відношень повинні мати форму, показану на Рис. 9, а не подібну тієї, яка приведена на Рис. 7. Говорять, що відношення знаходиться в першій нормальній формі (або 1НФ), якщо кожний його елемент має і завжди матиме атомарне значення. Відношення повинне бути в 1НФ навіть до постановки питання про його розбиття на два або більше відношень.
1.8. Концепція функціональної залежності
Процес розбиття відношення з метою зменшення вірогідності виникнення аномалій називається декомпозицією. Ключовим для здійснення декомпозиції логічним методичним шляхом є концепція функціональної залежності між атрибутами в даному відношенні.
Функціональна залежність (ФЗ) визначається таким чином:
Якщо дано два атрибути А і В, то говорять, що В функціонально залежить від А, якщо для кожного значення А існує рівно одне пов'язане з ним значення В (у будь-який момент часу). А і В можуть бути сладними, тобто вони можуть бути не одиничними атрибутами, а групи, що складаються з двох і більше атрибутів.
З практичної точки зору значення даного визначення полягає у тому, що якщо В функціонально залежить від А, то кожний з кортежів, що мають одне і те ж значення А повинен мати також одне і те ж значення В. Значення А і В можуть змінюватися час від часу, але при цьому вони повинні змінюватися так, щоб кожне унікальне значення А мало тільки одне значення В, пов'язане з ним. ФЗ описуються за допомогою декількох різних способів нотації. Два найбільш часто що використовуються способу показані на Рис. 11.
А -> В (Математична форма запису)
(Діаграма або графічна форма запису)
Рис. 11. Два можливі способи запису того, що атрибут В функціонально залежить від атрибута А
В конкретній ситуації ФЗ визначається шляхом деталізації властивостей всіх атрибутів у відношенні і висновку про те, як атрибути співвідносяться між собою. ФЗ не можуть бути доведені шляхом простого перегляду окремого екземпляра відношення і знаходження двох атрибутів, що мають ті ж значення в більш ніж одному кортежі. Це може слугувати ключем до того, в якому напрямі слід вести пошук ФЗ, але не доказом. ФЗ необхідно отримати виходячи з базових властивостей самих атрибутів.
Як приклад, знову звернемося до атрибутів відношення КОНСУЛЬТАНТ (Рис. 9). Після вивчення описів атрибутів може бути виведені залежність, наведена на Рис. 12.
Міркування, що привели до цих ФЗ, в деталях обговорюються нижче:
1. Номери студентів є унікальними. Кожному студенту призначається номер Сном, причому всі номери різні. Таким чином, якщо ви знаєте Сном студента, ви знаєте, що з ним може бути зв'язано тільки одне прізвище Спрізв; Сном -> Спрізв, зворотне не є вірним. Спрізв -> Сном не є правильною ФЗ, оскільки декілька студентів можуть мати одне прізвище.
Сном -> Спрізв
Сном -> Кном
Кном -> Тном
Тном -> Кном
Сном -> Тном
Сном, Курс, Семестр -> Оцінка
Рис. 12. Різні способи подання ФЗ, що існують між атрибутами відношення КОНСУЛЬТАНТ
2. Кожний студент прикріплений до однієї кімнати гуртожитку, але в одній кімнаті може проживати більше ніж один студент. Таким чином, Сном -> Кном є вірним, а Кном -> Сном - ні.
3. Оскільки в кожній кімнаті тільки один телефон і кожний телефон, у свою чергу, має унікальний номер, одержуємо Кном -> Тном і Тном -> Кном. Дана ситуація звичайно позначається у вигляді Сном <-> Тном, і говорять, що Сном і Тном взаємозалежні.
4.
16.04.2017 10:04-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора