Моделі даних

Дані, що зберігаються в БД, повинні бути організовані за певними правилами.

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

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

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

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

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

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

Сукупність конкретних значень полів сегмента називається екземпляром сегмента або записом: м. Амурська - вул. Перемоги, 3 - 18-67-53. Отже, один блок на схемі відображає безліч фактичних записів (примірників сегмента).

Рис. 2.  Ієрархічна база даних

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

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

Основні властивості ієрархічної моделі даних. 1. Кожен з підлеглих сегментів пов'язаний тільки з одним сегментом вищого рівня ієрархії. Зв'язки між сегментами одного рівня не допускаються. 2. Між сегментами двох рівнів можуть підтримуватися тільки зв'язки «один до багатьох» (одна філія - ​​багато магазинів, один склад - багато товарів) або «один до одного» (одна філія - ​​один директор).

Недоліки ієрархічної моделі даних:

1. Асиметричність запитів. У цьому можна переконатися, порівнюючи два запити. За допомогою першого з них вибирається запис з інформацією про партії товарів, для якої відомі назви філії, магазину та складу. У рамках другого запиту за відомостями про партії товарів потрібно визначити назву філії, в якому вона знаходиться. 2. Складність змін. Наприклад, при закритті деякого складу товари перерозподіляються між іншими складами. Ця операція зажадає кардинальної зміни структури бази даних. 3. Жорсткість структури, що не дозволяє врахувати в базі даних окремі реальні ситуації. Наприклад, товари, що зберігаються на одному складі, призначені декільком магазинам. 4. Складність експлуатації. Робота з ієрархічними базами даних потребує значної кваліфікації користувачів в області програмування. Зокрема, в СУБД IMS фірми IBM для опису загальної схеми бази даних і блоку зв'язку кожного користувача з базою даних використовувалася мова програмування Assembler. Для вибірки даних з БД - спеціалізована мову DL / 1, для обробки отриманої інформації - мови PL / 1 або Кобол. Перелічені причини призвели до того, що ієрархічна модель даних в даний час практично не використовується.

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

Стандарт мережевої моделі даних вперше був визначений у 1975 р. організацією CODASYL (Conference of Data System Languages).

У мережній моделі даних не накладається ніяких обмежень на кількість зв'язків, що входять в одну вершину. Отже, зв'язки можна встановлювати не тільки між вузлами сусідніх по підпорядкованості рівнів, але і різних рівнів (рис. 3):

 

Рис. 3  Мережева база даних

Зв'язки, зображені на рис. 3 і відсутні на рис. 2, можуть характеризувати цілком реальні взаємини в роботі торгового підприємства: представники дирекції можуть курирувати роботу конкретних підрозділів, підрозділу підприємства (автогосподарство, ремонтна служба) забезпечують роботу складів, співробітники підрозділів (бухгалтери, торгові агенти) взаємодіють з магазинами. Таких зв'язків можна визначити дуже багато.

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

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

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

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

З наведених причин СУБД, побудовані на основі мережної моделі (IDMS, db_VistaIII та ін), не набули широкого поширення.

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

Реляційна модель даних (РМД) покладена в основу більшості сучасних СУБД. Достоїнствами моделі є простота розміщення даних та зручність їх інтерпретації.

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

Кожна таблиця реляційної бази даних має ім'я і рядок заголовків. Розглянемо таблицю бази даних торговельного підприємства, в якій зберігаються відомості про постачальників товарів (табл. 1.1):

Таблица 1.1 Поставщики

Код	Название	Город
345	Волна	Хабаровск
412	Парус	Владивосток
123	Звезда	Хабаровск
215	Парус	Иркутск

Таблиця має ім'я Постачальники, назви стовпців таблиці Код, Назва, Місто являють собою рядок заголовків.

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

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

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

До таблиць РМД висуваються такі вимоги: 1. Значення даних, розташовані на перетині будь-яких рядка і стовпця, повинні бути неподільними (атомарними, елементарними). Ця вимога означає, що в кожній клітинці таблиці може знаходитися тільки одне значення. 2. У таблиці не повинно бути полів з однаковими назвами, порядок розташування полів є довільним. Наявність цієї вимоги визначається тим, що пошук інформації в таблиці реалізується в полях, імена яких зазначені в запиті. 3. Порядок проходження записів може бути довільним. 4. У таблиці не повинно бути однакових записів.

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

Первинним ключем таблиці Постачальники є поле Код. Поля Назва і Місто не можуть бути первинними ключами, так як в них є повторювані значення (див. табл. 1.1). Первинний ключ, визначений по одному полю таблиці, називається простим.

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

Таблица 1.2 Поставки товаров

Название товара	Артикул	Количество	Дата поставки	Шифр поставщика
Костюм	500	100	10.12.05	345
Сапоги	200	75	10.12.05	123
Туфли	100	120	11.12.05	123
Костюм	500	100	11.12.05	345
Костюм	300	50	12.12.05	345
Костюм	400	50	12.12.05	215
Туфли	100	100	12.12.05	215

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

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

Припустимо, у таблиці Додаткові відомості зберігається докладна інформація про організації, що постачають товари (табл. 1.3):

Таблица 1.3 Дополнительные сведения

Поставщик	Директор	Телефон	Адрес	№ договора
345	Иванов П. Л.	64-12-83	Мира, 4	75
412	Сеидов О. А.	22-17-12	Победы, 18	19
123	Цой О. М.	39-18-34	Блюхера, 1	79
215	Лодис С. С.	46-19-23	Пушкина, 1	35

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

Зв'яжемо таблиці Постачальники і Додаткові відомості за допомогою полів Код та Постачальник. Порівнюючи значення даних у цих полях і вибираючи поєднання записів, для яких вони збігаються, можна отримати відповіді, наприклад, на такі запити: «Хто є директором організації« Парус »з Владивостока?» (Сеїд О.А.); «Яка адреса у організації «Хвиля»? »(Миру, 4).

Наведений приклад демонструє зв'язок між таблицями «один до одного» - одного запису в таблиці Постачальники відповідає один запис у таблиці Додаткові відомості.

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

Насправді ніякої суперечності не існує - поле Шифр ​​постачальника є зовнішнім ключем таблиці Поставки товарів. Зовнішній ключ - це поле або група полів таблиці, які не є первинним ключем в даній таблиці, але є первинним ключем в іншій таблиці.

За допомогою зв'язування таблиць Постачальники і Поставки товарів по ключових полях, можна отримати відповіді на запити: «Яка організація поставила костюми 10 грудня 2005?» (Хвиля); «З яких міст були привезені туфлі?» (Хабаровськ, Іркутськ).

Пов'язуючи таблиці Поставки товарів та Додаткові відомості, можна отримати відповіді на запити: «Який номер телефону у організації, яка поставила костюми з артикулом 500?» (64-12-83); «Відповідно до якого договором поставлялися костюми з артикулом 400?» ( № 35).

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

Для зв'язування таблиць, дані в зв'язуючих полях обов'язково повинні бути отримані з одного домену. Імена зв'язуючих полів можуть відрізнятися один від одного (Код, Шифр ​​постачальника, Постачальник), розташування сполучних полів в таблицях може бути довільним (див. табл. 1.1 - 1.3).

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

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

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

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

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

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

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

Для практичної реалізації об'єктно-орієнтованих баз даних застосовуються два підходи [12]: 1. Використовується мова об'єктно-орієнтованого програмування (наприклад, С + +), доповнена засобами, що дозволяють при необхідності зберігати об'єкти після завершення програми, за допомогою якої вони були створені. 2. Основою є реляційна система, до якої додаються об'єктно-орієнтовані компоненти.

Недоліки об'єктно-орієнтованих баз даних: 1) відсутнє необхідне уніфіковане теоретичне обгрунтування й стандартизована термінологія; 2) не існує формально сформульованої методології проектування баз даних; 3) відсутні засоби створення нерегламентованих запитів; 4) немає загальних правил підтримки узгодженості даних.

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