Описання таблиць бази даних
Після того як спроектована ER-модель, можна приступати до створення реляційної моделі даних.
Вся інформація в реляційній моделі даних організовується у вигляді таблиць, які зв'язані між собою за допомогою зв'язків.
Кожен стовпець називається полем, а кожен рядок - кортежем. Для того щоб відрізнити один рядок від іншого в реляційній моделі даних використовується поняття ключа.
Ключ - поле, значення якого унікальним способом ідентифікує запис. Ключі можуть бути первинними та зовнішніми. Значення первинного ключа має бути унікальним для кожного запису в таблиці.
Зовнішній ключ - поле або група полів, які не є первинним ключем в даній таблиці, але є первинним в іншій.
Для предметної області «Розробка програмного забезпечення менеджера по роботі з клієнтами таксопарку» була побудована реляційна модель даних, яка зображена на рисунку 2.2:
Рисунок 2.2 - Структурна схема реляційної БД для предметної області «Розробити програмне забезпечення для автоматизації роботи менеджера по роботі з клієнтами таксопарку»
В результаті була створена база даних, яка складається з 5 таблиць. Кожна таблиця містить в собі унікальну інформацію.
У структурній схемі реляційної бази даних визначені відношення «один до багатьох» - в цьому випадку запис однієї таблиці може мати декілька погоджених з нею записів в іншій таблиці. При цьому кожен запис в другій таблиці узгоджується лише з одним записом в першій таблиці. Поле, що містить первинний ключ нової таблиці, зв'язується із зовнішнім ключем старої. Значення в полі із зовнішнім ключем можуть повторюватися.
Відповідно до предметної області, яка розглядається в курсовій роботі, це означає, що:
1. один клієнт може замовити декілька поїздок на таксі;
2. один водій може здійснити декілька поїздок;
3. один оператор може прийняти декілька замовлень на поїздку.
Окрім зв’язка «один до багатьох» в реляційній моделі даних підтримуються ще зв’язки «один до одного» та «багато до багатьох».
Зв’язок «один до одного» - при такому типові зв'язку одному запису в першій таблиці відповідає лише один запис в іншій таблиці. В цьому випадку слід перевірити можливість розміщення всіх записів в одній таблиці. Проте у ряді випадків можна використовувати декілька простіших таблиць. Відповідність записів встановлюється по полю, яке є первинним ключем в першій таблиці, і полю, званим зовнішнім ключем іншої таблиці.
Зв’язок «багато до багатьох» - кожному запису з однієї таблиці може відповідати будь-яка кількість записів в іншій таблиці і навпаки. Наприклад, кожна людина може дзвонити з декількох телефонів. З іншого боку деякими телефонами можуть користуватися декілька чоловік. В цьому випадку поля, по яких встановлюється зв'язок, є зовнішніми ключами. Вони можуть містити значення, що повторюються.
Будь-яка база даних повинна бути нормалізована до однієї з нормальних форм.
Нормальна форма - властивість відношення в реляційнiй моделі даних, що характеризує його з точки зору надмірності, яка потенційно може привести до логічно помилкових результатів вибірки або зміни даних.
Нормальна форма визначається як сукупність вимог, яким має задовольняти відношення.
Існують такі нормальні форми як:
§ перша нормальна форма;
§ друга нормальна форма;
§ третя нормальна форма;
§ нормальна форма Бойса-Кодда;
§ четверта нормальна форма;
§ п’ята нормальна форма;
§ шоста нормальна форма.
Перша нормальна форма (1НФ, 1NF) утворює ґрунт для структурованої схеми баз даних:
· кожна таблиця повинна мати основний ключ: мінімальний набір колонок, які ідентифікують запис;
· уникнення повторень груп (категорії даних, що можуть зустрічатись різну кількість разів в різних записах) правильно визначаючи неключові атрибути;
· атомарність: кожен атрибут повинен мати лише одне значення, а не множину значень.
Друга нормальна форма (2НФ, 2NF) вимагає, аби дані, що зберігаються в таблицях із композитним ключем не залежали лише від частини ключа:
· схема бази даних повинна відповідати вимогам першої нормальної форми;
· дані, що повторно з'являються в декількох колонках виносяться в окремі таблиці.
Третя нормальна форма (3НФ, 3NF) вимагає, аби дані в таблиці залежали винятково від основного ключа:
· схема бази даних повинна відповідати всім вимогам другої нормальної форми;
· будь-яке поле, що залежить від основного ключа та від будь-якого іншого поля, має виноситись в окрему таблицю.
Нормальна форма Бойса - Кодда (BCNF) - відношення знаходиться в BCNF тоді і тільки тоді, коли кожна її нетривіальна й неприводима зліва функціональна залежність має в якості свого детермінанта деякий потенційний ключ. Це більш сувора версія третьої нормальної форми, яка набуває актуальності при наявності щодо кількох потенційних ключів, хоча б один з яких є складеним. Якщо відносно тільки один потенційний ключ або всі потенційні ключі є простими (нескладовими), то BCNF еквівалентна 3NF.
Четверта нормальна форма (4NF) - таблиця знаходиться в 4NF, якщо вона знаходиться в BCNF і не містить нетривіальних багатозначних залежностей.
П'ята нормальна форма (5NF) - відношення знаходиться в п'ятій нормальній формі тоді і тільки тоді, коли кожна нетривіальна залежність з'єднання в ньому визначається потенційним ключем цього відношення.
База даних створена в курсовій роботі нормалізована до 3 нормальної форми.
Кожна таблиця призначена для зберігання окремої інформації. Опишемо кожну з таблиць створеної бази даних.
1. «Водители» -таблиця містить всю інформацію про водіїв, які працюють в таксопарку, а саме: номер водія; ПІБ водія, серія та номер паспорту; стаж його роботи водієм; телефон, за яким з ним можна буде зв’язатися; адреса; статус водія, коли він знаходиться на зміні та кількість поїздок, яку він здійснив, працюючи водієм в таксопарку. Структура таблиці «Водители» зображена на рисунку 2.3:
Рисунок 2.3 - Структура таблиці «Водители» в режимі конструктору
Таблиця 2.1 – Опис полів таблиці «Водители»
| Назва поля | Опис |
| Номер водителя | Первинний ключ |
| ФИО | Прізвище, Ім’я, по-батькові водія, який працює в таксопарку |
| Серия и номер паспорта | Паспортні данні водія, який працює в таксопарку |
| Стаж | Стаж керування транспортним засобом водія |
| Телефон | Телефон водія, за яким з ним можна зв’язатися |
| Адрес | Адреса, за якою мешкає водій |
| Статус | Статус водія, тобто «вільний» або «зайнятий» |
| Кол-во поездок | Кількість поїздок, яка була здійснена водієм таксопарку |
2. «Клиенты» - таблиця містить всю інформацію про клієнтів, які будуть здійснювати замовлення машин в таксопарку, а саме: їх ідентифікаційні номери, ПІБ клієнта, паспортні дані, адреса та телефон, за яким можна зв’язатися з клієнтом. Структура таблиці «Клиенты» зображена на рисунку 2.4:
Рисунок 2.4 - Структура таблиці «Клиенты» в режимі конструктору
Таблиця 2.2 – Опис полів таблиці «Клиенты»
| Назва поля | Опис |
| Номер клиента | Первинний ключ |
| Адрес | Адреса, за якою здійснює виклик таксі клієнт |
| Телефон | Телефон, за яким можна зв’язатися з клієнтом |
3. «Поездки»-таблиця містить всю інформацію про поїздки, які замовлялися клієнтами, та які виконувалися службою таксі, а саме такі пункти входять до таблиці: номер поїздки; оператор, який прийняв замовлення; водій, який здійснив замовлення; машина, на якій було здійснене замовлення, клієнт, замовлення якого й здійснював водій таксопарку; дата та час відправлення таксі за замовленням; звідки було зроблене замовлення та пункт призначення поїздки.
Таблиця має 4 зовнішніх ключа: «Номер оператора», «Номер водителя», «Номер машины» «Номер клиента». За цими полями таблиця «Поездки» пов’язується з іншими таблицями та бере інформацію саме з них. Наприклад, за полем «Номер оператора» відбувається зв'язок з таблицею «Операторы» та вилучає інформацію про операторів, які здійснюють прийом замовлень від клієнтів.
Структура таблиці «Поездки» в режимі конструктора зображена на рисунку 2.5:
Рисунок 2.5 - Структура таблиці «Поездки» в режимі конструктору
Таблиця 2.3 – Опис полів таблиці «Поездки»
| Назва поля | Опис |
| Номер поездки | Первинний ключ |
| Номер оператора | Зовнішній ключ для зв'язку з таблицею «Операторы» |
| Номер водителя | Зовнішній ключ для зв'язку з таблицею «Водители» |
| Номер машины | Зовнішній ключ для зв'язку з таблицею «Машины» |
| Номер клиента | Зовнішній ключ для зв'язку з таблицею «Клиенты» |
| Дата отправления | Дата відправлення таксі |
| Время отправления | Час відправлення таксі |
| Пункт отправления | Пункт відправлення таксі |
| Пункт назначения | Пункт призначення таксі |
| Сумма | Сума, яку повинен сплатити клієнт, за здійснену поїздку |
4. «Операторы»- таблиця містить всю інформацію про операторів, які працюють в службі таксі та оформляють замовлення на послуги клієнтів. В таблиці зберігається така інформація: номер оператора; його ПІБ; адреса та телефон, за яким можна зв’язатися с оператором; всі паспорті дані оператора та пароль, за яким оператор має можливість працювати з базою.
Структура таблиці «Операторы» зображена на рисунку 2.6:
Рисунок 2.6 - Структура таблиці «Операторы» в режимі конструктору
Таблиця 2.4 – Опис полів таблиці «Операторы»
| Назва поля | Опис |
| Номер оператора | Первинний ключ |
| ФИО | Прізвище, Ім’я, по-батькові оператора, який працює в таксопарку |
| Адрес | Адреса, за якою мешкає оператор |
| Телефон | Телефон оператора, за яким з ним можна зв’язатися |
| Паспортные данные | Паспортні данні оператора, який працює в таксопарку |
| Дата принятия на работу | Дата, коли оператор був прийнятий на роботу |
| Прохождение стажировки | Відомості про те, проходив або ні оператор стажування при прийнятті на роботу |
| Дата увольнения | Дата, коли був звільнений оператор |
| Пароль | Пароль оператора для санкціонованого доступу до даних |
5. «Машины» -таблиця містить всю інформацію про автомобілі, на яких виконуються замовлення та послуги таксопарку, а саме такі пункти як: код машини; її марка; колір; державний номер та статус (тобто вільною є на час замовлення саме ця машина або ж зайнятою).
Структура таблиці «Машины» зображена на рисунку 2.7:
Рисунок 2.7 - Структура таблиці «Машины» в режимі конструктору
Таблиця 2.5 – Опис полів таблиці «Машины»