Анализ данных в БД


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

Лидером разработки ОЛАП систем считается компания КОГНУС поставляющая продукт OURPLAY на самом деле ориентированные на простенькие СУБД типа Парадокс, Дебэйс, Крипер, таблицы Эксель и т.д. Среди больших систем такого рода можно отметить такие как Сикейт, Хобос, Олап Сервер от IBM, Информатика Мегакуб, Оракал-Экспресс, Microsoft SQL-server 7.0 Olap и т.д. Это уже не десктоповские СУБД, а реляционные СУБД специально выпущенные для кубов. Двухуровневые клиент-серверные системы работают эффективно при следующих условиях:
— Во-первых объем данных пересылаемых между клиентом и сервером не велик.
— Второе, большая часть вычислений может быть сделано заранее
— Третье, пункт пользователей ограничен, поскольку такие серверы не могут выполнять много запросов.
— Четвертое, клиенты изолированы друг от друга. Здесь понимается изоляция как работа с разными данными. Один работает по приему, другой по сбыту – в этом смысле изолированные.
— И последний пункт, приложение не требует постоянных модификаций и усовершенствований.

При строении трехуровневых систем, между клиентом и сервером помещают сервер приложений (Application server). Эта система используется в случае корпоративных ресурсов для того, чтобы разделить эти ресурсы между большим числом клиентов.

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

Процессы в системах анализа данных

Существует 3 большие группы.
1. Поиск зависимости:
— просмотр баз данных с целью автоматического выявления зависимостей. Проблема заключается в том, что создать автоматизированное программное средство, которое сможет производить поиск при различных типах данных, при данных, полученных за разное время, оказывается неудобным и сложным.
2. Прогнозирование:
— предполагает, что можно предъявить системы записей с некоторыми незаполненными полями, предлагается системе вставить туда данные.
3. Анализ аномалий:
— поиск подозрительных данных, сильно отличающихся от устойчивых значений.

Требования к оперативности-не предъявляются, данных – много.
Главное- достоверность выводов, на основе этих выводов принимаются решения, вкладываются деньги и т.д.

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

Перед тем как задать вопрос, пользователь должен знать:
1) источники получения данных, степень достоверности;
2) периодичность обновления, т.е. не только когда те или иные данные получены, но и когда ждать следующие данные, чтобы он мог прогнозировать и потом проверять правильность работы системы на прогнозах. Вообще, прежде чем довериться системе ее гоняют на различных тестах, моделируют ситуацию;
3) собственников данных – администратор нарезает права каждому пользователю – какие данные он может видеть, какие – корректировать, какие колонки таблиц видеть и править;
4) статистические оценки вопросов (например, время выполнения – еще до выполнения запроса пользователь должен примерно представлять, сколько времени будет выполняться запрос, количество объектов в полученном ответе на запрос – таблица, Полученная по запросу и состоящая из 1000 строк тяжела для восприятия).


Комментарии запрещены.




Статистика