Функции без использования фразы group by

Если не используется фраза GROUP BY, то в перечень элементов_SELECT можно включать лишь SQL-функции или выражения, содержащие такие функции. Другими словами, нельзя иметь в списке столбцы, не являющихся аргументами SQL-функций.

Например, выдать данные о массе лука (ПР=10), проданного поставщиками, и указать количество этих поставщиков:

	Результат:
SELECT SUM(К_во),COUNT(К_во) FROM Поставки WHERE ПР = 10;
	SUM(К_во)	COUNT(К_во)
	220	2

Если бы для вывода в результат еще и номера продукта был сформирован запрос

SELECT ПР,SUM(К_во),COUNT(К_во)

FROM Поставки

WHERE ПР = 10;

то было бы получено сообщение об ошибке. Это связано с тем, что SQL-функция создает единственное значение из множества значений столбца-аргумента, а для "свободного" столбца должно быть выдано все множество его значений. Без специального указания (оно задается фразой GROUP BY) SQL не будет выяснять, одинаковы значения этого множества (как в данном примере, где ПР=10) или различны (как было бы при отсутствии WHERE фразы). Поэтому подобный запрос отвергается системой.

Правда, никто не запрещает дать запрос

SELECT 'Кол-во лука =',SUM(К_во),COUNT(К_во)

FROM Поставки

WHERE ПР = 10;

Результат:
'Кол-во лука ='	SUM(К_во)	COUNT(К_во)
Кол-во лука =	220	2

Отметим также, что в столбце-аргументе перед применением любой функции, кроме COUNT(*), исключаются все неопределенные значения. Если оказывается, что аргумент - пустое множество, функция COUNT принимает значение 0, а остальные - NULL.

Например, для получения суммы цен, средней цены, количества поставляемых продуктов и количества разных цен продуктов, проданных коопторгом УРОЖАЙ (ПС=5), а также для получения количества продуктов, которые могут поставляться этим коопторгом, можно дать запрос

SELECT SUM(Цена),AVG(Цена),COUNT(Цена),

COUNT(DISTINCT Цена),COUNT(*)

FROM Поставки

WHERE ПС = 5;

и получить

SUM(Цена)	AVG(Цена)	COUNT(Цена)	COUNT(DISTINCT Цена)	COUNT (*)
6.2	1.24	5	4	7

В другом примере, где надо узнать "Сколько поставлено моркови и сколько поставщиков ее поставляют?":

SELECT SUM(К_во),COUNT(К_во)

FROM Поставки

WHER ПР = 2;

будет получен ответ:

SUM(К_во)	COUNT (К_во)
-0-	0

Наконец, попробуем получить сумму массы поставленного лука с его средней ценой ("Сапоги с яичницей"):

	Результат:
SELECT (SUM(К_во) +AVG(Цена)) FROM Поставки WHERE ПР = 10;
	SUM(К_во)+AVG(Цена)
	220.6

3. Поняття об’єктних та зв’язкових відношень в реляційних бд та суть умови посилкової цілістності даних.

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

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

Ключі в зв’язкових відношеннях називаються вторинними або зовнішніми ключами, оскільки вони є первинними ключами об’єктів інших відношень. Реляційна модель накладає на зовнішні ключі обмеження, яке називають посилковою цілісністю. Воно необхідне для забезпечення цілісності даних. Посилкова цілісність — це відповідність між об’єктними та зв’язковими відношеннями, яка полягає в тому, що кожному зовнішньому ключеві зв’язкового відношення має відповідати рядок якогось об’єктного відношення. Без такого обмеження може статися так, що зовнішній ключ посилається на об’єкт, про який нічого не відомо. У реляційній БД накладається ще одне обмеження — відношення мають бути нормалізовані.

Білет 20.

1. Додаткові обов’язки DBA

Додаткові обов’язки DBA:

• аналіз даних. Іноді DBA просять провести аналіз даних, щоб одержати рекомендації щодо поліпшення продуктивності чи ефективності збереження даних. Це може бути пов’язано з індексацією таблиць або з функціонуванням паралельних запитів;

• розробка БД (попередня). DBA часто залучається до попередньої стадії розробки структури БД. При включенні DBA у процес дизайну БД багато проблем можуть бути попереджені;

• моделювання та оптимізація даних. При моделюванні даних можна врахувати особливості системи вводу-виводу і значно збільшити продуктивність СУБД;

• надання допомоги розроблювачам у питаннях мови SQL, про збережені процедури. DBA повинен бути готовим стати консультантом для розроблювачів і користувачів. Він досить часто залучається до усунення проблем SQL-коду і до розробки (написанню) збережених процедур;

• розробка виробничих стандартів і угод по іменах. Оскільки в розробці і розгортанні додатків можуть брати участь декілька різних груп програмістів, то DBA часто залучається на роль розроблювача виробничих стандартів і угод по іменах, щоб додатки відповідали цим стандартам;

• документування середовища. DBA повинен документувати кожен аспект середовища СУБД, включаючи конфігурацію устаткування, відновлення та зміни програмного забезпечення і СУБД, а також усі питання, пов’язані зі зміною системи і її параметрів;

• консультування розробників і кінцевих користувачів;

• перевірка і тестування нових програм. DBA може брати участь у перевірці нових програм, для того, щоб дати рекомендації, основані на цій перевірці. Це може бути придбання нового програмного забезпечення чи планове їх відновлення і перехід на нові версії;

• оцінка нового програмного й апаратного забезпечення;

• планування завантаження системи і необхідного обсягу пам’яті. Визначення необхідності в придбанні додаткових серверів, додаткової дискової й оперативної пам’яті, щоб задовільнити зрослі потреби користувачів.

2. Використання GROUP BY

Фраза GROUP BY

Мы показали, как можно вычислить массу определенного продукта, поставляемого поставщиками. Предположим, что теперь требуется вычислить общую массу каждого из продуктов, поставляемых в настоящее время поставщиками. Это можно легко сделать с помощью предложения

SELECT ПР, SUM(К_во)

FROM Поставки

GROUP BY ПР;

Фраза GROUP BY (группировать по) инициирует перекомпоновку указанной во FROM таблицы по группам, каждая из которых имеет одинаковые значения в столбце, указанном в GROUP BY. В рассматриваемом примере строки таблицы Поставки группируются так, что в одной группе содержатся все строки для продукта с ПР = 1, в другой – для продукта с ПР = 2 и т.д.. Далее к каждой группе применяется фраза SELECT. Каждое выражение в этой фразе должно принимать единственное значение для группы, т.е. оно может быть либо значением столбца, указанного в GROUP BY, либо арифметическим выражением, включающим это значение, либо константой, либо одной из SQL-функций, которая оперирует всеми значениями столбца в группе и сводит эти значения к единственному значению (например, к сумме).

Отметим, что фраза GROUP BY не предполагает ORDER BY. Чтобы гарантировать упорядочение по ПР результата рассматриваемого примера следует дать запрос

SELECT ПР, SUM(К_во)

FROM Поставки

GROUP BY ПР

ORDER BY ПР;

Наконец, отметим, что строки таблицы можно группировать по любой комбинации ее столбцов. Так, по запросу

SELECT Т, БЛ, COUNT(БЛ)

FROM Заказ

GROUP BY Т, БЛ;

можно узнать коды и количество порций блюд, заказанных отдыхающими пансионата (32 человека) на каждую из трапез следующего дня:

Если в запросе используются фразы WHERE и GROUP BY, то строки, не удовлетворяющие фразе WHERE, исключаются до выполнения группирования.

Например, выдать для каждого продукта его код и общий объем возможных поставок, учитывая временную недееспособность поставщика с ПС=2:

SELECT

ПР, SUM(К_во) FROM

Поставки WHERE

ПС <> 2

GROUP BY ПР;

3. Порядок приведення реляційних відношень до 3НФ(4НФ).

Приведення до першої нор­мальної форми починається з перетворення даних з формату джерела (наприклад, первинного документа) у формат двовимір­ної таблиці, що містить певну кількість рядків і стовпчиків. Відношення в ШФ мають відповідати таким вимогам:* усі атрибути відношення повинні бути унікальними;• усі рядки таблиці повинні мати однакову структуру;• імена стовпців мають бути різними, а значення однорідними (однакового формату);* порядок рядків у таблиці не суттєвий. . На другому кроці нормалізації виявляють функціона­льні залежності відношення і будують діаграму функціональних залежностей неключових атрибутів від ключів, аналізують ці за­лежності з метою вилучення неповних функціональних залежно­стей. Отже, відношення перебувають у 2НФ, якщо вони перебува­ють у 1НФ і кожний неключовий атрибут функціонально повно залежить від складового ключа.

2НФ повністю усуває можливість виникнення протиріччя да­них, а також економить пам'ять при зберіганні відношень у пам'яті ЕОМ. Відношення в 2НФ потрібно аналізувати на присутність тран­зитивних залежностей. Якщо таких немає, відношення у 2 НФ автоматично є відношенням у ЗНФ.

Третій крок нормалізації — вилучення транзитивних залежно­стей. Тобто залежностей між неключовими атрибутами.

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

Білет 21.

1. Адміністратор БД

DBA – Database Administrator або АБД – адміністратор бази даних. Він одноосібно відповідає за її стан і має такі обов’язки:

• установка нового програмного забезпечення – це основний обов’язок DBA. Він полягає в установці нових версій Oracle, додатків і іншого програмного забезпечення, яке стосується адміністрування СУБД;

• конфігурування програмного й апаратного забезпечення (разом із системним адміністратором);

• досягнення безпеки. Це теж один із основних обов’язків DBA. Керування безпекою й адмініструванням БД включає такі роботи, як додавання і видалення користувачів, керування квотами, аудит, вирішення проблем безпеки та ін.;

• настройка продуктивності і моніторинг системи. DBA повинен постійно перевіряти продуктивність СУБД, а при необхідності виконувати настроювання. Навіть добре побудована система має потребу в постійній перевірці і періодичному перенастроюванні;

• резервне копіювання і відновлення системи. Головна задача DBA – зберігати дані в системі. Щоб робити це ефективно, необхідно розробити процедуру резервного копіювання і стратегію відновлення даних. Дуже важливо періодично тестувати відпрацьовану схему резервного копіювання і відновлення БД;

• процедура планового обслуговування. У задачу DBA входить також обов’язок складання календара обслуговування СУБД. Найкраще робити обслуговування СУБД вранці або у вихідні дні, щоб не викликати невдоволення користувачів у випадку відмови БД. В обслуговування входять архівування, тестування і настроювання;

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

• відновлення системи після збою. Оскільки збій системи спричиняє втрату користувачами доступу до своїх даних, DBA зобов’язаний якнайшвидше відновити роботу системи. Добре підготовлений DBA має план відновлення системи після збою.

2. Декартові створення таблиць

Декартово произведение таблиц

Соединения - это подмножества декартова произведения. Так как декартово произведение n таблиц - это таблица, содержащая все возможные строки r, такие, что r является сцеплением какой-либо строки из первой таблицы, строки из второй таблицы, ... и строки из n-й таблицы (а мы уже научились выделять с помощью SELECT любое подмножество реляционной таблицы), то осталось лишь выяснить, можно ли с помощью SELECT получить декартово произведение. Для получения декартова произведения нескольких таблиц надо указать во фразе FROM перечень перемножаемых таблиц, а во фразе SELECT – все их столбцы.

Так, для получения декартова произведения Вид_блюд и Трапезы надо выдать запрос

SELECT Вид_блюд.*, Трапезы.*

FROM Вид_блюд, Трапезы;

Получим таблицу, содержащую 5 х 3 = 15 строк:

перемножая таблицы Меню, Трапезы, Вид_блюд, Блюда:

SELECT Меню.*, Трапезы.*, Вид_блюд.*, Блюда.*

FROM Меню, Трапезы, Вид_блюд, Блюда;

образуется таблица содержащая 21 х 3 х 5 х 33 = 10395 строк.

Из первых 39 строк этой таблицы лишь две актуальных (отмечены "*"): в них совпадают номера блюд таблиц Меню и Блюда. В остальных – полная чепуха: к закускам отнесены супы и напитки, на завтрак предлагается незапланированный суп и т.д.

3. Порядок приведення реляційних відношень до нормальної форми Бойса-Кодда.(Фил)

Нормальна форма Бойса-Кодда, або ж підсилена 3НФ, аналізує відношення, що перебувають у 3НФ, але характеризуються аномаліями оновлення.

Класичне визначення ЗНФ не підходить для відношень, що характеризуються такими властивостями:

відношення має два (чи більше) потенційних ключі;

два потенційних ключі є складовими;

складові ключі перекриваються, тобто мають хоча б один спільний атрибут.

Означення: Відношення знаходиться в нормальній формі Бойса-Кодда тоді, коли всі його детермінанти є потенційними ключами.

Інакше кажучи, всі стрілки на діаграмі функціональної залежності у відношенні, що знаходиться у НФБК, можуть починатись лише з потенційних ключів і відповідно жодну з них не можна виключити за допомогою процедури декомпозиції.

Відношення, яке перебуває в НФБК, завжди є відношенням у ЗНФ. І, навпаки, відношення в ЗНФ не завжди можна привести до нормальної форми Бойса-Кодда, не втративши залежності між його атрибутами.

Розглянемо такий приклад. Нехай задано відношення R (місто, адреса, індекс), в якому є такі залежності:

Зведення відношення до ЗНФ дасть два відношення: R1 (місто, адреса), R2 (адреса, індекс). Вони перебувають у ЗНФ, але не є відношеннями в НФБК, оскільки у відношенні R існує залежність індекс -> місто, тобто відношення в ЗНФ не завжди є відношенням у НФБК. Якщо ми зведемо це відношення до НФБК, то отримаємо відношення R1 (місто, адреса), R2 (індекс, місто), в яких будуть відображені не всі залежності початкового відношення. Так, не буде відображено залежності індекс -> адреса, а саме індекс позначає відділення зв'язку, що обслуговує адресатів якоїсь вулиці певного міста. Отже, зведення до НФБК може призвести до втрати важливих для початкового відношення залежностей, а з'єднання отриманих у результаті такої деком позиції відношень не дасть початкового відношення. Тому при зведенні до НФБК необхідно ретельно вивчати всі залежності і виконувати його лише тоді, коли виконується така вимога: «з'єднання без втрат».

Відношення в НФБК завжди є відношенням у ЗНФ, але не завжди відношення в ЗНФ є відношенням у НФБК.

Нормальна форма Бойса-Кодда має такі самі переваги, що й ЗНФ, але її виконання потребує особливої уваги з погляду її зворотності.

Білет 22.

1. Знімок

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

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

Оператор визначення знімків Oracle використовує такий синтаксис:

CREATE SNAPSHOT [ім'я_схеми.]ім'я_знімка

TABLESPACE ім'я_табличної_області

STORAGE розмір_пам'яті

[REFRESH [FAST | COMPLETE | FORCE]

[START WITH дата_1 ][NEXT дата_2 ]]

[FOR UPDATE] AS запит;

2. Еквіз’єднання таблиць

Эквисоединение таблиц

Если из декартова произведения убрать ненужные строки и столбцы, то можно получить актуальные таблицы, соответствующие любому из соединений.

Очевидно, что отбор актуальных строк обеспечивается вводом в запрос WHERE фразы, в которой устанавливается соответствие между:

кодами трапез (Т) в таблицах Меню и Трапезы (Меню.Т = Трапезы.Т),

кодами видов блюд (В) в таблицах Меню и Вид_блюд (Меню.В = Вид_блюд.В),

номерами блюд (БЛ) в таблицах Меню и Блюда (Меню.БЛ = Блюда.БЛ).< /li >

Такой скорректированный запрос

SELECT Меню.*, Трапезы.*, Вид_блюд.*, Блюда.*

FROM Меню, Трапезы, Вид_блюд, Блюда

WHERE Меню.Т = Трапезы.Т

AND Меню.В = Вид_блюд.В

AND Меню.БЛ = Блюда.БЛ;

позволит получить эквисоединение таблиц Меню, Трапезы, Вид_блюд и Блюда:

3. Поняття та основні вимоги до даталогічного проектування

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

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

Основними факторами, що впливають на даталогічне проектування з боку СКБД, є:

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

Особливості фізичної організації даних у середовищі вибраної СКБД. Наприклад, у СКБД Paradox чи dBASE-системах база даних організована у вигляді набору взаємозв'язаних файлів форматів DT і DBF. Усі інші об'єкти, такі як форми та звіти, також зберігаються в окремих файлах. У середовищі СКБД Microsoft Access усі дані та інструментальні засоби роботи з ними зберігаються в єдиному файлі бази даних. Тому при проектуванні БД потрібно знати не лише правила побудови логічної, а й особливості фізичної організації бази даних.

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

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

Білет 23

1. Синтаксис операторів знімків Oracle

Оператор визначення знімків Oracle використовує такий синтаксис:

CREATE SNAPSHOT [ім'я_схеми.]ім'я_знімка

TABLESPACE ім'я_табличної_області

STORAGE розмір_пам'яті

[REFRESH [FAST | COMPLETE | FORCE]

[START WITH дата_1 ][NEXT дата_2 ]]

[FOR UPDATE] AS запит;

Ключове слово TABLESPACE визначає ім’я табличної області, у якій буде розміщений знімок. Якщо значення цього параметра не задано, то він розміщується в табличній області, заданій за замовчуванням для користувача – власника схеми, яка містить знімок.

Ключове слово STORAGE визначає обсяг зовнішньої пам’яті, яка виділяється під знімок. Для великих знімків доцільно явно виділяти необхідну пам’ять, щоб зменшити кількість запитів на динамічне виділення простору.

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

Ключове слово START WITH визначає дату першого автоматичного відновлення знімка за допомогою параметра дaтa_1. Природно, що параметр дaтa_1 повинен мати тип дати.

Ключове слово NEXT визначає за допомогою параметра дата_2 інтервал між автоматичними відновленнями знімка. Якщо ключове слово REFRESH опущене, то автоматичного відновлення даних знімка не відбувається. Також не відбувається автоматичного відновлення даних знімка, якщо опущені ключові слова: START WITH і NEXT. Тобто, зміни в майстрі-таблиці не поширюються на дані знімка автоматично.

Ключове слово FOR UPDATE означає, що дані знімка можна змінювати. Слово AS запит включає в знімок рядок, який є результатом виконання запиту. Параметр запит використовується для позначення будь-якого синтаксично правильного запиту, який не містить ключових слів ORDER BY або FOR UPDATE.

Для модифікації знімка можна скористатися командою ALTER SNAPSHOT.

2. Природне з’єднання та композиція таблиць

Естественное соединение таблиц

Легко заметить, что в эквисоединение таблиц вошли дубликаты столбцов, по которым проводилось соединение (Т, В и БЛ). Для исключения этих дубликатов можно создать естественное соединение тех же таблиц:

SELECT Т, В, БЛ, Трапеза, Вид, Блюдо, Основа, Выход, Труд

FROM Меню, Трапезы, Вид_блюд, Блюда

WHERE Меню.Т = Трапезы.Т

AND Меню.В = Вид_блюд.В

AND Меню.БЛ = Блюда.БЛ;

Реализация естественного соединения таблиц имеет вид

Композиция таблиц

Для исключения всех столбцов, по которым проводится соединение таблиц, надо создать композицию

SELECT Трапеза, Вид, Блюдо, Основа, Выход, Труд

FROM Меню, Трапезы, Вид_блюд, Блюда

WHERE Меню.Т = Трапезы.Т

AND Меню.В = Вид_блюд.В

AND Меню.БЛ = Блюда.БЛ;

3. Критерії вибору СУБД

Основні критерії: Операційне середовище. Переважна більшість систем має кілька версій, можуть працювати в різному операційному середовищі (UNIX-Solaris, Windows Server, Windows чи Linux). Винятком є лише Microsoft SQL Server, яка працює лише на Windows.Операційну систему вибирають у тому разі, якщо розробки лише плануються.

Загальні характеристики. До цих характеристик належать тип ЕОМ, операційне середовище, тип логічної моделі бази даних, кількісні обмеження СКБД (максимальне число записів у файлі та його максимальний обсяг, максимальне число індексів на один файл БД, максимальна кількість одночасно відкритих таблиць тощо), наявність русифікованої версії, фірма-виробник, обсяг оперативної пам'яті для системи, необхідність використання постійної пам'яті, тип системи (відкрита, закрита), мова системи (власна, СІ, Паскаль та ін.), кількість версій, що свідчить про попит на систему і спроби виробника вдосконалити систему, наявність версії, що підтримує розподілену базу даних.

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

обслуговування реплікацій;• забезпечення паралельної обробки даних. 3. Засоби підтримки прикладного програмного забезпечення -• підтримка OLAP-технологій. * підтримка розподілених запитів і трансакцій. • наявність мови запитів на базі SQL чи іншої мови;• наявність генератора програм і генератора звітів;* можливість захисту програмного продукту;

та ін. 4.Засоби підтримки роботи в мережі - • можливість роботи в глобальній мережі; * наявність автоматизованих засобів стеження за узгодженістю та цілісністю даних мережі при колективному використанні даних та ін. 5.Вартість системи. Вартість системи залежить від фірми виробника і виду СКБД та кількості її інсталяцій. Вартість повнофункціональної СКБД коливається у межах 500—1000 у.о., вартість сервера — від кількох сот до п'ятисот тисяч у.о.

Білет 24

1. Синоніми

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

Оператор визначення синоніма використовує такий синтаксис:

CREATE [PUBLIC] SYNONYM [ім’я_схеми.]ім’я_синоніма

FOR [ім’я_схеми2.]ім’я_ об’єкта[@ім’я_зв’язку_БД];

Ключове слово PUBLIC означає, що синонім буде доступний усім користувачам. За замовчуванням синонім доступний тільки користувачу, який його створив.

Синонім повинен мати ім’я, відмінне від інших об’єктів даного користувача. Параметр ім’я_синоніма ­– ім’я синоніма повинен відповідати угодам з найменувань об’єктів Oracle. Параметр ім’я_схеми задає ім’я існуючої в БД схеми. Для створення синоніма в довільній схемі потрібні відповідні привілеї. Якщо ім'я_схеми для синоніма опущено, то передбачається, що синонім створюється в схемі користувача, який видав команду.

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

Параметр ім'я_схеми2 задає ім’я схеми, у якій знаходиться об’єкт, для якого створюється синонім, а параметр ім’я_об’єкта вказує на цей об’єкт.

Для вилучення синоніма з БД необхідно бути його власником або мати привілей DROP ANY SYNONYM. Оператор вилучення синоніма має такий синтаксис:

DROP [PUBLIC] SYNONYM [ім'я_схеми.]ім'я_синоніма;

Тут необов’язкове ключове слово PUBLIC визначає факт вилучення загального синоніма. Параметр ім'я_синоніма визначає ім’я синоніма, який вилучається. Змінити синонім можна, скасувавши його і призначивши заново.

2. Тета з’єднання таблиць. З’єднання таблиць додатковими умовами

Тета-соединение таблиц

В базе данных ПАНСИОН трудно подобрать несложный пример, иллюстрирующий тета-соединение таблиц. Поэтому сконструируем такой надуманный запрос:

SELECT

Вид_блюд.*, Трапезы.* FROM

Вид_блюд, Трапезы WHERE

Вид > Трапеза;

позволяющий выбрать из полученного декартова произведения таблиц Вид_блюд и Трапезы лишь те строки, в которых значение трапезы "меньше" (по алфавиту) значения вида блюда:

Соединение таблиц с дополнительным условием

При формировании соединения создается рабочая таблица, к которой применимы все операции,: отбор нужных строк соединения (WHERE фраза), упорядочение получаемого результата (ORDER BY фраза) и агрегатирование данных (SQL-функции и GROUP BY фраза).

Например, для получения перечня блюд, предлагаемых в меню на завтрак, можно сформировать запрос на основе композиции

SELECT Вид, Блюдо, Основа, Выход, 'Номер -', БЛ

FROM Меню, Трапезы, Вид_блюд, Блюда

WHERE Меню.Т = Трапезы.Т

AND Меню.В = Вид_блюд.В

AND Меню.БЛ = Блюда.БЛ

AND Трапеза = ’Завтрак’;

3. Відображення на ієрархічну модель БД

Відображення на єрархічну модель виконується в два етапи.

Загальне відображення на єрархічну модель без урахування обмежень єрархічної СКБД. 2. Модифікація моделі з урахуванням обмежень, як. накладає вибрана єрархічна СКБД.

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

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

Першим кроком відображення інфологічної моделі на єрархічну буде вибір з-поміж інформаційних об'єктів інфологічної моделі того об'єкта, який міг би бути кореневим сегментом. 2. Зв'язки в єрархічних моделях будують за принципом «вихідний-продовжений». Тому другим кроком відображення на єрархічну модель є аналіз інформаційних об'єктів і виявлення з-поміж них ієрархічної підпорядкованості за принципом: «рід-вид», «ціле-частина», «причина - наслідок» і т. ін. В результаті цього аналізу об'єкти розміщуються по рівнях ієрархії.3. В єрархічній моделі підтримуються лише такі типи співвідношень між даними: 1:1 і 1 : Б. Тому потрібно перевірити типи співвідношень між даними і обмежитися лише згаданими. Другий етап відображення полягає в модифікації отриманої моделі з урахуванням обмежень вибраної єрархічної СКБД.

Білет 25.

1. Розподілена транзакція

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

Розподілена транзакція виконується в такій послідовності:

1. система А посилає повідомлення GET READY зв’язаним системам В і С та робить відмітку в журналі;

2. якщо В або С готові виконати свою частину транзакції, то вони посилають сигнал “Так”, роблять помітку в локальних журналах і переходять у стан готовності, інакше посилають “Ні”;

3. система А очікує на всі відповіді. Якщо всі відповіді “Так”, тоді посилається команда COMMIT. Якщо є хоча б одне “Ні”, то всім посилається ROLLBACK;

4. B і С зобов’язані виконати команду і повідомити про результат. Якщо в цей час відбувся збій (наприклад, на В), то після відновлення працездатності система В, перевіривши журнал і не знайшовши запису про завершення, знову зв’язується з А і завершує транзакцію.

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

2. З’єднання таблиці з ії копією

Соединение таблицы со своей копией

В ряде приложений возникает необходимость одновременной обработки данных какой-либо таблицы и одной или нескольких ее копий, создаваемых на время выполнения запроса.

Например, при создании списков студентов (таблица Студенты) возможен повторный ввод данных о каком-либо студенте с присвоением ему второго номера зачетной книжки. Для выявления таких ошибок можно соединить таблицу Студенты с ее временной копией, установив в WHERE фразе равенство значений всех одноименных столбцов этих таблиц кроме столбцов с номером зачетной книжки (для последних надо установить условие неравенства значений).

Временную копию таблицы можно сформировать, указав имя псевдонима за именем таблицы во фразе FROM. Так, с помощью фразы

FROM Блюда X, Блюда Y, Блюда Z

будут сформированы три копии таблицы Блюда с именами X, Y и Z.

В качестве примера соединения таблицы с ней самой сформируем запрос на вывод таких пар блюд таблицы Блюда, в которых совпадает основа, а название первого блюда пары меньше (по алфавиту), чем номер второго блюда пары. Для этого можно создать запрос с одной копией таблицы Блюда (Копия):

SELECT Блюдо, Копия.Блюдо, Основа

FROM Блюда, Блюда Копия

WHERE Основа = Копия.Основа

AND Блюдо < Копия.Блюдо;

или двумя ее копиями (Первая и Вторая):

SELECT Первая.Блюдо, Вторая.Блюдо, Основа

FROM Блюда Первая, Блюда Вторая

WHERE Первая.Основа = Вторая.Основа

AND Первая.Блюдо < Вторая.Блюдо;

3. Відображення на мережеву модель БД

Мережева модель БД — це орієнтований граф з поіменованими дугами і вершинами.

Основними структурними елементами моделей цього типу є агрегат, запис і набір даних.

При відображенні інфологічної моделі на мережеву інформа­ційним об'єктам ставлять у відповідність записи. Кожний запис вміщує певну множину атрибутів. Розрізняють такі поняття, як тип запису і екземпляр запису. Тип запису — це абстрактні харак­теристики, а екземпляр запису — їх конкретні значення. Усередині запису можуть виокремлюватись агрегати. Агрегат — це поіменована сукупність логічно взаємозв'язаних атрибутів усередині типу запису: ними можуть бути вектори, групи і по­вторюючі групи.

Два типи записів, об'єднані між собою дугою, організують набір даних, тобто набір — це поіменована сукупність зв'язаних записів. У мережевих моделях також можливе звертання до на­бору, тобто до двох взаємозв'язаних типів записів. Тип запису, з якого виходить дуга, називається власником набору, або основ­ним файлом. Тип запису, в який входить дуга, називається чле­ном набору, або підпорядкованим файлом. Дуга, спрямована від власника набору до його члена, являє собою логічний взаємо­зв'язок «один до багатьох» між власником і членом набору да­них.

Білет 26.

1. Основні характеристики віддалених СУБД

Основними характеристиками віддалених СУБД є такі:

1. прозорий протокол двофазної фіксації змін. Він забезпечує непротирічивість даних, транзакція, яка змінює дані в декількох вузлах, вважається успішною лише тоді, коли успішно виконалась обробка у всіх вузлах. У випадку помилки хоча би в одному з них результати роботи всієї транзакції анулюються;

2. горизонтальна і вертикальна фрагментація. Тобто таблицю можно розділити на рядки (горизонтально) або на стовпчики (вертикально), які розташувати в різних вузлах мережі;

3. незалежне дублювання даних, яке дозволяє створювати у вузлах дублі (копії) даних без зниження продуктивності програм і порушення цілісності даних;

4. можливість з’єднання таблиць, розташованих у різних вузлах, та одержання розподілених представлень;

5. оптимизація розподілених запитів. Алгоритми виконання складних операций (наприклад, з’єднання таблиць) повинні враховувати місце розташування даних у глобальній мережі, її пропускну здатність, ступінь завантаження, об’єм передаваних даних і обчислювальну потужність вузлів та вибирати оптимальний вузол для відповідної операції;

6. розподілення обмеження цілістності даних. Якщо між таблицями в різних вузлах існує залежність, то при модифікації основної таблиці автоматично модифікуються й таблиці, залежні від неї;

7. локальна автономія. Адміністратор БД даного вузла повністю контролює свою локальну БД, тобто може працювати незалежно від адміністраторів БД інших вузлів;

8. неперевна обробка. Команда, яка виконується в локальному вузлі БД, не може бути перервана з іншого вузла, тобто в кожному вузлі вона виконується незалежно і цілком;

9. незалежність від розміщення. Зміна місця зберігання даних не змінює програми, які їх обробляють;

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

11. глобальна. обробка взаємних блокувань і конфліктних ситуацій, які виникають при одночасному доступі до даних. Блокування даних може виконуватися в будь-якому вузлі БД, тому необхідно виявляти і розв’язувати ситуації, коли два різні вузли одночасно взаємно блокують один одного;

12. незалежність від типу комп’ютерів, операційних систем, мереживних протоколів, типів СУБД та шлюзів (gateways);

2. Види вкладених підзапитів

Вложенный подзапрос - это подзапрос, заключенный в круглые скобки и вложенный в WHERE (HAVING) фразу предложения SELECT или других предложений, использующих WHERE фразу. Вложенный подзапрос может содержать в своей WHERE (HAVING) фразе другой вложенный подзапрос и т.д. Нетрудно догадаться, что вложенный подзапрос создан для того, чтобы при отборе строк таблицы, сформированной основным запросом, можно было использовать данные из других таблиц (например, при отборе блюд для меню использовать данные о наличии продуктов в кладовой пансионата).

Существуют простые и коррелированные вложенные подзапросы. Они включаются в WHERE (HAVING) фразу с помощью условий IN, EXISTS или одного из условий сравнения ( = | <> | < | <= | > | > = ). Простые вложенные подзапросы обрабатываютя системой "снизу вверх". Первым обрабатывается вложенный подзапрос самого нижнего уровня. Множество значений, полученное в результате его выполнения, используется при реализации подзапроса более высокого уровня и т.д.

Запросы с коррелированными вложенными подзапросами обрабатываются системой в обратном порядке. Сначала выбирается первая строка рабочей таблицы, сформированной основным запросом, и из нее выбираются значения тех столбцов, которые используются во вложенном подзапросе (вложенных подзапросах). Если эти значения удовлетворяют условиям вложенного подзапроса, то выбранная строка включается в результат. Затем выбирается вторая строка и т.д., пока в результат не будут включены все строки, удовлетворяющие вложенному подзапросу (последовательности вложенных подзапросов).

Следует отметить, что SQL обладает большой избыточностью в том смысле, что он часто предоставляет несколько различных способов формулировки одного и того же запроса. Поэтому во многих примерах данной главы будут использованы уже знакомые нам по предыдущей главе концептуальные формулировки запросов. И несмотря на то, что часть из них успешнее реализуется с помощью соединений, здесь все же будут приведены их варианты с использованием вложенных подзапросов. Это связано с необходимостью детального знакомства с созданием и принципом выполнения вложенных подзапросов, так как существует немало задач (особенно на удаление и изменение данных), которые не могут быть реализованы другим способом. Кроме того, разные формулировки одного и того же запроса требуют для своего выполнения различных ресурсов памяти и могут значительно отличаться по времени реализации в разных СУБД.

3. Відображення на реляційну модель БД

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

Інформаційні об'єкти інфологічної моделі представляються в табличному вигляді і стають реляційними відношеннями. Необхідно лише перевірити виконання таких умов:

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

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

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

Білет 27.

1. Розподілена СУБД

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

Вузли являють собою комп’ютери, зв’язані мережею, а не процесори, які складають багатопроцесорну конфігурацію. Характер середовища є слабозв’язаний, де кожний вузол має власну операційну систему і функціонує незалежно.

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

Існують два способи доступу до віддалених даних:

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

2. реплікована база даних з використанням матеріалізованих представлень (materialized view), або знімків (snapshots). В цьому випадку на віддалених вузлах зберігаються копії або фрагменти головної розподіленої бази даних.

2. Прості вкладені підзапити

Простые вложенные подзапросы

Простые вложенные подзапросы используются для представления множества значений, исследование которых должно осуществляться в каком-либо предикате IN, что иллюстрируется в следующем примере: выдать название и статус поставщиков продукта с номером 11, т.е. помидоров.

	Результат:
SELECT Название, Статус FROM Поставщики WHERE ПС IN ( SELECT ПС FROM Поставки WHERE ПР = 11 );	Название Статус СЫТНЫЙ рынок УРОЖАЙ коопторг ЛЕТО агрофирма КОРЮШКА кооператив

при обработке полного запроса система выполняет прежде всего вложенный подзапрос. Этот подзапрос выдает множество номеров поставщиков, которые поставляют продукт с кодом ПР = 11, а именно множество (1, 5, 6, 8). Поэтому первоначальный запрос эквивалентен такому простому запросу:

SELECT Название, Статус

FROM Поставщики

WHERE ПС IN (1, 5, 6, 8);

Подзапрос с несколькими уровнями вложенности можно проиллюстрировать на том же примере. Пусть требуется узнать не поставщиков продукта 11, как это делалось в предыдущих запросах, а поставщиков помидоров, являющихся продуктом с номером 11. Для этого можно дать запрос

SELECT Название, Статус

FROM Поставщики

WHERE ПС IN

( SELECT ПС

FROM Поставки

WHERE ПР IN

( SELECT ПР

FROM Продукты

WHERE Продукт = 'Помидоры' ));

В данном случае результатом самого внутреннего подзапроса является только одно значение (11). Как уже было показано выше, подзапрос следующего уровня в свою очередь дает в результате множество (1, 5, 6, 8). Последний, самый внешний SELECT, вычисляет приведенный выше окончательный результат. Вообще допускается любая глубина вложенности подзапросов.

Тот же результат можно получить с помощью соединения

SELECT Название, Статус

FROM Поставщики, Поставки, Продукты

WHERE Поставщики.ПС = Поставки.ПС

AND Поставки.ПР = Продукты.ПР

AND Продукт = 'Помидоры';

При выполнении этого компактного запроса система должна одновременно обрабатывать данные из трех таблиц, тогда как в предыдущем примере эти таблицы обрабатываются поочередно. Естественно, что для их реализации тебуются различные ресурсы памяти и времени, однако этого невозможно ощутить при работе с ограниченным объемом данных в иллюстративной базе ПАНСИОН.

3. Особливості та характеристика СУБД Access

Microsoft Access є СУБД нового покоління, що входить до складу Microsoft Office і працює в середовищі Windows.

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

Під час роботи з названими об'єктами багато Майстрів MS Access допомагають користувачеві виконати роботу, не вдаючись до конструювання. Майстри дають змогу створювати одну з типових баз даних, нові форми, запити, звіти, аналізувати таблиці баз даних і т. ін. Має широкий спектр функцій, включаючи зв'язані запити, сортування по різних полях, зв'язок із зовнішніми таблицями і базами даних. Завдяки вбудованій мові VBA, в самому Access можна писати підпрограми, що працюють з базами даних. Основні компоненти MS Access:конструктор таблиць;конструктор екранних форм;конструктор SQL-запитів (мова SQL в MS Access не відповідає стандарту ANSI);конструктор звітів, що виводяться на друк.

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

Білет 28.

1. Створити тригер, вводу заздалегідь невірних даних у таблицю.

Нижче подано протокол створення тригера TrigKilnyt. Він має спрацьовувати під час вводу заздалегідь невірних даних у таблицю Gazpr. Передбачена стандартна обробка помилки з номером 20002 і видача діагностичного повідомлення про те, що число не може мати такого значення. Тригер спрацьовує під час спроби занесення в таблицю Gazpr значення поля Kilnyt, більшого за 15, і не спрацьовує в протилежному випадку. При спрацюванні триггера дані в таблицю не заносяться, бо він має ключове слово BEFORE. Звернемо увагу на змінну :new.Kilnyt, вона містить значення поля Kilnyt, яке буде введено і яке контролюється.

SQL> CREATE OR REPLACE TRIGGER TrigKilnyt

2 BEFORE INSERT ON Gazpr FOR EACH ROW

3 BEGIN

4 IF :new.Kilnyt>15 THEN

5 RAISE_APPLICATION_ERROR(-20002,'Число ниток не може бути >15');

6 END IF;

7 END;

8/

Trigger created.

SQL> insert into Kilnyt values(100);

2 /

insert into Kilnyt values(100)

*

ERROR at line 1:

ORA-20002: Число ниток не може бути >15

ORA-06512: at "SYSTEM.TRIGKILNYT", line 2

ORA-04088: error during execution of trigger 'SYSTEM.TRIGKILNYT'

SQL> insert into Gazpr (Kilnyt) values(3);

2 /

1 row created.

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

2. Використання одній той самої таблиці в зовнішнім і вкладеному підзапиту

Использование одной и той же таблицы во внешнем и вложенном подзапросе

Выдать номера поставщиков, которые поставляют хотя бы один продукт, поставляемый поставщиком 6.

	Результат:
SELECT DISTINCT ПС FROM Поставки WHERE ПР IN ( SELECT ПР FROM Поставки WHERE ПС = 6);	ПС 1 3 5 6 8

Отметим, что ссылка на Поставки во вложенном подзапросе означает не то же самое, что ссылка на Поставки во внешнем запросе. В действительности, два имени Поставки обозначают различные значения. Чтобы этот факт стал явным, полезно использовать псевдонимы, например, X и Y:

SELECT DISTINCT X.ПС

FROM Поставки X

WHERE X.ПР IN

( SELECT Y.ПР

FROM Поставки Y

WHERE Y.ПС = 6 );

Здесь X и Y – произвольные псевдонимы таблицы Поставки, определяемые во фразе FROM и используемые как явные уточнители во фразах SELECT и WHERE. Напомним, что псевдонимы определены лишь в пределах одного запроса.

3. Характеристик об’єктів бази даних Access

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

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

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

Модуль –– це програми на Microsoft Access Basic, які можуть бути прив’язані до окремих форм чи звітів і виконувати деякі дії при виникненні в них певних змін. У Access виділяється таке поняття, як подія, що визначає будь-яку зміну стану об’єктів.

Білет 29.

1. Тригер

Тригер – це процедура, яка автоматично запускається при виникненні подій, пов’язаних з виконанням операцій вставки, вилучення чи модифікації даних таблиці. Подія, яка керує запуском тригера, описується у вигляді логічних умов. Тобто кожній з цих операцій передує перевірка умов. Коли виникає подія, яка відповідає умовам тригера, сервер Огасlе автоматично запускає тригер.

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

Для того, щоб створити тригер, необхідно мати системний привілей CREATE TRIGGER. Для створення тригера в схемі, відмінної від поточної схеми користувача, потрібен системний привілей CREATE ANY TRIGGER.

Оператор визначення тригера має такий синтаксис:

CREATE [OR REPLACE ] TRIGGER [ім'я_схеми.] ім'я_тригера

BEFORE або AFTER

INSERT або DELETE або UPDATE [OF перелік_імен_полів]

[OR INSERT або DELETE або UPDATE [OF перелік_імен_полів]

ON [ім'я_схеми.]ім'я_таблиці або ім'я_представлення

[FOR EACH ROW] [WHEN умова]

тіло_програми_мовою_PL/SQL;

Ключове слово OR REPLACE означає безумовне заміщення старого тексту тригера. Якщо ключове слово OR REPLACE не зазначено і тригер уже визначений, то заміщення старого коду тригера не відбувається і повертається повідомлення про помилку.

Ключові слова BEFORE чи AFTER означають виконання коду тригера до або після операторів маніпулювання даними, які ініціювали запуск тригера. Наприклад, якщо тригер застосовується для перевірки повноважень користувача на право виконання операції, то, звичайно, потрібно запускати тригер до виконання операції (із ключовим словом BEFORE). Якщо тригер застосовують для аудиту, то розумно його запускати після виконання операції (із ключовим словом AFTER).

Слова INSERT, DELETE або UPDATE визначають конкретний оператор, який запускає тригер. Необов’язкове ключове слово OR приєднує додатковий оператор, який теж запускає тригер. В умові запуску тригера повинен бути обов’язково вказаний хоча б один оператор із трьох. Якщо перелік операторів, які запускають тригер, включає оператор UPDATE, то в умовах його спрацювання можна задавати конкретні назви полів.

Ключове слово ON задає ім’я таблиці або представлення, асоційовані з тригером.

Необов’язкове ключове слово FOR EACH ROW визначає тригер, як рядковий. Код тригера може бути асоційований або з операцією над таблицею в цілому, або з рядком, над яким виконується операція. Залежно від цього тригери поділяються на операторні й рядкові. Як правило, операторні тригери використовуються для перевірки правил, які оперують таблицею в цілому, а рядкові – для перевірки обмежень цілісності під час вставки рядків.

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

2. Вкладений підзапит оператором порівняння відмінним від IN

Вложенный подзапрос с оператором сравнения, отличным от IN

Выдать номера поставщиков, находящихся в том же городе, что и поставщик с номером 6.

	Результат:
SELECT ПС FROM Поставщики WHERE Город = ( SELECT Город FROM Поставщики WHERE ПС = 6 );	ПС 1 4 6

В подобных запросах можно использовать и другие операторы сравнения (<>, <= ,<, > = или >), однако, если вложенный подзапрос возвращает более одного значения и не используется оператор IN, будет возникать ошибка.

3. Таблиці в Access та правила їх побудови

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

Створення нової таблиці в новій базі даних

Натисніть кнопку Microsoft Office Access і виберіть пункт New.

У полі Ім’я файлу введіть ім’я файлу. Якщо потрібно змінити розташування, натисніть піктограму папки, щоб виконати огляд.

Натисніть кнопку Створити.

Відкривається нова база даних, створюється нова таблиця «Таблиця1», яка відкривається в поданні таблиці.

Створення нової таблиці в наявній базі даних

Натисніть кнопку Microsoft Office і виберіть пункт Open.

У діалоговому вікні Відкрити виберіть і відкрийте базу даних.

На вкладці Create, у групі Tables клацніть елемент Table.

Білет 30.

1. Обробка виняткових ситуацій

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

Таблиця 4.3. Перелік окремих виняткових ситуацій

Виняткова ситуація	Опис виняткової ситуації
LOGIN_DENIED	Неуспішне підключення до сервера (наприклад, введено помилковий пароль)
NOT_LOGGED_ON	Спроба виконати дію без підключення до сервера Oracle
INVALID_CURSOR	Посилання на неприпустимий курсор чи неприпустима операція з курсором
NO_DATA_FOUND	Не знайдені дані, які відповідають оператору SELECT INTO
OTHERS	Універсальна обробка помилок
TOO_MANY_ROWS	Оператор SELECT INTO повертає більше ніж один рядок
VALUE_ERROR	Арифметична помилка

Виняткова ситуація під час виконання програми може статися з об’єктивних причин або бути спровокованою програмістом з метою перевірки працездатності програми. При виникненні будь-якої виняткової ситуації відбувається автоматична передача керування в фрагмент блоку EXCEPTION програми. У цьому блоці можна запрограмувати як обробку конкретної помилки, так задіяти механізм універсальної обробки помилок за допомогою ключового слова OTHERS. Якщо блок EXCEPTION відсутній, то відбувається аварійний останов програми, що, як уже було вище сказано, недопустимо.

2. Функції підзапитів

Функции в подзапросе

Теперь, после знакомства с различными формулировками вложенных подзапросов и псевдонимами легче понять текст и алгоритм реализации запроса на получение тех поставщиков продуктов для Сырников, которые поставляют эти продукты за минимальную цену:

SELECT Продукт, Цена, Название, Статус

FROM Продукты, Состав, Блюда, Поставки, Поставщики

WHERE Продукты.ПР = Состав.ПР

AND Состав.БЛ = Блюда.БЛ

AND Поставки.ПР = Состав.ПР

AND Поставки.ПС = Поставщики.ПС

AND Блюдо = 'Сырники'

AND Цена = ( SELECT MIN(Цена)

FROM Поставки X

WHERE X.ПР = Поставки.ПР );

Естественно, что это коррелированный подзапрос: здесь сначала определяется минимальная цена продукта, входящего в состав Сырников, и только затем выясняется его поставщик.

3. Схема бази даних в СУБД Access її призначення та правила побудови

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

Між да­ними різних таблиць можна встановити зв'язок, вико­ристовуючи однакові значення їхніх полів. Функція зв'язку дає змогу користуватися даними кількох таб­лиць одночасно.

Поля, що застосовуються для встановлення зв'язку, повинні бути однакового типу і мати однакові значення.

Міжтабличні зв'язки можуть бути таких типів:

• відношення один до одного. При такому зв'язку кожному запису першої таблиці відповідає не більш як один запис другої. І, навпаки, один запис другої таблиці відповідає одному запису першої. Відношення між записами встановлюється при збі­гу значень ключових полів обох таблиць; • відношення один до багатьох — тип зв'язку, що використовується найчастіше. При такому зв'язку кожному запису першої таблиці можуть відпо­відати кілька записів другої, але один запис дру­гої таблиці не може мати зв'язок із більш як од­ним записом першої; • відношення багато до багатьох — тип зв'язку, що дає змогу встановити відношення між кілько­ма записами однієї таблиці та кількома записами другої. Для встановлення зв'язків в основному вікні БД треба активізувати вкладку Таблицы та команди Сер­вис, Схема данных або кнопку Схема данных. У ре­зультаті на екрані дисплея з'являється вікно, в якому зазначено всі встановлені за замовчуванням зв'язки. Для додання інших таблиць у схему даних потрібно при відкритому вікні Схема данных активізувати ко­манди Связи, Добавить таблицу головного меню або ви­користати команду Добавить таблицу контекстного ме­ню правої клавіші миші. В результаті на екрані дисп­лея з'являється вікно , в якому зазначено всі таблиці БД, з яких вибирають потрібну й активізують кнопку Добавить. Для зміни (або визначення) зв'язку між полями двох таблиць у вікні Схема данных активізують потрібне поле однієї таблиці, натискують на клавішу миші й, не відпускаючи її, «тягнуть» його в іншу таблицю. У вікні Изменение связей , що з'являється на екрані дисплея, активізують параметр Обеспечение целостно­сти данных і кнопку Объединение. Збереження ціліс­ності даних дає змогу уникнути записів-сиріт, тобто та­ких, які не мають зв'язку з основною таблицею.