Хранилища данных Основы технологии хранилищ данных Технология

Хранилища данных Основы технологии хранилищ данных

Технология хранилищ данных (Data Warehouse) n n n Во всем мире организации накапливают или уже накопили в процессе своей деятельности большие объемы данных. Эти коллекции данных хранят в себе большие потенциальные возможности по извлечению новой, аналитической информации, на основе которой можно и необходимо строить стратегию фирмы, выявлять тенденции развития рынка, находить новые решения, обусловливающие успешное развитие в условиях конкурентной борьбы. Концепция хранилища данных была задумана как технология, способная удовлетворить требования систем поддержки принятия решений и базирующаяся информации, поступающей из нескольких различных источников оперативных данных. Хранилище данных Предметно ориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для поддержки принятия решений. 2

ХД - базовая технология современных СППР Data Mining Data Warehouse Средства интеллектуальной обработки данных технология Хранилищ данных OLAP технология оперативной аналитической обработки данных Перечисленные технологии не являются взаимонезависимыми и, как правило, используются совместно, дополняя друга специфическими свойственными каждой из них функциями. 3

ХД – важнейший компонент СППР Хранилище данных Средства конечного пользователя Поиск закономерностей Инфраструктура Инструменты извлечения, преобразования и очистки данных Инструменты администриро вания хранилища Инструменты Business Intelligence Приложения Business Intelligence Витрины данных 4

ХД – важнейший компонент СППР Системы поддержки принятия решений Аналитические приложения (BI) OLAP ИАД Имитац. Модел. Нечеткие Нейронны е сети множества Иерархия Reporting Эконометрика Хранилище (Data Warehouse) Интеллектуальные интерфейсы Системы планирования ресурсов (ERP) Корпоративные информационные системы (CIS) Клиент-серверные приложения ( «Тонкие клиенты» ) 5

Предпосылки создания технологии ХД n При обработке информации (финансовой, бухгалтерской, банковской, маркетинговой и др. ) традиционным является разделение существующих задач на два широких класса: ¨ № 1 операционная обработка данных ¨ № 2 анализ данных или задача принятия решений (ППР). n Они принципиально различны, требуют разных подходов к своему решению, но при этом взаимно дополняют друга. n Разные виды обработки данных требуют разного подхода к хранению и представлению данных 6

№ 1 Операционная обработка данных и транзакционные системы n n n Транзакционные Системы (ТС) системы или части информационных систем, ориентированные на операционную (системы операционной обработки данных), или транзакционную обработку данных; (ПРОИЗВОДЯТ КУЧУ МУСОРА ДАННЫХ) Транзакция – логически целостная операция по обработке данных, обеспечивающаяся последовательностью взаимно обусловленных (логически связанных) простых операций с данными. В базе данных транзакция предполагает цепочку логически связанных изменений данных. Учетные системы часто выполняют подобные цепочки операций, поэтому их часто называют транзакционными. К этому классу относятся любые автоматизированные бухгалтерские или банковские системы, которые осуществляют учет и хранение первичной информации по работе предприятия или банка; 7

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

Системы обработки транзакций в реальном времени (OLTP). n n Системы обработки транзакций в реальном времени называются Online Transaction Processing Systems (OLTP). Системы OLTP могут реализовываться на основе файл-серверных или клиент-серверных архитектур, имеют нормализованные реляционные структуры баз данных. Системы OLTP предназначены для автоматизации повседневных задач, решаемых персоналом «нижнего» звена финансовых органов, банков или других учреждений (учет платежей в бюджет, учет расходов бюджета, клиентов, договоров, заказов, взаиморасчетов, запасов и пр. ). Типичным примером OLTP – систем является « 1 С Бухгалтерия» . OLTP системы производят "горы" информации и соответственно оптимизированы на обработку больших объемов данных, выполнение сложных транзакций и интенсивных операций чтения/записи небольших порций данных. 9

№ 2 Задача анализа данных или задача принятия решений n n n Решением задач этого вида занимаются Аналитические системы. Аналитические Системы (АС) системы или составляющие части информационных систем, ориентированные на анализ данных. Их часто называют системами поддержки принятия решений (СППР) Основная цель помочь управляющему персоналу организации принять правильное и своевременное решение (в зарубежной литературе им соответствует термин DSS Decision Support System) 10

Каких систем больше транзакционных или аналитических? n n n В настоящий момент более распространены транзакционные учетные системы. Это обусловлено тем, что на первых этапах автоматизации требовалось и требуется навести порядок именно в процессах повседневной рутинной обработки (переработки) данных, на что и ориентированы традиционные Учетные системы. Более того, аналитические системы являются в определенном смысле вторичными по отношению к ним. Здесь возможна аналогия с производством. Любая продукция, прежде чем попасть на склад и быть отгруженной потребителю, должна быть сначала произведена. И прежде чем заниматься анализом данных, необходимо эти данные иметь (произвести). А именно это и является одной из функций учетной системы. 11

Что такое современная аналитическая система? n Это совокупность интеллектуальных информационных приложений и инструментальных средств, которые используются для манипулирования данными, их анализа и предоставления результатов такого анализа конечному пользователю. n ХД – большая «куча мусора» в которой ищатся модели закономерностей инструментами BI (Business intelligence) 12

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

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

Недостатки OLTP систем с точки зрения решения задач анализа При попытке обеспечить информационную поддержку процесса анализа данных средствами транзакционных систем возникают ряд проблем: 1. Невозможность оперативного, получения информации по заранее нерегламентированным(непредусмотренным) запросам, т. е. новых появляющихся в темпе процесса аналитического осмысления пользователем данных; 2. Невозможность гибкого формирования представлений (способов отображения) данных, необходимых именно данному пользователю, которые бы обеспечили их эффективное восприятие и анализ; 3. Недостаточное количество ретроспективной (исторической) информации. В учетных системах данные хранятся за отчетный период, после чего помещаются в архив с целью ускорения работы учетной системы. 15

Невозможность получения необходимой информации в оперативном режиме n n Структура баз данных OLTP систем плохо приспособлена к выполнению аналитических запросов (выполнение сложного аналитического запроса к строго нормализованной базе данных требует объединения данных из большого количества таблиц и, как следствие, приводит к большим затратам времени на обработку запроса). Объединение данных из различных таблиц требует много вычислительных ресурсов, что приводит к замедлению работы учетной системы из – за конкуренции при выполнении аналитических запросов и запросов на выполнение трнзакций по учету новой информации, что нарушает нормальную работу учетной системы. 16

Нерегламентированные запросы n Аналитические задачи менее регламентированы (заранее не предсказуемы), чем задачи, для которых создавались используемые OLTP системы и требуют особого подхода и более гибких средств; n В процессе исследований данных у пользователя возникает множество новых запросов, появляющихся в темпе процесса аналитического осмысления пользователем запросов к системе; n Транзакционные системы, ограничиваются , как правило, набором фиксированных отчетов что не позволяет аналитику сделать сложный нерегламентированный запрос. 17

Недостаточное количество ретроспективной (исторической) информации n Очевидно, что чем больше информации вовлечено в процесс принятия решений, тем более обоснованное решение может быть принято. n В транзакционных системах, как правило, хранится или доступен лишь относительно небольшой объем информации за предыдущий период ( например за последний финансовый год). Старая информация архивируется и не доступна аналитику; 18

Ограниченные способности обработки и восприятия информации n Со временем становится очевидным, что по мере развития организации объем данных характеризующих её деятельность постоянно увеличивается, а по мере развития информационной системы усложняется и сама структура информации накапливаемой в ней. n Всё это в целом приводит к замедлению процесса построения традиционных отчетов настолько, что руководящий состав не успевает готовить на их основе соответствующие решения. n Кроме того, со временем для формирования правильных решений, учитывающих внешние факторы, возникает потребность вовлекать в процесс анализа данные из внешних источников. n Все это предъявляет специальные требования к инструментам и способам представления анализируемой информации. 19

Почему нельзя использовать традиционные БД в процессе принятия решений? n n n недостоверность данных; низкая производительность при нестандартных запросах; невозможность преобразования разнородных данных, так как они часто не имеют меток времени. Проблемы при подготовке отчетов возникают из за того, что: n трудно понять, где находятся данные, необходимые для анализа и принятия решения; n большинство БД ориентировано только на стандартные запросы; n нужно привлекать программистов для выполнения нестандартных запросов. 20

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

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

Вывод n Объективно существует необходимость в специальной технологии (ХД), позволяющей автоматически собирать данные из различных источников данных, систем обработки данных, согласовывать и объединять в предметно ориентированный формат, который нужен аналитикам. n Таким образом, можно сказать, что технология хранилищ данных — это технология управления данными и их анализа. 23

Отличия в требованиях к БД и ХД Традиционные данные, хранимые в БД Данные для принятия решений Детализированы Обобщены либо очищены Точны в момент доступа Представляют значения на указанное время Могут корректироваться Не корректируются, если введены в Хранилище Требования к способам дальнейшей обработки выясняются заранее Требования к способам дальнейшей обработки не имеют первостепенного значения Строятся на основе обычного цикла разработки систем Совершенно иной цикл разработки систем Чувствительны к производительности БД и поэтому предъявляют к ним жесткие требования Мягкие требования к производительности БД 24

Отличия в требованиях к БД и ХД Обрабатывается один данных за один запрос элемент Обрабатывается множество элементов данных за один запрос Управляются транзакциями Управляются аналитическими запросами Ориентированы на приложения Ориентированы на анализ Высокая степень доступности Относительная доступность Контролируется целостность всех данных Контролируется целостность подмножества данных Данные не избыточны Данные избыточны Статическая структура, произвольное содержание Гибкая структура Массивы данных редко используются в процессе Массивы данных широко используются в процессе обр-ки Поддерживают ежедневные операции Поддерживают периодический анализ 25

Основные требования к ХД n ХД должно быть: ¨ предметно ориентированным, интегрированным, ¨ предназначенным для поддержки принятия решений. ¨ n n Хранилище представляет собой среду накопления данных, которая оптимизирована для выполнения сложных аналитических запросов управленческого персонала. Эти запросы могут быть достаточно индивидуальны для каждой организации, каждого подразделения и даже отдельного аналитика. 26

Особенности организации информации в ХД: 1. предметная ориентированность; 2. интегрированность (целостность и внутренняя взаимосвязь); 3. временная привязка; 4. неразрушаемая совокупность данных. 27

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

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

Интегрированность (целостность и внутренняя взаимосвязь) n Несмотря на то что данные в ХД подгружаются из различных источников, они должны быть объединены едиными законами именования, способами измерения атрибутов и др. n Это имеет большое значение для организаций, в которых одновременно могут эксплуатироваться различные по своей архитектуре вычислительные системы, представляющие одинаковые данные по разному. n Например, могут использоваться несколько различных форматов представления дат или один и тот же показатель может называться по разному, например, "вероятность доведения информации" и "вероятность получения информации". В процессе загрузки данных подобные несоответствия устраняются автоматически; 30

Временная привязка n Оперативные системы охватывают небольшой интервал времени, что достигается за счет периодического архивирования данных. n ХД, напротив, содержит исторические данные, накопленные за большой интервал времени (пять—семь лет); n Данные в хранилище всегда напрямую связаны с определенным периодом времени. n Данные, выбранные их оперативных БД, накапливаются в хранилище в виде "исторических слоев", каждый из которых относится к конкретному периоду времени. Это позволяет анализировать тенденции в развитии бизнеса. 31

Неизменяемость n Это означает, что данные не обновляются в оперативном n n n режиме, а лишь регулярно пополняются за счет информации из оперативных систем обработки. При этом новые данные никогда не заменяют прежние, а лишь дополняют их. Таким образом, база данных хранилища постоянно пополняется новыми данными, последовательно интегрируемыми с уже накопленной информацией. Попав в определенный "исторический слой" хранилища, данные уже никогда не будут изменены. Это также отличает хранилище от оперативной БД, в которой данные все время меняются, "дышат", и один и тот же запрос, выполненный дважды с интервалом в 10 минут, может дать разные результаты. Стабильность данных также облегчает их анализ. 32

Прочие особенности ХД n n ОБЪЕМЫ. Хранилища данных содержат информацию, собранную из нескольких оперативных баз данных. Размер ХД на порядок больше оперативных баз, зачастую имея объем от сотен гигабайт до нескольких терабайт. ПОДДЕРЖКА. Хранилище данных поддерживается независимо от оперативных баз данных организации, поскольку требования к функциональности и производительности аналитических приложений отличаются от требований к транзакционным системам. СПЕЦИАЛИЗАЦИЯ. Хранилища данных создаются специально для приложений поддержки принятия решений и предоставляют накопленные за определенное время, сводные и консолидированные данные, которые более приемлемы для анализа, чем детальные индивидуальные записи. СЛОЖНЫЕ ЗАПРОСЫ. Рабочая нагрузка состоит из нестандартных, сложных запросов, которые обращаются к миллионам записей и выполняют огромное количество операций сканирования, соединения и агрегирования. Время ответа на запрос в данном случае важнее, чем пропускная способность. 33

Компонентная архитектура хранилища данных Система автоматизации. исп. Бюджета «Бюджет КС» Инструменты генерации отчетов и разработки приложений Менеджер загрузки СУБД Отчеты исполнения «Казначейство» Мене джер храни лища Глубоко агрегированные данные Агрегированные данные Детальные данные Мене джер храни лища Инструменты OLAP Метаданные Гос. Комитет по статистике Менеджер запросов Инструменты «раскопки» данных Data maining Хранилище Предметноориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для поддержки принятия решений. 34

Менеджер загрузки и м. хранилища n Менеджер загрузки (load manager), который часто называют внешним, (front end) компонентом, выполняет все операции, связанные с извлечением и загрузкой данных в хранилище. Эти операции включают простые преобразования данных, необходимые для их подготовки к вводу в хранилище. n Менеджер хранилища выполняет такие операции, как: ¨ ¨ ¨ анализ непротиворечивости и очистка данных; преобразование и перемещение исходных данных из временного хранилища в основные таблицы хранилища данных; создание индексов и представлений для базовых таблиц; денормализация данных (в случае необходимости); обобщение данных (в случае необходимости); резервное копирование и архивирование данных. 35

Средства доступа к данным n Пользователи взаимодействуют с хранилищем с помощью специальных инструментов доступа к данным. Само хранилище данных должно обеспечивать эффективное выполнение произвольных запросов и предоставлять средства проведения анализа. n Пользовательские инструменты доступа к данным можно разбить на пять основных групп: ¨ ¨ ¨ инструменты создания отчетов и запросов; инструменты разработки приложений; инструменты информационной системы руководителя (Executive Information System — EIS); инструменты оперативной аналитической обработки (OLAPинструменты) инструменты разработки данных. 36

Классификация инструментов доступа по уровню возможностей анализа или получаемых даннных Инструменты доступа к данным Уровни получаемых знаний Язык запросов и генерации отчетов Поверхностный Оперативная аналитическая обработка Неглубокий Data mining Скрытый 37

Средства доступа к данным n n Инструменты создания отчетов и запросов. Инструменты создания отчетов подразделяются на инструменты создания итоговых отчетов и редакторы отчетов. Инструменты создания итоговых отчетов используют для создания регулярных отчетов. Редакторы отчетов — это недорогие настольные инструменты, предназначенные для нужд конечных пользователей. Инструменты создания запросов в реляционных СУБД служат для ввода или генерации SQL команд, используемых для извлечения данных из хранилища. Подобные инструменты обычно скрывают от конечных пользователей сложность операторов языка SQL и структур баз данных — за счет вставки между пользователем и базой данных промежуточного метауровня. Метауровень — это программное обеспечение, которое предоставляет пользователю некоторое предметно ориентированное представление содержимого базы данных и позволяет генерировать SQL операторы с помощью визуальных инструментов типа "выбери и щелкни". 38

Средства доступа к данным n n Инструменты разработки приложений. Для обеспечения доступа пользователей к требуемой информации может потребоваться разработка собственных приложений с использованием графических сред доступа к данным, предназначенных для использования в системах архитектуры "клиент/сервер". Инструменты информационной системы руководителя. Информационные системы руководителя (Executive Information System — EIS), которые в последнее время стали называть "информационными системами для всех" (Everybody Information System — EIS), первоначально разрабатывались для поддержки принятия высокоуровневых стратегических решений. Однако впоследствии область применения этих систем была несколько расширена с целью предоставления поддержки управляющему персоналу всех уровней. 39

Средства доступа к данным n OLАР-инструменты. Инструменты оперативной аналитической обработки данных, или OLAP инструменты, создаются на основе концепции многомерной базы данных. n При использовании подобных инструментов предполагается, что данные организованы согласно многомерной модели, которая поддерживается специальной многомерной базой данных (Multi Dimensional Database — MDDB) или реляционной базой данных, предназначенной для работы с многомерными запросами. n Подробно OLAP инструменты будут рассмотрены далее. 40

Средства доступа к данным n Инструменты раскопки данных (добычи знаний) data mining. Добыча знаний — это процесс открытия новых осмысленных корреляций, распределений и тенденций путем переработки огромного количества информации извлеченной из хранилища данных, с использованием статистических и математических методов, а также методов искусственного интеллекта. n Методы добычи знаний обладают достаточным потенциалом, так как главным притягательным фактором использования технологии добычи знаний является способность создавать предсказательные, а не ретроспективные модели. n Обзор методов добычи данных будет дан далее. 41

Управление метаданными, репозиторий Метаданные — информация любого рода, которая требуется для управления хранилищем данных. Управление метаданными — важная составляющая процесса поддержки ХД. n Административные метаданные относится вся информация, которая требуется для настройки и использования хранилища данных. n Бизнес-метаданные включают в себя бизнес термины и определения, принадлежность данных и правила оплаты услуг хранилища. n Оперативные метаданные — это информация, собранная во время работы хранилища данных, такая как происхождение перенесенных и преобразованных данных; статус использования данных (активные, архивированные или удаленные); данные мониторинга, такие как статистика использования, сообщения об ошибках и результаты аудита. n Метаданные хранилища часто размещаются в репозитории, который позволяет совместно использовать метаданные различным инструментам и процессам при проектировании, установке, использовании, эксплуатации и администрировании хранилища. 42

Виды данных в хранилище n n n Детальные данные. В этой части хранилища данных хранятся все детальные данные, описанные в схеме базы данных. В большинстве случаев детальные данные хранятся не на оперативном уровне, а в виде информации, обобщенной до следующего уровня детализации. Как правило, детальные данные периодически добавляются в хранилище с автоматическим выполнением обобщения исходной информации до необходимого уровня. Частично и глубоко обобщенные данные. В этой области хранилища размещаются все данные, предварительно обработанные менеджером хранилища с целью их частичного или глубокого обобщения (aggregate). Назначение обобщенных данных состоит в повышении производительности запросов. Хранимые обобщенные данные обновляются по мере загрузки новых порций детальных данных в хранилище. 43

Проблемы хранилищ данных 1. 2. 3. 4. 5. 6. 7. 8. Недооценка ресурсов, необходимых для загрузки данных; Скрытые проблемы источников данных; Отсутствие требуемых данных в имеющихся архивах; Гомогенизация (однородность) данных; Высокие требования к ресурсам; Владение данными; Сложное сопровождение; Долговременный характер проектов; 44

Недооценка ресурсов, необходимых для загрузки данных n Многие разработчики склонны недооценивать время, необходимое для извлечения, очистки и загрузки данных в хранилище. n На выполнение этого процесса может потребоваться по данным источников до 80% общего времени разработки, хотя эту долю можно существенно сократить при использовании более совершенных инструментов очистки и сопровождения данных. 45

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

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

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

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

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

Сложности сопровождения n Хранилища данных обычно характеризуются сложностью сопровождения, поскольку любая реорганизация бизнес процессов или источников данных может повлиять на происходящие в них процессы. n Для того чтобы хранилище данных всегда оставалось Ценным ресурсом, необходимо, чтобы оно постоянно полностью соответствовало организации, работу которой оно поддерживает. 51

Долговременный характер проектов n Хранилище данных представляет собой единый информационный ресурс организации. n Однако для его создания может потребоваться несколько лет (бывает до 2 3), а потому многие организации строят также свои собственные витрины данных (будут рассмотрены ниже). n Магазины данных (data marts) предназначены для поддержки работы только какого то одного подразделения организации или одной ее прикладной области, а потому создать их можно гораздо быстрее. 52

Преимущества создания ХД При успешной реализации хранилища данных в организации могут быть достигнуты следующие преимущества: Потенциально высокая отдача от инвестиций; ¨ Повышение конкурентоспособности; ¨ Повышение эффективности труда лиц, ответственных за принятие решений; ¨ 53

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

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

Варианты архитектуры ХД 1. Классическая концепция (Corporate Information Factory (CIF)) Билл Инмон (Bill Inmon) 2. Виртуальное хранилище данных 56

Архитектура ХД (Билла Инмона) «Corporate Information Factory (СIF)» n n n Когда то этот подход был известен под названием корпоративного Хранилища данных (enterprise data warehouse, сокр. EDW). Скоординированное извлечение данных из источников. Загрузка реляционной базы данных, состоящей из таблиц в третьей нормальной форме, содержащей атомарные данные. Получившееся нормализованное Хранилище используется для того, чтобы наполнить информацией дополнительные репозитории презентационных данных, т. е. данных, подготовленных для анализа. Эти репозитории, в частности, включают специализированные Хранилища для изучения и "добычи" данных (Data Mining), a также витрины данных. 57

Архитектура ХД (Билла Инмона) «Corporate Information Factory (СIF)» n n n Скоординированное извлечение данных из источников. Накопление данных в централизованном хранилище Многомерный анализ данных в витринах 58

Архитектура – «виртуальное ХД» n В данном случае в отличие от классического ХД (физического) данные из оперативных источников данных (ОИД) не копируются в единое хранилище. n Они извлекаются, преобразуются и интегрируются непосредственно при выполнении аналитических запросов в оперативной памяти компьютера. Фактически такие запросы напрямую адресуются к опер. ИД 59

UDM от SQL 2005 и вируальные ХД n Поддержка архитектуры виртуального ХД достигается благодаря новой возможности SQL Server 2005 поддержке унифицированной модели измерений (UDM). n UDM позволяет получать BI данные непосредственно от OLTP систем так, чтобы чрезмерно не нагружать эти системы. В результате отпадает необходимость в витринах данных. n Новизна архитектуры UDM привела к появлению набора возможностей, предлагающих пользователям ряд преимуществ по сравнению с традиционными реализациями OLAP. Эти преимущества в значительной степени устраняют проблемы и недостатки, зачастую связанные с реализацией бизнес аналитики 60

UDM от SQL 2005 и виртуальные ХД n n UDM позволяет строить OLAP кубы непосредственно на основе данных транзакций. UDM не требует использования в качестве источника данных витрины данных со схемой звезды или снежинки. Годится любая нормально структурированная реляционная база данных. 61

Достоинства архитектуры – «виртуальное. ХД» n Минимизация объема памяти, занимаемой на носителе информацией; n Работа с текущими, детализированными данными. n Исключительно малое время запаздывания n Строя OLAP систему непосредственно на базе OLTP системы, можно устранить большую часть причин запаздывания данных, присущих хранилищам данных. По сути дела, мы можем полностью (или почти полностью) добиться работы в реальном времени. Тем не менее нужно стремиться найти баланс между потребностями оперативной бизнес аналитики и нагрузкой на OLTP системы. Если доступны соответствующие вычислительные мощности, то наряду с легкостью работы в созданной среде достигается и оперативность. 62

Достоинства архитектуры – «виртуальное. ХД» n Простота создания и обслуживания n Архитектура UDM устраняет большую часть сложностей, возникающих в большинстве OLAP проектов. n UDM позволяет избавиться от необходимости создания и поддержания витрин данных, равно как и от сопровождающих их процедур извлечения, трансформации и загрузки данных. Уже только это делает создание решений на основе UDM на порядок проще, чем при использовании других OLAP архитектур. 63

Недостатки архитектуры виртуального ХД n n Время обработки запросов агрегатов к виртуальному ХД значительно больше соответствующих показателей для физического хранилища. Для интегрированного взгляда на виртуальное хранилище неоходима постоянная готовность всех опер. ИД. Недоступность хотя бы одного из источников привести либо к невыполнению аналитических запросов, либо к неверным результатам. На один и тот же вопрос может быть получено несколько вариантов ответа. Это может быть связано с несинхронностью моментов обновления данных в разных ОИД, отличиями в описании одинаковых объектов и событий предметной области, ошибками при вводе, утерей фрагментов архивов и т. д. Главным же недостатком виртуального хранилища является невозможность получения данных за долгий период времени. При отсутствии физического хранилища доступны только те данные, которые на момент запроса есть в ОИД. Основное назначение OLTP систем — оперативная обработка текущих данных, поэтому они не ориентированы на хранение данных за длительный период времени. По мере устаревания данные выгружаются в архив и удаляются из оперативной БД. 64

Когда невозможно использовать виртуальное ХД ? 65

Недостатки архитектуры виртуального ХД n Отсутствие физического соединения n В других случаях данные могут находиться в базе ОLTP данных, способной работать с провайдером OLE DB, но полноценное подключение и возможность использования BI данных отсутствуют. Подключение к UDM требует поддержки соединений OLE DB. Если такая поддержка отсутствует, то, опять же, нам необходимо настроить витрину данных, которая будет служить хранилищем этих данных там, где требуется бизнес аналитика. n Конечно, нужен какой нибудь способ переноса экспортированного файла от базы OLTP данных в витрину данных, чтобы его можно было импортировать, что может подразумевать FTP передачу через модемное соединение, копирование экспортированного файла на архивную ленту или запись файла на DVD R с последующей транспортировкой диска из одного места в другое. Однако как бы ни передавались данные, они в любом случае попадают в витрину данных с помощью служб интеграции. 66

Недостатки архитектуры виртуального ХД n Данные сторонних источников n В некоторых случаях данные, необходимые для бизнес аналитики, находятся даже не в базе данных: рабочая информация от автомата на производственной линии может записываться в текстовый файл, звонки в потребительскую службу могут записываться в XML файл, а данные заказов могут вообще храниться исключительно в печатном виде. n Опять таки, в подобной ситуации данные перед использованием в UDM необходимо импортировать в витрину данных. Текстовые файлы и XML файлы могут импортироваться службами интеграции непосредственно. Бумажные копии должны сканироваться или вручную переводиться в электронный формат, который можно импортировать в витрину данных. 67

Недостатки архитектуры виртуального ХД n Грязные данные n Витрины данных могут также потребоваться в ситуации с грязными данными. Если данные в OLTP системах содержат ошибки, рассогласования или дублирующиеся записи, то перед использованием таких данных в качестве источника точной информации для бизнес аналитики их следует очистить. Из за ограничений OLTP систем возможность адекватной очистки данных в базе OLTP Данных может не поддерживаться. Вместо этого данные должны экспортироваться из OLTP системы и очищены службами интеграции при импорте данных в витрину данных. 68

Недостатки архитектуры виртуального ХД n Унаследованные базы данных n Чтобы подключаться к OLTP системам, источникам данных для UDM требуются провайдеры OLE DB. При создании источников данных может применяться несколько провайдеров OLE DB, однако для некоторых систем управления базами данных соответствующие провайдеры OLE DB не предусмотрены. Точнее, некоторые системы (в особенности устаревшие) вообще не предоставляют тот уровень доступа к данным, который необходим для провайдера OLE DB. n В подобных ситуациях данные из унаследованной системы необходимо экспортировать и копировать в базу, которая может работать с UDM, — витрина данных как раз и становится такой базой. Формат экспортируемых из унаследованной системы данных должен быть таким, чтобы данные затем можно было импортировать в витрину данных. Обычно для этого служат текстовые файлы определенного вида, в которых используются разделители данных или столбцы фиксированной ширины; возможно также применение XML файлов. 69

1. Витрины данных, как обособленная (специализированная) часть ХД n Поскольку конструирование хранилища данных — сложный процесс, который может занять несколько лет, некоторые организации вместо этого строят витрины данных (data mart), содержащие информацию для конкретных подразделений. n Например, маркетинговая витрина данных может содержать только информацию о клиентах, продуктах и продажах и не включать в себя планы поставок. n Несколько витрин данных для подразделений могут сосуществовать с основным хранилищем данных, давая частичное представление о содержании хранилища. n Витрины данных строятся значительно быстрее, чем хранилище, но впоследствии могут возникнуть серьезные проблемы с интеграцией, если первоначальное планирование проводилось без учета полной бизнес модели. 70

2. Витрины данных (вид ХД) , как промежуточная часть ХД. n Витрина данных (data mart) — это набор данных за определенный период времени, хранящихся в электронном хранилище и не использующихся в повседневной деятельности организации. n Вместо этого данные применяются для решения BI—задач, как промежуточное место хранения информации извлеченной из OLTP систем. Данные, находящиеся в витрине, обычно относятся к конкретной области деятельности организации. 71

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

Особенности организации витрин данных n n Консолидация и очистка. В витрине данных могут быть объединены данные сразу нескольких OLTP—систем. Это позволяет вычислять сложные аналитические меры, но, как уже отмечалось, может привести к ряду проблем. В разных OLTP—системах могут использоваться разные способы представления данных. Для представления одних и тех же данных могут применяться несовместимые типы данных; для представления одной и той же сущности — разные уникальные идентификаторы, а наличие различных временных и календарных схем может привести к сложностям при объединении данных из разнородных систем. Очистка данных (data cleansing) означает удаление несоответствий и ошибок в данных транзакций и делает их пригодными к переносу в витрину данных. В ходе очистки данные переводятся в формат, который не приведет к возникновению проблем в среде витрины данных, а несоответствующие типы данных приводятся к единому типу; различающиеся идентификаторы — к единому набору кодов, используемому в витрине данных. Помимо этого, при очистке производится исправление или удаление данных, не соответствующих бизнес—правилам, применяемым при вычислении мер, заданных для хранилища. 73

Модели структуры данных ХД n Логическая модель ¨ «Многомерный n куб» (гиперкуб) dimensional Физическая модель ¨ «Звезда» ¨ «Снежинка» 74

Особенности проектирования многомерной модели данных n Моделирование Dimensional сходно с моделированием связей и сущностей для реляционной модели, но отличаются целями. n Реляционная модель акцентируется на целостности и эффективности ввода данных. n Многомерная (Dimensional) модель ориентирована в первую очередь на выполнение сложных аналитических запросов к БД. 75

Особенности физической модели ХД Денормализация структуры РБД n n n Нормализация данных в реляционных СУБД приводит к созданию множества связанных между собой таблиц. В результате, выполнение сложных запросов неизбежно приводит к объединению многих таблиц, что существенно увеличивает время отклика. Создание хранилища данных подразумевает создание денормализованной структуры данных (допускается избыточность данных и возможность возникновения аномалий при манипулировании данными), ориентированной в первую очередь на высокую производительность при выполнении аналитических запросов. Нормализация делает модель хранилища слишком сложной, затрудняет ее понимание и ухудшает эффективность выполнения запроса. 76

Денормализованные, пространственные модели ХД на основе РБД n Одним из направлений развития РБД для систем принятия решений является разработка таблиц с денормализованной структурой (схемы «звезда» и «снежинка» ). n Структура такой базы данных не будет чисто реляционной это будет пространственная база данных, построенная с целью анализа данных, а не оптимзации выполнения транзакций и занимаемого места на носителях данных. 77

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

Основные составляющие схемы «звезда» n Схема звезда обычно содержит одну большую таблицу, называемую таблицей фактов (fact table), помещенную в центр, и окружающие ее меньшие таблицы, называемые таблицами размерности (dimensional table), соединенные с таблицей факта в виде звезды радиальными связями. В этих связях таблицы размерности являются родительскими, таблица факта дочерней. n Схема звезда может иметь также консольные таблицы (outrigger table), присоединенные к таблице размерности. Консольные таблицы являются родительскими, таблицы размерности дочерними. 79

Схема данных «Звезда» Таблица фактов Таблица размерности 80

Схема данных «Звезда» Таблица фактов Таблица размерности 81

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

Схема данных «Снежинка» Консольная таблица Таблица фактов Таблица размерности 83

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

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

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

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

Таблица фактов 88

Многомерный куб с несколькими таблицами фактов 89

Разновидности фактов n факты, связанные с транзакциями (Transaction facts). основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата); n факты, связанные с «моментальными снимками» (Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка; n факты, связанные с элементами документа (Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки); n факты, связанные с событиями или состоянием объекта (Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей). 90

Степень детализации фактов n Для многомерного анализа пригодны таблицы фактов, содержащие как можно более подробные данные (то есть соответствующие членам нижних уровней иерархии соответствующих измерений). n В данном случае предпочтительнее взять за основу факты продажи товаров отдельным заказчикам, а не суммы продаж для разных стран — последние все равно будут вычислены OLAP средством. Обобщенные данные будут вычислены. 91

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

Иерархическая структура измерений География (ОКАТО) Всё Иерархия измерения Всё «Время» Страны Годы Области Кварталы Районы Города Месяцы Дни

Иерархическая структура в ХД Артемьевски й р н 2 уровень (районы) Прогноз по району 1 уровень Корр. 1 Корр. 3 (Предприяти я) Корр. 2 Прогнозы по корр. НД Прогноз по 2 уровень С группе (группы доходов налогов) 1 уровень Прогноз по (налоги) НДС отдельным НДС 3 1 доходам

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

Медленно меняющиеся измерения (Slowly Changing Dimensions) в хранилище данных Бизнес аналитики, как основные пользователи корпоративного хранилища данных, нуждаются в отслеживании изменений значений атрибутов аналитических измерений. Например, смена организационно правовой формы собственника может привести к пересмотру стратегии кредитования клиента банка. Отслеживание изменений значений аналитических измерений в хранилище данных решается путем применения механизма медленно меняющихся измерений (Slowly Changing Dimensions, SCD). 96

Общий принцип отслеживания изменений Медленно меняющиеся измерения в базе данных реализуются в виде обычных таблиц, в которые добавляется ряд служебных столбцов, позволяющий реализовать логику отслеживания изменений данных. Для всех типов медленно меняющихся измерений принцип работы с записями основывается на предварительном определении действия, производимого с записью (вставка, изменение, удаление), и последующей логике обработки записи в зависимости от производимого с ней действия. Обычно реализация медленно меняющихся измерений производится в подсистеме ETL корпоративного хранилища данных, а определение статуса записи производится в момент захвата изменений данных. ETL (от англ. Extract, Transform, Load — дословно «извлечение, преобразование, загрузка» ) — один из основных процессов в управлении хранилищами данных, который включает в себя: извлечение данных из внешних источников; их трансформация и очистка. 97

В зависимости от действия, производимого с записью (вставка, изменение, удаление), для записи может быть определен один из следующих статусов: n На добавление запись новая и её необходимо добавить в таблицу. n На изменение – запись существует в таблице, но в каких то полях изменились содержимое. n На удаление запись существует в таблице, но теперь её необходимо удалить из неё. 98

SCD Type 1 К медленно меняющимся измерениям первого типа относятся те измерения, в которых не поддерживается отслеживание изменений данных во времени, т. е. значения полей записей в случае их изменения просто обновляются. Действия, производимые с записями таблицы SCD Type 1 в зависимости от их статуса, представлены в таблице. Статус записи Действие На добавление Записи присваивается следующий по порядку уникальный идентификатор. Запись добавляется в таблицу. На изменение Запись изменяется. На удаление Никаких действий над записью не производится. Удалять запись из таблицы нельзя, потому что к ней могут быть «привязаны» фактические данные. 99

Пример отслеживания изменений для случая, когда изменяется содержимое одного из полей записи. Таблица, в которой хранится информация по клиентским данным (CST), состоящая из 2 х полей: ID – первичный ключ записи и NAME – наименование клиента. ID NAME 1 ИП Иванов В случае изменения существующего наименования «ИП Иванов» на «ООО "Иванов и Ко. "» запись в таблице изменится следующим образом: ID NAME 1 ООО "Иванов и Ко. " 100

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

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

2. Кубы данных – оперативная аналиическая обработка (OLAP) (многомерная модель данных) 103

Понятие многомерной модели данных «Гиперкуб» n Гиперкуб OLAP это структура, в которой хранятся совокупности данных, полученные из базы данных OLAP путем всех возможных сочетаний значений измерений с фактами в таблице фактов. n Исходя из этого, создание окончательного отчета выполняется гораздо эффективнее, поскольку не требует выполнения никакого сложного запроса. 104

Пример гиперкуба для бюджетного процесса Факт доходы в доходную часть бюджета может определяться: n ¨ ¨ ¨ n датой поступления платежа (время), кодом дохода (классификатор доходов), плательщик данного платежа ПОЛУЧЕННАЯ СУММА = f(ВРЕМЯ, КОД ДОХОДА, ПЛАТЕЛЬЩИК) 105

Логическая модель «Многомерный гиперкуб» n В основе модели OLAP лежит понятие гиперкуба, или многомерного куба данных, в ячейках которого хранятся анализируемые (числовые) данные. n В многомерной модели измерения (dimensions) соответствуют осям куба, а анализируемые переменные(меры) (measures) или показатели – индивидуальным ячейкам куба. n Многомерная модель позволяет делать плоские срезы куба данных и поворачивать его нужной гранью любым удобным нам образом. n Используя многомерную модель, аналитик может легко получить представление данных в соответствии с собственными интересами. 106

Основные составляющие логической модели «Многомерный гиперкуб» n Данные, в гиперкубе, можно поделить на четыре категории: меры, ¨ измерения, ¨ атрибуты, ¨ ¨ n иерархии. Эти типы данных помогают определить логическую структуру витрины данных. 107

Доходы бюджета Логическая модель «Многомерный гиперкуб» Показате ли (меры) Измерени я Агрегаты Налоговые доходы 12 98, 3 НДФЛ 32, 4 Налог на прибыль 25 12, 8 Истринский р н Егорьевский р н Артемьевский р н НДС О (к КА ор Т ре О сп. ) февраль март январь апрель T (время) 1 кв. Агрегаты 108

Меры (показатели) n Мера — это основа бизнес—аналитики. По сути дела, без мер бизнес—аналитики бы просто не было. n Мера (measure) — это численное значение(числовой показатель), выражающее определенный аспект деятельности организации. Показатель это величина (обычно числового типа), которая собственно и является предметом анализа. Один OLAP куб может обладать одним или несколькими n n показателями. n Информация, представляемая этим значением, используется для принятия решения или оценки эффективности работы организации. 109

Меры (показатели) n Меры также называют фактическими значениями, или просто фактами. n Меры — это фактические значения, используемые в базовой и возвратной информации, поэтому таблицы, содержащие данные мер, называются таблицами фактов. n Однако таблицы содержать отнюдь фактические значения. фактов не могут только 110

Ячейка n Ячейка (cell) атомарная структура куба, соответствующая конкретному значению некоторого показателя. n Ячейки при визуализации располагаются внутри куба и здесь же принято отображать соответствующее значение показателя. 111

Измерения n n Измерение (dimension) — это способ ранжирования данных, используемый для разделения агрегированных мер на составляющие их части. Измерения позволяют ранжировать агрегированную меру. Ранжирование дает возможность видеть составные элементы агрегированных мер. Так, например, меру «суммы продаж» можно считать одиночной точкой информации. Для того чтобы развернуть эту меру «суммы продаж» , ее нужно ранжировать, используя измерения. Например общую сумму продаж можно разделить на суммы продаж за каждый год, месяцы, дни. 112

Измерения n n n Измерение (dimension) это множество объектов одного или нескольких типов, организованных в виде иерархической структуры и обеспечивающих информационный контекст числового показателя. Измерение принято визуализировать в виде ребра многомерного куба. Объекты, совокупность которых и образует измерение, называются членами измерений (members). Члены измерений визуализируют как точки или участи, откладываемые на осях гиперкуба. Например, временное измерение: Дни, Месяцы, Кварталы, Годы наиболее часто используемые в анализе, могут содержать следующие члены: 8 мая 2002 года, май 2002 года, 2 ой квартал 2002 года и 2002 год. Как уже было сказано, объекты в измерениях могут быть различного типа, например "производители" "марки автомобиля" или "годы" "кварталы". Эти объекты должны быть организованы в иерархическую структуру так, чтобы объекты одного типа принадлежали только одному уровню иерархии. 113

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

Агрегат ∑, среднее, количество и тд. n n Агрегат (aggregate) — это значение, вычисляемое по некоторому множеству детализированных записей. Агрегат зачастую представляет собой сумму множества чисел, хотя он также может вычисляться не суммированием, а выполнением каких—либо других арифметических операций или даже подсчетом числа элементов в группе. Так, итоговая сумма счетов, отправленных клиенту за выбранный год, является обобщенной (агрегированной) суммой счетов этого клиента за год. Средняя цена товара является агрегатом по группам товаров 115

Агрегат n n Агрегатами называют агрегированные по определенным условиям исходные значения показателей. Под агрегацией понимается любая процедура формирования меньшего количества значений (агрегатов) на основании большего количества исходных значений. В дальнейшем под терминами агрегирование и агрегация будем понимать не только процесс суммирования данных. Заблаговременное формирование и сохранение агрегатов с целью уменьшения времени отклика на пользовательский запрос является основным свойством систем поддержки оперативного анализа. 116

Атрибуты n n В некоторых случаях может потребоваться хранение дополнительной информации об измерениях в витрине данных. Такая дополнительная информация помогает более подробно описать измерения. Подобные включения дополнительной информации принято называть атрибутами измерения. Атрибут (attribute) — это дополнительный элемент информации, относящийся к измерению и не являющийся при этом уникальным идентификатором или описанием этого измерения. 117

Атрибуты n n n Атрибуты также служат для хранения информации, которая может применяться для ограничения или фильтрации записей, выбираемых из витрины данных в ходе анализа данных. Атрибуты хранятся в дополнительных столбцах таблиц измерений Например. «Покупатель» помимо номера может иметь атрибуты : Ф, И, О, телефон , которые можно использовать для отбора данных. 118

Иерархии в измерениях n Иерархии необходимы для определения порядка и возможности агрегации и детализации значений показателей n Иерархии применяются для организаций измерений в многоуровневые структуры. n Если меры определяют что хотят видеть аналитики, то измерения и иерархии определяют как они это хотят видеть. Существуют следующие типы иерархий: n Сбалансированные (balanced); n Несбалансированные (unbalanced); Неровные (balanced). n 119

Сбалансированные иерархии n n Это иерархии, в которых число уровней определено её структурой и неизменно, и каждая ветвь иерархического дерева содержит объекты каждого из уровней. Каждому производителю автомобилей может соответствовать несколько марок автомобилей, а каждой марке несколько моделей автомобилей, поэтому можно говорить о трёхуровневой иерархии этих объектов. В этом случае на первом уровне иерархии располагаются производители, на втором марки, а на третьем модели. n Как видно, для формирования сбалансированной иерархии необходимо наличие связи "один ко многим" между объектами менее детального уровня по отношению к объектам более детального уровня. В принципе каждый уровень сбалансированной иерархии можно представить как отдельное простое измерение, но тогда эти измерения окажутся зависимыми, в значит неизбежно повышение разреженности куба. 120

Несбалансированные иерархии n Это иерархии, в которых число уровней может быть изменено, и каждая ветвь иерархического дерева может содержать объекты, принадлежащие не всем уровням, только нескольким первым. n Необходимо заметить, что все объекты несбалансированной иерархии принадлежат одному типу. 121

Неровные иерархии n Это иерархии, в которых число уровней определено её структурой и постоянно, однако в отличие от сбалансированной иерархии некоторые ветви иерархического дерева могут не содержать объекты какого либо уровня. n Иерархии такого вида содержат такие члены, логические "родители" которых не находятся на непосредственно вышестоящем уровне. n Типичным примером является географическая иерархия, в которой есть уровни "Страны", "Штаты " и "Города", но при этом в наборе данных имеются страны, не имеющие штатов или регионов между уровнями "Страны" и "Города". 122

Архитектуры OLAP 123

Данные архитектуры различаются методами хранения кубов данных n многомерный OLAP формат (Multi dimensional OLAP MOLAP); n реляционный OLAP формат (Relational OLAP ROLAP); n гибридный OLAP формат (Hybrid OLAP HOLAP). 124

Данные архитектуры различаются методами хранения кубов данных 125

MOLAP n MOLAP является многомерным форматом хранения данных, который отличается высоким быстродействием. Помимо поддержки OLAP самих кубов данных при выборе данного формата данные будут храниться в многомерных структурах на OLAP сервере (OLAP структуры). n MOLAP обеспечивает наилучшее быстродействие выполнения запросов, поскольку этот формат специально оптимизирован для многомерных запросов к данным. 126

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

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

ROLAP n Реляционные хранилища OLAP содержат данные, передаваемые в кубы данных, вместе с агрегациями данных куба, причем данные хранятся в реляционных таблицах, размещенных в реляционном ХД. 129

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

Недостатки ROLAP n Главный недостаток ROLAP по сравнению с MOLAP — меньшая производительность. n Для обеспечения производительности, сравнимой с многомерными базами данных, необходимо использовать звездообразные схемы. В этом случае производительность реляционных систем может быть приближена к производительности систем на основе MOLAP. 131

HOLAP n n Гибридная архитектура, которая объединяет технологии ROLAP и MOLAP. В отличие от MOLAP, которая работает лучше, когда данные более плотные, серверы ROLAP лучше в тех случаях, когда данные довольно разрежены. Серверы HOLAP применяют подход ROLAP для разреженных областей многомерного пространства и подход MOLAP — для плотных областей. Серверы HOLAP разделяют запрос на несколько подзапросов, направляют их к соответствующим фрагментам данных, комбинируют результаты, а затем предоставляют результат пользователю. При использовании данного формата OLAP данные, передаваемые в куб данных, хранятся в реляционных базах данных подобно ROLAP. А агрегации данных (данные куба) записываются и представляются в многомерном формате. 132

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

Сравнительные характеристики Характеристика OLTP 1 2 Типовая Обновление Уровень аналитических операция Низкий требований ROLAP 3 Отчет Средний MOLAP 4 Анализ Высокий Неизменяе мые Определяемые пользователем Объем данных на Небольшой транзакцию Уровень данных Детальные От малого до большого Большой Детальные и суммарные Суммарные Историческ ие и текущие Записи Исторические, текущие и прогнозируемые отчеты Сроки хранения данных Текущие Структурные элементы Записи Определяемые пользователем Массивы 134

Достоинства OLAP: n n n n n простота использования и восприятия выходных таблиц; полнота аналитических данных; полная и легкая настройка отчета без программиста; возможность детализировать отчет в процессе анализа данных (от итогов к деталям); формирование отчетов в 10 раз быстрее; непротиворечивость данных в отчетах; консолидация информации из разных баз данных; повышенная защита данных; эквивалентность одного OLAP отчета целому набору простых отчетов. 135

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

Программные средства ХД n В настоящее время на рынке представлено большое количество OLAP систем, производимых разными фирмами: ¨ ¨ ¨ ¨ Oracle Express 6. 3, SQL Server 2005(и выше)Microsoft Analysis Services , Cognos Power. Play 6. 6, Cristal Analysis Holos 8. 5, Speedware Media, Applix i. TM 1 7, Hyperion Essbase 6. 1 и т. д. 137

SQL 2005 -Интегрированная платформа управления данными n n SQL Server 2005 представляет собой высокопроизводительную масштабируемую многофункциональную платформу, которая построена вокруг ядра, обеспечивающего работу реляционной базы данных, и включает большое количество сервисов. В целом система тесно интегрирована со всем комплексом ПО Microsoft, а сама СУБД и ряд ее сервисов, в свою очередь, являются ключевыми компонентами, обеспечивающими работу многих продуктов Microsoft. 138

SQL 2005 и выше- компоненты n реляционная база данных (Relation Database) безопасное, надежное, масштабируемое высокодоступное ядро с улучшенной производительностью, позволяющее работать как со структурированными, так и с неструктурированными (XML) данными, а также обеспечивающее поддержку. NET CLR (создание хранимых процедур, функций и триггеров на управляемом коде) и ADO; n сервисы репликаций (Replication Services) репликация данных для распределенных и мобильных приложений обработки информации, высокая доступность систем, масштабируемый параллелизм со вторичными хранилищами для отчетных решений предприятия и интеграция с разнородными системами, включая существующие базы данных Oracle; 139

SQL 2005 - компоненты n сервисы нотификаций (Notification Services) развитые возможности уведомлений для разработки и внедрения масштабируемых приложений, способных доставлять своевременные персонализированные обновления информации множеству соединенных и мобильных устройств; n сервисы интеграции (Integration Services) возможности извлечения, преобразования и загрузки информации для хранилищ данных и интеграции данных в масштабе предприятия; n аналитические сервисы (Analysis Services) аналитическая обработка в реальном времени (OLAP) для быстрого и сложного анализа больших и смешанных наборов данных, при которой используется многомерное хранение кубов, и решение задач Data Mining (извлечение знаний); 140

SQL 2005 - компоненты n сервисы отчетов (Reporting Services) исчерпывающее решение для управления как традиционными бумажными, так и интерактивными отчетами, основанными на Web технологиях, а также для их создания и доставки; n инструменты управления - SQL Server включает средства управления для настройки баз данных и развитого управления ими, обеспечивает тесную интеграцию с такими инструментами, как Microsoft Operations Manager (MOM) и Microsoft Systems Management Server (SMS). Стандартные протоколы доступа к данным существенно уменьшают время, необходимое для интеграции SQL Server с существующими системами. В дополнение встроена поддержка Web служб для обеспечения взаимодействия с другими приложениями и платформами; 141

SQL 2005 - компоненты n n инструменты разработки - SQL Server предлагает интегрированные инструменты разработки для ядра базы данных, извлечения, трансформации и загрузки данных, извлечения информации, OLAP и отчетности, которые тесно интегрированы с Microsoft Visual Studio для предоставления сквозных возможностей разработки приложений. Каждая главная подсистема SQL Server поставляется со своей собственной объектной моделью и набором API для расширения системы данных в любом направлении. 142

Средства бизнес-аналитики n n В комплекс средств интеллектуальной обработки данных SQL Server 2005 : Integration Services, Analysis Services OLAP, Analysis Services Data Mining и Reporting Services Кроме того, в SQL Server 2005 добавлены два новых средства разработки и управления: SQL Server Management Studio и SQL Server Business Intelligence Development Studio, простроенных на базе интегрированной среды Visual Studio 2005 IDE. Пакету BI Development Studio отводится основная роль в создании BI решений, он полностью реализует функциональность возможности администрирования реляционных и многомерных баз данных, добавляя к ней возможности загрузки и преобразования информации, управления отчетами и извлечения знаний. В его среде можно создавать и другие проекты Visual Studio (с использованием Visual C#, Visual Basic NET и т. д. ), что позволит разработчикам создавать действительно сквозные приложения. 143

Основные элементы архитектуры SQL Server 2005 BI-компонент SQL Server 2005 Извлечение, преобразование и загрузка данных (ETL Extract, Transformation, and Load) SQL Server 2005 Integration Services Реляционное хранилище данных Реляционная база данных SQL Server 2005 Многомерная база данных SQL Server 2005 Analysis Services Извлечение данных (Data Mining) SQL Server 2005 Analysis Services Управляемая система отчетности SQL Server 2005 Reporting Services Система пользовательских отчетов SQL Server 2005 Reporting Services Пользовательские запросы и анализ Продукты Microsoft Office (Excel, Office Web Components, Data Analyzer, Share. Point Portal) Инструменты разработки баз данных SQL Server 2005 Business Intelligence Development Studio (новый инструмент) Инструменты управления базами данных SQL Server Management Studio (новый инструмент) 144

Аналитические сервисы n SQL Server 2005 Analysis Services (AS 2005) состоит из двух основных дополняющих друга функциональных частей On Line Analytical Processing (OLAP) и Data Mining. 145

SQL 2005 – механизм Data Source View (DSV) и технологи Unified Dimensional Model (UDM) n n До SQL 2005 работа с кубами базировалась исключительно на применении реляционных звездообразных схем в качестве источника данных. AS 2005 с помощью нового механизма Data Source View (DSV) может представлять структуру кубов в виде атрибутивных схем. Это повышает гибкость обработки данных, в том числе дает возможность отслеживать обратные связи между кубами и рабочими базами данных. В то же время DSV позволяет работать со структурами кубов без их непосредственного соединения с источниками данных. OLAP 2005 использует новую технологию Unified Dimensional Model (UDM) для создания виртуальных ХД , которая представляет собой комбинированный механизм доступа к реляционным БД и многомерным OLAP кубам. 146

SQL 2005 -Интегрированная платформа управления данными n Microsoft SQL Server 2005 это полноценная платформа интеллектуальной обработки данных, которая предоставляет инфраструктурные и серверные компоненты для создания: ¨ ¨ ¨ n больших, сложных хранилищ данных, к которым легко выполнять запросы, и недорогих с точки зрения поддержки; небольших систем отчетности и анализа, простых в создании, которыми легко управлять на небольших предприятиях или в отделах больших предприятий; систем с небольшой задержкой обновления данных, которые доставляют аналитические данные оперативным пользователям; систем аналитики замкнутого цикла и систем добычи данных; встроенных систем, которые расширяют использование интеллектуальной обработки данных. Все входящие в состав SQL Server инструменты реляционная СУБД, Integration Services, Analysis Services, OLAP, Data Mining и Reporting Services значительно улучшены. Такие новые инструменты, как Business Intelligence Development Studio и SQL Server Management Studio, расширяют платформу интеллектуальной обработки данных Microsoft. 147

Microsoft SQL Server 2005 - Сервисы интеграции n Integration Services хотя и являются преемником DTS (Data Transformation Services) в SQL Server 2000, все же вполне могут считаться нововведением в SQL Server 2005. Integration Services были полностью переработаны по сравнению с DTS, чтобы стать реальной ETL платформой предприятия (Extract, Transformation, and Loading извлечение, преобразование и загрузка данных). 148

Microsoft SQL Server 2005 - Сервисы интеграции n Архитектура Integration Services совмещает в себе как ориентированный на операции механизм потока задач (task-flow), так и масштабируемый и производительный механизм потока данных (data-flow). Такое сочетание потоков задач и потоков данных позволяет эффективно использовать Integration Services в проектах с традиционными системами ETL и в проектах по созданию хранилищ данных, а также в более сложных проектах, например по внедрению центров данных. n Ядром Integration Services является конвейер преобразования данных, использующий буферную архитектуру, которая обеспечивает высокую производительность при манипуляции наборами данных путем загрузки их в память. Такой подход позволяет все шаги преобразования данных в ETL системах производить как одну операцию, т. е. без промежуточных результатов. В этом состоит существенное отличие Integration Services от традиционных средств ETL, которые очень часто создают промежуточные результаты почти на каждом шагу процесса заполнения хранилища или интеграции данных. 149

Microsoft SQL Server 2005 - Сервисы интеграции n В Integration Services все типы данных (структурированные, неструктурированные, XML и т. д. ) приводятся к табличному (т. е. состоящему из столбцов и строк) виду непосредственно путем загрузки в буферы. При этом операции, применимые к табличному представлению информации, могут быть задействованы на любом шаге конвейера обработки данных. n В целом такая архитектура позволяет использовать Integration Services во многих проектах по интеграции данных, начиная от традиционных ETL систем для хранилищ данных и заканчивая нетрадиционными технологиями интеграции информации, и при этом обеспечивать возможность работы не только с большими наборами данных, но и со сложными их потоками. Службы интеграции могут извлекать (а также выгружать) данные из различных источников, включая OLE DB, управляемые источники (ADO. NET), ODBC, плоские файлы, Excel и XML, с помощью специального набора компонентов, которые называются адаптерами (adapters). 150

Microsoft SQL Server 2005 - Сервисы интеграции n Помимо этих основных преобразований для хранилищ данных имеется поддержка таких расширенных хранилищ, как Slowly Changing Dimensions (SCD редко обновляемые размерности). Мастер SCD поможет пользователям определить, какие измерения являются редко обновляемыми, и на основе этой информации создаст полностью готовый к использованию поток данных с несколькими преобразованиями, реализующими загрузку медленно изменяющихся измерений. n Одной из ключевых особенностей Integration Services является их способность интегрировать не только данные, но и методы обработки этих данных. Такой подход позволяет включить в него средства очистки информации, основанные на методах нечеткой логики (fuzzy logic). В сочетании с технологией Data Mining в процессе передачи информации можно обнаружить аномальные данные, а также автоматически исправить их и заменить на лучшие значения. 151

Возможности SQL Server 2005 Business Intelligence Development Studio Характеристика BI Development Studio Хранение метаданных XML файлы, обеспечивающие более высокий уровень управления структурой метаданных Реализация BI приложения Решение (solution) в стиле приложений, создаваемых Visual Studio. Включает один или несколько проектов, один из которых имеет тип Analysis Services аналогичный database в AM 2000. Другие типы проектов представляют функции DTS и Reporting Services Автоматизация операций Использование технологии Intelli. Cube автоматизирует процедуры создания кубов. Для ручного управления используется Cube Editor Построение кубов Можно использовать несколько таблиц, имеющих различные размерности. Такой режим в AM 2000 можно было реализовать с помощью виртуальных кубов, но в новой версии он более "бесшовный 152

SQL Server Management Studio n n SQL Server Management Studio — утилита из Microsoft SQL Server 2005 и более поздних версий для конфигурирования, управления и администрирования всех компонентов Microsoft SQL Server. Утилита включает скриптовый редактор и графическую программу, которая работает с объектами и настройками сервера. Главным инструментом SQL Server Management Studio является Object Explorer, который позволяет пользователю просматривать, извлекать, и полностью управлять объектами сервера. 153

Проектирование ХД 1. 2. 3. 4. 5. 6. 7. Проектирование ХД состоит из нескольких этапов: Определение информационной структуры предприятия Выявление требований бизнес аналитиков Проектирование и реализация схемы витрины данных Создание проекта интеграции витрины данных с существующими источниками информации Проектирование и развертывание многомерного куба для аналитической системы Разработка проекта анализа данных Data. Mining

Два способа создания витрины данных n Для создания витрины данных в РБД SQL сервер существуют два подхода: проектирование «снизу вверх» создание структуры таблиц «Снежинка» или «Звезда» и «сверху вниз» создание реляционной схемы на основе структуры куба данных. n Для проектирования «Снизу вверх» может использоваться инструмент SQL Server Management Studio. n Для проектирования «Сверху вниз» применяется мастер Business Intelligence Development Studio.

Создание витрины данных «снизу вверх» Инструмент «SQL Server Management Studio. » Бухгалтерская система. (Accounting. System Database) Витрина данных Гиперкуб OLAP Visual Fox. Pro 9. 0 SQL 2005 n Цель проекта: разработать витрину данных для бизнес аналитиков компании MAXMIN

Создание реляционной витрины данных в SQL Server 2005 157

Создание витрины данных «снизу вверх» Инструмент «SQL Server Management Studio. » n Цель проекта: разработать витрину данных для бизнес аналитиков компании MAXMIN

Создание витрины данных «снизу вверх» Инструмент «SQL Server Management Studio. » Бухгалтерская система. (Accounting. System Database) Витрина данных Гиперкуб OLAP Visual Fox. Pro 9. 0 SQL 2005 n Цель проекта: разработать витрину данных для бизнес аналитиков компании MAXMIN

Создание витрины данных «сверху вниз» Инструмент «Business Intelligence Development Studio. » n Задачи 1. Создание AS куба с использованием мастера кубов Business Intelligence Development Studio. 2. Создание в Business Intelligence Development Studio реляционной витрины данных по определению куба.