Зацерковний В.І. та ін. ГІС та бази даних. І бази даних
 Скачать 31.1 Mb.
|
|
12.5. Правила Кодда Для визначення того, чи є база даних реляційною чи ні, Едгар Кодд розробив дванадцять правил. Якщо база даних задовольняє всі ці правила, то її з упевненістю можна назвати реляційною. Перше правило Кодда – дані в відношеннях повинні мати явне представлення. Це правило свідчить про те, що в реляційній базі даних повинен виконуватись принцип інформаційної неподільності. 405 Друге правило Кодда – до даних повинен бути забезпечений гаран- тований доступ. У цьому разі в будь-якій реляційній базі даних користувач, знаючи ім’я відношення, значення первинного ключа та ім’я атрибута, повинен отримати доступ до необхідних даних. Третє правило Кодда – в реляційній базі даних повинна бути реалі- зована обробка невизначених значень. Це положення говорить про те, що в реляційних базах даних для всіх типів даних повинна підтримуватись робота з невизначеними значеннями NULL. Четверте правило Кодда – опис бази даних повинен здійснюватись у термінах реляційної моделі. Це правило висуває додаткову вимогу до опису бази даних, яка повинна зберігатись у вигляді окремих зв’язаних між собою відношень, а доступ до його вмісту повинен здійснюватись за допомогою описаних вище реляційних операцій. П’яте правило Кодда – в реляційній базі даних повинна бути забезпе- чена повнота підмножини мови. При цьому мова маніпулювання даними і мова визначення даних повинні бути необхідними і достатніми засобами роботи з даними. Шосте правило Кодда – реляційна база даних повинна підтримувати оновлення представлень. У цьому разі створені за допомогою реляційних операцій представлення при зміні даних у вихідних відношеннях повинні також оновлюватися. Сьоме правило Кодда – в реляційній базі даних для маніпулювання даними повинна використовуватись високорівнева мова. Синтаксис операцій, що застосовуються до відношення в цілому або до кортежів зокрема, повинен бути зрозумілим будь-якому користувачеві. Восьме правило Кодда – в реляційній базі даних повинна бути забез- печена фізична незалежність даних. Виконання цього правила приводить базу даних у відповідність моделі ANSI/SPARC, в якій прикладні програми не повинні залежати від особливостей представлення даних на фізичному рівні. Дев’яте правило Кодда – в реляційній базі даних повинна бути реалізована логічна незалежність даних. Це правило свідчить про те, що додаток реляційних баз даних не повинен залежати від логічних обмежень, що накладаються на відношення. Десяте правило Кодда – в реляційній базі даних повинна бути забезпечена незалежність контролю цілісності. Дотримання цього правила призводить до необхідності зберігання засобів підтримки цілісності даних, таких як обмеження на первинні і зовнішні ключі, межі допустимого діапазону значень даних в окремих відносинах бази даних. Одинадцяте правило Кодда – реляційна база даних повинна мати дистрибутивну незалежність даних. У цьому разі до бази даних вису- вається вимога можливості перенесення на інші платформи і здатність до поширення, в тому числі в локальних та глобальних мережах. 406 Дванадцяте правило Кодда – реляційна база даних повинна забез- печувати узгодження мовних рівнів. Це правило Кодда головним чином спрямовано на узгодження виконання низькорівневих операцій, таких як резервне копіювання й архівація даних, та високорівневих операцій, на- приклад, вибірка даних, розділення прав користувачів і привілеїв доступу. Правила Кодда виступають переважно теоретичними вимогами, що висуваються до побудови реляційних баз даних. На практиці жодна база даних повною мірою не реалізує реляційну модель. Розробники баз даних керуються принципом розумної достатності, розробляючи систему, яка не суперечить необхідним вимогам реляційних баз даних і відповідає достатнім вимогам замовника. 12.6. Нормалізація реляційних баз даних Після статті, присвяченої реляційній алгебрі, Едгар Кодд у 1972 р. опублікував працю під назвою "Подальша нормалізація реляційної моделі баз даних", у якій ввів термін "нормалізація" і сформулював три нормальні форми. Нормалізація – це метод організації реляційної бази даних з метою скорочення надлишковості. При розробці і проектуванні будь-якої реляційної бази даних однією з перших розв’язується задача нормалізації її відношень, причому цей процес є ітераційним і полягає в послідовному переведенні відношень з першої нормальної форми в нормальні форми більш високого ступеня за певними правилами. Кожна наступна нормальна форма обмежує функціональну залежність відношень при збереженні властивостей попередніх нормальних форм. Нормалізація дозволяє повною мірою реалізувати переваги реляцій- ної моделі, змушує розробника створювати більшу кількість відношень, рівномірніше розподіляючи в них інформацію, що приводить до знижен- ня надлишковості і підвищення цілісності даних. Усього виділяють п’ять нормальних форм. 12.6.1. Перша нормальна форма Перше правило реляційної моделі полягає в тому, що жоден стовпчик не повинен містити два або більше значень. Відношення представлено в першій нормальній формі (1НФ) тоді і тільки тоді, коли всі його атрибути є простими, тобто містять тільки неподільні порції даних. 407 Наведемо приклад перетворення відношення на першу нормальну форму, використовуючи таблицю, в якій зберігаються дані про персо- нальні комп’ютери (рис. 12.11). Рис. 12.11. Перетворення відношення на першу нормальну форму Як видно з рис. 12.11 усі дані про комп’ютери, що містяться у вихідному відношенні, розбиті на чотири прості атрибути, які містять неподільні порції даних. Приведення відношень до першої нормальної форми спрощує роз- робку запитів і створення представлень, однак не виключає дублювання даних, що призводить до втрати цілісності і збільшення об’єму займаної пам’яті. Для вирішення цих проблем необхідно використовувати другу нормальну форму. 12.6.2. Друга нормальна форма Для проведення подальшої нормалізації відношень необхідно вико- ристовувати поняття первинного ключа, оскільки друга нормальна форма вимагає, щоб усі атрибути залежали від первинного ключа. Відношення представлено в другій нормальній формі (2НФ) тоді і тільки тоді, коли воно представлено в першій нормальній формі і кожний неключовий атрибут повністю визначається первинним ключем (рис. 12.12). Рис. 12.12. Перетворення відношення на другу нормальну форму model 1234 1456 1333 1782 1121 price speed quanti ty 10 5 3 8 18 total 6000 4250 2100 3600 6700 2НФ price 600 850 700 450 670 speed 500 750 500 600 600 quanti ty 10 5 3 8 18 total ty 6000 4250 2100 3600 6700 600 850 700 450 670 500 750 500 600 600 information $600 500 10 $6000 $850 750 5 $4250 $700 500 3 $2100 $450 600 8 $3600 $670 600 10 $6700 price 600 850 700 450 670 speed 500 750 500 600 600 quantity 10 5 3 8 18 total 6000 4250 2100 3600 6700 1НФ 408 Надлишковість першої нормальної форми може слугувати причи- ною виникнення аномалій вставки і видалення. Аномалії вставки вини- кають тоді, коли дані неможливо додати в відношення доти, поки вони неповні, або для цього буде потрібний додатковий перегляд відношення. Наприклад, немає сенсу зберігати абстрактну інформацію про комп’ютери, якщо вона не відповідає певній моделі. Застосування другої нормальної форми дозволяє усунути аномалії вставки і видалення. 12.6.3. Третя нормальна форма Застосування першої і другої нормальних форм дозволяє позбутися явного дублювання даних, однак неявне дублювання даних все ж таки має місце. Вирішити цю проблему допомагає використання третьої нормальної форми (рис. 12.13). Відношення представлено в третій нормальній формі (3НФ) тоді і тільки тоді, коли воно представлено в другій нормальній формі і всі неключові атрибути відношення взаємно незалежні та цілко- вито залежать від первинного ключа. Якщо у відношенні є залежність атрибутів складного ключа від неключових атрибутів, то необхідно перейти до посиленої третьої нормальної форми, яка називається нормальна форма Бойса–Кодда. Рис. 12.13. Перетворення відношення на третю нормальну форму Відношення представлено в нормальній формі Бойса–Кодда (БКНФ) тоді і тільки тоді, коли воно знаходиться в третій нормальній формі і в ньому відсутні залежності атрибутів складеного ключа від неключових атрибутів. Приведення відношень у третю нормальну форму є достатньою умовою для розв’язку практичних задач і на цьому в більшості випадків процес проектування реляційної бази даних закінчується. model 1234 1456 1333 1782 1121 price speed quanti ty 10 5 3 8 18 3НФ price 600 850 700 450 670 speed 500 750 500 600 600 quanti ty 10 5 3 8 18 total 6000 4250 2100 3600 6700 600 850 700 450 670 500 750 500 600 600 model 1234 1456 1333 1782 1121 409 12.6.4. Четверта нормальна форма В деяких випадках у відношеннях з’являється багатозначна залеж- ність даних, яка полягає в залежності атрибутів складеного ключа. Вида- лення або додавання кортежем призводить до обробки всім кортежем відношення, що веде до надлишковості. Для виключення багатозначних залежностей необхідно використовувати четверту нормальну форму. Відношення представлено в четвертій нормальній формі (4НФ) тоді і тільки тоді, коли воно знаходиться в нормальній формі Бойса– Кодда й існує багатозначна залежність первинного ключа від іншого атрибута, а решта атрибутів функціонально залежать від первин- ного ключа. 12.6.5. П’ята нормальна форма Результатом нормалізації всіх попередніх операцій були два нові відношення. Іноді це виконати не вдається або отримувані відношення явно мають небажані властивості. В цьому разі виконують декомпозицію вихідного відношення на відношення, кількість яких перевищує два. Однак така декомпозиція не повинна приводити до втрати даних і появи додаткових фіктивних кортежів. Саме для цього і розроблена п’ята нормальна форма. Відношення знаходиться в п’ятій нормальній формі (5НФ) тоді і тільки тоді, коли воно представлено в четвертій нормальній формі і не містить залежностей з’єднання. Треба відзначити, що глибоке розуміння процесів, що відбуваються при перетворенні на четверту і п’яту нормальні форми, вимагає залучення математичного апарата теорії множин. В цілому ж потрібно відзначити, що четверта і п’ята нормальні форми становлять більше теоретичний інтерес, ніж практичний. 12.7. Денормалізація баз даних При проектуванні бази даних, яка задовольняє всі нормальні форми, з’являється надлишок відношень, оскільки перехід до чергової нормальної форми призводить до розділу відношень. При цьому усувається надлиш- ковість даних, однак з’являється надлишок внутрішніх зв’язків між відношеннями. Крім того, виникають додаткові витрати на виконання операцій об’єднання, що істотно впливає на продуктивність. 410 Усунення надлишковості не обов’язково означає підвищення про- дуктивності. Накладні витрати на виконання операцій об’єднання суттєві, тому розробники іноді свідомо йдуть на порушення правил нормалізації. Процес порушення нормальних форм називається денормалізацією. Денормалізація викликана декількома причинами, основними з яких є час виконання запитів, час проведення оновлень, загальний об’єм схо- вища даних, аномалії видалення, що викликають втрату цілісності даних. 12.8. Переваги та недоліки реляційного підходу у створенні баз даних Реляційний підхід є найбільш поширеним у даний час, хоча поряд із загальновизнаними перевагами має і багато недоліків. До переваг реляційного підходу можна віднести: – наявність невеликого набору абстракцій, які дозволяють порівня- но просто моделювати значну частину найбільш поширених предметних сфер і припускають точні формальні визначення, залишаючись при цьому інтуїтивно зрозумілими; – наявність простого й одночасно потужного математичного апарату, що спирається головним чином на теорію множин і математичну логіку та забезпечує теоретичний базис реляційного підходу до організації баз даних; – можливість ненавігаційного маніпулювання даними без необхід- ності знання конкретної фізичної організації баз даних у зовнішній пам’яті. В даний час основним предметом критики реляційних СКБД є не їхня недостатня ефективність, а властива їм деяка обмеженість (прямий наслідок простоти) при використанні в галузях, у яких вимагаються гранично складні структури даних (наприклад, САПР). Ще одним часто відмічуваним недоліком реляційних баз даних є неможливість адекватно- го відображення семантики предметної сфери. Інакше кажучи, можли- вості представлення знань про семантичну специфіку предметної сфери в реляційних системах дуже обмежені. Сучасні дослідження у сфері постреляційних систем головним чином присвячені саме усуненню цих недоліків. 411 ХІІІ. ПІДВИЩЕННЯ ЕФЕКТИВНОСТІ РОБОТИ БАЗ ДАНИХ 13.1. Паралельні обчислення Сьогодні паралельні обчислення є надзвичайно популярними, на- приклад як для інтернет-магазинів, так і для бухгалтерських багатокорис- тувацьких систем. Сутність роботи таких полягає в наступному. Певний вид товару надходить на склад підприємства, після чого він продається покупцеві, причому продаж не повинен відбутись раніше від надходжен- ня і один і той же товар не повинен бути проданим різним покупцям. Такий процес називається паралелізмом. Від успішності реалізації паралельних обчислень залежить ефективність роботи системи в цілому. Паралелізм є доволі складною проблемою для СКБД, які повинні справлятись не тільки з численними запитами на підключення, а й планувати одночасний доступ до даних. Для розв’язку таких задач використовуються транзакції. 13.1.1. Поняття транзакції Транзакцією називається послідовність операцій, що здійсню- ються над базою даних і які переводять базу даних з одного несупереч- ливого стану в інший несуперечливий стан. В кінці транзакції відбувається або її відміна, або завершення. Відміна транзакції називається відкатом, завершення транзакції називається фіксацією. Транзакція повинна мати властивості, які представлені на рис. 13.1. Рис. 13.1. Властивості транзакції Властивості транзакцій Атомарність Узгодженість Ізольованість Стійкість 412 Атомарність означає дотримання принципу неподільності транзак- цій. Даний принцип полягає в тому, що всі інструкції, що складають транзакцію, обов’язково виконуються, інакше не виконується жодна з них. Будь-яких проміжних станів не існує. Атрибут є атомарним, якщо його значення втрачає зміст при будь- якому розбитті на частини або перевпорядкуванні. І навпаки, якщо будь- який спосіб розбивки на частини не позбавляє атрибут сенсу, то атрибут є неатомарним. Одне й те ж значення може бути атомарним або неатомарним залежно від змісту цього значення. Узгодженість гарантує, що у міру виконання транзакції дані пере- ходять з одного узгодженого стану в інший, при цьому не порушується взаємна узгодженість даних у БД. Ізоляція полягає в організації послідовної обробки транзакцій при доступі до бази даних, при цьому в користувача виникає враження, що всі транзакції виконуються паралельно. Стійкість означає, що при успішному завершенні транзакції в БД вносяться постійні, невідмінювані зміни. БД, що підтримує виконання стійких транзакцій, здатна витримати раптову аварію, наприклад, збій живлення, і при цьому залишатися узгодженою. Транзакції реалізуються шляхом ведення журналу всіх змін, що вносяться в базу даних у ході виконання кожної транзакції. За журналом можна відновити узгоджений стан БД у випадку збою. Існує декілька видів збою, класифікацію яких наведено на рис. 13.2. Рис. 13.2. Класифікація видів збою баз даних Виділяють два види апаратних збоїв. М’які збої виникають при рап- товій зупинці роботи комп’ютера, наприклад, при аварійному вимкненні живлення. Жорсткі збої проявляють себе при виході комп’ютера з ладу і спричиняють втрату інформації на носіях зовнішньої пам’яті. Види збоїв Апаратні Програмні М’які збої Жорсткі збої Аварійне завершення роботи СКБД збої Аварійне завершення користувацької програми 413 Серед програмних видів збоїв треба відзначити аварійне завершен- ня роботи СКБД і аварійне завершення користувацької програми, в результаті чого певна транзакція залишається незавершеною і потрібно ліквідувати її наслідки. Підтримка надійності збереження даних є пріоритетним завданням роботи СКБД. Для цього в БД необхідно зберігати надлишкову інфор- мацію для відновлення, причому ця інформація повинна зберігатись дуже надійно. Найбільш поширеним методом підтримки такої надлишковості є ведення журналу змін БД. Журналом транзакцій називається механізм збереження про- міжних станів, підтвердження або відкату транзакції, що реалізу- ється в СКБД. У багатьох випадках дотримуються стратегії "упереджувального" запису в журнал транзакцій (так званого протоколу Write Ahead Log – WAL), який полягає в тому, що запис про зміну будь-якого об’єкта БД повинен потрапити до зовнішньої пам’яті журналу раніше, ніж змінений об’єкт потрапить до зовнішньої пам’яті основної частини БД. Треба відзначити, що використання транзакції при оптимізації БД знижує продуктивність роботи, однак підвищує цілісність БД. Відсут- ність транзакцій приводить до істотного зростання продуктивності, проте страждає цілісність. Компроміс полягає в тому, що існують проміжні варіанти, які називаються рівнями ізоляції транзакцій, що дозволяють знайти компроміс між цими двома суперечливими вимогами. |