Операции прямого и обратного проектирования
Если логическая модель представлена в виде ER-диаграммы, то переход к физической модели значительно упрощается. В этом случае с помощью CASE-средства, например ERwin, можно выбрать нужную СУБД и автоматически создать соответствующую физическую модель данных. Затем на ее основе ERwin может сгенерировать системный каталог базы данных или соответствующий SQL-скрипт (описание базы данных на языке SQL). Этот процесс называется прямым проектированием. Тем самым достигается масштабируемость – создав один раз логическую модель данных, можно генерировать физические модели данных под любую СУБД, которую поддерживает ERwin. С другой стороны, ERwin способен по содержимому системного каталога базы данных или SQL-скрипту воссоздать физическую и логическую модели данных. Этот процесс называется обратным проектированием. На основе логической модели, полученной в процессе обратного проектирования, можно сгенерировать физическую модель и системный каталог базы данных для другой СУБД. Тем самым решается задача по переносу структуры базы данных с одной СУБД на другую, например с SQL Server на Oracle или с Access на Sybase и т.д.
Прямое проектирование:
1. Создать пупстую бд MYDB.mdb, закрыть Access
2. Tools►Forward Engineer/Schema Generation (или соответствующей кнопки на панели инструментов) откройте окно Forward Engineer Schema Generation и нажмите кнопку Generate. В появившемся окне Access Connection задайте имя пользователя (User Name) равным Admin, а также с помощью кнопки Browse (первой сверху) задайте полное имя созданной базы данных XXX.mdb. Далее нажмите кнопку Connect и выполните процесс прямого проектирования (Forward Engineer) с наполнением файла базы данных MYDB.mdb метаданными согласно созданной физической модели данных. После завершения процесса прямого проектирования с помощью команды меню Database►Database Connection откройте окно Access Connection и разорвите соединение с базой данных MYDB.mdb путем нажатия кнопки Disconnect.
3. Открыть Access, запустить MYDB.mdb
Обратное проектирование:
1.Закройте Access, после чего в ERwin закройте текущую модель данных с помощью команды меню File►Close.
2. В ERwin с помощью команды меню Tools►Reverse Engineer запустите мастер выполнения процесса обратного проектирования. На его странице Reverse Engineer – Select Template задайте тип новой модели – Логическая/Физическая, целевую базу данных – Access. На следующей странице Reverse Engineer – Set Options в древовидной структуре Items to Reverse Engineer найдите объект View и отключите его (сбросьте флажок) вместе со всеми подчиненными ему элементами. В появившемся окне Access Connection задайте имя пользователя (User Name) равным Admin, а также с помощью кнопки Browse (первой сверху) задайте полное имя созданной ранее в Access базы данных MYDB.mdb. Далее нажмите кнопку Connect и выполните процесс обратного проектирования (Reverse Engineer), в результате чего будет создана модель данных, соответствующая системному каталогу базы данных MYDB.mdb. После завершения процесса обратного проектирования с помощью команды меню Database►Database Connection откройте окно Access Connection и разорвите соединение с базой данных путем нажатия кнопки Disconnect.
57. SQL Server : курсоры и триггеры, их виды, процесс использования.
Механизмом, обеспечивающим хранение результата выборки на сервере и предоставляющим пользователю возможность доступа к любой строке выборки по ее номеру, являются курсоры. Курсор представляет собой своего рода окно, накладываемое на результат выборки. Пользователь может работать только с одной строкой в каждый момент, но перемещая окно, он способен получить доступ к любой строке выборки.
Виды курсовров:
1 Курсоры Transact-SQL. Создание курсоров этого типа и работа с ними ведется средствами команд Transact-SQL. Эти курсоры создаются на сервере. Интенсивное применение курсоров может потребовать использования доп. Оперативной памяти для хранения данных курсоров. Курсоры Transact-SQL могут создаваться и работать в транзакциях, хранимых процедурах и триггерах.
2. Курсоры API сервера. Этот тип курсоров используется приложениями при работе с различными механизмами доступа и данными (ODBC, OLE DB, DB Library и т.д.) Используя API, клиент выполняет команду создание курсора. API сервера принимают запрос и создает на сервере курсор Transact-SQL. Работа с этим курсором выполняется средствами API, реализующего все базовые операции с курсорами и некоторые дополнительные операции.
3. Курсоры клиента. Этот тип курсоров создается непосредственно на клиенте. Сервер обрабатывает отправленный клиентом запрос и возвращает ему результирующий набор. Клиент получает весь результирующий и уже сам организует нужные механизмы доступа данных. Это удобно при работе с небольшим набором данных, т.к. позволяет повысить производительность за счет уменьшения количества обращений к сети, требующих определенного времени на обработку.
Последовательные. Этот тип курсоров разрешает только последовательное считывание строк, начиная с первой строки и заканчивая последней.
Прокручиваемые. В отличии от последовательных курсоров, эти позволяют обращаться к произвольной строке результирующего набора.
Триггеры
Триггеры являются одной из разновидностей хранимых процедур. Их исполнение происходит при выполнении для таблицы какого-либо оператора языка манипулирования данными (DML). Триггеры используются для проверки целостности данных, а также для отката транзакций.
Триггер – это откомпилированная SQL-процедура, исполнение которой обусловлено наступлением определенных событий внутри реляционной базы данных. Применениетриггеров большей частью весьма удобно для пользователей базы данных. И все же их использование часто связано с дополнительными затратами ресурсов на операции ввода/вывода. В том случае, когда тех же результатов (с гораздо меньшими непроизводительными затратами ресурсов) можно добиться с помощью хранимых процедур или прикладных программ, применение триггеров нецелесообразно.
Триггеры – особый инструмент SQL-сервера, используемый для поддержания целостности данных в базе данных. С помощью ограничений целостности, правил и значений по умолчанию не всегда можно добиться нужного уровня функциональности. Часто требуется реализовать сложные алгоритмы проверки данных, гарантирующие их достоверность и реальность. Кроме того, иногда необходимо отслеживать изменения значений таблицы, чтобы нужным образом изменить связанные данные. Триггерыможно рассматривать как своего рода фильтры, вступающие в действие после выполнения всех операций в соответствии с правилами, стандартными значениями и т.д.
Триггер представляет собой специальный тип хранимых процедур, запускаемых сервером автоматически при попытке изменения данных в таблицах, с которыми триггерысвязаны. Каждый триггер привязывается к конкретной таблице. Все производимые им модификации данных рассматриваются как одна транзакция. В случае обнаружения ошибки или нарушения целостности данных происходит откат этой транзакции. Тем самым внесение изменений запрещается. Отменяются также все изменения, уже сделанные триггером.
Создает триггер только владелец базы данных. Это ограничение позволяет избежать случайного изменения структуры таблиц, способов связи с ними других объектов и т.п.
Триггер представляет собой весьма полезное и в то же время опасное средство. Так, при неправильной логике его работы можно легко уничтожить целую базу данных, поэтому триггеры необходимо очень тщательно отлаживать.
В отличие от обычной подпрограммы, триггер выполняется неявно в каждом случае возникновения триггерного события, к тому же он не имеет аргументов. Приведение его в действие иногда называют запуском триггера. С помощью триггеров достигаются следующие цели:
· проверка корректности введенных данных и выполнение сложных ограничений целостности данных, которые трудно, если вообще возможно, поддерживать с помощью ограничений целостности, установленных для таблицы;
· выдача предупреждений, напоминающих о необходимости выполнения некоторых действий при обновлении таблицы, реализованном определенным образом;
· накопление аудиторской информации посредством фиксации сведений о внесенных изменениях и тех лицах, которые их выполнили;
· поддержка репликации.
Триггеры BEFORE и AFTER
Если в определении триггера указано ключевое слово BEFORE, то триггер будет срабатывать непосредственно до выполнения операции обновления базовой таблицы соответствующим инициирующим оператором SQL. При задании ключевого слова AFTER триггер будет вызываться немедленно после выполнения инициирующего оператора.
Триггеры INSERT, UPDATE и DELETE
Выбор одного из этих ключевых слов при определении триггера указывает на природу события, которое должно приводить к срабатыванию триггера. При задании ключевого слова INSERT к срабатыванию триггера может привести только выполнение операции вставки строк в предметную таблицу. Если указываются ключевые слова UPDATE или DELETE, то число возможных событий, приводящих к срабатыванию триггера, возрастает. Кроме явных операций модификации строк предметной таблицы или удаления из нее строк к срабатыванию триггера могут привести ссылочные действия.
Заметим, что в стандарте SQL:1999 отсутствует возможность определения триггеров, для которых событием было бы выполнение операции выборки из предметной таблицы. Разработчики стандарта сочли, что область применения триггеров такого рода чересчур узка (трудно придумать какое-либо применение, кроме как для журнализации и аудита).
Триггеры ROW и STATEMENT
Если в определении триггера присутствует конструкция FOR EACH ROW, то триггер будет вызываться для каждой строки предметной таблицы, обновляемой инициирующим SQL-оператором. Если же задано FOR EACH STATEMENT (или явная спецификация FOR EACH отсутствует), то триггер сработает один раз на всем протяжении процесса выполнения инициирующего SQL-оператора.
Раздел WHEN
Включение в определение триггера раздела WHEN с соответствующим условным выражением позволяет более точно специфицировать условие применимости триггера. Вычисление условного выражения производится над строками предметной таблицы, и триггер срабатывает только в том случае, когда значением условного выражения является true. Понятно, что виды и интерпретация логических выражений, допускаемых в разделе WHEN, различаются у триггеров с FOR EACH ROW и у триггеров с FOR EACH STATEMENT. В первом случае условное выражение вычисляется для одной строки, которая должна быть обновлена инициирующим SQL-оператором. Во втором – условное выражение вычисляется для всей предметной таблицы целиком и, по всей видимости, должно базироваться на «кванторных» предикатах. Следует также понимать, что вычисление условия раздела WHEN данного триггера производится только в том случае, если произошло событие срабатывания триггера.