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

Саратовський Державний університет ім. Н.Г. Чернишевського

на тему: «Особливості розробки тригерів і процедур, що зберігаються в СУБД»

(На прикладі бази даних відділу кадрів)

студентки I V курсу заочного відділення КН та ІТ

(Прикладна математика та інформатика)

ФРОЛОВОЇ Марії Олександрівни

2. Реляційна база даних

3. Збережені процедури

Список використаної літератури

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

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

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

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

За структурою організації даних бази поділяються на реляційні та нереляційні.

· Підтримка мов БД

p align="justify"> Для роботи з базами даних використовуються спеціальні мови, в цілому звані мовами баз даних. У ранніх СУБД підтримувалося кілька спеціалізованих за своїми функціями мов. Найчастіше виділялися дві мови – мова визначення схеми БД (SDL – Schema Definition Language) та мова маніпулювання даними (DML – Data Manipulation Language). SDL служив головним чином визначення логічної структури БД, тобто. тієї структури БД, якою вона представляється користувачам. DML містив набір операторів маніпулювання даними, тобто. операторів, що дозволяють заносити дані до БД, видаляти, модифікувати чи вибирати існуючі дані.

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

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

2.РЕЛЯЦІЙНІ БАЗА ДАНИХ (РБД)

Були створені таблиці DAN (Interbase) та дані (MS Access) зі стовпцями:

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

· Зв'язування однієї таблиці з іншого

Але на прикладі наших таблиць можна показати реальне використання у діловій ситуації. Припустимо, що персонажі у наших перших таблицях – це працівники МНС України. В іншій таблиці, ми могли б запам'ятати додаткову інформацію про них. Стовпці другої таблиці PROF (Interbase)та професія (MSAccess)професія виглядають так:

SELECT * FROM PROF;SELECT професія.[код професії], професія.[назва професії] FROM професія;
InterbaseMS Access
K_P NAZ ==== ======== 1 пожежник 2 водій 3 бухгалтер 4 інспектор 5 начальник варти 6 диспетчер 7 секретар 8 водометчик 9 командир відділення 10 начальник частини 11 заступник з тилу 12 навідниккод назва професії професії = = = = = = = = = = = == = = = = = = = == 1 пожежник 2 водій 3 бухгалтер 4 інспектор 5 начальник варти 6 диспетчер 7 секретар 8 водометчик 9 командир відділення 10 начальник частини 11 заступник по тилу 12 навідник

Багато потужних функцій можна виконати, витягуючи інформацію з цих таблиць згідно з зазначеними параметрами, особливо коли ці параметри включають всебе фрагменти інформації пов'язані у різних таблицях один з одним. Наприклад, візьмемо запит: Виведення співробітників з відповідними професіями:

Схеми баз даних (Database Diagrams) — це тип об'єктів, який є лише у проектах Access. Вони є аналогом схеми даних у базах даних Access, проте у проектах Access це поняття значно розширено.

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

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

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

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

На відміну від рядків, стовпці таблиці впорядковуються та нумеруються, так у таблиці № 3 OCLAD перший стовпець зліва K_O містить код окладу. Щоб уникнути неоднозначності, всі стовпці таблиці повинні мати різні імена.Крім того, він є первинним ключем – важливим елементом у структурі бази даних. Кожен стовпець має певний тип даних. Всі дані конкретного стовпця відносяться до одного типу: текст, число, дата тощо, оскільки містить однотипну інформацію.

InterbaseSELECT TAB_NO,FAM,IMIA,OTSH,G_R,PROF.NAZ FROM DAN,PROF WHERE DAN.K_P=PROF.K_P;
MS AccessSELECT дані.[табельний номер], дані.прізвище, дані.ім'я, дані.по батькові, дані.[рік народження], професія.[назва професії] FROM професія INNER JOIN дані ON професія.[код професії] = дані.[код професії];
InterbaseTAB_NO FAM IMIA OTSH G_R NAZ ====== ====================================== ================ 1001 Петров Петро Петрович 01.12.1971 інспектор 1002 Сидоров Павло Сергійович 10.03.1975 начальник варти 1003 Кортунов Сергій Володимирович 17.07.1963 начальник частини 1001. чер 1005 Романова Євлампія Апполінаріївна 04.12.1982 диспетчер 1006 Несміла Агрофена Агрипівна 04.11.1976 секретар 1007 Сердюков Ігор Ігнатович 27.05.1978 пожежний1009 Люб011008 Люб. Шарипов Руслан Імранович 14.08.1960 пожежний 1010 Ухабистова Авдотья Владиленівна 07.10.1956 бухгалтер 1011 Ігумнов Андрій Дмитрович 25.03.1962 заступник за тилом 1012 Іллюшин Дмитро Олександрович 19.11.1958 навідник 1013 Туполєв Едуард Валентинович 06.01.1969 пожежний 1014 Рабінович Іцхак Абрамович 124.09. 968 водій
MS Access