Міністерство освіти інауки України
Вінницький національнийтехнічний університет
Інститут автоматики,електроніки та комп’ютерних систем управління
Факультет автоматики такомп’ютерних систем управління
Кафедра КСУ
СИСТЕМА УПРАВЛІННЯ БАЗОЮДАНИХ (ПІДСИСТЕМА “БІБЛІОТЕКА”) В СЕРЕДОВИЩІ 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іcrosoftAccess 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.Коректування технічного завдання допускається з дозволу керівника проекту.