Хранилища данных Материалы курса «Управление данными» НИУ ВШЭ ̶ Пермь Факультет бизнес-информатики Кафедра информационных технологий в бизнесе Лядова Л.Н. Пермь 2015

2 Режимы обработки данных: OLTP и OLAP Традиционная область применения баз данных – это системы оперативной обработки транзакций (OLTP – On-Line Transaction Processing). К этому классу относятся задачи управления банковскими счетами, учёта материальных ценностей, информационно-поисковые системы и т.п. Существуют также системы, ориентированные на задачи анализа данных (OLAP – On-Line Analytical Processing). Такие системы создаются для поддержки принятия решений (системы принятия решений – DSS – Decision Support Systems). К задачам анализа относятся выработка рекомендаций на будущее, принятие руководством решений и т.д. От качества информации, используемой в системах принятия решений, напрямую зависит финансовое положение предприятия.

3 Режимы обработки данных: OLTP и OLAP

4 Зачем нужны хранилища данных? Решение – автоматизация информационных процессов извлечения данных из систем оперативной обработки, разнородных источников и преобразования ее к единому виду, «доставки» полученных данных к рабочему месту аналитика. Эти функции и выполняет информационное хранилище. В основе реализации две задачи: –интеграция разрозненных данных, получаемых из оперативных систем, внешних источников, в едином информационном хранилище, их согласование; –физическое разделение узлов, где производится оперативная обработка данных, и узлов, где выполняется их анализ. Каково место хранилищ данных в информационной инфраструктуре предприятий?

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

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

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

8 Понятие интегрированной системы управления Интегрированные системы управления (ИСУ) часто называют системами MRP (Material Resource Planning) – ERP (Enterprise Resource Planning). Все более важное значение для оперативного принятия решений, гибкости приспособления к изменениям условий внутри и вне предприятия приобретают прогнозы по сценариям «что – если», реализация которых требует внедрения в информационные системы специальных компонентов поддержки решений. Современные средства поддержки принятия решений предполагают использование различных методов, инструментальных средств. Однако реализация этих средств всегда основана на анализе больших массивов многомерных данных, накапливаемых за длительные периоды

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

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

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

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

13 Обобщённая структура информационного пространства КИС Запросы Архивные базы данных Фактографические БД Базы документов Внешние базы данных Фактографические БД Базы документов Оперативные базы данных Фактографические БД Базы документов Информация в архив Новая информация Интеллектуальные базы данных Базы прецедентов Базы знаний Обращение к информации по прецедентам Накопление опыта Информационное хранилище Предметно-ориентированные базы данных

14 «Традиционный» подход к реализации средств DSS (на примере подготовки отчетов)

15 Подход, основанный на использовании средств импорта данных из разнородных внешних источников

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

17 Данные, подлежащие хранению, характеризуются следующими основными свойствами: долгим «временем жизни»; большим объёмом и сложными внутренними взаимосвязями; ориентацией структуры и представления данных на проблемную область, так как эти данные уже должны быть подготовлены для анализа. Понятие хранилища данных: характеристики данных

18 Типовая структура хранилища данных Источники данных Хранилище данных Приложения Оперативные данные Внешние данные Инструментарий OLTP Выборка Преобразование Согласование Транспортировка Метаданные Фактические данные Инструментарий OLAP Суммарные данные

19 Уровни информационного обеспечения КИС

20 Обобщённая структура мультисети КИС

21 Обобщённая структура ЛВС КИС

22 Программное обеспечение главного хранилища данных Программное обеспечение главного сервера, выделенного под хранилище данных, включает следующие компоненты: открытая многопользовательская многозадачная сетевая ОС; коммуникационные протоколы; сервер хранилища данных. Программное обеспечение главных серверов локальных вычислительных сетей подразделений состоит из: открытой многопользовательской многозадачной сетевой ОС; коммуникационных протоколов; сервера баз данных; сервера системы автоматизации документооборота; сервера архивирования и поиска документов по нечётко заданному критерию; сервера хранилища данных.

23 Обобщённая структура программного обеспечения КИС IV Функциональная подсистема поддержки работы должностных лиц с базами документов по нечетко заданным критериям Функциональная подсистема поддержки работы должностных лиц с базами прецедентов Функциональная подсистема поддержки работы должностных лиц с информационным хранилищем II Функциональная подсистема поддержки работы должностных лиц c фактографическими базами данных Автономная функциональная подсистема I Операционная система клиента Сервер хранилища данных Сетевые коммуникационные протоколы Сетевая операционная система сервера Сервер управления хранением, поиском и обработкой документов Сервер баз прецедентов Сервер баз данных Сервер управления документооборотом III Функциональная подсистема автоматизации документооборота

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

25 Структура СППР с физическим ХД

26 Структура СППР с виртуальным ХД

27 Понятие витрины данных Снижения затрат на создание ХД можно добиться, создавая его упрощённый вариант – витрину данных (Data Mart). Витрина данных (ВД) – это упрощённый вариант ХД, содержащий только тематически объединённые данные. ВД максимально приближена к конечному пользователю и содержит данные, тематически ориентированные на него (например, ВД для работников отдела маркетинга может содержать данные, необходимые для маркетингового анализа). ВД существенно меньше по объёму, чем ХД, и для ее реализации не требуется больших затрат. Они могут быть реализованы как самостоятельно, так и вместе с ХД.

28 Организация самостоятельных витрин данных

29 Организация витрин данных на основе хранилища данных

Архитектура хранилищ данных и типы данных Все данные в ХД делятся на три основные категории: детальные данные; агрегированные данные; метаданные.

31 Типы данных в хранилище данных Детальные данные: –измерения; –факты. Архивные данные. Агрегированные данные: –аддитивные; –полуаддитивные; –неаддитивные. Метаданные –Что (описание объектов); –Кто (описание пользователей); –Где (описание места хранения); –Как (описание действий); –Когда (описание времени); –Почему (описание причин)

32 Детальные данные в хранилище данных Детальными являются данные, переносимые непосредственно из ОИД. Они соответствуют элементарным событиям, фиксируемым OLTP-системами (например, продажи, эксперименты и пр.). Принято разделять все данные на измерения и факты. Измерениями называются наборы данных, необходимые для описания событий (например, города, товары, люди и т.п.). Фактами называются данные, отражающие сущность события (например, количество проданного товара, результаты экспериментов и т.п.). Фактические данные могут быть представлены в виде числовых или категориальных значений.

33 Агрегированные данные в хранилище данных На основании детальных данных могут быть получены агрегированные (обобщённые) данные. Агрегирование происходит путём суммирования числовых фактических данных по определённым измерениям. В зависимости от возможности агрегирования фактические данные подразделяются на следующие типы: аддитивные – числовые фактические данные, которые могут быть просуммированы по всем измерениям; полуаддитивные – числовые фактические данные, которые могут быть просуммированы только по определённым измерениям; неаддитивные – фактические данные, которые не могут просуммированы ни по одному измерению.

34 Метаданные в хранилище данных Для удобства работы с ХД необходима информация о содержащихся в нем данных – метаданными, которые должны отвечать на вопросы: Что (описание объектов) – объекты предметной области, информация о которых хранится в ХД. Кто (описание пользователей) – категории пользователей, использующих данные. Где (описание места хранения) – местоположение серверов, рабочих станций, ОИД, размещённые на них программные средства и распределение между ними данных. Как (описание действий) – действия, выполняемые над данными. Когда (описание времени) – время выполнения разных операций над данными (например, загрузка, агрегирование, архивирование, извлечение и т.п.). Почему (описание причин) – причины, повлёкшие выполнение над данными тех или иных операций (такими причинами могут быть требования пользователей, статистика обращений к данным и т.п.)

35 Информационные потоки в хранилище данных Данные, поступающие из ОИД в ХД, перемещаемые внутри ХД и поступающие из ХД к аналитикам, образуют следующие информационные потоки: входной поток (Inflow) – образуется данными, копируемыми из ОИД в ХД; поток обобщения (Upflow) – образуется агрегированием детальных данных и их сохранением в ХД; архивный поток (Downflow) – образуется перемещением детальных данных, количество обращений к которым снизилось; поток метаданных (Metaflow) – образуется потоком информации о данных в репозитории данных; выходной поток (Outflow) – образуется данными, извлекаемыми пользователями; обратный поток (Feedback flow) – образуется очищенными данными, записываемыми обратно в ОИД.

36 ETL-процесс

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

38 Проблема качества данных: уровень ячейки таблицы На данном уровне задача очистки (data cleansing) заключается в анализе и исправлении ошибок в данных, хранящихся в ячейках таблиц БД. К таким ошибкам можно отнести следующие: 1. Орфографические ошибки (опечатки) – ошибки, возникающие при вводе информации. 2. Отсутствие данных – ошибки, которые происходят из-за пропуска данных при вводе. 3. Фиктивные значения – это введенные в ячейки значения, не имеющие смысла. 4. Логически неверные значения – это значения, не соответствующие логическому смыслу, вкладываемому в данное поле таблицы (ограничениям, бизнес-правилам предметной области). 5. Закодированные значения – сокращенная запись или кодировка реальных данных, используемая для уменьшения занимаемого места. 6. Составные значения – это значения, содержащие несколько логических единиц данных в одной ячейке таблицы.

39 Проблема качества данных: уровень записи в таблице На данном уровне возникает проблема противоречивости значений в разных полях записи, описывающей один и тот же объект предметной области. Эти проблемы могут возникнуть при загрузке данных из ненормализованных баз данных, электронных таблиц. Например, возраст человека не соответствует дате рождения: age = 22, bdate = Возраст всегда можно вычислить на конкретную дату, следовательно, его ввод в таблицу – ошибка проектирования БД. Стоимость отпущенного товара не соответствует расчётной с учётом цены и установленных скидок… В хорошо спроектированных таблицах такие ситуации возникать не должны, но внешние источники могут быть ненадёжными…

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

41 Проблема качества данных: уровень баз данных Проблемы качества на уровне баз данных можно разделить на два уровня: Уровень одиночной БД. На данном уровне, как правило, возникают проблемы, связанные с нарушением целостности данных. Уровень множества БД. На данном уровне возникают проблемы, связанные с неоднородностью как структур данных БД, так и хранящейся в них информации. Можно выделить следующие основные проблемы этого уровня: различие структур БД: различие наименований полей, типов, размеров и др.; в разных БД одинаковые данные представлены по-разному (использованы разные типы, точность представления); в разных БД классификация элементов разная; в разных БД временная градация разная; в разных БД ключевые значения, идентифицирующие один и тот же объект предметной области, разные и т.п.

42 Проблема качества данных: этапы очистки данных В целом очистка данных включает несколько этапов: выявление проблем в данных; определение правил очистки данных; тестирование правил очистки данных; непосредственная очистка данных.

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

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

45 Проблема качества данных: непосредственно очистка данных На этом этапе выполняются преобразования в соответствии с определёнными ранее правилами очистки. Очистка выполняется в два приёма: устраняются проблемы, связанные с отдельными источниками данных; устраняются проблемы множества БД.

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

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

48 Рекомендации по созданию ХД: проблема выбора источников данных Идеальный способ выборки данных для загрузки в ХД состоит в том, что прежде всего определяются все запросы, которые будут генерироваться всеми приложениями, выполняемыми над ХД, и определяются таблицы и поля, фигурирующие в этих запросах. Определение всех запросов до создания ХД является трудной задачей. Однако это может стать возможным после начального создания ХД за счет регистрации в течение разумного промежутка времени всех запросов, поступающих от приложений. Анализ зарегистрированных запросов может быть использован для тонкой настройки ХД и удаления данных, к которым приложения не осуществляют доступ.

49 Рекомендации по созданию ХД: проблема выбора источников данных Описано много предложений по моделированию хранилища данных в виде репозитария результатов всех выполняемых запросов. Авторы этих предложений пытаются найти алгоритмы, которые будут выбирать (для загрузки в ХД) подмножество исходных данных, минимизирующее общее время ответов на запросы. Некоторые из авторов пытаются также минимизировать стоимость обновления ХД. Другими словами, они основываются на предположении, что все запросы к ХД можно заранее узнать или предсказать и что можно заранее узнать или предсказать все возможные изменения ХД, а следовательно, и исходных источников данных.

50 Рекомендации по созданию хранилищ данных: не используйте моделирование связи сущностей Типичный подход к созданию БД при разработке систем OLTP – систем обработки транзакций – конструирование диаграмм «сущность-связь» (ER, Entity-Relation). Сущности становятся таблицами реляционных баз данных, различные типы связей либо поддерживаются СУБД, либо моделируются также с помощью таблиц (связи типа «многие-со-многими»). ER-диаграммы, как правило, порождают нормализованные схемы БД. К сожалению данная модель не подходит для создания хранилищ, в частности, вследствие того, что в ХД часто используется денормализованная схема. В данном случае более подходящей является пространственная модель (dimensional model). Данный подход даёт более «простую» модель, которую проще поддерживать в соответствии с состоянием системы. Кроме того, данная модель легче воспринимается пользователями.

51 Пространственное моделирование Пространственная модель – альтернатива E-R-модели. Эта модель описывает данные с помощью измерений (dimensions) и фактов (facts), которые становятся конкретными таблицами базы данных при создании хранилища. Пространственная модель обеспечивает эффективный способ хранения текущих и исторических данных в такой форме, которая является наглядной, делает эти данные доступными пользователям и даёт им возможность анализировать эти данные, принимать правильные бизнес-решения на основе этого анализа. При этом предполагается, что хранилище содержит проверенные данные; исторические данные; интегрированные данные (одни и те же ключи используются всеми системами); легкодоступные данные.

52 Пространственное моделирование Факт «Заказ» Измерение «Время» Измерение «Покупатель» Измерение «Продукт»

53 Пространственное моделирование: таблицы фактов Таблицами БД при использовании пространственного подхода становятся измерения и факты. Таблица фактов (ТФ) содержит фактическую информацию, она является наиболее «объёмной» и быстро растёт (в КИС это могут быть сотни миллионов строк – записей). Таблиц этого типа может быть несколько. Они содержат подробные данные, загружаемые в хранилище (например, все детальные данные по всем сделанным покупателями заказам). Степень подробности данных, хранимых в ТФ, называется глубиной детализации (гранулярностью, granularity). Определение этой характеристики – одно из важнейших решений, принимаемых при разработке хранилища. Существуют разные виды ТФ: уровня транзакций, зависимые от событий, таблицы объединённых данных…

54 Пространственное моделирование: таблицы измерений Одной ТФ может соответствовать множество таблиц измерений (ТИ). Таблица измерений рассматривается как справочная таблица для ТФ. В этой таблице хранится описание, справочная информация об элементе данных по этому измерению (например, для заказа – информация о продукте или покупателе…). Данные в ТИ относительно статичны, количество данных на порядки меньше, чем в ТФ. Для извлечения этой справочной информации об объекте таблицы связываются ключами.

55 Ключи хранилища При определении ключей в таблицах хранилища могут возникать проблемы: При загрузке данных, поступающих из нескольких источников, коды, являющиеся ключами (если ключи – искусственные или неудачно выбраны), могут отличаться для одних и тех же объектов в разных системах. При накоплении данных в течение длительного времени одни и те же коды могут использоваться повторно для разных объектов (например, имена и т.п.). Таким образом, при проектировании хранилища необходимо решить вопрос о «сопоставлении» объектов и реализации ключей- заменителей (суррогатных ключей, surrogate keys), которые бы позволяли однозначно идентифицировать данные в хранилище в течение всего времени его существования.

56 Нормализация хранилища Нормальная пространственная форма – это фактически комбинация нормализации и денормализации. На следующем слайде показаны нормализованная и нормальная пространственная формы.

Нормализация хранилища Округ Ключ_округа Описание_округа Регион Ключ_региона Описание_Региона Ключ_округа Фирма Ключ фирмы Описание_фирмы Ключ_региона Округ Ключ_округа Описание_округа Регион Ключ_региона Описание_Региона Ключ_округа Описание_округа Фирма Ключ фирмы Описание_фирмы Ключ_региона Описание_региона Ключ_округа Описание_округа Нормализованная форма Нормальная пространственная форма

58 Правила и особенности OLAP (правила Е.Ф.Кодда) Основные особенности (B): F1: Многомерное концептуальное представление данных (Оригинальное правило 1). F2: Интуитивное манипулирование данными (Оригинальное правило 10). F3: Доступность: OLAP как посредник (Оригинальное правило 3). F4: Пакетное извлечение против интерпретации (Новое). F5: Модели анализа OLAP (Новое). F6: Архитектура "клиент-сервер" (Оригинальное правило 5). F7: Прозрачность (Оригинальное правило 2). F8: Многопользовательская поддержка (Оригинальное правило 8).

59 Правила и особенности OLAP (правила Е.Ф.Кодда) Специальные особенности (S): F9:Обработка ненормализованных данных (Новое). F10:Сохранение результатов OLAP: хранение их отдельно от исходных данных (Новое). F11:Исключение отсутствующих значений (Новое). F12:Обработка отсутствующих значений (Новое).

60 Правила и особенности OLAP (правила Е.Ф.Кодда) Особенности представления отчетов (R): F13:Гибкость формирования отчетов (Оригинальное правило 11). Требуется, чтобы измерения могли быть размещены в отчёте так, как это нужно пользователю. F14:Стандартная производительность отчетов (Оригинальное правило 4). F15:Автоматическая настройка физического уровня (Замена оригинального правила 7). F16:Универсальность измерений (Оригинальное правило 6). F17:Неограниченное число измерений и уровней агрегации (Оригинальное правило 12). F18:Неограниченные операции между размерностями (Оригинальное правило 9).

61 Технологии разработки хранилищ данных: основные принципы В самом простом варианте для ХД используется та же модель данных, которая лежит в основе транзакционной системы. Если транзакционная система функционирует на реляционной СУБД, самой сложной задачей становится выполнение запросов, поскольку невозможно заранее оптимизировать структуру БД так, чтобы все запросы работали эффективно. OLAP-системы построены на двух базовых принципах: все данные, необходимые для принятия решений, предварительно агрегированы на всех соответствующих уровнях и организованы так, чтобы обеспечить максимально быстрый доступ к ним; язык манипулирования данными основан на использовании бизнес-понятий.

62 Технологии разработки хранилищ данных: основные понятия Основными понятиями, типами данных в системах OLAP являются меры, измерения, атрибуты и иерархии: Мера (Measure) – это числовое значение, отражающее определённый аспект деятельности бизнес-системы. Измерение (Dimension) – способ ранжирования данных, используемый для разделения агрегированных мер на составляющие их части. Иерархия (Hierarchy) – это структуры, состоящие из связанных между собой измерений, организованных в два или более уровня. Атрибут (Attribute) – дополнительный элемент информации, относящийся к измерению, и не являющийся при этом уникальным идентификатором или описанием этого измерения.

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

64 Технологии разработки хранилищ данных: структура хранилища (витрины) При использовании звезды центр – таблица фактов. Каждая мера в этой таблице – отдельный столбец. Кроме того, по одному столбцу отведено для каждого измерения: в них хранятся внешние ключи, указывающие элементы соответствующих измерений. Первичный ключ таблицы является составным, он формируется объединением полей внешних ключей. ТФ получают обычно названия по названиям тех мер, которые они содержат. При этом информация об иерархиях хранится непосредственно в таблицах соответствующих измерений. Первичный ключ этих таблиц находится на самом нижнем уровне иерархии, следовательно, внешние ключи в таблице фактов также должны указывать на самые нижние уровни иерархии. Уникальной комбинации элементов самого нижнего уровня всех иерархий в ТФ соответствует отдельная строка, а ее ключ – комбинация внешних ключей.

65 Схема звезды с атрибутами измерений Ключ Год Описание Год Год Ключ Тип Товара Описание Тип Товара Тип Товара Ключ Регион Продаж Описание РегионаПродаж Имя Менеджера Регион Продаж Ключ Компания Описание Компании Данные ОКомпании Компания Ключ Покуп Группа Описание Покуп Группа Покуп Группа Ключ Год Ключ Тип Товара Ключ Регион Продаж Ключ Компания Ключ Покуп Группа Общие продажи Продажи

66 Схема звезды с иерархиями Ключ Год Описание Год Ключ Квартал Описание Квартал Ключ Месяц Описание Месяц Месяц Ключ Тип Товара Описание Тип Товара Ключ Товара Описание Товара Товар Ключ Регион Продаж Описание РегионаПродаж Ключ Город Продаж Описание Город Продаж Город Продаж Ключ Компания Описание Компании Данные ОКомпании Компания Ключ Покуп Группа Описание Покуп Группа Покуп Группа Ключ Месяц Ключ Товара Ключ Город Продаж Ключ Компания Ключ Покуп Группа Общие продажи Продажи

67 Схема снежинки Ключ Год Описание Год Год Ключ Тип Товара Описание Тип Товара Тип Товара Ключ Регион Продаж Описание РегионаПродаж Регион Продаж Ключ Компания Описание Компании Данные ОКомпании Компания Ключ Покуп Группа Описание Покуп Группа Покуп Группа Ключ Месяц Ключ Товара Ключ Город Продаж Ключ Компания Ключ Покуп Группа Общие продажи Продажи Ключ Товара Описание Товара Ключ Тип Товара Товар Ключ Город Продаж Описание Город Продаж Ключ Регион Продаж Город Продаж Ключ Год Ключ Квартал Описание Квартал Квартал Ключ Квартал Ключ Месяц Описание Месяц Месяц

68 Технологии разработки OLAP-систем: понятие куба В основе OLAP лежит понятие гиперкуба, или многомерного куба данных, в ячейках которого хранятся анализируемые (числовые) данные, например объёмы продаж. Измерения представляют собой совокупности значений других данных, скажем названий товаров и названий месяцев года. В простейшем случае двумерного куба (квадрата) мы получаем таблицу, показывающую значения уровней продаж по товарам и месяцам.

69 Технологии разработки OLAP-систем: понятие куба Куб (Cube) – это структура, содержащая значения одной или нескольких мер для всех уникальных комбинаций всех ее измерений. Это могут быть детализированные (листовые) значения, но куб также содержит и агрегированные значения, формируемые с помощью иерархий измерений или выносом одного или нескольких измерений из иерархии. Агрегат (Aggregate) – это скалярное значение, формируемое сочетанием значений определённого измерения или набора измерений. Чаще всего агрегат – это сумма, но могут использоваться и другие функции.

70 Технологии разработки OLAP-систем: операции Вводятся следующие базовые операции: поворот; проекция: при проекции значения в ячейках, лежащих на оси проекции, суммируются по некоторому предопределённому закону; раскрытие (drill-down): одно из значений измерения заменяется совокупностью значений из следующего уровня иерархии измерения; соответственно заменяются значения в ячейках гиперкуба; свёртка (roll-up/drill-up): операция, обратная раскрытию; сечение (slice-and-dice).

71 Технологии разработки OLAP-систем: усложнение модели Усложнение модели данных может идти по нескольким направлениям: увеличение числа измерений – данные о продажах не только по месяцам и товарам, но и по регионам (в этом случае куб из двухмерного становится трёхмерным и т.д.); усложнение содержимого ячейки – например, нас может интересовать не только уровень продаж, но и, скажем, чистая прибыль или остаток на складе (в этом случае в ячейке куба будет несколько значений); введение иерархии в пределах одного измерения (например, общее понятие ВРЕМЯ естественным образом связано с иерархией значений: год состоит из кварталов, квартал из месяцев и т.д.)

72 Базы данных, основанные на мерах и измерениях, иерархиях и кубах, а не на таблицах, строках, столбцах и связях, называются многомерными. Многомерные БД являются наиболее естественным средством хранения BI-информации. В зависимости от ответа на вопрос, существует ли гиперкуб как отдельная физическая структура или лишь как виртуальная модель данных, различают системы MOLAP (Multidimensional OLAP) и ROLAP (Relational OLAP). В MOLAP гиперкуб реализуется как отдельная база данных специальной нереляционной структуры, обеспечивающая максимально эффективный по скорости доступ к данным, но требующая дополнительного ресурса памяти. MOLAP-системы весьма чувствительны к объёмам хранимых данных. Поэтому данные из хранилища сначала помещаются в специальную многомерную базу (Multidimensional Data Base, MDB), а затем эффективно обрабатываются OLAP-сервером. Возможна также гибридная архитектура (HOLAP – Hybrid OLAP). Архитектура OLAP

73 Архитектуры OLAP Детализированные значения (реляционное хранилище) Предобработанные агрегаты (реляционное хранилище) Структура куба (многомерное хранилище) ROLAP Детализированные значения (многомерное хранилище) Предобработанные агрегаты (многомерное хранилище) Структура куба (многомерное хранилище) МOLAP Детализированные значения (реляционное хранилище) Предобработанные агрегаты (многомерное хранилище) Структура куба (многомерное хранилище) HOLAP