- •1 Предметна область
- •1.1 Постановка завдання
- •1.2 Інформаційні потоки
- •1.3 Виробничі функції
- •1.4 Вимоги до апаратного забезпечення
- •2 Побудова концептуальної моделі
- •2.1 Сутності
- •2.2 Зв’язки
- •3 Логічна модель даних
- •3.1 Нормалізація
- •3.2 Правила цілісності
- •3.2.1 Цілісність сутностей
- •3.2.2 Цілісність посилань
- •3.2.3 Цілісність доменів
- •4 Фізичне проектування
- •4.1 Представлення фізичної моделі бази даних
- •Висновки
3.2 Правила цілісності
3.2.1 Цілісність сутностей
Цілісність даних є дуже важливою для будь-якої бази даних, оскільки вона гарантує достовірність інформації, що зберігається в базі.
Цілісність сутностей в даній базі, спроектована таким чином, що в будь який момент часу можна знайти потрібний кортеж, і гарантується, що такий кортеж є унікальним. Наведемо табличку сутностей та первинних ключів:
Таблиця 16. Сутності та первинні ключі
Ім’я сутності |
Первинний ключ |
Staff |
staff_id |
MedicalData |
medical_id |
Departments |
department_name |
Crew |
crew_id |
CrewDetails |
crew_id, staff_id |
Aircraft |
aircraft_serialNumber |
Flights |
flights_id |
Schedule |
schedule_id |
Tickets |
ticket_id |
OrderDetails |
ticket_id, order_id |
Orders |
order_id |
Buyers |
passport |
3.2.2 Цілісність посилань
Цілісність посилань набувається за рахунок використання зовнішніх ключів. Це гарантує неможливість додання працівника не вказавши відділ. Перелічимо сутності та зовнішні ключі, що вони містять:
Таблиця 17. Сутності та зовнішні ключі
Сутність |
Зовнішній ключ |
Staff |
department_name |
MedicalData |
staff_id |
CrewDetail |
staff_id, crew_id |
Aircraft |
crew_id, flights_id |
Schedule |
aircraft_serialNumber, flights_id |
Tickets |
aircraft_serialNumber |
Orders |
staff_id, passport |
OrderDetails |
order_id, ticket_id |
3.2.3 Цілісність доменів
Для запобігання введення недостовірної інформації користувачем було створено домени, що накладають обмеження на типи даних і виступають хорошим механізмом збереження цілісності. В даній інформаційній системі було створено такі домени:
Таблиця 18. Домени та обмеження
Назва домену |
Обмеження |
FLNAME |
Текст довжиною від 1 до 20 символів |
BOOLEAN |
Число рівне 1 або 0 |
CARD |
Текст рівний 16 символам |
DATETIME |
Дата і час |
ADDRESS |
Адреса виду: Індекс, Місто, Вулиця № |
MONEY |
Дійсне 10 знаків до, 2 після коми |
NOMINATION |
Текст довжиною не більше 50 символів |
TEXT |
Текст довжиною не більше 300 символів |
PERSENTS |
Дійсне від 0 до 100 |
UINT |
Ціле, невід’ємне |
PHONE |
Текст довжиною 13 символів |
PASSWORD |
Текст довжиною 40 символів |
4 Фізичне проектування
4.1 Представлення фізичної моделі бази даних
На даному етапі створюються таблиці в такому вигляді, в якому вони будуть представлені в конкретній базі даних.
В ході дослідження предметної області було виділено такі домени:
Таблиця 19. Фізичне представлення доменів
Назва |
Тип даних |
Розмір поля |
FLNAME |
VARCHAR |
20 |
BOOLEAN |
SMALLINT |
Коротке ціле |
CARD |
VARCHAR |
16 |
DATETIME |
TIMESTAMP |
Довгий формат дати |
ADDRESS |
VARCHAR |
100 |
MONEY |
DECIMAL |
Довге дійсне |
NOMINATION |
VARCHAR |
50 |
TEXT |
VARCHAR |
300 |
PERSENTS |
FLOAT |
Дійсне |
UINT |
INTEGER |
Ціле |
PHONE |
VARCHAR |
13 |
PASSWORD |
VARCHAR |
40 |
Перетворимо сутність “Працівники” до фізичного вигляду. Оберемо метод “NULL значень”, та сформуємо структуру таблиці, оскільки був обраний саме цей метод, то всі атрибуту дочірніх сутностей та батьківської сутності переносяться в одну табличку. Також дослідимо зв’язок з сутністю “Відділи”, багато до одного – “Працівники” повинні містити зовнішній ключ “Відділи”
Таблиця 20. Проект таблиці “Торгівельна точка” для фізичної моделі
Назва поля |
Примітки |
Домен |
Код працівника |
Первинний ключ |
INT |
Назва відділу |
Зовнішній ключ |
CHAR |
Ім’я |
|
CHAR |
Прізвище |
|
CHAR |
По батькові |
|
CHAR |
Стать |
|
CHAR |
Стаж роботи |
|
FLOAT |
Зріст |
|
FLOAT |
Наявність дітей |
|
INT |
Зарплата |
|
MONEY |
Чи є керівником |
|
CHAR |
Класифікації літаків |
|
TEXT |
Додаткові мови |
|
TEXT |
Класифікації моторів |
|
TEXT |
Бухгалтерський досвід |
|
CHAR |
Військова служба |
|
CHAR |
Комунікабульність |
|
CHAR |
Перетворимо сутність “Відділи” до фізичного вигляду.
Таблиця 21. Проект таблиці “Відділи ” для фізичної моделі
Назва поля |
Примітки |
Тип даних |
Назва відділу |
Первинний ключ |
CHAR |
Аналогічно до попереднього варіанту з сутністю “Працівники” дослідивши зв’язок сутності “Медичні дані” із сутністю “Працівники” бачимо, що це зв'язок багато до одного, отже маємо:
Таблиця 22. Проект таблиці “Медичні дані” для фізичної моделі
Назва поля |
Примітки |
Тип даних |
Код медданих |
Первинний ключ |
INT |
Код працівника |
Зовнішній ключ |
INT |
Дата |
|
DATE |
Таблиця 23. Проект таблиці “Бригади” для фізичної моделі
Назва поля |
Примітки |
Тип даних |
Код бригади |
Первинний ключ |
INT |
Дата створення |
|
DATE |
Таблиця 24. Проект таблиці “Деталі бригади” для фізичної моделі
Назва поля |
Примітки |
Тип даних |
Код працівника |
Зовнішній ключ, первинний ключ |
INT |
Код бригади |
Зовнішній ключ, Первинний ключ |
INT |
Таблиця 25. Проект таблиці “Літаки” для фізичної моделі
Назва поля |
Примітки |
Тип даних |
Код літака |
Первинний ключ |
INT |
Код бригади |
Зовнішній ключ |
INT |
Код рейсу |
Зовнішній ключ |
INT |
Модель |
|
CHAR |
Місця |
|
INT |
Статус |
|
CHAR |
Таблиця 26. Проект таблиці “Рейси” для фізичної моделі
Назва поля |
Примітки |
Тип даних |
Код рейсу |
Первинний ключ. |
INT |
Точка відправлення |
|
CHAR |
Точка прильоту |
|
CHAR |
Вартість квитка |
|
MONEY |
Час перельоту |
|
DATE |
Таблиця 27. Проект таблиці “Розклад” для фізичної моделі
Назва поля |
Примітки |
Тип даних |
Код розкладу |
Первинний ключ |
INT |
Код літака |
Зовнішній ключ |
INT |
Код рейсу |
Зовнішній ключ |
INT |
Час вильоту |
|
DATE |
Таблиця 28. Проект таблиці “Білети” для фізичної моделі
Назва поля |
Примітки |
Тип даних |
Код білету |
Первинний ключ |
INT |
Код літака |
Зовнішній ключ |
INT |
Таблиця 29. Проект таблиці “Клієнти” для фізичної моделі
Назва поля |
Примітки |
Тип даних |
Паспорт |
Первинний ключ |
CHAR |
Ім’я |
|
CHAR |
Прізвище |
|
CHAR |
По батькові |
|
CHAR |
Таблиця 30. Проект таблиці “Замовлення” для фізичної моделі
Назва поля |
Примітки |
Тип даних |
Код замовлення |
Первинний ключ |
INT |
Паспорт |
Зовнішній ключ |
CHAR |
Код працівника |
Зовнішній ключ |
INT |
Дата покупки |
|
DATE |
Статус покупки |
|
CHAR |
Таблиця 31. Проект таблиці “Деталі замовлення” для фізичної моделі
Назва поля |
Примітки |
Тип даних |
Код замовлення |
Зовнішній ключ, первинний ключ |
INT |
Код білету |
Зовнішній ключ, первинний ключ |
INT |