КИС / KIS

Security при передаче данных из базы и обратно. Встроенные возможности шифрования защищают наиболее ценную информацию даже от привилегированных пользователей, которые могут превысить свои полномочия, а также от злонамеренных пользователей, пытающихся прочесть файлы данных из операционной системы. Тонкий аудит отслеживает действия базы данных, включая операторы, выполняемые пользователями, и возвращаемую информацию. Это предостерегает пользователей от превышения своих полномочий, так как они знают, что все их действия отслеживаются. Широкие возможности аудита также помогают выявить бреши в безопасности. Например, при обращении к секретным областям базы данных обработчик событий может отправить предупреждение администратору. Если действия пользователя будут признаны опасными, сеанс работы с базой данных будет немедленно прерван.

Механизмы безопасности должны учитывать размеры Интернета: поддерживать работу с большим количеством пользователей и быть простыми в управлении. Oracle предлагает несколько решений для построения Интернет-приложений, обеспечивающих безопасность доступа пользователей: улучшенную аутентификацию прокси базы данных, поддержку инфраструктуры открытых ключей (Public Key Infrastructure, PKI) и новые средства однократной сквозной регистрации для доступа к серверам приложений. Совокупность этих функций позволяет предприятиям точно идентифицировать пользователей на всех уровнях сети. Работа ПО промежуточного уровня больше не ограничивается простым подключением Web-пользователя к базе данных. Средства аутентификации на уровне прокси формируют множество масштабируемых малых сессий для работы с базой данных, беря на себя нагрузку по проверке подлинности, что обеспечивает тонкое управление доступом и подробный аудит.

Однократная аутентификация обеспечивается компонентом Login Server для служб порталов на сервере приложений. В итоге для доступа ко всем Web-приложениям предприятия пользователю потребуется лишь одна учетная запись. Для управления полномочиями пользователей системным администраторам достаточно поддерживать один центральный каталог LDAP (Интернет-каталог Oracle). Централизация сведений о полномочиях пользователей не только повышает безопасность, но и снижает затраты на администрирование. База данных Oracle предлагает механизмы совместного использования аппаратного и программного обеспечения несколькими группами пользователей. Раздельное хранение данных каждой группы обеспечивают Virtual Private Database и Oracle

Label Security.

140

Кроме того, СУБД Oracle могут работать под управлением любой операционной системы: как Windows Server, так и Unix и др. Это делает ее более гибкой и адаптируемой к любой информационной системе. Столь развитые средства обеспечения надежности и безопасности также способствуют ее распространенности. По статистике, около 53 % информационных систем предприятий базируются на Oracle.

3)СУБД компании IBM

Кнастоящему времени разработаны линейки продуктов DB2 и

Informix, включающая как собственно СУБД, так и средства разработки и анализа данных (DB2 Universal Database DB2 Personal Edition, DB2 Enterprise 9 и др., а также Informix Dynamic Server, Informix Dynamic Server Express, Informix Extended Parallel Server и др.).

Универсальный сервер баз данных DB2 Universal Database – это масштабируемая обьектно-реляционная система управления базами данных с интегрированной поддержкой мультимедиа и Web, работающая на системах от персональных компьютеров и серверов на процессорах Intel до Unix, от однопроцессорных систем до симметричных многопроцессорных систем (SMP) и систем с массовым параллелизмом

(MPP), на хостах AS/400 и мейнфреймах. DB2 Universal Database

объединяет в себе высокую производительность систем обработки транзакций в режиме on-line, объектно-реляционные расширения, усовершенствованные средства оптимизации с возможностями параллельной обработки и поддержкой очень больших баз данных. DB2 Universal Database также имеет новые встроенные средства для облегчения переноса на свою базу приложений, разработанных на других системах управления базами данных, таких как Oracle, Microsoft, Sybase и Informix. Помимо этого, DB2 Universal Database включает в себя дополнительные средства поддержки систем аналитической обработки в реальном времени (OLAP) и систем поддержки принятия решений, множество простых в использовании расширений (DB2 extenders). DB2 Universal Database доступна на абсолютном большинстве ключевых платформ, что дает заказчикам ту гибкость, которая им необходима.

При огромном разнообразии СУБД вполне естественны споры (которые возникли с момента появления СУБД и, по-видимому, не утихнут никогда) о том, какая СУБД лучше.

Однозначного ответа на этот вопрос не существует. Каждая СУБД имеет свои границы применимости, у каждой из них существуют свои достоинства и недостатки, свое соотношение цена-качество. Выбор прежде всего зависит от класса задач, которые нужно решать с использованием СУБД, от тех критериев, которые для соответствующего

141

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

6.6. Критерии выбора СУБД при создании информационных систем

Выбор СУБД представляет собой сложную многопараметрическую задачу. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям предприятия, при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, самой системы, разработку необходимого программного обеспечения на ее основе, а также обучение персонала. Кроме того, необходимо убедиться, что новая СУБД способна принести предприятию реальные выгоды.

По результатам анализа, например [23, 25, 26], попытаемся сформулировать требования или критерии при выборе СУБД. Очевидно, наиболее простой подход при выборе СУБД основан на оценке того, в какой мере существующие системы удовлетворяют основным требованиям создаваемого проекта информационной системы. Более сложным и дорогостоящим вариантом является создание испытательного проекта на основе нескольких СУБД и последующий выбор наиболее подходящего из кандидатов. Но и в этом случае необходимо ограничивать круг возможных систем, опираясь на некие критерии отбора. Вообще говоря, перечень требований к СУБД, используемых при анализе той или иной информационной системы, может изменяться в зависимости от поставленных целей. Тем не менее, можно выделить несколько групп критериев:

Моделирование данных

Особенности архитектуры и функциональные возможности

Контроль работы системы

Особенности разработки приложений

Производительность

Надежность

Требования к рабочей среде

Смешанные критерии

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

142

Моделирование данных

Используемая модель данных.

Триггеры и хранимые процедуры. Триггер – программа базы данных, вызываемая всякий раз при вставке, изменении или удалении строки таблицы. Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти изменения будут приняты. Хранимая процедура – программа, которая хранится на сервере и может вызываться клиентом. Поскольку хранимые процедуры выполняются непосредственно на сервере базы данных, обеспечивается более высокое быстродействие, нежели при выполнении тех же операций средствами клиента БД. В различных программных продуктах для реализации триггеров и хранимых процедур используются различные инструменты.

Средства поиска. Некоторые современные системы имеют встроенные дополнительные средства контекстного поиска.

Предусмотренные типы данных. Здесь следует учесть два фактически независимых критерия: базовые или основные типы данных, заложенные в систему, и наличие возможности расширения типов. В то время как отклонения базовых наборов типов данных у современных систем от некоего стандартного обычно невелики, механизмы расширения типов данных в системах того или иного производителя существенно различаются.

Реализация языка запросов. Все современные системы совместимы со стандартным языком доступа к данным SQL-92, однако многие из них реализуют те или иные расширения данного стандарта.

Особенности архитектуры и функциональные возможности

Мобильность. Мобильность – это независимость системы от среды, в которой она работает. Средой в данном случае является как аппаратура, так и программное обеспечение (операционная система).

Масштабируемость. При выборе СУБД необходимо учитывать, сможет ли данная система соответствовать росту информационной системы, причем рост может проявляться в увеличении числа пользователей, объема хранимых данных и объема обрабатываемой информации.

Распределенность. Основной причиной применения информационных систем на основе баз данных является стремление объединить взгляды на всю информацию организации. Самый простой и надежный подход – централизация хранения и

143

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

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

Контроль работы системы

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

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

Особенности разработки приложений

Многие производители СУБД выпускают также средства разработки приложений для своих систем. Как правило, эти средства позволяют наилучшим образом реализовать все возможности сервера, поэтому при анализе СУБД стоит рассмотреть также и возможности средств разработки приложений.

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

Многоязыковая поддержка. Поддержка большого количества национальных языков расширяет область применения системы и приложений, построенных на ее основе.

Возможности разработки Web-приложений. При разработке различных приложений зачастую возникает необходимость использовать возможности среды Internet. Средства разработки некоторых производителей имеют большой набор инструментов для построения приложений под Web.

Поддерживаемые языки программирования. Широкий спектр используемых языков программирования повышает доступность системы для разработчиков, а также может существенно повлиять

144

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

Производительность

Рейтинг TPC (Transactions Per Cent). Для тестирования производительности применяются различные средства, и существует множество тестовых рейтингов. Одним из самых популярных и объективных является TPC-анализ производительности систем. Фактически TPC анализ рассматривает композицию СУБД и аппаратуры, на которой эта СУБД работает. Показатель TPC – это отношение количества запросов, обрабатываемых за некий промежуток времени, к стоимости всей системы.

Возможности параллельной архитектуры. Для обеспечения параллельной обработки данных существует как минимум два подхода: распараллеливание обработки последовательности запросов на несколько процессоров, либо использование нескольких компьютеров-клиентов, работающих с одной БД, которые объединяют в так называемый параллельный сервер.

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

Надежность

Понятие надежности системы имеет много смыслов – это и сохранность информации, не зависящая от любых сбоев, и безотказность работы системы в любых условиях, и обеспечение защиты данных от несанкционированного доступа.

Восстановление после сбоев. При возникновении программных или аппаратных сбоев целостность, да и работоспособность всей системы может быть нарушена. От того, как эффективно спланирован механизм восстановления после сбоев, зависит жизнеспособность системы.

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

145

удалении таблиц. Существует множество механизмов резервирования данных (хранение одной или более копий всей базы данных, хранение копии ее части, копирование логической структуры и т.д.). Зачастую в систему закладывается возможность использования нескольких таких механизмов.

Откат изменений. При выполнении транзакции применяется простое правило: либо транзакция выполняется полностью, либо не выполняется вообще. Это означает, что в случае сбоев все результаты не доведенных до конца транзакций должны быть аннулированы. Механизм отката может иметь различные быстродействие и эффективность.

Многоуровневая система защиты. Информационная система организации почти всегда включает в себя секретную информацию, поэтому для предотвращения несанкционированного доступа используется служба идентификации пользователей. Уровень защиты может быть различным. Кроме непосредственной идентификации пользователей при входе в систему может использоваться также механизм шифрования данных при передаче по линиям связи.

Требования к рабочей среде

Поддерживаемые аппаратные платформы.

Минимальные требования к оборудованию.

Максимальный размер адресуемой памяти. Поскольку почти все современные системы используют свою файловую систему, немаловажным фактором является то, какой максимальный объем физической памяти они могут использовать.

Операционные системы, под управлением которых способна работать СУБД.

Смешанные критерии

Качество и полнота документации. К сожалению, не все системы имеют полную и подробную документацию.

Локализованность. Возможность использования национальных языков не во всех системах реализована полностью.

Модель формирования стоимости. Как правило, производители СУБД используют определенные модели формирования стоимости. Например, стоимость одного и того же продукта может существенно изменяться в зависимости от того, сколько пользователей будет с ним работать.

Стабильность производителя.

Распространенность СУБД.

146

Следует отметить, что по существующей практике решение об использовании той или иной СУБД принимает один человек – обычно руководитель предприятия, а он может опираться отнюдь не на технические критерии. Здесь свою роль могут сыграть такие незначительные с технической точки зрения факторы, как рекламная раскрутка компании-производителя СУБД, использование конкретных систем на других предприятиях, стоимость.

7. СИСТЕМЫ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ

7.1. Задачи, решаемые СППР

СППР – это системы, обладающие средствами ввода, хранения и анализа данных, относящихся к определенной предметной области, с целью поиска решения. Таким образом, можно выделить три основные задачи, решаемые в СППР [27]:

Ввод данных;

Хранение данных;

Анализ данных.

Ввод данных в СППР осуществляется либо автоматически от датчиков, либо человеком-оператором. Если ввод осуществляется одновременно несколькими операторами, то система должна решать проблемы параллельного доступа и модификации одних и тех же данных.

В подсистемах ввода данных, называемых OLTP (Online transaction processing), реализуется операционная (транзакционная) обработка данных. Для их реализации используются СУБД.

Задача хранения данных должна обеспечить надежное хранение больших объемов данных. На СППР также могут быть возложены задачи резервного хранения данных, архивирования и т.п. Для реализации подсистемы хранения используют СУБД и концепцию хранилищ данных.

Анализ данных – это основная задача СППР. Система предоставляет аналитику данные в соответствующем виде (отчеты, таблицы, графики и т.п.) для изучения и анализа, именно поэтому такие системы обеспечивают выполнение функции поддержки принятия решения. Подсистема анализа может быть построена на основе:

подсистемы информационно-поискового анализа на базе реляционных СУБД и статических запросов с использование языка SQL;

подсистемы оперативно-аналитического анализа. Для реализации таких подсистем применяется технология оперативной аналитичес-

кой обработки данных OLAP (Online analytical processing),

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

147

подсистемы интеллектуального анализа. Данная подсистема реализует методы и алгоритмы Data Mining (“добыча данных”). Рассмотрим основные требования, предъявляемые к системам OLTP

иСППР.

Типичный запрос в OLTP-системе, как правило, затрагивает отдельные записи в таблицах. В системах анализа, наоборот, требуется выполнять запросы сразу над большим количеством данных с широким применением группировок и обобщений (суммирования и т.п.).

Структура базы данных, обслуживающей OLTP-систему, обычно довольно сложна. Она может содержать десятки таблиц, ссылающихся друг на друга. При проектировании систем анализа стараются максимально упростить схему БД и уменьшить количество таблиц, участвующих в запросе.

Как правило, системы анализа предназначены для анализа временных зависимостей, в то время как OLTP-системы обычно имеют дело с текущими значениями каких-либо параметров.

OLTP-системы, как правило, работают в режиме реального времени, поэтому к ним предъявляются жесткие требования по обработке данных. В системах анализа обычно выдвигают значительно менее жесткие требования ко времени выполнения запроса. В отличие от OLTP-систем данные в системах анализа меняются редко.

7.2. Хранилища данных

Противоречивость требований к OLTP-системам и системам, ориентированным на анализ информации, усложняет задачу интеграции их как подсистем единой СППР. В настоящее время наиболее популярным решением этой проблемы является подход, ориентированный на использование концепции хранилищ данных (ХД) [27]. Основная идея хранилищ данных заключается в разделении БД для OLTP-систем и БД для выполнения анализа. Такое разделение позволяет оптимизировать как структуры данных оперативного хранения для выполнения операций ввода, модификации, удаления и поиска, так и структуры данных, используемых для анализа. В СППР эти два типа данных называются соответственно оперативными источниками данных (ОИД) и хранилищем данных.

В 1992 г. Уильман Г. Инмон подробно описал концепцию ХД в своей монографии ”Построение хранилищ данных”. В своей работе Инмон дал следующее определение ХД. Хранилища данных – это предметно-ориентированный, интегрированный, неизменный, поддерживающий хронологию набор данных, организованный для целей поддержки

148

принятия решений. При реализации в СППР концепции ХД данные из разных ОИД копируются в единое хранилище. Собранные данные приводятся к единому формату, согласовываются и обобщаются. Аналитические запросы адресуются к ХД.

Такая модель приводит к дублированию информации в ОИД и в ХД. Однако Инмон в своей работе утверждает, что избыточность данных не превышает 1 %. Это объясняется следующими причинами. При загрузке информации из ОИД в ХД данные фильтруются и очищаются. Многие из них не попадают в ХД. Информация в ОИД носит оперативный характер, и данные, потеряв актуальность, удаляются. В ХД, напротив, хранится историческая информация. В ХД хранится обобщенная информация, которая в ОИД отсутствует.

Избыточность информации можно свести к нулю, если использовать виртуальное ХД. В этом случае данные из ОИД не копируются в единое хранилище. Они извлекаются, преобразуются и интегрируются непосредственно при выполнении аналитических запросов. Основными достоинствами виртуального ХД являются: минимизация объема памяти, занимаемой на носителе информации, и работа с текущими, детализованными данными. Недостатки:

время обработки запросов к виртуальному ХД значительно выше;

выполнение сложных аналитических запросов над ОИД занимает большой объем ресурсов компьютеров, на которых они работают;

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

Основными проблемами при создании ХД являются:

необходимость интеграции данных из неоднородных источников;

потребность в хранении и обработке очень больших объемов информации;

необходимость наличия многоуровневых справочников метаданных (данных о данных);

повышенные требования к безопасности данных.

Снижения затрат на создание ХД можно добиться, создавая его

упрощенный вариант – витрину данных (Data Mart), содержащий только тематически объединенные данные (например данные, необходимые для маркетингового анализа). ВД существенно меньше по объему, чем ХД, и для ее реализации не требуется больших затрат. Они могут быть реализованы как самостоятельно, так и вместе с ХД.

Все данные в ХД делятся на три основные категории:

детальные данные;

агрегированные данные;

метаданные.

149