3.2. Системи управління базами даних
Обробка даних засобами СУБД. Додавання, вилучення, зміна та відбір даних здійснюється за допомогою мови запитів, вбудованої алгоритмічної мови та інших засобів СУБД. Реалізація запитів забезпечується діалоговою системою команд меню чи запитами за зразком QBE (Query by Example) [88]. В першому випадку окремий запит виконується однією чи декількома командами мови СУБД. Послідовність команд мови СУБД утворює програму (наприклад, за цим принципом працювала СУБД Dbase, такі принципи використовуються в СУБД Oracle). В другому випадку користувач для виконання запиту вибирає потрібну команду з меню чи за допомогою кнопок на формі, або вказує в запиті зразок, за яким створюється запит, а також, за необхідності, умови відбору та операції, які потрібно виконувати над даними (наприклад, Paradox, Access).
Мови СУБД. Для роботи з базами даних використовують спеціальні мови, які в цілому називають мовами баз даних. В ранніх СУБД підтримувалося кілька спеціалізованих за своїми функціями мов. Частіше всього виділялися дві мови [Error: Reference source not found] – мова визначення схеми бази даних (SDL – Schema Definition Language) та мова маніпулювання даними (DML – Data Manipulation Language). Мова SDL використовувалася переважно для опису логічної структури бази даних – тієї структури бази даних, яка представляється користувачам. Мова DML містила набір операторів маніпулювання даними – операторів, які дозволяють додавати дані до БД, знищувати, модифікувати чи вибирати існуючі дані.
В сучасних СУБД зазвичай підтримується єдина інтегрована мова, що містить усі необхідні засоби для роботи з базами даних, починаючи від її створення, і забезпечує базовий інтерфейс користувача з базами даних. Стандартною мовою найрозповсюдженіших в даний час СУБД є мова SQL (Structured чи Standard Query Language) [Error: Reference source not found]. Мова SQL поєднує засоби SDL та DML – дозволяє описувати (визначати) схему реляційної бази даних та маніпулювати даними. При цьому назви об’єктів бази даних підтримуються на мовному рівні в тому сенсі, що компілятор мови SQL здійснює перетворення імен об’єктів в їх внутрішні ідентифікатори на основі спеціальних службових таблиць-каталогів (внутрішня частина СУБД (ядро) взагалі не працює з іменами таблиць, полів тощо).
Мова SQL містить спеціальні засоби визначення обмежень цілісності БД (які також зберігаються в спеціальних таблицях-каталогах) і забезпечення контролю цілісності здійснюється на мовному рівні – при компіляції операторів модифікації БД компілятор SQL, на основі наявних в базі даних обмежень, цілісності генерує відповідний програмний код.
Спеціальні оператори мови SQL дозволяють визначати так звані представлення БД, які фактично є запитами, що зберігаються в базі даних і результатом виконання яких є повернення таблиці з іменованими полями [Error: Reference source not found]. Для користувача представлення є такою ж таблицею, як і будь-яка базова таблиця, що зберігається в базі даних, але за допомогою представлень можна обмежити, чи, навпаки, розширити доступ конкретного користувача до інформації в БД. Підтримка представлень також забезпечується на мовному рівні.
Авторизація доступу до об’єктів БД також здійснюється на основі спеціального набору операторів SQL. Ідея полягає в тому, що для виконання операторів SQL користувач повинен бути наділений певними повноваженнями. Користувач, який створив таблицю БД, має повний набір повноважень для роботи з цією таблицею. Такого користувача часто називають власником об’єкта БД (Database Object Owner – DBO). До повноважень власника об’єкта бази даних також належать повноваження на передачу усіх (чи частини) цих повноважень іншому користувачу. Повноваження користувачів також описуються в спеціальних таблицях-каталогах і контроль цих повноважень здійснюється на рівні мови.
Коротка історія мови SQL. Стандарти SQL. Мова SQL, призначена для взаємодії з базами даних, з’явилася в середині 70-х років (перші публікації датуються 1974 роком) і була розроблена в компанії IBM в рамках проекту експериментальної реляційної СУБД System R [Error: Reference source not found]. Початкова назва мови SEQUEL (Structured English Query Language) тільки частково відображала суть цієї мови – хоча мова орієнтувалася перш за все на простий і зрозумілий користувачам спосіб формування запитів до реляційних баз даних, але в дійсності з самого початку це була повноцінна мова БД, яка крім DML підтримувала також SDL.
На даний час мова SQL реалізована практично в усіх комерційних СУБД і майже в усіх СУБД, які спочатку базувалися на не реляційному підході. Усі компанії декларують відповідність своєї реалізації стандарту SQL, хоча цього вдалося досягти не одразу.
Найближчими до System R були дві системи компанії IBM – SQL/DS та DB2. Розробники цих систем використовували досвід проекту System R, а СУБД SQL/DS напряму базувалася на програмному коді System R. Звідси й подібність діалектів SQL в цих системах – з SQL System R було вилучено тільки ті частини, які були недостатньо пророблені, чи реалізація яких викликала занадто великі технічні складності. Такий шлях до комерційної реалізації SQL часто називають рухом „зверху вниз“.
Інший підхід використовувався в таких системах, як Oracle, Informix та Sybase – реалізація SQL здійснювалася „знизу вверх“. В перших випущених на ринок версіях цих систем використовувалася обмежена підмножина SQL System R. Зокрема, в першій відомій реалізації SQL в СУБД Oracle в операторах вибірки не допускалося використання вкладених підзапитів, а також була відсутня можливість формулювання запитів зі з’єднанням кількох відношень (таблиць). Незважаючи на такі обмеження, а також на досить слабку, на перших порах, ефективність СУБД, орієнтація компаній на підтримку різних апаратних платформ та зацікавленість користувачів в переході до реляційних систем дозволило компаніям досягти комерційних успіхів та приступити до удосконалення своїх реалізацій.
Особливістю більшості сучасних комерційних СУБД, яка ускладнює порівняння існуючих діалектів SQL, є відсутність однотипного описання мови. Зазвичай описання розкидано по документації і перемішано з описанням специфічних для даної системи мовних засобів, які не мають прямого відношення до SQL. Незважаючи на це можна стверджувати, що базовий набір операторів SQL – оператори описання схеми БД, вибірки та маніпулювання даними, авторизації доступу до даних та ін. більш менш устоявся і відповідає стандарту.
Діяльність зі стандартизації мови SQL почалася практично одночасно з появою перших її комерційних реалізації. В 1982 році комітету з баз даних Американського національного інституту стандартів (ANSI) було доручено розробити специфікацію стандартної мови реляційних баз даних. Стандарт було прийнято ANSI в 1986 році, а в 1987 році він був схвалений Міжнародною організацією зі стандартизації (ISO). Цей стандарт прийнято називати SQL/86 [89].
Зрозуміло, що за основу стандарту не можна було брати SQL System R. По-перше, цей стандарт мови не було достатньо технічно пророблено. По-друге, його занадто складно було реалізовувати. Тому за основу стандарту було взято діалект SQL, який склався в IBM до початку 1980-х років. По суті цей стандарт представляв собою технічно пророблену підмножину SQL System R.
До 1989 року стандарт SQL/86 було дещо розширено, в результаті чого було підготовлено та прийнято наступний стандарт, який отримав назву ANSI/ISO SQL/89. На цьому етапі процес стандартизації SQL проходив досить складно і з використанням не тільки наукових аргументів [90]. В результаті цього SQL/89 в багатьох частинах має досить загальний характер і допускає досить широке трактування. В цьому стандарті повністю відсутні такі важливі розділи, як маніпулювання схемою бази даних та динамічний SQL. Тому багато з важливих аспектів мови відповідно до стандарту визначаються в реалізації [Error: Reference source not found].
Можливо, найважливішими досягненнями стандарту SQL/89 є чітка стандартизація синтаксису та семантики операторів вибірки даних і маніпулювання даними а також фіксація засобів обмеження цілісності бази даних. Були специфіковані засоби визначення первинного та зовнішнього ключів відношень і, так званих, перевірочних обмежень цілісності, які представляють собою підмножину обмежень цілісності SQL System R. Засоби визначення зовнішніх ключів дозволяють легко формулювати вимоги так званої цілісності посилань бази даних. Цю розповсюджену в реляційних БД вимогу можна було сформулювати і на основі загального механізму обмежень цілісності SQL System R, однак формулювання на основі поняття зовнішнього ключа простіше і зрозуміліше.
Усвідомлюючи неповноту стандарту SQL на фоні завершення розробки цього стандарту спеціалісти різних компаній почали роботу над новим стандартом SQL2. Ця робота також тривала кілька років, було випущено велику кількість проектів стандарту, поки нарешті в березні 1992 року не було прийнято остаточний проект стандарту SQL/92. Цей проект є набагато повніший стандарту SQL/89 і охоплює практично усі аспекти, необхідні для реалізації програм: маніпулювання схемою БД, управління трансакціями (з’явилися точки збереження) та сесіями (сесія – це послідовність трансакцій, в межах якої зберігаються тимчасові відношення), підключення до БД, динамічний SQL. Крім того були стандартизовані відношення-каталоги БД, що, взагалі кажучи, не зв’язано безпосередньо з мовою, але дуже сильно впливає на реалізацію.
В 1995 році стандарт було доповнено специфікацією інтерфейсу рівня виклику (Call-Level Interface – SQL/CLI). SQL/CLI представляє собою набір специфікацій процедур, виклики яких дозволяють виконувати оператори SQL, що задаються динамічно. По суті SQL/CLI представляє собою альтернативу динамічному SQL. Інтерфейси процедур визначені для усіх основних мов програмування: С, Ada, Pascal, PL/1 тощо. Слід зазначити, що стандарт SQL/CLI ліг в основу для створення інтерфейсів ODBC (Open Database Connectivity) та JDBC (Java Database Connectivity) [Error: Reference source not found].
В 1996 році до стандарту SQL/92 було додано іще один компонент – SQL/PSM (Persistent Stored Modules). Основна мета цієї специфікації полягає в тому, щоб стандартизувати способи визначення та використання збережених процедур – спеціальним чином оформлених програм, що включають оператори SQL, які зберігаються в базі даних, можуть викликатися програмами та виконуються всередині СУБД.
Незадовго до завершення робіт по визначенню стандарту SQL2 була розпочата робота над стандартом SQL3. Спочатку планувалося завершити проект в 1995 році і включити до мови деякі об’єктні можливості – користувацькі типи даних, підтримку тригерів тощо. Реально роботу над новим стандартом вдалося частково завершити тільки в 1999 році, і з цієї причини (а також у зв’язку з проблемою 2000 року) стандарт отримав назву SQL:1999.
Наведемо коротку характеристику поточного стану стандарту SQL:1999 та перспектив його розвитку. Перш за все зазначимо, що кожний новий варіант стандарту SQL був значно об’ємніше попереднього. Так, наприклад, якщо стандарт SQL/89 займав біля 600 сторінок, то об’єм SQL/92 має на 300 сторінок більше, а перші проекти SQL3 займали біля 1500 сторінок [91]. Тому розробники SQL3 прийшли до висновку, що при таких об’ємах стандарту ймовірність його прийняття та наступної успішної підтримки значно зменшується. Тому було прийнято рішення розбити стандарт на відносно незалежні частини, які можна було б розробляти і підтримувати окремо.
В 1999 році були прийняті п’ять перших частин стандарту SQL:1999 [Error: Reference source not found]. Перша частина (SQL/Framework) присвячена опису концептуальної структури стандарту. В цій частині приводиться розгорнута анотація наступних чотирьох частин та формулюються вимоги до реалізацій, які претендують на відповідність стандарту.
Друга частина SQL:1999 (SQL/Foundation) утворює базис стандарту. Вводиться система типів мови, формулюються правила визначення функціональних залежностей та можливих ключів, визначаються синтаксис та семантика основних операторів SQL:
операторів визначення та маніпулювання схемою даних;
операторів маніпулювання даними;
операторів управління трансакціями;
операторів підключення до бази даних тощо.
Третю частину займає уточнена по відношенню до SQL/92 специфікація SQL/CLI. В четвертій частині специфікується SQL/PSM – синтаксис та семантика мови визначення збережених процедур. І в п’ятій частині – SQL/Bindings – визначаються правила зв’язування SQL для стандартних мов програмування FORTRAN, COBOL, PL/1, Pascal, Ada, C та MUMPS.
В кінці 2003 року було прийнято та опубліковано новий варіант міжнародного стандарту SQL:2003. Багато фахівців вважало, що у варіанті стандарту, розробленого після SQL:1999, будуть тільки виправлені неточності SQL:1999. В дійсності ж в SQL:2003 специфіковано ряд нових і важливих засобів. Також було змінено загальну організацію стандарту. Стандарт SQL:2003 складається з таких частин:
9075-1, SQL/Framework;
9075-2, SQL/Foundation;
9075-3, SQL/CLI;
9075-4, SQL/PSM;
9075-9, SQL/MED;
9075-10, SQL/OLB;
9075-11, SQL/Schemata;
9075-13, SQL/JRT;
9075-14, SQL/XML.
Частини 1-4 та 9-10 з необхідними змінами залишилися такими ж, як і в SQL:1999. Частина 5 (SQL/Bindings) перестала існувати, а відповідні специфікації включено в частину 2. Розділ частини 2 SQL:1999, присвячений інформаційній схемі, виділено в окрему частину 11. З’явилося дві нові частини – 13 та 14. Частина 13 (SQL/JRT) повністю називається “SQL Routines and Types Using the Java Programming Language” („використання підпрограм та типів SQL в мові програмування Java“). Поява такої частини стандарту виправдана підвищеною увагою до мови Java з боку провідних розробників SQL-орієнтованих СУБД. Остання частина SQL:2003 присвячена специфікації мовних засобів, які дозволяють працювати з XML-документами в середовищі SQL.
Поточний стан процесу стандартизації мови SQL відображає поточний стан технології SQL-орієнтованих баз даних. Провідні постачальники відповідних СУБД стараються максимально швидко реагувати на потреби та кон’юнктуру ринку і додають до своїх продуктів все нові й нові можливості. Очевидною є потреба в стандартизації відповідних мовних засобів, але процес стандартизації явно не встигає за цими змінами.
Структура мови SQL. Мова SQL, яка відповідає останнім стандартам SQL:2003, SQL:1999 (і навіть SQL/92), є досить складною мовою, усі можливості якої одразу не просто усвідомити і, тим більше, зрозуміти. Тому виникає необхідність в розбитті мови на рівні, такі, що кожен рівень мови включає усі конструкції, які входять до нижчих рівнів. В стандарті визначається кілька способів розбиття мови на рівні. В одній із класифікацій мова розбивається на базовий (entry), проміжний (intermediate) та повний (full) рівні [Error: Reference source not found]. Ця класифікація орієнтована, перш за все, на виробників СУБД, в яких підтримується SQL. Реалізація базового рівня мови є обов’язковою умовою хоча б якоїсь відповідності стандарту. Реалізація проміжного рівня є бажаною, і зазвичай саме такий рівень мови підтримується провідними компаніями-виробниками SQL-орієнтованих СУБД. Нарешті, повний рівень мови є метою, до досягнення якої слід прагнути. В даній класифікації критерієм віднесення тієї чи іншої можливості мови є оцінювана розробниками стандарту SQL технічна складність реалізації цієї можливості. Зрозуміло, така класифікація є важливою і для програмістів програм баз даних, але тільки для того, щоб оцінити реальні можливості конкретної СУБД. Для розуміння мови SQL таке розбиття на рівні є несуттєвим.
Інший метод класифікації в графічному вигляді представлено на рис. 3.1.
Рис. 3.1. Класифікація рівнів SQL
Серед усіх конструкцій мови SQL можна виділити такі конструкції, які можна було б використовувати при прямій (direct) взаємодії кінцевого користувача з СУБД (наприклад, в інтерактивному режимі). До деякої міри цей рівень мови також є базовим, оскільки відповідні засоби мови в найбільшій мірі відображають її орієнтованість на роботу з множинами. На наступному рівні, рівні вбудованого (embedded) SQL, мова доповнюється конструкціями, які дозволяють використовувати можливості прямого SQL в програмах, написаних на традиційних мовах програмування. На рівні динамічного (dynamic) SQL до вбудованого SQL додаються конструкції, що дозволяють програмам звертатися до СУБД з конструкціями прямого SQL, які динамічно утворюються під час виконання програми.