>
Як і в ієрархічній моделі забезпечується тільки підтримання цілісності по посиланнях (власник відносини - член відносини) [7].
Ієрархічна модель
Структура даних
Організація даних в СУБД ієрархічного типу визначається в термінах: елемент, агрегат, запис (група), групове ставлення, база даних.
· Атрибут (елемент даних) - найменша одиниця структури даних. Зазвичай кожному елементу при описі бази даних присвоюється унікальне ім'я. За цим імені до нього звертаються при обробці. Елемент даних також часто називають полем.
· Запис - іменована сукупність атрибутів. Використання записів дозволяє за одне звернення до бази отримати деяку логічно зв'язану сукупність даних. Саме записи змінюються, додаються і видаляються. Тип запису визначається складом її атрибутів. Примірник записи - конкретний запис з конкретним значенням елементів
· Групове ставлення - ієрархічне відношення між записами двох типів. Батьківська запис (власник групового відносини) називається вихідної записом, а дочірні записи (члени групового відносини) - підлеглими. Ієрархічна база даних може зберігати тільки такі деревовидні структури.
Коренева запис кожного дерева обов'язково повинна містити ключ з унікальним значенням. Ключі некореневих записів повинні мати унікальне значення тільки в рамках групового відносини. Кожен запис ідентифікується повним зчепленим ключем, під яким розуміється сукупність ключів всіх записів від кореневої за ієрархічним шляху.
При графічному зображенні групові відносини зображують дугами орієнтованого графа, а типи записів - вершинами (діаграма Бахмана).
Для групових відносин в ієрархічній моделі забезпечується автоматичний режим включення і фіксоване членство. Ето означає, що для запам'ятовування будь некорневой записи в БД повинна існувати її батьківська запис. При видаленні батьківської запису автоматично видаляються всі підлеглі.
Обмеження цілісності
Підтримується лише цілісність зв'язків між власниками та членами групового відносини (ніякої нащадок не може існувати без предка). Як уже зазначалося, не забезпечується автоматична підтримка відповідності парних записів, що входять в різні ієрархії.
Об'єктно-орієнтована модель.
Основні труднощі об'єктно-орієнтованого моделювання даних витікають з того, що такого розвиненого математичного апарату, на який могла б спиратися загальна об'єктно-орієнтована модель даних, не існує. У великій мірі тому досі немає базової об'єктно-орієнтованої моделі. З іншого боку, деякі автори стверджують, що загальна об'єктно-орієнтована модель даних в класичному сенсі і не може бути визначена з причини непридатності класичного поняття моделі даних до парадигми об'єктної орієнтованості.
Один з найбільш відомих теоретиків у галузі моделей даних Беєр пропонує в загальних рисах формальну основу ООБД, далеко не повну і не є моделлю даних в традиційному сенсі, але дозволяє дослідникам і розробникам систем ООБД принаймні говорити на одній мові (якщо, звичайно, пропозиції Беєр будуть розвинені і отримають підтримку). Незалежно від подальшої долі цих пропозицій ми вважаємо корисним коротко їх переказати.
По-перше, слідуючи практиці багатьох ООБД, пропонується виділити два рівня моделювання об'єктів: нижній (структурний) і верхній (поведінковий). На структурному рівні підтримуються складні об'єкти, їх ідентифікація та різновиди зв'язку isa raquo ;. База даних - це набір елементів даних, пов'язаних відносинами входить в клас або є атрибутом raquo ;. Таким чином, БД може розглядатися як орієнтований граф. Важливим моментом є підтримання поряд з поняттям об'єкта поняття значення (пізніше ми побачимо, як багато на цьому побудовано в одній з успішних об'єктно-орієнтованих СУБД O2).
Важливим аспектом є чіткий поділ схеми БД і самої БД. В якості первинних концепцій схемного рівня ООБД виступають типи і класи. Відзначається, що у всіх системах, що використовують тільки одне поняття (або тип, або клас), це поняття неминуче перевантажено: тип припускає наявність деякого безлічі значень, що визначається структурою даних цього типу; клас також припускає наявність безлічі об'єктів, але це безліч визначається користувачем. Таким чином, типи і класи відіграють різну роль, і для строгості і недвозначності потрібно одночасна підтримка обох понять.
Беєр не представляє повної формальної моделі структурного рівня ООБД, але висловлює впевненість, що поточного рівня розуміння достатньо, щоб формалізувати таку модель. Що ж стосується поведінкового рівня, запропонований тільки загальний підхід до необхідному для цього логічного апарату (...
