4.2. Види моделей даних

Ядром будь-якої бази даних є модель даних. Модель становить безліч структур даних, обмежень цілісності й операцій маніпулювання даними. За допомогою моделі даних можуть бути представлені об'єкти предметної області й взаємозв'язку між ними.

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

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

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

Файлова модель даних

У файлових системах реалізується модель типу плоский файл. При такій моделі машинна ІБ являє собою сукупність не зв'язаних між собою файлів (незалежних) з однотипними записами з лінійною (однорівневою) структурою.

Основні типи структур даних файлової моделі – поле, запис, файл.

Запис є основною структурною одиницею обробки даних і одиницею обміну між оперативною і зовнішньою пам'яттю.

Екземпляр запису являє собою реалізацію запису, що містить конкретні значення полів. Структура запису файлу – лінійна, тобто поля мають єдине значення. Кожен екземпляр запису однозначно ідентифікується унікальним ключем запису. У загальному випадку ключі запису бувають двох видів: первинний (унікальний) і вторинний ключ.

Первинний ключ (ПК) – це одне чи декілька полів, що однозначно ідентифікують запис. Якщо первинний ключ складається з одного поля, він називається простим, якщо з декількох полів – складним ключем.

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

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

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

ІМ’Я ФАЙЛУ				Ознака ключа
ПОЛЕ		ФОРМА ПОЛЯ
Позначення	Найменування	Тип	Довжина		Точність

Рис. 4.1. Структура файла

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

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

Ієрархічна (або деревоподібна) БД складається з упорядкованого набору дерев; більш точно – з упорядкованого набору декількох екземплярів одного типу дерева.

Об'єкти, зв'язані ієрархічними відносинами, утворять орієнтований граф (перевернене дерево), вид якого представлений на рис. 4.2.

одна точка прямого доступу

Рис. 4.2. Графічне зображення ієрархічної структури БД

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

До кожного запису бази даних існує тільки один (ієрархічний) шлях від кореневого запису. Наприклад, як видно з рис. 4.2, для запису С4 шлях проходить через записи А і ВЗ.

Приклад, представлений на рис. 4.3, ілюструє використання ієрархічної моделі бази даних для опису БД ПРАЦІВНИК.

Для розглянутого прикладу ієрархічна структура правомірна, тому що кожен студент учиться в певній (тільки одній) групі, що ставиться до певного (тільки одного) факультету, відповідно факультет належить тільки певному ВНЗ.

Рис. 4.3. Приклад ієрархічної структури БД

Приклад типу дерева (схеми ієрархічної БД) наведений на рис. 4.4:

Тут Відділ є предком для Начальник і Працівник, а Начальник і Працівник - нащадки Відділ. Між типами запису підтримуються зв'язки.

Рис. 4.4. Ієрархічна схема БД

Ієрархічні структури відносно просто створюються й підтримуються. Це важливо для ряду додатків, однак безліч даних за своєю природою не зв'язані в деревоподібними структурами. У багатьох структурах даних один запис вимагає більше одного подання (тому доводиться розробляти способи об'єднання даних, які по-різному представляються різним користувачам, в одну загальну схему БД. У результаті виходять звичайно більш складні структури в порівнянні з деревоподібними. Тому програмне забезпечення, сконструйоване тільки для роботи з деревоподібними структурами, має обмежене застосування й нерідко сильно впливає на можливості збільшення обсягу й розвитку БД.

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

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

Мережна модель даних

У мережній структурі при тих же основних поняттях (рівень, вузол, зв'язок) кожен елемент може бути пов'язаний з будь-яким іншим елементом. На рис. 4.5 зображена мережна структура бази даних.

прямий доступ до будь-якого об'єкта

Рис. 4.5. Графічне зображення мережної структури

Приклад. Прикладом складної мережної структури може служити структура бази даних, що містить відомості про студентів, що беруть участь у науково-дослідних роботах (НДРС). Можлива участь одного студента в декількох НДРС, а також участь декількох студентів у розробці однієї НДРС.

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

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

Мережна БД складається з набору записів і набору зв'язків між цими записами. Простий приклад мережної схеми БД наведений на рис. 4.6:

Рис. 4.6. Приклад мережної схеми БД

Мережна модель даних визначається в тих же термінах, що й ієрархічна. Вона складається з безлічі записів, які можуть бути власниками або членами групових відносин. Зв'язок між записом-власником і записом-членом також має вигляд один до багатьох.

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

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

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

Реляційна модель орієнтована на організацію даних у вигляді двовимірних таблиць. Кожна реляційна таблиця представляє собою двовимірний масив і має наступні властивості:

кожен елемент таблиці – один елемент даних;

усі стовпці в таблиці однорідні, тобто всі елементи в стовпці мають однаковий тип (числовий, символьний і т. д.) і довжину;

кожен стовпець має унікальне ім'я;

однакові рядки в таблиці відсутні;

порядок проходження рядків і стовпців може бути довільним.

Приклад. Реляційної таблицею (або відношенням) можна представити інформацію про студентів, що навчаються у ВНЗ (рис. 4.7).

Табельний номер	Прізвище	Ім'я	По батькові	Дата народження	Назва відділу
001111	Грищенко	Наталія	Петрівна	05.10.67	Відділ кадрів
001112	Степанов	Семен	Максимович	22.03.54	Відділ кадрів
001211	Литвин	Юлія	Олегівна	01.04.80	Бухгалтерія

Рис. 4.7. Приклад реляційної таблиці

Відношення представлене у вигляді таблиці, рядки якої відповідають кортежам або записам, а стовпці – атрибутам відносин, доменам, полям.

Поле «Табельний номер» є первинним ключем. Якщо записи однозначно визначаються значеннями декількох полів, то така таблиця бази даних має складений ключ.

Щоб зв'язати дві реляційні таблиці, необхідно первинний ключ батьківської таблиці ввести до складу первинного ключа, другий – до дочірньої таблиці або потрібно ввести в структуру дочірньої таблиці зовнішній ключ, що є точною копією первинного ключа батьківської таблиці.

Приклад. На рис. 4.8 показано приклад реляційної моделі, побудованої на основі відносин: СЕСІЯ, СТУДЕНТ, ГУРТОЖИТОК, ПРОЖИВАННЯ.

Рис. 4.8. Приклад реляційної моделі

ПРАЦІВНИК (табельний номер, прізвище, ім'я, по батькові);

ТАБЕЛЬ (табельний номер, відпрацьований час)

ШТАТНИЙ РОЗКЛАД (код посади, назва посади, оклад);

ЗАРОБІТНА ПЛАТА (номер, табельний номер, код посади, нараховано).

Таблиці ПРАЦІВНИК і ТАБЕЛЬ мають співпадаючі ключі (табельний номер), що дає можливість легко організувати зв'язок між ними. Таблиця ЗАРОБІТНА ПЛАТА має первинний ключ (номер) і містить зовнішні ключі (табельний номер і код посади), які забезпечують її зв'язок з таблицями ТАБЕЛЬ і ШТАТНИЙ РОЗКЛАД.

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

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

У спрощеному вигляді плоска таблиця – це таблиця, кожен осередок якої може бути однозначно ідентифікований указівкою рядка й стовпця таблиці. Крім того, в одному стовпці всі осередки повинні містити дані одного простого типу.