Система управления базами данных (СУБД) - комплекс программ, которые обеспечивают взаимодействие пользователя с базой данных. Посредством СУБД обеспечивается решение таких основных заданий:
1. Создание базы данных;
2. Занесение, корректировка и изъятие данных;
3. Упорядочение данных;
4. Выбор совокупности данных, что отвечают заданным критериям;
5. Оформление выходных данных и т.д.
Совокупность СУБД и базы данных - это банк данных. К достоинствам подхода, который основывается на концепции банка данных, принадлежит:
1. Удовлетворение информационных потребностей разных типов пользователей;
2. Достоверность и непротиворечивость информации, что сохраняется;
3. Санкционированный доступ к данным;
4. Адаптационной модели к изменениям предметной области;
5. Выдача информации в форме установленной пользователем;
6. Одноразовое введение данных и многократное их использование;
7. Возможность исключения избыточности данных, что сохраняются, и т.д.
Базу данных можно считать корпоративной если она: включена в КИС, отвечает требованиям распределенной обработки данных, масштабируема. [3]
В последние годы в мире оформился ряд новых концепций хранения и
анализа корпоративных данных:
1. Информационные системы класса OLTP
2. Хранилища данных (Data Warehouse);
3. Оперативная аналитическая обработка (On-Line Analytical Processing, OLAP);
4. Интеллектуальный анализ данных - ИАД (Data Mining).
Технологии OLAP тесно связаны с технологиями построения хранилища данных (Data Warehouse) и методами интеллектуальной обработки - Data Mining.
Информационные системы класса OLTP (On-Line Transaction Processing) или OLTP-системы предназначены, прежде всего, для обслуживания повседневной деятельности предприятия.
Главная задача этих систем - выполнение большого количества коротких транзакций. Транзакцией называют неделимую с точки зрения воздействия на базу данных последовательность операций манипулирования данными.
Сами транзакции являются достаточно простыми, но проблемы состоят в том, что таких транзакций очень много, выполняются они одновременно и при возникновении ошибок транзакция должна откатиться и вернуть систему в состояние, в котором та была до начала транзакции. Практически все запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления и удаления. Типичными примерами OLTP - приложений являются системы складского учета, заказов билетов, операционные банковские системы и др. Запросы на выборку в OLTP - системах, в основном, предназначены для предоставления пользователям выборки данных из различного рода справочников. Поскольку большая часть запросов известна заранее ещё на этапе проектирования системы, то критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных.
Таким образом, OLTP-системы имеют следующие особенности:
1. Рассчитаны на быстрое обслуживание относительно простых запросов большого числа пользователей;
2. Работают с данными, которые требуют защиты от несанкционированного доступа, нарушений целостности, аппаратных и программных сбоев.
Для обеспечения целостности данных и изолированности пользователей транзакции в OLTP-системах должны обладать четырьмя основными свойствами:
1. Атомарность. Транзакция должна выполняться как единая операция доступа к базе данных (БД) и может быть выполнена полностью либо не выполнена совсем.
2. Согласованность. Свойство согласованности гарантирует взаимную целостность данных, т.е. выполнение ограничений целостности БД после окончания обработки транзакции.
3. Изолированность. Это свойство означает, что транзакции должны выполняться независимо друг от друга, и доступ к данным, изменяемым с помощью одной транзакции, для других транзакций должен быть запрещен, пока изменения не будут завершены.
4. Долговечность. Свойство долговечности означает, что если транзакция выполнена успешно, то произведенные ею изменения в данных не должны быть потеряны ни при каких обстоятельствах. [5]
Длительное время в качестве стратегии разработки OLTP-систем использовались следующие принципы:
построение отдельных автоматизированных рабочих мест (АРМ), предназначенных для обработки групп функционально связанных документов, и тиражирование готовых АРМ на места;
построение полнофункциональных систем с тиражированием и настройкой по местам. Однако получаемые таким способом системы имели невысокие адаптационные возможности, предъявляли высокие требования к эксплуатационному персоналу и требовали больших накладных расходов на сопровождение.
Относительно недавно начала применяться новая, третья стратегия разработки информационных систем класса OLTP. Ее суть состоит в том, что тиражируются не готовые системы, а некоторые заготовки и технологический инструмент, позволяющие непосредственно на месте быстро построить или достроить систему с необходимой функциональностью и далее с помощью этого же инструмента ее модифицировать в соответствии с динамикой предметной области.
Хранилище данных (ХД) - предметно-ориентированный, интегрированный, неизменчивый, поддерживающий хронологию набор данных, организованный для целей поддержки управления.
По аналогии с реальными хранилищами, в хранилищах данных имеются большие области для сбора, хранения или перемещения существующих данных. Понятие "хранение данных" возникло, в середине 1980-х гг., и предназначалось для описания архитектурной модели потока данных от операционной системы к средствам поддержки принятия решений. Без такой архитектурной модели передаваемая управляющая информация обычно содержит большое количество избыточных данных.
В больших корпорациях множественные проекты принятия решений обычно осуществляются независимо, и при этом используется один и тот же набор данных. Таким образом, происходит накопление дублированных данных, что в конечном итоге приводит к снижению эффективности поддержки принятия решений.
Для повышения эффективности поддержки принятия решений и уменьшения дублированности данных применяют очистку данных (data cleaningили scrubbing). В ХД очистку данных также применяют для выявления и удаления ошибок, несоответствий в данных с целью улучшения их качества.
Хранилища данных требуют и одновременно обеспечивают всестороннюю поддержку очистки данных. Они загружают и постоянно обновляют огромные объемы данных из различных источников, поэтому вероятность попадания в них "грязных данных" весьма высока. Более того, хранилища данных используются в процессе принятия решений, следовательно, чтобы некорректные данные не привели к некорректным выводам, необходимо проводить корректировки таких данных. Например, дублирующаяся или утраченная информация может стать причиной некорректной или неадекватной статистики ("мусор на входе - мусор на выходе"). Ввиду большого спектра возможных несоответствий в данных и большого объема данных их очистка считается одной из самых крупных проблем в технологии хранилищ данных.
В состав хранилища данных, как правило, входит:
виртуальное хранилище данных;
витрины данных;
глобальное хранилище данных;
многоуровневая архитектура хранилища данных.
В основе виртуального хранилища данных лежит репозиторий метаданных, который описывается источниками информации (БД транзакционных систем, внешние файлы и др.), SQL-запросами для их считывания и процедурами обработки и предоставления информации. Непосредственный доступ к последним обеспечивает программное обеспечение промежуточного слоя. В этом случае избыточность данных нулевая. Конечные пользователи фактически работают с транзакционными системами напрямую со всеми вытекающими отсюда плюсами (доступ к не агрегированным данным в реальном времени) и минусами (интенсивный сетевой трафик, снижение производительности OLTP-систем и реальная угроза их работоспособности вследствие неудачных действий пользователей-аналитиков).
Витрина данных (Data Mart) - это облегченный вариант хранилища данных, содержащий только тематически объединенные данные. Целевая база данных максимально приближена к конечному пользователю и может содержать тематически ориентированные агрегатные данные. Витрина данных существенно меньше по объему, чем хранилище данных, поэтому его реализации не требуется мощная вычислительная техника.
Глобальное хранилище данных. В последнее время все более популярной становится идея совместить концепции хранилища и витрины данных в одной реализации и использовать хранилище данных в качестве единственного источника интегрированных данных для всех витрин данных. Тогда естественной становится следующая трехуровневая архитектура системы.
На первом уровне реализуется корпоративное хранилище данных на основе одной из развитых современных реляционных СУБД. Это хранилище состоит, в основном, из детализированных данных. Реляционные СУБД обеспечивают эффективное хранение и управление данными очень большого объема, но не слишком хорошо соответствуют потребностям OLAP-систем, в частности, в связи с требованием многомерного представления данных.
На втором уровне поддерживаются витрины данных на основе многомерной системы управления базами данных (примером такой системы является OracleExpressServer). Такие СУБД почти идеально подходят для целей разработки OLAP-систем, но пока не позволяют хранить сверхбольшие объемы данных (предельный размер многомерной базы данных составляет 10-40 Гбайт). В данном случае это и не требуется, поскольку речь идет о витринах данных. Необходимо заметить, что витрина данных не обязательно должна быть полностью сформирована. Она может содержать ссылки на хранилище данных и добирать оттуда информацию по мере поступления запросов. Конечно, это несколько увеличивает время отклика, но зато снимает проблему ограниченного объема многомерной базы данных.