Моделі організації даних

Набір принципів, що визначають організацію логічної структури зберігання даних у базі, одержав назву моделі даних. Моделі баз даних визначаються трьома компонентами:

• припустимою організацією даних;

• обмеженнями цілісності;

• безліччю припустимих операцій.

У теорії систем керування базами даних виділяють моделі трьох основних типів: ієрархічну, мережеву й реляційну.

Ієрархічна модель

У ієрархічній моделі всі записи, агрегати й атрибути бази даних утворять Ієрархічно організований набір, тобто таку структуру, у якій всі елементи зв'язані відносинами підпорядкованості й при цьому будь-який елемент може підкорятися тільки одному якому-небудь іншому елементу. Таку форму залежності зручно зображувати за допомогою деревоподібного графа (схеми, що складає із крапок і стрілок, що зв'язна й не має циклів). Приклад ієрархічної структури бази даних наведений на рис. 1.

Рис1. Схема ієрархічної моделі даних

Типовим представником сімейства баз даних, заснованих на ієрархічній моделі, є Information Management System (IMS) фірми IBM, перша версія якої з'явилася в 1968 р.

Мережева модель

Концепція мережевої моделі даних пов'язана з ім'ям Ч. Бахмана. Мережевий підхід до організації даних є розширенням ієрархічного. В ієрархічних структурах запис-нащадок повинна мати в точності одного предка; у мережевій структурі даних нащадок може мати будь-яке число предків (рис. 2).

Рис.2. Схема мережевої моделі даних

Мережева БД складається з набору записів і набору зв'язків між цими записами, точніше, з набору екземплярів записів заданих типів (із припустимого набору типів) і набору екземплярів із заданого набору типів зв'язку.

Прикладом системи керування даними з мережною організацією є Integrated Database Management System (IDMS) компанії Cullinet Software Inc., розроблена в середині 70-х років. Вона призначена для використання на «більших» обчислювальних машинах. Архітектура системи заснована на пропозиціях Data Base Task Group (DBTG), Conference on Data Systems Languages (CODASYL), організації, відповідальної за визначення стандартів мови програмування Кобол.

Серед достоїнств систем керування даними, заснованих на ієрархічній або мережній моделях, можуть бути названі: їхня компактність й, як правило, висока швидкодія, а серед недоліків - не універсальність, високий ступінь залежності від конкретних даних.

Реляційна модель даних

Концепції реляційної моделі вперше були сформульовані в роботах американського вченого Едгара Кодда і ґрунтується на понятті відношення (relation). Звідки відбувається її друга назва — модель Кодда.

Мал. 3. Схема реляційної моделі даних

У реляційній моделі об'єкти і взаємозв'язки між ними представляються за допомогою таблиць (рис.3). Для її формального визначення використовується фундаментальне поняття відношення.

При створенні інформаційної системи сукупність стосунків дозволяє зберігати дані про об'єкти наочної області і моделювати зв'язки між ними. Елементи РМД і форми їх уявлення приведені в таблиці. 1.

Таблица 1 Елементи реляційної моделі

Елемент реляційної моделі	Форма уявлення
Відношення	Таблиця
Схема відношення	Рядок заголовків стовпців таблиці (заголовок таблиці)
Кортеж	Рядок таблиці
Суть	Опис властивостей об'єкту
Поле	Стовпчик в таблиці/відношенні
Атрибут	Заголовок стовпця таблиці
Домен	Безліч допустимих значень атрибуту
Значення атрибуту	Значення поля в записі
Первинний ключ	Один або декілька атрибутів
Тип даних	Тип значень елементів таблиці

Відношення є найважливішим поняттям і є двомірною таблицею, що містить деякі дані.

Відношенням є безліч елементів, званих кортежами.. Наочною формою представлення відношення є звична для людського сприйняття двовимірна таблиця.

Таблиця має рядки (записи) і стовпці (колонки). Кожен рядок таблиці має однакову структуру і складається з полів. Рядкам таблиці відповідають кортежі, а стовпцям — атрибути відношення.

За допомогою однієї таблиці зручно описувати простий вид зв'язків між даними, а саме ділення одного об'єкту (явища, суть, системи і інш.), інформація про яке зберігається в таблиці, на безліч підоб'єктів, кожному з яких відповідає рядок або запис таблиці. При цьому кожен з підоб'єктів має однакову структуру або властивості, що описуються відповідними значеннями полів записів. Наприклад, таблиця може містити відомості про групу учнів, про кожне з яких відомі наступні характеристики: прізвище, ім'я і по батькові, пів, вік і освіта. Оскільки в рамках однієї таблиці не удається описати складніші логічні структури даних з наочної області, застосовують скріплення таблиць.

Суттєвістю є об'єкт будь-якої природи, дані про яке зберігаються в базі даних. Дані про суть зберігаються у відношенні.

Атрибутами є властивості, що характеризують суть В структурі таблиці кожен атрибут іменується і йому відповідає заголовок деякого стовпця таблиці.

Математично відношення можна описати таким чином. Хай даны n безлічі D1, D2, D3..., Dn, тоді відношення R є безліч впорядкованих кортежів <dl, d2, d3..., dn>, де dk ( Dk, dk — атрибут, а Dk -домен відношення R. Елементи декартова твори — кортежами відношення. Число п визначає ступінь відношення, а кількість кортежів — його потужність. Разом з поняттями домена і кортежу при роботі з реляційними таблицями використовуються альтернативні ним поняття поля і запису.

На мал. 4 наведений приклад представлення відношення СПІВРОБІТНИК.

У спільному випадку порядок кортежів у відношенні, як і в будь-якій безлічі, не визначений. Проте в реляційних СУБД для зручності кортежі все ж упорядковують. Найчастіше для цього вибирають деякий атрибут, по якому система автоматично сортує кортежі по зростанню або убуванню. Якщо користувач не призначає атрибуту упорядкування, система автоматично привласнює номер кортежам в порядку їх введення.

Мал. 4. Представлення відношення СПІВРОБІТНИК

Формально, якщо переставити атрибути у відношенні, то виходить нове відношення. Проте в реляційних БД перестановка атрибутів не приводить до утворення нового відношення.

Доменом є безліч всіх можливих значень визначеного атрибуту відношення. Відношення СПІВРОБІТНИК включає 4 домени. Домен 1 містить прізвища всіх співробітників, домен 2 — номери всіх відділів фірми, домен 3 — назви всіх посад, домен 4 — дати народження всіх Сотрудников. Кожен домен утворює значення одного типа даних, наприклад, числові або символьні.

Відношення СПІВРОБІТНИК містить 3 кортежі. Кортеж рассматриваемого відношення складається з 4 елементів, кожен з яких вибирається з відповідного домена. Кожному кортежу відповідає рядок таблиці (мал. 4).

Схема відношення (заголовок відношення) є списком імен атрибутів. Наприклад, для наведеного прикладу схема відношення має вигляд СПІВРОБІТНИК(ФІО, Відділ, Посада, Д_рожденія). Безліч власне кортежів відношення часто називають вмістом (тілом) відношення.

Первинним ключем (ключем відношення, ключовим атрибутом) називається атрибут відношення, що однозначно ідентифікує кожен з його кортежів. Наприклад, у відношенні СПІВРОБІТНИК(ФІО, Відділ, Посада, Д_рожденія) ключовим є атрибут «ФІО». Ключ може бути складеним (складним), тобто складатися з декількох атрибутів.

Фізичне розміщення даних в реляційних базах на зовнішніх носіях легко здійснюється за допомогою звичайних файлів.

Гідність реляційної моделі даних полягає в простоті, зрозумілості і зручності фізичної реалізації на ЕОМ. Саме простота і зрозумілість для користувача з'явилися основною причиною їх широкого використання. Проблеми ж ефективності обробки даних цього типа виявилися технічно цілком вирішуваними.

Основними недоліками реляційної моделі є наступні: відсутність стандартних засобів ідентифікації окремих записів і складність опису ієрархічних і мережевих зв'язків.

У реляційній базі даних кожна таблиця повинна мати первинний ключ (ключовий елемент) — поле або комбінацію полів, які єдиним чином ідентифікують кожен рядок в таблиці.

Важливою перевагою реляційної моделі є те, що в її рамках дії над даними можуть бути зведені до операцій реляційної алгебри, які виконуються над стосунками. Це такі операції, як об'єднання, перетин, віднімання, декартовий твір, вибірка, проекція, з'єднання, ділення.

Найважливішою проблемою, що вирішується при проектуванні баз даних, є створення такої їх структури, яка б забезпечувала мінімальне дублювання інформації і спрощувала процедури обробки і оновлення даних. Коддом був запропонований деякий набір формальних вимог універсального характеру до організації даних, які дозволяють ефективно вирішувати перераховані завдання. Ці вимоги до стану таблиць даних отримали назву нормальних форм. Спочатку були сформульовані три нормальні форми. Надалі з'явилася нормальна форма Бойса—Кодда і нормальні форми вищих порядків. Проте вони не набули широкого поширення на практиці.

• Говорять, що відношення знаходиться в першій нормальній формі, якщо всі його атрибути є простими.

• Говорять, що відношення знаходиться в другій нормальній формі, якщо воно задовольняє вимогам першої нормальної форми і кожен не ключовий атрибут функціонально повно залежить від ключа (однозначно визначається їм).

• Говорять, що відношення знаходиться в третій нормальній формі, якщо воно задовольняє вимогам другої нормальної форми і при цьому будь-який не ключовий атрибут залежить від ключа не транзитивно. Відмітимо, що транзитивною називається така залежність, при якій який-небудь не ключовий атрибут залежить від іншого не ключового атрибуту, а той, у свою чергу, вже залежить від ключа.

Принциповим моментом є те, що для приведення таблиць до стану, що задовольняє вимогам нормальних форм, або, як ще говорять, для нормалізації даних над ними, мають бути здійснені перераховані вище операції реляційної алгебри.

Прикладами зарубіжних реляційних СКБД для ПЕОМ є наступні: dBaselll Plus і dBase IY (фірма Ashton-Tate), DB2 (IBM), R:BASE (Microrim), FoxPro ранніх версій і FoxBase (Fox Software), Paradox і dBASE for Windows (Borland), FoxPro пізніших версій, Visual FoxPro і Access (Microsoft), Clarion (Clarion Software), Ingres (ASK Computer Systems) і Oracle (Oracle).

До вітчизняних СКБД реляційного типа відносяться системи: ПАЛЬМА (ГИК АН УРСР), а також система HyTech (МІФІ).

Відмітимо, що останні версії реляційних СУБД мають деякі властивості об'єктно-орієнтованих систем. Такі СУБД часто називають об'єктно-реляційними. За приклад такої системи можна вважати продукти Oracle 8.x. Системи попередніх версій аж до Oracle 7.x вважаються «чисто» за реляційних.