НОУ ІНТУІТ, Лекція, Діалект SQL фірми ORACLE

Походження та обсяг діалекту SQL фірми Oracle

Для успішного програмування Oracle на SQL недостатньо знати суто формальний опис мови. Необхідно володіти ширшим набором знань, що мають відношення до справи. З цією метою нижче розглядається ланцюжок понять, що підводить до "діалекту SQL, запропонованому фірмою Oracle". Вона влаштована в такий спосіб: база даних → модель даних, СУБД; реляційна модель; мову запитів до даних та зміни даних → SQL → діалект SQL у Oracle.

База даних та модель даних

База даних

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

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

"Зазвичай великі збори даних, організованих для особливо швидкого та зручного способу пошуку та вилучення (наприклад, з ЕОМ)" (Merriam-Webster's Collegiate Dictionary, www.merriam-webster.com/dictionary/database, датовано 1962).
"Збори структуризованих даних в ЕОМ, що підтримується СУБД, яка забезпечує різним додаткам різний вид даних" (F. Pascal, Understanding Relational Databases with examples in SQL-92, New York, NY: John Whiley & Sons, 1993).
"База даних - набір аксіом. Результат на запит до бази є теорема. Процес виведення теореми з аксіом є доказ. Доказ здійснюється маніпулюванням символів за умовленими математичними правилами. Доказ [тобто результат запиту до бази] настільки ж здоровийі логічно (consistent), наскільки здорові та логічні правила" (H. Darwen. The Duplicity of Duplicate Rows. Relational Database Writings 1989-1991, Reading, MA: Addison-Wesley, 1992).

Можливе узагальнення цих та інших визначень:

"Сукупність всіх даних деякої прикладної області" [для використання в програмних системах] (Філіппов В. І. Загальний опис системи КОМПАС. // Автоматизація програмування. Москва: ВЦ АН СРСР, 1989).

Істотні елементи у визначеннях БД:

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

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

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

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

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

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

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

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

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

До функцій, які забезпечують сучасні СУБД, входять такі:

Підтримка логічної моделі даних (визначення даних, оперування даними).
Відновлення даних (транзакції, журналізація, контрольні точки).
Управління одночасним доступом до даних у БД.
Безпека даних (права доступу та інше).
Самостійна оптимізація виконання операцій.
Інші, у тому числі з перерахованих (адміністрування,статистика, розподіл даних тощо).

Реляційний підхід до моделювання даних

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

Все, що я з'їв, і все, що я випив, лишилося зі мною;

Все інше, що є, право, не варте клацання.

Вираз "модель даних" часто розуміється у двох різних сенсах: як формальний опис деякої конкретної предметної області та як інструмент для складання подібних описів. Потрібний зміст зазвичай доводиться визначати за контекстом. Тут вираз "реляційна модель даних" сприймається як інструмент складання в БД конкретних описів конкретних предметних областей.

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

"Тип даних" (type) - безліч допустимих величин ("область визначення") та операцій. Для всіх типів існують операції порівняння та присвоєння. Величин не заборонено мати структуру, наприклад, об'єкта.
"Ставлення" (relation) - безліч атрибутів: унікальних імен з уточненням типу даних; плюс безліч " наборів величин " ( " рядів " ), відповідних атрибутам. Величини в наборах можуть бути представлені лише одиничними значеннями відповідних атрибутів типів, тобто бути скалярами ("1 нормальна форма").
"Змінна відносини" (relation variable) - змінна типу відносини конкретного виду, необхідне поняття для визначення в базі даних дій щодо "оновлення відносин", "внесення змін до даних". Порушуючи точність і в силу поверхнево-ознайомчого характеру цього матеріалу далі замість назви "змінна стосунки" вживатиметься просто "відношення" (подібновільному вживанню слова "ціле" замість "змінна цілого типу").
"Ключ" (key) - група атрибутів, значення яких у всіх наборах відносно різні, але жодна підгрупа цих атрибутів такою властивістю вже не має (властивість "мінімальності" ключа). Зокрема група може складатися з єдиного атрибуту. Ключ щодо повинен бути завжди, і якщо їх кілька, одне їх має бути призначений " первинним " (primary).
" Зовнішній ключ " (foreign key) — група атрибутів, значення яких у кожному наборі величин відносини мають збігатися зі значеннями ключа можливо іншого відношення. Зовнішні ключі не обов'язкові і проголошуються за потребами моделювання.
"Операції" (operation) - безліч спільних дій над відносинами, що дають в результаті знову-таки відносини ("замкненість операцій"). Використовуються для отримання нових відносин у потребах подальшого моделювання або під час вилучення з бази необхідних даних. Перелік операцій можна визначати по-різному; у перших пропозиціях моделі наводилося вісім операцій (проекції, з'єднання, відбору та ін.), вже не мінімальний набір, як компроміс між відсутністю надмірності та зручністю вживання.
"Реляційна база даних" (relational database) - набір відносин.

" Тип даних " іноді називають " доменом " (domain), але іноді під " доменом " розуміють лише " область визначення " величин. "Набір величин" (tuple) українською інакше називають "кортежем" або "n-кою".

Для зручності відносини часто зображують як таблиць, хоча таке уявлення неправомірно (відносно не визначено ні порядок атрибутів, ні порядок наборів величин, на відміну таблиці). У SQL, з урахуванням якого побудована зокрема СУБД Oracle, поняття "відносини" (аточніше, поняття "змінної відносини") як інструменту моделювання замінено саме на "таблицю". Іншим уявленням даних відношення може бути гіперкуб, і до нього теж іноді зручно вдаватися до міркувань про наявну БД.

Якщо відмовитися від визначального слова-кальки "реляційний", то термін "реляційна БД" можна перекласти як "БД відносин" (точніше, "БД побудованаза допомогоювідносин"; відносин як інструменту, а не об'єкта моделювання: інакше вихідний термін був би relation database). Так само термін "реляційна модель" можна перекласти як "модель відносин", тобто "система понять для побудови моделі предметної області у вигляді набору відносин". З ряду причин, у тому числі історичного та мовного характерів, цього не було свого часу зроблено.

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

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