Розділ 3 Розробка об’єктів для доступу до реляційним даним

3.1 Розробка об'єктів для маніпулювання даними

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

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

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

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

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

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

В курсовій роботі було розроблено 2 зберігаючих процедури: CREATE PROCEDURE PersonClientInsert та CREATE PROCEDURE PersonEmpInsert. Коди розробки зберігаючих процедури представлені в додатку Д

Найменші труднощі при розгляді наведеного вище коду викликає знайомий оператор INSERT. Єдиною відмінністю від класичного варіанта використання цього оператора є наявність змінних у пропозиції VALUES, що дозволяє змінювати внесену в таблиці Person й Employee інформацію, не переписуючи всього оператора Transact-SQL. Оскільки в заголовку збереженої процедури були визначені типи всіх змінних, можна не піклуватися про висновок у лапки внесених у таблицю строкових значень.

Розглянемо спосіб внесення інформації в таблицю Employee.

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

Необхідно звернути увагу на оголошення змінної @PersonID у. розташований далі оператор, привласнює значення цієї змінної, рівне значенню стовпця PersonID у тільки що внесеної в таблицю Person нового запису. Оскільки Рersonl є ідентифікаційним стовпцем таблиці Person, варто скористатися деяким спеціальним методом добування інформації із цього стовпця.

MS SQL Server надає кілька різних методів добування інформації з ідентифікаційного стовпця таблиці, однак у цьому випадку для виконання цієї операції скористаємося функцією IDENT_CURRENT. Як аргумент ця функція приймає ім'я таблиці, а як результат повертає значення первинного ключа останньої внесеної в таблицю запису.

Значення первинного ключа PersonID останньої внесеної в таблицю Person запису необхідно для створення відповідного йому зовнішнього ключа таблиці Employee, що дозволить встановити зв'язок між записами обох таблиць. Наявність такого зв'язку надто важливо для цілісності бази даних взагалі й для проведення об'єднань таблиці Employee з іншими таблицями зокрема. Значите первинного ключа таблиці Person привласнюється локальної змінної @PersonID і передається як параметр у наступний оператор INSERT.

Оператор INSERT, здійснює внесення інформації в таблицю Employee. Виконаєте код, у результаті чого MS SQL Server поверне повідомлення, що підтверджує успішне створення збереженої процедури.

Для того щоб упевнитися в працездатності тільки що створеної збереженої процедури, її необхідно хоча б один раз виконати. Але перед цим давайте здійснимо додаткову перевірку зберігаюча в таблицях Person й Employee інформації й переконаємося в тім, що її внесення, принаймні теоретично, пройде коректно. Процедура CREATE PROCEDURE PersonClientInsert дуже схожа на попередню.