align="justify"> 3. Створення реляційної бази даних у середовищі СУБД Access
Реляційна модель буде формуватися з ER-моделі шляхом перетворення класів об'єктів і процесів в самостійні відносини - таблиці. Даталогіческая модель реляційної бази даних визначається сукупністю логічно пов'язаних реляційних таблиць.
Логічні зв'язки між таблицями відповідають структурним зв'язкам між інформаційними об'єктами і встановлюються на рівні ключів зв'язку (зовнішнім ключем підлеглої таблиці і первинним ключем головної таблиці).
У результаті моделювання отримана реляційна модель наступного виду:
. Товари (ШтрихКод, НазвТов, Постачальник, Ціна, НаСкладе);
. Постачальники (КодПост, НазвПост, Адреса, Фам_дірект, Телефон);
. Каса (Кассір1 (Іванова А), Кассір2 (Петров І), Сума);
. Тимчасова (ШтрихКод, НазвТов, Ціна, Кількість, К_оплате, Готівкою, Здача);
. Журнал_Операціі (НомерЗапісі, ШтрихКод, Операція, Дата).
Створимо таблиці класів об'єктів з відповідними типами даних і властивостями полів. Структура представлена ??на малюнку 3.
Рисунок 3 - Структура таблиць з типами даних
Таким чином, реалізована фізична модель в СУБД Access.
За допомогою інструментальних засобів у вікні Схема даних встановлюються зв'язки між полями таблиць (див. малюнок 4).
Малюнок 4 - Схема даних
Спосіб зміни зв'язку між таблицями представлений на малюнку 5.
Малюнок 5 - Установка зв'язку «один-до-багатьох»
Схема даних додатків представлена ??на малюнках Б.1-Б.4.
4. Проектування і розробка програми касира
Для проектування та розробки додатку діаграми варіантів використання недостатньо, можуть знадобитися більш конкретні деталі. Для цього необхідно скласти словесний алгоритм потоку подій для користувача при виконанні користувальницької завдання, а так само словесний алгоритм потоку подій для програмного забезпечення.
Словесний алгоритм потоку подій для касира буде виглядати так:
1. Одержати товар;
2. Викликати необхідну програму;
. Ввести штрих код - з'являється форма даних товару з таблиці Товари;
. Підрахувати кількість товару;
. При внесенні кількості товару провести розрахунок до оплати;
. Отримати гроші від клієнта, перерахувати, дати здачу;
. Зафіксувати операцію в програмі;
. Віддати чек клієнту;
. Вийти з програми.
Далі складемо словесний алгоритм потоку подій для програмного забезпечення, який буде виглядати так:
1. Запускається програма. Відкривається діалогове вікно «Введіть штрих-код товару»;
2. Викликаються дані про товар в таблицю Тимчасова;
. Формою виводяться дані товару з таблиці Тимчасова;
4. Вводяться дані про кількість товару, що продається;
5. Розраховується сума до оплати;
. Розраховується здача;
. Оновлюються дані в таблиці Тимчасова;
. Оновлюється кількість товару на складі;
. Дані про проведену операцію фіксуються в журналі операцій;
. Оновлюється сума на касі;
. Видаляються всі записи з таблиці Тимчасова;
. Друкується чек;
. Відкривається початкова форма.
Основний потік подій описує нормальний хід подій. При розробці програми операції основного потоку подій реалізуються запитами (на вибірку, оновлення, додавання, видалення) і формами.
Зупинимося докладніше на запитах, за допомогою яких реалізуються операції основного потоку подій. Їх в базі даних досить багато, тому опишемо найцікавіші з них.
Перша операція, на яку слід докладніше розглянути це операція, яка змінює кількість товару на складі після покупки. Ця операція здійснюється за допомогою запиту на оновлення. У конструкторі запиту, в полі «Умова», через будівник виразів записується команда: [Товари]! [НаСкладе] - [Тимчасова]! [Кількість]. Таким чином, кількість купленого товару віднімається з кількості товару, що знаходиться в таблиці Товари.
Також можна розглянути операцію, яка оновлює ...
