Мережеві і ієрархічні бази даних

При викладі мережевий і ієрархічної моделей даних доцільно використовувати такий порядок.

Спочатку описується логічна структура моделі даних (МД), потім - процеси використання побудованої БД за допомогою запропонованого Е.Ф. Коддом мови Альфа [9] і, нарешті, процедура програмного опису (створення та використання) БД. Оскільки Альфа-опис вказаних моделей даних не відрізняється від Альфа-опису реляційної моделі даних, воно опущено.

Логічна структура мережевий БД

При різних способах реалізації мережевих моделей [1 -11] найбільшого поширення набула модель Кодаса (CODASYL Conference on DAta SYstems Language - Асоціація з мов систем обробки даних), запропонована Робочою групою по базах даних (DBTG - DataBase Task Group). Ця модель вважається найбільш розвиненою мережевою моделлю даних, постійно розвивається, підтримується і супроводжується, будучи як би стандартом.

Асоціація Кодаса утворилася в 1959 р, а Робоча група БД, починаючи з 1969 р, випускала специфікації. Основи мережевої моделі були закладені в 1971 р Комітетом з ЯОД. Замість Робочої групи БД стала працювати Робоча група мов БД, що почала з розширення коболе. Серйозні результати були отримані в 1973 р У звітах групи була описана мережева модель даних, фактично мало змінилася з тих пір. Основна мета Кодаса - створення ієрархічної моделі, що дозволяє описувати відносини М: М, т. Е. Зменшити недоліки ієрархічної моделі.

Розроблялися і відповідні СУБД: DMS (корпорації UNIVAC), IDMS (Cullinane), DBMS (DEC), IDS (Honeywell). В даний час широко відома db_Vista, що працює на персональних комп'ютерах в DOS і Windows.

Структурними елементами мережевої моделі даних Кодаса є елемент даних, агрегат даних і запис (рис. 6.1, а), яким присвоюються імена.

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

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

Структурні елементи мережевої БД

Рис. 6.1. Структурні елементи мережевої БД

Розрізняють агрегати типу "вектор" і типу "повторювана група". Агрегат, що повторюється компонента якого є простим елементом даних, називається "вектором". Наприклад агрегат "Заробітна плата", в якому екземпляр елемента даних може повторюватися до 12 разів (за кожен місяць року). Агрегат, що повторюється компонента якого представлена сукупністю даних, називається повторюваної групою. У повторювану групу можуть входити окремі елементи даних, вектори, агрегати або повторювані групи. На рис. 6.1, г представлений агрегат "Замовлення на покупку", що має в своєму складі повторювану групу "Партія товару".

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

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

Записи є фактично найпростішими структурними елементами, через які здійснюються зв'язки: елементом зв'язку служить набір.

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

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

  • 1. База даних може містити будь-яку кількість типів записів і типів наборів.
  • 2. Між двома типами запису може бути визначено будь-яку кількість типів наборів.
  • 3. Тип запису може бути власником і одночасно членом декількох типів наборів.

Допускається додавання нового запису в якості примірника власника, якщо запис-член відсутня.

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

Набори можуть бути декількох різновидів.

1. З одними і тими ж типами записів, але різними типами наборів.

Сингулярний набір

Рис. 6.2. Сингулярний набір

  • 2. Набори з трьох і більше записів, у тому числі зі зворотним зв'язком.
  • 3. Сингулярний набір (тільки один екземпляр). У такого набору немає природного власника і в якості його виступає система (рис. 6.2). Надалі такі набори можуть придбати запис-власника.

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

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

Багаточленний набір

Рис. 6.3. Багаточленний набір

"Монографія". Примірник деякого типу Многочленом набору включає в себе один примірник запису-власника і всі пов'язані з ним екземпляри записів-членів заданих типів. У конкретних СУБД концепція Многочленом набору може бути не реалізована.

У мережній БД можливі наступні способи доступу:

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

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

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

На графічній діаграмі схеми БД тип набору зображується пойменованої дугою між відповідними типами записів: дуга виходить з типу запису-власника набору і заходить в тип запісі- члена набору.

У моделі КОДЛСІЛ основним внутрішнім обмеженням цілісності є функціональність зв'язків, т. Е. За допомогою наборів можна реалізувати безпосередньо зв'язку типу 1: 1, 1: М, М: 1. У моделі це перше внутрішнє обмеження виражається твердженням: в конкретному екземплярі набору екземпляр запісі- члена набору може мати не більше одного примірника запису-власника набору. Отже, число примірників набору деякого типу в точності дорівнює числу екземплярів записів-власників цього типу набору в БД. При цьому екземпляр набору може бути і порожнім, т. Е. Складатися з примірника запису-власника (екземпляри записів-членів можуть бути відсутніми в деякі моменти часу при функціонуванні системи).

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

Функціональний характер реалізованих зв'язків не дозволяє безпосередньо представляти в моделі тип "багато до багатьох". Для представлення зв'язку типу М: N вводять допоміжний тип запису і дві функціональні зв'язку типу 1: М (див. Рис. 4.7).

 
< Попер   ЗМІСТ   Наст >