Перевірка відношень за допомогою правил нормалізації

Плвн

1. Перевірка відповідності відношень вимогам транзакцій користувачів

2. Перевірка підтримки цілісності приклад створення логічної моделі

бази даних

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

Приклад. В результаті проектування отримано відношення показана на рис. 6.24.

При дослідженні даного відношення були виявлені такі функціональні залежності:

Дисципліна, Викладач, Студент, Дата ^ Оцінка Студент ^ Група У наведеній схемі існують аномалії і необхідно продовжити нормалізацію. В результаті декомпозиції вихідного відношення буде отримана схема показана на рис. 6.25.

Перевірка відповідності відношень вимогам транзакцій користувачів

Перевірка полягає в нанесенні безпосередньо на ER- діаграму всіх шляхів, які потрібні для виконання кожної з транзакцій. Якщо таким чином вдається виконати всі транзакції, то перевірка на цьому завершується. У протилежному випадку необхідно повернутися до попередніх етапів і перевірити, а у разі потреби і змінити ті фрагменти моделі, які не відповідають необхідній роботі транзакцій.

Якщо в результаті перевірки будуть виявлені області, які не беруть безпосередньої участі у роботі транзакцій, то можливо їх вилучення з моделі.

Перевірка підтримки цілісності

Обмеження цілісності запобігають появі в БД суперечливих даних. Вирішення цієї проблеми на стадії проектування полягає у такому:

- наявність обов'язкових і необов'язкових значень даних для атрибутів (NULL, NOT NULL);

- наявність обмежень для доменів атрибутів (визначення області значень або діапазону значень);

- цілісність сутностей (обов'язкова наявність Primary Key в кожному відношенні);

- посилкова цілісність (зв'язування таблиць за допомогою Foreign Key);

- обмеження предметної області (бізнес правила), які реалізуються як засобами БД, так і на рівні застосувань.

У табл. 6.1 наведені правила зовнішнього ключа для відношення "один до багатьох" для сильної сутності.

Для слабкої сутності використовуються ті ж самі правила за винятком обмежень на зовнішній ключ: NOT NULL, ON DELETE CASCADE, ON UPDATE CASCADE.

Приклад створення логічної моделі бази даних

У прикладі (п.5.4) розроблено концептуальний проект бази даних для предметної області ВИЩИИ НАВЧАЛЬНИИ ЗАКЛАД (ВНЗ). ER-діаграма відображає всі бізнес правила, які в свою чергу визначають сутності, атрибути, зв'язки і т.д.

Наступним етапом проектування бази даних є створення логічної моделі бази даних на основі створеної ER-моделі (рис. 5.21). Створення логічної моделі бази даних виконується шляхом застосування правил перетворення (гл. 6.) ER-діаграми в логічну модель (рис. 6.26).

Після створення логічної моделі даних реляційна схема аналізується на коректність об'єднання атрибутів в одному відношенні. Перевірка коректності виконується шляхом застосування послідовної нормалізації до кожного з відношень. Метою цієї перевірки є отримання гарантій того, що схема бази даних щонайменше знаходиться в 3-й нормальній формі або в нормальній формі Бойса-Кодда. Якщо ця умова не виконується, то необхідно повернутися на попередні етапи проектування і перебудувати помилково створені фрагменти моделі. Перевірка логічної моделі бази даних ВНЗ показує, що реляційна схема знаходиться в 4-й нормальній формі й корегування моделі не потрібно.

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

Подальша перевірка моделі вимагає перевірки підтримки цілісності даних. На основі матеріалів прикладу можна тільки визначити, що підтримується посилкова цілісність. Всі інші перевірки, включаючи і перевірку транзакцій користувачів, вимагають більш детально опрацьованого проекту бази даних.

Правила перетворення ER-діаграми в логічну модель наведені в дод. 2.

Література

1. Гайдамакин Н.А. Автоматизированные информационные системы, базы и банки данных. Вводный курс. - М.: Гелиос АРВ, 2002. - 368 с.

2. Гайна Г.А. Організація баз даних і знань. Мови баз даних: Конспект лекцій.-К .:КНУБА, 2002. - 64 с.

3. Гайна Г.А., Попович Н.Л. Організація баз даних і знань. Організація реляційних баз даних: Конспект лекцій. - К.:КНУБА, 2000. - 76 с.

4. Гарсиа-Молина Г., Ульман Д., Уидом Д. Системы баз данных.-М.: Издательский дом "Вильямс", 2003. - 1088 с.

5. Григорьев Ю.А., Ревунков Г.И. Банки данных.-М.: Изд-во МГТУ им. Н.Э.Баумана, 2002. - 320 с.

6. Грофф Дж., Вайнберг П. Энциклопедия SQL. - СПб.: Питер, 2003. - 896 с.

7. Дейт К.Дж. Введение в системы баз данных. - К.: Диалектика, 1998. - 784 с.

8. Диго С.М. Проектирование и использование баз данных.-М.: Финансы и статистика, 1995. - 208 с.

9. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2001. - 304 с.

10. Когаловский М.Р. Энциклопедия технологий баз данных.- М.: Финансы и статистика, 2002. - 800 с.

11. Конноли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. - М.: Издательский дом "Вильямс", 2003. - 1440 с.

12. Кренке Д. Теория и практика построения баз данных. - СПб.: Питер, 2003. - 800 с.

13. Малыхина М.П. Базы данных: основы, проектирование, использование. - СПб.: БХВ-Петербург, 2004. - 512 с.

14. Роб П., Коронел К. Системы баз данных: проектирование, реализация и управление. - СПб.: БХВ-Петербург, 2004. - 1040 с.