(Information Management System компанії IBM) (На даний момент це сама поширена СУБД з усіх даного типу). Застосовуються й інші ієрархічні системи: TDMS (Time-Shared Date Management System) компанії Development Corporation; Mark IV Multi - Access Retrieval System компанії Control Data Corporation; System - 2000 розробки SAS-Institute.
Відносини в ієрархічній моделі даних організовані у вигляді сукупностей дерев, де дерево - Структура даних, в якій тип сегмента нащадка пов'язаний тільки з одним типом сегмента предка. Графічно: Предок - точка на кінці стрілки, а Нащадок - точка на вістря стрілки. У базах даних визначено, що точки - це типи записів, а стрілки представляють відносини один - до - одному або один - до - багатьох.
До обмеження ієрархічної моделі даних можна віднести:
1. Відсутній явне розділення логічних і фізичних характеристик моделі;
2. Для представлення неієрархічних відносин даних потрібні додаткові маніпуляції;
3. Непередбачені запити можуть вимагати реорганізації бази даних.
3. Мережева модель
Мережі - природний спосіб представлення відношень між об'єктами. Вони широко застосовуються в математиці, дослідженнях операцій, хімії, фізики, соціології та інших галузях знань. Мережі зазвичай можуть бути представлені математичною структурою, яка називається спрямованим графом. Спрямований граф має просту структуру. Він складається з точок або вузлів, з'єднаних стрілками або ребрами. У контексті моделей даних вузли можна представляти як типи записів даних, а ребра представляють відносини один-до-одного або один-ко-многим. Структура
графа робить можливими прості уявлення ієрархічних відносин (таких, як генеалогічні дані).
Мережева модель даних - Це подання даних мережевими структурами типів записів і пов'язаних відносинами потужності один-до-одного або один-ко-многим. В кінці 60-х конференція по мовам систем даних (Conference on Data Systems Languages, CODASYL) доручила підгрупі, названої Database Task Group (DTBG), розробити стандарти систем управління базами даних. На DTBG робила сильний вплив архітектура, використана в одній з самих перших СУБД, Iategrated Data Store (IDS), створеної раніше компанією General Electric.Ето призвело до того, що була рекомендована мережева модель.
Документи Database Task Group (DTBG) (група для розробки стандартів систем управління базами даних) від 1971 року залишається основною формулюванням мережевої моделі, на нього посилаються як на модель CODASYL DTBG. Вона послужила основою для розробки мережевих систем управління базами даних декількох виробників. IDS (Honeywell) і IDMS (Computer Associates) - дві найбільш відомих комерційних реалізації. У мережній моделі існує дві основні структури даних: типи записів та набори:
В· Тип записів. Сукупність логічно пов'язаних елементів даних.
В· Набір. У моделі DTBG відношення один-до-багатьох між двома типами записів.
В· Проста мережу. Структура даних, в якій всі бінарні відносини мають потужність один-до-багатьох.
В· Складна мережу. Структура даних, в якій одне або декілька бінарних відносин мають потужність багато-до-багатьох.
В· Тип записи зв'язку. Формальна запис, створена для того, щоб перетворити складну мережу в еквівалентну їй просту мережу.
В моделі DBTG можливі тільки прості мережі, в яких всі відносини мають потужність один-до-одного або один-ко-многим. Складні мережі, що включають одне або кілька відносин багато-до-багатьох, не можуть бути безпосередньо реалізовані в моделі DBTG. Наслідком можливості створення штучних формальних записів є необхідність додаткового об'єму пам'яті і обробки, проте при цьому модель даних має просту мережеву форму і задовольняє вимогам DBTG.
4. Реляційна модель
В 1970-1971 роках Е.Ф. Кодд опублікував дві статті, в яких ввів реляційну модель даних і реляційні мови обробки даних - реляційну алгебру і реляційне числення.
В· Реляційна алгебра - Процедурний мова обробки реляційних таблиць.
В· Реляційне числення - Непроцедурного мова створення запитів.
Всі існуючі до того часу підходи до зв'язування записів з різних файлів використовували фізичні покажчики або адреси на диску. У своїй роботі Кодд продемонстрував, що такі бази даних істотно обмежують число типів маніпуляцій даними. Більш того, вони дуже чутливі до змін в фізичному оточенні. Коли в комп'ютерній системі встановлювався новий накопичувач або змінювалися адреси зберігання даних, вимагалося додаткове перетворення файлів. Якщо до формату запису у файлі додавалися нові поля, то фізичні адреси всіх записів файлу змінювалися. Тобто такі бази даних не дозволяли маніпулювати даними так, як це дозволяла б логічна структура. Всі ці проблеми подолала реляційна модель, заснована на логічних відносинах даних.
Існує два підходи до проектування реляційної бази даних.
В· Перший підхід полягає в тому, що на етапі концептуального проектування створюється не концептуальна модель даних, а безпосередньо реляційна схема бази даних, складається з визначень реляційних таблиць, що піддаються нормалізації.
В· Другий підхід заснований на механічному перетворенні функціональної моделі, створеної раніше, в нормалізовану реляційну модель. Цей підхід найчастіше використовується при проектуванні великих, складних схем баз даних, необхідних для корпоративних інформаційних систем.
Табл.1. Основні визначення реляційних СУБД
Термін
Визначення
Реляційна модель даних
Організовує і представляє дані у вигляді таблиць або реляцій.
Реляційна база даних (РБД, RDBMS).
База даних, побудована на реляційній моделі.
Реляція (Таблиця-елементарна інформаційна одиниця)
Двовимірна таблиця, містить рядки і стовпці даних.
Ступінь реляції.
Кількість атрибутів реляції. При тому необхідно пам'ятати, що ніякі два атрибути реляція не можуть мати однакових імен.
Кортежі
Рядки реляції (Таблиці), відповідають об'єкту, конкретній події або явища.
Атрибути
Стовпці таблиці, характеризують ознаки, параметри об'єкта, події, явища.
Область атрибуту
Набір всіх можливих значень, які можуть приймати атрибути. Якщо в процесі роботи виникає ситуація, що атрибут непридатний або значення одного або кількох атрібутовстрокі поки невідомі, то рядок запишеться в базуданних з порожніми значеніяміетіх атрибутів (NULL рядок).
Пусте значення
Значення, приписуване атрибуту в кортежі, якщо атрибут непридатний або його значення невідомо
Ключ
Будь набір атрибутів, однозначно визначає кожен кортеж реляційної таблиці.
Ключ реляції
Ключ також можна описати як мінімальне безліч атрибутів, що однозначно визначають (або функціонально визначають) кожне значення атрибута в кортежі.
Складовою ключ
Ключ містить два або більше атрибуту.
Потенційний ключ
У будь-якій даній реляційної таблиці може виявитися більше одного набору атрибутів. Зазвичай в якості первинного ключа вибирають потенційний ключ, яким найпростіше користуватися при повсякденній роботі по введенню даних.
Первинний ключ.
...
