1. 5. Що є СУБД в цілому - функції і структура
2. 5.1 Основні функції СУБД
3. 5.1.1 Безпосереднє управління даними у зовнішній пам'яті
4. 5.1.2 Управління буферами оперативної пам'яті
5. 5.1.3 Управління транзакціями
6. 5.1.4 Журналізація
7. 5.1.5 Мови БД
8. 5.2 Типова організація сучасної СУБД
9. 6. Так, були кошти (управління базами даних) в наш час ...
10. 6.1 Основні особливості систем, заснованих на інвертованих списках.
11. 6.1.1 Структури даних
12. 6.1.2 Маніпулювання даними
13. 6.1.3 Обмеження цілісності
14. 6.2 Ієрархічні системи
15. 6.2.1 Ієрархічні структури даних
16. 6.2.2 Маніпулювання даними
17. 6.2.3 Обмеження цілісності
18. 6.3 Мережеві системи
19. 6.3.1 Мережеві структури даних
20. 6.3.2 Маніпулювання даними
21. 6.3.3 Обмеження цілісності
22. 6.4 Переваги і недоліки

С.Д. Кузнецов

Інститут системного програмування РАН, Асоціація користувачів ОС UNIX (SUUG), Московська секція ACM SIGMOD, [email protected]

5. Що є СУБД в цілому - функції і структура 6. Так, були кошти (управління базами даних) в наш час ...

5. Що є СУБД в цілому - функції і структура

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

5.1 Основні функції СУБД

До числа функцій СУБД (з користю для користувачів систем) прийнято відносити наступне:

5.1.1 Безпосереднє управління даними у зовнішній пам'яті

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

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

5.1.2 Управління буферами оперативної пам'яті

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

5.1.3 Управління транзакціями

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

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

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

5.1.4 Журналізація

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

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

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

У всіх випадках дотримуються стратегії "упреждающей" записи в журнал (так званого протоколу Write Ahead Log - WAL). Грубо кажучи, ця стратегія полягає в тому, що запис про зміну будь-якого об'єкта БД повинна потрапити в зовнішню пам'ять журналу раніше, ніж змінений об'єкт потрапить у зовнішню пам'ять основної частини БД. Відомо, якщо в СУБД коректно дотримується протокол WAL, то за допомогою журналу можна вирішити всі проблеми відновлення БД після будь-якого збою.

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

При м'якому збої у зовнішній пам'яті основної частини БД можуть перебувати об'єкти, модифіковані транзакціями, що не закінчилися до моменту збою, і можуть бути відсутніми об'єкти, модифіковані транзакціями, які до моменту збою успішно завершилися (через використання буферів оперативної пам'яті, вміст яких при м'якому збої пропадає ). При дотриманні протоколу WAL у зовнішній пам'яті журналу повинні гарантовано перебувати записи, які відносяться до операцій модифікації обох видів об'єктів. Метою процесу відновлення після м'якого збою є стан зовнішньої пам'яті основної частини БД, яке виникло б при фіксації в зовнішній пам'яті змін всіх завершилися транзакцій і яке не містило б ніяких слідів незакінчених транзакцій. Щоб цього домогтися, спочатку виробляють відкат незавершених транзакцій (undo), а потім повторно відтворюють (redo) ті операції завершених транзакцій, результати яких не відображені у зовнішній пам'яті. Цей процес містить багато тонкощів, пов'язаних із загальною організацією управління буферами і журналом. Більш детально ми розглянемо це у відповідній лекції.

Для відновлення БД після жорсткого збою використовують журнал і архівну копію БД. Грубо кажучи, архівна копія - це повна копія БД до моменту початку заповнення журналу (мається багато варіантів більш гнучкою трактування сенсу архівної копії). Звичайно, для нормального відновлення БД після жорсткого збою необхідно, щоб журнал не пропав. Як вже зазначалося, до збереження журналу в зовнішній пам'яті в СУБД пред'являються особливо підвищені вимоги. Тоді відновлення БД полягає в тому, що виходячи з архівної копії за журналом відтворюється робота всіх транзакцій, які закінчилися до моменту збою. В принципі можна навіть відтворити роботу незавершених транзакцій і продовжити їх роботу після кінця відновлення. Однак в реальних системах це зазвичай не робиться, оскільки процес відновлення після жорсткого збою є досить тривалим.

5.1.5 Мови БД

Для роботи з базами даних використовуються спеціальні мови, в цілому звані мовами баз даних. У ранніх СУБД підтримувалося декілька спеціалізованих за своїми функціями мов. Найчастіше виділялися два - мова визначення схеми БД (SDL - Schema Definition Language) і мова маніпулювання даними (DML - Data Manipulation Language). SDL служив головним чином для визначення логічної структури БД, тобто тієї структури БД, якою вона представляється користувачам. DML містив набір операторів маніпулювання даними, тобто операторів, що дозволяють заносити дані в БД, видаляти, модифікувати або вибирати існуючі дані. Ми розглянемо більш докладно мови ранніх СУБД в наступній лекції.

В сучасних СУБД зазвичай підтримується єдиний інтегрований мову, що містить всі необхідні засоби для роботи з БД, починаючи від її створення і забезпечує базовий призначений для користувача інтерфейс з базами даних. Стандартним мовою найбільш поширених в даний час реляційних СУБД є мова SQL (Structured Query Language). У кількох лекціях цього курсу мову SQL буде розглядатися досить докладно, а поки ми перерахуємо основні функції реляційної СУБД, підтримувані на "мовному" рівні (тобто функції, підтримувані при реалізації інтерфейсу SQL).

Перш за все мова SQL поєднує засоби SDL і DML, тобто дозволяє визначати схему реляційної БД і маніпулювати даними. При цьому іменування об'єктів БД (для реляційної БД - іменування таблиць і їх стовпців) підтримується на мовному рівні в тому сенсі, що компілятор мови SQL виробляє перетворення імен об'єктів в їх внутрішні ідентифікатори на підставі спеціально підтримуваних службових таблиць-каталогів. Внутрішня частина СУБД (ядро) взагалі не працює з іменами таблиць і їх стовпців.

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

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

Нарешті, авторизація доступу до об'єктів БД виробляється на основі спеціального набору операторів SQL. Ідея полягає в тому, що для виконання операторів SQL різного виду користувач повинен володіти різними повноваженнями. Користувач, який створив таблицю БД, володіє повним набором повноважень для роботи з цією таблицею. У їх число входить повноваження на передачу всіх або частини повноважень іншим користувачам, включаючи повноваження на передачу повноважень. Повноваження користувачів описуються в спеціальних таблицях-каталогах, контроль повноважень підтримується на мовному рівні.

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

5.2 Типова організація сучасної СУБД

Природно, організація типовою СУБД і склад її компонентів відповідає розглянутому нами набору функцій. Нагадаємо, що ми виділили такі основні функції СУБД:

• управління даними у зовнішній пам'яті;
• управління буферами оперативної пам'яті;
• управління транзакціями;
• журнализация і відновлення БД після збоїв;
• підтримка мов БД.

Логічно в сучасній реляційної СУБД можна виділити найбільш внутрішню частину - ядро ​​СУБД (часто його називають Data Base Engine), компілятор мови БД (зазвичай SQL), підсистему підтримки часу виконання, набір утиліт. У деяких системах ці частини виділяються явно, в інших - ні, але логічно такий поділ можна провести у всіх СУБД.

Ядро СУБД відповідає за управління даними у зовнішній пам'яті, управління буферами оперативної пам'яті, управління транзакціями і журнализацию. Відповідно можна виділити такі компоненти ядра (принаймні, логічно, хоча в деяких системах ці компоненти виділяються явно), як менеджер даних, менеджер буферів, менеджер транзакцій і менеджер журналу. Як можна було зрозуміти з першої частини цієї лекції, функції цих комонентов взаємопов'язані, і для забезпечення коректної роботи СУБД всі ці компоненти повинні взаємодіяти з ретельно продуманим і перевіреним протоколах. Ядро СУБД має власний інтерфейс, який недоступний користувачам безпосередньо і використовуються в програмах, вироблених компілятором SQL (або в підсистемі підтримки виконання таких програм), і утиліти БД. Ядро СУБД є основною резидентної частиною СУБД. При використанні архітектури "клієнт-сервер" ядро ​​є основним складовим серверної частини системи.

Основна функція компілятора мови БД - компіляція операторів мови БД в деяку виконувану програму.

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

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

6. Так, були кошти (управління базами даних) в наш час ...

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

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

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

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

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

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

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

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

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

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

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

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

6.1.1 Структури даних

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

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

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

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

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

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

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

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

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

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

• LOCATE FIRST - знайти перший запис таблиці T у фізичному порядку; повертає адресу записи;
• LOCATE FIRST WITH SEARCH KEY EQUEL - знайти перший запис таблиці T в порядку ключа пошуку K з заданим значенням K; повертає адресу записи;
• LOCATE NEXT - знайти перший запис, наступну за записом з заданим адресою в заданому шляху доступу; повертає адресу записи;
• LOCATE NEXT WITH SEARCH KEY EQUEL - знайти такий запис таблиці T в порядку шляхи пошуку з заданим значенням K; має бути відповідність між використовуваним способом сканування і ключем K; повертає адресу записи;
• LOCATE FIRST WITH SEARCH KEY GREATER - знайти перший запис таблиці T в порядку ключа пошуку K зі значенням ключового поля, великим заданого значення K; повертає адресу записи;
• RETRIVE - вибрати запис з вказаною адресою;
• UPDATE - оновити запис з вказаною адресою;
• DELETE - видалити запис з вказаною адресою;
• STORE - включити запис в зазначену таблицю; операція генерує адреса записи.

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

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

6.2 Ієрархічні системи

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

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

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

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

Приклад типу дерева (схеми ієрархічної БД):

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

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

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

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

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

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

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

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

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

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

6.3 Мережеві системи

Типовим представником є ​​Integrated Database Management System (IDMS) компанії Cullinet Software, Inc., призначена для використання на машинах основного класу фірми IBM під управлінням більшості операційних систем. Архітектура системи заснована на пропозиціях Data Base Task Group (DBTG) Комітету з мов програмування Conference on Data Systems Languages ​​(CODASYL), організації, відповідальної за визначення мови програмування Кобол. Звіт DBTG був опублікований в 1971 році, а в 70-х роках з'явилося кілька систем, серед яких IDMS.

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

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

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

Тип зв'язку визначається для двох типів запису: предка і нащадка. Примірник типу зв'язку складається з одного примірника типу записи предка і упорядкованого набору примірників типу записи нащадка. Для даного типу зв'язку L з типом запису предка P і типом запису нащадка C повинні виконуватися дві умови:

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

На формування типів зв'язку не накладаються особливі обмеження; можливі, наприклад, ситуації:

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

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

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

d) Може існувати будь-яке число типів зв'язку з одним і тим же типом запису предка і одним і тим же типом запису нащадка; і якщо L1 і L2 - два типи зв'язку з одним і тим же типом запису предка P і одним і тим же типом запису нащадка C, то правила, за якими утворюється споріднення, в різних зв'язках можуть відрізнятися.

e) Типи записи X і Y можуть бути предком і нащадком в одній зв'язку і нащадком і предком - в інший.

f) Предок і нащадок можуть бути одного типу запису.

Простий приклад мережевий схеми БД:

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

Зразковий набір операцій може бути таким:

• Знайти певний запис в наборі однотипних записів (інженера Сидорова);
• Перейти від предка до першого нащадку за деякою зв'язку (до першого співробітнику відділу 310);
• Перейти до наступного нащадку у деякому зв'язку (від Сидорова до Іванова);
• Перейти від нащадка до предка за деякою зв'язку (знайти відділ Сидорова);
• Створити новий запис;
• Знищити запис;
• Змінити запис;
• Включити в зв'язок;
• Виключити з зв'язку;
• Переставити в інший зв'язок і т.д.

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

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

6.4 Переваги і недоліки

Переваги ранніх СУБД:

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

недоліки:

• Занадто складно користуватися;
• Фактично необхідні знання про фізичну організації;
• Прикладні системи залежать від цієї організації;
• Їх логіка перевантажена деталями організації доступу до БД.

Продовження в наступному номері.

*) Продовження. Початок див. СУБД # 1