Использование between

С помощью BETWEEN ... AND ... (находится в интервале от ... до ...) можно отобрать строки, в которых значение какого-либо столбца находятся в заданном диапазоне.

Например, выдать перечень продуктов, в которых значение содержания белка находится в диапазоне от 10 до 50:

Можно задать и NOT BETWEEN (не принадлежит диапазону между), например:

BETWEEN особенно удобен при работе с данными, задаваемыми интервалами, начало и конец которых расположен в разных столбцах.

Для примера воспользуемся таблицей "минимальных окладов" (табл. 2.1), величина которых непосредственно связана со студенческой стипендией. В этой таблице для текущего значения минимального оклада установлена запредельная дата окончания 9 сентября 9999 года.

Таблица 2.1 Минимальные оклады

Миноклад	Начало	Конец
2250	01-01-1993	31-03-1993
4275	01-04-1993	30-06-1993
7740	01-07-1993	30-11-1993
14620	01-12-1993	30-06-1994
20500	01-07-1994	09-09-9999

Если, например, потребовалось узнать, какие изменения минимальных окладов производились в 1993/94 учебном году, то можно выдать запрос

SELECT Начало, Миноклад

FROM Миноклады

WHERE Начало BETWEEN '1-9-1993' AND '31-8-1994'

и получить результат:

Начало	Миноклад
01-12-1993	14620
01-07-1994	20500

Отметим, что при формировании запросов значения дат следует заключать в апострофы, чтобы СУБД не путала их с выражениями и не пыталась вычитать из 31 значение 8, а затем 1994.

Для выявления всех значений минимальных окладов, которые существовали в 1993/94 учебном году, можно сформировать запрос

SELECT *

FROM Миноклады

WHERE Начало BETWEEN '1-9-1993' AND '31-8-1994'

OR Конец BETWEEN '1-9-1993' AND '31-8-1994'

Миноклад	Начало	Конец
7740	01/07/1993	30/11/1993
14620	01/12/1993	30/06/1994
20500	01/07/1994	09/09/9999

Наконец, для получения минимального оклада на 15-5-1994:

	Результат:
SELECT Миноклад FROM Миноклады WHERE '15-05-1994' BETWEEN Начало AND Конец

3. Правила побудови реляційної моделі даних.

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

Власне, при відображенні на реляційну модель пере­проектовувати інформаційні об'єкти, якщо не було припущено помилок на етапі інфологічного проектування, практично не по­трібно. Тобто інформаційні об'єкти інфологічної моделі представ­ляються в табличному вигляді і стають реляційними відношен­нями. Необхідно лише перевірити виконання таких умов:1. Усі атрибути відношень мають бути атомарними, тобто не­подільними.2. Відношення не повинно мати дублюючих рядків і стовп­чиків.3. Усі атрибути у відношенні повинні мати унікальні імена. Наступним кроком відображення є визначення зв'язків' між таблицями.

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

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

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

Білет 17

1. Реєстрація подій.

Реєстрація подій, пов’язаних з доступом до об’єктів, відбується за допомогою команди:

AUDIT перелік_дій_для_аудиту

ON [схема.]об’єкт або DEFAULT

[WHENEVER [NOT] SUCCESSFUL]

Параметр перелік_дій_для_аудиту залежить від типу об’єкта, окремі його значення приведені нижче в таблиці 4.4.

Таблиця 4.4 Значення параметра перелік_дій_для_аудиту.

Ім’я дії	Допустимі об’єкти Oracle
SELECT	Таблиця, представлення, знімок, послідовність
INSERT, UPDATE, DELETE	Таблиця, представлення, знімок
EXECUTE	Процедура, функція, пакет
GRANT, AUDIT, RENAME	Таблиця, представлення, знімок, функція, послідовність, процедура, пакет

Розглянемо приклад аудиту таблиці Gazpr користувача system. За внесенням записів у цю таблицю слідкує тригер TrigKilnyt, який не дозволяє вводити дані, якщо число ниток газопроводу більші за 15. Наприкінці прикладу міститься команда звернення до представлення user_audit_trail.

SQL> connect system/manager

Connected.

SQL> audit insert on Gazpr

2 whenever not successful;

Audit succeeded.

SQL> insert into Gazpr values(100);

insert into Gazpr 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(5);

1 row created.

SQL> noaudit insert on Gazpr;

Noaudit succeeded.

SQL> select username, action, timestamp, ses_actions, returncode

2 from user_audit_trail;

USERNAME ACTION TIMESTAMP SES_ACTIONS RETURNCODE

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

SYSTEM 103 03-NOV-09 ----B---- 0

Переглянувши результати аудиту і проаналізувавши їх, знаходимо одну зафіксовану операцію, яку забезпечив параметр команди аудиту WHENEVER NOT SUCCESSFUL. Успішна операція внесення запису в таблицю Gazpr не зафіксована.

Командою SELECT були виведені такі поля представлення user_audit_trail:

username – ім’я користувача;

action – числовий код дії користувача (в даному випадку – код команди INSERT);

timestamp – дата створення реєстраційного запису;

ses_actions – рядок символів, успішне або неуспішне виконання команди;

returncode – код операції (у випадку помилки цей код дорівнює 0).

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