2.3 Структурна схема реляційної бази даних та описання таблиць бази даних
Після того, як спроектована модель «Сутність – зв'язок», треба переходити до другого етапу проектування бази даних, а саме, до створення реляційної моделі даних.
Враховуючи всю складність ієрархічної та мережевої моделі, найбільше поширення отримала реляційна модель даних. Вся інформація в реляційній моделі даних організована у вигляді таблиць, які пов’язані між собою за допомогою зв’зків.
Реляційні системи беруть початок в математичній теорії множин. Вони були запропоновані наприкінці 1968 р. доктором Е. Ф. Коддом з фірми IBM. В термінології реляційної моделі даних кожен стовпець таблиці називається полем (атрибутом), а кожен рядок таблиці – записом (кортежем).
Кортежі можуть розташовуватися в будь-якій черзі, при цьому відношення буде залишатися тим самим та мати той самий зміст. Кортежі називають поширенням, станом або тілом відношення, яке постійно змінюється.
Дані в одному полі можуть мати значення лише з деякої сукупності припустимих значень, яка називається доменом.
Важливим наслідком відсутності в таблиці однакових записів є наявність в ній первинного ключа. Значення первинного ключа повинне бути унікальним для кожного запису таблиці, тобто, повинне однозначно визначати кожен запис таблиці.
Для того, щоб можна було б зв’язати таблиці між собою в реляційній моделі використовується поняття зовнішнього ключа, значення якого повинно дорівнювати значенню первинного ключа в іншій таблиці, з якою відбувається зв'язок.
Ступінь відношення визначається кількістю атрибутів, яку містить відношення.
Відношення лише з одним атрибутом має ступінь 1 та називається унарним відношенням. Відношення з двома атрибутами має назву бінарне, відношення з трьома атрибутами – тернарне, а для відношень з більшою кількістю атрибутів використовується термін n-парний.
Кординальність – кількість кортежів, яку містить відношення. Ця характеристика змінюється при кожному додаванні або знищенні кортежів. Кординальність є властивістю тіла відношення та визначається поточним станом відношення в окрему мить.
Для предметної області «Розробити базу даних для роботи з абонентами телефонної АТС» була побудована реляційна модель, зображена на рис. 2.2:
Рис. 2.2 Структурна схема реляційної БД для предметної області
«Розробити базу даних для роботи з абонентами телефонної АТС»
В даній базі даних всі таблиці пов’язані між собою зв’язками «один до одного» та «один до багатьох».
Зв'язок «один до одного»(1:1) означає: кожному значенню пов’язуючого поля відповідає один запис по обидва боки.
Зв'язок «один до багатьох» означає (1:N) – кожному значенню пов’язуючого поля з одного боку відповідає декілька записів по другий бік (наприклад, один абонент може здійснити багато дзвінків, один абонент може мати декілька номерів).
Окрім описаних вище зв'язків в реляційній моделі даних підтримується ще зв'язок «багато до багатьох», який означає: (М:N) – значення в полях неодноразово зустрічаються в пов’язаних відношеннях. Такий тип зв’язку треба обходити та розподіляти його на зв’язки 1:N (створюється третє відношення, яке пов’язується з початковими зв’язками 1:N).
В результаті проведеної роботи можна побачити, що була створена база даних, яка складається з 6 таблиць. База даних нормалізована до 3 нормальної форми.
Нормалізація відношень забезпечує ефективність структур даних в реляційній БД. Цей процес зменшує надмірність даних (зберігання однакових даних в декількох місцях). В результаті більш раціонально використовується зовнішня пам’ять, зменшується ймовірність порушення узгоджуваності даних.
Нормалізація являє собою дії послідовного перетворення початкової (ненормалізованої) таблиці в нормализовані відношення в першій нормальній формі (1НФ), 2НФ, 3НФ, нормальній формі Бойса-Кодда (НФБК), 4НФ, 5НФ.
Відношення знаходиться в третій нормальній формі, якщо воно знаходиться в другій нормальній формі та кожен його не ключовий атрибут безпосередньо (не транзитивно) залежить від первинного ключа.
В базі даних кожна таблиці зберігає окрему інформацію. База даних для АТС складється з 6 таблиць. Наведу опис для кожної з них:
«Абоненты» Ця таблиця зберігає дані про абонента такі як: Код абонента, номер телефону номер додаткового телефону, ПІБ. Структура таблиці зображена на рис. 2.3:
Рис. 2.3 Структура таблиці «Абоненты» в режимі конструктору
«Абонплата» - дана таблиця зберігає дані про розрахунки абонентів. Такі як ПІБ абонента, тривалість розмови, суму сплати, тариф, дату сплати та дату видачі. Структура таблиці зображена на рис. 2.4:
Рис. 2.4 Структура таблиці «Абонплата» в режимі конструктору
Таблиця має зовнішні ключі такі як «ФИО Абонента» та «Тариф», призначені для зв’язка з таблицями, які зберігають інформацію про абонентів та тарифи.
3 . «Тарифы» - дана таблиця зберігає відомості про тарифи такі як: код тарифу, його опис та вартість. Структура зображена на рис. 2.5
Рис. 2.5 Структура таблиці «Тарифы» в режимі конструктору
4 . «Звонки» - в цій таблиці зберігаються дані про дзвінки абонентів такі як: ПІБ абонента, який викликає, ПІБ викликаємого абонента, Дата дзвінка, Час дзвінка, тривалість розмови та час закінчення. Структура таблиці зображена на рис. 2.6:
Рис. 2.6 Структура таблиці «Звонки» в режимі конструктору
Таблиця має наступні ключі призначені для зв’язка з таблицею «Абоненты» «Абонент 1» , « Абонент 2».
5 . «Справочные Бюро» - таблиця містить дані про довідкові бюро такі як:
Код бюро, його назва та номер. Структура таблиці зображена на рис. 2.7:
Рис. 2.7 Структура таблиці «Справочные Бюро» в режимі конструктору
6. «Пользователи» - таблиця зберігає дані про користувачів бази даних такі як:
Код , Логін, Пароль. Структура зображена на рис. 2.8:
Рис. 2.8 Структура таблиці «Пользователи» в режимі конструктору