Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Структурна схема реляційної бази даних та

Поиск

Описання таблиць бази даних

Після того як спроектована 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 – Опис полів таблиці «Машины»

Назва поля Опис
Номер машины Первинний ключ
Гос_номер Державний номер машини, на якій працює в таксопарку водій
Марка Марка машини
Цвет Колір машини
Статус Статус машини, тобто «вільна» або «на виклику»


Поделиться:


Последнее изменение этой страницы: 2016-12-28; просмотров: 324; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.149.251.26 (0.008 с.)