Витрины данных (Data mart)

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

Источником данных для витрин служат данные хранилища, которые, как правило, агрегируются и консолидируются по различным уровням иерархии. Детальные данные могут также помещаться в витрину или присутствовать в ней в виде ссылок на данные хранилища.

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

Различные витрины данных содержат разные комбинации и выборки одних и тех же детализированных данных хранилища. Важно, что данные витрины поступают из центрального хранилища данных.

Метаданные

Метаданные − это любые данные о данных. Метаданные играют важную роль в построении СППР. Одновременно это один из наиболее сложных и недостаточно практически проработанных объектов. В общем случае можно выделить по крайней мере три аспекта метаданных, которые должны присутствовать в системе.

1. С точки зрения пользователей:

метаданные для бизнес-аналитиков,

метаданные для администраторов,

метаданные для разработчиков.

2. С точки зрения предметных областей:

структуры данных хранилища,

модели бизнес-процессов,

описания пользователей,

технологические и пр.

3. С точки зрения функциональности системы:

метаданные о процессах трансформации,

метаданные по администрированию системы,

метаданные о приложениях,

метаданные о представлении данных пользователям.

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

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

База моделей

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

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

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

По цели использования модели подразделяются:

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

описательные, описывающие поведение некоторой системы и не предназначенные для целей управления (оптимизации).

По способу оценки модели классифицируются:

детерминистские, использующие оценку переменных одним числом при конкретных значениях исходных данных,

стохастические, оценивающие переменные несколькими параметрами, так как исходные данные заданы вероятностными характеристиками.

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

По области возможных приложений модели разбиваются:

специа­лизированные, предназначенные для использования только одной системой,

уни­версальные − для использования несколькими системами.

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

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

Стратегические модели используются на высших уровнях управления для установления целей организации, объемов ресурсов, необходимых для их достижения, а также политики приобретения и использования этих ресурсов. Они могут быть также полез­ны при выборе вариантов размещения предприятий, прогнозировании политики конкурен­тов. Для стратегических моделей характерны: значительная широта охвата, множество переменных, представление данных в сжатой агрегированной форме. Часто эти данные ба­зируются на внешних источниках и могут иметь субъективный характер. Горизонт плани­рования в стратегических моделях, как правило, измеряется в годах. Эти модели обычно детерминистские, описательные, специализированные для использования на одной опреде­ленной фирме.

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

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

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

Система управления базой моделей должна обладать следующими возможностями: создавать новые модели или изменять существующие, поддерживать и обновлять парамет­ры моделей, манипулировать моделями.

Что такое хранилище данных? Как правило, это база, в которой хранится вся масса информации по деятельности той или иной компании. Но нередко бывает нужным выделить из всего этого масштабного комплекса данные по одному направлению работы организации, подразделению, служебному вопросу. Здесь приходит на помощь иной тип хранилища - так называемые витрины данных. Что это, каковы ее достоинства, недостатки, разновидности, мы с вами будем рассматривать на протяжении статьи.

Что это?

Что такое витрины данных? Английский вариант - Data Mart. Существует несколько синонимов понятия:

• Специализированное хранилище
• Киоск данных.
• Рынок данных и проч.

Определимся с трактовкой термина "витрина данных":

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

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

Концепция хранилища

Идея создания витрин данных была предложена в 1991 году Forrester Research. Авторы представляли данное хранилище информации как определенное множество специфических баз данных, которые содержат в себе сведения, относящиеся к конкретным векторам деятельности корпорации.

Forrester Research выделяли следующие сильные стороны своего проекта - витрин данных:

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

Но те же Forrester Research говорили и о слабых сторонах своего изобретения:

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

Перейдем теперь к новой теме.

Конструирование витрин

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

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

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

Независимые витрины: примеры

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

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

• Витрина данных подразделения маркетинга. Включает в себя информацию о продуктах компании, ее клиентах, планах по продажам и проч.
• Витрина данных отделения продаж.
• ВД финансового отдела.
• ВД подразделения оценки рисков и прочее.

Достоинства независимых витрин

Давайте выделим ключевые преимущества витрин данных, которые найдены непосредственными создателями и пользователями:

• Максимально ориентированы на сотрудника, предоставляют ему только ту информацию, которая необходима при выполнении служебного задания.
• Значительно меньше "весят", нежели базы данных.
• Создание витрин - технологически легкий процесс (чем проектирование комплексных хранилищ данных). Кроме того, проще проходит и наполнение ВД, и работа конечных пользователей с ними.
• Содержат в себе агрегированную информацию по определенным тематикам.
• Достаточно быстрое внедрение витрин данных.
• Создание для ответов на конкретный ряд вопросов.
• Данные оптимизированы для использования определенным кругом пользователей. Это облегчает процедуру наполнения ВД, способствует увеличению производительности системы.

Недостатки независимых витрин

Давайте определимся с минусами витрин данных, которые выделяют пользователи и проектировщики:

Смешанная концепция

А что будет, если соединить между собой концепции витрин данных и хранилища данных? Таким вопросом задался в 1994 году М. Демарест. Именно он предложил объединить вышеуказанные концепции для дальнейшего использования хранилища (базы) данных в качестве интегрированного единого источника при проектировании витрин данных.

Данное решение объединяет в себе три уровня:

1. Общекорпоративная база данных, чья основа - реляционная СУБД (система управления базами данных). Имеет слабо денормализованную либо нормализованную схему (или детализированные данные).
2. База данных (БД) конкретного отдела, подразделения организации, конечного работника-пользователя. Реализуется уже на основе многомерной СУБД (агрегированных данных).
3. Рабочие места конечных сотрудников-пользователей, на которые непосредственно устанавливается аналитический инструментарий.

Данная многомерная структура со временем станет стандартной во многих компаниях. Главная причина того - объединение в ней достоинств двух подходов:

• Компактное хранение детализированной информации, поддержка масштабных баз данных, что реализуется на основе реляционных систем управления БД.
• Простая настройка, быстрый отклик на запрос пользователя при работе с агрегированной информацией на основе многомерных систем управления БД.

Достоинства трехмерных витрин

Плюсы данного типа ВД следующие:

• Упрощенное создание подобных витрин данных, так как они наполняются из стандартизированного надежного единого источника.
• ВД синхронизированы и совместимы с корпоративной БД.
• Сравнительно легкое расширение хранилища, возможность добавления новых витрин.
• Гарантия хорошей производительности системы.

Недостатки трехмерных витрин

Здесь также выделяется ряд минусов:

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

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

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

Для рассказа нам понадобится простой пример сложной задачи. Рассмотрим некий промышленный комплекс, обладающий огромным количеством оборудования, обвешанного различными датчиками и сенсорами, регулярно сообщающими сведения о его состоянии. Для простоты рассмотрим только два агрегата, котел и резервуар, и три датчика: температуры котла и резервуара, а также давления в котле. Эти датчики контролируются АСУ разных производителей и выдают информацию в разные хранилища: сведения о температуре и давлении в котле поступают в HBase, а данные о температуре в резервуаре пишутся в лог-файлы, расположенные в HDFS. Следующая схема иллюстрирует процесс сбора данных.

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

Способы хранения для данных разных типов зависят от их объема, структуры и требуемого режима доступа. В данном случае мы выбрали именно такие средства для создания «разнобоя», но и на реальных предприятиях чаще всего нет возможности свободно их выбирать – все зависит от сложившегося ИТ-ландшафта. Аналитической же системе нужно собрать весь «зоопарк» под одной крышей.

Пусть мы хотим предоставить аналитику возможность делать запросы такого типа:

• Какие единицы маслонаполненного оборудования работали при температуре выше 300 градусов за последнюю неделю?
• Какое оборудование находится в состоянии, выходящем за пределы рабочего диапазона?

Заранее построить и запрограммировать все подобные запросы не получится. Выполнение любого из них требует связывания данных из разных источников, в том числе из находящихся за пределами нашего модельного примера. Извне могут поступать, например, справочные сведения о рабочих диапазонах температуры и давления для разных видов оборудования, фасетные классификаторы, позволяющие определить, какое оборудование является маслонаполненным, и др. Все подобные запросы аналитик формулирует в терминах концептуальной модели предметной области , то есть ровно в тех выражениях, в которых он думает о работе своего предприятия. Для представления концептуальных моделей в электронной форме существует стек семантических технологий: язык OWL, хранилища триплетов, язык запросов SPARQL. Не имея возможности подробно рассказывать о них в этой статье, сошлемся на .

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

При взгляде на этот граф становится понятной схема выполнения запроса. Сначала нужно отфильтровать измерения температуры за заданный период со значением больше 400 0 C, и измерения давления со значением больше 5 мПа; затем нужно найти среди них те, которые выполнены сенсорами, установленные на одной и той же единице оборудования, и при этом выполнены одновременно. Именно так и будет действовать витрина данных.
Схема нашей системы будет такой:

Порядок работы системы таков:

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

Вся «магия», конечно, происходит внутри витрины. Перечислим принципиальные моменты.

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

2. В нашем примере данные одного и того же типа (измерения температуры) хранятся одновременно в двух разных источниках – HBase и текстовом файле HDFS. Однако для выполнения приведенного запроса обращаться к файлу не нужно, т.к. в нем заведомо нет полезной информации: ведь в файле хранятся измерения температуры резервуара, а давление в резервуарах не измеряется. Этот момент дает представление о том, как должен работать оптимизатор выполнения запросов.

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

4. В качестве источников данных могут выступать не только хранилища, но и сервисы. В нашем примере мы спрятали за сервисом расчет предпосылок к возникновению аварийного состояния при помощи одного из алгоритмов Spark MLlib. Этот сервис получает на вход информацию о состоянии устройства, и оценивает его с точки зрения наличия предпосылок к аварии (для обучения использованы ретроспективные данные о том, какие условия предшествовали реально случившимся авариям; в качестве исходных данных нужно рассматривать не только мгновенные значения физических характеристик устройства, но и элементы основных данных – например, степень его износа).
Эта возможность очень важна, так как позволяет аналитику самому выполнять запуск расчетных модулей, подготовленных программистами, передавая им на вход различные массивы данных. В этом случае аналитик будет работать уже не с исходными данными, а с результатами вычислений на их основе.

5. Аналитик строит запросы при помощи интерфейсов нашей Системы управления знаниями, среди которых – как несколько вариантов формального конструктора запросов, так и интерфейс поиска на контролируемом естественном языке. На следующем рисунке слева показана форма построения запроса на контролируемом языке, а справа – пример результатов другого запроса.

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

За рамками нашего рассказа осталось немало интересных моментов:

• как организован сбор данных сенсоров в HBase с помощью Flume;
• запросы к источникам данных могут выполняться не просто асинхронно, но даже при отсутствии онлайн-связи с ними – на этот случай предусмотрен специальный механизм передачи запроса и получения ответа;
• результаты выполнения запроса могут не просто выдаваться пользователю в виде таблицы или выгружаться в Excel, но и попадать напрямую в BI-систему в виде набора данных для дальнейшего анализа;
• способы конвертации идентификаторов и ссылок на объекты в разных источниках, вопросы транспорта сообщений между компонентами системы, и многое другое.

Разумеется, реальные промышленные применения витрины данных куда сложнее описанного примера. Нашей целью в этой статье была демонстрация того, что использование семантических технологий и концептуального моделирования в тандеме со средствами Big Data позволяет расширить число доступных аналитику способов использования данных, решать прикладные задачи в самых неординарных условиях. В сочетании с возможностями

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

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

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

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

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

Конец работы -

Эта тема принадлежит разделу:

Учебное пособие учебной Дисциплины Информационные технологии в профессиональной деятельности

Учебное пособие учебной ДИСЦИПЛИНЫ Информационные технологии в.. Разработчик к э н доцент Ярошенко Е В..

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ:

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Твитнуть

Все темы данного раздела:

Корпоративная информационная система
Решение управленческих задач на основе оперативной и достоверной информации при постоянном увеличении количества факторов, влияющих на работу предприятия и, одновременно, сокращении времени на прин

Методология планирования материальных потребностей предприятия. MRP системы
MRP (Material Requirement Planning)- Планирование потребности в материалах. Методология планирования потребности в материальных ресурсах (MRP) заключается

Системы планирования производственных ресурсов. MRP II системы
MRP II (Manufacturing Resource Planning) – Планирование производственных ресурсов. Основными целями MRP систем являются: удовлетворение потребности в материалах, компонент

Система планирования ресурсов предприятий. ERP система
ERP система (Enterprise Resource Planning System) – система планирования ресурсов предприятий. Новым этапом в развитии и внедрении систем управления предприятием, основанн

Разновидности ERP-систем
ERP представляет собой интегрированный программный продукт, позволяющий управлять дистрибуцией, логистикой, запасами, доставкой, бухгалтерским учётом. На российском рынке представлены все

CRM системы
CRM система (Customer Relationship Management System)– система управления взаимоотношениями с клиентами. Это современная стратегия, основанная на и

Цели, процессы, структура
Функциональность CRM охватывает маркетинг, продажи и сервис, что соответствуют стадиям привлечения клиента, самого акта совершения сделки (транзакция) и послепродажного обслуживания, то есть все те

Обзор CRM-решений в России
Если на западном рынке количество CRM-систем измеряется сотнями, то в России представлен довольно узкий спектр решений, в основном крупных поставщиков, давно предлагающих свои ERP-системы. В то же

SRM системы
SRM система (Supplier Relationship Management) – это системы управления отношениями с поставщиками. SRM система - инструмент укрепления отношений с поставщиками. Многие предприятия стараются повыси

Базы данных и хранилища данных
Часто в речи мы подменяет слово «информация» словом «данные». Между данными и информацией действительно существует тесная связь. Существование одного без другого невозможно. Преобр

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

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

Business Intelligence (BI)
Внедрение BI-технологий в различные программные продукты является новым и перспективным подходом к управлению данными и знаниями компании. Впервые о таком понятии, как «bus

Многомерный анализ данных на основе OLAP
Для решения аналитических задач, связанных со сложными расчетами, прогнозированием, моделированием сценариев «Что, если…» применяется технология многомерного анализа данных - Технол

Технология Data Mining
По данным компании Gartner, неструктурированные документы составляют более 80% корпоративных данных, а количество внешних источников (интернет-ресурсов, блогов, форумов, СМИ) исчисл

Типы закономерностей, которые позволяют выявлять методы Data Mining
Выделяют пять стандартных типов закономерностей, которые позволяют выявлять методы Data Mining: ассоциация, последовательность, классификация, кластеризация и прогн

Процесс принятия решений
Как принять правильное решение? Этот вечный вопрос мы задаём себе на протяжении всей жизни. И как часто принимаем решения в лучшем случае на основе интуиции. Методами рационального

Задачи принятия решения
Задача принятия решения имеет две главные разновидности: 1. задача выбора (выбрать или отвергнуть несколько вариантов из группы возможных) 2. задача распр

Технология принятия решения
При принятии решения все решения можно разделить на четыре большие группы: 1. решения, основанные на теории управления 2. решения, основанные на модели Карнеги (модель ограниченно

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

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

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

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

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

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

Реализация
Практическая разработка ЭС с использованием выбранных инструментальных средств: традиционных языков программирования, языков обработки списков и процедурных языков, языка логического программирован

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

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

Управление рисками ИТ-проекта
Управление рисками ИТ-проекта, в целом, включает следующие процессы: выявление и идентификацию предполагаемых рисков; анализ и оценку рисков; выбо