Общая характеристика реляционной модели данных

Автор работы: Пользователь скрыл имя, 28 Февраля 2013 в 14:56, лекция

Описание работы

Основы реляционной модели данных были впервые изложены в статье Е.Кодда в 1970 г. Эта работа послужила стимулом для большого количества статей и книг, в которых реля-ционная модель получила дальнейшее развитие. Наиболее распространенная трактовка реляционной модели данных принадлежит К.Дейту. Согласно Дейту, реляционная модель состоит из трех частей:
• Структурной части
• Целостной части
• Манипуляционной части

Файлы: 1 файл

Базовые понятия реляционной модели данных.docx

— 169.99 Кб (Скачать файл)

 стандартных средств  защиты базы  данных в  ORACLE.  Например, с       

 помощью триггера можно  запретить обновление данных  о запрлате  в       

 таблице EMP  во время  выходных и  праздничных дней,  а также  в       

 нерабочие часы. 

 

 

        Лучше  всего  для  комплексной  проверки полномочий использовать       

 триггер предложения  BEFORE.  Это дает следующие преимущества:  

 

 

            *  Контроль   осуществляется   до   исполнения   предложения              

 триггера,  так  что  не  придется  отменять   выполненную              

 работу, если предложение  будет подвергнуто откату. 

 

 

            *  Контроль  осуществляется  лишь  один  раз для предложения              

 триггера,  а  не  по  каждой  строке,  затрагиваемой этим              

 предложением. 

 

Пример 

 

 

        Следующий пример показывает  триггер, который задействует  защиту.       

 Комментарии внутри  кода объясняют логику этого  триггера. 

 

 

        CREATE TRIGGER emp_permit_changes       

BEFORE INSERT OR DELETE OR UPDATE ON emp       

DECLARE         

dummy INTEGER;         

not_on_weekends EXCEPTION;         

not_on_holidays EXCEPTION;         

non_working_hours EXCEPTION;       

BEGIN         

/* проверить на выходные */         

IF (TO_CHAR(sysdate, 'DY') = 'SAT' OR            

(TO_CHAR(sysdate, 'DY') = 'SUN' OR THEN           

RAISE not_on_weekends; 

         END IF;         

/* проверить на праздники */          

SELECT COUNT(*) INTO dummy FROM company_holidays            

WHERE TRUNC(day) = TRUNC(sysdate);           

 /* TRUNC отсекает компоненту времени из даты */         

 IF dummy > 0 THEN      

      RAISE not_on_holidays;         

 END IF;         

/* Проверить на рабочие  часы (8am .. 6pm) */         

IF (TO_CHAR(sysdate, 'HH24') < 8 OR            

(TO_CHAR(sysdate, 'HH24') > 18 THEN           

RAISE non_working_hours;         

END IF;    

    EXCEPTION         

WHEN not_on_weekends THEN           

raise_application_error (-20324,             

'May not change employee table during the weekend');          

WHEN not_on_holidays THEN           

raise_application_error (-20325,             

'May not change employee table during a holiday');          

WHEN non_working_hours THEN           

raise_application_error (-20326,             

'May not change employee table during non-working hours');       

 END; 

 

 

 

Триггеры и прозрачная регистрация событий

----------------------------------------- 

 

 

        Триггеры весьма полезны,  когда вы хотите организовать  прозрачное       

 выполнение  обновлений  базы  данных,  связанных с определенными       

 событиями. 

 

 

        Например,  триггер  REORDER  на  странице 8-14 показывает пример       

 триггера,  который  осуществляет  повторный  заказ товара, когда       

 имеют место определенные  условия (а именно, количество  товара  в       

 наличии,  PART_ON_HANDS,  меньше,  чем  предписанное   значение,       

REORDER_POINT). 

 

Триггеры и вычисляемые  значения столбцов

---------------------------------------- 

 

 

        Триггеры  могут   автоматически  вычислять   значения  столбцов,       

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

 или  UPDATE.   Такой  тип  триггера  полезен  для принудительной       

 установки значений  определенных столбцов, зависящих  от  значений       

 других столбцов в  той же самой строке.  Для такого типа операций       

 необходимы триггеры  строк BEFORE, ибо: 

 

 

            *  Зависимые значения должны  быть вычислены перед  тем, как              

 произойдет вставка  или обновление, так, чтобы предложение               

 триггера могло использовать  вычисленные значения. 

 

 

            *  Триггер должен  возбуждаться для  каждой строки,  которую              

 затрагивает возбуждающее  триггер предложение  INSERT или              

UPDATE. 

 

Пример 

 

 

        Следующий пример показывает, как можно использовать триггер  для       

 вычисления значений  новых столбцов в таблице при  каждой  вставке       

 новой строки  или обновлении  существующей строки.   Комментарии       

 внутри кода объясняют  логику этого триггера. 

 

 

        BEFORE INSERT OR UPDATE OF ename ON emp 

 

 

        /* Перед появлением нового значения поля ENAME, вычислить          

 значения полей UPPERNAME и SOUNDEXNAME. Следует запретить          

 пользователям обновлять  эти поля непосредственно. */ 

 

 

        FOR EACH ROW       

BEGIN           

:new.uppername := UPPER(:new.ename);           

:new.soundexname := SOUNDEX(:new.ename);       

 END; 

 

 

 

Синхронная поддержка  копий таблиц с помощью триггеров

-----------------------------------------------------  

 

 

        Триггеры   можно   использовать   для   того,   чтобы обеспечить       

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

 распределенной базы  данных.  За  примером такого  типа триггера        

 обратитесь к главе  12, "Управление снимками".

 


Информация о работе Общая характеристика реляционной модели данных