Проектування нормалізованих відносин
Поскільки аналіз предметної області був доволі детальним, плюс в попередньому розділі було, можемо одразу приступити до виокремлення сутностей із універсального відношення:
R(Номер кіоска; Адреса кіоска; Категорія видання; Індекс видання; Назва видання; Обсяг реклами; Період видання; Частота виходу; Роздрібна вартість; Вартість за підпискою; Українське/закордонне; Опис видання; П. І. Б. продавця; Контактний телефон; Дата чергування; П. І. Б. клієнта; Контактний телефон клієнта; Адреса клієнта; Підписка; Постійний клієнт; Поточна операційна дата; Кількість проданих примірників; Вартість продажу; Термін відкладення продажу; Назва додаткової послуги; Обсяг виручки за послугу; Початок підписки; Кінець підписки; Вартість підписки; Адреса доставки; Ким підписано)
Розглянемо три форми нормалізації і застосуємо їх до універсального відношення. Відношення називається приведеним до першої нормальної форми (1НФ), якщо всі його атрибути прості. Як бачимо всі атрибути даного універсального відношення прості, тобто атомарні, нероздільні. Отже відношення знаходиться у першій нормальній формі.
Відношення знаходиться в другій нормальній формі (2НФ), якщо воно знаходиться в 1НФ і кожний не ключовий атрибут функціонально повно залежить від складеного ключа.
Отже, почергово розглянемо кожен об‘єкт предметної області, підберемо для нього атрибути і проведемо нормалізацію методом декомпозиції.
Метод декомпозиції є одним з найбільш зручних методів проектування невеликих баз даних. Для нормалізації відношення методом декомпозиції потрібно виконати наступні дії:
1) Розробка універсального відношення для бази даних;
2) Визначення всіх функціональних залежностей, які присутні між атрибутами універсального відношення;
3) Визначення того, чи знаходиться розглянуте відношення в НФБК. Якщо так, проектування закінчується; якщо ні - відношення розбивається на два відношення;
4) Повторення кроків 2 та 3 для кожного нового відношення, отриманого в результаті декомпозиції.
Одразу виокремимо очевидні сутності.
R1(Шифр; Номер кіоску, Адреса кіоску)
Шифр необхідний, тому що на одному і тому ж відділенні пошти можуть бути зав‘язані декілька кіосків.
R2 (Шифр клієнта, П. І. Б.; Контактний телефон; Адреса; Є підписником; Є постійним клієнтом)
Далі необхідний перелік працівників та чергування:
R3 (Шифр, П. І. Б.; Контактний телефон)
R4 (Шифр; Номер кіоска; Дата чергування; П. І. Б. працівника)
Сутність R4 за великим рахунком в даній базі даних не потрібна, адже вона не несе ніяких унікальних даних. Однак вона суттєва для побудови користувацького інтерфейса, а тому на таке порушення нормалізації йти доцільно.
Наступною необхідною сутністю буде замовлення кіоском певної кількості примірників друкованих видань.
R5 (Шифр; Індекс видання; Кількість примірників; Номер кіоска; Дата доставки; Чи є це тестовим тиражем)
Параметр Тестовий тираж введено з метою подальшого ведення аналітики по конкретному кіоску. Безпосередньо зараз він задіяний не буде, але для розвитку на перспективу із розгорнутою статистикою попиту, він суттєвий.
Поскільки у нас з‘явився уже параметр індекса видання, слід ввести і цю сутність:
R6 (Шифр; Категорія; Індекс; Назва; Обсяг реклами; Період видання; Частота виходу; Роздрібна вартість; Вартість за підпискою; Чи є українським; Опис)
Відповідно, необхідні сутності для забезпечення основної функції - реалізації друкованих видань. Для цього потрібні чотири сутності: підписки, продажі, відкладені продажі та додаткові послуги. Відповідно опишемо їх в термінах відношень:
R7 (Шифр; П. І. Б. підписника; Індекс видання; Початок підписки; Кінець підписки; Вартість; Адреса доставки; Дата оформлення; Кіоск; Черговий продавець)
R8 (Шифр; Операційна дата; Номер кіоска; Індекс видання; Кількість примірників; Виручка)
R9 (Шифр; П. І. Б. клієнта; Індекс видання; Термін відкладення; Кількість примірників; Сума покупки)
У відкладених продажах не вказується номер кіоску. Згідно прейскуранту, відкладені продажі можуть бути оплачені у будь-якому відділенні.
R10 (Шифр; Номер кіоска; Назва послуги; Операційна дата; Обсяг виручки)
Таким чином, в процесі нормалізації сформовано перелік сутностей, які становитимуть основу даної бази даних, і в подальшому перетворяться на таблиці. Ось їх перелік:
Кіоск;
Клієнти;
Працівники;
Чергування;
Замовлення;
Видання;
Підписки;
Продажі;
Відкладені продажі;
Додаткові послуги.
Маючи такий перелік, можна говорити, що основна вимога до технічного завдання виконана, і слід переходити до наступної фази розробки.
Загальні поняття і визначення цілісності
Для забезпечення цілісності бази даних необхідно встановити зв‘язки між сутностями. Тоді при введенні даних не буде виникати проблема помилок, як чисто технічних, так і при узгодженні однакових полів в різних функціях. Для цього складемо схему взаємозв‘язків між різними сутностями на основі табличних викладок.
Рисунок 2.6 - Схема бази даних мережі магазинів «Преса» у Вінниці
Основні типи даних
Оскільки більшість даних, які використовуються в даній базі даних, є текстовими, саме рядки і є основним типом даних, з яким доведеться працювати користувачу.
Для ідентифікаторів використовуються три основних типи даних:
Текстовий;
Числовий;
Грошовий.
Текстовий варіант використовується для всіх полів у даній базі даних, а також для маніпуляцій із ними в запитах і скриптах. Зокрема, на основі саме текстових полів здійснюється звертання до параметричних запитів.
Для решти ідентифікаторів використовуються числові типи даних, оскільки вони компактніші, і цілісність зв‘язків працює на базі саме числових співставлень.
Особливе місце в даній базі даних займають поля із грошовим типом даних. Вони використовуються не лише для вказання таких показників як вартість підписки, чи роздрібна вартість, а й використовується для обчислення загальних сум платежів та підсумкових фінансових звітів.
В деяких сутностях необхідне використання дат. Використовується стандартний тип даних Date, який входить до складу VBA, і має відповідний діалоговий елемент для полегшення введення даних у формі.
Рисунок 2.7 - Діалоговий елемент, що відповідає типу даних Date
Також, було використано тип Memo там, де необхідно було робити додаткові примітки (наприклад, в таблиці Видів робіт), які неможливо класифікувати. Це було викликано тим, що цей тип даних фактично безмежний, а тому користувач може вільно ввести будь-яку кількість додаткових даних. В даній БД він застосовується для розміщення короткої довідки про друкований орган (журнал чи газету).