МИНОБРНАУКИ РОССИИ федеральное государственное бюджетное образовательное учреждение высшего образования «Московский государственный технологический университет «СТАНКИН» (ФГБОУ ВО МГТУ «СТАНКИН») ИНСТИТУТ информационных технологий Кафедра информационных систем КУРСОВОЙ ПРОЕКТ по дисциплине «Управление данными» на тему: Студент: группа: Руководитель старший преподаватель Москва 2021 г. Оглавление ВВЕДЕНИЕ.............................................................................................................. 1 ГЛАВА 1. ОБЩИЕ СВЕДЕНИЯ О ТРИГГЕРАХ (ХРАНИМЫХ ПРОЦЕДУРАХ) ...................................................................................................... 4 1.1. История появления и развития триггеров в базах данных ....................... 4 1.2. Активные базы данных и активные правила ............................................. 7 ГЛАВА 2. ОПИСАНИЕ ИСПОЛЬЗОВАНИЯ ТРИГГЕРОВ В РАЗЛИЧНЫХ БАЗАХ ДАННЫХ ................................................................................................... 9 2.1. Триггеры в FoxPro......................................................................................... 9 2.2. Триггеры в Access ....................................................................................... 10 2.3 Триггеры в базах данных Paradox .............................................................. 12 2.4 Триггеры в dBase.......................................................................................... 16 ЗАКЛЮЧЕНИЕ ..................................................................................................... 28 СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ ................................................. 29 Приложение В. Код программы............................................................................42 2 ВВЕДЕНИЕ Идея активных механизмов, способных реагировать на заданное событие, реализованная в системах баз данных, берет свое начало в 1975 году, когда она была впервые реализована в системе System R компании IBM. Идея была довольно проста; важно было реализовать механизм, способный реагировать на различные типы событий, происходящих преимущественно внутри базы данных или в ее окружении. В теории баз данных такое поведение описывалось концепцией активных правил (Event-Condition-Action, ECA). Правила ECA интерпретируются следующим образом: если в системе происходит некоторое событие и выполняются некоторые условия, то заданное действие (или набор действий) автоматически выполняется как реакция системы на это событие. События, определенные в правилах ECA, могут различаться по своей сложности, начиная от простых (например, основные операторы манипулирования данными, такие как INSERT, UPDATE и/или DELETE) до сложных, которые могут быть определены с помощью простых событий или таких событий, как последовательность событий, отрицание и т.д. В системах баз данных правила ECA чаще всего реализуются через механизм триггеров. Триггер представляет собой объект базы данных, написанный на определенном процедурном языке, который автоматически выполняется при наступлении определенного события. Для упрощения процесса проектирования триггеров баз данных был представлен примерный подход. Этот подход использует Query-By-Example (QBE) в качестве графического интерфейса для создания триггеров (Lee et al., 2000b) и делает весь процесс проектирования триггеров более удобным для пользователя. В настоящее время современные системы баз данных должны решать важные задачи, такие как большой объем данных, целостность данных, масштабируемость, разнообразие источников данных, неструктурированные данные и т.д. Поэтому в некоторых областях применения традиционные реляционные базы данных были "заменены" их аналогами NoSQL, разработанными для лучшей адаптации к этим вызовам. Графовые базы данных - это категория баз данных в экосистеме NoSQL, предназначенных для эффективного хранения и управления высокосвязанными данными (например, данными социальных сетей). Триггеры как объекты базы данных были введены лишь недавно в очень немногих системах управления графовыми базами данных (GDBMS) (например, Neo4j и JanusGraph), и они по-прежнему требуют от пользователей разного уровня знаний синтаксиса языка запросов. Данное исследование мотивировано этой проблемой, и цель этой работы - сделать процесс проектирования триггеров в графовых базах данных проще, быстрее и понятнее для различных пользователей. ГЛАВА 1. ОБЩИЕ СВЕДЕНИЯ О ТРИГГЕРАХ (ХРАНИМЫХ ПРОЦЕДУРАХ) 1.1. История появления и развития триггеров в базах данных За прошедшие годы появился ряд исследовательских работ, в которых были представлены графовые механизмы спецификации правил и визуальные интерфейсы. В 90-е годы Даял, Уидом и Сери опубликовали несколько соответствующих научных работ и книг, связанных с активными системами баз данных. В этих публикациях авторы обсудили активные системы баз данных в целом и их возможные области применения (Widom and Ceri, 1996), использование декларативного подхода для спецификации модели выполнения активных правил (Ceri, 1992), семантику и реализацию выполнения правил (Dayal et al., 1994) и т.д. Nowak, Bak и Jedrzejek разработали графовый прототип реализации графического интерфейса для задания правил (Nowak et al., 2012). Помимо создания правил, интерфейс способен выполнять рассуждения о правилах для получения результатов. Процесс создания правила осуществляется путем указания тела (левой части, LHS) и головы (правой части, RHS) правила в виде двух отдельных графов, которые затем используются для построения утверждений "if LHS then RHS". Созданные правила способны проверять, существует ли в базе знаний данный факт с определенными значениями атрибутов, или существует ли связь между двумя существующими фактами. Первый тип условий поддерживается в текущем состоянии нашей реализации, в то время как проверка существования отношений будет частью нашей будущей работы. Авторы использовали механизм правил Jess для создания и обоснования правил, который требует от пользователей указывать условия правил, следуя синтаксису языка Jess, аналогичному RDF. В предлагаемом подходе пользователи могут задавать правила, просто следуя "естественной" семантике, т.е. им не нужно быть знакомыми с каким-либо синтаксисом. 4 Далее Грунер, Вебер и Эппл исследовали возможность использования систем на основе правил для промышленной автоматизации (Gruner et al., 2014). В частности, авторы использовали Neo4j GDBMS и Cypher для создания системы на основе правил, которая продемонстрирует преимущества использования графовых концепций для задания правил. В их подходе правило состоит из предпосылки (запроса Cypher) и заключения (серии операций, выполняемых по результатам оценки запроса), и хранится в формате XML в виде утверждения, написанного на описательном синтаксисе, аналогичном RuleML. Однако в этом подходе правила создаются либо вручную по запросу, либо системой, что снижает необходимость вовлечения пользователей в процесс спецификации правил. С другой стороны, наш графический интерфейс для спецификации правил обеспечивает большую гибкость для пользователей, и он еще больше вовлекает пользователя в процесс, делая его более простым. Кроме того, интересный механизм на основе правил был представлен в работе (Rapsevicius and Juska, 2014). Авторы разработали экспертную систему для детектора Compact Muon Solenoid (CMS) Cathode Strip Chambers на Большом адронном коллайдере (БАК). Одним из компонентов системы является механизм обработки сложных событий (CEP) на основе правил, который состоит из правил, написанных на синтаксисе SQL и образующих дерево решений. В контексте данной статьи правило представляет собой именованное вычислительное выражение, которое приводит к выводу, если выполняются условия выражения (Rapsevicius and Juska, 2014). Механизм CEP обеспечивает, чтобы для каждого входящего потока данных срабатывало соответствующее правило, которое оценивает условия и возвращает заключение на основе этой оценки. Затем вывод может быть настроен на выполнение определенного действия, например, отправку уведомлений, выполнение команд и т.д. Определения правил хранятся в таблицах реляционной базы данных, и авторы разработали интерфейс GUI для спецификации правил. Тем не менее, интерфейс требует, чтобы пользователи 5 задавали правила с помощью определенных операторов без явных указаний по синтаксису. По сравнению с предлагаемым нами подходом, графический интерфейс требует от пользователей определенных знаний синтаксиса, в то время как наш подход позволяет пользователям задавать правила полностью визуально, независимо от их уровня знаний и опыта. Идея активных графовых баз данных все еще находится на ранних стадиях своего развития. Наиболее значительный вклад в эту область был сделан Канканамге и др., которые разработали Graphflow, активную базу данных графов (Kankanamge et al., 2017). Система построена на Neo4j и использует Cypher++, декларативное расширение Cypher, которое поддерживает триггеры как правила "подграф-условие-действие". Cypher++ поддерживает спецификацию правил, которые срабатывают при выполнении запросов MATCH, CREATE, DELETE, UPDATE и SHORTEST PATH, и такие правила могут привести к созданию новых версий основного графа свойств или записи подграфа в локальный файл. Синтаксис Cypher++ эквивалентен языку запросов Cypher. Более того, Cypher++ представляет собой одну из нескольких реализаций проекта openCypher (Neo4j, 2018), целью которого является постоянное совершенствование языка запросов Cypher и превращение его в стандартизированный язык запросов к графам. В работе (DSG, 2017) авторы представили обзор архитектуры системы Graphflow, показанной на рисунке 1. Система использует два процессора запросов в зависимости от типа события, которое вызвало правило. Процессор одноразовых запросов отвечает за обработку операторов Cypher (MATCH, UPDATE, INSERT и т.д.) и выполняет обновление базового хранилища графов, в то время как процессор непрерывных запросов хранит и оценивает правила действий с подграфами для выполнения заданных действий. В нашем случае все поддерживаемые в настоящее время правила обрабатываются одним процессором запросов. 6 1.2. Активные базы данных и активные правила Активные базы данных представляют собой решения баз данных, которые полагаются на активные (ECA) правила для того, чтобы автоматически реагировать на определенные события. В контексте активных правил событие представляет собой некоторое изменение состояния, которое требует вмешательства. Простейшими типами событий являются: - Заявления, такие как INSERT, UPDATE и/или DELETE, - Временные события (абсолютные, относительные и периодические), - События, определяемые пользователем, - События транзакции (начало/конец транзакции), - События метода (в объектно-ориентированных базах данных) и т.д. Простые события могут быть объединены (E1 и E2, E4 или E3, и т.д.), в результате чего образуется сложное событие. К другим типам сложных событий относятся: - отрицание - событие не произошло в течение заданного интервала времени t, - повторение - повторение чего-либо несколько раз в течение заданного интервала времени t, - последовательность - несколько событий произошли в заранее определенной последовательности и т.д. Чтобы смоделировать активную систему, необходимо позаботиться об объектах, событиях и транзакциях, которые преобразуют состояния базы данных, оперируя объектами (Kangsabanik et al., 1997). Хорошая активная система управления базами данных (ADBMS) обычно относится к системе, которая поддерживает больше и больше различных типов событий. Процесс выполнения правил ECA состоит из нескольких этапов. После обнаружения события оно запускает одно или несколько правил. Условия для сработавших правил должны быть оценены. Мы говорим, что правило сработало, но это не является гарантией того, что оно будет выполнено, поскольку необходимо оценить компонент условия правила. На основе оценки 7 условия выполняются действия правил (если оценка условия была успешной). Выполняемые действия могут вызвать другие (новые) правила. Кроме того, в (Herbst, 1996) было введено понятие правил ECAA как расширение правил ECA. В модели правил ECAA, если условие для произошедшего события успешно оценено, выполняется первое действие, в противном случае выполняется альтернативное действие. 8 ГЛАВА 2. ОПИСАНИЕ ИСПОЛЬЗОВАНИЯ ТРИГГЕРОВ В РАЗЛИЧНЫХ БАЗАХ ДАННЫХ 2.1. Триггеры в FoxPro Но за все это время им так и не удалось обойти правила, триггеры и код ссылочной целостности, встроенные в их базы данных. Таким образом, в этом случае не возникает сомнений, что данный набор функциональных возможностей Visual FoxPro можно проигнорировать. В любом случае, даже если мы не использовали эти инструменты, мы всегда обеспечивали правила и ссылочную структуру. Рассмотрим следующие проблемы, которые, возможно, имеют репрезентативные для тех, с кем вы столкнулись. - Отслеживание последней строки в счете-фактуре. - При вводе в счет-фактуру позиции для товарного продукта, который только возвращается, но не продаётся (например, пустой ацетиленовой баллон). - Ввод заказа на покупку с указанием способа доставки "UPS", когда только «MotorCarrier» и «AirFreight» являются действительными способами доставки данного продавца. - Внесение изменений в номер счета-фактуры. - В случае отсутствия истории о клиенте в исторических данных, связанных с этим клиентом, удаление. - Ввод количества из 2 товаров, продаваемых по $5 каждый, и правильное представление расширений как $10. Было бы неплохо, если бы мы могли просто записать счет-фактуру и затем выполнить команду DELETE для удаления счета-фактуры и внесения в журнал изменений. Однако, в реальности мы также должны удалить эти 112 позиций. Это пример функции ссылочной целостности Мы убираем возможность появления "бесхозных", то есть не принадлежащих к номенклатуре, записей в таблице позиций. 9 На складе не хватало одного из трех устройств, и покупатель решил заказать три гаджета по $5. Однако в связи с нехваткой товара второй из трех устройств был отложен, и отправлен только один. В случае если пользователь введет дату рождения 15 декабря 1928 в записи пациента в программе управления педиатрической медпрактики и получит код для проверки возраста пациента, мы можем проверить возраст пациента. В результате расчетов получается возраст больше 18 лет (или иной критерий, установленный практикой для своей аудитории), мы можем сообщить пользователю сообщение о том, что это значения не соответствует, и потребовать изменить его до внесения изменений в запись. Здесь это функция ограничения домена. И здесь вопрос заключается не в том, нужно или нет нашим приложениям справляться с такими ситуациями, а в том, как встроенные в базу данных правила, триггеры и код ссыльной целостности, которые мы встраиваем туда, могут быть частью вашей стратегии для разрешения этих задач. 2.2. Триггеры в Access Триггер - это блок PL/SQL, который хранится в базе данных и (если он находится во включенном состоянии) ("срабатывает") в ответ на заданное событие. Триггер имеет следующую структуру: 10 автоматически выполняется Имя_триггера должно быть уникальным для триггеров в схеме. Триггер может иметь то же имя, что и другой тип объекта в схеме (например, таблица). Если триггер находится в активированном состоянии, то триггерное_событие заставляет базу данных выполнить триггерное_действие, если триггерное_ограничение равно TRUE или опущено. Триггер_событие связан либо с таблицей, либо с представлением, либо со схемой, либо с базой данных, и является одним из этих событий: - оператор DML (описан в разделе "Об операторах языка манипулирования данными (DML)") - оператор DDL (описан в разделе "Об операторах языка определения данных (DDL)") - операция с базой данных (SERVERERROR, LOGON, LOGOFF, STARTUP или SHUTDOWN). Если триггер срабатывающее_событие находится не в заставляет отключенном состоянии, базу выполнять данных срабатывающее_действие, даже если ограничение_триггера равно TRUE или опущено. По умолчанию триггер создается во включенном состоянии. Вы можете отключить включенный триггер и включить отключенный триггер. В отличие от подпрограммы, триггер не может быть вызван напрямую. Триггер вызывается только по событию запуска, которое может быть вызвано любым пользователем или приложением. Вы можете не знать, что триггер выполняется, если он не вызывает ошибку, которая не обрабатывается должным образом. Простой триггер может сработать ровно в одной из этих временных точек: 1. Перед выполнением триггерного события (триггер BEFORE на уровне утверждения) 2. После выполнения триггерного события (триггер AFTER на уровне утверждений) 11 3. Перед каждой строкой, на которую влияет событие (триггер BEFORE на уровне строки) 4. После каждой строки, на которую влияет событие (триггер AFTER на уровне строки). Составной триггер может срабатывать в нескольких временных точках. Информацию о составных триггерах смотрите в Oracle Database PL/SQL Language Reference. Триггер INSTEAD OF определен на представлении, и его триггерное событие - это DML-оператор. Вместо выполнения оператора DML, Oracle Database выполняет триггер INSTEAD OF. Для получения дополнительной информации см. раздел "Создание триггера INSTEAD OF". Системный триггер определяется на схеме или базе данных. Триггер, определенный для схемы, срабатывает для каждого события, связанного с владельцем схемы (текущим пользователем). Триггер, определенный для базы данных, срабатывает для каждого события, связанного со всеми пользователями. Одно из применений триггеров - обеспечение соблюдения бизнесправил, которые применяются ко всем клиентским приложениям. Например, предположим, что данные, добавляемые в таблицу EMPLOYEES, должны иметь определенный формат, и что многие клиентские приложения могут добавлять данные в эту таблицу. Триггер на таблице может обеспечить надлежащий формат всех данных, добавляемых в нее. Поскольку триггер выполняется каждый раз, когда любой клиент добавляет данные в таблицу, ни один клиент не может обойти правила, а код, обеспечивающий выполнение правил, может храниться и поддерживаться только в триггере, а не в каждом клиентском приложении. 2.3 Триггеры в базах данных Paradox 12 Представленная в составе редакционной редакции Professional и Education пакета Microsoft WordPerfect Office, СУбД Paradox является удобной реляционной базой данных, которая предоставляет множество способов хранения и извлечения данных Кроме того, из сохраненных в СУБД Paradox сведений можно создавать качественные формы для заполнения, таблицы и отчеты В этом случае также можно размещать данные в файлах различного формата. Например, для этого используется формат Quattro Pro(QPW), Microsoft Excel(XLS) или Lotus 1-2-4 и dBASE(DBF), решать задачи учета коммунальных услуг, составлять архивы и работать с ними Парадокс предоставляет широкий выбор способов хранения, отображения и показа данных. Компоненты, используемые для хранения и представления данных, называются объектами (objects). В системе Paradox есть следующие объекты: таблица (tab), форма (form), отчет (report), запрос (qr) и библиотека программ (library). По данным Paradox, они размещены в таблицах. Из рядов (row) и колонн (column), в таблице. Для каждого ряда имеется вся информация о конкретном предмете (Item), который он включает в себя, и называется запись (record), а каждая колонка – одну категорию данных, называемую полем(field). Привилегии, которыми обладает идентификатор авторизации оператора, должны включать хотя бы одну из следующих полномочий: - привилегия ALTER для таблицы, для которой определен триггер BEFORE или AFTER - привилегия CONTROL на представлении, на котором определен триггер INSTEAD OF - владелец представления, на котором определен триггер INSTEAD OF - привилегия ALTERIN на схеме таблицы или представления, на которой определен триггер - полномочия DBADM и одно из: 13 - полномочия IMPLICIT_SCHEMA на базе данных, если неявное или явное имя схемы триггера не существует - привилегия CREATEIN на схеме, если имя схемы триггера ссылается на существующую схему - полномочия DBADM Если авторизационный идентификатор оператора не имеет полномочий DATAACCESS, привилегии (за исключением групповых привилегий), которыми обладает авторизационный идентификатор оператора, должны включать все следующие полномочия, пока существует триггер: На таблице, на которой определен триггер, если указаны какие-либо переменные перехода или таблицы: - Привилегия SELECT на таблице, на которой определен триггер, если указаны какие-либо переменные перехода или таблицы. - Привилегия CONTROL на таблице, на которой определен триггер, если указаны любые переменные или таблицы перехода - Право доступа к данным На любую таблицу или представление, на которые ссылается условие срабатывания: - привилегия SELECT на любой таблице или представлении, на которые ссылается условие срабатывания. - привилегия CONTROL на любой таблице или представлении, на которые ссылается условие срабатывания. - полномочия DATAACCESS Необходимые привилегии для вызова указанных сработавших операторов SQL. Групповые привилегии не учитываются для любой таблицы или представления, указанных в операторе CREATE TRIGGER. Чтобы заменить существующий триггер, идентификатор полномочий оператора должен быть владельцем существующего триггера (SQLSTATE 42501). 14 Если указана опция SECURED, привилегии, которыми обладает идентификатор авторизации оператора, должны дополнительно включать полномочия SECADM или CREATE_SECURE_OBJECT (SQLSTATE 42501). Триггер-событие Триггер-действие Триггер-процедура 15 2.4 Триггеры в dBase DBase - это микрокомпьютерная система управления базами данных (СУБД), работающая на платформе Windows. Уникальность DBase заключается в том, что она позволяет без проблем создавать широкий спектр приложений, включая промежуточные приложения, веб-приложения, размещенные на серверах Windows, и клиентские приложения Windows. DBase предназначен для работы с реляционными базами данных. Это универсальный язык третьего поколения с непроцедурными возможностями и очень хорошим отладчиком. Историю DBase можно проследить с 1978 года, когда она была создана Уэйном Рэтлиффом и первоначально называлась "Вулкан". В 1980-х годах 16 компания Ashton-Tate приобрела Vulcan и продавала его как DBase II, который считается первой версией DBase. DBase II была совместима с 16-битной управляющей программой для микрокомпьютеров. Последующие версии, такие как DBase III, III+ и DBase IV, использовались на 16-битных платформах DOS. Последующие версии, такие как Visual DBase 5.5 и Visual DBase 5.7, работали на 16-битных платформах Windows. Visual DBase 7.0, Visual DBase 7.5, dB2K и DBase Plus - более поздние версии, работающие на 32-битных платформах Windows. По состоянию на 2011 год, DBase Plus является наиболее широко используемой версией. Хранение данных в формате DBase широко распространено и поддерживается многочисленными системами управления базами данных. DBase использует процедурные функции и команды, похожие на язык BASIC. В ней используются простые команды для работы с данными, такие как USE и GO TOP для перехода по записям, STR() и SUBSTR() для работы со строками, REPLACE и STORE для работы со значениями полей. Также используются и другие команды, такие как STORE, DO, APPEND и MODIFY. Основной формат файлов DBase - .dbf. DBase имеет множество выдающихся особенностей, которые способствуют его выдающемуся положению среди систем и инструментов управления базами данных, таких как: - компилятор Just in time (JIT), который преобразует исходный язык в машинный. - компоновщик для создания приложений DBase (файлы .exe) - программа установки движка времени выполнения для веб-серверов и машин, на которых должны выполняться приложения времени выполнения DBase - препроцессоры для чтения исходного файла программы и создания препроцессированных файлов в качестве выходных данных, которые поступают в компилятор - интегрированная среда разработки с командным окном и навигатором 17 - двусторонние средства проектирования графического интерфейса пользователя (GUI), которые позволяют переключаться между инструментом проектирования GUI и редактором кода. - редактор исходного кода, который позволяет вручную редактировать и вводить коды. DBase также имеет множество визуальных классов и классов баз данных. К визуальным классам относятся: PushButton Изображение Сетка Полоса прокрутки ActiveX Отчет ReportViewer SpinBox ComboBox ListBox Текст TextLabel Форма SubForm Блокнот Контейнер Поле ввода Радиокнопка Классы базы данных включают: RowSet Поле StoredProc Датамодуль 18 Сессия База данных Запрос Триггеры могут быть определены как объект базы данных, который выполняет определенные действия для автоматического выполнения всякий раз, если пользователи пытаются выполнить команды изменения данных (UPDATE, DELETE и DESCRIPTION) для указанных таблиц. По этим таблицам триггеры привязываются к конкретным таблицам. В MSDN говорится о том, что триггеры могут быть определены как специальный вид хранимых процедур. Для того чтобы описать типы триггеров нам необходимо сначала понять магические таблицы, на которые они ссылаются и использовать их для повторного использования. Две таблицы, которые в народе называют Magic tables были вставлены и удалены в dBase. Не физические таблицы, а внутренние таблицы dbase, обычно используемые с триггером для извлечения вставленных, удалённых или обновленных строк. Таблицы с информацией по вставленным строкам, удаленным строчкам и обновленным строчкам. Разница между хранимой процедурой и триггером 1. В случае необходимости мы можем выполнить хранимую процедуру всякий же раз, когда хотим, с помощью команды exec, однако триггер можно выполнить только всякий случай, когда событие (вставка, удаление и обновление) запускается в таблице таблицы, для которой определен триггер 2. Мы можем вызвать хранимую процедуру с другой хранимой процедуры, но нам не удается напрямую вызвать другой триггер внутри другого триггера. Мы можем достичь только вложенности триггера, при которой действие (вставка) или удаление (обновление) должны инициировать выполнение другого триггера из той же или другой таблицы. 19 3. Однако нам известно, что хранимые процедуры могут быть запланированы на выполнение в заранее определенное время, но мы никак не можем спланировать триггер 4. Как правило хранимая процедура принимает входные параметр как входной параметр, но мы не можем передавать параметры из исходного триггера в хранимую процедуру 5. В случае возврата триггера в исходное состояние, хранимые процедуры возвращают значение, но триггер не может вернуть значение. 6. В нашем случае мы можем использовать команды Print внутри хранимой процедуры для отладки, но нам не дано использовать команду print внутри триггера 7. Можно использовать операторы транзакции, например начало транзакции или фиксация трансакции в хранилище процедуры, но мы не можем использовать эти операторы во внутренней процедуре. 8. Мы можем вызвать хранимую процедуру с внешнего интерфейса (.asp файлы,.aspx-файл,.ascx-файл и т. Д.), но мы не можем вызвать триггер оттуда. Два типа триггеров, приведенных ниже: 1. Трехгнездная система AFTER. 2. Триггеры INSTEAD OF При этом мы будем рассматривать три таблицы, в которых имена customer, customer Transactions и Custmail представлены следующим образом: Триггеры AFTER выполняются после выполнения действия модификации данных (INSERT, UPDATE или DELETE) для соответствующих таблиц. Таблица может иметь несколько триггеров, определенных на ней. 20 Предположим, у нас есть требование, что всякий раз, когда добавляется новый клиент, автоматически его соответствующее значение должно быть вставлено в таблицу Custmail, чтобы можно было отправить электронное письмо клиенту и уполномоченному лицу в Банке. Чтобы решить эту проблему, мы можем создать триггер After Insert для таблицы customer, синтаксис которой приведен ниже: Триггер сработает всякий раз, как новый клиент добавляется в банк и соответствующий текст вписывается в табличку Custmail. Служба доставки почты будет использовать записи из таблицы custmail в качестве отправной точки для отправки почты клиенту Но допустим и другое условие, что в случае удаления клиента из системы он получает письмо с уведомлением об удалении. В таблице custmail каждый раз, когда клиент удаляется из основной таблицы клиентов, нужно вставить запись клиента в таблицу custmail. Для этого мы будем использовать триггера AFTER для удаления. При этом в данном примере мы будем использовать таблицу Deleted 21 Допустим, у нас также есть требование, что всякий раз, когда клиент зачисляет средства на свою учетную запись или обновляет свое имя (имя и фамилию) ему должно быть отправлено письмо, в котором содержится эта информация. При использовании триггера After для обновления можно использовать триггер After для обновления Здесь мы будем использовать таблицу Inserted. Здесь мы использовали функцию Update для числа столбцов, custFname и custEname, которые запускают триггер обновления при изменении этих столбов. 22 Триггер INSTEAD OF используется для того, чтобы выполнить другое действие вместо действия, вызывающего срабатывание триггера. Набор из трех триггеров INSTEAD OF Они могут определяться в случае вставки, удаления или обновления. А если мы возьмем для примера такую ситуацию: у нас есть условие, что в одном транзакции пользователь не сможет получить более 15000 долларов. В нашем случае мы можем использовать триггер вместо ограничения. Для снятия со счета более 15000 долларов за один день необходимо получить сообщение об ошибке «Cannot Set more 15000 on your account». В этом примере мы используем волшебную таблицу Inserted. 23 В триггерах DDL такое же поведение,как и в триггерах DML, за исключением того факта, что они запускаются в ответна событие типа DDL, такое например команда Alter, команда Dropи команды Create. По сути дела, это означает, что он будет срабатывать при попытке изменения схемы базы данных. Именно поэтому эти триггерные триггеры не создаются для конкретной таблички, но они применимы ко всем табличкам в базе данных. Триггеры DDL могут быть запущенны только после выполнения команд, которые их запустили. Их можно использовать для следующих целей: 1) Чтобы избежать любых изменений в схеме базы данных. 2) Мы хотим хранить все события, которые изменяют схему базы данных. Например, предположим, что мы собираемся создать таблицу command_log, где будут храниться все пользовательские команды по созданию таблиц (Create table), и команды, которые изменяют таблицы Кроме того мы не хотим, чтобы какая-нибудь таблица была удалена. Если какая-либо команда удаления таблицы запушена, триггер DDL отработает команду с сообщением «Вы не имеете права удалять таблицу». Приводим скрипт для таблицы command_log. 24 Чтобы сохранить команду create table в таблице command_logs нам сначала нужно создать триггер для запуска команды Create table. В этот триггер включается каждый раз при запуске любой команды для создания таблицы, и вставляет ее в таблицу command_log, выводя сообщение «Таблица была успешно создана» Примечание. В данном случае Eventdata — это функция, которая возвращает информацию о событии сервера или базы данных. Вернет в исходное значение тип XML. А если же нам необходимо сохранять команду Alter_table в таблице command_log? Тогда нам необходимо создать триггер для команды Alternate_table. Такой же триггер срабатывает всякий раз при запуске любой команды из базы данных, выводящей на экран сообщение «Таблица изменена». При создании таблицы в базе данных мы должны создать триггер для команды dpkgdrop table и выполнить команду drop table. Этот триггер не позволит удалить любой таблице, а также выведет сообщение «Табличка не может быть удалена». 25 В Sql Server триггер называется вложенным, когда один триггер инициирует другой триггер, находящийся в той же или другой таблице. Например, предположим, что существует два триггера t1, определенных в таблице tbl1, и один триггер t2, определенный во таблице tbl2, если действие этих триггерных триггеров инициирует триггер t1, то они называются вложенными. При этом в SQL Server триггеров может быть вложено до 32 уровней. В случае, если в процессе действия вложенных триггеров происходит бесконечный цикл, то после 32 уровня триггера он завершается. Триггеры выполняют внутри транзакции, поэтому сбой на любом уровне внутри вложенного триггера может отменить всю транзакцию и вызвать общий откат. Также мы можем приостановить выполнение вложенных триггеров с использованием следующей команды SQL: С помощью рекурсивных триггеров в SQL Server можно инициировать триггер повторно. Первый тип – это когда в SQL Server имеется два типа рекурсии. 1. Это прямая рекурсия. 2. Промежуточная рекурсия В прямой рекурсии действие триггеров вновь инициирует сам триггер, и это приводит к рекурсивному вызовутю триггера. На самом деле, в косвенной рекурсии действие над тремяггерактивирует другой триггер-активист (триггер), и выполнение этого триггера опять вызывает исходный триггер, который был инициирован ранее, и это происходит рекурсивно И тот и другой триггер могут быть в одной и той же таблицы или созданы в разных таблицах. Внимание: рекурсивный тригнер возможен только при установке опции рекурсивного триггера. 26 Следующую команду SQL следует добавить к команде установки опции рекурсивного запуска Минусы триггеров. 1) Это сложно поддерживать, поскольку существует вероятность того, что новый разработчик может забыть о триггере, установленном в базе данных, и задать вопрос, как данные вставляются, удаляют или обновляются автоматически. 2) Это связано с тем, что их сложно отлаживать, так как их сложно просматривать по сравнению с хранящимися процедурами, представлениями, функциям и т. д. 3) Однако чрезмерное их использование может привести к замедлению производительности приложения из-за того что, если мы определили триггеры в некоторых таблицах, они будут автоматически выполнятся каждый раз при вставке, удалении или обновлении в таблицах (на основе определения трехггера), и это делает обработку крайне медленной. 4) Если в триггере написано сложный код, то это может замедлить работу приложений. 5) При создании таблиц с высокой частотой операций, например массовой вставки, стоимость создания триггеров может быть выше для таблиц, в которых высока вероятность проведения операции DML (вставка, удаление и обновление). 27 ЗАКЛЮЧЕНИЕ Триггеры как активные механизмы все еще сталкиваются с низким уровнем поддержки в графовых базах данных с ограниченными возможностями. Существующие исследовательские подходы к построению графовых движков правил требуют от пользователей с разным уровнем знаний и опыта знакомства с синтаксисом языка запросов, что может потребовать от пользователей определенного периода обучения. 28 СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ 1. Сери, С. (1992). Декларативный подход к активным базам данных. В [1992] Восьмая международная конференция по инженерии данных, страницы 452-456. IEEE. 2. Dayal, U., Hanson, E., and Widom, J. (1994). Активные системы баз данных. Технический отчет, Стэнфордская лаборатория InfoLab. 3. Де Марци, М. (2015). Триггеры в neo4j. Доступно на https://maxdemarzi.com/2015/03/25/triggersin-neo4j/. 4. ДСГ, У. (2017). Graphflow. Доступно по адресу http:// graphflow.io/. 5. Грунер, С., Вебер, П. и Эппле, У. (2014). Проектирование на основе правил с использованием декларативных запросов к графовой базе данных. В 2014 году 12-я Международная конференция IEEE по промышленной информатике (INDIN), стр. 274-279. IEEE. 6. Хербст, Х. (1996). Бизнес-правила в системном анализе: мета-модель и система репозитория. Информационные системы, 21(2):147-166. 7. JanusGraph (2017). Журнал транзакций. Доступно на сайте https://docs.janusgraph.org/latest/log.html. 8. Кангсабаник, П., Молл, Р., и Маджумдар, А. К. (1997). Техника моделирования приложений в активных объектно-ориентированных системах управления базами данных. Информационные науки, 102(1-4):67-103. 9. Kankanamge, C., Sahu, S., Mhedbhi, A., Chen, J., and Salihoglu, S. (2017). Graphflow: Активная база данных графов. В материалах Международной конференции ACM 2017 года по управлению данными, страницы 1695-1698. ACM. 10. Lee, D., Mao, W., Chiu, H., and Chu, W. W. (2000a). Tbe: Графический интерфейс для написания триггерных правил в активных базах данных. In Advances in Visual Information Management, pages 367-386. Springer. 29 11. Ли, Д., Мао, В., Чиу, Х. и Чу, В. В. (2005). Проектирование триггеров с помощью триггеров на примерах. Знания и информационные системы, 7(1):110-134. 12. Lee, D., Mao, W., and Chu, W. W. (2000b). Tbe: Triggerby-example. Международная конференция по концептуальному моделированию, страницы 112-125. Springer. 13. Neo4j, I. (2018). opencypher. Доступно 15 мая 2019 года на сайте https://www.opencypher.org/about. 14. Новак, М., Бак, Дж. и Еджейк, К. (2012). Редактор правил на основе графа. В RuleML (2). 15. Рапсевичус, В. и Юска, Е. (2014). Экспертная система для детектора lhc cms cathode strip chambers (csc). Ядерные приборы и методы в физических исследованиях Раздел A: Ускорители, спектрометры, детекторы и сопутствующее оборудование, 738:126-131. 16. Уидом, Дж. и Сери, С. (1996). Активные системы баз данных: Триггеры и правила для расширенной обработки баз данных. Морган Кауфманн. 30
