50258 (Система управління базою даних (підсистема "Бібліотека") в середовищі Access), страница 2

- побудова діаграми ER - типу , що включає в свій склад всі суті і зв'язки данної предметної області;

- побудова набору попередніх відношень за вказівкою передбачуваного початкового ключа для кожного відношення ;

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

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

Ми маємо універсальне відношення:

R (№, категорія_літератури, назва_книги, дата_отримання, П_І_Б_читача, рік_народження, адреса, номер_телефонна, код_книги, автор, рік_друку, язик_книги, кількість_сторінок, видавник, зображення).

Для розглянутого прикладу універсальне відношення необхідно розбити на три відношення:

R1(№, категорія_літератури);

R2(назва_книги, дата_отримання, П_І_Б_читача, рік_народження, адреса, номер_телефонна);

R3(код_книги, автор, рік_друку, язик_книги, кількість_сторінок, видавник, зображення).

Правило 1: якщо степінь бінарних зв’язків 1:1 і клас належності обов’язковий для обох сутей, гарантується однократне появлення кожного значення сутей в будь-якому екземплярі відношень. Тобто у відношенні ніколи не буде ні порожньої інформації, ні груп надлишкових даних що повторються. Проте, якщо клас належності однієї з сутей стане необов’язковим, то одного відношеня буде недостаньо, оскільки у всіх кортежах що містять інформацію про екземпляри однієї суті, що не мають зв’язків з екземплярами другоі суті, з’являються пробіли [9].

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

Формування двох відношень, кортежі кожного з яких включають лише опис атрибутів відповідної суті, приводить до виключення пробілів у відношеннях [10]. При цьому зв’язок між сутями буде притримуватися завдяки включенню в одне з відношень ключевих атрибутів іншої суті.

Правило 3: якщо степінь бінарного зв’язку 1:1 клас належності обох сутей не являється обов’язковим, то необхідно використовувати три відношення: по одному для кожноі суті, ключі котрих служать у якості первинних ключів відповідних відношень, і один для зв’язку. Первинним ключем цього відношення може бути будь-яка з двох сутей. Серед своїх атрибутів відношення, що виділється для зв’язку, повинно мати по одному ключеві суті кожноі суті.

Правило 4: якщо степінь бінарного зв’язку 1:N, і клас належності n – зв’язаної суті є обов’язковим, то досить використати по одному відношенню на кожну суть, при умові, що ключ кожної суті служить у якості первинного ключа для відповідного відношення. Додатково, ключ 1 – зв’заної суті повинен бути добавлений, як атрибут у відношенні, що відводиться n – зв’язаній суті.

Правило 5: якщо ступінь бінарного зв’язку 1:N, і клас належності n – зв’язаної суті являється необов’язковим, то необхідно формування трьох відношень: по одному для кожноі суті, причому ключ кожноі суті служить в якості первинного ключа для відповідного відношення, і одного відношення для зв’язку. Зв’язок повинен мати серед своїх атрибутів ключ суті кожної із зв’язуваних сутей.

При степені бінарного зв’язку M:N без залежності від класу належності сутей завжди необхідно використовувати три відношення [4].

Правило 6: якщо степінь бінарного зв’язку M:N, то для зберігання даних потрібні три відношення: по одному для кожної суті, при чому ключ кожної суті служить у якості первинного ключа для відповідного відношення, та одного відношення для зв’язку. Зв’язок повинен мати серед своїх атрибутів і ключ суті кожної із зв’язуваних сутей. Виявлення у предметній області трьохсторонніх зв’язків приводить до необхідності використання чотирьох відношень.

Правило 7: у випадку наявності трьохстороннього зв’язку завжди використовуються чотири відношення: по одному для кожноі суті, причому ключ кожної суті служить в якості первинного ключа для відповідного відношення, і одного відношення для зв’язку. Зв’язок повинен мати серед своїх атрибутів ключі суті кожної із зв’язуваних сутей.

Очевидно, що використання двох відношень в цьому випадку дозволяє встановити дублювання інформації (багатократній опис атрибута 1 – зв’язаної суті, зв’язаного з n атрибутами n – зв’язаної суті) [2].

4.2 Нормалізація відношень

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

Розглянемо теореми про нормалізацію відношень.

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

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

Теорема 3: відношення знаходиться в третій нормальній формі, якщо воно знаходиться в другій нормальній формі і кожен його не ключовий атрибут нетранзитивно залежить від первинного ключа [5].

Використовуючи вищезазначені теореми, проведемо аналіз спроектованих відношень.

Відношення «Жанри книг» знаходяться у першій нормальній формі, тому що всі його атрибути прості.

Відношення «Жанри літератури» знаходяться у першій нормальній формі, тому що всі його атрибути прості.

Відношення «Картки читачів» знаходяться у першій нормальній формі, тому що всі його атрибути прості.

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

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

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

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

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

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

5 Реалізація запитів та вихідних форм

5.1 Аналіз реалізованих запитів

У розроблених програмах були реалізовані наступні запити:

а) назва книг та авторів;

б) перехресний запит по довідковій літературі;

в) запит на прізвище;

г)запит по видавниках;

д)запит по адресі.

Запит «Назва книг та авторів» наведено на рисунку 5.1.

Рисунок 5.1 – Запит «Назва книг та авторів»

Запит «Перехресний запит по довідковій літературі» наведено на

рисунку 5.2.

Рисунок 5.2 – Запит «Перехресний запит по довідковій літературі»

Запит «Прізвище» наведено на рисунку 5.3.

Рисунок 5.3 – Запит «Прізвище»

Запит «По видавниках» наведено на рисунку 5.4.

Рисунок 5.4 – Запит «По видавниках»

Запит «По адресі» наведено на рисунку 5.5.

Рисунок 5.5 – Запит «По адресі»

5.2 Розробка вихідних форм

Для підвищення якості та швидкості роботи розробленої СУБД розроблено десять звичайних форм (кожна форма містить кнопки, що підвищує ефективність використання даних форм) та одну кнопкову.

Для підтвердження правильності роботи всіх форм нижче наведені рисунки вікон усіх форм.

Форма 1 «Картки читачів кожної літературів» зображена на рисунку 5.6.

Рисунок 5.6 –“Кнопкова форма”

Форма 2 «Жанри літератури».

Ця форма є структурною для головної форми СУБД, яка зображена на рисунку 5.7.

Рисунок 5.7 –“Кнопкова форма”

Кожна підлегла форма має свій інтерфейс (рисунки 5.8, …, 5.11).

Рисунок 5.8 – Форма “Жанр наукова”

Форма 3 «Жанр довідкова література» зображена на рисунку 5.9.

Рисунок 5.9 – Форма “ Жанр довідкова література ”

Форма 4 «Картки читачів комп’ютери та інтернет» зображена на рисунку 5.10.

Рисунок 5.10 – Форма “ Картки читачів комп’ютери та інтернет ”

Форма 5 «Картки читачів наукова література» зображена на рис. 5.11.

Рисунок 5.11 – Форма «Картки читачів наукова література»

Форма 6 «Картки читачів довідкова література» зображена на рисунку 5.12.

Рисунок 5.12– Форма «Картки читачів довідкова література»

Форма 7 «Картки читачів ділова література» зображена на рисунку 5.13.

Рисунок 5.13– Форма «Картки читачів ділова література»

6. Розробка експлуаційної документації

6.1 Керівництво користувача

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

- переглядати наявні записи у БД, що містять усі необхідні дані для перегляду інформації;

- здійснювати вибірковий перегляд записів за допомогою кнопоки “фільтрувати”, за допомогою кнопи “открить форму користувач в зручному режимі може переглянути базу даних;

- додавати нові дані і коригувати наявні в базі дані;

- видаляти записи з бази даних.

СУБД досить проста у використанні.

1. 6.2 Керівництво програміста

Для розробки даної бази даних використовувалося операційне середовище Wіndows XP, інтегрований пакет прикладних програм Mіcrosoft Offіce 2003 і його додаток Mіcrosoft Access 2007 - могутній інструмент обробки даних.

Для створення таблиці виконуютья наступні дії.

1. При запуску Access відкривається вікно Access, в якому необхідно вибрати режим ''Созданіє нової бази данних''. Натиснути ОК.

2. Створюваній базі даних привласнити ім'я і натиснути ''Создать''.

3. У вікні, що з'явилося, вибрати вкладку ''Таблиці'' і натиснути ''Создать''.

4. Далі із списку вибрати спосіб створення таблиці.В нашому випадку використовується режим конструктора.

5. У вікні заповнити необхідні імена полів, встановити їх тип, властивості і опис (не обов'язково).

6. За допомогою кнопки на панелі інструментів або через вікно бази даних перейти в режим таблиць здійснити введення або коректування даних.