2. Приклад використання інтерактивного sql в субд mysql

СУБД MySQL користується широкою популярністю в програмістсь- кому середовищі, хоча не набула статусу гранду серед СУБД, проте широ­ко розповсюджена й працює під різними платформами. Зокрема, даний приклад ілюструє роботу інтерактивного SQL під операційною системою Linux Debian.

Для початку роботи в командному рядку введемо:

...$ mysql

Командна оболонка шелла видасть запрошення на зразок: welcome to the mysql monitor, commands end with ; or g. your mysql connection id is 46 to server version: 3.22.32-log type 'help' for help. mysql>

то у відповідь на нього наберіть q, залишимо на якийсь час інтерпре­татор sql запитів, і займемося адмініструванням сервера mysql. Перш за все необхідно встановити пароль адміністратора сервера БД. Тепер потрібно завести користувачів і дати їм деякі права. Все адміністрування прово­диться через звичайні таблиці mysql, а їхня правка також здійснюється ста­ндартними sql командами. Найперша таблиця, яка визначає допуск корис­тувача до сервера, так і називається - user. Щоб з’ясувати хто у нас там є, й що він може робити, наберемо:

mysqldump -и root -р -opt mysql user>mysql-users.sql

стосуються сервера В цілому. І Іривілеї grunt, references, index і utter №ЮЇЬ можливість передавати права, а також змінювати, зв’язувати й індексувати таблиці,

Два важливі зауваження.

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

По-друге, привілеї, які стосуються сервера в цілому, налаштовують­ся тільки в цій таблиці, і хоча б один користувач, у даному випадку root, повинен мати ці привілеї, інакше сервер стане некерованим.

Якщо у ваші плани входить дати доступ до сервера всім користува-

• • г* • і • • • і If •• ечгч*

чам і під будь-яким їм ям, заведіть користувача з порожнім їм ям . Ті ж правила застосовуються до імен і адрес комп'ютерів-хостів. Тепер, попра­вивши записи в таблиці, але в жодному випадку не її структуру, відправи­мо команди назад в mysql.

...$ mysql -и root -p < mysql-users.sql і попросимо сервер перечитати змінені права ...$ mysqladmin -и root -р reload

Ще одне зауваження щодо паролів. У розглянутому нами файлі поля паролів порожні, і це треба негайно виправити. Правити їх у текстовому файлі незручно, тому що mysql використовуваний для шифрування пароля окрему програму, і зберігає пароль у зашифрованому вигляді. Щоб устано­вити пароль, наприклад, користувачеві «user2», треба виконати таку ко­манду:

...$ mysql mysql -і 'update user setpassword=password(«0») where user=«user2»;'

Відмінність від звичайної системи паролів у тому, що імена користу­вачів БД можуть бути не пов'язані з їхніми реєстраційними іменами в сис­темі, користувачі не можуть міняти свої паролі, і цей пароль відомий адмі­ністраторові БД.

Розібравшись із найпершою адміністративною таблицею user, решта таб­лиць: db, host, tables_priv, columns_priv, func - змінюємо аналогічно.

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

Далі вже можна робити залипмкщо, звичайно, початкова база гото­ва. Нехай у нас є телефонна база даних. Тоді до неї можна робити інтерак­тивні залити, наприклад:

select p.phonum, р. па im, s. nie к, b.bldng

from phone p, street s, building b # короткі синоніми таблиць where

p.bd_id=b.bd_id # таким чином and b.st_id=s.st_id # зв'язують таблиці and p.phonum like «%1234%» # власне запит order by p.naim;

Зауважимо, що в секторі клієнт-серверних застосувань Mysql цілком здатний конкурувати з визнаними комерційними СУБД, навіть із такими як Sybase. Але вся потужність MySql розкривається в поєднанні з технологія­ми Internet.

3. Програмно-вбудований(embeded) SQL

Інтерактивна форма роботи з SQL адекватна для адміністратора баз даних, можлива для певних категорій користувачів, проте зовсім неприй­нятна для всіх програмістів і переважної більшості користувачів БД. Про­грам но-вбудований SQL (Embedded SQL) призначений для того, щоб вбу­довувати SQL запити в прикладну програму. Але як це зробити?

Як «пояснити» компілятору C++, COBOL чи PL/1, що частина про­грами це не оператори мови, а оператори якогось іншого коду? Ця пробле­ма дещо нагадує задачу реалізації мережевої моделі по стандарту CODASYL. Там теж застосовується мови високого рівня. Принципова різ­ниця полягає в тому, що на відміну від схем та підехем стандарту CODASYL, які по-суті є підмножинами процедурних мов, SQL є деклара­тивною. Як з'єднати можливості мови програмування структурного рівня (змінні, розгалуження, цикли) і використати можливості SQL (запити декларативного типу, де вже не на програміста, а на СУБД лягає обов’язок по їхній оптимізаиії й вибору плану виконання )?

Ці й деякі інші проблеми вирішуються декількома способами. Ці способи частково описані й у стандарті SQL-92. На даний момент використовують­ся два варіанти програмного SQL: статичний та динамічний. Розглянемо, що являє собою кожний варіант.

Статичний SQL є різновид програмного SQL, призначеного для вбу­довування SQL-операторів у текст програми мовою програмування висо­кого рівня. Розглянемо ще раз алгоритм виконання SQL-запитів в інтера­ктивному режимі роботи. Легко бачити, що користувач змушений очікувати результатів виконання запиту протягом усього часу роботи алго­ритму. Якщо через якийсь час користувачеві знову потрібно буде виконати той же самий запит, СУБД знову проробить ті ж самі дії, що й при попере-

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

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

для повернення в програму результатів запиту використати спеціальні конструкції, відсутні в інтерактивному SQL;

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

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

Розглянемо два основних етапи, пов'язаних із роботою статичного SQL - компіляцію та виконання програми. Схема компіляції й збирання програми виглядає в такий спосіб: програма, що включає оператори мови програмування високого рівня разом з операторами SQL, подається на вхід спеціального препроцесора, що виділяє з її частини, пов’язані з SQL. Замість інструкцій вбудованого SQL препроцесор підставляє виклики спеціальних функцій СУБД. Бібліотеки таких функцій для зв'язку з мовами програмування існують для всіх розповсюджених серверних СУБД. Варто особливо відзначити, що ці бібліотеки мають «закритий» інтерфейс, тобто розробники можуть міняти його за своїм розсудом, відповідно обновивши препроцесор. Усе це говорить про те, що програміст не повинен втручати­ся в цей процес. Самі інструкції SQL препроцесор виділяє в окремий файл. Програма надходить на вхід звичайного компілятора мови програмування, після чого виходять об'єктні модулі. Далі ці об'єктні модулі разом із біблі­отеками СУБД збираються в один виконує модуль, що, - додаток. Поряд із цими операціями відбувається робота з файлом, що містить SQL- інструкції. У літературі цей модуль часто зветься «модуль запитів до бази даних» (Database Request Module, DBRM). Обробку цього модуля здійс­нює спеціальна утиліта, що зазвичай називається BIND. Для кожної ін­струкції SQL утиліта виконує наступні дії:

здійснює синтаксичний аналіз запиту (перевіряє, чи є запит коректним);

перевіряє, чи існують у базі даних ті об'єкти, на які посилається запит;

вибирає, яким чином здійснювати виконання запиту - план виконання запиту.

Усі плани виконання запитів зберігаються в СУБД для наступного використання.

Рис. 6.4. Схема компіляції програми зі вбудованими інструкціями статичного

Схема виконання програми виглядає в такий спосіб:

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

СУБД виконує запит відповідно до обраного плану. Результат вико­нання запиту надходить у додаток. Основними командами статичного SQL є:

EXEC SQL	специфікатор, що вказує, що наступна за ним інструкція є інструкцією вбу­дованого SQL
9	у мові С - ознака закінчення інструкції вбудованого SQL
DECLARE TABLE	повідомляє таблицю, що потім буде використовуватися в інструкціях вбу-

	дованого SQL
SQLCODE	змінна для обробки помилок
SQISTATE	змінна для обробки помилок
GET DIAGNOSTICS	інструкція для обробки помилок
WHENEVER SQLWARN1NG GOTO SQLERROR NOT FOUND CONTINUE	інструкцій для спрощення набір спіль­но використовувані обробки помилок
BEGIN DECLARE SECTION END DECLA RE SECTION	інструкції для визначення області, у якій будуть оголошені змінні, у нас­лідку використовувані в запитах SQL
INTO	використовується в операторі SELECT для вказівки змінної, у яку необхідно помістити результат виконання запиту

• можуть використатися тільки в тих місцях, де в запитах зазвичай стоять константи. Наприклад, неможливо параметризувати ім'я таблиці, з якої проводиться вибірка, а також назви колонок. У результаті ми приходимо до наступного висновку. При використанні статичного варіанта вбудованого (програмного) SQL необхідно на етапі написання програми точно знати склад запитів, які необхідно буде виконувати в програмі. У багатьох випадках це обмеження є істотним. Для його усунення реалізовано новий різновид програмного SQL — динамічний Розглянемо коротко основні ідеї динамічного SQL.

4. Динамічний SQL

Ще один різновид програмного призначена для вбудовування SQL-операторів у текст програми мовою програмування високого рівня, який допускає динамічне формування й виконання запитів під час роботи програми. Історія виникнення динамічного багато в чому пов'язана з компанією ІВМ, що впровадила цей потужний інструмент у свою СУБД DВ2. Стандарт SQL-89 не підтримував динамічний SQL. Лише в 1992 році в стандарт SQL-2 були включені специфікації динамічного SQL. Для того щоб використати цей інструментарій у своїх програмах, необхідно розумі­ти основні концепції та ідеї, закладені в динамічний SQL і принципи його функціонування. Саме це і є предметом розгляду в даному розділі. Теоре­тики вважають основною концепцією динамічного таке твердження: вбудована інструкція SQL не записується у вихідний текст програми[13]. Замість цього програма формує текст інструкції під час виконання в одній зі своїх областей даних, а потім передає сформовану інструкцію в СУБД для динамічного виконання.

Згадаємо, як працювала статична SQL. Схема використання передба­чала 2 етапи - компіляція програми й виконання програми. На етап компі­ляції лягало основне навантаження в тому розумінні, що він вирішував пи­тання перевірки, розбору й оптимізації запитів, оскільки було відомо, що саме розбирати й оптимізувати. Цілком очевидно, що подібну двоетапну схему не можна реалізувати для динамічного SQL, адже на етапі компіля­ції програми ще невідомо, що саме потрібно розбирати й оптимізувати. Які наслідки цієї зміни? Будь-який механізм має свої переваги й недоліки. Пе­реваги динамічного SQL у тому, що він дозволяє формувати запит до бази даних під час роботи програми, реагуючи на ті або інші події, що відбули­ся. Така можливість є життєво важливою для клієнт-серверної й триланко- вої архітектури, у яких структура бази даних і ділові правила мають тенде­нцію до зміни, що вимагає певної гнучкості при організації процесу обробки даних. Недолік динамічного SQL — низька продуктивність у порі­внянні зі статичним. Дійсно, багато з операцій, що виконувалися на етапі компіляції один раз, тепер виконуються безпосередньо під час роботи про­грами. У зв'язку із цим, вважається правильним рекомендувати викорис­тання статичного різновиду SQL, там, де тільки можливо. У свою чергу апарат динамічного SQL треба застосовувати тільки там, де без цього обій­тись неможливо. Розглянемо схему функціонування динамічного SQL. Схема передбачає одноетапне й двоетапне виконання інструкцій. Одноета- пне виконання інструкцій здійснюється командою EXECUTE в такій послі­довності:

IMMEDIATE. Модуль, що виконує, (запуск на виконання).

Виконання звичайних інструкцій МПВУ.

Виклик функцій СУБД для виконання інструкцій вбудованого SQL.

Аналіз синтаксису Перевірка наявності об'єктів. Оптимізація (вибір

плану)

Виконання плану.

Команда EXECUTE IMMEDIA ТЕ.

Схема виконання інструкції передбачає: двоетапне динамічне фор­мування команди SQL у рядковому вигляді під час роботи програми; двое- тапна передача рядкового вигляду інструкції в СУБД за допомогою коман­ди EXECUTE IMMEDIATE', двоетапне виконання інструкції системою керування БД, що включає синтаксичний аналіз, перевірку параметрів, оп- тимізацію (вибір плану) і виконання цього плану. Основні проблеми одно­стайної схеми полягають у тому, що вона не дозволяє виконувати інструк­ції SELECT (тому що немає засобів для повернення в додаток результатів запиту) і приводить до нераціональних витрат обчислювальних ресурсів (тому що при повторному виконанні тієї ж інструкції знову буде витраче­ний час на всі ті ж дії по її інтерпретації й виконанню).

Двоетапне виконання інструкцій ґрунтується на наступному мірку­ванні: швидше за все, команда динамічного SQL у такому виді, як вона на-

дходить на виконання, буде виконуватися неодноразово. ГІри цьому мо> жуть мінятися якісь конкретні деталі. А це значить, що інструкцію можна параметризувати. Використання параметризованих інструкцій дозволяє зробити схему виконання двоетапним, розділивши процес на «підготовку інструкції» і «виконання інструкції».

Рис. 6.5. Схема виконання програми із вбудованими інструкціями динамічного SQL із

застосуванням двоетапної схеми

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

EXECUTE IMMEDIATE -Негайне виконання інструкції;

PREPARE- Підготовка інструкції до виконання ;

EXECUTE - Виконання підготовленої раніше інструкції;

DESCRIBE - Спеціальна команда, що бере участь при поверненні резуль­тату виконання інструкцій динамічного SQL;

DECLARE CURSOR - Різновид інструкції DECLARE CURSOR, що застосо­вувалася раніше в рамках статичного SQL, яка містить замість запиту його ім'я (пов'язане із запитом за допомогою інструкції PREPARE);

OPEN FETCH CLOSE - Різновид інструкцій для роботи з курсором у дина­мічному SQL.

Як ми бачимо основу цих операторів складають згадувані в розділі оператори , які в мові SQL називаються операторами управлінням курсо- pa(Cursor Control Language).