Навігація
Головна
 
Головна arrow Інформатика arrow Бази даних
< Попередня   ЗМІСТ   Наступна >

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

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

Спочатку описується логічна структура моделі даних (МД), потім - процеси використання побудованої БД за допомогою запропонованого Е.Ф. Коддом мови Альфа [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).

 
Якщо Ви помітили помилку в тексті позначте слово та натисніть Shift + Enter
< Попередня   ЗМІСТ   Наступна >
 
Дисципліни
Агропромисловість
Аудит та Бухоблік
Банківська справа
БЖД
Географія
Документознавство
Екологія
Економіка
Етика та Естетика
Журналістика
Інвестування
Інформатика
Історія
Культурологія
Література
Логіка
Логістика
Маркетинг
Медицина
Нерухомість
Менеджмент
Педагогіка
Політологія
Політекономія
Право
Природознавство
Психологія
Релігієзнавство
Риторика
Соціологія
Статистика
Техніка
Страхова справа
Товарознавство
Туризм
Філософія
Фінанси
Пошук