Лекція 2. Середовище бази даних

Лекція 2. Середовище бази даних

Лекція 2. Середовище бази даних........................................................................................ 1

Структура цієї лекції.............................................................................................................. 2

2.1. Трьохрівнева архітектура ANSI-SPARC.................................................................. 2

2.1.1. Зовнішній рівень..................................................................................................... 4

2.1.2. Концептуальний рівень......................................................................................... 4

2.1.3. Внутрішній рівень................................................................................................... 5

2.1.4. Схеми, відображення й екземпляри................................................................. 5

2.1.5. Незалежність від даних......................................................................................... 7

2.2. Мови баз даних.............................................................................................................. 8

2.2.1. Мова визначення даних - DDL............................................................................ 8

2.2.2. Мова керування даними - DML........................................................................... 9

Процедурні мови DML.......................................................................................................... 9

Не процедурні мови DML.................................................................................................. 10

2.2.3. Мови 4GL................................................................................................................ 10

Генератори форм........................................................................................................ 11

Генератори звітів........................................................................................................ 11

Генератори графічного представлення даних.................................................... 11

Генератори програм................................................................................................... 11

2.3. Моделі даних і концептуальне моделювання....................................................... 11

2.3.1. Об'єктні моделі даних.......................................................................................... 12

2.3.2. Моделі даних на основі записів........................................................................ 13

Реляційна модель даних........................................................................................... 13

Мережна модель даних............................................................................................. 15

Ієрархічна модель даних........................................................................................... 15

2.3.3. Фізичні моделі даних........................................................................................... 16

2.3.4. Концептуальне моделювання........................................................................... 16

2.4. Функції СКБД................................................................................................................. 16

2.4.1. Збереження, витяг і відновлення даних........................................................ 17

2.4.2. Каталог, доступний кінцевим користувачам................................................. 17

2.4.3. Підтримка транзакцій.......................................................................................... 18

2.4.4. Сервисы керування паралельністю................................................................ 18

2.4.5. Сервіси відновлення........................................................................................... 19

2.4.6. Сервіси контролю доступу до даних............................................................... 19

2.4.7. Підтримка обміну даними.................................................................................. 19

2.4.8. Служби підтримки цілісності даних................................................................. 20

2.4.9. Служби підтримки незалежності від даних................................................... 20

2.4.10. Допоміжні служби.............................................................................................. 20

2.5. Компоненти СКБД....................................................................................................... 21

2.6. Архітектура багатокористувачевих СКБД............................................................. 23

2.6.1. Телеобробка.......................................................................................................... 23

2.6.2. Файловий сервер................................................................................................. 24

2.6.3. Технологія „клиент/сервер"................................................................................ 25

2.7. Системні каталоги....................................................................................................... 27

2.7.1. Служба IRDS......................................................................................................... 28

Резюме................................................................................................................................... 29

 

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

· сутностей "реального світу", таких як Staff (Працівник), Property (Об'єкт нерухомості), Owners (Власники об'єктів) і Renters (Орендарі);

· атрибутів, що описують властивості чи якості кожної сутності (наприклад, сутність Staff має атрибути Name-(Ім'я), Address (Адреса) і Salary (Зарплата));

· зв'язків між цими сутностями (наприклад, Staff керує Property).

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

Структура цієї лекції

У розділі 2.1 розглядаються трьохрівнева архітектура ANSI-SPARC і переваги, що досягаються у випадку її використання. У розділі 2.2 розглядаються типи мов, що використовуються в середовищі СКБД, а в розділі 2.3 пояснюються поняття моделей даних і концептуального моделювання, що більш докладно будуть описані в інших главах цієї книги. У розділі 2.4 обговорюються основні функції, що повинна виконувати СКБД, а в розділах 2.5 і 2.6 - архітектура типової СКБД. Завершується ця глава вивченням функціональних можливостей системного каталогу СКБД, у якому зберігаються мета-дані, тобто дані про дані, що зберігаються в цій базі даних. Приклади в цій главі побудовані на основі навчального проекту DreawHowe, описаного в розділі 1.7.

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

Зовнішній рівень

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

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

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

Концептуальний рівень

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

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

· усі сутності, їхні атрибути і зв'язки;

· накладаються на дані обмеження;

· семантична інформація про дані;

· інформація про міри забезпечення безпеки і підтримки цілісності даних.

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

Внутрішній рівень

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

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

· розподіл дискового простору для збереження даних і індексів;

· опис подробиць збереження записів (із указівкою реальних розмірів елементів даних, що зберігаються);

· зведення про розміщення записів;

· зведення про стиск даних і обраних методах їхнього шифрування.

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

Незалежність від даних

Основним призначенням трьохрівневої архітектури є забезпечення незалежності від даних, що означає, що зміни на нижніх рівнях ніяк не впливають на верхні рівні. Розрізняють два типи незалежності від даних: логічну і фізичну.

Логічна Логічна незалежність від даних означає повну захищеність

незалежність зовнішніх схем від змін, внесених у концептуальну

від даних схему.

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

Фізична Фізична незалежність від даних означає захищеність

незалежність концептуальної схеми від змін, внесених у внутрішню

від даних схему.

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

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

Мови баз даних

Внутрішня мова СКБД для роботи з даними складається з двох частин: мови визначення даних (Data Definition Language - DDL) і мови керування даними (Data Manipulation Language - DML). Мова DDL використовується для визначення схеми бази даних, а мова DML - для читання і відновлення даних, збережених у базі. Ці мови називаються підмовами даних, оскільки в них відсутні конструкції для виконання всіх обчислювальних операцій, які звичайно використовуються у мовах програмування високого рівня. У багатьох СКБД передбачена можливість впровадження операторів підмови даних у програми, написаних на таких мовах програмування високого рівня, як COBOL, Fortran, Pascal, Ada чи С. У цьому випадку мову високого рівня прийнято називати базовою мовою (host language). Перед компіляцією файлу програми базовою мовою, що містять впроваджені оператори підмови даних, буде потрібно попередньо видалити ці оператори, замінивши їх викликами відповідних функцій СКБД. Потім цей попередньо оброблений файл звичайним образом компілюється з поміщенням результатів в об'єктний модуль, що компонується з бібліотекою, що містить викликувані в програмі функції СКБД. Після цього отриманий програмний текст буде готовий до виконання. Крім механізму впровадження, для більшості підмов даних також надаються засоби інтерактивного виконання їх операторів, що вводяться користувачем безпосередньо зі свого термінала.

Мова визначення даних - DDL

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

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

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

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

Мова керування даними - DML

Мова DML - м ова, що містить набір операторів для підтримки основних операцій маніпулювання даними, що містилися в базі.

До операцій керування даними відносяться:

· вставка в базу даних нових зведень;

· модифікація зведень, збережених у базі даних;

· витяг зведень, що містяться в базі даних;

· видалення зведень з бази даних.

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

Мови DML відрізняються базовими конструкціями витягу даних. Варто розрізняти два типи мов DML: процедурний і не процедурний. Основна відмінність між ними полягає в тім, що процедурні мови вказують те, як можна одержати результат оператора мови DML, тоді як не процедурні мови описують те, який результат буде отриманий. Як правило, у процедурних мовах запису розглядаються по окремості, тоді як не процедурні мови оперують з цілими наборами записів.

Процедурні мови DML

Процедурна мова DML - мова, що дозволяє повідомити системі про те, які дані необхідні, і точно вказати, якїх можна витягти.

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

Не процедурні мови DML

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

Не процедурні мови DML дозволяють визначити весь набір необхідних даних за допомогою одного оператора чи витягу відновлення. За допомогою не процедурних мов DML користувач указує, які дані йому потрібні, без визначення способуїх одержання. СКБД транслює вираз мовою DML у процедуру (чи набір процедур), що забезпечує маніпулювання викликаним набором записів. Даний підхід звільняє користувача від необхідності знати деталі внутрішньої реалізації структур даних і особливості алгоритмів, які використовуються для витягу і можливого перетворення даних. У результаті робота користувача одержує визначений ступінь незалежності від даних. Не процедурні мови часто також називають декларативними мовами. Реляційні СКБД у тій чи іншій формі звичайно включають підтримку не процедурних мов маніпулювання даними - найчастіше це буває мова структурованих запитів SQL (Structured Query Language) чи мова запитів за зразком QBE (Query-by-Example). Не процедурні мови звичайно простіше зрозуміти і використовувати, чим процедурні мови DML, оскільки користувачем виконується менша частина роботи, а СКБД - велика.

Частина не процедурної мови DML, що відповідає за витяг даних, називається мовою запитів. Мову запитів можна визначити як високорівневу вузькоспеціалізовану мову, яка призначена для задоволення різних вимог по вибірці інформації з бази даних. У цьому змісті термін "запит" зарезервований для позначення оператора витягу даних, вираженого за допомогою мови запитів. Терміни "мова запитів" і "мова керування даними" часто використовуються як синоніми, хоча, з технічної точки зору, це некоректно.

Мови 4GL

Абревіатура "4GL" являє собою скорочений англійський варіант написання терміна мова четвертого покоління (Fourth-Generation Language). He існує чіткого визначення цього поняття, хоча, по суті, мова йде про деякий стенографічний варіант мови програмування. Якщо для організації деякої операції з даними мовою третього покоління (3GL) типу COBOL буде потрібно написати сотні рядків коду, то для реалізації цієї ж операції мовою четвертого покоління буде досить 10-20 рядків.

У той час, як мови третього покоління є процедурними, мови 4GL виступають як не процедурні, оскільки користувач визначає, що повинно бути зроблено, але не говорить, як саме бажаний результат повинний бути досягнутий. Передбачається, що реалізація мов четвертого покоління буде значною мірою заснована на використанні компонентів високого рівня, що часто називають "інструментами четвертого покоління". Користувачу, не буде потрібно визначати всі етапи виконання програми, необхідні для рішення поставленої задачі, а досить буде лише визначити потрібні параметри, на підставі яких згадані вище інструменти автоматично здійснять генерацію прикладного додатка. Очікується, що мови четвертого покоління дозволять підвищити продуктивність роботи на порядок, але за рахунок обмеження типів задач, які можна буде вирішувати з їхньою допомогою. Виділяють наступні типи мов четвертого покоління:

· мови представлення інформації, наприклад мови чи запитів генератори звітів;

· спеціалізовані мови, наприклад мови електронних таблиць і баз даних;

· генератори додатків, що при створенні додатків забезпечують визначення, вставку, чи відновлення витяг зведень з бази даних;

· мови дуже високого рівня, призначені для генерації коду додатків.

Як приклади мов четвертого покоління можна вказати згадувані вище мови SQL і QBE. Розглянемо коротенько деякі інші типи 40G мов.

Генератори форм

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

Генератори звітів

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

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

Генератори програм

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

Об'єктні моделі даних

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

· Модель типу "сутність-зв'язок", чи ER-модель (Entity-Relationship model).

· Семантична модель.

· Функціональна модель.

· Об'єктно-орієнтована модель.

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

Реляційна модель даних

Реляційна модель даних заснована на понятті математичних відносин. У реляційній моделі дані і зв'язки представлені у виді таблиць, кожна з який має кілька стовпців з унікальними іменами. У табл. 2.1 і 2.2 показаний приклад реляційної схеми деякої частини проекту DreamHome, що містить зведення про відділення компанії і персонал організації. Наприклад, з табл. 2.2 видно, що співробітник 'John White' проживає за адресою '19 Taylor St, London' і працює менеджером з річною зарплатою в 30000 фунтів стерлінгів у відділенні компанії з номером 'У5', що, згідно з даними з табл. 2.1, розташований за адресою '22 Deer Rd, Sidcup, London'. Тут важливо відзначити, що між відносинами Staff і Branch існує наступний зв'язок: співробітник працює у відділенні компанії. Однак між цими двома відносинами немає явно заданого зв'язку; її існування можна помітити, тільки знаючи, що атрибут Bno у відношенні Staff еквівалентний атрибуту Bno у відношенні Branch.

Зверніть увагу, що в реляційній моделі даних єдина вимога полягає в тому, щоб база даних з погляду користувача виглядала як набір таблиць. Однак таке сприйняття відноситься тільки до логічної структури бази даних, тобто до зовнішнього і концептуального рівнів архітектури ANSI/SPARC. Воно не відноситься до фізичної структури бази даних, що може бути реалізоване за допомогою різноманітних структур збереження.

Мережна модель даних

У мережній моделі дані представлені у вигляді колекцій записів, а зв'язки - у вигляді наборів. На відміну від реляційної моделі, зв'язку тут явно моделюються наборами, що реалізуються за допомогою покажчиків. Мережну модель можна представити як граф із записами у виді вузлів графа і наборами у виді його ребер. На мал.2.4 показаний приклад мережної схеми для тих же наборів даних, що показані в табл. 2.1 і 2.2. Самою популярною мережною СКБД є система IDMS/R фірми Computer Associates.

 

Рис. 2.4. Приклад фрагмента мережної схеми

Ієрархічна модель даних

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

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

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

Фізичні моделі даних

Фізичні моделі даних описують те, як дані зберігаються в комп'ютері, представляючи інформацію про структуру записів,їх упорядкованості і існуючих шляхах доступу. Фізичних моделей даних не так багато, як логічних, а самими популярними серед них є узагальнююча модель (unifying model) i модель пам'яті кадрів (frame memory).

Концептуальне моделювання

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

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

Функції СКБД

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

Підтримка транзакцій

СКБД повинна матимеханізм, що гарантує виконання або всіх операцій відновлення даної транзакції, або жодної з них.

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

Сервіси відновлення

СКБД повинна надавати кошти відновлення бази даних на випадок якого-небудь її чи ушкодження руйнування.

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

Підтримка обміну даними

СКБД повинна мати здатність до інтеграції з комунікаційним програмним забезпеченням.

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

Допоміжні служби

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

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

· Засобу моніторингу, призначені для відстеження характеристик функціонування і використання бази даних.