Система поддержки принятия решений или СППР (Decision Support Systems, DSS) — это компьютерная система, которая путем сбора и анализа большого количества информации может влиять на процесс принятия решений организационного плана в бизнесе и предпринимательстве. Интерактивные системы позволяют руководителям получить полезную информацию из первоисточников, проанализировать ее, а также выявить существующие бизнес-модели для решения определенных задач. С помощью СППР можно проследить за всеми доступными информационными активами, получить сравнительные значения объемов продаж, спрогнозировать доход организации при гипотетическом внедрении новой технологии, а также рассмотреть все возможные альтернативные решения.
По взаимодействию с пользователем выделяют три вида СППР:
пассивные помогают в процессе принятия решений, но не могут выдвинуть конкретного предложения;
активные непосредственно участвуют в разработке правильного решения;
кооперативные предполагают взаимодействие СППР с пользователем. Выдвинутое системой предложение пользователь может доработать, усовершенствовать, а затем отправить обратно в систему для проверки. После этого предложение вновь представляется пользователю, и так до тех пор, пока он не одобрит решение.
По способу поддержки различают:
модельно-ориентированные СППР, используют в работе доступ к статистическим, финансовым или иным моделям;
СППР, основанные на коммуникациях, поддерживают работу двух и более пользователей, занимающихся общей задачей;
СППР, ориентированные на данные, имеют доступ к временным рядам организации. Они используют в работе не только внутренние, но и внешние данные;
СППР, ориентированные на документы, манипулируют неструктурированной информацией, заключенной в различных электронных форматах;
СППР, ориентированные на знания, предоставляют специализированные решения проблем, основанные на фактах.
По сфере использования выделяют общесистемные и настольные СППР. Общесистемные работают с большими СХД и применяются многими пользователями. Настольные являются небольшими системами и подходят для управления с персонального компьютера одного пользователя.
Выделяют четыре основных компонента:
информационные хранилища данных;
средства и методы извлечения, обработки и загрузки данных (ETL);
многомерная база данных и средства анализа OLAP;
средства Data Mining.
СППР позволяет облегчить работу руководителям предприятий и повысить ее эффективность. Они значительно ускоряют решение проблем в бизнесе. СППР способствуют налаживанию межличностного контакта. На их основе можно проводить обучение и подготовку кадров. Данные информационные системы позволяют повысить контроль над деятельностью организации. Наличие четко функционирующей СППР дает большие преимущества по сравнению с конкурирующими структурами. Благодаря предложениям, выдвигаемым СППР, открываются новые подходы к решению повседневных и нестандартных задач.
На уровне логической модели возможны также связи типа М : М (многие ко многим), которые используются тогда, когда между атрибутами сущностей существуют многозначные зависимости. Связь такого типа каждому кортежу одной сущности ставит в соответствие любое (в том числе нулевое) число кортежей другой сущности и наоборот.
Переход от логической модели данных к физической заключается в том, что сущности преобразуются в таблицы, атрибуты и кортежи становятся соответственно столбцами и строками таблиц, домены отображаются в типы данных, принятые в конкретной СУБД. Таблицы, как и сущности, снабжаются первичными и внешними ключами и связываются между собой с помощью связей типа 1:1 и 1:М. Связи типа М:М при переходе к физической модели преобразуются в пары связей типа 1:М и связующие таблицы.
Если логическая модель представлена в виде 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.
Механизмом, обеспечивающим хранение результата выборки на сервере и предоставляющим пользователю возможность доступа к любой строке выборки по ее номеру, являются курсоры. Курсор представляет собой своего рода окно, накладываемое на результат выборки. Пользователь может работать только с одной строкой в каждый момент, но перемещая окно, он способен получить доступ к любой строке выборки.
Виды курсовров:
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 данного триггера производится только в том случае, если произошло событие срабатывания триггера.