Операція вибірки SELECT передбачена для вибірки певних рядків та стовпців

SELECT DEPT#, DNAME, BUDGET

FROM DEPT

WHERE BUDGET>8M

PROJECT DEPT#, BUDGET

FROM DEPT

Join DEPT AND EMP

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

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

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

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

На цьому ми закінчуємо огляд аспекту структури і обробки даних, і переходимо до аспекту цілісності. Ще раз скористаємося нашою базою даних. На практиці для неї потрібно було б визначити декілька обмежень підтримки цілісності бази. Наприклад, зарплата службовця не повинна виходити за рамки 25-95 тисяч за рік, а бюджет відділу повинен, наприклад, лежати в межах 1-15 млн тощо.

Деякі з таких правил цілісності мають таке важливе значення, що навіть одержали спеціальне значення.

1. кожен рядок в таблиці ВІДДІЛИ повинен містити унікальне значення стовпчика ВІДД№; аналогічно кожен рідок в таблиці РОБІТН повинен містити унікальне значення РОБІТН№. Кажуть, що зазначені стовпці є первинними ключами для своїх таблиць

2. кожне значення стовпчика ВІДД№ в таблиці РОБІТНИКИ повинне існувати як значення стовпчика ВІДДІЛ№ таблиці ВІДДІЛИ для відображення того факту, що кожен робітник повинен відноситися до конкретного існуючого ( описаного в таблиці) відділу. Кажуть, що стовпчик ВІДД№ в таблиці РОБІТНИКИ є зовнішнім ключем, який посилається на первинний ключ таблиці ВІДДІЛИ.

Отже, наведемо приблизне визначення реляційної моделі. Вона складається з пяти компонентів:

6. Необмежний набір скалярних типів (включаючи, зокрема, логічний тип);

7. Генератор типів відношень і відповідна інтерпретація для таких генерованих типів.

8. Можливість визначення змінних відношень для таких генерованих типів відношень.

9. Операція реляційного присвоєння для присвоєння реляційних значень таким змінним відношенням;

10. Необмежений набір реляційних операторів для одержання значень відношень з інших значень відношень.

Як бачимо, реляційна модель - це дещо більше ніж просто таблиця плюс вибірка, проекція та зєднання.

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

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

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

§ Принципи реляційної моделі були закладені 1969 та 1970 роках Коддом, який в той час був дослідником, що працював у корпорації ІВМ. Кодд, математик за освітою, вперше дійшов висновку, що математичні дисципліни можна використовувати для впровадження в область управління базами даних строгих принципів та точності.

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

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

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

Delete

From EMP

Where EMP#='E4'; Одержуємо:

Концептуально це можна прокоментувати наступним чином: старе значення відношення РОБІТНИКИ було замінено на зовсім інше, нове значення відношення. Попереднє значення складалося з 4-х рядків, а нове з 3-х. Насправді дана операція видалення рядка - це просто інший, спрощений спосіб запису для певної операції реляційного присвоювання, яка могла б виглядати приблизно так:

EMP:= EMP MINUS (EMP where EMP#='E4');

Як і при будь-якому обчисленні, тут з концептуальної точки зору спочатку обраховується вираз, розташований праворуч від позначки присвоювання, а потім результат присвоюється змінній, яка записана перед знаком присвоювання (за визначенням, перед знаком присвоювання може стояти лише змінна). Змінна-відношення (relval).

Зміст відношень

Відношення повязані з типами даних, а реляційна модель, як зазначалося, містить необмежений набір типів даних. Крім того, користувач може визначати свої власні типи. Наприклад, визначати типи можна наступним чином (на мові Tutorial D):

Type EMP#....; - множина можливих номерів відділів

Type NAME…; - всі можливі імена

Type DEPT#...;

Type Money …;

Кожне відношення, вірніше кожне значення відношення, складається з двох частин: набору пар „імя_стовпчика: імя_типу” (заголовок) і набору рядків, узгоджених з цим заголовком (тіло).

На практиці частина заголовку імя-тип опускаються.

Спосіб представлення змісту відношень:

- по-перше, дане відношення r і заголовок відношення r є певним предикатом або логічною функцію;

- по-друге, кожен рядок у тілі відношення r є істинним висловом, одержаним з предикату шляхом підстановки певних значень аргументів відповідного типу замість місцезнаходжень або параметрів цього предикату

Наприклад, для таблиці РОБІТНИКИ предикат буде наступним:

Робітник з номером ЕМР#, на прізвище ENAME працює у відділі з номером DEPT# і одержує зарплатуSALARY.

Тут параметрами є ЕМР#, ENAME, DEPT# і SALARY, яким відповідають чотири стовпчики змінної-відношення РОБІТНИКИ. Ось приклад відповідного істинного твердження:

Робітник з номерно Е1 на прізвище Лопе працює у відділі з номером Д1 і одержує зарплатню 40 тис на рік.

Інакше кажучи:

Типи - це обєкти (множини обєктів), які можна обговорювати;

Відношення - це факти (множини фактів), відносно обєктів, які можна обговорювати.

Типи повязані з відношеннями так само як іменники повязані з реченнями. Необхідні як типи так і відношення, бо без перших ми не будемо мати що сказати, а без других не будемо знати як.

Базові змінні-відношення і представлення

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

Реляційні системи надають засоби для створення, в першу чергу базових змінних-відношень. На мові SQL, наприклад, ця фнкція забезпечується оператором CREATE TABLE EMP…;

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

CREATE VIEW TOEMP AS

(EMP WHERE SALARY> 33K) {emp, ename, salary};

Коли оператор виконується, вираз, що стоїть за ключовим словом AS і фактично визначає представлення, не обчислюється, а просто запамятовується системою. Проте зовні все виглядає так начеб то у базі даних зявилася реальна змінна-відношення, значення якої розміщені у незатемнених ділянках

Як вже зазначалося, такі змінні-відношення як ЕМР та ДЕР можна вважати реальними, тоді як змінна-відношення ТОЕМР слід розуміти як віртуальну змінну-відношення. Інакше кажучи, вона зовні існує, але насправді її немає (значення цієї змінної-відношення у будь-який момент часу залежить від значень деяких інших змінних-відношень.) вираз, що визначає представлення не обраховується насправді, а представлення - це просто вікно, через яке ми можемо бачити потрібні нам значення базової змінної-відношення ЕМР. Звідси випливає, що будь-які зміні у базовій змінній призводитимуть до змін у незатемненій частині представлення. Аналогічно, зміни у змінну-відношення ТОЕМР будуть автоматично внесені до реальної змінної-відношення ЕМР і, отже, спостерігатимуться через вікно.

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

(TOEMP WHERE SALARY< 42K) {EMP#, SALARY} ==

((EMP WHERE SALARY>33K) {EMP#, ENAME, SALARY}

WHERE SALARY< 42K) {EMP#, SALARY};