Автор работы: Пользователь скрыл имя, 09 Февраля 2013 в 19:21, реферат
На первых этапах автоматизации требовалось и требуется навести порядок именно в процессах повседневной рутинной обработки (переработки) данных, на что и ориентированны традиционные СОД. Более того, системы СППР являются в определенном смысле вторичными, по отношению к ним. Здесь возможна аналогия с производством. Любая продукция, прежде чем попасть на склад и быть отгружена потребителю, должна быть сначала произведена. И прежде чем заниматься анализом данных, необходимо эти данные иметь (произвести). А именно, это и является одной из функций СОД.
Как уже было сказано выше, концепция Хранилищ Данных определяет лишь самые общие принципы построения аналитической системы и в первую очередь сконцентрирована на свойствах и требованиям к данным, но не способах их организации и представления в целевой БД и режимах их использования.
То есть, она фактически не затрагивает и оставляет свободу выбора в вопросах, относящихся:
В определённом смысле, концепция Хранилищ Данных, это концепция построения аналитической системы, но не концепция её использования. Но, данные собираются не для того чтобы храниться, они должны работать. Ответ на вопрос, как наилучшим образом и наиболее полно использовать уже собранные и подготовленные для анализа данные и дают различные концепции анализа данных:
Всего три-четыре года назад, результатом работы любой аналитической системы, являлись регламентированные многостраничные отчеты и диаграммы. Но, как правило, после просмотра такого отчета, у аналитика появлялся не готовый ответ, а новая серия вопросов. Однако если бы ему захотелось получить ответ на новый, непредусмотренный при проектировании системы вопрос, он мог ждать его часы, а иногда и дни.
Каждый новый запрос, в системах реализуемых на основе традиционных технологий статического анализа данных (таблица 3), должен быть сначала формально описан, передан программисту, запрограммирован и, наконец, выполнен. Но после того как аналитик, наконец, получал долгожданный ответ, достаточно часто оказывалось, что решение не могло ждать и оно уже принято, или, что ещё чаще, произошло взаимное непонимание и получен ответ не на совсем тот вопрос.
Таблица
3. Сравнение характеристик
Характеристика |
Статический анализ |
Динамический анализ |
Типы вопросов |
Сколько? Как? Когда? |
Почему? Что будет если? |
Время отклика |
Не регламентируется |
Секунды |
Типичные операции |
Регламентированный отчет, диаграмма |
Последовательность интерактивных отчетов, диаграмм, экранных форм. Динамическое изменение уровней агрегации и срезов данных. |
Уровень аналитических требований |
Средний |
Высокий |
Тип экранных форм |
В основном определенный заранее, регламентированный |
Определяемый пользователем |
Уровень агрегации данных |
Детализированные и суммарные |
В основном суммарные |
Возраст данных |
Исторические и текущие и прогнозируемые |
Исторические, текущие и прогнозируемые |
Типы запросов |
В основном предсказуемые |
Непредсказуемые, от случаю к случаю |
Назначение |
Регламентированная аналитическая обработка |
Многопроходный анализ, моделирование и построение прогнозов |
У истоков концепции многомерного динамического анализа - OLAP, стоит основоположник реляционного подхода Э.Кодд /3/, сформулировавший 12 основных требований к средствам реализации OLAP.
Заметим, что у Кодда, термин OLAP обозначает исключительно конкретный способ представления данных на концептуальном уровне - многомерный. Более того, в своей работе он ни разу не использовал термин Многомерная СУБД.
В этом смысле,
представляет интерес сам список
терминов используемых Коддом в его
работе: “OLAP Server”, “Multiple
Data Dimension”, Multi-Dimensional Conceptual View”, “OLAP Product”,
“OLAP Tool”, “Server component of OLAP Tools” и даже “OLAP Tools Physical Schema”, но ни разу ни “Multi-Dimensional DataBase”, ни “Multi-
Однако исторически сложилось так, что сегодня, термин OLAP подразумевает не только многомерный взгляд на данные со стороны конечного пользователя, но и многомерное представление данных в целевой БД /4/. Именно с этим, связано появление в качестве самостоятельного термина Реляционный OLAP (ROLAP). Между этими концепциями существует единственное принципиальное различие: - что понимать под термином “Server Component of OLAP Tools”: - интерфейс к целевой БД или собственно целевую БД.
Закономерен вопрос,
как взаимно соотносятся
Таким образом, формально говоря об одном и том же, эти концепции не конкурируют, а скорее взаимно дополняют друг друга.
В то же время, эти
концепции никак
Аналитические системы всегда предъявляли существенно более высокие, чем традиционные СОД, требования к аппаратному обеспечению и программному обеспечению. И, приступая к построению аналитической системы, следует понимать, что её реализация практически невозможна без разрешения таких вопросов как:
Основополагающим отличием Хранилищ Данных от традиционных СОД является то, что они практически никогда не создаются на пустом месте. И практически всегда, конечное решение будет разнородным (с точки зрения производителей программных средств, принципов построения, операционных систем)
Основой Хранилищ Данных являются не внутренние, как в большинстве традиционных СОД, а внешние источниками данных: различного рода информационные системы, электронные архивы, общедоступные и коммерческие электронные каталоги, справочники, статистические сборники. Как правило, сегодня в любой организации реально функционирует множество несвязанных или слабо связанных СОД. В большинстве случаев, они создавались в различное время, различными коллективами разработчиков и реализованы на основе различных программных и аппаратных средств. Таким образом, уже сама основа, на которой будет строиться Хранилище Данных, чаще всего уже является крайне неоднородной. Добавьте сюда средства выгрузки, транспортировки, реализации целевой БД Хранилища Данных.
Очевидно, что в таких условиях, даже говорить об однородности программных средств чрезвычайно сложно. И практически всегда, задача построения Хранилища Данных, это задача построения единой согласовано функционирующей информационной системы, на основе неоднородных программных средств и решений. И уже сам выбор средств реализации Хранилища Данных становится чрезвычайно сложной задачей. Здесь должно учитываться множество факторов, включая, взаимную совместимость различных программных компонент, легкость их освоения и использования, эффективность функционирования, стабильность и даже формы, уровень и потенциальную перспективность взаимоотношений различных фирм производителей.
Хранилища Данных уже по своей природе являются распределенным решением.
В основе концепции Хранилищ Данных, лежит физическое разделение узлов, в которых выполняется операционная обработка, от узлов в которых выполняется анализ данных. И хотя, при реализации такой системы, нет необходимости в строгой синхронизации данных в различных узлах (например, на основе средств двух фазной фиксации транзакций), средства асинхронной асимметричной репликации данных являются неотъемлемой частью практически любого решения.
.
Наличие метаданных и средств их представления конечным пользователям является одним из основополагающих факторов успешной реализации Хранилища Данных. Более того, без наличия актуальных, максимально полных и легко понимаемых пользователем описаний данных, Хранилище Данных превращается в обычный, но очень дорогостоящий электронный архив
Первой же задачей, с которой сталкиваешься при проектировании и реализации системы Хранилищ Данных, является необходимость одновременной работы с самыми разнородными внешними источниками данных, несогласованностью их структур и форматов, масштабами и количеством архивов, которые должны быть переработаны и загружены. И при построении такой системы, разработчику сложно обойтись без высокоуровневых средств описания информационной модели системы. Причем, эта модель должна содержать описания не только целевых структур данных в БД Хранилища, но и структур данных в источниках их получения (различных информационных системах, архивах, электронных справочниках и т.д.), правила, процедуры и периодичность их выборки и выгрузки, процедуры и места согласования и агрегации.
Здесь следует сделать несколько замечаний относительно выбора конкретных средств проектирования. Как уже было сказано выше, характерными свойствами аналитической системы, является:
Рассмотрим, как
это влияет на выбор и требования
к средствам проектирования. С
одной стороны, из-за разнородности
программных и системных
О значимости метаданных в информационных системах говорится много. Тем не менее, на практике, в подавляющем большинстве традиционных СОД их роль, по крайней мере, с точки зрения конечного пользователя, не очень велика. С чем это связано? Для того чтобы ответить на этот вопрос, рассмотрим три основных категории специалистов работающих с СОД: конечные пользователи, системные администраторы, разработчики.
Это наиболее массовый
слой специалистов работающих с СОД.
Именно они, в конечном счете, являются
основными заказчиками и
Более того, обычно предполагается, что, чем меньше от пользователя требуется знаний о структурах и потоках данных, взаимосвязях и взаимозависимостях различных программных компонент, тем лучше реализована информационная система. В таких системах, обычно не только не приветствуется, но и даже не допускается возможность свободной импровизации с данными и процедурами их обработки. Здесь, преднамеренно не рассматриваются случаи, когда у конечного пользователя возникает необходимость в выполнении нового заранее непредусмотренного запроса (выборки), так как, такой вид деятельности свойственен аналитической, а не оперативной системе.
Администраторы БД - категория специалистов, основной задачей которых является поддержание СОД в актуальном рабочем состоянии. Их, как правило, интересует не семантика данных, а способы их физического представления и организации. Администратор обычно не работает с конкретными значениями данных, не занимается написанием новых и модернизацией уже существующих прикладных программ. И хотя потребность в наличии и доступности метаданных у этой категории специалистов высока, их обычно вполне устраивают ограниченные описания данных, содержащиеся в традиционных справочниках БД. И даже, несмотря на то, что структура описаний в таких справочниках достаточно сложна для понимания, это так же не вызывает особых нареканий. Число администраторов обычно невелико и они, как правило, обладают достаточной квалификацией и опытом работы.
Разработчики - категория специалистов ответственных за разработку и дальнейшее развитие СОД. Наличие метаданных (данных о данных) является необходимым условием успешной реализации любой СОД. И именно при разработке (модернизации) СОД, эта информация формируется и активно используется. Однако формируется, не означает того, что формируется электронный образ общедоступной и общепонятной базы метаданных. Более того, даже если при разработке информационной системы используется CASE инструментарий:
Информация о работе Концепции построения и реализации информационных систем