
- •Стратегія автоматизації предметної області
- •Загальні положення
- •Мета, цілі та задачі створення бази даних
- •Вимоги до інформаційного забезпечення
- •Аналіз предметної області
- •Загальні положення системного аналізу по
- •Загальні положення діяльності кас продажу авіаквитків
- •Системний аналіз предметної області
- •Сутність Політ
- •Сутність Аеропорт
- •Сутність Авіалайнер
- •Сутність Місце
- •Сутність Компанія
- •Сутність Варіант авіалайнера
- •Сутність Квиток
- •Сутність Клієнт
- •Сутність Електронний квиток
- •Інформаційно-довідкові задачі
- •Концептуальне моделювання предметної області
- •Теоретичні положення концептуального моделювання
- •Мова er – моделювання по
- •Побудова концептуальної моделі авіакас
- •Логічне та фізичне проектування бази даних
- •Логічне проектування
- •Фізичне проектування
- •Скрипти створення бази даних
- •Інформаційно-пошукові запити
- •Висновки
Побудова концептуальної моделі авіакас
На основі проведеного аналізу предметної області була побудована концептуальна модель з використанням мови ER–моделювання. Концептуальна модель наведена на наступному рисунку. Дамо декілька зауважень:
По–перше, ця модель не містить опису атрибутів сутностей у зв’язку з відсутністю місця для їх зображення. Передбачається, що атрибути сутностей разом з їх властивостями (бізнес–правилами) детально описані на етапі аналізу.
По–друге, мова ER–моделювання не передбачає детального представлення інформаційно–довідкових задач. Ми припускаємо, що вони мають звичайний текстовий опис, який представлений на етапі аналізу.
І, по-третє, наша концептуальна модель не містить інших складових, а саме, докладний і строгий опис сховищ даних, та детальний опис потоків даних. Це не було зроблено, так як опис цих складових концептуальної моделі виходить за рамки курсової роботи.
Логічне та фізичне проектування бази даних
Завдання цього етапу полягає у проведенні логічного та фізичного проектування бази даних.
Логічне проектування — це розробка логічної структури системи баз даних без прив'язки до конкретної СУБД, структур збереження, методам доступу і т.д..
Фізичне проектування – це проект системи бази даних для конкретної СКБД. Під час виконання даного етапу модель сутностей і зв'язків перетворюється в схему бази даних і специфікації поза машинного збереження.
Логічне проектування
У якості логічній моделі бази даних була обрана реляційна модель, оскільки саме реляційна модель використовується у більшості розвинених СКБД.
Для перетворення концептуальної моделі, представленої у вигляді мови ER–моделювання, у реляційну модель, був використаний наступний алгоритм.
Крок 1. Перетворення сутностей у таблиці. Кожна сутність перетворюється у таблицю. Ім’я сутності представляється у вигляді семантично осмисленого імені у латинському алфавіті.
Крок 2. Перетворення атрибутів у стовпці. Кожний атрибут перетвориться в стовпець. Ім’я атрибуту представляється у вигляді семантично осмисленого імені у латинському алфавіті. У цей момент уточнюється формат представлення значень стовпця. Факультативні атрибути стають NULL-стовпцями. Обов'язкові атрибути стають NOT NULL-стовпцями.
Крок 3. Подання унікальних ідентифікаторів ключами таблиць. Складові унікального ідентифікатора сутності стають первинним ключем таблиці. Нагадаємо, що сутність може мати більш ніж один унікальний ідентифікатор Тому вибирається той, котрий використовується найбільше часто. Всі інші унікальні ідентифікатори приймають обмеження цілісності UNIQUE NOT та NOT NULL. Сутність може унікально ідентифікуватися комбінацією атрибутів і/або зв'язків. При використанні в ідентифікаторі сутності зв'язку до складу первинного ключа включається зовнішній ключ, який посилається на ту таблицю, з якою пов’язаний той або інший зв’язок.
Крок 4. Перетворення зв'язків багато-до-одного й один-до-одного в зовнішні ключі. Зв'язки типу багато-до-одного й один-до-одного породжують зовнішні ключі. Інакше кажучи, необхідно взяти унікальні ідентифікатори кожної сутності, розташованої в закінчення зв'язку зі ступенем один, і ввести його у відношення, розташоване з боку зв'язку "багато" як стовпці. Факультативним зв'язкам відповідають NULL-стовпці. Обов'язковим зв'язкам відповідають NOT NULL-стовпці.
Рис. Концептуальна ER-модель авіакас
Крок 5. Введення спеціальних первинних ключів. Для більш адекватного відображення логічного проекту бази даних у фізичний, вводимо у всі таблиці один спеціальний стовпець з обмеженням цілісності первинного ключа. Всі ті стовпці, які мають властивість первинного ключа згідно з концептуальною моделлю, набувають обмеження цілісності UNIQUE та NOTNULL.
Повна логічна база даних на основі концептуальної моделі з урахуванням обмежень цілісності та наведеного вище алгоритму детально представлена в наступних таблицях.
Таблиця 1. Відношення сутності Політ
Політ (Flight)
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
FliID |
Ціле |
10 |
Унікальний ID |
Первинний ключ |
BeginTime |
Дата |
|
Час зльоту |
Обов’язковий |
EndTime |
Дата |
|
Час посадки |
Обов’язковий |
BeginPosition |
Ціле |
7 |
Початковий аеропорт |
Обов’язковий |
EndPosition |
Ціле |
7 |
Кінцевий аеропорт |
Обов’язковий |
AirFK |
Ціле |
7 |
Зв’язок з авіалайнером |
Обов’язковий |
SeaFK |
Ціле |
7 |
Зв’язок з місцями |
Обов’язковий |
ComFK |
Ціле |
7 |
Зв’язок з компаніями |
Обов’язковий |
Таблиця 2. Відношення сутності Аеропорт
Аеропорт (Airport)
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
AirID |
Ціле |
7 |
Унікальний ID |
Первинний ключ |
Name |
Текст |
30 |
Назва аеропорту |
Обов’язковий |
Country |
Текст |
30 |
Країна, де знаходиться аеропорт |
Обов’язковий |
City |
Текст |
30 |
Місто, де знаходиться аеропорт |
Обов’язковий |
Address |
Текст |
50 |
Адреса аеропорту |
Обов’язковий |
Fax |
Текст |
20 |
Факс |
Обов’язковий |
Phone |
Текст |
20 |
Телефон |
Обов’язковий |
HomePage |
Текст |
30 |
Домашня сторінка |
Обов’язковий |
Обмеження цілісності таблиці |
UNIQUE(Name, Country, City) |
Таблиця 3. Відношення сутності Авіалайнер
Авіалайнер (Airliner)
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
AirID |
Ціле |
7 |
Унікальний ID |
Первинний ключ |
Num |
Текст |
10 |
Номер борту літака |
Обов’язковий |
Name |
Текст |
10 |
Назва літака |
Обов’язковий |
VarFK |
Ціле |
7 |
Зв’язок з варіантом цісць |
Обов’язковий |
Обмеження цілісності таблиці |
UNIQUE(Number) |
Таблиця 4. Відношення сутності Місце
Місце (Seat)
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
SeatID |
Ціле |
7 |
Унікальний ID |
Первинний ключ |
SoldFCS |
Ціле |
3 |
Продано місць першого класу |
Обов’язковий |
SoldBCS |
Ціле |
3 |
Продано місць бізнес класу |
Обов’язковий |
SoldECS |
Ціле |
3 |
Продано місць економ класу |
Обов’язковий |
Обмеження цілісності таблиці |
UNIQUE(SoldFCS, SoldBCS, SoldECS) |
Таблиця 5. Відношення сутності Компанія
Компанія (Company)
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
ComID |
Ціле |
7 |
Унікальний ID |
Первинний ключ |
Name |
Текст |
30 |
Назва компанії |
Обов’язковий |
Address |
Текст |
30 |
Адреса компанії |
Обов’язковий |
Country |
Текст |
30 |
Країна де знаходиться компанія |
Обов’язковий |
City |
Текст |
30 |
Країна |
Обов’язковий |
Fax |
Текст |
20 |
Факс |
Не обов’язковий |
Phone |
Текст |
20 |
Телефонний номер |
Обов’язковий |
HomePage |
Текст |
30 |
Домашня сторінка |
Не обов’язковий |
Обмеження цілісності таблиці |
UNIQUE(Name, Country, City) |
Таблиця 6. Відношення сутності Варіант авіалайнера
Варіант авіалайнера (VariantAirliner)
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
VarID |
Ціле |
7 |
Унікальний ID |
Первинний ключ |
FirstClassSeat |
Ціле |
3 |
Кількість місць першого класу |
Обов’язковий |
BusinessClassSeat |
Ціле |
3 |
Кількість місць бізнес класу |
Обов’язковий |
EconomyClassSeat |
Ціле |
3 |
Кількість місць економ класу |
Обов’язковий |
Обмеження цілісності таблиці |
UNIQUE(FirstClassSeat, BusinessClassSeat, EconomyClassSeat) |
Таблиця 7. Відношення сутності Квиток
Квиток (Ticket)
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
TicID |
Ціле |
7 |
Унікальний ID |
Первинний ключ |
FliFK |
Ціле |
3 |
Зв’язок з польотом |
Обов’язковий |
CliFK |
Ціле |
3 |
Зв’язок з клієнтом |
Обов’язковий |
Seat |
Ціле |
3 |
Номер місця |
Обов’язковий |
ClassSeatType |
Ціле |
1 |
Тип місця |
Обов’язковий |
Price |
Ціле |
5 |
Ціна |
Обов’язковий |
Обмеження цілісності таблиці |
UNIQUE(FliFK,Seat), Check ClassSeatType in (1, 2, 3) |
Таблиця 8 Відношення сутності Клієнт
Клієнт (Client)
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
CliID |
Ціле |
7 |
Унікальний ID |
Первинний ключ |
Name |
Текст |
30 |
Ім’я клієнта |
Обов’язковий |
SurName |
Текст |
30 |
Прізвище |
Обов’язковий |
Age |
Ціле |
3 |
Вік |
Обов’язковий |
Passport |
Текст |
10 |
Номер та серія паспорта |
Обов’язковий |
Country |
Текст |
30 |
Країна |
Не обов’язковий |
City |
Текст |
30 |
Місто |
Не обов’язковий |
Address |
Текст |
30 |
Адреса |
Не обов’язковий |
Phone |
Текст |
20 |
Телефон |
Обов’язковий |
Обмеження цілісності таблиці |
UNIQUE(Name, Surname, Passport) |
Таблиця 8 Відношення сутності Електронний квиток
Електронний квиток (ETicket)
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
TicFK |
Ціле |
7 |
Зв’язок з квитками |
Обов’язковий |
Текст |
30 |
Електронна адреса клієнта |
Не обов’язковий |
|
Fax |
Текст |
20 |
Факс |
Не обов’язковий |
CreditCard |
Текст |
16 |
Номер кредитної карти |
Не обов’язковий |