практична-2

Міністерство освіти і науки України

Вінницький національний технічний університет

Факультет інформаційних технологій та комп’ютерної інженерії

Кафедра захисту інформації

Звіт

з практичної роботи №2

«НОРМАЛІЗАЦІЯ ВІДНОШЕНЬ РЕЛЯЦІЙНОЇ БД»

Виконав студент гр. 1 БС – 16 б Салига Є. С. Лабораторну роботу захищено з оцінкою ____________________________ Перевірив доц. каф. ЗІ __________ Куперштейн Л. М. _________________ 2019 р.

Мета: вивчення нормальних форм відношень та отримання навичок приведення відношень відповідно до їх вимог.

Хід роботи:

1. Спростити розроблену в практичній роботі №1 ER-модель БД та перетворити у реляційну модель.

2. Провести процес нормалізації відношень БД

   1. Перевірити відповідність вимогам 1НФ відношень БД. У разі не відповідності запропонувати необхідні трансформації відношень.

   2. Перевірити відповідність вимогам 2НФ відношень БД. У разі не відповідності запропонувати необхідні трансформації відношень.

   3. Перевірити відповідність вимогам 3НФ відношень БД. У разі не відповідності запропонувати необхідні трансформації відношень.

   4. Перевірити відповідність вимогам БКНФ відношень БД. У разі не відповідності запропонувати необхідні трансформації відношень.

3. Описати потенційній запити користувача до проектованої БД та оцінити можливість їх виконання.

4. Виконати додаткове завдання.

   1. Описати функціональні і транзитивні залежності між атрибутами вихідного відношення (див. додаток 1)

   2. Виявити ключ вихідного відношення.

   3. Нормалізувати вихідне відношення методом нормальних форм.

   4. Побудувати схему даних БД методом декомпозиції без втрат.

5. Оформити звіт по роботі.

Виконання:

Логічна модель, що була побудована у практичній роботі №1, відповідає завданню про побудову логічної моделі «Аптека». Дана область широкою, адже видів ліків може буде дуже багато, так само як і тих хто їх купляв. Тому було складено лише деякі сутності та описано їх ключі, атрибути та зв’язки, щоб спростити модель.

Після того як дану модель було спрощено, потрібно перевести її у реляційну модель. Для цього використаємо середовище MS Access. Кожна сутність – це табличка, її атрибути – назви стовпчиків, а її екземпляри – значення стовпчиків. Зв’язки у даній моделі будуть представлені за допомогою діаграми, де також буде визначено ключові поля кожної із таблиць. Заповнивши екземплярами таблиці, потрібно проаналізувати їх нормальний вигляд, якщо ж він не відповідає вимогам, то привести дану модель до 1, 2, 3 та БК нормальних форм.

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

Перевіримо усі таблички на відповідність цих вимог.

Таблиця «Покупці» містить у собі код покупця, який є ключовим та унікальним полем, значення якого не може повторюватися. Стовпчик ПІБ має символьний тип, дата має тип DATETIME, код товару, вартість та код службовця – числовий тип. Тобто, значення п’яти вище описаних стовбців можуть повторюватись, але за рахунок унікальності поля код покупця, рядки повторюватись не будуть. Отже, дана табличка відповідає вимогам 1НФ.

Таблиця «Службовці» містить у собі код службовця, що є ключовим та унікальним значенням, тобто не повторюється. ПІБ має символьний тип, значення якого не повторюються, оскільки в аптеці не можуть працювати 2 різні особи з однаковим ПІБ. Посада має символьний тип, дата прийому на роботу – тип DATE; значення цих стовбців можуть повторюватись, але за рахунок унікальності першого стовбця, рядки повторюватись не будуть. Отже, дана табличка відповідає вимогам 1НФ.

Таблиця «Ліки» має чотири стовбця. Перший стовбець є ключовим та унікальним. Другий стовбець має символьний тип, значення якого не повторюються, оскільки в аптеці немає ліків з абсолютно однаковою назвою. Третій стовбець має тип DATE, четвертий – числовий тип; значення цих двох стовбців можуть повторюватись, але за рахунок унікальності першого стовбця, рядки повторюватись не будуть. Отже, дана табличка відповідає вимогам 1НФ.

Таблиця «Постачальники» має чотири стовбця. Перший є унікальним та ключовим, тобто не повторюються. Другий стовбець має символьний тип, значення якого не повторюються, оскільки від одної компанії не можуть бути 2 різних постачальника з однаковим ПІБ. Наступні два стовбці мають символьне тип, значення яких можуть повторюватись, але за рахунок того, що перший стовпчик є унікальним, рядки повторюватись не будуть. Отже, дана табличка відповідає вимогам 1НФ.

Таблиця «Склад» має три стовбці. Перший стовбець є ключовим та унікальним, тобто його значення повторюватись не можуть. Інші стовбці мають числові типи, значення яких можуть повторюватись, але за рахунок унікальності першого стовбця, рядки повторюватись не будуть. Отже, дана табличка відповідає вимогам 1НФ.

Таблиця «Замінники ліків» має два стовбця. Перший стовбець чисельний тип, значення якого не повторюються. Другий має символьний тип, значення якого можуть повторюватись, але за рахунок того, що значення першого повторюватись не можуть, повторень рядків не буде. Отже, дана табличка відповідає вимогам 1НФ.

2. Приведемо дану реляційну модель до 2 нормальної форми, тобто: таблиця має містити первинний ключ, всі атрибути повинні описувати весь первинний ключ а не деяку його частину, таблиця має перебувати у 1НФ.

Усі таблиці перебувають у першій нормальній формі, але не усі таблиці містять первинний ключ, а також не усі атрибути таблиць описують його повністю.

Для нормалізації даної моделі змінимо декілька таблиць.

Таблиця «Замінники ліків» – додамо унікальний стовбець код заміни, який буде являтись первинним ключем та мати тип INT.

Таблиця «Ліки» – додамо ще 1 стовбець, який був створений вище – код заміни, після чого, в сумі з іншими атрибутами, первинний ключ буде описуватись повністю.

Отже, перевіривши усі умови було відредаговано дану реляційну модель у відповідності до 2 НФ, тепер усі таблиці мають первинний ключ, вони знаходять у 1 НФ, а усі атрибути кожної таблиці описують весь первинний ключ, а не лише його частину.

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

Усі таблиці перебувають у 2 НФ, перевіримо чи їх атрибути залежать лише від первинного ключа.

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

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

Таблиця «Ліки» містить атрибути, що залежать лише від первинного ключа таблиці, а також такий атрибут, як код постачальника, що залежить від первинного ключа іншої таблиці.

Таблиця «Замінники ліків» містить атрибут, що залежать лише від первинного ключа таблиці, а також такі атрибути, як код товару та назва товару, що залежать від первинних ключів інших таблиць.

Таблиця «Склад» містить атрибут, що залежать лише від первинного ключа таблиці, а також такий атрибут, як код товару, що залежить від первинного ключа іншої таблиці.

Отже, перевіривши усі умови на відповідність даної реляційної моделі до 3 НФ, змін не відбулося, тобто усі таблиці перебувають у 2 НФ та усі неключові атрибути кожної з таблиць залежать лише від первинного ключа, а не від інших неключових атрибутів.

4. Приведемо дану реляційну модель до БК нормальної форми. Тобто посиленої третьої нормальної форми: між ключами – кандидатами немає функціональної залежності.

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

Спроектуємо дану реляційну модель у середовищі MS Access, та опишемо можливі запити до цієї БД.

Висновок: Виконавши дану практичну роботу було набуто навички побудови нормалізації моделі БД. Нормалізовано ER-модель для об’єкту Аптека. Побудовано реляційну модель на основі ER-моделі.