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

Посмотреть архив целиком


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

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

Інститут автоматики, електроніки та комп’ютерних систем управління

Факультет автоматики та комп’ютерних систем управління

Кафедра КСУ








СИСТЕМА УПРАВЛІННЯ БАЗОЮ ДАНИХ (ПІДСИСТЕМА “БІБЛІОТЕКА”) В СЕРЕДОВИЩІ ACCESS

Пояснювальна записка

до курсового проекту з дисципліни

Бази знань та експертні системи”

за спеціальністю

Системи управління і автоматики”




Керівник курсового проекту

к.т.н., доц. Мітюшкін Ю.І.





Вінниця ВНТУ 2009


ІНДИВІДУАЛЬНЕ ЗАВДАННЯ


на виконання курсового проекту з дисципліни

Бази знань та експертні системи”

студенту Варіант № 19

Тема: СУБД вузу (підсистема “Бібліотека”) в середовищі Access

Вихідні дані:

- степінь універсального відношення не менше 12 ;

- потужність універсального відношення не менше 12 ;

- кількість "сутностей" ER-діаграми не менше 4;

- кількість попередніх відношень не менше 4;

- форма нормалізації первинних відношень не менше 3;

- кількість вихідних форм не менше 5;

- кількість реалізованих запитів не менше 5.

Структура курсового проекту:

    • Титульний лист.

    • Анотація.

    • Вступ.

    • 1 Характеристика області та об’єкта дослідження.

    • 2 Розробка універсального відношення.

    • 3 Розробка ER-моделі предметної області.

    • 4 Проектування нормалізованих відношень.

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

    • 6 Розробка програмного забезпечення СУБД.

    • Висновки.

    • Список літератури.

    • Додатки.



Анотація


В курсовому проекті представлена СУБД бібліотеки. Даний продукт розроблений для отримання довідки про книги та картки читачів. Проведено нормалізацію та розроблено ER-модель СУБД. Розглянуто функціональні підсистеми, побудовано схеми даних програми та інтерфейсу. Проведено тестування програми, виділено основні переваги та недоліки програмного продукту.



Зміст


Вступ

1. Розробка структурної схеми БД

1.1 Змістовна постановка задачі

1.2 Схема даних програми

2. Розробка універсального відношення

3. Розробка ER-моделі предметної області

4. Проектування нормалізованих відношень

4.1 Одержання початкових відношень по методу “суть – зв’язок

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

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

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

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

6. Розробка програмного забезпечення СУБД

6.1 Інструкція користувачу

6.2 Інструкція програмісту

Висновки

Література

Додаток А Технічне завдання




Вступ


Сьогодні бази даних є потужним і зручним способом зберігання і користування інформацією. Вони необхідні у величезній кількості установ, організацій, підприємств для ведення поточних справ. Важливість баз даних важко переоцінити. Тому вони належать до пріоритетного напрямку розвитку програмних продуктів і займають значне місце на ринку прикладних пакетів, а на їх розробку витрачаються шалені гроші. Отже бази даних – це актуально і своєчасно.

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

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



1. Розробка структурної схеми БД


1.1 Змістовна постановка задачі


У даному курсовому проекті повина бути розроблена система управління базою даних бібліотеки в середовищі Access. У базі даних міститься інформація про книги, а також інформація про читача.

Інформація про книги та читачів міститься в дев’яти таблицях:

  • Жанри книг;

  • Картки читачів «Комп’ютери та інтернет»;

  • Картки читачів «Наукова література»;

  • Картки читачів «Довідкова література»;

  • Картки читачів «Ділова література»;

  • Жанр «Наукова література»;

  • Жанр «Довідкова література»;

  • Жанр «Ділова література»;

Вихідна інформація, тобто довідка про книги, що подається у вигляді п’яти запитів, одинадцяти форм та двох звітів.


1.2 Схема даних програми


Щоб розробити БД необхідно спочатку скласти таблицю, в яку занести усі необхідні нам дані : №, категорія літератури, назва книги, дата отримання, ПІБ читача, рік народження, адреса, номер телефонна, код книги, автор, рік друку, язик книги, кількість сторінок, видавник, зображення.

Отримано декілька таблиць, назви яких приведені в попередньому пункті.


Рисунок 1.1 – Розробка таблиць БД


Найчастіше структуру таблиць створюють командою Конструктор таблиць. Користувач у цьому випадку задає:

- назви полів методом введення назви;

- тип даних методом вибору типу з запропонованого списку;

- описи, які є необов'язковими;

- додаткові властивості (характеристики) полів (лише у разі потреби) методом заповнення таблиці властивостей:

а) довжину поля;

б) значення за замовчуванням;

в) умови на значення, яке вводитимуть;

г) формат поля;

д) індексованість поля тощо.

Далі необхідно зв’язати отримані таблиці, обрати ключове поле. Для такого зв'язку(його називають реляційним) вибираємо поля, в яких значення не повторюються, наприклад, числове поле типу лічильник, поле з персональними номерами виду продукції тощо (поле з назвою продукції не підходить, бо в БД можуть бути однакові назви продукції). У Конструкторі таблиці такому полю присвоюють ключ (командою з головного меню Вправка  Ключове поле або командою з контекстного меню поля).

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

На рисунках 1.2, …, 1.4 зображено конструктори таблиці, в яких описано поля та їх типи,а також ключове поле, по якому будуть з’єднані наші таблиці.


Рисунок 1.2 – Перелік категорій літератури


Рисунок 1.3 – Інформація про читача


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


Рисунок 1.4 – Інформація про книгу


Приклад задання ключового поля наведено на рисунку 1.5.


Рисунок 1.5 – Приклад задання ключового поля


Задавши ключове поле хоча б в одній таблиці, налагоджуємо зв'язки між таблицями командою Сервіс  Схема даних. У вікно Схема даних вставляємо потрібні таблиці, а зв'язок налагоджуємо методом перетягування і накладання назви поля з однієї таблиці на назву поля іншої.


Рисунок 1.7 – Створення схеми даних




2. Розробка універсального відношення


Провівши аналіз предметної області, визначимо атрибути, які необхідно ввести в універсальне відношення. До них віднесемо:

а) жанри літератури:

1) №;

2) категорія літератури;

б) картки читачів:

1) назва книги;

2) дата отримання;

3) ПІБ читача;

4) рік народження;

5) адреса;

6) номер телефонна;

в) жанр літератури:

1) код книги;

2) автор;

3) рік друку;

4) язик книги;

5) кількість сторінок;

6) видавник;

7) зображення.

Отже, cпроектоване універсальне відношення матиме наступний вигляд:

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

Кожен інформаційний об'єкт характеризується певним набором атрибутів (властивостей)[2]. Перелік цих атрибутів для даного об’єкта представлений в таблиці 2.1.


Таблиця 2.1 - Перелік атрибутів для формування універсального відношення бази даних вузу (підсистема “Бібліотека”)

Назва атрибуту

Ім’я поля

Коментар

номер продукції

унікальне

категорія_літератури

Категорія літератури

унікальне

назва_книги

Назва книги

може повторюватись

дата_отримання

Дата отримання

може повторюватись

П_І_Б_читача

Прізвище

може повторюватись

Ім’я

Побатькові

рік_народження

Рік народження

може повторюватись

адреса

адреса

може повторюватись

код_книги

Код книги

унікальне

автор

автор

може повторюватись

рік_друку

Рік друку

може повторюватись

мова_книги

мова_книги

може повторюватись

кількість_сторінок

Кількість сторінок

може повторюватись

видавник

видавник

може повторюватись

зображення

зображення

унікальне




3. Розробка ЕR-моделі предметної області


ER-модель (entіty-relatіonshіp model) базується на важливості інформації про об’єкт дослідження і призначена для логічного представлення даних – вона визначає дані в контексті їх взаємозв’язків з іншими даними. Фактично, на основі даної моделі можуть бути побудовані і такі, як ієрархічна, мережева, реляційна моделі.

Під сутністю ЕR-моделі слід розуміти об’єкт, який може бути ідентифікований деяким способом, що відрізняє його від інших об’єктів (наприклад, людина). Будь-яка сутність складається з множини атрибутів, які описують властивості всіх об’єктів, що належать до даної сутності [3].

В данному проекті сутностями є такі об'єкти: жанри книг, картки читачів, жанри літератури.

Характеристики зв’язків предметної області можна представити за допомогою ER-моделей. Зв'язок в рамках ER-моделі представляє собою деяку асоціацію, встановлену, як мінімум між двома сутностями [4]. Це можна побачити на рисунках нижче.


Рисунок 3.1– ER-діаграма сутностей «Жанри книг» і «Жанри літератури»


Рисунок 3.2 – ER-діаграма сутностей «Жанри літератури» і «Картки читачів»


Аналізуючи наведені ER-моделі, можна описати характеристику зв’язків предметної області „Бібліотека” і побудувати результуючу ER-модель.


Таблиця 3.1 - Характеристика зв’язків предметної області

Суть 1

Суть 2

Тип зв’язку

Ім’я зв’язку

Тип належності

Жанри книг

Картки читачів

1:1

Можуть підлягати

не обов.;не обов.

Жанри літератури

Картки читачів

1:1

Має

не обов.; обов.




4 Проектування нормалізованих відношень


4.1 Одержання початкових відношень по методу “суть – зв'язок”


Загальний підхід до проектування баз данних на основі ER-методу що включає в себе наступні кроки:

- побудова діаграми 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.