3.2. Побудова концептуальної моделі продажу товарів для продажу
На основі проведеного аналізу предметної області була побудована концептуальна модель з використанням мови ER–моделювання. Концептуальна модель наведена на наступному рисунку.
4. Логічне та фізичне проектування бази даних
Завдання цього етапу полягає у проведенні логічного та фізичного проектування бази даних.
Логічне проектування — це розробка логічної структури системи баз даних без прив'язки до конкретної СУБД, структур збереження, методам доступу і т.д..
Фізичне проектування – це проект системи бази даних для конкретної СКБД. Під час виконання даного етапу модель сутностей і зв'язків перетворюється в схему бази даних і специфікації позамашинного збереження.
4.1. Логічне проектування
У якості логічній моделі бази даних була обрана реляційна модель, оскільки саме реляційна модель використовується у більшості розвинених СКБД.
Для перетворення концептуальної моделі, представленої у вигляді мови ER–моделювання, у реляційну модель, був використаний наступний алгоритм.
Крок 1. Перетворення сутностей у таблиці. Кожна сутність перетворюється у таблицю. Ім’я сутності представляється у вигляді семантично осмисленого імені у латинському алфавіті.
Крок 2. Перетворення атрибутів у стовпці. Кожний атрибут перетвориться в стовпець. Ім’я атрибуту представляється у вигляді семантично осмисленого імені у латинському алфавіті. У цей момент уточнюється формат представлення значень стовпця. Факультативні атрибути стають NULL-стовпцями. Обов'язкові атрибути стають NOT NULL-стовпцями.
Крок 3. Подання унікальних ідентифікаторів ключами таблиць. Складові унікального ідентифікатора сутності стають первинним ключем таблиці. Нагадаємо, що сутність може мати більш ніж один унікальний ідентифікатор Тому вибирається той, котрий використовується найбільше часто. Всі інші унікальні ідентифікатори приймають обмеження цілісності UNIQUE NOT та NOT NULL.
Крок 4. Перетворення зв'язків багато-до-одного й один-до-одного в зовнішні ключі. Зв'язки типу багато-до-одного й один-до-одного породжують зовнішні ключі. Інакше кажучи, необхідно взяти унікальні ідентифікатори кожної сутності, розташованої в закінчення зв'язку зі ступенем один, і ввести його у відношення, розташоване з боку зв'язку "багато" як стовпці. Факультативним зв'язкам відповідають NULL-стовпці. Обов'язковим зв'язкам відповідають NOT NULL-стовпці.
Крок 5. Введення спеціальних первинних ключів. Для більш адекватного відображення логічного проекту бази даних у фізичний, вводимо у всі таблиці один спеціальний стовпець з обмеженням цілісності первинного ключа. Всі ті стовпці, які мають властивість первинного ключа згідно з концептуальною моделлю, набувають обмеження цілісності UNIQUE та NOT NULL.
Рис. Концептуальна ER-модель продажу товарів
Сутність може унікально ідентифікуватися комбінацією атрибутів і/або зв'язків. При використанні в ідентифікаторі сутності зв'язку до складу первинного ключа включається зовнішній ключ, який посилається на ту таблицю, з якою пов’язаний той або інший зв’язок.
Повна логічна база даних на основі концептуальної моделі з урахуванням обмежень цілісності та наведеного вище алгоритму детально представлена в наступних таблицях.
Таблиця 1. Відношення сутності Товар
TOVAR
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
TovNum |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
Name |
строка |
15 |
Назва товару |
Унікальний, обов’язковий |
VudNum |
ціле число |
10 |
Зв’язок з видом товару |
Зовнішній ключ, що посилається на первинний ключ відношення VUD. Обов’язковий |
OdunNum |
ціле число |
10 |
Зв’язок з одиницею вимірювання |
Зовнішній ключ, що посилається на первинний ключ відношення ODUN. Обов’язковий |
NazNum |
ціле число |
10 |
Зв’язок з призначенням товару |
Зовнішній ключ, що посилається на первинний ключ відношення NAZNACH. Обов’язковий |
ProizNum |
ціле число |
10 |
Зв’язок з виробником товару |
Зовнішній ключ, що посилається на первинний ключ відношення PROIZVOD. Обов’язковий |
PostNum |
ціле число |
10 |
Зв’язок з постачальником товару |
Зовнішній ключ, що посилається на первинний ключ відношення POSTACH. Обов’язковий |
Misce |
строка |
20 |
Змістовний опис місця знаходження на полицях |
Факультативний |
Cina |
Число |
3,3 |
Ціна товару |
Обов’язковий |
Таблиця 2. Відношення сутності Вид
VUD
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
VudNum |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
Name |
строка |
15 |
Назва виду товару |
Унікальний, обов’язковий |
Opus |
строка |
40 |
Змістовний опис |
Факультативний |
Таблиця 3. Відношення сутності Виробник
PROIZVOD
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
ProizNum |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
Name |
строка |
15 |
Назва виробника |
Унікальний, обов’язковий |
Strana |
строка |
15 |
Країна виробник |
Обов’язковий |
Таблиця 4. Відношення сутності Постачальник
POSTACH
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
PostNum |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
Name |
строка |
15 |
Назва постачальника |
Унікальний, обов’язковий |
RR |
ціле число |
10 |
Розрахунковий рахунок |
Обов’язковий |
UrAdr |
строка |
40 |
Юридична адреса постачальника |
Обов’язковий |
FizAdr |
строка |
40 |
Фізична адреса постачальника |
Обов’язковий |
Таблиця 5. Відношення сутності Покупець
POKUP
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
PokNum |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
Name |
строка |
15 |
Призвище покупця |
Унікальний, обов’язковий |
Tel |
ціле число |
|
Телефон покупця |
Унікальний, обов’язковий |
Таблиця 6. Відношення сутності Продавець
PROD
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
ProdNum |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
Name |
строка |
15 |
Призвище продавця |
Унікальний, обов’язковий |
Tel |
ціле число |
10 |
Телефон продавця |
Унікальний, обов’язковий |
Pasport |
строка |
8 |
Паспортні дані |
Унікальний, обов’язковий |
Adres |
строка |
25 |
Адреса продавця |
Обов’язковий |
Таблиця 7. Відношення сутності Звіт
ZVIT
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
ZvNum |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
Date |
дата |
|
Дата проданного товару |
обов’язковий |
PokNum |
ціле число |
10 |
Зв’язок з покупцем |
Зовнішній ключ, що посилається на первинний ключ відношення POKUP. Обов’язковий |
TovNum |
строка |
40 |
Зв’язок з товаром |
Зовнішній ключ, що посилається на первинний ключ відношення TOVAR. Обов’язковий |
Kol |
ціле число |
10 |
Кількість купленого товару |
обов’язковий |
Sum |
число |
(3,3) |
Сума купленного товару |
обов’язковий |
ProdNum |
Ціле число |
10 |
Зв’язок зі спеціальністю |
Зовнішній ключ, що посилається на первинний ключ відношення PROD. Обов’язковий |