бхідно, щоб автоматично перевірялося однозначна відповідність році видання, тобто кожній назві має відповідати одна і тільки один рік видання. Подібним чином підтримка відповідностей повинна бути реалізована для кожного заданого обмеження.
Крім цього, зберігання даних в одній таблиці при заданих обмеженнях є надмірною.
1.3 Неформальна постановка задачі
Проведений аналіз предметної області показав, що ведення даних в одній таблиці не відповідає деяким вимогам, що пред'являються до реляційних БД з причини, описаним в попередньому розділі.
Для вирішення завдання ефективної роботи БД обліку літератури необхідно представити її структуру у вигляді декількох таблиць, кожна, з якої містить окремий факт предметної області.
Наприклад, інформація про видачу літератури студенту (ПІБ, назва, дата видачі, дата повернення), про навчальній літературі, про предмет. При цьому БД повинна представляти собою цілісну систему, тобто користувач повинний мати можливість в будь-який момент часу отримати всю (яку) інформацію, яка зберігається в БД.
Таким чином, в курсовому проекті вирішуються такі завдання:
- проаналізувати методи проектування баз даних;
- з опису предметної області виділити безліч атрибутів, необхідних для зберігання даних;
- виділити безліч функціональних залежностей, що визначають однозначні зв'язки між атрибутами;
- серед заданої множини функціональних залежностей виділити неповні і транзитивні залежності;
- використовуючи метод нормалізації структури відносини, побудувати третю нормальна форма схеми БД;
- розробити і реалізувати статичні запити до БД у вигляді уявлень;
- реалізувати розширену підтримку цілісності, з використанням тригерів;
- реалізувати додаткові функції адміністрування БД (з використанням збережених процедур і функцій);
. ПРОЕКТУВАННЯ СТРУКТУРИ БАЗИ ДАНИХ
2.1 Визначення функціональних залежностей
На підставі розглянутих вимог до БД (розділ 1.2) і поставленого завдання (розділ 1.3) формалізуємо обмеження на дані у вигляді функціональних залежностей.
1. Назва ® тема, тип, автор, рік видання
2. Назва ® предмет, кафедра
. Предмет ® викладач
. ПІБ студента, назва ® дата видачі, дата повернення
2.2 Розробка структури бази даних
база дані запит тригер
Для виключення можливих аномалій описаних в розділі 1.2 необхідно нормалізувати БД, тобто привести її до нормальної форми. Задані обмеження у вигляді функціональних залежностей (розділ 2.1.) Дозволяють побудувати третю нормальну форму (3НФ), яка усуне небажані властивості ведення БД.
Очевидно, що представлений набір атрибутів (малюнок 1) відповідає першій нормальній формі (1НФ). Скористаємося визначенням неповної функціональної залежності [1,2] і побудуємо другу нормальну форму (2НФ).
Алгоритм. Якщо в деяких відносинах виявлена ??залежність атрибутів від частини складеного потенційного ключа, то проводимо декомпозицію цих відносин на кілька відносин наступним чином: ті атрибути, які залежать від частини складеного потенційного ключа, виносяться в окреме відношення разом з цією частиною ключа. У вихідному відношенні залишаються всі ключові атрибути:
Початкове ставлення:.
Ключ: - складний.
Функціональні залежності:
- залежність всіх атрибутів від ключа відносини.
- залежність деяких атрибутів від частини складного ключа.
декомпозіровано відносини:
- залишок від вихідного відносини. Ключ.
- атрибути, винесені з вихідного відносини разом з частиною складного ключа. Ключ. Звідси зрозуміло, що ставлення знаходиться в другій нормальній формі (2НФ) тоді і тільки тоді, коли відношення знаходиться в 1НФ, і немає неключових атрибутів, залежних від частини складеного потенційного ключа.
Можна ввести поняття неповної функціональної залежності: Чи не ключовий атрибут функціонально повно залежить від складеного ключа якщо він повно залежить від усього ключа в цілому, але не знаходиться у функціональній залежності від якого-небудь з вхідних до нього атрибутів.
Серед заданих функціональних залежностей неповної є залежність Назва ® тема, тип, автор, рік видання, предмет, кафедра. Д...
