Лекція 3 Дореляційні підходи до організації та дореляційні моделі бд 2 год



Скачати 203.69 Kb.
Дата конвертації22.04.2017
Розмір203.69 Kb.
Лекція 3

  1. Дореляційні підходи до організації та дореляційні моделі БД – 2 год

    1. Спільні риси дореляційних систем організації БД

    2. Основні особливості систем на базі інвертованих списків

      1. Структури даних

      2. Маніпулювання даними

      3. Обмеження цілісності

    3. Ієрархічні моделі БД

      1. Ієрархічні структури даних

      2. Маніпулювання даними

      3. Обмеження цілісності

    4. Мережеві моделі БД

      1. Мережеві структури даних

      2. Маніпулювання даними

      3. Обмеження цілісності


1.1. Спільні риси дореляційних систем організації БД

Перш, ніж перейти до детального і послідовного вивчення реляційних систем БД, зупинимося коротко на ранніх (дореляційних) СУБД. У цьому є сенс по трьох причинах:



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

  • по-друге, внутрішня організація реляційних систем багато в чому заснована на використанні методів ранніх систем;

  • по-третє, деяке знання в області ранніх систем буде корисно для розуміння шляхів розвитку постреляційних СУБД.

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

Почнемо з деяких найбільш загальних характеристик ранніх систем:



  1. Ці системи активно використовувалися протягом багатьох років, довше, ніж використовується яка-небудь з реляційних СУБД. Насправді деякі з ранніх систем використовуються навіть у наш час, накопичені величезні бази даних, і однією з актуальних проблем інформаційних систем є використання цих систем разом із сучасними системами.

  2. Усі ранні системи не ґрунтувалися на яких-небудь абстрактних моделях. Як ми згадували, поняття моделі даних фактично узаконилося серед фахівців в області БД тільки разом з реляційним підходом. Абстрактні представлення ранніх систем з'явилися пізніше на основі аналізу і виявлення загальних ознак у різних конкретних систем.

  3. У ранніх системах доступ до БД провадився на рівні записів. Користувачі цих систем здійснювали явну навігацію в БД, використовуючи мови програмування, розширені функціями СУБД. Інтерактивний доступ до БД підтримувався тільки шляхом створення відповідних прикладних програм із власним інтерфейсом.

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

  5. Навігаційна природа ранніх систем і доступ до даних на рівні записів змушували користувача самого робити всю оптимізацію доступу до БД, без якої-небудь підтримки системи.

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


    1. Основні особливості систем на базі інвертованих списків

      1. Структури даних

      2. Маніпулювання даними

      3. Обмеження цілісності

До найбільш відомих і типових представників таких систем відносяться Datacom/DB компанії Applied Data Research, Inc. (ADR), орієнтована на використання на машинах основного класу фірми IBM, і Adabas компанії Software AG.

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




      1. Структури даних

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

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

  2. Фізична упорядкованість рядків усіх таблиць може визначатися і для всієї БД (так робиться, наприклад, у Datacom/DB).

  3. Для кожної таблиці можна визначити довільне число ключів пошуку, для яких будуються індекси. Ці індекси автоматично підтримуються системою, але явно видні користувачам.

      1. Маніпулювання даними

Підтримуються два класи операторів:

  1. Оператори, що встановлюють адресу запису, серед яких:

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

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

b. Оператори над адресованими записами

Типовий набір операторів:



  • LOCATE FIRST - знайти перший запис таблиці T у фізичному порядку; повертає адресу запису;

  • LOCATE FIRST WITH SEARCH KEY EQUAL - знайти перший запис таблиці T із заданим значенням ключа пошуку K; повертає адресу запису;

  • LOCATE NEXT - знайти перший запис, що іде за записом із заданою адресою у заданому шляху доступу; повертає адресу запису;

  • LOCATE NEXT WITH SEARCH KEY EQUAL - знайти наступний запис таблиці T у порядку шляху пошуку із заданим значенням K; повинна бути відповідність між використовуваним способом сканування і ключем K; повертає адресу запису;

  • LOCATE FIRST WITH SEARCH KEY GREATER - знайти перший запис таблиці T у порядку ключа пошуку K зі значенням ключового поля, більшим заданого значення K; повертає адресу запису;

  • RETRIVE - вибрати запис із зазначеною адресою;

  • UPDATE - обновити запис із зазначеною адресою;

  • DELETE - видалити запис із зазначеною адресою;

STORE - уключити запис у зазначену таблицю; операція генерує адресу запису.
1.2.3. Обмеження цілісності

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



    1. Ієрархічні моделі БД

      1. Ієрархічні cтруктури даних

      2. Маніпулювання даними

      3. Обмеження цілісності

Типовим представником (найбільш відомим і поширеним) є Information Management System (IMS) фірми IBM. Перша версія з'явилася в 1968 р. Дотепер підтримується багато баз даних, що створює істотні проблеми з переходом як на нову технологію БД, так і на нову техніку.


      1. Ієрархічні структури даних

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

Організація даних у СУБД ієрархічного типу визначається в термінах: елемент, агрегат, запис (група), групове відношення, база даних.



  • Атрибут (елемент даних) - найменша одиниця структури даних. Звичайно кожному елементу при описі бази даних присвоюється унікальне ім'я. По цьому імені до нього звертаються при обробці. Елемент даних також часто називають полем.

  • Запис - іменована сукупність атрибутів. Використання записів дозволяє за одне звертання до бази отримати деяку логічно зв'язану сукупність даних. Самі записи змінюються, додаються і видаляються. Тип запису визначається складом його атрибутів. Екземпляр запису - конкретний запис із конкретним значенням елементів

  • Групове відношення - ієрархічне відношення між записами двох типів. Батьківський запис (власник групового відношення) називається вихідним записом, а дочірні записи (члени групового відношення) - підлеглими. Ієрархічна база даних може зберігати тільки такі деревоподібні структури.

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

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

При графічному зображенні групові відносини зображують дугами орієнтованого графа, а типи записів - вершинами (діаграма Бахмана).

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

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

Організація ієрархічної деревоподібної структури:



  • усі типи зв'язків повинні бути функціональними (1:1, 1:M, M:1);

  • дерево являє собою неорієнтований граф, що не містить циклів.

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

  • у дереві кожен вузол i-рівня зв'язаний тільки з одним батьківським вузлом (i-1)-рівня (будь-який син може мати не більш одного рідного батька, а будь-який батько - безліч синів);

  • дуга дерева відповідає типу зв'язку "вихідний-породжений";

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

  • всі екземпляри даного типу нащадка з загальним екземпляром типу предка називаються близнюками.

Для БД визначений повний порядок обходу - униз, праворуч; існує єдиний лінійний ієрархічний шлях доступу до будь-якого вузла, починаючи з кореня дерева.
Приклад типу дерева (схеми ієрархічної БД):

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

База даних із такою схемою могла б виглядати в такий спосіб (ми показуємо один екземпляр дерева):

Способи опису конкретних схем, що базуються на ієрархічній моделі (ІМ), і відповідні мови маніпулювання даними залежать від конкретної реалізації. Нижче наведений приклад графічного представлення ЇМ тематичних збірників видавництв, вигляд певної конкретної бази даних і опис схеми ЇМ у системі IMS фірми IBM.



Dbd Name = Тематичні збірники

Segm Name = Видавництво

Field Name = Назва

Field Name = Адреса

Field Name = Рахунок

Segm Name = Збірник, Parent = Видавництво

Field Name = Назва

Field Name = Періодичність

Field Name = Ціна

Field Name = Відповідальний_редактор

Segm Name = Стаття, Parent = Збірник

Field Name = Назва

Segm Name = Автор, Parent = Стаття

Field Name = ПІБ

Field Name = Гонорар

У IMS використовувалася оригінальна і нестандартна термінологія: "сегмент" замість "запис", а під "записом БД" розумілося все дерево сегментів.

Ще один приклад:

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

Тому, для інформаційної системи управління персоналом необхідно створити групове відношення, що складається з батьківського запису ВІДДІЛ (НАЙМЕНУВАННЯ_ВІДДІЛУ, ЧИСЛО_ПРАЦІВНИКІВ) і дочірнього запису СПІВРОБІТНИК (ПРІЗВИЩЕ, ПОСАДА, ОКЛАД). Це відношення показане на мал. (а) (Для простоти покладається, що є тільки два дочірні записи).

Для автоматизації обліку контрактів із замовниками необхідне створення ще однієї ієрархічної структури : замовник - контракти з ним - співробітники, задіяні в роботі над контрактом. Це дерево буде включати записи ЗАМОВНИК(НАЙМЕНУВАННЯ_ЗАМОВНИКА, АДРЕСА), КОНТРАКТ(НОМЕР, ДАТА,СУМА), ВИКОНАВЕЦЬ (ПРІЗВИЩЕ, ПОСАДА, НАЙМЕНУВАННЯ_ВІДДІЛУ) (мал. (b)).





Рис.

З цього прикладу видні недоліки ієрархічних БД:



  • Частково дублюється інформація між записами СПІВРОБІТНИК і ВИКОНАВЕЦЬ (такі записи називають парними), причому в ієрархічній моделі даних не передбачена підтримка відповідності між парними записами.

Ієрархічна модель реалізує відношення між вихідним і дочірнім записом за схемою 1:N, тобто одного батьківського запису може відповідати будь-як кількість дочірніх . Припустимо тепер, що виконавець може брати участь більш ніж в одному контракті (тобто виникає зв'язок типу M:N). У цьому випадку в базу даних необхідно ввести ще одне групове відношення, у якому ВИКОНАВЕЦЬ буде вихідним записом, а КОНТРАКТ - дочірньої (мал. (c)). Таким чином, ми знову змушені дублювати інформацію.


      1. Маніпулювання даними

В ієрархічній моделі визначені наступні операції над даними:

  • ДОДАТИ в базу даних новий запис. Для кореневого запису обов'язкове формування значення ключа.

  • ЗМІНИТИ значення даних попередньо витягненого запису. Ключові дані не повинні піддаватися змінам.

  • ВИДАЛИТИ деякий запис і всі підлеглі йому записи.

  • ВИТЯГТИ:

  • витягти кореневий запис за ключовим значенням, допускається також послідовний перегляд кореневих записів

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

В операції ВИТЯГТИ допускається завдання умов вибірки (наприклад, витягти співробітників з окладом більш 1 тисячі руб.)

Оператори маніпулювання ієрархічно організованими даними


Знайти зазначене дерево БД (наприклад, лікарню ©40); Перейти від одного дерева до іншого; Перейти від одного запису до іншого усередині дерева (наприклад, від палати - до першого пацієнта); Перейти від одного запису до іншої в порядку обходу ієрархії; Уставити новий запис у зазначену позицію; Видалити поточний запис.

Прикладами типових операторів маніпулювання ієрархічно організованими даними можуть бути наступні:



  • Знайти зазначене дерево БД (наприклад, відділ 310);

  • Перейти від одного дерева до іншого;

  • Перейти від одного запису до іншго усередині дерева (наприклад, від відділу - до першого співробітника);

  • Перейти від одного запису до іншої в порядку обходу ієрархії;

  • Уставити новий запис у зазначену позицію;

  • Видалити поточний запис.

Мова доступу до даних, яку підтримує IMS, дозволяє звертатися до елементів прямо, знаючи назву і, можливо, додаткову умову. Наприклад, можна роздрукувати назву всіх збірників, відповідальним редактором яких є Іванов:

Get Unique Збірник Where Відповідальний_редактор = "Іванов"

/* одержали перший збірник */

While true do

Print Збірник.Назва

Get next Збірник Where Відповідальний_редактор = "Іванов"

End while

Вибравши один зі збірників у попередньому прикладі, можна спуститися "униз" по ієрархії (оператор Get next Within Parent дозволяє перебрати всі элементы-потомки, що належать обраному елементу) і, наприклад, переглянути одну з статей чи кілька статей з обраного збірника

Get Unique Збірник Where Відповідальний_редактор = "Іванов"
/* одержали перший збірник */

While true do

Print "Збірник", Збірник.Назва

Get next Within Parent Статтья

While true do

Print Статтья.Назва

Get next Within Parent Стаття

End while

Get next Збірник Where Відповідальний_редактор = "Іванов"

End while


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

Недоліки ЇМ:

1. Операції маніпулювання даними в ієрархічних системах орієнтовані насамперед на пошук інформації вниз, тобто за даним екземпляром сегмента-батька можна знайти всі екземпляри сегментів-синів. Зворотний пошук утруднений, а часто і неможливий. Наприклад, наведений вище запит працює надзвичайно швидко, оскільки напрямок пошуку збігається зі схемою ієрархії. Однак спроба реалізувати запит типу "У скількох збірниках статей опублікував свої статті пан Петров?" може виявитися дуже важкою задачею

2. Дублювання даних на логічному рівні.

3. Для представлення зв'язку M:N необхідне дублювання дерев.4. У ЇМ автоматично підтримується цілісність посилань між предками і нащадками за правилом: ніякий нащадок не може існувати без свого батька. Цілісність за посиланнями між записами, що не входять в одну ієрархію, не підтримується. Тому неможливо збереження в БД породженого вузла без відповідного вихідного. Аналогічно, видалення вихідного вузла тягне видалення всіх породжених вузлів (дерев), зв'язаних з ним.




      1. Обмеження цілісності

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

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

В ієрархічних системах підтримувалася деяка форма представлень БД на основі обмеження ієрархії. Прикладом представлення наведеної вище БД може бути ієрархія



    1. Мережеві моделі БД

      1. Мережеві структури даних

      2. Маніпулювання даними

      3. Обмеження цілісності

      1. Мережеві структури даних

На розробку цього стандарту великий вплив зробив американський учений Ч.Бахман. Мережний підхід до організації даних є розширенням ієрархічного. Архітектура мережної моделі заснована на пропозиціях Data Base Task Group (DBTG) Комітету з мов програмування Conference on Data Systems Languages (CODASYL), 1971р.

Основні принципи мережної моделі даних були разработны в середині 60-х років, еталонний варіант мережної моделі даних описаний у звітах робочої групи по мовах баз даних (Cоnference on Dаta System Languages) CODASYL (1971 р.).



Ціль розроблювачів: створення моделі, що дозволяє описувати зв'язки M:N і що дозволяє зменшити недоліки ІМ.

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

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

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



Внутрішні особливості ММ:

1. Усі типи зв'язків повинні бути функціональними (1:1, 1:M, M:1); У моделі це внутрішнє обмеження виражається твердженням: для даного типу зв'язку L з типом запису предка P і типом запису нащадка C (набору) повинні виконуватися наступні дві умови:



  • Кожен екземпляр типу P є предком тільки в одному екземплярі L;

  • Кожен екземпляр C є нащадком не більш, ніж в одному екземплярі L.

  1. Екземпляр запису може бути членом тільки одного екземпляра набору серед всіх екземплярів набору одного типу (він може входити до складу двох і більш екземплярів наборів, але різних типів).

  2. Для представлення зв'язку M:N уводиться додатковий тип запису і два функціональні зв'язки типу 1:M і M:1. При необхідності запис-зв'язування може містити додаткову інформацію.



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


Ієрархічна структура з попереднього приклада перетворюється в мережеву в такий спосіб (див. мал. нижче):

  • для відображення типу M:N уводиться запис СПІВРОБІТНИК_КОНТРАКТ, що не має полів і служить тільки для зв'язку записів КОНТРАКТ і СПІВРОБІТНИК, див. мал. .(Відзначимо, що в цьому записі може зберігатися і корисна інформація, наприклад, частка даного співробітника в спільній винагороді за даним контрактом.)

Рис. 3.2
Кожен екземпляр групового відношення характеризується наступними ознаками:


  • спосіб упорядкування підлеглих записів:

  • довільний,

  • хронологічний /черга/,

  • зворотний хронологічний /стік/,

  • сортований.

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

  • режим включення підлеглих записів:

  • автоматичний - неможливо занести в БД запис без того, щоб вона була відразу ж закріплена за деяким власником;

  • ручний - дозволяє запам'ятати в БД підлеглий запис і не включати його негайно в екземпляр групового відношення. Ця операція пізніше ініціюється користувачем).

  • режим виключення Прийнято виділяти три класи членства підлеглих записів у групових відносинах:

  1. Фіксоване. Підлеглий запис жорстко зв'язаний із записом власником і його можна виключити з групового відношення, тільки видаливши. При видаленні запису-власника всі підлеглі записи автоматично теж видаляються. У розглянутому вище прикладі фіксоване членство припускає групове відношення "УКЛАДАЄ" між записами "КОНТРАКТ" і "ЗАМОВНИК", оскільки контракт не може існувати без замовника.

  2. Обов'язкове. Допускається переключення підлеглого запису на іншого власника, але неможливо його існування без власника. Для видалення запису-власника необхідно, щоб він не мала підлеглих записів з обов'язковим членством. Таким відношенням зв'язані записи "СПІВРОБІТНИК" і "ВІДДІЛ". Якщо відділ розформовується, усі його співробітники повинні бути або переведені в інші відділи, або звільнені.

  3. Необов'язкове. Можна виключити запис із групового відношення, але зберегти його в базі даних не прикріплюючи до іншого власнику. При видаленні запису-власника його підлеглі записи - необов'язкові члени зберігаються в базі, не беручи участь більш у груповому відношенні такого типу. Прикладом такого групового відношення може служити "ВИКОНУЄ" між "СПІВРОБІТНИКИ" і "КОНТРАКТ", оскільки в організації можуть існувати працівники, чия діяльність не зв'язана з виконанням яких-небудь договірних зобов'язань перед замовниками.

Обмеження на типи записів і зв'язків ММ: Тип запису нащадка у одному типові зв'язку L1 може бути типом запису предка у іншому типові запису L2 (як в ієрархії)

Даний тип запису Р може бути типом запису предка у довільній кількості типів зв'язків



Даний тип запису Р може бути типом запису нащадка у довільній кількості типів зв'язків



Може існувати довільна кількість типів зв'язку з одним й тим самим типом запису предка й одним тим самим типом запису нащадка; при цьому, якщо L1 та L2 – два типи зв'язку з одним і тим самим типом запису предка та одним й тим самим типом запису нащадка С, то правила, за якими утворюється споріднення, можуть відрізнятися



Типи записів Х та У можуть бути предком та нащадком у одному зв'язку і нащадком та предком – у іншому.


Предок та нащадок можуть бути записами одного типу. СМ може містити цикли, коли попередня вершина волночас є наступною. Зв'язок записів одного типу називають петлею.




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



      1. Маніпулювання даними

У мережевій моделі підтримуються наступні операції над даними:

  • ДОДАТИ - внести запис у БД і, у залежності від режиму включення, або включити його в групове відношення, де він оголошений підлеглим, або не включати ні в яке групове відношення.

  • ВКЛЮЧИТИ В ГРУПОВЕ ВІДНОШЕННЯ - зв'язати існуючий підлеглий запис із записом-власником.

  • ПЕРЕКЛЮЧИТИ - зв'язати існуючий підлеглий запис з іншим записом-власником у тому же груповому відношенні.

  • ОБНОВИТИ - змінити значення елементів попередньо витягнутого запису.

  • ВИТЯГТИ - витягти записи послідовно за значенням ключа, а також використовуючи групові відношення - від власника можна перейти до записів - членам, а від підлеглого запису до власника набору.

  • ВИДАЛИТИ - забрати з БД запис. Якщо цей запис є власником групового відношення, то аналізується клас членства підлеглих записів. Обов'язкові члени повинні бути попередньо виключені з групового відношення, фіксовані вилучені разом із власником, необов'язкові залишаться в БД.

  • ВИКЛЮЧИТИ З ГРУПОВОГО ВІДНОШЕННЯ - розірвати зв'язок між записом-власником і записом-членом.

Операції маніпулювання даними:

  • Знайти конкретний запис у наборі однотипних записів (палату з зазначеним номером);

  • Перейти від предка до першого нащадка по деякому зв'язку (до першого лікаря деякої лікарні);

  • Перейти до наступного нащадку в деякому зв'язку (від лікаря Сидорова до Іванова);

  • Перейти від нащадка до предка по деякому зв'язку (знайти лікарню лікаря Сидорова);

  • Створити новий запис;

  • Знищити запис;

  • Модифікувати запис;

  • Включити в зв'язок;

  • Виключити зі зв'язку;

  • Переставити в інший зв'язок і т.д.

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


Record name is Видавництво

01 Назва Type is Character 30

01 Адреса Type is Character 30

01 Рахунок Type is Picture "999999999"

Record name is Збірник

01 Назва Type is Character 30

01 Періодичність Type is fixed

01 Ціна Type is fixed

01 Відповідальний_редактор Type is Character 20

Record name is Стаття

01 Назва Type is Character 80

Record name is Автор

01 ПІБ Type is Character 20

01 Гонорар Type is fixed

Set name is Випускає

Owner is Видавництво

Member is Збірник

Set name is Містить

Owner is Збірник

Member is Стаття

. . . . . . . . . . . . . . .

Будь-яка мережева структура може бути наведена до більш простого вигляду введенням надмірності. У деяких випадках виникаюча при цьому надмірність мала і є припустимою, в інших випадках вона може бути надмірною.





      1. Обмеження цілісності

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

    1. Преимущества и недостатки моделей

ІМ (ієрархічна модель) : забезпечує незалежність за даними, але не забезпечує структурну незалежність.

Переваги:



  1. забезпечує сумісне використання даних;

  2. концептуальна простота забезпечується відношенням предок-нащпдок;

  3. цілісність БД забезпечується відношенням предок-нащпдок;

  4. ефективно працює з постійними зв'язками 1:М.

Недоліки:


  1. навігаційна система ускладнює проектування, впровадження, розробку додатків, застосування і керування;

  2. обмеження у реалізації (відсутність зв'язків М:N чи зв'язків з кількома предками);

  3. відсутність у СУБД мови визначення даних чи мови маніпулювання даними;

  4. відсутність стандартизації


ММ (мережева модель): забезпечує незалежність за даними, але не забезпечує структурну незалежність.

Переваги:



  1. концептуальна простота, принаймні, порівняльна з ІМ;

  2. обробка великої кількості типів зв'язків, таких, як, наприклад, М:N, та зв'язків з багатьмв предками;

  3. відношення власник/член забезпечує цілісність БД;

  4. стандартизація;

  5. у СУБД включено мову визначення даних та мову маніпулювання даними

Недоліки:


  1. складність система доступу до даних зменшує її ефективність (навігаційний метод доступа до даних);

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

Реляційна модель забезпечує незалежність за даними і структурну незалежність.

Переваги:

  1. табличне представлення суттєво покращує концептуальну простоту, що спрощує проектування, впровадження, розробку додатків, застосування і керування.БД

  2. можливість обробки нерегламентованих запитів на основі SQL;

  3. потужна РСУБД спрощує реалізацію і впровадження.

Недоліки:

  1. потужна РСУБД висуває підвищені вимоги додо обладнання та системного програмного забезпечення;

  2. концептуальна простота системи допускає можливість поганого використання хорошої системи некваліфікованим користувачем;

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


База даних захищена авторським правом ©lecture.in.ua 2016
звернутися до адміністрації

    Головна сторінка