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

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

4. Групові відношення є відношеннями підпорядкованості. Група (запис) – власник відношення має підлеглі групи – члени відношень. Вихідна група називається предком, підпорядкована – нащадком.

5. Групові стосунки утворюють ієрархічну структуру, яку можна описати як орієнтований граф наступного вигляду:

   • існує єдина особлива вершина (відповідна групі), названа коренем, в яку не заходить жодне ребро (група не має предків);

   • у всі останні вершини входить лише одне ребро (всі останні групи мають одного предка), а виходить довільна кількість ребер (групи мають довільну кількість нащадків);

   • відсутні цикли.

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

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

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

СУБД, що підтримують ієрархічну модель, досить широко використовувалися на обчислювальних системах IBM 360/370 (ЄС ЕОМ). Як приклади таких систем можна вказати IMS, OKA і широко тиражовану в СРСР вітчизняну розробку ІНЕС. Прикладом ієрархічної СУБД для персональних ЕОМ є вітчизняна система НІКА (адаптація системи ІНЕС до IBM РС).

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

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

• модель має бути зрозуміла користувачеві, що не має особливих навиків у програмуванні;

• поява нових аспектів використання даних і необхідність введення нових зв'язків не повинні наводити до реструктуризації всієї моделі даних і бази даних в цілому.

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

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

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

Розглянемо приклад запису ER-діаграми (див. мал. 5.2.) в термінах реляційних баз даних.

Спочатку представимо таблиці, що відповідають сутностям.

Таблиця СТУДЕНТ

Код

Прізвище

Дата народження

Місце народження

Таблиця ФАКУЛЬТЕТ

Номер

Назва

Таблиця СПЕЦІАЛЬНІСТЬ

Номер

Назва

Представимо таблиці, що описують зв'язки.

Таблиця "Студент вчиться на факультеті"

Код студента

Номер факультету

Таблиця "Студент вчиться за фахом"

Код студента

Номер спеціальності

Таблиця "На факультеті є спеціальності"

Номер факультету

Номер спеціальності

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

Для приведених таблиць не вказані домени атрибутів. Відсутність зазначення доменів призводить до неоднозначної інтерпретації вмісту таблиці. Наприклад, дві таблиці з однаковими атрибутами

Код студента

Прізвище

Дата народження

Місце народження

можуть мати різне смислове значення і, відповідно, різний вміст (у одній таблиці містяться зведення про всіх студентів факультету, в іншій таблиці зведення лише про старост факультету). Для усунення неоднозначної інтерпретації в разі відсутності зазначення доменів використовують ім'я таблиці (СТУДЕНТ; СТАРОСТА)

Для формального опису таблиці використовується теоретико-множинне поняття відношення.

Схемою відношення R називається перелік імен атрибутів відношення (що відповідають стовпцям таблиці) з зазначенням доменів цих атрибутів і позначається R(A₁, A₂ ..., A_n);

де {A_i} – множина значень, що приймаються атрибутом A_i(i=1,n).

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

Як основний недолік реляційної моделі можна вказати дублювання інформації при представленні зв'язків.

Необхідно відзначити, що більшість СУБД для персональних ЕОМ підтримують саме реляційну модель даних. Як приклади таких найбільш поширених СУБД можна вказати всі dBase-подібні системи, DB2, Paradox, Access, FoxPro, Oracle, MS SQL Server.

Детальніше реляційна модель даних розглянемо в наступній лекції.