2.7 Аналіз концептуальних вимог

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

• Максимальна реалізація набору сутностей із мінімальними порушеннями нормальних форм;

• Забезпечення інтерактивного введення даних відповідно логіці діяльності точки продажу;

• Забезпечення формування звітності, в т. ч. фінансової;

• Якомога коротший ланцюжок дій при основних задачах бази даних.

Проаналізуємо ці вимоги.

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

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

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

Окремо слід сказати про деякі обмеження, які накладаються на форми. Проаналізувавши побудовану нами схему сутностей, неважко помітити, що основними сутностями, до якої сходяться дані з усіх інших таблиць – є Замовлення, Продажі, Підписки та Додаткові послуги. Для того, щоб пришвидшити введення даних, краще за все базові дані виносити не в безпосередньо в текстовій формі, в які треба заносити дані «з нуля», а за допомогою спеціальних елементів керування (наприклад, комбобоксів). Таким чином, дані, що дублюються, можна вносити в автоматичному режимі – за допомогою скриптів, і одночасно виконувати їх перевірку, що додатково підвищить цілісність бази даних. Таким чином, користувацький інтерфейс слід будувати на основі ієрархічної структури форм, яка будуватиметься наступним чином:

• Рівень 1: Кнопочна форма;

• Рівень 2: Навігаційна форма;

• Рівень 3: Форма для «основної діяльності»;

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

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

2.8 Побудова концептуальної моделі

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

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

• Видання;

• Клієнти;

• Кіоски;

• Продавці.

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

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

Рисунок 2.8 - Схема ієрархії першого рівня

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

Рисунок 2.9 - Схема виклику форм другого та третього порядку

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

Рисунок 2.10 - Агрегатна форма

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

Звітність реалізується на базі параметричних запитів і запитів на вибірку, які використовуються скриптами на Visual Basic for Applications. Більшість із них реалізується звичайним SQL-виразом, як показано в

додатку …

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

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

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

Таким чином, поставлений нами концепт бази, із побудованим інтуїтивним інтерфейсом та розвиненою системою звітності, можна вважати накресленим, і приступити до власне реалізації БД.

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

Тепер нам необхідно просто його занести в обробник кнопки On Click.

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

Другим типом макросів є безпосередньо скрипти, які пишуться в модулях на Visual Basic for Applications. Яскравим прикладом таких є автоматичне введення даних. Ця форма уже демонструвалась вище в додатку Д. Вона продубльована просто для зручності. Як видно, вона будується навколо спискового елемента керування Індекс, який, в свою чергу, контролюють поле (Назва видання), і обидві, в свою чергу, контролює поле Тип видання.

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

Звернімо увагу, на відміну від більшості вбудованих запитів, які зазвичай застосовуються в таких елементах, цей – параметричний. Щоб упевнитись в тому, що він завжди міститиме актуальні дані, необхідний пов‘язаний скрипт в обробнику подій On Change для поля Назва, який за даною назвою буде визначати вже індекс. В обох випадках скрипти прості і є простим звертанням до відповідного параметричного запиту. Скрипт для визначення вмісту «пов‘язаного» поля наведений в додатку Е.

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

Аналогічно, параметричні запити використовуються для фінансових розрахунків. Візьмемо ту саму форму, що наведена в додатку Д. Нам відомо, що вартість підписки повинна розраховуватись, виходячи із кількості місяців та кількості примірників, яку хоче отримувати замовник. Маємо наступний скрипт фінансових розрахунків, який наведений в додатку Е.

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

І окремо слід сказати про автоматично генеровані скрипти фінансових підсумків, які були використані при формуванні деяких звітів в даній базі даних. Вони заносяться автоматично в додаткові поля, які створюються за допомогою «майстра звітів»:

Рисунок 2.11 - Діалог формування автоматизованих підсумкових скриптів

Результат такої настройки виглядає наступним чином (в режимі конструктора звітів):

Рисунок 2.12 - Автоматично згенеровані скрипти

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