Хранилища данных (ХД): причины возникновения

Хранилища Данных Лекция 1. Хранилища данных (ХД): причины возникновения Вступление Эффективное управление крупным и средним бизнесом сегодня немыслимо без применения передовых информационных технологий – систем поддержки принятия решений (СППР). Процесс управления сводится к решению 3 задач: • Где мы находимся? • Куда мы хотим прийти? • Как мы туда попадем? Процесс управления носит итерационный характер: • принятие решения –> • применение управляющего воздействия –> • оценка состояния системы –> • оценка правильности выбранного решения –> • при наличии отклонений снова принятие решения. Вступление Современные информационные технологии позволяют аналитику формулировать и решать следующие классы задач: • Аналитические (вычисление заданных показателей и статистических характеристик) • Визуализация данных • Добыча знаний (data mining – проверка статистических гипотез, кластеризация, нахождение ассоциаций и временных шаблонов и т.п.) • Имитационные (проведение на ЭВМ экспериментов на моделях, описывающих поведение сложных систем, например, в интервалы времени для анализа возможных последствий принятия того или иного решения) Вступление • Синтез управления (для определения допустимых управляющих воздействий, обеспечивающих достижение заданной цели, оценка достижимости цели, определение множества возможных управляющих воздействий) • Оптимизационные (интеграция имитационных, управленческих, оптимизационных и статистических методов моделирования и прогнозирования, выбор наиболее эффективного решения) Вступление Однако в настоящее время нет информационных средств для решения всех задач в комплексе. Бизнес – это сложный объект, который состоит из множества различных по свойствам подсистем, между которыми действует большое число разнородных связей. В кибернетике такие объекты получили название сложных систем, а методы их изучения – системным анализом (эта наука развивается с начала 40-х гг. в период II-й Мировой Войны). Общая с точки зрения теории познания триада имеет вид: Гипотеза – Модель – Решение Вступление Гипотеза – это открытие, которое является новым положением, осуществляется на основе интуиции (из глубин человеческого подсознания, сформированного на основе личного опыта). По гипотезе строится модель – формальное математическое описание – и находится решение. Полученное решение проверяется в эксперименте (отвергается или принимается). В результате получается знание, которым можно руководствоваться в практике. Проблемы: • Динамичное изменение экономической ситуации мешает применять накопленный опыт, не успевает вырабатываться интуиция. • В условиях свободного рынка нет возможности проводить целенаправленные эксперименты. Вступление В настоящее время актуальна разработка и использование комплексного ПО, реализующего задачи 1, 2 и 3-го классов. Для их решения стремительно развиваются OLAP-технологии (On-Line Analytical Processing). OLAP – это инструменты оперативного анализа данных, содержащихся в хранилище, которые предназначены для общения аналитика с проблемой, а не с компьютером. Эволюция корпоративных информационных систем Развитие предприятий происходило без стратегического плана, снизу вверх по мере осознания необходимости автоматизации того или иного участка производства. Необходимым условием для автоматизации является появление: • информационных технологий; • аппаратно-программных средств; • людских ресурсов; • бюджетных средств. В большинстве компаний имеются информационные системы (ИС) на базе СУБД и обслуживают повседневную деятельность отделов компании. Такие ИС получили название транзакционных или OLТP (On-Line Transactions Processing). Эволюция корпоративных информационных систем Накопление больших объемов данных в последнее время сделали актуальными прикладные задачи, предназначенные для извлечения, сбора и представления конечному пользователю информации, необходимой для анализа текущего состояния дел и прогноза будущего решения. Такие ИС получили название систем поддержки принятия решений. Исторически первыми такими системами стали ИС руководителя (EIS – Executive Information Systems). Существует два подхода к интеграции корпоративной информации: • децентрализованное объединение источников (схема спагетти); • централизованное объединение источников. #1 Введение СППР • Существует особый класс систем – системы поддержки принятия решений (СППР) • Они предназначены для извлечения, сбора и представления конечному пользователю информации, необходимой для анализа текущего состояния дел и прогноза будущего решения • Основные пользователи – люди, принимающие решения или влияющие на их принятие (топ-менеджеры, аналитики) • В большинстве компаний имеются информационные системы на базе СУБД и обслуживают повседневную деятельность отделов компании – транзакционные или OLТP (On-Line Transactions Processing) Интеграция данных • Чтобы анализировать данные – надо их объединить • Два основных подхода: o децентрализованное объединение источников (схема спагетти) o централизованное объединение источников Основные понятия Ответственным за принятие корпоративных решений необходимо иметь доступ ко всем данным организации независимо от их расположения. Для • выполнения полного анализа деятельности организации, • определения ее деловых показателей, • выяснения характеристик существующего спроса, • тенденций изменения спроса. Причем необходимо иметь доступ не только к текущим данным, но и к ранее накопленным (историческим) данным. Для упрощения подобного анализа была разработана концепция хранилища данных (data warehouse). Основные понятия • Хранилища данных (Datawarehouse) и оперативный анализ данных (On-Line Analytical Processing, OLAP) – информационные технологии, которые обеспечивают аналитикам, управленцам и руководителям высшего звена возможность изучать большие объемы взаимосвязанных данных при помощи быстрого интерактивного отображения информации на разных уровнях детализации с различных точек зрения в соответствии с представлениями пользователя о предметном пространстве. • Основная цель хранилищ – создание единого логического представления данных, содержащихся в разнотипных БД или в единой модели корпоративных данных. Задачи ХД • Интеграция в одном месте, согласование и, возможно, агрегация ранее разъединенных детализированных данных: o Исторических архивов o Данных из оперативных систем o Данных из внешних источников • Разделения наборов данных, используемых для оперативной обработки, и наборов данных, используемых для решения задач поддержки принятия решений • Обеспечения всесторонней информационной поддержки максимальному кругу пользователей Описание ХД • Хранилище содержит сведения, поступающие из самых разных источников данных, функционирующих под управлением разных операционных модулей, а также различные накопительные и сводные данные. • Концепция хранилища данных базируется на усовершенствованной технологии баз данных и предусматривает специальные средства управления процессом хранения информации. • Ответственным за принятие корпоративных решений необходимо иметь мощные инструменты анализа накопленных данных. Основные средства анализа: o инструменты оперативной аналитической обработки (On-Line Analytical Processing – OLAP) o инструменты разработки данных (data mining). История вопроса • 1962 – фундаментальная книга Кена Айверсона (Ken Iverson) «A Programming Language (APL)» • 1970 – первый программный продукт для многомерного анализа данных – Express • 1988 – статья Девлина и Мэрфи (B. Devlin, Paul T. Murphy) «An Architecture for a Business and Information System» • 1992 – монография Уильяма Инмона (William H. Inmon) «Building the Data Warehouse» • 1993-1995 – статьи Эдгара Кодда (Edgar F. Codd) «12 правил OLAP» и «Дополнительные правила OLAP» • 1996 – монография Ральфа Кимбалла (Ralph Kimball) «The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses» #2 Определение ХД Определение по Инмону («в узком смысле») Хранилище данных – это предметноориентированная, интегрированная, вариантная по времени, не разрушаемая совокупность данных, предназначенная для поддержки принятия управленческих решений. Общее определение («в широком смысле») Хранилище данных – ориентированная на поддержку управленческих решений автоматизированная система, состоящая из организационной структуры, технических средств, базы или совокупности баз данных и ПО, которое выполняет, как правило, следующие функции: • извлечение данных из разрозненных источников, их трансформация и загрузка в хранилище; • администрирование данных и хранилища; • извлечение данных из хранилища, аналитическая обработка и представление данных конечным пользователям. Основные требования к ХД • Поддержка высокой скорости получения данных из хранилища • Поддержка внутренней непротиворечивости данных • Возможность получения и сравнения так называемых срезов данных (slice and dice) • Наличие удобных утилит просмотра данных в хранилище • Полнота и достоверность хранимых данных • Поддержка качественного процесса пополнения данных Развитие ХД Развитие хранилищ данных обусловлено: • Созданием развитого ПО оперативного анализа данных и нерегламентированных запросов пользователей. • Появлением новых типов БД на основе многомерной модели и параллельной обработки запросов, которые опирались на достижения в области распределенных систем и вычислений в памяти. • Появлением ПО промежуточного слоя, обеспечившие связь между разнотипными БД. • Резким снижением стоимости хранения информации. Проблемы разработки и сопровождения ХД • Недооценка ресурсов, необходимых для загрузки данных. • Скрытые проблемы источников данных. • Отсутствие требуемых данных в имеющихся системах. • Повышение требований конечных пользователей. • Унификация данных. • Высокие требования к ресурсам. • Владение данными. • Сложное сопровождение. • Долговременный характер проектов. • Сложности интеграции. #3 OLAP OLAP Системы поддержки принятия решений предоставляют пользователю агрегатные данные для различных выборок из исходного набора в удобном для восприятия и анализа виде. Агрегатные функции образуют многомерный (и, следовательно, нереляционный) набор данных (называемый гиперкубом или метакубом), оси которого содержат параметры, а ячейки – зависящие от них агрегатные данные. Вдоль каждой оси данные могут быть организованы в виде иерархии, представляющей различные уровни их детализации. OLAP Благодаря такой модели данных пользователи могут: • формулировать сложные запросы; • генерировать отчеты; • получать подмножества данных. OLAP – это ключевой компонент организации хранилищ данных OLAP: Тест FASMI FASMI – Fast Analysis of Shared Multidimensional Information – Быстрый анализ разделяемой многомерной информации. Fast: ответ на запрос в течение 1-20 с. Analysis: логический и статистический анализ для бизнес-приложений любой сложности. Shared: защищенный многопользовательский доступ. Multidimensional: многомерное представление данных, включая иерархии. Information: большое количество данных и информации. Реализация OLAP OLAP-функциональность может быть реализована различными способами, начиная с простейших средств анализа данных в офисных приложениях и заканчивая распределенными аналитическими системами, основанными на серверных продуктах. #4 Сравнение ХД и OLTP Сравнение ХД и OLTP СУБД, созданная для поддержки оперативной обработки транзакций (OLTP), обычно рассматривается как непригодная для организации хранилищ данных, поскольку к этим двум типам систем предъявляются совершенно разные требования. Системы OLTP проектируются с целью обеспечения максимально интенсивной обработки фиксированных транзакций. Хранилища данных проектируются прежде всего для обработки единичных произвольных запросов. Сравнение ХД и OLTP Сравнение ХД и OLTP Система OLTP Хранилище данных Содержание Текущие данные Исторические данные Хранение Подробные сведения Подробные сведения, а также частично и полностью обобщенные данные Данные Динамические В основном статические Способ обработки данных Повторяющийся Нерегламентированный, неструктурированный и эвристический Интенсивность обработки транзакций Высокая Средняя и низкая Способ использования данных Предсказуемый Непредсказуемый Предназначение Обработка транзакций Проведение анализа Ориентированность Прикладная область Предметная область Поддерживаемые решения Повседневные Стратегические Использование Работники front-end Руководство Сравнение ХД и OLTP OLAP – это надстройка над OLТP и использует транзакционные системы в качестве источников данных. Сравнение ХД и OLTP Система OLTP Хранилище данных Несколько различных систем OLTP Одно хранилище данных Оптимально подходит для интенсивной обработки транзакций, спроектированных заранее, многократно повторяющихся и связанных преимущественно с обновлением данных Предназначено для обработки относительно небольшого количества транзакций непредсказуемого характера и требующие ответа на произвольные, неструктурированные и эвристические запросы Данные организованы согласно требованиям конкретных деловых приложений и позволяют принимать повседневные решения большому количеству параллельно работающих пользователей-исполнителей Информация организована в соответствии с требованиями возможных запросов и предназначена для поддержки принятия долговременных стратегических решений относительно небольшим количеством руководящих сотрудников Сравнение ХД и OLTP Система OLTP Хранилище данных Системы OLTP Предназначены для получения быстрого ответа на произвольные запросы С помощью ХД можно получить ответы на запросы более сложные, чем запросы с простейшими обобщениями Какова средняя цена объектов недвижимости в крупнейших городах Великобритании? Как может повлиять на продажу объектов недвижимости в различных регионах Британии повышение юридических издержек на 3,5% и снижение государственных налогов на 1,5% при оформлении сделок с объектами недвижимости стоимостью свыше 100 000 фунтов? #5 Ключевые свойства ХД Общие свойства хранилищ  Ориентированность на предметную область или ряд предметных областей  Интегрированность  Зависимость от времени (поддержка хронологии)  Постоянство Ориентированность на предметную область Приложения всегда оперируют функциями, такими, например, как открытие сделки, кредитование, выписка накладной, зачисление на счет и т.д. Хранилище данных организовано вокруг фактов и предметов, таких, как сделка, сумма кредита, покупатель, поставщик, продукт и т.д. Интегрированность Проявляется в: • в согласованности имен, • в согласованности единиц измерения переменных, • в согласованности структур данных, • в согласованности физических атрибутов данных и др. Причины рассогласования: • наличие множества средств разработки, • существование множества способов построения приложения. Зависимость от времени Все данные в хранилище в определенный момент времени совместны (непротиворечивы). Оперативные приложения ориентированы на короткий временной промежуток, а аналитические – на большие промежутки (год, десятилетие и т.д.). Структура хранилища включает – явно или неявно – элемент времени. Данные, однажды корректно в хранилище записанные, не могут быть обновлены. Постоянство В оперативной среде операции обновления, добавления, удаления и изменения производятся над записями регулярно. Базовые манипуляции с данными хранилища ограничены начальной загрузкой данных и доступом к ним. На уровне проектирования хранилища данных отпадает необходимость в поддержке механизмов, обеспечивающих корректность обновлений. В хранилище данных не нужны функции оперативного резервного копирования и восстановления, обеспечения целостность данных, механизмы разрешения конфликтов и тупиковых ситуаций. #6 Базовая архитектура ХД Архитектура ХД Диспетчер загрузки Источник оперативных данных 2 Метаданные Высокая агрегация Низкая агрегация Диспетчер запросов Диспетчер ХД Источник оперативных данных 1 Инструменты формирования отчетов, запросов, разработки приложений и EIS Инструменты OLAP Подробные данные Диспетчер ХД Источник оперативных данных N Хранилище оперативных данных (ODS) Инструменты Разработки данных Данные архивной/ резервной копии Инструменты доступа конечного пользователя Архитектура ХД Диспетчер загрузки Источник оперативных данных 2 Метаданные Высокая агрегация Низкая агрегация Диспетчер запросов Диспетчер ХД Источник оперативных данных 1 Инструменты формирования отчетов, запросов, разработки приложений и EIS Инструменты OLAP Подробные данные Диспетчер ХД Источник оперативных данных N Хранилище оперативных данных (ODS) Инструменты Разработки данных Данные архивной/ резервной копии Инструменты доступа конечного пользователя Витрины данных Инструменты формирования отчетов, запросов, разработки приложений и EIS Агрегированные данные (реляционные) Инструменты OLAP Агрегированные данные (многомерные) Инструменты Разработки данных Хранилища Данных Лекция 2. Разработка архитектуры ХД Вступление Хранилища данных имеют ключевую специфику – они не являются коробочным продуктом. Поэтому проекты по построению хранилища данных имеют характер итеративной разработки и состоят из нескольких этапов: 1. Предпроектное обследование организации и сбор требований 2. Разработка архитектуры 3. Логическое моделирование 4. Физический дизайн баз данных хранилища и витрин данных 5. Разработка процедур наполнения хранилища и витрин данных 6. Разработка пользовательских приложений 7. Поддержка и развитие системы В этой лекции мы сконцентрируемся на важнейшем этапе – проектирование архитектуры. #1 Концептуальная архитектура Уровни данных При рассмотрении концептуальной архитектуры (архитектуры верхнего уровня) мы не аперируем типами данных, спецификой источников, контурами расположения тех или иных имеющихся ИС и пр. Мы будем рассматривать архитектуры корпоративного хранилища данных в контексте шести уровней данных: • • • • • • Источники данных Извлечение-Преобразование-Загрузка Хранение данных Выборка-Реструктуризация-Доставка Предоставление данных Бизнес-приложения Несмотря на то, что отдельные компоненты могут отсутствовать, уровни в том или ином виде сохраняются. Уровни данных Концептуальные архитектуры Мы рассмотрим следующие архитектуры: Виртуальные хранилища данных Независимые витрины данных Централизованное хранилище данных с ETL Централизованное хранилище данных с ELT Централизованное ХД с ОCД Расширенная модель с витринами данных Централизованная ETL с параллельными ХД и ВД • Хранилище с накоплением данных в витринах • Хранилище данных с интеграционной шиной • Итоговая архитектура КХД • • • • • • • Виртуальное хранилище Виртуальное хранилище Первая идея – это сокращение расходов. Вторая идея – надо работать с самыми свежими данными. Аналитические системы должны напрямую работать с источниками данных, минуя всех посредников. Третья идея – мы сами все напишем. В итоге получаем жесткую связь между источниками данных и аналитическими приложениями. Любое изменение в источнике данных должно согласовываться с разработчиками универсального клиента с тем, чтобы избежать передачи искаженных и неверно интерпретируемых данных в аналитические программы. На каждом рабочем месте необходимо поддерживать набор интерфейсов доступа к различным системамисточникам. Независимые витрины данных Независимые витрины данных Преимуществом создания независимых витрин является легкость и простота их организации, так как каждая из них оперирует с данными одной задачи, и поэтому не возникает проблем с метаданными и НСИ. Данные просто копируются на регулярной основе из транзакционной системы в витрину данных. Но информация в витринах не согласована. Каждая витрина унаследовала от транзакционной системы свою терминологию, свою модель данных, свою нормативносправочную информацию, в том числе, кодировку данных. Таким образом, все преимущества независимых витрин данных исчезают при первом же требовании пользователей работать с данными из нескольких витрин. Централизованное ХД с ETL Централизованное ХД с ETL Средства ETL должны знать все об источниках данных: структуры хранящихся данных и их форматы, различия в алгоритмах обработки данных, смысл хранящихся данных, график выполнения обработки информации в транзакционных системах. Игнорирование этих данных о данных (метаданных) неизбежно приводит к ухудшению качества информации, загружаемой в хранилище. По мере роста числа источников данных и объема обрабатываемых данных необходимо отделить средства управления НСИ от средств ETL, и обеспечить их эффективное взаимодействие. ETL vs ELT Порядок исполнения операций, а также место физического преобразования данных качественно влияет и на производительность, и на сам принцип меппинга данных Централизованное ХД с ELT Централизованное ХД с ELT Применение схемы ETL позволяет полностью разнести функции обработки и хранения данных. Схема ELT нагружает центральное хранилище данных несвойственными ей функциями преобразования данных. В результате переноса функциональности от ETL в ЦХД нам необходимо не только обеспечить ту же вычислительную производительность, но и спроектировать универсальную платформу, способную равно эффективно обрабатывать данные и хранить их. Применение ELT вместо ETL оправдано, если: • Нет жестких требований к надежности, производительности и защищенности хранилища. • Бюджетные ограничения вынуждают идти на риск утраты данных. • Хранилище данных и источники данных взаимодействуют через сервисную шину (SOA). Централизованное ХД с ODS Централизованное ХД с ODS Оперативный склад данных (ODS) был предложен с тем, чтобы сократить время задержки между поступлением информации из ETL и аналитическими системами. ODS располагает менее точной информацией из-за отсутствия внутренних проверок, и более детальными данными из-за отсутствия этапа консолидации данных. Поэтому данные из ODS предназначены для принятия тактических решений, тогда как информация из центрального хранилища данных (ЦХД) лучше подходит для решения стратегических задач. Отсутствие витрин данных помогает тактикам быстрее получить доступ к данным, но прямая работа пользовательских программ с ЦХД допустима, если пользовательские запросы не препятствуют нормальному функционированию ЦХД, если между пользователями и ЦХД имеются высокоскоростные линии связи, и если случайный доступ ко всем данным не ведет к серьезным потерям. Расширенная модель с ВД Расширенная модель с ВД Разные пользовательские приложения нуждаются в различных форматах данных: многомерные кубы, ряды данных, двумерные массивы, реляционные таблицы, файлы в формате MS Excel, текстовые файлы с разделителями, XML-файлы и т.д. Никакая структура данных в ЦХД не может удовлетворить этим требованиям. Выходом является создание витрин, чьи структуры данных оптимизированы под специфические требования отдельных приложений. Еще одной причиной необходимости создания витрин данных является требование к надежности КХД, которое часто определяется, как пять или четыре девятки. Это означает, что КХД может простаивать не более 5 минут в год (99,999%) или не более часа в год (99,99%). Создание комплекса с такими характеристиками является сложной и весьма недешевой инженерной задачей. Расширенная модель с ВД Если витрины наполняются напрямую из ЦХД, то фактическое количество пользователей снижается с сотен и тысяч до десятков витрин, которые и являются пользователями ЦХД. При использовании средств SRD (Sample, Restructure, Delivery – выборка, реструктуризация, доставка) количество пользователей сокращается до 1. В этом случае вся логика информационного снабжения витрин сосредотачивается в SRD. Витрины могут быть оптимизированы под обслуживание пользовательских запросов. Программнотехнический комплекс КХД может быть оптимизирован исключительно под надежное, защищенное хранение данных. Средства SRD также смягчают нагрузку на ЦХД за счет того, что разные витрины могут обращаться к одним и тем же данным, тогда как SRD извлекает данные один раз, преобразует к различным форматам и доставляет в разные витрины данных. Централизованная ETL с параллельными ХД и ВД Централизованная ETL с параллельными ХД и ВД В данном случае система ETL является центром, вокруг которого строится вся архитектура КХД. Информация из разнородных источников поступает в ETL, которая загружает очищенные и согласованные данные в ЦХД, в ODS и, при необходимости, в зоны временного хранения. Это обычная практика для КХД. Необычным является загрузка данных из ETL напрямую в витрины данных. На практике такая архитектура возникает из-за требований скорейшего, без временных задержек, доступа к аналитическим данным. Использование ODS не решает задачи, так как пользователи могут находиться в другом регионе, и им требуется территориальная витрина данных. Другой причиной может стать запрет на размещение разнотипной информации в ODS по соображениям безопасности. Централизованная ETL с параллельными ХД и ВД Информация, попавшая в витрину данных напрямую из ETL, может противоречить данным, поступившим из ЦХД. В качестве решения иногда в витрине реализуют те же алгоритмы верификации данных, что и в ЦХД. Недостатком является необходимость поддержки и синхронизации одних и тех же алгоритмов в ЦХД и в витринах, питающихся непосредственно от ETL. Таким образом, параллельные ВД приводят к повторной обработке данных, к созданию избыточных операционных архивов, к поддержке дублирующих приложений и децентрализации обработки данных, что, как правило, является причиной рассогласования информации. Тем не менее, параллельные витрины имеют право на существование в тех случаях, когда оперативность доступа к аналитической информации важнее недостатков этой архитектуры. ХД с накоплением данных в ВД ХД с накоплением данных в ВД Основанием для появления этой архитектуры явились следующие предпосылки: 1. Некоторые компании до сих пор внедряют и эксплуатируют разрозненные прикладные витрины данных. Качество данных в этих витринах удовлетворяет аналитиков, работающих с витринами. 2. В некоторых компаниях сложилось мнение, что создание КХД сопряжено с непредсказуемыми последствиями. 3. Требование быстрых результатов. Необходимость отчитываться ежеквартально вызывает потребность в быстрых осязаемых результатах. В результате появляется стремление сделать и внедрить какоенибудь ограниченное решение без связи с остальными задачам. ХД с накоплением данных в ВД В итоге, пользователи независимых прикладных витрин говорят на разных языках бизнеса, и каждая витрина содержит собственные метаданные. Другая проблема заключается в различии нормативно-справочной информации (НСИ), используемых в независимых витринах данных. Разница в кодировке данных, в используемых кодификаторах, справочниках, классификаторах, идентификаторах, нормативах и словарях делает невозможным объединение этих данных без серьезного анализа, проектирования и разработки средств ведения НСИ. Тем не менее, эта архитектура имеет право на существование, там, где единая модель данных или не нужна, или невозможна, и где в ЦХД передается сравнительно небольшой объем данных без необходимости детализации их происхождения и исходных составляющих. ХД с интеграционной шиной ХД с интеграционной шиной Широкое распространение сервисориентированной архитектуры (SOA) привело к желанию использовать ее в решениях для КХД вместо средств ETL в ЦХД и вместо средств SRD в витрины данных. Интеграционная шина, которая лежит в основе SOA, предназначена для интеграции вебсервисов и приложений и выполняет следующие задачи: • Определяет сервис, соответствующий запросу от источника, и направляет запрос к сервису. • Преобразует транспортные протоколы между источником запроса и сервисом. • Преобразует форматы сообщений между источником запроса и сервисом. • Управляет бизнес-событиями различных источников. ХД с интеграционной шиной При такой архитектуре в разы возрастет нагрузка на системы-источники данных, так как одна и та же информация будет многократно передаваться по запросам в ЦХД, ODS, зоны временного хранения и системы управления метаданными и НСИ. Во-вторых, регламент сбора информации, ранее централизованный в ETL, теперь рассеян по приложениям, запрашивающим данных. Рано или поздно возникнут рассогласования в регламентах сбора данных для ЦХД, ODS, систем ведения НСИ и метаданных. Данные, собранные по разным методикам, в разные отрезки времени, обработанные по разным алгоритмам, будут несогласованны друг с другом. Тем самым будет разрушена основная цель создания ЦХД как единого источника согласованных непротиворечивых данных. ХД с интеграционной шиной Таким образом, интеграционная шина может быть использована в архитектуре КХД как транспортная среда между источниками данных и ETL и между SRD и витринами данных в тех случаях, когда компоненты КХД территориально разнесены и находятся за межсетевыми экранами в соответствии со строгими требованиями к защите информации. В этом случае для обеспечения взаимодействия достаточно, чтобы был разрешен обмен по протоколам HTTP/ HTTPS. Вся логика сбора и преобразования информации должна быть попрежнему сосредоточена в ETL и SRD. Итоговая архитектура КХД Итоговая архитектура КХД Главное преимущество этой архитектуры – предоставление доступа для удобной работы пользователей с необходимым объемом данных, возможность быстрого восстановления содержимого витрин из ЦХД при сбое витрины, обеспечение работы пользователей при отсутствии связи с ЦХД. Средства ETL обеспечивают полный, надежный, точный сбор информации из источников данных благодаря сосредоточенной в ETL логике сбора, обработки и преобразования данных и взаимодействию с системами ведения метаданных и НСИ. Система ведения метаданных поддерживает актуальность бизнес-метаданных, технических, операционных и проектных метаданных. Итоговая архитектура КХД Система ведения НСИ является третейским судьей при разрешении конфликтов кодировок данных. ЦХД несет только нагрузку по надежному защищенному хранению данных. Структура данных в ЦХД оптимизирована исключительно с целью обеспечения эффективного хранения данных. SRD в такой архитектуре являются единственным пользователем ЦХД, беря на себя всю работу по заполнению витрин данных и, тем самым, снижая нагрузку на ЦХД по обслуживанию запросов пользователей. Витрины данных содержат данные в структурах и форматах, оптимальных для решения задач пользователей данной витрины. Архитектурные принципы Основные принципы, которым должна следовать архитектура КХД: • Качество данных, которое можно понимать, как полные, точные и воспроизводимые данные, доставленные в срок туда, где они нужны. Качество данных трудно измерить напрямую, но о нем можно судить по принимаемым решениям. То есть, качество данных требует инвестиций, но и само способно приносить прибыль. • Защищенность и надежность хранения данных. Ценность информации, накопленной в КХД, может быть сравнима с рыночной стоимостью компании. Несанкционированный доступ к КХД чреват серьезными последствиями, поэтому должны быть приняты меры, адекватные ценности данных. Архитектурные принципы Основные принципы, которым должна следовать архитектура КХД: • Данные должны быть доступны сотрудникам в объеме, необходимом и достаточном для выполнения своих функциональных обязанностей. • Сотрудники должны иметь единое понимание данных, то есть должно быть установлено единое смысловое пространство. • Необходимо, по возможности, устранить конфликты в кодировках данных в системах источниках. Принципы организации КХД Проблемно-предметная ориентация Данные объединяются в категории и хранятся в соответствии с областями, которые они описывают, а не с приложениями, которые они используют. Интегрированность Данные объединены так, чтобы они удовлетворяли всем требованиям предприятия в целом, а не единственной функции бизнеса. Некорректируемость Данные в хранилище данных не создаются: т.е. поступают из внешних источников, не корректируются и не удаляются. Зависимость от времени Данные в хранилище точны и корректны только в том случае, когда они привязаны к некоторому промежутку или моменту времени Вендорные практики Microsoft – замкнутая цепочка продуктов Проблемные места: ETL, ODS, НСИ, Метаданные Вендорные практики Oracle – замкнутая цепочка продуктов Проблемные места: ETL, ODS, НСИ, Метаданные Отраслевые практики CRM-based отрасли Проблемные места: ODS, DDS, Витрины Отраслевые практики SRM-based отрасли Проблемные места: ODS, DDS, Витрины Отраслевые практики SCM-based отрасли Проблемные места: ETL, DDS, Метаданные, НСИ Отраслевые практики ERP-based отрасли Проблемные места: Метаданные, НСИ #2 Техническая архитектура КХД Слои данных в КХД • Primary Data Layer: Staging Area и Operational Data Store • Core Data Layer: ЦХД и НСИ (возможно отдельно, а возможно интегрировано в ЦХД) • Data Mart Layer: витрины данных (регулярные и операционные) • Service Layer: метаданные, DQ, средства мониторинга и диагностики Staging Area Область временного хранения данных является промежуточным слоем между источниками данных и областью постоянного хранения. В данной области сохраняются извлеченные из операционных систем-источников (СУБД, csv, dbf, xml файлов, web-сервисов и т.д.) данные, производится их очистка, трансформация, обогащение, подготовка к загрузке в область постоянного хранения. Зачастую очередной цикл обработки и загрузки данных в хранилище не может быть начат пока не будут извлечены все необходимые данные из различных системисточников, а в силу ряда причин (географической распределенности, разных циклов функционирования систем и т.п.) данные в источниках могут быть доступны в разные моменты по времени. Область временного хранения служит для сбора всех необходимых данных перед началом трансформации. Staging Area Одной из наиболее важных задач при построении хранилища данных является определение соответствия (mapping) сущностей системисточников данных и сущностей модели хранилища данных. Обычно подобное соответствие представляет собой отношение десятков (а иногда и сотен) таблиц системисточников к десяткам таблиц области постоянного хранения данных. Правильно организованная область временного хранения данных позволяет значительно упростить организацию процессов загрузки данных из области временного в область постоянного хранения. Operational Data Store Роль этого компонента – интеграция с системами-источниками, загрузка и хранение первичных данных, а также предварительная очистка данных: проверка на соответствия правилам форматно-логического контроля, зафиксированных в «соглашении об интерфейсе взаимодействия» с источником. Кроме того, данный компонент решает очень важную для хранилища задачу – выделения «истинной дельты изменений» – не зависимо от того, позволяет ли источник отслеживать изменения в данных или нет и каким образом. Как только данные попали в ODS – для всех остальных слоев вопрос выделения дельты уже понятен – благодаря маркировке метаатрибутами. Данные в этом слое хранятся в структурах, максимально близких к системе-источнику – чтобы сохранить первичные данные как можно ближе к их первозданному виду. Detail Data Store Область постоянного хранения данных в себя включает: • Детальные данные (System of records) – область хранения детальных данных, приведенных к структуре модели данных корпоративного хранилища, прошедших очистку и обогащение • Агрегаты (Summary area) – сгруппированные по времени (чаще просуммированные) детальные данные Data Mart Слой Витрин отвечает за подготовку и предоставление данных конечным потребителям – людям или системам. На этом уровне максимально учитываются требования потребителя – как логические (понятийные), так и физические. Сервис должен предоставлять ровно то, что необходимо – не больше, не меньше. Если потребителем является внешняя система, то как правило, она диктует те структуры данных, которые ей необходимы и регламенты забора информации. Хорошим подходом считается такой, при котором за корректный забор данных отвечает сам потребитель. Хранилище данные подготовило, сформировало витрину, обеспечило возможность инкрементального забора данных (маркировка мета-атрибутами для последующего выделения дельты изменений) через SRD, а системапотребитель далее сама управляет и отвечает за то, как она этой витриной пользуется. Metadata Метаданные хранилища включают в себя: • информацию о данных, их бизнес-описание и структуру хранения; • описание структур источников данных, их доступности; • информацию о структуре процессов ETL, периодичности их выполнения, применяемых правил очистки и преобразования данных; • описание бизнес-представления данных, помогающее пользователю работать с BIприложением; • информацию о настройках безопасности, правил аутентификации и назначенных прав доступа; • статистику утилизации ресурсов, обращений к данным и др., которая помогает администратору оптимизировать работу базы данных хранилища. #3 Источники данных Источники по типу хранения • Реляционные данные Прямая бесшовная интеграция • Текстовые файлы (в том числе XML) Прямая бесшовная интеграция • Файлы Microsoft Excel Прямая бесшовная интеграция только от некоторых Вендоров, в остальных случаях требуются драйвера и повышается нагрузка на ETL процессы • OLAP-кубы Бесшовная интеграция только от Вендора, в остальных случаях требуются драйвера и повышается нагрузка на ETL процессы, а также требуется отдельный контур интеграции (риски) • Веб-каналы данных Требуется отдельный контур безопасности, при высокой частоте обращения заводят отдельный ODS • Нереляционные данные JSON преобразование, отдельный ETL, отдельный ODS Источники по типу обновления • OLTP-источники Обновление онлайн, как правило, по факту каждой транзакции, синхронизация с ETL не требуется • Batch-источники Обновление онлайн, как правило, по факту формирования очередного пакета данных, синхронизация с ETL не требуется • Периодически обновляемые по расписанию Необходима синхронизация с ETL на основе грануляции времени • Периодически обновляемые вручную Необходима синхронизация с ETL на программной основе (например, триггеры) Источники по типу интеграции • Поставщик данных Источник для дальнейшей модификации, хранения и выгрузки во внешние системы • Получатель данных Потребитель данных из КХД • Гибридное взаимодействие И поставщик, и получатель #4 Подход к реализации Бизнес-требования Функциональная спецификация Проектирование Архитектура КХД рассматривается в четырех аспектах: • Логическая архитектура. Представляет архитектуру системы с точки зрения пакетов базовых классов и их взаимосвязей. Определяются автоматизируемые процессы и функции, необходимые для достижения поставленных целей, которые затем разделяются на задачи, подлежащие реализации на стадии разработки. • Архитектура процессов. Определяет информационное обеспечение системы – состав и содержание процессов преобразования и передачи данных. • Компонентная архитектура. Представляет архитектуру ПО системы, ее декомпозицию на подсистемы и компоненты. • Техническая архитектура. Описывает физические узлы системы и связи между ними. Логическая архитектура Интеграция ранее разъединенных детализированных данных: • исторических архивов, • данных из оперативных систем, • данных из внешних источников. Разделение наборов данных, используемых для оперативной обработки, и наборов данных, используемых для решения задач поддержки принятия решений. Архитектура процессов Пять классов данных: • источники данных, • оперативный склад данных, • хранилище данных, • витрины данных, • репозитарий метаданных. На основе анализа прецедентов использования системы, выявленных на прошлых этапах, определяются представления данных конечным прикладным пользователям системы: состав показателей и их разрезы. Осуществляется сегментация представлений данных в соответствии с их проблемной ориентацией. Архитектура процессов Обследование источников данных: • Если имеется более одного источника, то следует ли определить, какой из них лучше? • Какие преобразования необходимо выполнить, чтобы приготовить источник к загрузке в хранилище? • Согласуются ли структура источника и структура хранилища? • Насколько согласуются данные источника с нормативно-справочной информацией? • Что будет происходить, если источник имеет несколько месторасположений? • Насколько аккуратны данные источника? • Как источник обновляется? • Каковы возраст и перспективность источника? • Насколько полны данные? • Что потребуется для интеграции данных источника в поток загрузки? • Какова технология хранения данных в источнике? • Насколько эффективно может осуществляться доступ к источнику? Архитектура процессов На основе выполненного анализа принимаются следующие архитектурные решения: 1. Определяются состав, содержание и источники потоков данных, которые будут поступать из источников в хранилище. 2. Определяются преобразования, которые должны быть выполнены над данными при загрузке, а также периодичность загрузки данных в хранилище. 3. При необходимости проектируются структуры оперативного склада данных и транзитных файлов. 4. Выявляются данные, которые отсутствуют в источниках информационного хранилища. Для таких данных, как правило, проектируются процедуры и регламенты ручного ввода. Компонентная архитектура Система на самом верхнем уровне состоит, как правило, из двух видов ПО: общего и специального. К общему ПО относятся: • ПО промежуточного слоя, которое обеспечивает сетевой доступ к приложениям и БД. Сюда относятся сетевые и коммуникационные протоколы, драйверы, системы обмена сообщениями и пр. • ПО загрузки и предварительной обработки данных. Этот уровень включает в себя набор средств для загрузки данных из OLTP-систем и внешних источников. Проектируется, как правило, в сочетании с дополнительной обработкой: проверкой данных на чистоту, консолидацией, форматированием, фильтрацией и пр. • Серверное ПО. Представляет собой ядро всей системы. Оно включает в себя серверы РБД, серверы МБД, серверы приложений (поисковые, аналитической обработки, добычи знаний и др.). Компонентная архитектура Специальное ПО представляет собой совокупность программ, которые объединяются в следующие подсистемы: • Подсистему загрузки данных • Подсистему обработки запросов и представления данных • Подсистему администрирования В этой части должны быть спроектированы модули, составляющие подсистему, и алгоритмы отдельных процедур, входящих в их состав. Техническая архитектура Серверное ПО работает под управлением серверов приложений и серверов БД. Клиентское ПО устанавливается на ПК конечных пользователей. В основном в приоритете технологии «тонкого» клиента, при которой на ПК пользователя находится лишь Web-браузер, а вся функциональность клиентского ПО загружается с сервера приложений в виде JavaScript-программ или апплетов. Техническая архитектура во многом зависит от масштабов и требований, предъявляемых к ее производительности и надежности. Реализация Внедрение Общая схема реализации КХД Типичные проблемы • Если не трогать – все работает. Как только требуется внести изменение – начинаются «локальные обвалы». • Данные загружаются ежедневно, по регламенту, в рамках одного большого процесса. Если вдруг возникает сбой – это требует ручного вмешательства. • Накатили релиз – получили проблемы. • Один источник не смог вовремя отдать данные – ждут все процессы. • Целостность данных контролирует база данных – наши процессы падают с ошибкой, когда она нарушается. • У нас очень большое хранилище – 2000 таблиц в одной общей схеме. И еще 3000 в множестве других схем. Мы уже слабо представляем, как они устроены и по какому поводу появились. Приходится многие задачи решать заново, поскольку, так проще и быстрее (чем разбираться «в чужом коде»). В итоге имеем расхождения и дублирующийся функционал. Типичные проблемы • Мы ожидаем, что источник будет давать качественные данные. Но оказывается, что это не так. • Пользователь требует обоснования той или иной цифры, но у нас не предусмотрено средств «сквозного анализа» (data lineage). • Как развивать систему постепенно, не уходя в разработку «ядра системы» на целый год? • Должны ли мы сохранять данные, или историю их изменений, если «бизнесу они не нужны»? • Нужно ли пытаться унифицировать данные на хранилище, если у нас есть система управления НСИ? Если есть МДМ, означает ли это, что теперь вся проблема с мастерданными решена? • У нас скоро ожидается замена ключевых учетных систем. Должно ли хранилище данных быть готовым к смене источника? Как этого достичь? Типичные проблемы Чувствительность КХД к обозначенным выше проблемам является свойством хрупкости КХД (fragile). Залог антихрупкости КХД – адаптивность, заложенная в самой архитектуре. Заключение Заключение • Рассмотрены типовые концептуальные архитектуры КХД, а также отраслевые практики • Раскрыта техническая архитектура КХД и описаны соответствующие слои данных • Рассмотрены ключевые этапы проектирования КХД и возникающие типовые проблемы Хранилища Данных Лекция 3. Архитектура аналитического Ландшафта дата платформ. Хранилища данных #1 Источники данных Транзакционные системыисточники Системы-источники данных телеметрии Формат данных из источника • • • • • Файловые СУБД (JDBC и ODBC драйвера) REST-сервисы SOAP-сервисы Event-based СУБД • Основные функции СУБД • JDBC и ODBC драйвера Источники данных через веб-интерфейс • REST-сервис • SOAP-сервис • Event-driven #2 Форма хранения Data Lake Data Hub • Общая модель данных • Сбор данных из нескольких источников • Поддержка операционных и транзакционных приложений Витрина данных • • • • Меньший объем данных Упрощенный доступ к данным Гибкость Сегментирование данных BI-инструментарий • • • • Хранение Интеграция Анализ Визуализация DWH Real-time analytics • • • • Формирование операционных решений Мониторинг показателей Прогнозная аналитика Одновременное представление исторических и текущих данных #3 Мастер-данные MDM, DQ, НСИ DQ Хранение основных данных НСИ Что такое мастер данные Мастер-данные – это согласованный и унифицированный набор сущностей (идентификаторов) с атрибутами, который описывает основные объекты компании, включая продукты, клиентов, поставщиков и прочее. o Мастер-данные, в отличие от ЛОКАЦИИ транзакционных, • Магазины редко изменяются • Офисы o Мастер-данные часто • Заводы представляют собой • Региональные отделения «разрезы» отчетности • Координаты (GIS) (продажи по определенному SKU) o Мастер-данные, как КОНТРАГЕНТЫ правило, имеют • Клиенты долгий срок жизни и • Сотрудники используются • Вендоры • Поставщики одновременно во многих приложениях и • Торговые партеры системах, как операционных, так и аналитических o Могут быть иерархичными (зонтичный бренд – бренд – SKU) ОБЪЕКТЫ • • • • • Продукты Оборудование Комплектующие Счета Активы ГРУППЫ • Территории продаж • Структура организации • Прайс-лист • Сегментация клиентов Мастер данные в организации Потребители данных Reporting Продажи, Заказы, Чеки Ценообразование, маршрутизация документооборота Товар, Поставщик, Клиент План счетов/статей учёта, профит/кост центры Отчетность (в случае аналитического MDM), Интеграционная платформа (в случае операционного MDM) Transactional Data Транзакционные данные, зависимые от мастер данных Conditional Master Data Master data Key reference data Информация, применяемая в зависимости от каких-либо условий (напр., зависимость цены от клиента и товара) Определение товаров, поставщиков, клиентов и их взаимодействие внутри организации Определяющие данные для всех элементов Управление качеством данных Неотъемлемой частью системы управления мастер-данными является управление качеством данных Основные шаги и активности процесса управления качеством данных по методологии Аксенчер: Процесс управления качеством данных Оценка Чистка •Профилирование данных с использованием специализированных инструментов •Основана на статистической обработке больших объемов данных •Анализ, сравнение и сопоставление данных хранящихся в гетерогенных СУБД и прочих системах •Результаты сохраняются в репозитории •Доработка систем и процессов ввода данных •Ручная коррекция •Использование инструментов ETL для исправления типовых ошибок •Использование специализированных инструментов использующих вероятностные методы и внешние базы данных (ФИАС) Удаление дубликатов •Определение возможных дубликатов •Автоматическое и ручное объединение дубликатов в мастерзапись и внесение соответствующих изменений в исходные базы данных •Формирование и поддержка ссылочных таблиц для предотвращения появления дубликатов в будущем Дополнение •Дополнение исходных данных информацией из внешних источников таких как -Телефонные справочники -ФИАС -Маркетинговые агентства -Демография и т.п. Аудит •Контроль качества осуществляемый на регулярной основе •Метрики оценки включают все аспекты качества данных •Результаты аудита сохраняются для выявления тенденций •Автоматический процесс выполняемый в ключевых контрольных точках ИТ Система управления качеством данных (DQ services) #4 Корпоративные хранилища данных Слои данных в КХД • • • • • Stage (stg) ОDS PreDDS DDS DM Staging и ODS слой • Staging – временное хранение данных • ODS – историчность PreDDS и DDS слой • • • • Целостность Нормализация Обработанный вид Только для чтения DM слой #5 Современные подходы к проектированию хранилищ данных Современные подходы к проектированию хранилищ данных • • • • • Dimensional Modeling Подход Билла Инмона Подход Ральфа Кимбалла Data Vault 2.0 Anchor Modeling Dimensional Modeling Достоинства Dimensional Modeling • Понятность • Быстрое чтение данных • Масштабируемость Модели типа «звезда» и «снежинка» Звезда Снежинка Подход Билла Инмона Corporate Information Factory (СIF) Пример подход Билла Инмона Подход Ральфа Кимбалла Data Warehouse Bus Пример подхода Ральфа Кимбалла Гибридный подход Hybrid Approach Пример гибридного подхода Сравнение подходов Кимбалла и Инмона Инмон Кимбалл • Гибкость • Низкая избыточность • Единый источник данных • Логическая модель точнее описывается более подробно описывает бизнеспроцессы • Скорость разработки • Скорость выполнения запросов • Разделение на таблицы в схеме звезда позволяет обеспечить более простой доступ к данным • Простота поддержки Data Vault 2.0 Хаб Таблицы-Ссылки Таблицы-Сателлиты Принцип работы Data Vault 2.0 • Обработанные данные попадают в RDV из Stage area • Business Vault • Data Marts Преимущества и недостатки Data Vault 2.0 Преимущества Недостатки • Гибкость и масштабируемость • Agile-подход из коробки • Высокая сложность • Обилие JOIN'ов Anchor Modeling • • • • Якорь Атрибут Связь Узел Пример использования Anchor Modeling Data vault vs Anchor Modeling Data vault Anchor Modeling Преимущества • Гибкость и масштабируемость • Хорошая читаемость схемы данных Преимущества • Привязка к бизнеспроцессам и хорошая визуализация Недостатки • Трудность в понимании бизнес-процессов Недостатки • Большое число таблиц • Трудность в чтении схемы • Сложность масштабирования Хранилища Данных Лекция 4. Проектирование. Этап логического моделирования Вступление Логическое проектирование базы или хранилища производится после получения концептуальной схемы объектов в предметной области предприятия. Является «каркасом» для хранения данных с минимальными затратами на изменение и максимальной эффективностью для извлечения. Логическая схема позволит быстро и наглядно объяснить команде как связаны между собой объекты вместо десятка страниц текста. Вам – убедиться, что структура обеспечивает целостность, непротиворечивость и эксплуатационную пригодность. #1 Цели и задачи логического проектирования Цель логической схемы Наглядно представить объекты предметной области и связи между ними в терминах хранения данных в СУБД     Кратко Однозначно Быстро Емко Дать описание того с чем работает БД и как связаны между собой данные. Исключить ошибочное толкование требований из ФТ. Этапы проектирования Составление концептуальной схемы Процесс создания проходит несколько последовательных вех. Постепенно разрешаются конфликты связей. В схеме детализируют атрибуты. Используют приемы оптимального размещения для реляционных БД. Логическая схема Концептуальная схема Выделяем объекты и действия в предметной области. Располагаем их на концептуальной схеме. Кластеризуем отношения в известные домены. 1 На основе концепта добавляем атрибуты, поводим нормализацию, выявляем аномалии, избавляемся от составных ключей и разрешаем N:N связи 3 2 Анализ предметной области Проводится анализ предметной области. Описываются кейсы использования данных и типичные вопросы, которые необходимо решать с помощью БД 5 4 Диаграмма потоков данных Создаем диаграмму потоков данных. Ищем расхождения с концептуальной схемой. Валидация Проводим валидацию на реальном кейсе с последующей модификацией схемы в случае необходимости Риски ошибок проектирования Логическая схема должна быть сбалансирована по нагрузке чтения\записи и робастна к изменениям Схема хранения будет использоваться для записи данных ETL процессами – значит нужно нормализовать отношения чтобы избежать аномалий: модификации, удаления, ввода. Аномалия обновления. При изменении значения в одной придется обновлять и значения в других записях. Аномалия удаления. Удаление атрибута у одной сущности может привести к удалению самой сущности. Аномалия ввода. При добавлении новой записи вводится значение, не входящее в заданный диапазон. Появляется новый экземпляр данных. При чтении ХД большое количество джойнов негативно сказывается на производительности. Прибегают к намеренной денормализации. При развитии ХД новыми источниками данных схема пополняется новыми объектами, связями и атрибутикой. В том числе в существующих сущностях появляются новые атрибуты. Схема должна быть устойчива к изменениям. Используйте Naming Convention. Реализуйте бизнес-логику в базе, а не в приложении. Анализ предметной области Необходимо собрать все кейсы использования пользователями системы отчётности. Какие задачи они решают? Необходимо рассмотреть бизнес-процессы в предметной области. Определить объекты, которыми они оперируют. Понять как они связаны между собой и с процессом. Рассмотреть user-story пользователя и понять какую проблему он решает? Что использует для принятия решения и какие действия предпринимает после? Что является результатом его действий или объектом управления? #2 Моделирование История пользователя Из user story определяем сущности и некоторые меры, которые помогают оценить событие в любых единицах измерений Событие Абонент заплатил АП за следующий период использования услуги. Измерения Абонент, услуга, период, канал платежа, средство платежа, вид АП, валюта, чек, счет, касса, дата внесения, за какого абонента внесена АП. Меры Сумма АП, скидка, налог, бонус списанный или накопленный, кол-во платежей. Концептуальное моделирование На данном уровне просто отражаем те сущности, которые выявили на предыдущем этапе Концептуальные модели данных являются представлениями сложных реальных структур данных. Помогают изображать отношения, связи между ними, другими компонентами и любые ограничения, которые существуют. Способствуют получению четкой картины – какие таблицы необходимо создавать. периоды Услуги Абоненты Каналы Оплата подписки Платежи Кассы Фактовая таблица должна оперировать наименьшей гранулярностью для долговременного хранения. Витрина – необходимой для отчетности. Количественные меры не всегда аддитивны (например, количество уникальных абонентов). DFD Прообраз концептуальной схемы – позволяет валидировать ваше понимание ПО и процессов в ней Формируя диаграмму потоков данных убеждаемся, что выделенные нами ранее сущности присутствуют в ней и наоборот нет «забытых» нами. Диаграмма позволяет понять что является входом процесса, а что выходом. Как он протекает? Какие промежуточные состояния и данные необходимы? Сущности Атрибутируем сущности – первый шаг понять, где нужна декомпозиция на две таблицы. Фактически это уже логическая схема Необходимо определить что у нас будет выступать натуральным ключом в предметной области. Выяснить какую атрибутику будем хранить в отношении, а какую в связанных с ним зависимых сущностях. периоды • • • Дата-начала Дата-окончания Льготный? Услуги • • • • Абоненты Код Название Тип Дата ввода • • • • • • Оплата подписки Сумма начисления Сумма оплаты НДС оплаты Скидка начисления Бонусов списано Бонусов начислено • • • • • • ФИО Адрес Email Телефон Счет Дата подключения Каналы • • • Название Тип провайдер Платежи • • • • Дата платежа Сумма НДС Номер чека Кассы • • • • Номер Местоположение Дата открытия Время работы Связи Выявляем связи которые имеют отношение M:M, рекурсии или циклы между сущностями. Избавляемся от них Одна подписка может оплачиваться в несколько частей разными платежами. Один платеж может быть направлен на погашение АП по нескольким подпискам. периоды • • • Дата-начала Дата-окончания Льготный? Услуги • • • • Абоненты Код Название Тип Дата ввода • • • • • • Оплата подписки Сумма начисления Сумма оплаты НДС оплаты Скидка начисления Бонусов списано Бонусов начислено Платежный документ • • • ID документа ID платежа ID подписки • • • • • • ФИО Адрес Email Телефон Счет Дата подключения Каналы • • • Название Тип провайдер Платежи • • • • Дата платежа Сумма НДС Номер чека Кассы • • • • Номер Местоположение Дата открытия Время работы Логическая схема ER модель Постепенно добавляем в схему деталей и получаем драфт логической схемы в которой проводим нормализацию Переходим от натуральных ключей к суррогатным и отображаем в той нотации, которая принята в нашей организации. И переходим к дальнейшим шагам – выявлению функциональных зависимостей и нормализации. Так у нас впервые получается схема, которую можно назвать логической. периоды • • • • • Prd_start_key Prd_end_key … Услуги • • Абоненты ID услуги … • • • • • • • ID абонента … Оплата подписки ID pay_doc ID абонента … Charge_calc Charge_pay Vat_pay Disc_pay Изобразим ее в одном из канонически сложившихся образов … Нотация Чена Один из первых формализованный способ отображения логической схемы Является достаточно перегруженным объектами. Сложно читать состав полей объектов, если их количество более десяти. Практически не используется в практике. Нотация Crows foot Стандарт де-факто для визуализации логической схемы. Лаконичен и интуитивно понятен Поскольку схема часто подвергается изменениям удобно использовать онлайн генераторы из текстового описания, в т.ч. плагины для confluens. https://plantuml-editor.kkeisuke.com/ Элементы нотации «Вороньи лапки» «Лапка» представляет собой перевернутую стрелку Сущность Связь Слабая сущность Ассоциативная Связь Онлайн генератор схем Ускоряет работу и позволяет с минимальными издержками поддерживать в актуальном виде схему @startuml entity "D_SUBSCRIBER" as esubs { hide circle *subs_id : int <> ' avoid problems with angled crows -feet *fio : string skinparam linetype ortho *account : int title пример учебной схемы phone : string email : string entity "Периоды" as eprd { *date_id : date <> -*p_start : date *p_end : date -other_details : ... } entity "F_payments" as epay { *pay_id : int <> -- -other_details : ... *s_type : intg cheque : string -other_details : ... Полезная статья об использовании в проектах } https://habr.com/ru/post/416077/ entity "M_paydoc" as ep2s { *map_id : int <> *s_open_date : date -- -other_details : ... *doc_id : int <> } *pay_id : int <> entity "F_subscription" as esbscr { *sbscr_id *sbscr_id : int <> -*date_id : int <> serv_id : int <> subs_id : int <> -charge$ : int charge_vat$:int discount:int bonus_wildraw:int -other_details : ... } https://plantuml-editor.kkeisuke.com/ pay_vat : int entity "d_services" as eserv { *s_name : string <> Пример имплементации *pay_charge : int } -- http://plantuml.com/ru/guide open_date : date is_holiday : int *serv_id : int <> Документация по движку --other_details : ... } eprd ||..o{ esbscr eserv ||..o{ esbscr esubs ||..o{ esbscr esbscr ||..o{ ep2s epay ||..o{ ep2s @enduml #3 Функциональные зависимости Функциональная зависимость (ФЗ) Это связь между атрибутами сущностей в отношении Если сущность A функционально определяет сущность B, то такую зависимость принято обозначать следующим образом: 𝐴𝐴 → 𝐵𝐵 {X, Y} → {𝑍𝑍} А – детерминант В – зависимая часть могут представлять собой наборы атрибутов Допущения и обозначения реляционной алгебры к базе данных Отношение = Таблица (R) Кортеж = строка таблицы (T) Атрибут = столбец таблицы (T[a]) Отношение R удовлетворяет ФЗ А → В (где А, В ⊆ R) тогда и только тогда, когда для любых кортежей t1, t2 ∈ R выполняется: если t1[X] = t2[X], то t1[Y] = t2[Y]. если 𝑇𝑇1 𝑥𝑥 = 𝑇𝑇2 𝑥𝑥 , то 𝑇𝑇1 𝑦𝑦 = 𝑇𝑇2 𝑦𝑦 https://habr.com/ru/company/JetBrains-education/blog/473882/ Виды ФЗ Выделяют несколько видов ФЗ в зависимости о того какие эффекты они описывают зависимость Многозначная Частичная полная транзитивная [не-] тривиальная Не строгие ФЗ позволяют нарушения на некотором подмножестве кортежей отношения. Их называют приближенными. Количество нарушений регулируется показателем максимальной ошибки. Например, emax = 0.01 – говорит о том, что 1% записей в отношении может нарушать ФЗ. Полная ФЗ Связь между атрибутами сущностей, где зависимая часть полностью и однозначно определяется детерминантом Полная ФЗ Person_id FIO Hire_date Experience Position Grade 1 Иванов 01/01/2016 63 руководитель 100,000 2 Петров 01/01/2020 13 Разработчик 90,000 Пример полной функциональной зависимости. Детерминант однозначно и полностью определяет зависимую часть. Зависимая, в свою очередь, зависит только от одной части отношения, от одного атрибута. Вычислимая зависимая часть в СУБД может быть полностью удалена из отношения. Частичная ФЗ Зависимая часть ФЗ определяется частью детерминанта Частичная ФЗ Company FIO FIO Hire_date Hire_date Experience Experience Position Position Grade Alhpa Иванов Иванов 01/01/2016 01/01/2016 63 63 руководительруководитель 100,000 Alpha Петров Петров 01/01/2020 01/01/2020 13 13 Разработчик Разработчик 90,000 Составной ключ Зависимый атрибут «Позиция» от части «FIO» в составном ключе «FIO» + «birth_date», что является примером частичной ФЗ. Транзитивная ФЗ ФЗ между несколькими атрибутами в отношении. Разрешается декомпозицией отношения на два Транзитивная зависимость FIO Hire_date Experience Position Grade Иванов 01/01/2016 63 руководитель 100,000 Петров 01/01/2020 13 Разработчик 90,000 Составной ключ «Позиция» зависит от «FIO». Сотрудник занимает конкретную должность. Грейд оклада определяется должностью и зависит от нее. (Не-)Тривиальная ФЗ ФЗ между несколькими атрибутами в отношении. Разрешается декомпозицией отношения на два Тривиальная ФЗ – зависимая часть является подмножеством детерминанта. Тривиальная ФЗ X Y {X, Y} → {𝑌𝑌} Person_id FIO Hire_date Experience Position Grade 1 Иванов 01/01/2016 63 руководитель 100,000 2 Петров 01/01/2020 13 Разработчик 90,000 Нетривиальная ФЗ – где зависимая часть может содержать атрибуты из множества детерминанта, но всей совокупностью атрибутов не является подмножеством детерминанта. B1 , B1 , … 𝐵𝐵𝑚𝑚 ⊄ A1 , A1 , … A𝑛𝑛 B1 , B1 , … 𝐵𝐵𝑚𝑚 ∩ A1 , A1 , … A𝑛𝑛 ≠ ∅ #4 Нормализация Что такое нормализация данных? Процесс приведения отношения в такую форму, чтобы уменьшить в ней количество ФЗ 1НФ 2НФ 3НФ НФБК 4НФ 5НФ 6НФ Избыточная ФЗ – содержит информацию, которая может быть получена на основе других зависимостей в БД. Корректной считается схема базы данных без избыточных ФЗ. Для этого применяют процедуру декомпозиции или разложения имеющегося множества отношений. Порождаемое множество содержит большее число отношений, которые являются проекциями исходного. Обратимый пошаговый процесс замены данной совокупности отношений другой схемой с устранением избыточных ФЗ называется нормализацией. Первая нормальная форма (1НФ) В одной «ячейке» – одно значение Основным правилом 1НФ является – атомарность значений. Строки таблиц не должны зависеть друг от друга, т.е. первая запись не должна влиять на вторую и наоборот. Аналогичная ситуация со столбцами записей. Нет дублирующихся записей. Денормализованная Book Национал Страни Толщ Издате Страна ID Формат Цена Предмет Жанр ьность цы ина ль издателя жанра MySQL, Чад Американе Твердая База Толсты Руково 49,99 520 Apress США 1 Рассел ц обложка данных й дство Дизайн Заголовок Автор Начало проектирования и оптимизации БД MySQL 1НФ Book Заголовок Автор Национа Страни Толщин Тип ID ID Формат Цена Жанр льность цы а публикации жанра издателя Начало проектирования и Чад Американ Твердая 49,99 оптимизации БД Рассел ец обложка MySQL Subject 520 Толстый Электронная книга Map_book_subs Руководс тво 1 ID subj Предмет Заголовок 1 MySQL ID subj Начало проектирования и оптимизации БД MySQL 1 2 База данных Начало проектирования и оптимизации БД MySQL 2 3 Дизайн Начало проектирования и оптимизации БД MySQL 3 1 Publisher ID Страна издате имя издателя ля 1 Apress США Вторая нормальная форма (2НФ) Отсутствие зависимости неключевых полей от части составного ключа Переменная отношения находится во второй нормальной форме тогда и только тогда, когда она находится в 1НФ и каждый не ключевой атрибут неприводимо зависит от её потенциального ключа. 2НФ запрещает создавать отношения как несвязанные (хаотические) наборы атрибутов. Book Заголовок Автор Национа Формат льность Начало проектирования и оптимизации БД MySQL Чад Америка Рассел нец Твердая обложка Начало проектирования и оптимизации БД MySQL Чад Америка Электронная публикация Рассел нец Реляционная модель для управления БД Реляционная модель для управления БД Мягкая обложка Электронная EF Codd Британец публикация EF Codd Британец Book Заголовок Толщи ID ID Жанр на жанра издателя Цена Страниц 49,99 520 Толстый 1 Руководс тво 1 22,34 520 Толстый 1 Руководс тво 1 39,99 538 Толстый 2 Науч поп 2 13,88 538 Толстый 2 Науч поп 2 Map_book_price Нацио ID ID Стра Толщ Жан Автор нальн жан издат ниц ина р ость ра еля Начало проектирования и Чад Америк 520 оптимизации БД Рассел анец MySQL Реляционная Британе модель для EF Codd 538 ц управления БД Толст ый Толст ый Руко 1 водст во 2 Науч поп 2НФ Заголовок Формат Цена Начало проектирования и оптимизации БД MySQL Твердая обложка 49,99 1 Начало проектирования Электронная и оптимизации БД MySQL публикация 2 Реляционная модель для Мягкая управления БД обложка Реляционная модель для Электронная управления БД публикация 22,34 39,99 13,88 Третья нормальная форма (3НФ) Избавление от транзитивных зависимостей Book Национальн Страниц ость Заголовок Автор Начало проектирования и оптимизации БД MySQL Чад Рассел Американец Реляционная модель для управления БД EF Codd Британец Book Заголовок Начало проектирования и оптимизации БД MySQL Толщина ID жанра Жанр ID издателя 520 Толстый 1 Руководст во 1 538 Толстый 2 Науч поп 2 3НФ Author ID Толщ ID Автор Страниц издат ина жанра еля Чад Рассел 520 Толсты й 1 1 Реляционная модель EF Codd для управления БД 538 Толсты й 2 2 Автор Национальность Чад Рассел Американец EF Codd Британец Genre ID жанра Жанр 1 Руководство 2 Науч поп Нормальная форма Бойса-Кодда Отсутствуют зависимости ключевых атрибутов от не-ключевых НФБК допускает наличие только таких нетривиальных ФЗ, в которых ключ определяет один или более других атрибутов. 𝑋𝑋 → 𝐴𝐴 , где 𝐴𝐴, 𝑋𝑋 входят в некий ключ нетривиальная ФЗ Город Адрес Индекс Москва Шаболовка 10 119049 Москва Лубянка 1 101000 Санкт-Петербург Литейный пр-к 24 191187 Санкт-Петербург Гагаринская 14 191187 Город Город Индекс Адрес Индекс Москва Москва 119049 Шаболовка 10 119049 Санкт-Петербург Москва 101000 Лубянка 1 101000 Санкт-Петербург 191187 Литейный пр-к 24 191187 Гагаринская 14 191187 Четвертая и пятая НФ Дальнейшая декомпозиция сводится к тому, чтобы уменьшить количество ФЗ в отношении Отношение в 4НФ – все независимые многозначные ФЗ разнесены в отдельные отношения с одним и тем же ключом. 4НФ требует чтобы отношение не содержало независимых многозначных ФЗ. ID ритей лера 1 1 2 2 3 Заголовок Начало проектирования и оптимизации БД MySQL Реляционная модель для управления БД Начало проектирования и оптимизации БД MySQL Начало проектирования и оптимизации БД MySQL Реляционная модель для управления БД Локация ID ритей лера Калифорния 1 Калифорния 1 Калифорния 2 Флорида 3 Заголовок Начало проектирования и оптимизации БД MySQL Реляционная модель для управления БД Начало проектирования и оптимизации БД MySQL Реляционная модель для управления БД ID ритей лера Локация 1 Калифорния 2 Калифорния 2 Флорида 3 Невада Невада Пятая НФ – каждая нетривиальная зависимость определяется потенциальным ключом отношения. Носит больше академический характер. Шестая нормальная форма (6НФ) Вариант пятой формы. Дальнейшая декомпозиция невозможна без потери данных о связях Получаемое отношение имеет только однозначную тривиальную ФЗ. Используется в некоторых СУБД, например, Vertica. Заголовок Автор Начало проектирования и Чад Рассел оптимизации БД MySQL Реляционная модель для управления БД EF Codd Автор Национальность ID жанра Жанр Чад Рассел Американец 1 Руководство EF Codd Британец 2 Науч поп Заголовок Страниц Заголовок Толщина Заголовок ID жанра Начало проектирования и оптимизации БД MySQL 520 Начало проектирования и Толстый оптимизации БД MySQL Начало проектирования и оптимизации БД MySQL 1 Реляционная модель для управления БД 538 Реляционная модель для Толстый управления БД Реляционная модель для управления БД 2 Заголовок Формат Цена Начало проектирования и оптимизации БД MySQL Твердая обложка 49,99 Начало проектирования и оптимизации БД MySQL Электронная публикация 22,34 Реляционная модель для управления БД Реляционная модель для управления БД Мягкая обложка Электронная публикация 39,99 13,88 #5 Приемы в моделировании Slowly Changing Dimensions В хранилищах необходимо отслеживать историю изменения атрибутов в отношениях Так называют измерения, значения которых со временем могут изменяться, но не часто. При этом изменяются не ключевые атрибуты измерения. Примером таких измерений может являться «Клиент», т.к. клиент может изменить фамилию, номер паспорта и другие атрибуты, но происходит это очень редко. До: После: ID Name dept ID Name dept 1 John Dep A 1 John Dep A 2 Mary Dep B 2 Mary Dep C Типы SCD Всего их восемь. Практический смысл для ХД имеют три Многие типы являются комбинацией более простых • Ничего не делаем – храним оригинал 1 • Простое Перезаписывание 2 • Добавить новую строку 3 • Добавить новый атрибут в таблицу 4 • Новая историческая таблица 5 • Тип 4(основа) + Тип 1 6 • Тип 2(основа) + Тип 1 + Тип 4 7 • 2*тип 1 + 2*Тип 2 Рассмотрим первые четыре … Тип 0 и Тип 1 Не применимы для ХД в большинстве случае, но для OLTP иногда подойдут Пассивный метод хранения, т. к. предполагается, что значения атрибутов такого типа не будут меняться. Примерами могут служить дата создания записи, дата и место рождения, серийный номер устройства. SCD type 0 Документ ФИО Дата рождения 11 22 333444 Иванов И. 01.01.1995 SCD type 1 До изменений ID Табельны й ФИО Дата рождения Должность 34 Ac-4 Иванов И. 01.01.1995 Младший специалист После изменений ID Табельны й ФИО Дата рождения Должность 34 Ас-4 Иванов И. 01.01.1985 Старший Специалист Тип 2 – добавить новую строку В таблицу добавляется новая строка с обновленными значениями. Старые сохраняются В отношение добавилась новая строка и ряд колонок, для удобства выбора актуальной или исторической записи. Этот тип наиболее часто используется на практике. Также можно осуществлять вставку ранее «потерянных» изменений в историчность наблюдаемых атрибутов. ID Табельный ФИО Дата рождения Должность 34 Ac-4 Иванов И. 01.01.1995 Мл. специалист Основная: До изменений Мл. специалист → Ст.специалист, произошло 01/01/2020, при этом появятся следующие изменения ID Табельный ФИО Дата рождения Должность 34 Ac-4 Иванов И. 01.01.1995 Мл. специалист 35 Ac-4 Иванов И. 01.01.1995 Ст. специалист ID Таб-й ФИО Д. Рожд Должность Версия 34 Ac-4 Иванов И. 01.01.1995 Мл.специалист 35 Ac-4 Иванов И. 01.01.1995 Ст. специалист 1 ID Таб-й ФИО Д. Рожд Должность Start_date End_date 34 Ac-4 Иванов И. 01.01.1995 Мл.специалист 01.01.2001 01.01.2002 35 Ac-4 Иванов И. 01.01.1995 Ст. специалист 01.01.2002 31.12.2999 Вариант 1 Вариант 2 Вариант 3 Тип 3 – добавить новый атрибут В отношение добавляется столбец для хранения нового значения Добавляется новый столбец. Слабо применимая практика из-за появления новых функциональных зависимостей. Сложно отслеживать много атрибутов. Невозможно отслеживать более одного изменения. ID Табельный ФИО Дата рождения Должность 34 Ac-4 Иванов И. 01.01.1995 Мл. специалист Основная: До изменений Мл. специалист → Ст.специалист, произошло 01/01/2020, при этом появятся следующие изменения ID Табельный ФИО Д. Рожд Должность старая Должность новая Дата изменений 34 Ac-4 Иванов И. 01.01.1995 Мл.специалист Ст. специалист 01.01.2020 Вариант 1 Тип 4 – историческая таблица Используется в системах, где внесение изменений в структуры таблиц ограничено или невозможно Ведется две таблицы: Основная – всегда перезаписывается текущими данными (Тип 1). Идентификатор изменяемой записи сохранится. Историческая – организуется по Типу 2. ID Табельный ФИО Дата рождения Должность 34 Ac-4 Иванов И. 01.01.1995 Мл. специалист 55 Ас-5 Петров В. 01.09.1999 Стажер Основная: До изменений Стажер → Разработчик, произошло 02/01/2020, при этом появятся следующие изменения IDd Табельный ФИО Дата рождения Должность 34 Ac-4 Иванов И. 01.01.1995 Мл. специалист 55 Ас-5 Петров В. 01.09.1999 Разработчик IDi Табельный ФИО Д. Рожд Должность Дата изменений 4 Ac-4 Иванов И. 01.01.1995 Мл.специалист 01.01.2020 5 Ас-5 Петров В 01.09.1999 Стажер 01.01.2020 6 Ас-5 Петров В. 01.09.1999 Разработчик 02.01.2020 Основная: исходная запись обновится Историческая: добавится новая запись Ограничения целостности В ХД ограничения стоит использовать только после тщательной оценки полезности данных возможностей Первичный Ключ • Отлично подходит для справочников, иерархий. • Без него не работает внешний ключ. • С ним всегда связан индекс. • Значения всегда NOT NULL. Внешний Ключ • Используется для обеспечения связности между таблицами. • Предотвращает появление недопустимых значений в подчиненной таблице. Уникальности • Хороший кандидат на поля, где могут быть NULL или комбинации значений. Не подходят для фактовых таблиц Для справочников и иерархий Для маппингов Практика использования Not NULL Старайтесь не допускать в БД полей с NULL значениями. Особенно в измерениях В отличие от PK, FK & UQ относятся только к содержательным значениям в отношении, NN ограничение применяется только по требованию. NOT NULL Самое замечательное в нем, что БД может использовать INNER JOIN вместо OUTER JOIN, а это приводит к более оптимальным путям выполнения запросов. В ХД данное ограничение играет ключевую роль в оптимизации Query Rewrite. Опоздавшие измерения Late arriving dimension – спланируйте стратегию работы с теми данными, которые оперируют еще несуществующими измерениями Фокус на измерение: Внесите в него все что вам известно. Остальное потом через процесс DQ по работе с фактами. Фокус на факты: Используйте специальные значения из отрицательного диапазона. Реализуйте стратегию замены в фактах отсутствующих измерений. Кассы название 1 Шлюз банка 2 Агрегатор Х 3 Центральный офис -1 Не определено -2 Не применимо -3 Не существующая Фокус на качество: помещайте факты с такими измерениями во временную область хранения. Стремитесь к ее разбору до окончания «времени жизни» записи. Факт должен «Созреть» Отношение многие-к-многим Решается в реляционных СУБД вводом дополнительного отношения (bridge-table, mapping) Классический вариант отразить такую связь – это добавить промежуточную таблицу формирующую необходимый набор. Такой вариант хорошо подходит для операционной работы. Мы всегда знаем актуальную картину. Можем рассчитать необходимый гонорар автору. Избежим замножений подсчета выручки. Авторы пишут книги, иногда совместно. Получают гонорары. Книги издаются в разных издательствах. В хранилищах схема усложняется Необходимо учитывать, что в разное время состав группы или ее атрибуты могут изменяться Требуется ввести идентификатор группы. Использовать его для фактовой таблицы. Если факты касаются состава группы – можно использовать либо идентификатор конкретной связи, либо идентификатор группы и дату события. Факт Dim Map Факт #6 Модели данных КХД Этапы моделирования Общая модель данных корпоративного хранилища разрабатывается последовательно и состоит из: • концептуальной модели данных (инфологической); • логической модели данных (даталогической); • физической модели данных. Концептуальная модель Концептуальная модель хранилища данных представляет собой описание главных (основных) сущностей и отношений между ними. Концептуальная модель является отражением предметных областей, в рамках которых планируется построение хранилища данных. Концептуальная модель Процесс формирования концептуальной модели включает в себя следующие работы: • проведение анализа полученных бизнестребований; • классификация данных и определение функциональных областей (Subject Area); • формирование набора сущностей (Entitys) концептуальной модели, отнесение каждой сущности к конкретной функциональной области; • формирование матрицы показателейизмерений; • верификация модели по результатам анализа источников; • верификация модели по бизнес требованиям; • формирование рабочего документа с описанием концептуальной модели; • согласование концептуальной модели с функциональными специалистами Заказчика. Логическая модель Логическая модель расширяет концептуальную путем определения для сущностей их атрибутов, описаний и ограничений, уточняет состав сущностей и взаимосвязи между ними. Логическая модель Процесс формирования логической модели включает в себя следующие работы: • определение атрибутов (Attributes); • уточнение состава сущностей области хранения детальных данных (System of Records); • сопоставление данных систем-источников атрибутам сущностей логической модели данных; • определение иерархий (Hierarchy); • определение состава и типов медленно меняющихся измерений (SCD); • определение основных бизнес-запросов (Business Queries); • проведение GAP-анализа; • принятие решений по требованиям, которые не могут быть удовлетворены; • определение состава и структуры агрегатов (Summary Area), витрин данных (Data Marts); • определение состава значений (Domains) для измерений и иерархий. Особенности моделирования времени в КХД Традиционные подходы к моделированию оперативных систем основываются, как правило, на статическом представлении реального мира. При этом если время и учитывается, то только в виде временных отметок создания записей и их модификации. С точки зрения моделирования времени хранилища данных принципиально отличаются от оперативных систем, и модели хранилищ данных более интенсивно используют временные отметки. Можно выделить три основных подхода к моделированию времени в хранилищах данных: 1. Модель снимков данных 2. Событийная модель 3. Статусная модель . Модель снимков данных Снимок данных — это представление данных в определенный момент времени. Данная модель характерна для оперативных систем (OLTP). Обновления данных носят деструктивный характер (т. е. предыдущие значения атрибутов замещаются новыми). Поскольку модель не обеспечивает хранения истории изменений, ее применение в хранилищах данных ограниченно. Событийная модель Событийная модель используется для моделирования данных о наступлении событий в определенные моменты времени. Эта модель хорошо подходит для моделирования транзакций, таких как продажи, финансовые транзакции, складские операции и т. д. Статусная модель Статусная модель используется для моделирования состояния объектов во времени. Она хорошо подходит для представления данных, имеющих нетранзакционный характер. Существует три способа моделирования изменяющихся во времени статусов: • непрерывная модель – для хранения промежутков времени используется одно поле даты, при этом дата начала следующего периода совпадает с датой окончания предыдущего; • начало и окончание – для хранения промежутков времени используется два поля: дата начала и дата окончания периода действия статуса; • начало и длительность – для хранения промежутков времени используется одно поле даты (дата начала) и поле длительности периода. Статусная модель Наибольшее распространение при создании статусных моделей получил способ «начало и окончание». Статусная и событийная модели являются взаимно дополняющими. Путем преобразований из одной можно получить другую. Например, зная остаток на счете на определенный момент и историю транзакций в событийной модели, можно восстановить все статусы счета (остатки на счете) в периоды между транзакциями. И наоборот, имея статусную модель остатков на счете, можно вычислить события (т. е. транзакции), которые происходили со счетом в начале (конце) каждого периода. Вопросы целостности данных Ввиду историчности данных их целостность в хранилище носит характер, отличный от целостности данных в оперативных системах. Если при построении транзакционных систем речь идет о целостности транзакций и соблюдении ссылочной целостности, то в хранилищах данных кроме этого очень важно обеспечивать историческую целостность данных и соблюдение бизнес-правил, которые могут выражаться механизмами, отличными от ссылочной целостности. Соответственно, ссылочная целостность и непротиворечивость данных в хранилище данных обеспечиваются иначе. Как правило, при проектировании хранилищ данных не используются триггеры и встроенные в СУБД механизмы контроля целостности. Они способны очень сильно снизить производительность системы и увеличить окно загрузки. Вместо этого целостность данных контролируется на этапе их загрузки путем выполнения различных проверок. Измерения Измерения содержат неизменяемые либо редко изменяемые данные. В подавляющем большинстве случаев эти данные представляют собой по одной записи для каждого члена нижнего уровня иерархии в измерении. Витрины данных, как правило, характеризуются наличием явного измерения «время». При этом структура данного измерения может меняться в зависимости от моделируемой предметной области и требований, предъявляемых пользователями к представлению времени. Помимо стандартных атрибутов времени, как правило, возникает необходимость моделирования специальных атрибутов времени, таких как: • • • • • недели; времена года; сезоны; выходные и праздники; рабочие смены. Факты Факты являются основной компонентой хранилища данных. Как правило, они содержат сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться. Обычно говорят о четырех наиболее часто встречающихся типах фактов. К ним относятся: • факты, связанные с транзакциями (Transaction facts). Они основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата); • факты, связанные с «моментальными снимками» (Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка; Факты • факты, связанные с элементами документа (Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки); • факты, связанные с событиями или состоянием объекта (Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей). Аддитивные факты Аддитивность определяет возможность суммирования факта вдоль определенного измерения. Аддитивные факты можно суммировать и группировать вдоль всех измерений на любых уровнях иерархии. Аддитивными, как правило, являются величины, характеризующие обороты (потоки, объемы операций). Полуаддитивные факты Полуаддитивный факт – это факт, который можно суммировать вдоль определенных измерений, и нельзя – вдоль других. Примером может служить остаток на счете (или остаток товара на складе). Данную величину нельзя суммировать вдоль измерения «время». Однако сумма остатков на счетах вдоль измерения «клиенты» имеет вполне реальный смысл для анализа. Неаддитивные факты Неаддитивные факты вообще нельзя суммировать. Любое отношение двух величин (выраженное в процентах) является примером неаддитивного факта. Неаддитивные факты рекомендуют моделировать таким образом, чтобы сделать их более аддитивными. Например, представить процент составляющими его величинами Физическая модель Физическая модель данных описывает реализацию объектов логической модели на уровне объектов конкретной базы данных. Процесс формирования физической модели заключается в: • определении правил наименования объектов базы данных; • разработке объектов хранения (таблиц, материализованных представлений, кубов и т.п.); • определении состава полей (Columns) и их типов данных (Data Types); • формирование первичных (Primary Keys) и внешних ключей (Foreign Keys); • уточнении состава значений (Domains) для измерений и иерархий; • проектирование состава и структуры разделов (Partitions), индексов (Indexes), последовательностей (Sequences) и т.д. • формирование рабочего документа с описанием физической модели; • согласование физической модели с техническими специалистами Заказчика. Выбор ключей Выбор ключей для таблиц хранилища данных является непростой задачей и может существенно повлиять на дальнейшее развитие схемы данных, производительность системы и ее надежность. Существуют разные способы решения этой задачи, каждый – со своими плюсами и минусами. Упрощенный же подход к ее решению может привести к ухудшению качества хранилища вплоть до потери логической целостности данных. Перед разработчиком модели хранилища встает вопрос: использовать ли в хранилище данных ключи из оперативных систем, и если нет, то как их сформировать? Рассмотрим варианты решения этой задачи. Использование ключей из оперативных систем Данное решение представляется очевидным, однако практика показывает, что оно далеко не самое удачное. Одна из проблем при использовании ключей из оперативных систем заключается в том, что некоторые приложения могут использовать одно и то же значение ключа для идентификации новых объектов после удаления из базы данных объектов, идентифицировавшихся этим значением ключа ранее. А поскольку данные из хранилища, как правило, не удаляются, повторное использование ключевых значений в оперативной системе может очень сильно затруднить поддержку хранилища. При большом количестве источников данных есть вероятность совпадения ключей в записях из разных источников. Генерация ключей Одно из решений заключается в генерации новых ключей для записей, загружаемых из системисточников. Существует несколько подходов к генерации ключей. • Новый ключ генерируется путем конкатенации ключа из системы-источника с уникальным идентификатором этой системы. Данный подход исключает возможность совпадения ключей из различных источников, позволяет проследить, из какого источника данные попали в хранилище, но не решает проблемы повторного использования ключей в оперативных системах. • Новый ключ генерируется путем конкатенации ключа из системы-источника с меткой времени загрузки записи в хранилище. Данный подход позволяет сделать ключ действительно уникальным за счет уникальности метки времени. Однако длина ключевого поля может оказаться ощутимой для системы, в результате чего возможно снижение производительности при выполнении операции соединения таблиц по ключевым полям. Генерация ключей • Новый ключ генерируется с помощью специального алгоритма (простейший случай — генерация возрастающей последовательности целых чисел). Преимущество такого подхода заключается в том, что ключи можно сделать минимально короткими. Это позволит решить проблемы с производительностью и сэкономить дисковое пространство, необходимое для хранения записей. Однако в этом случае необходимо иметь специальную структуру метаданных (таблица или несколько таблиц) для хранения соответствий между ключами оперативных систем и суррогатными ключами хранилища данных, а также процедуры для управления данной структурой. Выбор конкретного способа генерации ключей зависит от масштаба проекта, количества и качества систем-источников, требований к производительности и поддержке хранилища данных и полностью определяется проектной группой. Модели данных КХД Основные модели представления данных: • • • • • • • • Иерархическая Сетевая Реляционная Постреляционная Нереляционная Многомерная Объектно-ориентированная Объектно-реляционная Реляционные модели данных Наиболее распространенная модель данных КХД представляет собой ER-модель (Entity-relationship model – модель «сущность-связь»), описывающую на нескольких уровнях набор взаимосвязанных сущностей, которые сгруппированы по функциональным областям и отражают потребности бизнеса в аналитическом анализе и отчетности. Многомерные модели данных При проектировании аналитических витрин подходит многомерная модель. Этот подход хорошо ложится на понимание бизнеспользователей – т.к. это модель, простая и удобная для человеческого восприятия – люди оперируют понятными и привычными понятиями метрик (показателей) и разрезов, по которым они анализируются. И это позволяет просто и четко выстроить процесс сбора требований – мы рисуем набор «матриц разрезов и показателей», общаясь с представителями различных подразделений. А потом сводим в одну структуру – «модель анализа»: формируем измерения и определяем факты, которые на них определены. Попутно прорабатываем иерархии и правила агрегации. Многомерные модели данных Приемы моделирования витрин данных отличаются от приемов моделирования хранилищ данных в силу различных требований к структурам данных. Если основной задачей хранилища данных является хранение консолидированной исторической информации, то витрина данных строится с учетом требований по доступу к данным и представления информации. Как правило, для моделирования витрин данных используются схемы типа «звезда» и «снежинка». Рассмотрим компоненты схемы «звезда». Измерения Таблицы измерений содержат как минимум одно описательное поле (обычно с именем члена измерения) и, как правило, целочисленное ключевое поле (обычно это суррогатный ключ) для однозначной идентификации члена измерения. Если будущее измерение, основанное на данной таблице измерений, содержит иерархию, то таблица измерений также может содержать поля, указывающие на «родителя» данного члена в этой иерархии. Нередко (но не всегда) таблица измерений может содержать и поля, указывающие на «прародителей», и иных «предков» в данной иерархии (это обычно характерно для сбалансированных иерархий), а также дополнительные атрибуты членов измерений, содержавшиеся в исходной оперативной базе данных (например, адреса и телефоны клиентов). Измерения Измерения Каждая таблица измерений должна находиться в отношении «один ко многим» с таблицей фактов. Отметим, что скорость роста таблиц измерений должна быть незначительной по сравнению со скоростью роста таблицы фактов; например, добавление новой записи в таблицу измерений, характеризующую товары, производится только при появлении нового товара, не продававшегося ранее. Одно измерение куба может содержаться как в одной таблице (в том числе и при наличии нескольких уровней иерархии), так и в нескольких связанных таблицах, соответствующих различным уровням иерархии в измерении. Если каждое измерение содержится в одной таблице, такая схема хранилища данных носит название «звезда» (star schema). Измерения Если же хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема хранилища данных носит название «снежинка» (snowflake schema). Дополнительные таблицы измерений в такой схеме, обычно соответствующие верхним уровням иерархии измерения и находящиеся в соотношении «один ко многим» в главной таблице измерений, соответствующей нижнему уровню иерархии, иногда называют консольными таблицами (outrigger table). Измерения Измерения Отметим, что даже при наличии иерархических измерений с целью повышения скорости выполнения запросов к хранилищу данных нередко предпочтение отдается схеме «звезда». Однако не все хранилища данных проектируются по двум приведенным выше схемам. Так, довольно часто вместо ключевого поля для измерения, содержащего данные типа «дата», и соответствующей таблицы измерений сама таблица фактов может содержать ключевое поле типа «дата». Тогда соответствующая таблица измерений просто отсутствует. В случае несбалансированной иерархии в схему «снежинка» также следует вносить коррективы. В этом случае обычно в таблице измерений присутствует связь, аналогичная соответствующей связи в оперативной базе данных. Измерения Измерения Еще один пример отступления от правил – наличие нескольких разных иерархий для одного и того же измерения. Типичные примеры таких иерархий – иерархии для календарного и финансового года (при условии, что финансовый год начинается не с 1 января), или с различными способами группировки членов измерения (например, группировать товары можно по категориям, а можно и по компаниям-поставщикам). В этом случае таблица измерений содержит поля для всех возможных иерархий с одними и теми же членами нижнего уровня, но с разными членами верхних уровней. Таблица измерений может содержать поля, не имеющие отношения к иерархиям и представляющие собой просто дополнительные атрибуты членов измерений (member properties). Иногда такие атрибуты могут быть использованы при анализе данных. Факты Таблица фактов, как правило, содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Чаще всего это целочисленные значения либо значения типа «дата/время» – ведь таблица фактов может содержать сотни тысяч или даже миллионы записей, и хранить в ней повторяющиеся текстовые описания, как правило, невыгодно – лучше поместить их в меньшие по объему таблицы измерений. При этом как ключевые, так и некоторые неключевые поля должны соответствовать будущим измерениям. Помимо этого таблица фактов содержит одно или несколько числовых полей, на основании которых в дальнейшем будут получены агрегатные данные. Таблицы покрытия Таблицы покрытия используются с целью моделирования сочетания измерений, для которых отсутствуют факты. Например, нужно найти количество категорий продуктов, которые сегодня ни разу не продавались. Таблица фактов продаж не может ответить на данный вопрос, поскольку она регистрирует только факты продаж. Для того чтобы модель позволяла отвечать на подобные вопросы, нужна дополнительная таблица фактов (по сути дела, не содержащая фактов), которая и называется таблицей покрытия. Иерархии Иерархии в измерениях необходимы для возможности агрегации и детализации значений показателей. Существуют следующие типы иерархий: • Сбалансированные (balanced) • Несбалансированные (unbalanced) • Неровные (ragged) Сбалансированные иерархии Это иерархии, в которых число уровней определено её структурой и неизменно, и каждая ветвь иерархического дерева содержит объекты каждого из уровней. • Каждому производителю автомобилей может соответствовать несколько марок автомобилей, а каждой марке – несколько моделей автомобилей, поэтому можно говорить о трёхуровневой иерархии этих объектов. • В этом случае на первом уровне иерархии располагаются производители, на втором – марки, а на третьем – модели. • Как видно, для формирования сбалансированной иерархии необходимо наличие связи «один-комногим» между объектами менее детального уровня по отношению к объектам более детального уровня. • В принципе каждый уровень сбалансированной иерархии можно представить как отдельное простое измерение, но тогда эти измерения окажутся зависимыми, а значит неизбежно повышение разреженности куба. Сбалансированные иерархии Несбалансированные иерархии Это иерархии, в которых число уровней может быть изменено, и каждая ветвь иерархического дерева может содержать объекты, принадлежащие не всем уровням, только нескольким первым. • Необходимо заметить, что все объекты несбалансированной иерархии принадлежат одному типу. • Типичный пример несбалансированной иерархии иерархия типа «начальник-подчиненный», где все объекты имеют один и тот же тип – «Сотрудник». Несбалансированные иерархии Неровные иерархии Это иерархии, в которых число уровней определено её структурой и постоянно, однако в отличие от сбалансированной иерархии некоторые ветви иерархического дерева могут не содержать объекты какого-либо уровня. • Иерархии такого вида содержат такие члены, логические «родители» которых не находятся на непосредственно вышестоящем уровне. • Типичным примером является географическая иерархия, в которой есть уровни «Страны», «Штаты» и «Города», но при этом в наборе данных имеются страны, не имеющие штатов или регионов между верхним и нижним уровнями иерархии. Неровные иерархии Технические аспекты многомерного хранения данных В многомерных хранилищах данных содержатся агрегатные данные различной степени подробности, например, объемы продаж по дням, месяцам, годам, по категориям товаров и т.п. Цель хранения агрегатных данных – сократить время выполнения запросов, поскольку в большинстве случаев для анализа и прогнозов интересны не детальные, а суммарные данные. Поэтому при создании многомерной базы данных всегда вычисляются и сохраняются некоторые агрегатные данные. Технические аспекты многомерного хранения данных Отметим, что сохранение всех агрегатных данных не всегда оправданно. Дело в том, что при добавлении новых измерений объем данных, составляющих куб, растет экспоненциально (иногда говорят о «взрывном росте» объема данных). Если говорить более точно, степень роста объема агрегатных данных зависит от количества измерений куба и членов измерений на различных уровнях иерархий этих измерений. Для решения проблемы «взрывного роста» применяются разнообразные схемы, позволяющие при вычислении далеко не всех возможных агрегатных данных достичь приемлемой скорости выполнения запросов. Технические аспекты многомерного хранения данных Как исходные, так и агрегатные данные могут храниться либо в реляционных, либо в многомерных структурах. Поэтому в настоящее время применяются три способа хранения данных: • MOLAP (Multidimensional OLAP) • ROLAP (Relational OLAP) • HOLAP (Hybrid OLAP) Технические аспекты многомерного хранения данных MOLAP (Multidimensional OLAP) – исходные и агрегатные данные хранятся в многомерной базе данных. Хранение данных в многомерных структурах позволяет манипулировать данными как многомерным массивом, благодаря чему скорость вычисления агрегатных значений одинакова для любого из измерений. Однако в этом случае многомерная база данных оказывается избыточной, так как многомерные данные полностью содержат исходные реляционные данные. ROLAP (Relational OLAP) – исходные данные остаются в той же реляционной базе данных, где они изначально и находились. Агрегатные же данные помещают в специально созданные для их хранения служебные таблицы в той же базе данных. HOLAP (Hybrid OLAP) – исходные данные остаются в той же реляционной базе данных, где они изначально находились, а агрегатные данные хранятся в многомерной базе данных. Нереляционные модели данных Базы данных NoSQL используют разнообразные модели данных для доступа к данным и управления ими. Базы данных таких типов оптимизированы для приложений, которые работают с большим объемом данных, нуждаются в низкой задержке и гибких моделях данных. Все это достигается путем смягчения жестких требований к непротиворечивости данных, характерных для других типов БД. Наиболее популярные NoSQL модели данных: • Графовая модель • Модель ключ-значение • Модель семейства столбцов • Документная модель Конечная форма физического представления данных – JSON Графовая модель данных Модель key-value Столбчатые модели Документная модели Сравнение этапов моделирования Взаимосвязь этапов Разработка моделей данных хранилища не является отдельной задачей и выполняется в плотном взаимодействии с другими процессами и участниками проекта. Ключевые участники: • Бизнес-аналитик • Разработчик ETL • Специалист по модели • Администратор БД Основные стадии: • Формирование требований и разработка ТЗ • Эскизные проект • Технический проект Формирование требований и разработка ТЗ Участник Определение требований Разработка концептуальной модели Бизнес-аналитик Сбор бизнестребований Анализ бизнестребований Формирование реестров показателей и измерений Разработчик ETL Определение состава источников данных Анализ и изучение источников данных Специалист по модели Получение и анализ информации Разработка концептуальной модели Администратор БД Эскизный проект Участник Разработка логической модели Бизнес-аналитик Определение основных бизнес-запросов Разработчик ETL Анализ соответствия модели и источников данных Разработка Staging Area Разработка интерфейсов обмена данными Специалист по модели Разработка логической модели Администратор БД Проектирование БД Технический проект Участник Разработка физической модели Бизнес-аналитик Определение правил преобразования Определение значений измерений Проектирование отчетности Разработчик ETL Проектирование правил преобразования Проектирование ETLпроцессов Специалист по модели Разработка физической модели Администратор БД Разработка физической модели Заключение Заключение • Рассмотрены цели и задачи логического проектирования • Рассмотрены типовые приемы в моделировании • Описаны различные модели данных КХД, подробно разобрана многомерная модель данных Приложения Постреляционные модели данных Постреляционная модель данных допускает многозначные поля – поля, значения которых состоят из подзначений. Набор значений многозначных полей считается самостоятельной таблицей, встроенной в основную таблицу. Для обеспечения целостности данных приходится создавать процедуры, автоматически вызываемые до или после обращения к данным. Достоинством постреляционной модели является возможность представления совокупности связанных реляционных таблиц одной постреляционной таблицей. Это обеспечивает высокую наглядность представления информации и повышение эффективности ее обработки. Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных. Иерархические модели данных Иерархические модели данных поддерживают древовидную организацию информации. Для описания структуры (схемы) иерархической БД на некотором языке программирования используется тип данных «дерево». Сетевые модели данных Для описания схемы сетевой БД используется две группы типов: «запись» и «связь». Тип «связь» определяется для двух типов «запись»: предка и потомка. В сетевой модели допускаются отношения «многие ко многим». Записи не зависят друг от друга. При удалении записи удаляются и все ее связи, но не сами связанные записи. Сетевые модели данных Объектно-ориентированные модели данных Большим недостатком объектноориентированных баз данных является их тесная связь с применяемым языком программирования и, как следствие, высокая понятийная сложность, неудобство обработки данных и низкая скорость выполнения запросов Хранилища Данных Лекция 5. Пример проектирования #1 Пример Постановка Требуемый информационный пакет представлен ниже. При этом необходимо рассматривать только заказы в состоянии «отправлено» (status = 5) Персонал Продукт Группа отдела Категория Отдел Подкатегория Продавец (ФИО) Наименование Дата рождения Цена по прайс-листу с учетом времени появления заказа Пол Номер продукта Объем продаж, Количество Доставка Время доставки Страна Код страны Год Регион Квартал Код региона Месяц Город День Код города Источник данных 1 Источник данных 2 Итоговая многомерная модель Заключение Заключение • Разобран пример построения логической модели данных для нужд аналитической витрины