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

Предикаты используются для  задания способов и режимов использования  записей, отбираемых на основе условий в инструкции SQL. Такими предикатами являются:

ALL... - отбирает все записи, соответствующие  условиям, заданным в инструкции SQL, используется по умолчанию;

DISTINCT... - исключает записи, которые  содержат повторяющиеся значения  в выбранных полях;

DISTINCTROW... - опускает данные, основанные  на целиком повторяющихся записях,  а не на отдельных повторяющихся  полях;

ТОРп... - возвращает п записей, находящихся  в начале или в конце диапазона, описанного с помощью предложения ORDER BY;

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

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

• СУБД для конечных пользователей;

• СУБД для программистов (профессионалов).

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

В профессиональных СУБД язык базы данных (SQL) дополняется элементами, присущими процедурным языкам программирования - описателями и средствами работы с различ-ного типа переменными, операторами, функциями, процедурами и т. д. В результате формируется специализированный на работу с данными декларативно-процедурный язык высокого уровня, который встроен в СУБД (точнее надстроен над ядром СУБД). Такие языки называют «включающими». На основе включающего языка разрабатываются полностью автономные прикладные информационные системы, реализующие более простой и понятный для специалистов в определенной предметной области (скажем, в бухгалтерии) интерфейс работы с информацией.

С учетом этапов в развитии программных средств СУБД такие  языки получили название языков четвертого поколения - 4GL (Forth Generation Language). Языки 4GL могут быть непосредственно встроены в сами СУБД, а могут существовать в виде отдельных сред программирования. В последнем случае в таких  средах разрабатываются прикладные части информационных систем, реализующие только интерфейс и высокоуровневые функции по обработке данных. За низкоуровневым, как говорят, «сервисом» к данным такие прикладные системы обращаются к SQL-серверам, являющимися отдельными специализированными разновидностями СУБД. «Общение» между прикладными системами и SQL-серверами происходит соответственно на языке SQL.

Свои языки 4GL имеют  практически все развитые профессиональные СУБД-Orac/e, SyBase, Informix, Ingres, DB2, отечественная  СУБД ЛИНТЕР. Распространенными отдельными средами программирования для создания информационных систем в настоящее время являются системы Visual Basic фирмы Microsoft и Delphi фирмы Borland Intemational. Кроме того, уже упоминавшиеся CASE-средства автоматизированного проектирования - PowerBuilder фирмы PowerSoft, Oracle Designer фирмы Oracle, SQLWindows фирмы Gupta и др., также, как правило, имеют свои встроенные языки 4GL.

В заключение следует отметить, что в последнее время наметилась тенденция встраивания развитых языков уровня 4GL и в СУБД для конечных пользователей - razgovorodele.ru. В качестве примера можно привести СУБД Access фирмы Microsoft, имеющей один из наиболее развитых интерфейсов по созданию и работе с базами данных для конечных пользователей, и в то же время оснащенной встроенным языком уровня 4GL - VBA (Visual Basic for Application), являющегося диалектом языка Visual Basic.

ИСПОЛЬЗОВАНИЕ ТРИГГЕРОВ  БАЗЫ ДАННЫХ        

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

 хранятся в  базе данных  и неявно  исполняются ("возбуждаются"),        

 когда модифицируется  ассоциированная  таблица.  Темы этой  главы        

 включают обсуждение  следующих вопросов:            

*  создание, отладка, изменение, удаление, включение и              

 выключение триггеров             

*  примеры применения траггеров         

 Информация в этой  главе  применима лишь к тем  системам, которые        

 используют  ORACLE  с  процедурной  опцией.  Если вы используете       

Trusted ORACLE,  обратитесь к  документу Trusted  ORACLE7 Server       

Administrator's   Guide   для   дополнительной   информации   об       

 определении и применении  триггеров в этом окружении.  

Проектирование триггеров         

 Используйте следующие  рекомендации при проектировании  триггеров:            

*  Используйте триггеры для  того, чтобы гарантировать,  что              

 при  выполнении  определенной  операции  будут  выполнены              

 связанные с ней  действия.            

*  Используйте триггеры базы  данных только для  глобальных,              

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

 для соответствующего  предложения (предложения  триггера),               

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

 базы данных выдает  это предложение.            

*  Не  определяйте  триггеров,  дублирующих возможности, уже              

 встроенные в ORACLE.  Например, не определяйте  триггеров              

 для ввода в  действие правил целостности  данных, которые              

 могут  быть  легко  реализованы посредством декларативных              

 ограничений целостности.  

[!]         *  Будьте  внимательны,   чтобы  не   создавать  рекурсивных              

 триггеров.  Например, создание такого триггера AFTER  для              

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

 предложение   UPDATE   по   таблице   EMP,   приведет   к              

 рекурсивному   возбуждению   этого   триггера   вплоть до              

 переполнения числа  триггеров.        

 Так   как   триггер   должен   быть   откомпилирован,   когда он       

 возбуждается впервые  (а также при последующих возбуждениях, если       

 он был вытеснен  из своей разделяемой области  контекста), хорошей       

 идеей является ограничение  размера триггеров (приблизительно  60       

 строками).   Компиляция  триггеров  меньшего  размера  не окажет       

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

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

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

 хранится  в  откомпилированной  форме).   В  этом случае триггер       

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

 затрат времени на  компиляцию.  

Создание триггеров        

 Триггеры  создаются  с  помощью  команды  CREATE  TRIGGER.   Эту 

       команду  можно  использовать  в  любом интерактивном инструменте       

(таком  как  SQL*Plus  или  SQL*DBA);  при использовании в таких       

 инструментах,  одиночная  наклонная  черта  ("/"),  вводимая как        

 последняя строка, обозначает  конец предложения CREATE TRIGGER.       

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

 таблицей EMP:        

CREATE TRIGGER dummy       

BEFORE DELETE OR INSERT OR UPDATE ON emp       

FOR EACH ROW       

WHEN (new.empno > 0)       

 DECLARE           

/* переменные, константы,  курсоры и т.п. */       

 BEGIN           

/* блок PL/SQL */       

END;        

 Предложение  CREATE   собъется,  если   в  блоке   PL/SQL  будут       

 обнаружены ошибки.        

 Последующие  секции  будут   использовать  этот  пример,   чтобы       

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

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

CREATE   TRIGGER   обратитесь   к   секции   "Примеры применения       

 триггеров" на странице 8-16. 

Предварительные условия

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

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

CATPROC.SQL под  учетным именем  SYS. Этот  скрипт автоматически       

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

 или  используются  этой  опцией.   Местоположение  этого   файла       

 зависит от операционной  системы; обратитесь к вашему  руководству       

 по инсталляции. 

Именование триггеров

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

 Имена триггеров должны  быть  уникальными среди всех триггеров  в       

 той же схеме.   Имена триггеров не  обязаны быть уникальными  по       

 отношению к  другим объектам  схемы (таких  как таблицы, обзоры,       

 процедуры); например, таблица  и триггер могут иметь одно  и то же       

 имя (хотя, во избежание  путаницы, это не рекомендуется).  

Опции BEFORE/AFTER

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

 Либо  опция  BEFORE,  либо  опция  AFTER  должна  быть указана в       

 предложении CREATE TRIGGER,  чтобы точно специфицировать,  когда       

 должно  исполняться  тело  триггера  по  отношению  к исполнению       

 предложения триггера.  В предложении CREATE TRIGGER опция BEFORE       

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

 обозначающим  предложение  триггера.   Например,  триггер DUMMY,       

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

BEFORE.        

 Триггеры строк  AFTER несколько  более эффективны,  чем триггеры  

      строк BEFORE.  При  триггерах строк BEFORE,  затрагиваемые блоки       

 данных  должны  быть  считаны  (логической,  а  не   физической,       

 операцией  чтения)  один  раз  для  триггера  и еще один раз для       

 предложения триггера.  Альтернативно, при триггерах строк AFTER,        

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

 сразу для предложения  триггера и для самого триггера.  

Предложение триггера

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

 Предложение триггера  специфицирует:            

*  Тип предложения  SQL, которое  возбуждает тело  триггера.              

 Допустимыми  возможностями  являются  DELETE,  INSERT   и              

UPDATE.  В спецификацию  предложения триггера могут  быть              

 включены одна, две  или все три этих опции.            

*  Таблицу, ассоциированную  с триггером.   Заметьте, что  в              

 предложении  триггера  может  быть  специфицирована ровно              

 одна таблица (но  не обзор).        

 Например, предложениями,  возбуждающими триггер  DUMMY, являются       

 любые  предложения  DELETE,  INSERT  или  UPDATE по таблице EMP.       

 Любое   из   следующих   предложений   возбудит   триггер DUMMY,       

 показанный в предыдущем  примере:        

 DELETE FROM emp;        

 INSERT INTO emp VALUES ( . . . );        

INSERT INTO emp SELECT . . . FROM . . . ;        

UPDATE emp SET . . . ;    

 Список столбцов для UPDATE         

 Если  предложение  триггера  специфицирует  UPDATE,  то  в   эту