Міністерство освіти і науки України
Вінницький національний технічний університет
Інститут автоматики, електроніки та комп’ютерних систем управління
Факультет автоматики та комп’ютерних систем управління
Кафедра КСУ
СИСТЕМА УПРАВЛІННЯ БАЗОЮ ДАНИХ (ПІДСИСТЕМА “БІБЛІОТЕКА”) В СЕРЕДОВИЩІ 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.
Рисунок 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 Керівництво користувача
Для користувача є приємним той факт, що при роботі з програмою використовується як клавиатура так і мишка. Працюючи з даною СУБД, користувач може:
- переглядати наявні записи у БД, що містять усі необхідні дані для перегляду інформації;
- здійснювати вибірковий перегляд записів за допомогою кнопоки “фільтрувати”, за допомогою кнопи “открить форму користувач в зручному режимі може переглянути базу даних;
- додавати нові дані і коригувати наявні в базі дані;
- видаляти записи з бази даних.
СУБД досить проста у використанні.
6.2 Керівництво програміста
Для розробки даної бази даних використовувалося операційне середовище Wіndows XP, інтегрований пакет прикладних програм Mіcrosoft Offіce 2003 і його додаток Mіcrosoft Access 2007 - могутній інструмент обробки даних.
Для створення таблиці виконуютья наступні дії.
1. При запуску Access відкривається вікно Access, в якому необхідно вибрати режим ''Созданіє нової бази данних''. Натиснути ОК.
2. Створюваній базі даних привласнити ім'я і натиснути ''Создать''.
3. У вікні, що з'явилося, вибрати вкладку ''Таблиці'' і натиснути ''Создать''.
4. Далі із списку вибрати спосіб створення таблиці.В нашому випадку використовується режим конструктора.
5. У вікні заповнити необхідні імена полів, встановити їх тип, властивості і опис (не обов'язково).
6. За допомогою кнопки на панелі інструментів або через вікно бази даних перейти в режим таблиць здійснити введення або коректування даних.
Для створення запитів виконується наступне.
1. Вибрати вкладку ''Запроси'' і натиснути ''Создать''.
2. У вікні, що з'явилося, вибрати спосіб створення за допомогою конструктора: відкриється вікно конструктора.
3. З'явиться вікно із списком таблиць. Вибрати із списку потрібну таблицю і натиснути ''Добавіть''. Якщо ще потрібні які-небудь таблиці, вибрати необхідні і після кожної - ''Добавіть''.
4. Перетягнути мишею поля з макету таблиці або вибрати із списку, що розкривається, в рядку поле.
5. У рядку ''сортіровка'' вказати порядок сортування, в рядку ''показать'' - виводити на екран чи ні, в рядку ''условіє отбора'' - критерій відбору.
6. Для побудови параметричного запиту, в рядку ''Условіє отбора'' ввести вираз для задачі параметрів такої структури ([Вираз]). При запуску запиту комп'ютер зажадає введення необхідного параметра.
7. Для запуску запиту натиснути на панелі інструментів ''воськліцательний знак'', або виконати команду ''запрос - запуськ'', або через вікно бази даних, натиснувши ''Открить''.
Наступні дії виконуються для створення форми.
1. Вибрати вкладку ''Форма'' і натиснути ''Создать''.
2. У вікні, що з'явилося, вибрати спосіб створення за допомогою майстра або конструктора.
3. У списку таблиць і запитів, що з'явився, вибрати потрібну і потім пройтися по всіх вікнах майстра.
4. Допрацювати форму можна в режимі конструктора або самостійно створити форму в цьому режимі, додаючи на неї елементи управління.
5. Для створення кнопки у формі необхідно запустити майстер на панелі елементів, а потім на цій же панелі натиснути елемент створення кнопки і мишкою вказати місце розташування. У послідовності вікон, що з'явилася, вказати послідовно дію для кнопки, що буде зображено на кнопці і привласнити їй ім'я.
6. Для створення підлеглої форми необхідно запустити майстер на панелі елементів, а потім на цій же панелі натиснути елемент створення підлагодженої форми і мишкою вказати місце розташування і розмір. У послідовності вікон, що з'явилася, вибрати тип і вид підлеглої форми, для таблиць і зпросов - потрібні поля, встановити зв'язок форми з підлеглою формою, задати ім'я і натиснути ''Готово''.
7. Зберегти форму.
8. Проглянути форму можна, увійшовши до вікна бази даних, натиснувши ''Открить''.
При створенні звіту виконується наступне.
1. Перейти на вкладку ''Отчети'' і натиснути ''Создать''.
2. У вікні, що з'явилося, вибрати форму створення звіту. Створювати звіт найлегше за допомогою майстра.
3. У послідовності вікон, що з'явилася, послідовно вказати: тип таблиці або запиту і потрібні поля для звіту, встановити рівні угрупування і сортування усередині груп, макет і стиль звіту, задати ім'я і натиснути ''Готово''.
4. Допрацювати звіт можна в режимі конструктора.
5. Зберегти звіт.
6. Для проглядання звіту, перейти у вікно бази даних і натиснути ''Просмотр''.
Наступні кроки виконуються для створення головної кнопкової форми.
1. Виконати команду ''Сервіс - настройка - диспетчер кнопкових форм''.
2. Відкриється вікно, в якому задаються імена необхідних сторінок кнопкової форми при натисненні кнопки ''Создать''.
3. Відкриваючи подвійним клацанням миші сторінку, задаємо в ній потрібні нам елементи, указуючи його текст на кнопковій формі і виконувану команду. Дії повторити для кожної сторінки і кожного елементу.
4. У головній формі обов'язково створити кнопку ''Виход'' і ''Ізмененіє кнопкової форми'', на кожній сторінці - ''Возврат в головну форму''.
5. Зберегти форму.
6. Для запуску форми у вікні бази даних вибрати її на вкладці ''Форми'' і відкрити.
Висновки
Виходячи з описуваного вище процесу проектування і побудови бази даних, а також основних цілей проектування баз даних і постановки задачі можна зробити такі висновки: була спроектована і створена база даних для даної предметної області, створена програма, що забезпечує роботу користувача з базою даних (перегляд, редагування інформації в базі даних і здійснення пошуку) у зручній для нього формі.
В першому розділі курсового проекту дана характеристика об’єкта, описані особливості галузі дослідження.
В другому розділі розроблено універсальне відношення (вибір інформаційних об'єктів, задання необхідних властивостей для кожного об'єкта, виявлення зв'язків між об'єктами, виявлення обмежень, що накладаються на інформаційні об'єкти, типи зв'язків між ними, характеристики інформаційних об'єктів).
В третьому розділі проведено розробку ER-моделі.
В четвертому розділі було проведено нормалізацію відношень.
В п’ятому розділі описані розроблені запити та форми і в якості тестування наведені рисунки, що зображують роботу форм.
В шостому розділі описано розробку програмного забезпечення, а також інструкції програмісту і користувачу.
Отже, в курсовому проекті я набув навичок в створенні БД та створив програмний продукт, який може застосовувутися в реальному житті.
Література
1. Каратыгин С.А. Access. Руководство пользователя с примерами. – К.: Бамбук, 2000. – 376 c.
2. Гусева Т.И., Башин Ю.Б. Проектирование баз данных в примерах и задачах. – М.: Радио и связь, 1992.
3. Джеффри Д. Ульман, Дж. Уидом. Введение в системы баз данных. – М.: Лори, 2000. – 376с.
4. Райордан Р. Основы реляционных баз данных. – М.: Издательско-торговый дом «Русская Редакция», 2001. – 384с.
5. Чекалов А.П. Базы данных: от проектирования до разработки приложений. — СПб.: БХВ-Петербург, 2003. – 384с.
6. Коцюбинський В.Ю. Прикладні програмні системи. Конспект лекцій. – Вінниця: ВДТУ, 2002. – 73с.
7. Информатика. Базовый курс / С.В. Симонович и др. - СПб: Издательство «Питер», 2000. – 640с.
8. Информатика: Учебное пособие / Под ред. В.Г. Кирия. – Иркутск: ИрГТУ ,1998. – 382с.
9. Информатика: Учебное пособие / В.В. Ломтадзе, Л.П. Шишкина. – Иркутск: ИрГТУ, 1999. – 116 с.
10. Мейлер М. Теория реляционных баз данных. – М.: Мир, 1987.-608 с.
11. Романюк О.Н., Савчук Т.О. Організація баз даних і знань. Навчальний посібник. – Вінниця: УНІВЕРСУМ-Вінниця, 2003. – 217 с.
12. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1989. -351 с.
Додаток А
Міністерство освіти і науки України
Вінницький національний технічний університет
Інститут автоматики, електроніки та комп’ютерних систем управління
ТЕХНІЧНЕ ЗАВДАННЯ
на курсовий проект на тему:
«Система управління базою даних бібліотеки в середовищі Access»
08-01.БЗЕС.019.00.000 ТЗ
1. Призначення та галузь застосування розробки.
1.1. Призначення – керування базою даних бібліотеки.
1.2. Галузь застосування – навчальний процес.
2. Основа розробки – робочий навчальний план дисципліни.
3. Мета розробки.
3.1 Метою курсового проекту є створення системи керування базою даних вузу (підсистема “Бібліотека”).
3.2 Перелік головних функцій.
- робота користувача у режимі кольорового меню;
- введення, видалення та оновлення інформації в базі даних;
- видачу відповідей на запити на вибір користувача на екран дисплею;
- збереження файлів;
4. Джерела розробки – індивідуальне завдання на курсовий проект з дисципліни, літературні та інші технічні матеріали з інформаційних технологій та розробки систем керування базами даних.
5. Технічні вимоги.
5.1. Вимоги до програмної платформи
5.1.1. WІNDOWS ’XP.
5.1.1. Access 2007 (Mіcrosoft Offіce).
5.2. Умови експлуатації системи.
5.2.1 Робота на стандартних ПЕОМ в приміщеннях зі стандартними умовами.
5.2.2 Можливість цілодобового функціонування системи
5.2.3 Текст програмного забезпечення системи є цілком закритим
6. Стадії та етапи розробки.
6.1 Кінцеві терміни виконання КП:
- характеристика області та об’єкта дослідження: 14.10.2009
- розробка моделі досліджуваного об’єкта: 18.11.2009
- розробка програмного забезпечення об’єкта дослідження: 9.12.2009
- тестування програмного забезпечення та комп’ютерні експерименти: 16.12.2009
6.2 Початок розробки: 14 вересня 2009 р.
7. Порядок контролю і приймання.
7.1. Виконання етапів графічної та розрахункової документації курсового проекту контролюється викладачем згідно з графіком виконання проекту.
7.2. Прийняття проекту здійснюється комісією затвердженою зав. кафедрою згідно з графіком захисту.
8. Коректування технічного завдання допускається з дозволу керівника проекту.