3 Розробка додатку

База даних створена у середовищі СУБД Access 2003.

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

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

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

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

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

• кожне поле має бути пов'язане з темою таблиці;

• не рекомендується включати до таблиці дані, що є резуль­татом виразу;

• у таблиці має бути вся необхідна інформація;

• інформацію варто розбивати на найменші логічні одиниці.

З тим, щоб СУБД могла зв'язати дані з різних таблиць, наприклад дані про дільницю та результати голосування на ній, кожна таблиця повинна містити поле чи набір полів, що задаватимуть індивідуальне значення кожного запису в таблиці. Таке поле чи набір полів називають основним ключем.

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

Рисунок 3.1 – Таблиці створюваної бази даних

• Таблиця «Блюда»

Спочатку треба визначитись які саме дані буде мати таблиця. Таблиця створюється у режимі конструктора. У стовпці «Имя поля» вказується унікальне ім’я кожного необхідного нам поля. Бажано щоб ім’я не співпадали навіть у різних таблицях. Перше поле – «код_блюда». Присвоюємо тип даних лічильник, та у розділі «Индексированное поле» обираємо «Да(совпадения не допускаются)». Це означає що кожна нова страва буде мати свій унікальний номер-код. Це дозволяє нам уникнути конфлікту коли б дві різні страви мали б один код. Наступний атрибут – «код_раздела». Формат – «Числовой», поле обов’язкові, бо страва не може не мати розділу. Було обрано саме такий формат даних, бо цей атрибут розширюється в іншій таблиці. Таким же чином робляться й наступні поля.

Рисунок 3.2 – Таблиця « Блюда»

Таким же чином проектуємо наступні таблиці:

• Таблиця «Заказ»

Містить інформацію про закази

• Таблиця «Ингрдиенты»

Містить інформацію про інгредієнти що входять до складу страв.

• Таблиця «Состав»

Містить інформацію про рецепти .

• Таблиця «Раздел»

Містить інформацію про розділи.

Генерація схеми бази даних.

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

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

1. «Сервис»  «Схема данных».

2. У вікні «Добавление таблицы» за допомогою кнопки «Добавить» послідовно обираємо всі таблиці, між якими встановлюється зв’язок  закрити вікно «Добавление таблицы».

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

4. У вікні «Изменение связей» встановлюємо прапорець «Обеспечение целостности даннях», «Каскадное обновление связанных полей» та «Каскадное удаление связанных записей»  «Создать».

У вікні «Схема даннях» з’являється лінія зв’язку між відповідними полями, звичайно, 1:М або 1:1.

Рисунок 3.3 – Схема даних

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

Рисунок 3.4– Форми бази даних

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

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

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

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

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

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

Найпростіше форми створювати у режимі майстра за допомогою простого редагування.

• Форма «Рецепты»

Спочатку треба чітко визначитись для чого нам буде потрібна форма та що вона буде відображати. Наприклад, форма «рецепты» дозволяє проглядати рецепт вибраної страви. Реалізується завдяки підлеглої форми та запиту «рецепты1».

Рисунок 3.5 – Форма «Рецепт»

Для створення головної форми треба в майстрі створення форм обрати потрібну нам таблицю. Обираємо таблицю «блюда». Обираємо в ній те поле, яке буде визначатися критерії пошуку та підбору. Це поле: код_блюда. Усі інші поля форма буде генерувати сама. Далі треба перетворити поле у поле зі списком. Це робиться через контекстне меню. Обирається єлемень «Преобразовать элемент в» та у випадаючому меню обирається «Поле со списком». Перетворюємо таким чином усі поля. Набагато зручніше було б обирати певні назви аніж їх коди, тому треба щоб у списку відображалися самі назви. У контекстному меню «Свойства» елемента обирається закладень «Данные» та у полі «Источник строк» треба натиснути на кнопку. Відкривається вікно конструктора запитів. У цьому вікні необхідно обрати таблицю, в якій зазначені елементи обраного поля зі списку. Наприклад, обрали поле «код_блюда», тому таблицю треба обрати «блюда». Обираємо поля «блюда» та «код_блюда» та закриваємо запит. Обирається закладень «Макет», та у графі «Число столбцов» треба зазначити «2», бо підключили 2 стовпці. У графі «Ширина стоблцов» треба зазначити «0;2,54», таким чином виділяємо для першого стовпця «код_блюда» 0 см (його буде не видно), а на поле із назвою зазначили 2,54 см. Те ж саме робиться із наступними стовпцями.

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

Додаємо необхідні таблиці та бачимо що одразу ж відображаються звязки між ними. Перетягуємо необхідні стовпці. Треба зазначити крітерії відбору. Наприклад, змінемо крітерій відбору у строчці «Условие отбора» у стовпці «Блюдо», що вітягли із таблиці «Блюда». Треба зазначити умову таку, щоб цей стовпець брав дані із зробленої нами форми. У конструкторі треба обрати зі списку форм потрібну. Обирається «Рецепт». Справа відображається список усіх полей форми. Обирається «код_блюда». Таким чином ми привязали запит до форми. Запит зберігається за потрібним ім’ям.

У головній формі на панелі інструментів обирається «подчинённая форма/отчёт» та виділяється область, на якій саме буде розміщено нову підлеглу форму. Зі списку обираємо запит, який автоматично збережеться як підлегла форма.

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

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

• Форма «заказ»

Форма дозволяє додавати, видаляти та виводити записи до заказів.

Робиться майстром із таблиці «Заказ». Для додавання можна вставити кнопку та при виборі її функції обрати «Добавление записи».

• Форма «Выбор заказа»

Форма дозволяє вибрати певний заказ та вивести звіт із заказаними блюдами, вартістю блюд окремо та взагалі.

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

Рисунок 3.6 – Звіти бази даних

• Звіт «Меню»

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

Рисунок 3.7 – звіт «Меню»

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

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

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

Рисунок 3.8 – Запити бази даних

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

• Запит «запрос1»

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

• Запит «Просмотр ингредиентов»

Запит для виведення інформації щодо складу певної страви.

• Запит «рецепты1»

Запит створено для виведення підлеглої форми. Виводить назву інгредієнтів та їх кількість для приготування певної страви.

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

Кнопкова форма є не що інше, як Меню для роботи в базі даних. У меню може бути декілька вкладених підменю.

При створенні бази даних за допомогою майстра автоматично створюється кнопкова форма, що допомагає переміщатися по базі даних. На кнопкову панель поміщаються кнопки, при натисканні яких відкриваються форми або звіти (або відкриваються інші кнопкові форми, за допомогою яких відкриваються інші форми або звіти), здійснюється вихід з Microsoft Access або змінюється сама кнопкова форма. При створенні кнопкової форми за допомогою диспетчера кнопкових форм Microsoft Access створює таблицю «Элементы кнопочной формы», яка містить опис кнопок, що виводяться у формі, і виконуваних ними дій.

Дана кнопкова форма є стартовою – відкривається за замовчуванням при запуску бази даних.

Рисунок 3.9 – Кнопкова форма