Історія реляційної моделі даних

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

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

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

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

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

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

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

Реляційна модель даних — логічна модель даних. Вперше була запропонована британським ученим співробітником компанії IBM Едгаром Франком Коддом (E. F. Codd) в 1970 році в статті «A Relational Model of Data for Large Shared Data Banks» (російський переклад статті, в якій вона вперше описана, опублікований в журналі «СУБД» N 1 за 1995 р.). В даний час ця модель є фактичним стандартом, на який орієнтуються практично всі сучасні комерційні СУБД.

У реляційній моделі досягається набагато більш високий рівень абстракції даних, ніж в ієрархічної або мережевий. У згаданій статті Е. Ф. Кодда стверджується, що «реляційна модель надає засоби опису даних на основі тільки їх природної структури, тобто без потреби введення якої додаткової структури для цілей машинного представлення». Іншими словами, подання даних не залежить від способу їх фізичної організації. Це забезпечується за рахунок використання математичної теорії відносин (сама назва «реляційна» походить від англійського relation— «відношення»).

До складу реляційної моделі даних зазвичай включають теорію нормалізації. Крістофер Дейт визначив три складові частини реляційної моделі даних:

· структурна;

· маніпуляційна;

· цілісна.

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

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

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

Можна провести аналогію між елементами реляційної моделі даних і елементами моделі «сутність-зв'язок». Реляційні відносини відповідають наборам сутностей, а кортежі — сутностям. Тому, також як і в моделі «сутність-зв'язок» стовпці в таблиці, що представляє реляційне відношення, називають атрибутами.

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

Іменоване безліч пар «ім'я атрибута — ім'я домену» називається схемою відношення. Потужність цієї множини — називають ступенем чи «арністю» відносини. Набір іменованих схем відносин представляє із себе схему бази даних.

Атрибут, значення якого однозначно ідентифікує кортежі, називається ключовим (або просто ключем). У нашому випадку ключем є атрибут «Табельний номер», оскільки його значення унікально для кожного працівника підприємства. Якщо кортежі ідентифікуються тільки зчепленням значень декількох атрибутів, то говорять, що відношення має складовий ключ. Ставлення може містити кілька ключів. Завжди один із ключів оголошується первинним, його значення не можуть обновлятися. Всі інші ключі відносини називаються можливими ключами.

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

 

Переваги реляційної моделі:

· простота і доступність для розуміння користувачем. Єдиною використовуваною інформаційною конструкцією є «таблиця»;

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

· повна незалежність даних. Зміни в прикладній програмі при зміні реляційної БД мінімальні;

· для організації запитів і написання прикладного ПЗ немає необхідності знати конкретну організацію БД у зовнішній пам'яті.

 

Недоліки реляційної моделі:

· далеко не завжди предметна область може бути представлена у вигляді «таблиць»;

· в результаті логічного проектування з'являється безліч «таблиць». Це призводить до труднощів розуміння структури даних;

· БД займає відносно багато зовнішньої пам'яті;

· відносно низька швидкість доступу до даних.