Лекция.
Будет после первого модуля – зачет, после второго модуля – КДЗ и экзамен.
Основное место работы у лектора – «Ланит».
Business Intelligence (BI) – это широкий набор технологий и приложений для сбора, хранения и анализа данных, помогающий корпоративным пользователям в принятии решений на основе этой информации – определение из Педивикии.
BI приложения включают в себя инструменты для решения задач отчетности, анализа данных, статистического анализа, прогнозирования, планирования, поиска скрытых закономерностей.
Вообще формального определения нет, но вообще BI это вся совокупность средств для сбора, хранения и анализа данных, примерно так.
Вообще все хранилища данных нужны, потому что современному бизнесу требуется не только оперативное управление (которое просто поддерживает бизнес-процесс и использует OLTP). OLAP (Online Analysis Process) системы поддерживают принятие более глобальных решений, и это и есть BI.
BI используется для:
1) Понимания текущего состояния бизнеса и направлений его движения
2) Совместной работы пользователей над анализа информации
3) Сокращения времени принятия решений
BI – сейчас уже явялется неотъемлимой частью IT структуры компании. Бум внедрения BI пришелся как раз на время кризиса, т. к. все искали способы сократить затраты.
Первый простейший уровень формирования отчетности – это тупо вытаскивание SQL запросами из БД нужной инфы, то есть прямая связь между клиентом и БД. Но тут возникают проблемы:
1) БД может меняться, тогда надо переделывать всю связь.
2) Реляционные БД (все нормальные формы) заточены под то, чтобы выполнить как можно большее количество небольших операций (чуть-чуть вставить в таблицу, чуть-чуть извлечь из таблицы и т. д.), а глобальные операции (типа прочитать всю таблицу, сгруппировать как-нибудь и т. д.) выполняются медленно. Причем такие запросы мешают оперативной работе.
Как эти проблемы решаются:
1) Разбивается база данных на содержащую текущую информацию и историю. Это подход Data WareHouse – хранилища данных, обычно тут не используются нормальные формы, чтобы проще было выполнять транзакции агрегации и суммирования.
То есть из источников данных (текущих БД) по некотоым бизнес-правилам данные переходят в хранлища данных. Но тут тоже есть проблемы, есть источников много или если данные «грязные».
«грязные данные» -- это то, что связанно с ручным вводом, орфографичческие ошибки, различные названия одного и того же
2) Эта проблема решается вводом промежуточного Staging Area между источником и хранилищем, где осуществляется очистка данных.
И итог развития BI – это появление различных форм представления отчетов (отчеты в свободной форме).
Таким образом хранилища данных возникают как ответ на необходимость анализа, синхронизации, очистки и хранения больших объемов данных.
В общем средства BI – это попытка освободить аналитика от необходимости писать запросы к БД, заменив все технические подробности понятным представлением. То есть это переход от физического представления данных к семантическому (смысловому).
Характеристики OLTP и OLAP есть на слайдах.
Хранилища данных (по Биллу Инмону) – предметно-ориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для поддержки принятия решений.
Принципы организации хранилища (подробнее на слайдах):
1) Проблемно-предметная ориентация – данные в категориях и хранится в соответствии с областями, которые они описывают
2) Интегрированность – объединяет данные
3) Некорректируемость – данные в хранилище лежат, только добавляются (это не совсем верно, т. к. бывает, что периоды закрываются задним числом, но это частности)
4) Зависимость от времени – данные в хранилище точны и корректны только тогда, когда они привязаны к некоторому промежутку или моменту времени
Ральф Кинбалл – это альтертантивная теория ХД (его книга «The Data Warehouse Toolkit»), star-схема.
Билл Инмон – это хранилище в 3NF – это его основное отличие от Кинбалла (его книга «Building the Data Warehouse»).
Есть еще гибридная технология Data Vault (by Dan E. Linstedt).
В последнее время классическую схему BI дополняют еще прямой связью между источником данных и отчетами, чтобы учитывать в отчетах оперативную информацию, плюс может быть обратная связь, когда отчеты влияют на бизнес-процессы.
ETL (Extract, Transform, Load) – это класс ПО, один из основных процессов, служит для трансфера данных из оперативных информационных систем в ХД.
MDM (Master Data Management) – управление основными данными (нормативно-справочной информации) – то есть условно-постоянным компонентом корпоративной инфомации, являющейся основой для унификации и нормализации данных.
Основные игроки: MS, Oracle, SAS, IBM, SAP.
Рынок BI
| Вендор | BI-средство | OLAP-средство |
| Oracle | Hyperion | Essbase |
| SAP | Business Objects | BusinessWarehouse |
| IBM | Cognos BI | TM1 |
| SAS | SAS | |
| Microsoft | Reporting services (SSRS) | Analysing Services (SSAS) |
| QlikTech | QlikView – для небольших задач |
Вообще они все похожи по функционалу, так и по стоимости, так что выбор обычно осуществляется по политическим причинам. Все они основаны на реляционных БД.
Рынок DWH (Data WareHouse)
Есть другие принципы построения БД – многомерные БД и поколоночные БД.
Вендоры: Teradata (поколоночная) – комплекс программно-аппаратный, обеспечивающий примерно одинаковое время отклика при любых объемах данных. Это дорого, но очень надежно.
Также свои альтернативные БД есть у IBM, Oracle, MS.
Рынок DI (Data Integration)
Oracle – OWB, ODI (Oracle Data Integrator)
SAP – Data Integrator
IBM – Data Stage
Microsoft -- SSIS
Отельный большой продукт фирмы Informatica – как бы круче всех. Почему – неясно. =)
Основные тенденции:
1) BI в бизнес-процессы
2) Быстрый анализ (анализ источников на ходу, без подключения ХД)
3) In Memory (для повышения скорости работы с данными все держим в памяти)
4) Mobile представление информации на планшетниках и смартах
5) Движение в средний и малый бизнес – создание дешевых пакетов
6) Clouds
Архитектура ХД.
Архитектура – это набор технологий, регламентов, программно-аппаратных компонент из которых формируется ХД. Это вкратце. Полное определение – на слайде.
Типова архитектура ХД.
1) Источники данных
2) Буферная область (stage area) – первичный процесс загрузки данных из источника, без особых преобразований. Тут происходит очистка данных, сведение их в общие сущности, которые представлены в ХД.
3) КХД (Корпоративное хранилище данных) – метаданные, агрегированные данные
4) Витрины данных (Data Mart) – презентационный уровень, на нем конечный пользователь общается с ХД. Это представление данных по определенной предметной области.
КХД и витрины данных бывают объединены (это подход Кинбалла).
Витрины данных часто бывают денормализованными (с повторения и так далее).
Часто они бывают представлены в многомерном виде, когда есть некая мера (например, объем выручки) и много измерений (аналитик, dimensions) – некая категория, в которой рассматривается мера (например, по магазину, по товару, по времени).
Схема многомерного представления может быть star-схемой, где в центре – ФАКТ, лучи – ИЗМЕРЕНИЯ. Если измерения сложные и состоят из нескольких таблиц, То это схема «снежинка».
В ФАКТе – центральная таблица – со всеми ключами и значением меры. В ИЗМЕРЕНИях – инфа об dimesionsах, то есть список магазинов, например и ключ магазина.
По Кимбаллу – ХД – это набор витрин данных. Тут много повторений получается. Витрины данных использует одни и те же измерения, поэтому подход называют еще «с единой шиной данных». На слайдах есть наглядная картинка.
Лекция 2.
Литература по хранилищам данных BI, бизнес-аналитики и т. д.:
1) Infology.ru
2) Olap.ru
3) Sql.ru
4) Книги Ральфа Кимбалла
5) Туманов В. Е. Проектирование ХД для систем бизнес-аналитики
6) Теорию можно почитать на Интуите
Подходы к моделированию ХД.
1) Модель ER (сущность-свзяь)
2) Многомерное моделирование (Dimensions model, DM)
3) Свод данных (Data Vault)
В основном используются первые 2 подхода.
В рамках моделирования систем поддержки временных изменений – есть еще темпоральное моделирование, оно может включаться в любой из трех подходов.
Понятия в реляционных БД:
1) Первичный ключ – однозначный идентификатор объекта, состоит из минимального набора атрибута (может быть составным, состоять из нескольких атрибутов)
2) Внешний ключ
3) Бизнес ключ (альтернативный ключ, естественный ключ) – ключ, который имеет смысл в предметной области, например, паспорт, фамилия и так далее, но этот ключ неудобен обычно
4) Суррогатный ключ – специально добавленный атрибут в сущность, который будет являться идентификатором, обычно числовая замена более сложного ключа. Есть правило, что суррогатный ключ не должен быть зависим от естественного ключа, то есть лучше всего эго делать с помощью простого счетчика
Третий и четвертый ключ используются вместе.
Пример. Сформировать ХД для хранения информации для обеспечения анализа состояния на рынке недвижимости. Нужны данные о предложении и о покупках (анализ договоров купли-продажи).
Решение.
Проанализировать предметную область и понять что нам нужно. Для этого надо ответить на вопросы:
1) Когда
2) Где
3) Кто
4) Что
5) Почему
6) Как
Выделить необходимые объекты предметной области.
В примере возникают следующие сущности:
1) Квартира
2) Дом
3) Адрес
4) Владелец
5) Застройщик
6) Покупатель
Что анализируем:
1) Предложение
2) Продажи
После этого рисуется ER-диаграммка.
Адрес – это как бы территория, где находится несколько домов.
Гранулярность – детализированность данных. Она может относиться к каждой сущности.
При запросе соединяем несколько таблиц, группируем и ставим условия.
В этой схеме нет поддержки хранения истории и изменений. Поэтому это не хранилище данных, а обычная оперативная БД. =)
Для поддержки времени:
Есть два способа:
1) Поддержка моментальных снимков (копия таблиц на определенный момент времени)
2) Поддержка событий – добавление в каждую таблицу дополнительных полей, которые будут хранить время изменений.
Например:
Введены поля:
1) Время начала действия атрибутов
2) Время окончания действия атрибутов
Это позволяет по строчкам хранить историю, то есть каждая строчка отвечает не за отдельную квартиру, а за отдельную квартиру в определенный период времени.
Таким образом мы ввели событийную модель поддержки изменений, так как новые строчки создаются по событиям (продажа, например).
Slow-change dimension (SCD).
Это относится к многомерной модели. Тут атрибуты, такие как объект, дом и так далее, называются измерениями (dimensions).
Так как они меняются редко, они называются более узко – slow change dimension. Этот термин ввел Кимбалл.
Существуют три типа поддержки:
1) Нет поддержки вообще (первая версия нашей модельки, так как всегда хранится только текущее состояние дел). Изменения вообще не хранятся.
2) Событийная модель поддержки изменений (это как раз добавление двух атрибутов, вторая версия диаграммки). Для такой поддержки необходим суррогатный ключ и пара полей для хранения даты начала действия объекта (строчки) и даты конца действия объекта. При событии добавляется новая строка с новым суррогатным ключом, тем же бизнес-ключом и новыми датами. Иногда еще добавляется техническое поле (активная/неактвная запись), это делается для ускорения индексов и переборов.
3) Добавление нескольких атрибутов вместо того атрибута, который может меняться. Это ограничивает срок хранения истории количеством добавленных атрибутов. Пример ниже:
Тогда мы будет хранить историю с точностью до предыдущего владельца.
Многомерное моделирование.
Основные понятия:
1) Меры (показатели) – measure – всегда числовое значение
2) Факт – fact
3) Измерение – dimension – может состоять из нескольких атрибутов (текстовых, числовых, каких угодно)
Факты содержат набор мер (значений) по определенным измерениям.
Измерения показывают детализацию или изменение того или иного факта.
Факты бывают исходные и производные (предпосчитанные, так сказать).
Измерение может быть вырожденным если оно находится в самой таблице фактов (например, часто таким измерением бывает время).
Сделаем модельку типа «звезда» в многомерной модели:
Это круто, так как можно не хранить конкретные объекты, это более соответствует тому, что есть на самом деле. Эта схема более общая, тут можно хранить не только объекты и их детализацию, а обобщенные характеристики. То есть типы объектов. Если нам не нужны конкретные объекты, а только типы объектов. То есть вместо измерений Дом, Объект, Адрес можно сделать другие измерения – однокомнатные квартиры или же дома на улице такой-то. Это более похоже на то, что требуется для витрин данных.
Так вот Инман – это 3НФ, так как тут все логично.
Кимбалл – за многомерность, тут тоже можно в принципе хранить детализацию, но можно и хранить обобщенную информацию.
Факты делятся на:
1) Транзакционные данные
2) Данные моментальных снимков (на определенный момент времени)
a. Периодические – например, остаток товара на складе на какой-то момент
b. Кумулятивные (накопительный) – это например сумма продаж сначала года, это фиксация определенного факта
Еще факты бывают:
1) Аддитивным – когда его можно складывать по любым измерениям (например, объем продаж)
2) Полуаддтитивный – когда по некоторым измерениям операция сложения возможна, а по некоторым нет (например, количество товаров, их нельзя складывать по измерению «товары», так как нельзя сложить тонну воды с количеством батонов, но можно складывать, например, по регионам)
3) Совсем неаддитивный – вообще нельзя складывать. Например, температура, давление.
Если между сущностями связь типа «многие ко многим», то лучше их сделать разными измерениями.
Если между сущностями связь типа «один ко многим или наоборот», то одна сущность скорее всего является атрибутом другой.
Иерархии – бывают двух типов:
1) Сбалансированные – когда все элементы последнего уровня находятся на одном уровне. То есть количество предыдущих уровней для всех элементов одного уровня равно. Обычно реализуется таблицей из столбцов, каждый из которых отвечает за уровень иерархии, причем пропусков нигде нет.
2) Несбалансированные – соответственно, наоборот. Обычно это подчиненность – одному уровню могут быть подчинены разные уровни.
Это поддерживается путем создания «технических уровней» между напрямую подчиненными разными уровнями. Или же возможно создание связи таблицы с самой собой (структура parent_child), где каждому отдельному уровню (строчке) присваивается значение одного из столбцов, где указывается родитель (то есть то, кому данный уровень починяется). Такая структура позволяет создавать любые иерархии, в том числе несбалансированные. Но тут есть проблема с развертыванием-свертыванием, это будет довольно затратная операция. Хотя так все делают. =)
Data Vault.
Это попытка совместить многомерный подход и нормальные формы.
Ее предложил Ден Листред. Она вообще в 3НФ.
Понятия:
1) Hub -- сущности
2) Satellite – аттрибуты
3) Link – связь между сущностями
Hub содержит только идентификатор, дату загрузки значения и источник данных. Модель сделана специально для ХД.
Суть сателлитов в том, что можно добавлять атрибуты, создавая новые таблицы, не переформатируя имеющиеся. Это круто для ХД.
Пример:
Тут тоже есть 3НФ, но тут проконтралирован процесс загрузки данных (прозрачность данных есть), а также существенно упрощено добавление новых атрибутов.
Это с одной стороны многомерный подход, с другой стороны, тут есть 3НФ. Несмотря на то, что связей тоже дофига получается, но крупные хранилища строятся.
Вообще просто 3НФ для ХД почти не используется. Обычно используется многомерное моделирование.
Лекция 3.
ETL (Extract, Transform, Load), загрузка данных, преобразование данных и проч.
Одно из ETL-срества – это SSIS от Microsoft.
Master Data Services – средство для обработки справочной информации.
Для ETL всегда есть источники (source) и приемники (destination), а также алгоритмы, которые находятся между ними.
Источниками могут быть:
1) БД
2) Файлы
3) Сервисы
Приемниками могут быть все те же штуки. Хотя основным приемником является обычно БД.
Касательно движка, который преобразует данные, оно может быть:
1) Преобразование движком ETL-средств в памяти (это классический ETL).
2) Преобразование средствами СУБД приемника (это условно называют EL-T), что характерно для Oracle Data Integrator.
Наличие двух подходов связано с тем, что преобразование данных не так давно было слишком ресурсоемким процессом для выполнения средствами СУБД. То есть была задача не нагружать СУБД приемника. Но сейчас железки стали куда дешевле, поэтому сейчас уже вполне можно заставить СУБД заставить это делать.
Что лучше – в общем, сказать нельзя.
Флагманы в сфере ETL – это продукты SAP, IBM, Informatica.
MS хорошо чувствует себя на среднем рынке, но лезет на крупный.
The Microsoft Data Warehouse Toolkit – книжечка про ХД на базе MS’а от Кимбалла.
Ibm.com/start – открыт прием резюме на стажировку студентов в IBM, Student Internship
Проблемы в ETL:
1) Синхронизация справочников. Источников обычно много, и справочники у них свои, нет единого общего справочника. При слитии данных из них в одну БД возникает проблема синхронизации. Варианты решения:
a. Можно вообще не решать, но тогда не будет интеграции данных, це неудобно.
b. Реализовать синхронизацию самостоятельно – нарисовать таблицу маппинга, то есть целевую таблицу и связи с элементами из источников.
c. Заставить правильно составить справочники в источниках. Это практически невозможно.
d. Master data management – организовать общий, централизованный справочник.
2) Качество данных. Пользователям надо доказывать, что данные в отчетах (в ХД) адекватно получены из источников. Для этого нужно:
a. Профилирование – для того, чтобы понять, какие вообще есть данные и какие между ними существуют зависимости. Это позволяет задать такую структуру данных, которая поможет сделать данные более чистыми.
b. Прозрачность данных – то есть тенденция предоставлять пользователю информацию о том, как были получены конечные данные в отчете. До формулы по крайней мере. Это ценится юзерами. Это может осуществляться за счет:
i. Логирования
ii. Спецсредств ETL
3) Задержка данных. Вообще говоря работа ETL требует времени, поэтому между появлением данных на источнике и появлением их в приемнике может быть достаточно большой лаг. Это надо учитывать как бы. Это либо регулируется регламентом, либо прямым подключением средств BI к источнику данных.
Вообще значимыми являются первые 2 проблемы. Задержку еще не слишком сложно объяснить, а вот качество данных всех очень волнует.
Состав документации перед внедрением/созданием ETL:
1) Source interface definition (SID) – описание источника данных (определение требований):
a. Описание источника – что он вообще из себя представляет, какую информацию содержит.
b. Описание формата – какие таблицы, в каком формате, какие в них поля будут в том медиа, через которые будут загружаться данные. Тут хорошо работает буферная область – например, в источнике создается отдельная сецтабличка, из которой (и только из которой) ETL-средство будет брать данные.
c. Регламент загрузки – как грузим, с какой периодичностью, когда грузим, какой объем. Объем бывает:
i. Полный – грузим все, думать особо не надо, все хорошо работает на маленьких объемах
ii. Инкрементальный – загружаем каждый раз только измененную часть (подход CDC – changed data capture). Тут возникает проблема, как узнать, какие данные были изменены. Чтобы их найти, можно:
1. Смотреть даты изменений (логи), то есть захват изменений с помощью журнала СУБД (У MS’а появилось с 2005 версии).
2. Ведение кастомных логов.
3. Смотреть даты в табличках, если они есть.
4. Добавить даты в табличках, если их нет.
2) Куда мы это кладем
3) Описание алгоритмов преобразования
a. Маппирование справочников
b. Очистка данных (от лишних пробелов, символов)
c. Look-up’ы – подмена значений
Поговорим о ETL’е от MS’а – SSIS.
Архитектура.
Два потока (runtime engines):
1) Control flow
2) Data flow
Есть много connection manager’ов подключаться ко многим источникам.
Container – это совокупность нескольких задач.
Есть виды контейнеров:
1) Для каждого
2) По условию
3) Просто агрегация задач
Задачи – могут быть очень разными, вплоть до Scripting’а – запуска тупо кода на VB или C#, и формирования мэйлов. Есть также операции с XML документами.
DTS – это старое название SSIS (2000 версия).
Категории задач трансформации:
1) Построчная – копирование колонок, зависимость колонок, связи
2) Rowset – пайвоты и проч
3) Сплит и джоин – создание нескольких потоков данных из одного и наоборот, лукапы и проч
У остальных вендоров проектирование ETL такое же незатейливое, как у MS’а, отличается только визуально, а не по концепциии.
Лекция 4.
Поговорим об OLAP’е.
Вообще ОЛАП – это про всякие кубы данных и срезы по разным измерениям.
Смысл куба в том, что это не прсото табличка, а матрица. У нее первый столбец и первая строчка – это значения атрибутов. Посередине – цифры.
Типы:
1) Multidimensional OLAP (MOLAP) – и детальные данные хранятся в многомерной БД
2) Relational OLAP (ROLAP) – все хранится в реляционной БД, агрегаты хрятятся в служебных таблицах
3) Hybrid (HOLAP) – детальные данные хранятся в реляционнй БД, а агрегаты хранятся в многомерной БД.
Примеры многомерных БД: SSAS, Oracle Essbase, IBM TM1.
Смысл многомерных БД – это повысить производительность БД для анализа.
Но на данный момент из-за роста производительности железок разница в быстродействии невелика.
По идее ХД должно содержать агрегированную информацию и детальную. Первое удобнее хранить в многомерке, второе – в реляционной. Но при этом на трансфер из реляционной БД в многмерную тоже тратится время и ресурсы, поэтому сейчас, когда все можно релизовать на реляционной БД, это можно вполне делать.
MOLAP хранит только числа, в этом ограничение.
SSAS в принципе может реализовывать все типы OLAP’а.
Ключевое требование OLAP – поддержка иерархий и множественных иерархий
Операции с кубиками:
1) Slice and dice – взятие подкуба
2) Roll up -- сворачивание
3) Drill down – детализация данных в кубе
4) Pivot – транспонирование, различная визуализация одной и той же инфы
5) Drill through – переход к детальным данным, хранящимся в оперативной БД.
SSAS
2008 и 2005 SQL сервер – достаточно мощные продукты.
Есть два подхода – простой анализ и data mining.
MDX – аналог SQL для работы с многомерными БД. Разработка MS’а.
SSAS делает пре-агрегацию автоматически.
UDM – unified dimensional model – фишка МСа про то, чтобы процесс перехода от реляционной модели данных в многомерную (удобную пользователю, понятную по сути) был прозрачен.
Data Source View – это реляционное представление предметной области. Источников этих «взглядов» может быть несколько.
Партиции в кубах – это разбивка данных внутри кубов по способу хранения. Это используется для обновления данных.
Атрибуты могут быть организованны иерархии.
Группы атрибутов круче чем иерархии, так как понятнее.
Типы атрибутов:
1) Key
2) Parent key
3) Regular
Parent-Child иерерахии (несбалансированные) используют связь самих с собой, для того, чтобы задать начальников элементов таблицы из этой же таблицы.
Для каждой табицы фактов надо создавать свою группу.
Вырожденное измерение – то, которое строиться на основе таблицы фактов, а не собственной таблицы. Это удобно, когда атрибутов у измерения немного (1-2).
Вычисления бывают:
1) Calculated members
2) Named sets
3) Scoped assignments
Вычисления задаются на языке MDX.
Объекты OLAP состоят из трех типов данны:
1) Метаданные – описание объекта
2) Данные – элементы измерений, записи таблиц фактов
3) Агрегаты – пре-агрегированные данные таблиц фактов.
Все данные можно разбивать на патриции и обновлять только их.
Лекция 5.
MDX – multi dimensional expressions. Создан MS’ом, стал сейчас стандартом.
Основные понятия:
Куб (Cube)
Мера, факт, показатель (measure)
Член (Member) – элемент измерения
Кортеж (Tuple) – коллекция членов, набор элементов из разных измерений
Множество (Set) – множество кортежей
При обращении к члену через идентификатор, надо перед ним ставить символ “&”
Кортежи заключаются в ().
Перечисления кортежей (множества) заключаются в “{}”, диапазон задается с помощью “:”
Наборы из разных типов членов не могут существовать.
При запросе типа SELECT надо после каждого выбираемого поля указывать, куда их пихать – в колонки (on columns) или в строки (on rows). Также есть вообще говоря другие оси, их может быть аж до 128, первые пять имеют псевдонимы – columns, rows, pages, и еще что-то там.
WITH – это штука чтобы определять наборы. Это вроде как USING в c#. Так проще потом запрос писать. Экономии в вычислениях это не дает. =(
Функции:
Crossjoin – это тупо декартово произведение
Filter – это фильтр. =) Не срез, а именно фильтр. То есть сначала выбираем, а потом что-нибудь отбираем. Where же позволяет взять срез, там нельзя указать точное значение.
Topcount – это первые несколько значений.
Bottomcount – аналог только с сортировкой от меньшего к большему.
Функуции управления членами:
Default member – это обычно обращение к верхнему элементу
Prevmember и nextmember – это про предыдущей и последующие элементы в рамках иерархии, используется для задания функций.
ParallelPeriod это для задания смещений при сравнении данных за какие-то периоды
И так далее.
Функции управления наборами:
Children, Descendants(), Ascendants(),
Levels() – это для того, чтобы обращаться к элементам иерархии одного уровня.
Почитать Кинбалла – ETL, проектирование ХД, ЖЦ ХД, проектирование ХД в SQL Server 2008 R2.
Лекция 6
Жизненный цикл ХД – слайд со схемой в презентации.
Характерная черта – нет утилизации, вывода из эксплуатации.
1) Инициация проекта
2) Сбор бизнес-требований (business requirements definition). Тут у нас консалтинг, приоритезация требований и вся фигня.
3) Результатом этого сбора является некоторая таблица, в которой перечислены измерения и фактические области данных. Смысл в том, что по строкам пишутся факты, по столбцам – измерения, а на их пересечении ставится отметка, если факт относится к измерению.
4) Проектирование и разработка. Архитектура:
a. Техническая – программно-аппаратная часть внедрения.
b. Безопасность, архивирование, прочие нетехнические требования.
5) Развертывание, интеграция в предприятие.
Ну в общем это все не совсем так, правильно – на картинке со слайдов.
Успех создания ХД во многом зависит от качества ETL, которое очень сильно зависит от качества исходных данных. В общем. ETL – это очень важно. =)
Профилирование данных – это выяснение возможных значений, это делается перед созданием ETL.
Этапы проектирование DWH:
1) Определение фактов – это есть результат бизнес-анализа.
2) Добавление временнЫх ключей. Каждый факт должен иметь привязанность к времени. Можно добавить время в бизнес-ключ каждого факта и измерения, но это фигово, потому что ключ получится составным. Поэтому связку – бизнес-ключ, время – делают альтернативным ключом и вводят суррогатный ключ.
3) Добавление производных данных. Это то, что нету в оперативной БД, но обычно нужно при анализе.
4) Определение гранулярности данных – в смысле насколько мы можем сделать drillиться в эти данные вглубь.
5) Объединение измерений. Некоторые измерения, если вариантов атрибутов у них немного (до 5-и), можно объединить в одну табличку-измерение.
6) Создание массивов. Если нам не нужны точные, гранулированные данные, можно объединить их в группы по некоторому признаку. Если попадает у факта значение в диапазон, то он относится к группе. Пример – уровень дохода.
7) Агрегирование и разделение данных. Агрегаты могут храниться и в одной таблице с детальными данными, но чаще – в отдельной таблице.
Зачем делать время отдельным измерением – чтобы хранить доп. атрибуты, связанные с конретными днями.
Иерархии:
1) По отдельной таблице для каждого уровня иерархии
2) Parent-child (в одной таблице)
3) Отделение связи между parent и child ом в отдельную таблицу, обеспечивающую связь. Это круче всего, можно поддержать хранение истории изменения иерархии без изменения самого товара. Плюс возможность задать альтернативные иерархии – более одного родителя можно задать. Ну и еще много всякого стафа можно сделать. Получается 2 таблицы – смысловая и вспомогательная, обеспечивающая иерархию.
Что должно быть атрибутом, что должно быть отдельным измерением?
Есть несколько наборов атрибутов. Если между атрибутами отношение «многие-ко-многим», то они должны быть в разных измерениях. Если связь между атрибутами «один-ко-многим», то это одно измерение.
PowerDesigner – аналог ERWin’а, более мощное средство.
Лекция 7.
Роли заказчика и исполнителя при построении хранилищ данных. Их дофига всяких, можно посмотреть на «www.prj-exp.ru», там есть Матрица ответственности по ролям.
Для любых внедрений ИС, в том числе ХД главный чувак от заказчика – это куратор проекта.
Иерархия людей от исполнителя:
1) Куратор проекта
2) Руководитель проекта
3) Системный архитектор – отвечает за систему в целом. Эта роль может быть разделена на несколько людей, но всегда должен быть один чувак, который отвечает за всю систему.
4) Бизнес-аналитик – перевод бизнес-требований в функциональные требования
5) Архитектор по ETL и разработчики
6) Администратор БД
7) Администратор приложений
8) Архитектор ETL и разработчики
9) Архитектор BI и разработчики
Модель RACI
R – responsible (исполнитель, отвечающий за действие)
A – accountant – ответственный за качество выполненной работы
C – consultant
I – наблюдатель
При внедрении на этапе перед требованиями хорошо проводить обучение чуваков из команды заказчика дабы обеспечить единый язык и понимание между заказчиком и исполниетелем.
Проблемы (риски), возникающие при внедрении:
1) Качественные. Трудности во время анализа данных, проблемы с определением качества
2) Организационные. Тут часто бывает проблема с закрытостью систем, откуда мы берем информацию для ХД.
3) Технические. Необходимо выбрать адекватные задачам и размерам технологии.
Физическое моделирование ХД.
Тут имеется ввиду в основном оптимизация работы конкретных систем.
Техники оптимизации:
Денормализация бывает 2-х видов:
1) Нисходящая – внесение полей из более общей таблицы в более детализированную, зависимую таблицу. Это делается с целью минимизации использования связей. В общем виде это объединение таблиц.
2) Восходдящая – внесение полей из зависимой таблицы в родительскую. Это обычно вынесение агрегированных показателей. Делается для того же самого.
Разделение таблиц (изменение логики структуры БД):
1) Горизонтальное. Таблицы бьются по записям, чтобы в одной таблице было меньше записей. Часто бьется на текущие и архивные записи, то есть разбиение по времени.
2) Вертикальное. Разделение таблиц на несколько по атрибутам. Атрибуты, выделяемые в другие таблицы определяются по принципу частоты запрашивания их.
Партиции – это физическое разбиение таблицы на несколько файлов.
Индексы.
Расширения SQL. Group by и проч.
Тенденции.
1) БД в памяти.
2) Повышение прозрачности данных.
3) Интеграция BI с ERP