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

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

Концепция DW была предложена в 1990 г. Б. Инмоном и стала одной из доминирующих в разработке информационных технологий обработки данных 90-х годов. Появление этой концепции было следствием неявного осознания того факта, что существует два основных функционально различных класса систем обработки информации [3, с.24].

Первый базируется на обработке текущего потока транзакций и предоставляет текущий или охватывающий небольшой временной период снимок информации. Второй основан на сборе и подготовке большого по объему и временному периоду (от 5 лет) массива значимой информации, предназначенного для проведения анализа данных. Развитие концепции DW позволило провести границы между этими двумя типами систем. В русском языке термин «Data Warehouse» переводится двояко: как хранилище данных и как информационное хранилище. Однако термин «Information warehouse» был введен корпорацией IBM в начале 80-х годов и, по утверждению ее специалистов, означает нечто большее, чем DW по Инмону. Поэтому целесообразно пользоваться общепринятым термином «хранилище данных», хотя он несколько хуже передает суть концепции.

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

Очень важен основной принцип действия DW: единожды занесенные в DW данные затем многократно извлекаются из него и используются для анализа. Отсюда вытекает одно из основных преимуществ использования DW в работе предприятия - контроль за критически важной информацией, полученной из различных источников, как за производственным ресурсом [4, с.24].

Отметим, что наиболее уязвимым местом использования DW на предприятии, с точки зрения бизнеса, является корректность его данных, полученных из разных источников. Данные перед загрузкой в DW должны быть либо «очищены от шума», либо обработаны методами нечеткой логики, допускающей наличие противоречивых фактов. Например, данные о предприятии-партнере могут быть получены от разных экспертов, чьи оценки порой бывают диаметрально противоположными.

Ральф Кимбалл (Ralph Kimball), один из авторов концепции хранилищ данных, описывал хранилище данных как «место, где люди могут получить доступ к своим данным». [9, с.24] Он же сформулировал и основные требования к хранилищам данных:

- поддержка высокой скорости получения данных из хранилища;

- поддержка внутренней непротиворечивости данных;

- возможность получения и сравнения так называемых срезов данных (slice and dice);

- наличие удобных утилит просмотра данных в хранилище;

- полнота и достоверность хранимых данных;

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

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

Хранилище данных представляет собой банк данных определенной структуры, содержащий информацию о производственном процессе компании в историческом контексте. Главное назначение хранилища - обеспечивать быстрое выполнение произвольных аналитических запросов.

Типичное хранилище данных, как правило, отличается от обычной реляционной базы данных. Во-первых, обычные базы данных предназначены для того, чтобы помочь пользователям выполнять повседневную работу, тогда как хранилища данных предназначены для принятия решений. Например, продажа товара и выписка счета производятся с использованием базы данных, предназначенной для обработки транзакций, а анализ динамики продаж за несколько лет, позволяющий спланировать работу с поставщиками, - с помощью хранилища данных [2, с.24].

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

И в-третьих, обычные базы данных чаще всего являются источником данных, попадающих в хранилище. Кроме того, хранилище может пополняться за счет внешних источников, например статистических отчетов [6, с.24].

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

Согласно исследованию META Group, 90 - 95% компаний списка Fortune 2000 активно применяют хранилища данных, чтобы добиться преимущества в конкурентной борьбе и получить значительно большую отдачу от своих инвестиций. Трехлетнее изучение опыта 62 организаций, проведенное International Data Corporation (IDC) показало, что эти организации в среднем получили 400-процентный возврат своих инвестиций в СППР-системы [4, с.24]. Перечислим главные преимущества хранилищ данных:

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

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

- Быстрота разработки: специфическая логическая организация хранилища и существующее специализированное ПО позволяют создавать аналитические системы с минимальными затратами на программирование.

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

- Историчность и стабильность: OLTP-системы оперируют с актуальными данными, срок применения и хранения которых обычно не превышает величины текущего бизнес-периода (полугода-год), в то время как информационное хранилище данных нацелено на долговременное хранение информации в течение 10-15 лет. Стабильность означает, что фактическая информация в хранилище данных не обновляется и не удаляется, а только специальным образом адаптируется к изменениям бизнесс-атрибутов. Таким образом, появляется возможность осуществлять исторический анализ информации.

- Независимость: выделенность информационного хранилища существенно снижает нагрузку на OLTP-системы со стороны аналитических приложений, тем самым производительность существующих систем не ухудшается, а на практике происходит уменьшение времени отклика и улучшение доступности систем.

1.2 Таблицы измерений

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

Каждая таблица измерений должна находиться в отношении «один ко многим» с таблицей фактов.

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

Пример таблицы измерений приведен в приложении Г.

Одно измерение куба может содержаться как в одной таблице (в том числе и при наличии нескольких уровней иерархии), так и в нескольких связанных таблицах, соответствующих различным уровням иерархии в измерении. Если каждое измерение содержится в одной таблице, такая схема хранилища данных носит название «звезда» (star schema). Пример схемы приведен в Приложении Б.

Если же хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема хранилища данных носит название «снежинка» (snowflake schema). Дополнительные таблицы измерений в такой схеме, обычно соответствующие верхним уровням иерархии измерения и находящиеся в соотношении «один ко многим» в главной таблице измерений, соответствующей нижнему уровню иерархии, иногда называют консольными таблицами (outrigger table). Пример схемы «снежинка» приведен в приложении Д.

Отметим, что даже при наличии иерархических измерений с целью повышения скорости выполнения запросов к хранилищу данных нередко предпочтение отдается схеме «звезда».

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

Еще один пример отступления от правил - наличие нескольких разных иерархий для одного и того же измерения. Типичные примеры таких иерархий - иерархии для календарного и финансового года (при условии, что финансовый год начинается не с 1 января), или с различными способами группировки членов измерения (например, группировать товары можно по категориям, а можно и по компаниям-поставщикам). В этом случае таблица измерений содержит поля для всех возможных иерархий с одними и теми же членами нижнего уровня, но с разными членами верхних уровней пример такой таблицы приведен на рисунке в приложении В. [7, с.24].

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

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

2. Аналитические системы

2.1 Создание информационно-аналитических систем

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

Создание информационно-аналитических систем, реально отвечающих целям и задачам организаций, представляет собой достаточно сложный процесс, включающий этапы формирования концепции, проектирования, разработки, внедрения и сопровождения. Сам характер этого процесса требует предварительной разработки достаточно жесткой фиксированной технологической схемы. Технологическая схема представляет собой в соответствии со стандартом ГОСТ Р ИСО/МЭК 12207-99, описывающим процессы жизненного цикла программных средств, последовательность работ и задач, выполняемых определенными исполнителями.

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

Технология и методика создания информационно-аналитических систем охватывает следующие виды деятельности:

· сбор, анализ и детализацию требований к информационно-аналитической системе, определение приоритетов реализации этих требований и постановка задач по их реализации, определение требований по архитектуре, надежности и защите от несанкционированного доступа и определение состава данных;

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

· разработка аналитических приложений, выбор и настройка инструментальных средств сбора, преобразования и очистки данных и организации доступа пользователей к данным, разработка метаданных, тестирование, разработка документации пользователей [7, с.24].

Рекомендации по выполнению работ и задач включают рекомендации по вопросам сбора требований, идентификации источников данных, извлечения и преобразования данных для размещения в хранилище, создания тематических витрин данных, разработки регламентных отчетов, применения средств углубленного анализа данных, вопросы хранения «исторических» данных.

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

· При определении адресных сведений следует придерживаться следующей структуры адреса: почтовый индекс, код населенного пункта по общестатистическому классификатору ОКАТО (урезанный до шести знаков, существенных для отдельной области), код улицы, номер дома, номер корпуса/строения, номер квартиры/помещения. Классификаторы улиц в настоящее время разрабатываются администрациями городов и должны интегрироваться на сервере областной администрации в едином адресаторе. В настоящее время разработан и поддерживается классификатор улиц города Иваново. Возможно использовать в качестве основы такого адресатора базу областной налоговой инспекции. Вместе с тем, правомерно областной адресатор курировать управлению архитектуры в рамках ведения градостроительного кадастра совместно с информационно-аналитическом центром областной администрации и распространять всем заинтересованным ведомствам для ведения своих реестров.

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

· Желательно иметь на уровне области интегрированные хранилища сведений по юридическим и физическим лицам, определенная информация из которых может быть использована различными ведомствами в качестве соответствующих общесистемных справочников. Так на уровне информационно-аналитического центра администрации области должна вестись интегрированная база по юридическим лицам, которая объединяет сведения, собираемые регистрирующими органами администраций городов и районов, а также ряд вышеупомянутых ведомственных реестров. В настоящее время в администрациях крупных городов уже ведутся соответствующие базы данных, которые могут быть использованы в интересах ведения общего хранилища. Недостающую информацию можно получить из реестра областного комитета статистики. Уточнять информацию можно на основе открытых для публикации сведений реестра налогоплательщиков областной налоговой инспекции. Хранилище сведений по физическим лицам должно вестись на основе данных адресного бюро управления внутренних дел, а также областного отдела ЗАГС и, возможно, областной налоговой инспекции.

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

· Каждое зарегистрированное строение и помещение должно иметь уникальный в рамках области кадастровый номер, который будет однозначно идентифицировать его в региональной информационной системе, аналогично коду ИНН юридического лица или социальному номеру физического лица. Это может быть инвентарный номер БТИ или при его отсутствии реестровый номер КУГИ. По соответствующему инвентарному номеру в хранилище будет накапливаться динамика состояния объекта собственности. Аналогичным образом должны быть идентифицированы все ресурсы области [10, с.24].

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

2.2 Области применения

Аналитические системы СППР позволяют решать три основных задачи: ведение отчётности, анализ информации в реальном времени (OLAP) и интеллектуальный анализ данных.

Отчётность.

Сервис отчётности СППР помогает организации справиться с созданием всевозможных информационных отчетов, справок, документов, сводных ведомостей и пр., особенно когда число выпускаемых отчетов велико и формы отчётов часто меняются. Средства СППР, автоматизируя выпуск отчётов, позволяют перевести их хранение в электронный вид и распространять по корпоративной сети между служащими компании [8, с.24].

OLAP

Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing). OLAP - это ключевой компонент организации хранилищ данных. Концепция OLAP была описана в 1993 году Эдгаром Коддом, известным исследователем баз данных и автором реляционной модели данных. В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information - быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа:

- предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа;

- возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде;

- многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа;

- многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это - ключевое требование OLAP);

- возможность обращаться к любой нужной информации независимо от ее объема и места хранения [4, с.24].

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

OLAP (On-Line Analitycal Processing) - сервис представляет собой инструмент для анализа больших объемов данных в режиме реального времени. Взаимодействуя с OLAP-системой, пользователь сможет осуществлять гибкий просмотр информации, получать произвольные срезы данных, и выполнять аналитические операции детализации, свертки, сквозного распределения, сравнения во времени. Вся работа с OLAP-системой происходит в терминах предметной области [7, с.24].

OLAP-системы являются частью более общего понятия Business Intelligence, которое включает в себя помимо традиционного OLAP-сервиса средства организации совместного использования документов, возникающих в процессе работы пользователей хранилища. Технология Business Intelligence обеспечивает электронный обмен отчетными документами, разграничение прав пользователей, доступ к аналитической информации из Интернет и Интранет [4, с.24].

Интеллектуальный анализ данных или «добыча данных» (Data Mining)

При помощи средств добычи данных можно проводить глубокие исследования данных. Эти исследования включают в себя: поиск зависимостей между данными (напр., «Верно ли, что рост продаж продукта А обусловлен ростом продаж продукта В?»); выявление устойчивых бизнес-групп (напр. «Какие группы клиентов, близких по поведенческим и другим характеристикам, можно выделить? Какие характеристики клиентов при этом оказывают наибольшее влияние на классификацию?»); прогнозирование поведения бизнес-показателей (напр. «Какой объем перевозок ожидается в следующем месяце?»); оценка влияния решений на бизнес компании (напр. «Как изменится спрос на товар А среди группы потребителей Б, если снизить цену на товар С?»); поиск аномалий (напр. «С какими сегментами клиентской базы связаны наиболее высокие риски?»).

Телекоммуникации

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

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

Есть категории клиентов, которые постоянно меняют провайдеров, реагируя на те или иные рекламные компании. СППР позволяют выявить наиболее характерные признаки «стабильных» клиентов, т.е. клиентов, длительное время остающихся верными одной компании, давая возможность ориентировать свою маркетинговую политику на удержание именно этой категории клиентов.

Банковское дело

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

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

Например компания Intersoft Lab, специализирующаяся в области разработки аналитических и управленческих систем для банков, коммерческих и производственных предприятий, бюджетных организаций, провела демо-день на тему «Постановка и автоматизация бюджетирования в холдингах и финансово-промышленных группах».

Тема демо-дня была выбрана неслучайно: сегодня все больше предприятий и компаний ощущают потребность в инструменте, с помощью которого можно четко определить возможности и перспективы развития компании, повысить финансовую обоснованность и ответственность за принимаемые управленческие решения. Достаточно сказать, что эффективные управленческие технологии позволяют сократить потребность в оборотных средствах на 10-30%. Поэтому понятен и закономерен интерес к программной разработке компании Intersoft Lab - управленческой системе "Контур Корпорация. Бюджет холдинга", созданной на основе платформы интеллектуального анализа данных "Контур". Система позволяет планировать бюджетные показатели финансово-хозяйственной деятельности предприятий холдинга, учитывать, контролировать и анализировать фактическое исполнение бюджетов. Первым шагом к знакомству с программным продуктом стало определение целей и задач внедрения бюджетного управления в холдингах и финансово-промышленных группах. Участники семинара познакомились с принципами постановки бюджетного управления в многофилиальной компании и подробно рассмотрели организационные, методические и технологические аспекты внедрения автоматизированной системы бюджетирования на предприятии. Специалисты компании Intersoft Lab подробно остановились на функциональных и технических возможностях программного комплекса "Контур Корпорация. Бюджет холдинга". Практическое применение системы было продемонстрировано на примере технологии ведения бюджета движения денежных средств. Многочисленные вопросы слушателей касались, в частности, автоматизации бюджетирования на предприятии. Большой интерес вызвало обсуждение методов "раскраски" бюджетов. Для разметки бюджетных данных аналитическими признаками существует три основных способа: настройка бюджетной аналитики и разметка бюджетных данных в учетной системе, автоматическая разметка данных в ходе загрузки на основании автоматизированных (запрограммированных) алгоритмов разметки, разметка вручную в интерфейсе системы. Все эти способы разметки данных поддерживаются в автоматизированной системе "Контур Корпорация. Бюджет холдинга".

Заключение

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

Хранилище предоставляет возможность получения каждым подразделением данных в разрезе интересующих его показателей, в удобном и привычном для сотрудников этого подразделения виде. Можно сравнить хранилище с огромным складом с большим ассортиментом продукции, а информацию по подразделениям, получаемых из него, с небольшими специализированными отделами, где собрана соответствующая категория товаров. Такого рода специализированные представления информации, часто называют витринами данных. Создание хранилища данных и соответствующей инфраструктуры начинается с тщательного планирования и определения сроков работ. Первое - как уже говорилось выше - надо четко определить цели визуализации данных. Должна быть проанализирована отчетность компании. Целесообразно разбить отчетность на обязательную (предоставляемую в контролирующие органы) и внутрикорпоративную. Далее идет разделение по срокам (ежедневная, ежемесячная, ежеквартальная и т.д.). Внутрикорпоративная информация также разделяется по отделам (подразделениям) для создания витрин данных. Уже на этом этапе нужно выявить и избавиться по возможности от дублирования отчетности.

Итак, в рассмотренной теме курсовой работы можно выделить особенности:

1. Хранилища данных (Data warehouses) представляют собой предметно ориентированный, интегрированный, неизменный, поддерживающий хронологию набор данных, предназначенный для поддержки принятия решений.

2. Главное назначение хранилища - обеспечивать быстрое выполнение произвольных аналитических запросов.

3. Основными составляющими структуры хранилищ данных являются таблица фактов (fact table) и таблицы измерений (dimension tables).

4. Аналитические системы СППР позволяют решать три основных задачи: ведение отчётности, анализ информации в реальном времени (OLAP) и интеллектуальный анализ данных.

При помощи средств добычи данных можно проводить глубокие исследования данных. Эти исследования включают в себя: поиск зависимостей между данными; выявление устойчивых бизнес-групп; прогнозирование поведения бизнес-показателей; оценка влияния решений на бизнес компании; поиск аномалий.

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

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

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

Глоссарий