Взгляд со стороны специалиста, отвечающего за реализацию и сопровождение системы (выраженный Б. Инмоном), который также вполне естественно говорит о том, что конечной целью Хранилища Данных является обеспечение информационных потребностей конечных пользователей (менеджеров и аналитиков). Но для него главное - выявление наиболее общих свойств и характеристик данных. Решение вопросов сбора, транспортировки, очистки, согласования и агрегации данных из различных внешних источников.
Таким образом, формально говоря об одном и том же, эти концепции не конкурируют, а скорее, взаимно дополняют друг друга.
В то же время эти концепции никак непосредственно не взаимосвязаны. Хранилище Данных может использоваться исключительно как источник для регламентированных аналитических сводок и отчетов или для регламентированной статистической обработки, но не для OLAP. А OLAP-инструментарий может быть с успехом использован для непосредственной работы с оперативными данными из традиционной СОД.
1.3 Технологии и средства реализации
1.3.1 Вопросы реализации Хранилищ Данных
Аналитические системы всегда предъявляли существенно более высокие, чем традиционные СОД, требования к аппаратному обеспечению и программному обеспечению. И, приступая к построению ХД, следует учитывать необходимость разрешения таких вопросов, как:
1. неоднородность программной среды;
2. распределенность;
3. защита данных от несанкционированного доступа;
4. построение и ведение многоуровневых справочников метаданных;
5. эффективное хранение и обработка очень больших объемов данных.
Основополагающим отличием Хранилищ Данных от традиционных СОД является то, что они практически никогда не создаются на пустом месте. И почти всегда конечное решение будет разнородным (с точки зрения производителей программных средств, принципов построения, операционных систем).
Основа Хранилищ Данных - не внутренние, как в большинстве традиционных СОД, а внешние источники данных: различного рода информационные системы, электронные архивы, общедоступные и коммерческие электронные каталоги, справочники, статистические сборники. Как правило, сегодня в любой организации реально функционирует множество несвязанных или слабо связанных СОД. В большинстве случаев они создавались в различное время, различными коллективами разработчиков и реализованы на основе различных программных и аппаратных средств. Таким образом, уже сама основа, на которой будет строиться Хранилище Данных, чаще всего уже является крайне не однородной. Добавьте сюда средства выгрузки, транспортировки, реализации целевой БД Хранилища Данных.
Очевидно, что в таких условиях даже говорить об однородности программных средств чрезвычайно сложно. И практически всегда задача построения Хранилища Данных - это задача построения единой, согласованно функционирующей, информационной системы на основе неоднородных программных средств и решений. И уже сам выбор средств реализации Хранилища Данных становится чрезвычайно сложной задачей. Здесь должно учитываться множество факторов, включая взаимную совместимость различных программных компонентов, легкость их освоения и использования, эффективность функционирования, стабильность и даже формы, уровень и потенциальную перспективность взаимоотношений различных фирм производителей.
2 Распределенность
Хранилища Данных уже по своей природе являются распределенным решением.
В основе концепции Хранилищ Данных лежит физическое разделение узлов, где выполняется операционная обработка, от узлов, в которых выполняется анализ данных. И хотя при реализации такой системы нет необходимости в строгой синхронизации данных в различных узлах (например на основе средств двухфазной фиксации транзакций), средства асинхронной асимметричной репликации данных являются неотъемлемой частью практически любого решения.
3 Защита данных от несанкционированного доступа;
Собрав в одном месте всю информацию об истории развития организации, ее успехах и неудачах, о взаимоотношениях с поставщиками и заказчиками, об истории развития и состоянии рынка, менеджеры получают уникальную возможность для анализа прошлой деятельности, сегодняшнего дня и построения обоснованных прогнозов на будущее. Однако не следует забывать и о том, что, если не обеспечены надлежащие средства защиты и ограничения прав доступа, вы можете снабдить этой информацией и ваших конкурентов.
Одним из первых же вопросов, встающих при обсуждении проекта Хранилища Данных, является вопрос защиты данных. Чисто психологически, многих пугают не столько затраты на реализацию системы Хранилищ Данных (чаще всего есть понимание, что эффект от ее использования будет больше), а то, что доступ к критически значимой информации может получить кто-либо, не имеющий на это права.
В таких системах часто оказывается недостаточно защиты, обеспечиваемой в стандартных конфигурациях коммерческих СУБД (обычно уровень защиты по классу "C2 Orange Book"). Региональный менеджер должен видеть только те данные, которые относятся к его региону, а менеджер подразделения не должен видеть данные, относящиеся ко всей фирме. Но для повышения эффективности доступа к данным, в целевой БД Хранилища Данных все эти данные, как правило, хранятся в виде единой фактологической таблицы. Следствием этого является то, что средства реализации должны поддерживать ограничения доступа не только на уровне отдельных таблиц и их колонок, но и отдельных строк в таблице (класс "B1 Orange Book").
Не менее остро стоят и вопросы авторизации и идентификации пользователей, защиты данных в местах их преобразования и согласования, в процесс их передачи по сети (шифрование паролей, текстов запросов, данных).
4 Построение и ведение многоуровневых справочников метаданных
Наличие метаданных и средств их представления конечным пользователям - это один из основополагающих факторов успешной реализации Хранилища Данных. Более того, без наличия актуальных, максимально полных и легко понимаемых пользователем описаний данных Хранилище Данных превращается в обычный, но очень дорогостоящий электронный архив.
Первая же задача, с которой сталкиваешься при проектировании и реализации системы Хранилищ Данных, заключается в необходимости одновременной работы с самыми разнородными внешними источниками данных, несогласованностью их структур и форматов, масштабами и количеством архивов, которые должны быть переработаны и загружены. И при построении такой системы разработчику сложно обойтись без высокоуровневых средств описания информационной модели системы. Причем эта модель должна содержать описания не только целевых структур данных в БД Хранилища, но и структур данных в источниках их получения (различных информационных системах, архивах, электронных справочниках и т. д.), правила, процедуры и периодичность их выборки и выгрузки, процедуры и места согласования и агрегации.
Здесь следует сделать несколько замечаний относительно выбора конкретных средств проектирования. Как уже было сказано выше, характерными свойствами аналитической системы, являются:
- разнородность компонентов;
- ориентированность на нерегламентированную работу с данными.
Рассмотрим, как это влияет на выбор и требования к средствам проектирования. С одной стороны, из-за разнородности программных и системных компонентов, образующих Хранилища, и малой доли регламентированных пользовательских приложений, чаще всего результатом проектирования системы будет не готовый к исполнению программный продукт (что является обычным требованием для средств проектирования СОД), а база метаданных, содержащая всестороннее многоуровневое описание целевой информационной системы. С другой стороны, как будет показано ниже, в аналитических системах именно вопросы полноты, актуальности, простоты использования и понимания метаданных приобретают особую актуальность.
О значимости метаданных в информационных системах говорится много. Тем не менее на практике в подавляющем большинстве традиционных СОД их роль, по крайней мере, с точки зрения конечного пользователя, не очень велика. С чем это связано? Для того чтобы ответить на этот вопрос, рассмотрим три основных категории специалистов, работающих с СОД: конечные пользователи, системные администраторы, разработчики.
Конечные пользователи - это наиболее массовый слой специалистов, работающих с СОД. Именно они, в конечном счете, являются основными заказчиками и пользователями системы. Но в случае традиционной СОД, которую можно сравнить с хорошо отлаженным заводским конвейером, именно они, как правило, и не получают никаких преимуществ ни от наличия, ни от отсутствия базы метаданных. Обязанности и функции каждой категории конечных пользователей обычно четко оговорены в соответствующих инструкциях ("Инструкция оператора", "Инструкция пользователя" и т. д.), а всю уточняющую информацию они могут получить с помощью специальных регламентированных подсказок и комментариев.
Более того, обычно предполагается, что чем меньше от пользователя требуется знаний о структурах и потоках данных, взаимосвязях и взаимозависимостях различных программных компонентов, тем лучше реализована информационная система. В таких системах обычно не только не приветствуется, но и даже не допускается возможность свободной импровизации с данными и процедурами их обработки. Здесь преднамеренно не рассматриваются случаи, когда у конечного пользователя возникает необходимость в выполнении нового, заранее непредусмотренного, запроса (выборки), так как этот вид деятельности свойственен аналитической, а не оперативной системе.