Размещено на http://www.allbest.ru/

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

Кафедра інформаційних технологій проектування в електроніці та телекомунікаціях

Курсова робота

з дисципліни "Організація баз даних та знань"

на тему: Розробка бази даних "Бібліотека"

Студента 2 курсу РІ-121 групи

Непрана І.В. .

Керівник доц. каф. ІТПЕТ

к.ф.-м.н. Андріянов О.В.

м. Одеса - 2014 рік

Зміст

Вступ

1. Аналіз вимог до розроблюваної бази даних на основі завдання

1.1 Мета розробки

1.2 Завдання курсової роботи

2. Проектування ER-діаграми

3. Розробка бази даних

3.1 Початок проектування

3.2 Розробка схеми даних

3.3 Розробка таблиць

3.4 Розробка форм

3.5 Розробка запитів

3.6 Розробка звітів

Висновки

Список використаної літератури

Додатки

Вступ

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

Сьогодні є великий вибір програмних засобів, які власне організовують бази даних - чи це Microsoft Access, чи це Oracle, чи це MySQL всі ці продукти так чи інакше використовують мову структурованих запитів - SQL (Structured Queries Language).

Моя база даних - це приклад такої бази для звичайної бібліотеки, в якій можуть бути тисячі, або й сотні тисяч, книжок. Я повинен створити структуру такої бази, щоб систематизувати всю необхідну інформацію, включаючи дані про книги, про читачів, а також представити її в зручному для користування вигляді. СУБД, яка використовується при цьому це - Microsoft Access 2010.

1. Аналіз вимог до розроблюваної бази даних на основі завдання

1.1 Мета розробки

Основною метою курсової роботи з дисципліни "Організація баз даних та знань" є систематизація, поглиблення і активне застосування знань з створення та управління базами даних, закріплення знань, отриманих у лекційному курсі, а також на практичних та лабораторних заняттях. Дану мету можна розкрити наступним чином: систематизація та закріплення теоретичних знань студентів з основних розділів курсу "Організація баз даних та знань"; прищеплення практичних навичок використання SQL, та візуальних засобів розробки бази даних; знайомство з навчальною та науковою літературою, журналами та іншими інформаційними джерелами з метою аналізу стану вирішуваних завдань; виконання всіх етапів розробки бази даних на прикладі, близькому до реальних завдань.

1.2 Завдання курсової роботи

Завдання курсової роботи - розвиток у студентів звичок розробки баз даних, які включають вивчення предметної області, для якої розробляється база, вибір, обґрунтування і використання схеми даних. Особливу увагу було приділено зручності роботи з базою даних та продуктивності бази даних у вигляді миттєвої реакції на запити користувача, водночас з красивим та приємним оформленням інтерфейсу.

Завдання, які вирішуються в ході виконання курсової роботи:

* розробка бази даних відповідно до вимог завдання на курсову роботу;

* закріплення практичних навичок в оформленні документації на кожному етапі розробки.

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

2. Проектування ER-діаграми

До початку реалізації бази даних в СУБД, тобто вживу, необхідно зобразити її структуру у вигляді ER-діаграми. Модель "сутність-зв'язок" (ER-модель) (англ. Entity-relationship model або entity-relationship diagram) - модель даних, яка дозволяє описувати концептуальні схеми за допомогою узагальнених конструкцій блоків. ER-модель - це мета-модель даних, тобто засіб опису моделей даних. ER-модель зручна при проектуванні інформаційних систем, баз даних, архітектур комп'ютерних застосунків та інших систем (моделей). За допомогою такої моделі виділяють найсуттєвіші елементи (вузли, блоки) моделі і встановлюють зв'язки між ними.

Існує ряд моделей для представлення знань. Одним з найзручніших інструментів уніфікованого представлення даних, незалежного від реалізовуючого його програмного забезпечення, є модель "сутність-зв'язок" (entity - relationship model, ER - model).

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

ER-діаграма допомагає заздалегідь продумати схему бази даних, тобто це схоже на блок-схеми алгоритмів, які ми створювали при проектуванні курсової роботи з дисципліни "Алгоритмізація та проектування", не по виду, звичайно, а по суті. В ER-діаграмі таблиці зображуються прямокутниками, зв'язки між таблицями (сутностями) - ромбами, між якими проводять лінії з відповідними стрілочками чи без них.

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

Зв'язки між сутностями типу "один до багатьох" відображаються на ER-діаграмі стрілочками в одному напрямку. До ромбика малюється лінія, як і при "один до одного", а від ромбика до другої сутності малюється стрілочка. Стрілочкою позначається сутність в якій будуть використовуватися записи з першої сутності з можливістю повторювання значень. В моїй діаграмі такий зв'язок встановлено між сутностями "Жанр" та "Книги", а також - "Читачі" та "Картки читачів".

Зв'язки між сутностями типу "багато до багатьох" на ER-діаграмі зображуються стрілочками в обидві сторони. Такий тип зв'язку повідомляє, що записи і з першої і з другої сутності можуть повторюватися. В моїй діаграмі таких зв'язків немає. Моя ER-діаграма складається з 4 сутностей - 4 таблиці, відповідно, в базі даних, та зв'язків між ними.

Перша сутність це - "Книги". У неї атрибутами є - "Назва книги", "Номер зберігання", "Автори", "ISBN", "Наявність в бібліотеці", "Видання", "Рік видання". Зрозуміло, що вона містить всі необхідні дані про книжки, що наявні в бібліотеці. Відповідно до ER-діаграми наведеної в додатку 1, а конкретно до її частини, що виділена на рис.1, сутність "Книги" пов'язана з двома іншими сутностями зв'язками.



Рисунок 1 - Зв'язки сутності "Книги" на ER-діаграмі

З рис. 1 видно, що атрибут "Номер зберігання" з сутності "Книги" використовується в сутності "Картки читачів", а атрибут "ID жанру" використовується в самій сутності "Книги", при чому зв'язок з "ID жанру" - "один до багатьох", а з "Номером зберігання" - "один до одного". Тобто, одному елементу "Номер зберігання" відповідає єдиний запис в сутності "Картки читачів", а от одному елементу "ID жанру" може відповідати декілька записів в таблиці "Книги".

Друга сутність це - "Жанр". Атрибутами цієї сутності є "Назва жанру", "ID жанру". В цій сутності зберігається інформація про всі жанри книг, які зберігаються в нашій бібліотеці. Сутність "Жанр" пов'язана єдиним зв'язком з сутністю "Книги", про що було сказано вище. Хочу ще навести фрагмент з "ER-діаграми", який зображає сутність "Жанр" представлений на рис.2.



Рисунок 2 - Сутність "Жанр" та її зв'язок

Третя сутність це - "Читачі". "ID читача", "Адреса" та "Ім'я" це - атрибути третьої сутності нашої діаграми. Тут у нас зберігається інформація про наших читачів, які беруть книги в бібліотеці. Зв'язок встановлено з сутністю "Картки читачів" зв'язком типу "один до багатьох". Ми беремо атрибут "ID читача" та використовуємо його, з можливістю повторювання значень в сутності "Картки читачів". Таким чином ми визначаємо читачів, які взяли ту чи іншу книгу (книги) в бібліотеці в сутності "Картки читачів".

Четверта сутність це - "Картки читачів". Атрибутами цієї сутності це - "Дата видачі" і "Дата повернення". За допомогою зв'язків в цій сутності, м ще отримуємо атрибути "Номер зберігання" і "ID читача", про що було вже сказано вище, коли ми розбирали попередні сутності діаграми.

Повна ER-діаграма представлена у додатку А.

3. Розробка бази даних

3.1 Початок проектування

При проектуванні бази даних "Бібліотека" я використовував СУБД Microsoft Access 2010, що визначено завданням. Саме 2010 версію, тому що вона найбільш сучасна з версій, які підтримують створення кнопочної форми, яку необхідно створити у відповідності з поставленим завданням.

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

3.2 Розробка схеми даних

Схема даних це - один із найважливіших елементів в базі даних. За допомогою схеми даних укладаються зв'язки між атрибутами таблиць, що грає дуже важливу роль при проектуванні будь-якої бази даних. Наша схема даних створювалася на основі розробленої раніше ER-діаграми. Відповідно до неї і були влаштовані зв'язки між таблицями.

Перший зв'язок між таблицями "Жанр" та "Книги", а точніше їх атрибутів "ID жанру" та "Жанр", зображено на рис.3, що наведений нижче.

Рисунок 3 - Зв'язок "ID жанра"

Зв'язок встановлено "один до багатьох", як і було вказано в ER-діаграмі.

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

Інший зв'язок в схемі даних, це зв'язок "Номер зберігання" таблиць "Книги" та "Картки читачів". Цей зв'язок "один до одного", що добре видно на рисунку 4, який наведено нижче.

Рисунок 4 - Зв'язок "Номер зберігання"

Одному номеру зберігання з таблиці книги відповідає одна єдина книга в бібліотеці, чи якесь інше видання, не обов'язково саме книга. Цьому ж номеру може відповідати єдиний запис в таблиці "Карти читачів", якщо читач візьме більше однієї книги, то записів буде більше, але на один запис, тільки один номер зберігання.

Між таблицями "Читачі" та "Карти читачів" встановлений зв'язок "один до одного". Ми беремо "Код читача" в таблиці "Читачі" та підставляємо його в атрибут "Читач" таблиці "Карти читачів", однак в параметрах підстановки зроблені умови, які замість коду відображають нам ім'я читача для зручності і зрозумілості даних. До речі, я не сказав цього раніше, але це дуже важливо - завдяки такому підходу ми при складанні форм в майбутньому не отримаємо проблем з відображенням імені читачів, а їх кодів, які зовсім не інформативні.

Зв'язок згаданий вище зображено на рисунку 5, що наведено нижче.

Рисунок 5 - Зв'язок "Код читача"

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

3.3 Розробка таблиць

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

Перша таблиця це - "Книги". З назви зрозуміло, що в цій таблиці зберігаються дані про всі книги та інші друковані видання, які зберігаються в бібліотеці.

В цій таблиці зберігаються назви книг, їх жанри, автори, видавництва, роки видання, інформація про наявність книги в бібліотеці, код ISBN кожної книги та їх номера зберігання.

Структура таблиці зображена на рисунку 6, який наведено нижче.

Рисунок 6 - Структура таблиці "Книги"

Тут можна наочно ознайомитися з відповідними типами даних для кожного атрибуту. Однак, для атрибуту "Жанр" є ще й код підстановки, який я згадував вище, для відображення замість ідентифікатора жанру його назву. Скріншот з розділом підстановки атрибуту "Жанр" зображено на рисунку 7.

Рисунок 7 - Підстановка атрибуту "Жанр"

Скріншот самої таблиці наведено у додатку Б, в розділі таблиць.

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

Структура таблиці наведена на рисунку 8, там ми можемо бачити всі типи атрибутів таблиці. Рисунок 8 наведено нижче.

Рисунок 8 - Структура таблиці "Картки читачів"

Також в цій таблиці використовується вже згаданий вище прийом підстановки даних, тут - в атрибуті "Читач". Код підстановки: "SELECT [Читатели].[Код], [Читатели].[Имя] FROM Читатели;". Так само, як і в попередньому прикладі використанні цього прийому, ми отримаємо підстановку даних в атрибут "Читач" замість його числового значення, і так само точно ми уникаємо необхідності копіювати одну й ту ж саму інформацію в декілька різних таблиць.

Наступна таблиця - "Жанри". Тут зберігаються всі жанри видань, а також їхні числові ідентифікатори. Тип атрибуту "ID жанру" - лічильник, атрибуту "Жанр" - текстовий. Підстановки відсутні. Таблиця дуже проста і має відповідну просту структуру.

І остання таблиця в нашій базі даних - "Читачі". Тут зберігається інформація про всіх читачів, їх імена, адреса та унікальні ідентифікатори в бібліотеці. Типи атрибутів "Адреса" та "Імя" - текстові, а "Ко" - лічильник.

Структура теж досить проста, підстановок немає. Про зв'язки з іншими таблицями було сказано раніше. Тому, сенсу наводити скріншоти немає.

3.4 Розробка форм

access запит інтерфейс навігація

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

В нашій базі даних ми розробили п'ять різних форм, чотири - для кожної таблиці відповідно, а п'ята - кнопочка форма відповідно до завдання.

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

Перша така форма це - "Жанр". В цій формі ми можемо, як додавати нові записи, так і редагувати попередні. У нас є всього два поля з даними це - "Жанр" і його ідентифікаційний номер - "ID жанру".

Зовнішній вигляд форми "Жанр" приведено на рисунку 9.

Рисунок 9 - Форма "Жанр"

Друга форма це - "Картки читачів". Аналогічні функції вона представляє користувачеві. Є чотири поля для введення/редагування даних, а також поле з прапорцем для відмітки про повернення книги читачем в бібліотеку.

В полях "Номер зберігання" та "Читач" реалізовані поля зі списком. Тобто при вводі даних користувач обмежений значеннями наведеними у списку і не може вводити у ці поля інші значення.

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

Четверта форма - "Картки користувачів". Тут у нас лише три поля для вводу це - "Ім'я", "Код" та "Адреса". "Код" інкрементується автоматично, а інші поля необхідно заповнювати самому. Вигляд форми наведено на рисунку 10.

Рисунок 10 - Форма "Читачі"

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

Головна сторінка створеної кнопкової форми наведена на рисунку 11.

Рисунок 11 - Головна сторінка кнопкової форми

Як і повинно бути - при клікі по будь якому елементу меню кнопкової форми ми або переходимо на один із елементів управління бази даних, або виходимо з неї, при клікі по кнопці "Вихід".

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

При натисканні ж на кнопку "Запити" нам відкриється другий рівень меню з доступними до виконання запитами, все дуже просто.

Окремою кнопкою я виділив виконання макросу "Комплекс "Книги немає". Цей макрос послідовно запускає декілька запитів, які повністю переглядають в таблиці "Картки читачів" дані про наявність книг в бібліотеці, а потім вносять необхідні зміни про статус книг в таблицю "Книги". Це дуже сильно спрощує роботу з базою даних, адже зникає необхідність вести облік наявності книг вручну, все за нас зробить середовище бази даних, якщо йому правильно пояснити, що ми від нього хочемо.

І останнє про форми - хотів би додати, що для додавання запитів в кнопкову форму були створені додаткові форми по всім необхідним запитам, однак я їх не згадую, тому що вони повністю повторюють собою відповідні запити і існують лише для створення кнопкової форми.

3.5 Розробка запитів

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

Всі запити без виключень розроблені в режимі SQL, автоматичними редакторами, які постачаються в середовищі MS Access 2010 я не користувався.

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



Рисунок 12 - Запити

Перший з них це - "Боржники". Цей запит повертає імена та адреси читачів, які взяли книги та не вчасно їх повернули. Запитом враховується період на який книга була видана читачеві і якщо, період закінчився, а читач так і не повернув книгу він потрапляє у вибірку. Цей запит задовольняє фрагмент завдання про облік боржників.

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

Наступний запит - "Книги відсутні в бібліотеці". Дзеркальний запит до попереднього. Результати цього запиту будуть більш корисними для працівників бібліотеки, вони знатимуть, які саме книги взагалі зараз на руках у читачів. Проте, якщо читача цікавить якась конкретна книга і він бажає взяти в бібліотеці лише її і тільки її, то результати цього запиту будуть для нього дуже корисними, це набагато швидше та зручніше ніж шукати книгу в вибірці наявних книг, яких може бути дуже багато.

Тепер переходимо до додаткових запитів, які працюють на оновлення таблиці "Книги" в базі.

Перший з них та четвертий взагалі це - запит "Обновити в таблиці статус книг". Він перевіряє книги на їх відсутність у бібліотеці та оновлює таблицю "Книги" при знаходженні книг, що відсутні. Лише для відсутніх книг працює цей запит, адже, нажаль, версія SQL, яка використовується в СУБД Microsoft Access не дозволяє виконувати більше однієї дії в одному запиті, тому деякі, навіть поєднані дії, необхідно відокремлювати в окремі запити. Проте, з іншого боку, такий підхід збільшує читаність кодів запитів, тому що вони стають простішими і виконують лише одну визначену функцію.

Другий спеціальний запит називається "Оновити книги, що є в бібліотеці". Він вже навпаки - працює шукаючи книги, які є в бібліотеці і вносить зміни в таблицю "Книги", якщо книги є в бібліотеці.

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

SQL код запиту "Оновити книги, що є в бібліотеці": "UPDATE Книги SET [Книга в библиотеке] = 0

WHERE [Номер хранения] IN (SELECT [Номер хранения] FROM [Карты читателей] WHERE (DateDiff("d",[Карты читателей].[Дата возврата],Date())>0)) AND [Номер хранения] IN

(SELECT [Номер хранения]

FROM [Карты читателей]

WHERE [Книга возвращена]=False);".

3.6 Розробка звітів

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

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

У моїй базі даних створено сім звітів - для кожної таблиці і для основних трьох запитів. Звіти створювалися майстром звітів. В таких звітах, як "Картки читачів", "Книги", "Жанри" та "Читачі" обрано групування по ключовим полям цих елементів. В інших групування не створювалося через відсутність такої необхідності.

На рисунку 13 зображені всі створені звіти в базі даних "Бібліотека".

Рис. 13 - Звіти

Тепер, я хотів би представити фрагмент виконання звіту "Книги", який максимально наочно і точно показує всю зручність формату запитів. Результат роботи звіту представлено на рисунку 14.

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



Рисунок 14 - Звіт "Книги"

Ще один приклад відмінної роботи звітів наведено на рисунку 15, це звіт "Картки читачів".

Рисунок 15 - Звіт "Книги"

В цьому звіті нам надається інформація про книги, які взяті читачами додому, ким саме, коли і коли вони повинні повернуте книгу, а також яку саме книгу було взято (її номер зберігання).

Як ви самі бачите, все дуже зручно та компактно розміщено.

І останнє, що я хотів би сказати у цьому розділі. Це макрос "Комплекс "Книги немає". Його створено, як об'єднувача декількох запитів на оновлення таблиці "Книги", про що вже було сказано раніше. Як на ділі цей макрос виглядає, ви можете побачити на рисунку 16.

Рисунок 16 - Макрос

Логіка роботи макросу проста і послідовна. Ми отримуємо дані в запиті "Книги, що відсутні в бібліотеці". Потім включається запит "Обновити статус книг", який знаходить відсутні книги і вносить відповідні зміни в таблицю "Книги" при необхідності. Потім, включається запит "Оновити книги, що є в бібліотеці" і проходить дзеркальна операція до попередньої.

Висновки

В процесі виконання курсової роботи я вивчив техніку створення баз даних з використанням сучасної платформи Microsoft Access 2010. Розроблено базу даних "Бібліотека", яка може слугувати наочним прикладом використання функцій Access та SQL. При проектуванні програми спочатку була складена ER-діаграма бази даних з описом кожної сутності у вигляді її атрибутів, потім була розроблена схема даних в базі даних. Відповідно до поставленого завдання були розроблені відповідні запити, форми, таблиці та звіти. Також, було розроблено спеціальний макрос для оновлення даних. Для наочності роботи бази даних, користувачу представлена кнопкова форма, за допомогою якої можна здійснювати навігацію по базі даних, вносити необхідні зміни до існуючих записів, або додавати нові.

Також, я вивчив принципи складання запитів на мові структурованих запитів SQL. За допомогою зручних і зрозумілих команд мови SQL я розробив п'ять запитів, які показали свою повну працездатність і виконують свої функції повністю правильно.

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

Список використаної літератури

1. Мартин Д. Планирование развития автоматизированных систем. - М.: Финансы и статистика, 1984. - 196 с.

2. Мейер М. Теория реляционных баз данных. - М.: Мир, 1999. - 608 с.

3. Оззу М.Т., Валдуриз П. Распределенные и параллельные системы баз данных //СУБД. - 2000. - №4. - С.4-26.

4. Озкарахан Э. Машины баз данных и управление базами данных. - М.: Мир, 1989.

5. Пржиялковский В.В. Абстракции в проектировании БД //СУБД. - 2005. - №1. - С.90-97.

6. Прохоров А, Определение оптимальной структуры базы данных //Informix magazine. Русское издание. - 2006. - Апрель.

7. "SQL Полное руководство". BHV, Киев. - 1998. - 250 с.

Додаток А. ER-діаграма

Додаток Б. Елементи бази даних

Вихідні коди та результати виконання запитів

Звіти

Форми

Таблиці

Размещено на Allbest.ru