Розробка бази даних служби побуту

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

РЕФЕРАТ

Розробка бази даних служби побуту (ремонт годинників) // Курсовий проект // Дем'янчик Степан Теодозійович // Тернопільський національний технічний університет імені Івана Пулюя. Факультет комп'ютерно-інформаційних систем та програмної інженерії. Кафедра комп'ютерних наук. СНс-31 // Тернопіль. 2016 рік // Сторінок - 35. Рисунків - 10. Джерел - 12.

Ключові слова - БД, СКБД, СУБД, РЦЗ, НФ.

Об'єкт дослідження - створення бази даних служби побуту (ремонт годинників).

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

Предметом дослідження є ER-діаграми, реляційні моделі баз даних, системи управління базами даних Microsoft Access 2010.

У першому розділі курсової роботи описано загальні теоретичні відомості про бази даних.

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

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

Метод реалізації - використання Microsoft Access для побудови бази даних.



ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ

БД - база даних

СКБД - система керування базами даних

СУБД - система управління базами даних

ПК - персональний комп'ютер

ПЕОМ - персональна електронно-обчислювальна машина

АСУ - автоматизована система управління

ІЗ - інформаційне забезпечення

CD-ROM (compact disc read-only memory) - різновид компакт-дисків з даними, доступними тільки для читання

DVD (Digital Versatile Disc - цифровий багатоцільовий диск) - носій інформації у вигляді диска має можливість зберігати більше інформації за рахунок використання лазера з меншою довжиною хвилі, ніж для звичайних компакт-дисків

USB (Universal Serial Bus) - універсальна послідовна шина, призначена для з'єднання периферійних пристроїв

RAD (Rapid Application Development) - швидка розробка додатків



ЗМІСТ

ВСТУП

1. ОСНОВНІ ОСОБЛИВОСТІ БАЗИ ДАНИХ

1.1 Загальна характеристика реляційних баз даних

1.2 Проектування бази даних

1.2.1 Особливості концептуального проектування

1.2.2 Нормалізація таблиць

1.2.3 Фізичне проектування

2. ПРОЕКТУВАННЯ БАЗИ ДАНИХ

2.1 Концептуальне проектування

2.2 Перетворення ER-моделі в реляційну

2.3 Фізичне проектування

2.4 Реалізація алгоритмів обробки даних

2.5 Проектування інтерфейсу

2.6 Конструювання звітів

3. ЗАСТОСУВАННЯ РОЗРОБЛЕНОЇ БАЗИ ДАНИХ

3.1 Робота користувача з базою даних

3.2 Результати використання бази даних

ВИСНОВКИ

ПЕРЕЛІК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ



ВСТУП

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

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

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

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

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

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

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

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

Предметом дослідження є ER-діаграми, реляційні моделі баз даних, системи управління базами даних Microsoft Access 2010.



1. ОСНОВНІ ОСОБЛИВОСТІ БАЗИ ДАНИХ

1.1 Загальна характеристика реляційних баз даних

У традиційних АСУ (автоматизованих системах управління) -- системах обробки інформації, які функціонували на машинах типу ЄС ЕОМ, дані були організовані у вигляді незв'язаних між собою локальних інформаційних файлів лінійної структури. Суть такого підходу до організації інформаційного забезпечення (ІЗ) полягала в тому, що файли проектуються окремо для кожної конкретної задачі чи для їх комплексів. Такі системи називають файловими.

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

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

Схема відношення задасться ім'ям відношення та іменами відповідних доменів.

Реляційна база даних -- це набір взаємозв'язаних відношень, які можна поділити на два класи: об'єктні й зв'язкові.

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

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

Зв'язкове відношення зберігає ключі двох або більше об'єктних відношень, за якими встановлюються зв'язки між ними.

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

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

У реляційній базі даних накладається ще одне обмеження - відношення мають бути нормалізовані.

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

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

1.2 Проектування бази даних

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

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

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

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

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

1.2.1 Особливості концептуального проектування

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

Засобом моделювання предметної області на етапі концептуального проектування є модель "сутність-зв'язок". Часто її називають ER-моделлю (Entity -- сутність, Relation -- зв'язок). Основні поняття ER-діаграми --сутність, атрибут, зв'язок. Сутність -- це об'єкт предметної області, який необхідно відображувати в базі даних з точки зору прикладної програми чи користувача бази даних. Це може бути предмет, факт, дія, явище чи поняття, що є предметом пізнання людини чи результатом її діяльності і інформацію про які потрібно зберігати в базі даних.

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

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

Розрізнюють тип сутності та її екземпляри. Тип сутності описує абстрактні, а екземпляр -- конкретні характеристики сутності. Наприклад, сутність СТУДЕНТ (№ залікової книжки, ПІБ, рік народження, курс, група) є типом, а СТУДЕНТ (009393, КОСТЕНКО, 1976, 1-й курс, 1-ша група) -- екземпляром сутності.

Загалом кажучи є такі типи зв'язків: один до одного, один до багатьох, багато до одного, багато до багатьох.

Тип співвідношення "один до одного" Т (А1, А2) = 1:1 існує тоді, коли одному і тому самому екземпляру атрибута А1 відповідає не більш як один екземпляр атрибута А2, і навпаки, наприклад, атрибути "табельний номер" і "прізвище, ім'я та по батькові" знаходяться у співвідношенні 1:1.

Тип співвідношення "один до багатьох" Т (А1, А2) = 1:Б існує тоді, коли одному значенню атрибута А1 може відповідати нуль або багато значень атрибута А2, одночасно будь-якому екземпляру атрибута А2 може відповідати не більше як один екземпляр атрибута А1. Наприклад, між атрибутами Т (цех, бригада) = 1:Б.

Тип співвідношення "багато до одного" Т (А1, А2) = Б:1 існує, коли одному значенню атрибута А1 відповідає щонайбільше одне значення атрибута і будь-якому атрибуту А2 може відповідати нуль чи багато значень атрибута А1. Якщо Т (А1, А2) = Б:1, тоді Т (А2, А1) = 1:Б.

Тип співвідношення "багато до багатьох" Т (А1, А2) = Б:Б означає, що будь-якому значенню А1 може відповідати нуль чи кілька значень А2 і водночас, навпаки, будь-якому значенню А2 може відповідати нуль чи кілька значень А1. Наприклад, Т (матеріал, постачальник) = Б:Б, один і той самий матеріал може постачатися різними постачальниками і, навпаки, один постачальник може постачати різні матеріали.

1.2.2 Нормалізація таблиць

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

Нормалізацію відношень виконують за кілька кроків:

Перша ітерація (перший крок) -- зведення відношень до першої нормальної форми (1НФ). Відношення в 1НФ мають відповідати таким вимогам:

усі атрибути відношення мають бути унікальними, тобто не допускається їх дублювання, а також атомарними, тобто неподільними;

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

імена стовпців мають бути різними, а значення однорідними (однакового формату);

Таблиці, що розглядаються перебувають у 1НФ.

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

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

Атрибут В залежить від А у відношенні R тоді, коли в кожний момент часу одному й тому самому значенню А відповідає не більше як одне значення В.

Цій залежності відповідає співвідношення 1:1 між атрибутами (наприклад, як між атрибутами код деталі > назва деталі, код верстата > назва верстата).

Коли відношення має складні ключі, то залежність неключових атрибутів від такого ключа може бути повною або частковою. Якщо маємо відношення R (A*, В*, С, D), ключ якого складається з двох атрибутів А і В, тобто є складним (знаком (*) позначено ключові атрибути), то функціональні залежності в такому відношенні можуть мати такий вигляд:

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

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

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

Виконавши декомпозицію відношення R, отримаємо замість одного два відношення, які будуть перебувати в 2НФ:

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

Третій крок нормалізації -- вилучення транзитивних залежностей. Відношення в 2НФ потрібно аналізувати на присутність транзитивних залежностей.

Транзитивна залежність -- це залежність між неключовими атрибутами. Нехай є відношення R (A*, С, D), у якому атрибут D безпосередньо не залежить від ключового атрибута А, а залежить від неключового атрибута С, який залежить від А. Тоді атрибут D транзитивно залежить від А.

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

Відношення перебуває в ЗНФ, якщо воно перебуває в 2НФ і кожний неключовий атрибут нетранзитивно залежить від первинного ключа.

Існує ще підсилена ЗНФ - нормальна форма Бойса - Кодда (БКНФ).

БКІНФ вивчає залежності ключових атрибутів від неключових; якщо такі залежності існують, то їх потрібно вилучити.

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

1.2.3 Фізичне проектування

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

Основними факторами, що впливають на даталогічне проектування з боку системи управління базами даних, є такі:

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

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

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

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

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

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

усі атрибути відношень мають бути атомарними, тобто неподільними;

відношення не повинно мати дублюючих рядків і стовпчиків;

усі атрибути у відношенні повинні мати унікальні імена.

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

Об'єктними будуть ті відношення, що вміщують нормативно-довідкові дані й первинні ключі яких не можуть дублюватися. Ці відношення можуть бути віднесеними до умовно-постійних файлів.

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

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

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

Отримані реляційні відношення мають відповідати умовам нормалізації. Тому отриману в результаті відображення модель потрібно ще раз перевірити на відповідність її вимогам ЗНФ.



2. ПРОЕКТУВАННЯ БАЗИ ДАНИХ

2.1 Концептуальне проектування

проектування база access логічний

На сьогоднішній день напевно кожен має годинник. Без них важко уявити своє життя. Але вони ламаються і не кожен знає як по-ремонтувати його. Тому були створені спеціальні сервісні центри.

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

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

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

У БД повинна зберігатися інформація про:

ЗАМОВЛЕННЯ : код замолвення, код клієнта, вартість, відмітка про виконання, дата звернення, дата виконання, код послуги;

ЗАПЧАСТИНИ : код запчастини, вид запчастини, код послуги;

КЛІЄНТІВ : код клієнта, ім'я, телефон, адреса;

МАЙСТРІВ : код майстра, ім'я, адреса, код послуги;

ПОСЛУГИ : код послуги, вид послуги, вартість послуги, код замовлення.

При проектуванні бази даних служби побуту ми виділимо такі сутності, як ЗАМОВЛЕННЯ, ЗАПЧАСТИНИ, КЛІЄНТИ, МАЙСТРИ, ПОСЛУГИ.

На ER-діаграмі сутності записуються в прямокутнику.

Між встановленими сутностями було визначено зв'язки, тобто як взаємодіють сутності. У даній предметній області можна виділити такі зв'язки:

КЛІЄНТ - МАЄ - ЗАМОВЛЕННЯ;

ПОСЛУГУ - ВИКОНУЄ - МАЙСТР;

ПОСЛУГА - МАЄ - ЗАМОВЛЕННЯ;

ПОСЛУГА - МАЄ - ЗАПЧАСТИНИ.

НА ER-діаграмі зв'язки позначаються ромбами.

Для кожного із встановлених зв'язків визначимо тип зв'язку. Отже, для встановлених нами зв'язків можна так визначити їх типи. Оскільки клієнт може зробити декілька замовлень, а замовлення мають відношення тільки до одного клієнта, то кожен екземпляр сутності КЛІЄНТ має бути пов'язаний більш, ніж з одним екземпляром сутності ЗАМОВЛЕННЯ, а кожен екземпляр сутності ЗАМОВЛЕННЯ може бути пов'язаний не більше ніж з одним екземпляром сутності КЛІЄНТ. В цьому випадку зв'язок 1 має тип ”один до багатьох” (1:Б), і виглядає так, як показано на рисунку 2.1.1.

Рисунок 2.1.1 - ER-діаграма для зв'язку 1

Оскільки послугу можуть виконати декілька майстрів, а майстри пов'язані тільки з певною послугою, то кожен екземпляр сутності ПОСЛУГА може бути пов'язаний більш, ніж з одним екземпляром сутності МАЙСТР, а кожен екземпляр сутності МАЙСТР може бути пов'язаний не більше, ніж з одним екземпляром сутності ПОСЛУГА. В цьому випадку зв'язок 2 має тип “один до багатьох” (1:Б).

Загальний вигляд поданий на рисунку 2.1.2.



Рисунок 2.1.2 - ER-діаграма для зв'язку 2

Оскільки певна послуга може мати декілька замовлень, а замовлення пов'язані тільки з певною послугою, то кожен екземпляр сутності ПОСЛУГА може бути пов'язаний більш, ніж з одним екземпляром сутності ЗАМОВЛЕННЯ, а кожен екземпляр сутності ЗАМОВЛЕННЯ може бути пов'язаний не більше, ніж з одним екземпляром сутності ПОСЛУГА. В цьому випадку зв'язок 3 має тип “один до багатьох” (1:Б). Загальний вигляд поданий на рисунку 2.1.3.

Рисунок 2.1.3 - ER-діаграма для зв'язку 3

Певна послуга може мати декілька запчастин, а запчастини пов'язані тільки з певною послугою, то кожен екземпляр сутності ПОСЛУГА може бути пов'язаний більш, ніж з одним екземпляром сутності ЗАПЧАСТИНИ, а кожен екземпляр сутності ЗАПЧАСТИНИ може бути пов'язаний не більше, ніж з одним екземпляром сутності ПОСЛУГА. В цьому випадку зв'язок 4 має тип “один до багатьох” (1:Б).

Загальний вигляд поданий на рисунку 2.1.4.



Рисунок 2.1.4 - ER-діаграма для зв'язку 4

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

Набори атрибутів сутностей предметної області слуби побуту (ремонт годинників) представленно в таблиці 2.1.1.

Таблиця 2.1.1 - Набори атрибутів сутностей предметної області служби побуту (ремонт годинників)

КЛІЄНТИ	МАЙСТРИ	ЗАМОВЛЕННЯ	ПОСЛУГИ	ЗАПЧАСТИНИ
Код клієнта	Код майстра	Код замовлення	Код послуги	Код запчастини
Ім'я	Ім'я	Код клієнта	Вид послуги	Вид запчастини
Телефон	Адреса	Вартість	Вартість послуги	Вартість запчастини
Адреса	Код послуги	Відмітка про виконання	Код замовлення	Код послуги
		Дата звернення
		Дата виконання
		Код послуги

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

2.2 Перетворення ER-моделі в реляційну

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

Отже в нашому випадку визначено зв'язки типу 1:Б, причому клас приналежності сутності на стороні М, в обох випадках є обов'язковим, то необхідно побудувати таблиці для кожної з сутностей, де первинний ключ сутності має бути первинним ключем відповідної таблиці. Отже побудуємо такі таблиці:

2.3 Фізичне проектування

Для предметної області служби побуту (ремонт годинників) у Microsoft Access було створено п'ять таблиць, а саме: КЛІЄНТИ, ЗАМОВЛЕННЯ, МАЙСТРИ, ПОСЛУГИ та ЗАПЧАСТИНИ. Визначено ключові атрибути таким чином: для таблиці КЛІЄНТИ ключовий атрибут код клієнта, для таблиці ЗАМОВЛЕННЯ - код замовлення, для таблиці МАЙСТРИ - код майстра, для таблиці ПОСЛУГИ - код послуги, для таблиці ЗАПЧАСТИНИ - код запчастини.

Схема даних для предметної області служби побуту (ремонт годинників) подана у додатку А.

2.4 Реалізація алгоритмів обробки даних

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

Узагальнений алгоритм рішення комплексу завдань зводиться до вказівки послідовності звернень до таблиць БД для вибірки необхідної інформації.

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

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

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

Система керування реляційною БД призначена для виконання запитів на вибірку інформації:

вибирати підмножину стовпців таблиці;

об'єднувати стовпці різних таблиць;

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

Для формування запитів до БД використовуються “Запит за зразком” (Query by Example QBE) або мова запитів SQL (Structured Query Language).

У даній інформаційній системі створено декілька запитів:

Лістинг 2.3.1 - SQL-код запиту “відомість про замовлення”

SELECT Клієнти.Імя, Послуги.ВидРоботи, Майстри.Імя, Замовлення.Вартість, Замовлення.ВідміткаПроВиконання, Замовлення.ДатаЗвернення, Замовлення.ДатаВиконання

FROM (Послуги INNER JOIN (Клієнти INNER JOIN Замовлення ON Клієнти.КодКлієнта = Замовлення.КодКлієнта) ON Послуги.КодРоботи = Замовлення.Код_послуги) INNER JOIN Майстри ON Послуги.КодРоботи = Майстри.КодРоботи;

Лістинг 2.3.2 - SQL-код запиту “замовлення у певний період часу”

SELECT Клієнти.Імя, Послуги.ВидРоботи, Майстри.Імя, Замовлення.Вартість, Замовлення.ВідміткаПроВиконання

FROM (Послуги INNER JOIN (Клієнти INNER JOIN Замовлення ON Клієнти.КодКлієнта = Замовлення.КодКлієнта) ON Послуги.КодРоботи = Замовлення.Код_послуги) INNER JOIN Майстри ON Послуги.КодРоботи = Майстри.КодРоботи

WHERE (((Замовлення.ДатаЗвернення)<Now()) AND ((Замовлення.ДатаВиконання)>Now()));

Лістинг 2.3.3 - SQL-код запиту “кількість замовлення клієнтів”

SELECT Клієнти.Імя, Count("Кількість") AS [Кількість замовлень]

FROM Клієнти INNER JOIN Замовлення ON Клієнти.КодКлієнта = Замовлення.КодКлієнта

GROUP BY Клієнти.Імя;

2.5 Проектування інтерфейсу

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

Рисунок 2.5.1 - Форма авторизації користувачів

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

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

Рисунок 2.5.2 - Основна користувацька форма

У даній формі використовуються такі елементи: вкладки, список, поля зі списком, рисунок, надписи, текстові поля та кнопки. Список відображає інформацію про клієнтів, які робили замовлення. Якщо клієнт є у базі даних, то користувач може вибрати його у полі зі списком. Якщо ні, то можна перейти на вкладку Клієнти та добавити його. Аналогічно із майстром. Залежно від того, який вид роботи вибрав користувач, то такій роботи буде відповідати певні майстри і запчастини, які також вибираються у полях зі списком. Текстове поле Вартість відображає загальну ціну послуги, яка буде надана. Це поле заблоковано, у нього неможливо вводити якісь дані. Текстові поля «Дата Звернення» та «Дата виконання» призначені для вибору дати. Кнопка «Прийняти замовлення» записує дані, які користувач вибрав і ввів, у відповідну таблицю. Кнопка «Відкрити звіт» закриває форму і відкриває звіт «Звіт по замовленнях». Кнопка «Змінити користувача» завершує роботу із користувацькою формою та переходить до форми авторизації. Вкладки призначенні для відображення даних про замовлення, клієнтів (рис. 2.5.3) чи майстрів (рис. 2.5.4). На кожній вкладці також є свої елементи управління.

Рисунок 2.5.3 - Вкладка “Клієнти”



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

Рисунок 2.5.4 - Вкладка “Майстри”

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



2.6 Конструювання звітів

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

Для створення стандартного звіту або звіту у вільній формі використовуються генератори (конструктори) або майстри звітів.

У даній інформаційній системі подано такі звіти:

Звіт сформований на основі запиту «Звіт» для відображення ведення обліку замовлень для адміністратора або менеджера (рис. 2.6.1).

Рисунок 2.6.1 - Звіт по замовленням

Звіт сформований на основі запиту «Дата» для відображення замовлень, які ще не виконанні (рис. 2.6.2).



Рисунок 2.6.2 - Звіт по невиконанних замовленнях



3. ЗАСТОСУВАННЯ РОЗРОБЛЕНОЇ БАЗИ ДАНИХ

3.1 Робота користувача з базою даних

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

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

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

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

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

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

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

3.2 Результати використання бази даних

Створена база даних відповідає усім вимогам, які були поставлені на етапі проектування бази даних.

Концептуальне і фізичне проектування виконане відповідно до усіх норм та правел проектування.

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

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



ВИСНОВКИ

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

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

У результаті виконання даної роботи було:

досліджено теоретичні джерела по проблемах проектування та розробки баз даних;

розглянуто теоретичний матеріал з питань реляційного підходу до розробки баз даних;

охарактеризовано системи управління базами даних Microsoft Access 2010;

розроблено ER-модель предметної області служби побуту;

визначено імена сутностей і перелік атрибутів предметної області;

перетворено ER-модель предметної області у реляційну модель;

проведено нормалізацію реляційної моделі;

побудовано оптимальну модель предметної області;

створено базу даних у СУБД Microsoft Access 2010;

розроблено різні типи запитів до бази даних;

створено форму з вкладками та багатотабличну форму;

виконане завдання по створенню звіту, відповідно до вимог.

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

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



ПЕРЕЛІК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ

Конноллі Томас, Бегг Каролін. Бази даних. М.: Вільямс, 2003.

Роланд Фред Д. Основні концепції баз даних. М.: Вільямс, 2002.

Тихомиров Ю.В. Microsoft SQL Server 2000: розробка застосувань.- Спб.: БХВ-Петербург, 2000.

Хансен Р., Хансен Дж. Бази даних: розробка і використання: Пер. з англ. М.: БІНОМ, 2000.

Ульман Д., Уидом Д. Проектування баз даних./ К. - Лори.- 2000.- 347 с.

Кузнецов Д. Основы современных баз данных. / Материалы Центра Информационных Технологий МГУ 1997, 300 с.

Дженнингс Р. Использование Microsoft Access 2000 / Вильямс.- 2000 - 1152 с.

Вильям Дж. Пейдж, Использование Oracle 8. Москва-Санкт-Петербург - Киев, Вильямс, 1999,-1024 стр.

Дженнингс Р. Использование Microsoft Access 2000 / Вильямс.- 2000 - 1152 с.

К. Дж. Дейт. Введення в системи баз даних . - М.-С.П.-К: 2001.

Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ.: Уч.пос. - М.: Издательский дом "Вильямс", 2000.- 1120с.

Ю. Бекаревич, Н. Пушкіна. СУБД Access для Windows 2000. Видавнича група BHV. - К: 2000.



Додаток А

ER-діаграма

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

...