Фреймворк проектирования логической модели хранилища данных Текст научной статьи по специальности «Компьютерные и информационные науки»

Фреймворк проектирования логическом модели хранилища данных

о см о см

со

о ш т

X

<

т о х

X

Солянов Кирилл Сергеевич

аспирант Финансового университета при Правительстве Российской Федерации, kirsol4@yandex.ru

Стацюк Любовь Владимировна

преподаватель информатики, ГБОУ Школы №56 им. акад. В.А. Легасова, stacuk.lubov@yandex.ru

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

Введение

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

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

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

При построении ХД не следует недооценивать важность этапа проектирования, так как качество выполнения данного этапа влияет как на эффективность всего будущего ХД, то есть насколько оно надежно и отвечает предъявляемым требованиям, так и на трудоемкость остальных этапов.

Проблема проектирования логической модели данных ХД

Проектирование ХД представляет собой высокоуровневое описание компонентов ХД и их взаимосвязи. Оно включает в себя разработку технологической, сетевой и логической архитектур. Логическая архитектура должна быть детализирована до схемы потоков данных - слои данных, этапы преобразования, и логической модели данных (ЛМД). В рамках данной работы подробнее рассмотрена проблема проектирования ЛМД.

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

следует стандартизировать подход к проектированию. Стандартизация подхода - залог понятности и удобства использования и развития МД.

Таблица 1

Рисунок 1- Критерии успешности ЛМД

Безусловно, занимаясь проектированием модели данных хранилища нельзя упустить из внимания принципы нормализации данных, основоположником которых был Э.Кодд [2]. Однако, следует отметить, что нормализация - это не панацея для проектировщиков ХД, и в определенный момент дальнейшая нормализация модели будет не приближать, а, напротив, отдалять от оптимального состояния. Рассмотрим нормальные формы подробнее - см.таблицу 1.

Таким образом, исходя из таблицы 1 оптимальной степенью нормализации модели ХД является третья или четвертая нормальная форма в зависимости от специфики предметной области и мнения проектировщика. Однако, нельзя утверждать, что другие подходы к проектированию не жизнеспособны и применение других нормальных форм невозможно. На практике существуют примеры промышленных ХД, которые построены по шестой нормальной форме, несмотря на то что еще около десяти лет назад научное сообщество придерживалось мнения, что даже пятая нормальная форма носит исключительно теоретический характер. Это доказывает тезис о том, что степень нормализации данных -это не единственный и, возможно, не главный критерий качества МД ХД.

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

В правильной МД аналогичные фрагменты ХД должны быть спроектированы одинаковым образом; модель должна быть понятна и интуитивно читаться. Целевым состоянием МД можно назвать следующую: один раз поняв логику ее построения, можно интуитивно находить необходимые данные, устанавливать связи между объектами и даже предугадывать названия сущностей и атрибутов. Для достижения такого состояния

Нормальная форма Ключевая особенность Влияние на критерий успешности

Вычислитель- Объем дан-

ная нагрузка ных

Первая нор- Устранение Значительно Не значи-

мал. форма множественных значений уменьшается тельно увеличивается

Вторая нор- Устранение ча- Не значительно Значительно

мал. форма стичнозависи-мых атрибутов увеличивается уменьшается

Третья нор- Устранение за- Не значительно Значительно

мал. форма висимостей от неключевых атрибутов (только первичный ключ) увеличивается уменьшается

Нормал. Устранение за- Не значительно Не значи-

форма висимостей от увеличивается тельно умень-

Бойса- неключевых шается

Кодда атрибутов (все потенциальные ключ)

Четвертая Устранение Не значительно Значительно

нормал. многозначных увеличивается уменьшается

форма зависимостей

Пятая нор- Устранение не- Не значительно Не значи-

мал. форма тривиальных зависимостей увеличивается тельно увеличивается

Доменно- Установление Значительно Не изменяется

ключевая ограничений уменьшается

нормал. форма домена и ключа

Шестая Независимое Значительно уве- Значительно

нормал. форма версионирова-ние всех атрибутов личивается уменьшается

Первая Не изменяется Значительно уве- Требуется со-

нормал. личивается блюдать

форма

Вторая Не значительно Не значительно Требуется со-

нормал. форма увеличивается уменьшается блюдать

Третья Не значительно Не значительно Требуется со-

нормал. форма увеличивается уменьшается блюдать

Нормал. Не значительно Не значительно Возможно со-

форма уменьшается уменьшается блюдение в

Бойса-Кодда некоторых случаях

Четвертая Не изменяется Не значительно Требуется со-

нормал. форма уменьшается блюдать при соблюдении нормальной формы Бойса-Кодда

Пятая нор- Не изменяется Не значительно Не следует со-

мал. форма уменьшается блюдать

Доменно- Значительно Не значительно Не следует со-

ключевая уменьшается уменьшается блюдать

нормал. форма

Шестая Значительно Значительно Не следует со-

нормал. форма уменьшается уменьшается блюдать

о см

0 см

со

01

о ш т

X

3

<

т о х

X

Фреймворк проектирования ЛМД

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

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

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

На рисунке 3 приведен пример иерархии типовых таблиц для фрагмента бизнес-объекта «Сделка» из банковской предметной области. В данном примере «Сделка» является основной таблицей измерения, «Кредитная сделка» и «Депозитная сделка» типовыми таблицами первого уровня, «Кредитная линия» и «Транш» - типовыми таблицами второго уровня.

Сделка

> сделки Дата открыл«

Кредитная Депозитная

сделка слегка

- Признак цегси п -■- НасчнкаамыЛ остаток

Рисунок 2 - Фреймворк проектирования ЛМД

Любое проектирование начинается с изучения предметной области, с которой будет выполняться работа. Необходимо определить какие глобальные бизнес-процессы выполняются в организации, а также выделить из них те, информационное обеспечение которых предполагается осуществлять с помощью ХД. По мере развития ХД и уровня зрелости организации с точки зрения управления данными все информационные потоки компании должны быть выстроены через единое корпоративное ХД [3]. Определенные бизнес-процессы группируются, образуя области деятельности организации. Эти области соответствуют компонентам будущего ХД.

Следующим шагом необходимо определить всех участников бизнес-процессов и ключевые объекты, задействованных в них. Результатом данной работы должен стать перечень бизнес-объектов ХД каждого компонента. Фреймворком предусмотрены следующие типы бизнес-объектов по их природе: «Измерение», «Транзакция», «Интервальный факт», «Справочник» [4].

После определения набора бизнес-объектов каждый из них должен быть всесторонне проанализирован, должны быть выявлены его ключевые элементы и характеристики. Результаты данного анализа определяют сущностный состав каждого бизнес-объекта. Фреймворком определены следующие типы сущностей: «Основная таблица», «Типовая таблица», «Таблица-бридж», «Таблица версионного атрибута», «Таблица дополнительных атрибутов», «Справочная таблица».

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

Кредитная

Примак

►юнтапбнонляеым: ш

Транш номер транша о

Рисунок 3 - Пример иерархии типовых таблиц

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

Таблица 2

Матрица соответствия типов бизнес-объектов и типов

Основная Основная Основная таб- Основная

таблица таблица лица интер- таблица

измере- транзакции вального справоч-

ния факта ника

Измерение 1 0 0 0

Транзакция 0 1 0 0

Интерваль- 0 0 1 0

ный факт

Справочник 0 0 0 1

Измерение 0 - * 0 - * 0 - * 0 - 1

Транзакция 0 - * 0 - * 0 0 - 1

Интерваль- 0 0 0 0

ный факт

Справочник 0 - * 0 - 1 0 0

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

При этом для упрощения и автоматизации рутиной части проектирования ЛМД фреймворк определяет обязательный минимальный атрибутный состав для каждого типа сущности - см. таблицу 3.

Таблица 3

Обязательный минимальный атрибутный состав сущностей

Тип сущности Наименование атрибута Первичный ключ

Основная таблица измерения Идентификатор объекта PK

Основная таблица транзакции Идентификатор объекта PK

Основная таблица транзакции Дата транзакции

Основная таблица интервального факта Идентификатор объекта-измерения PK

Основная таблица интервального факта Дата начала действия факта PK

Основная таблица интервального факта Дата окончания действия факта

Основная таблиц справочника Идентификатор объекта PK

Основная таблиц справочника Код справочного значения

Основная таблиц справочника Расшифровка справочного значения

Типовая таблица Идентификатор объекта PK

Таблица-бридж Идентификатор основного объекта PK

Таблица-бридж Идентификатор связанного объекта PK

Таблица-бридж Тип связи PK

Таблица-бридж Дата начала действия связи PK

Таблица-бридж Дата окончания действия связи

Таблица версионности атрибута Идентификатор объекта PK

Таблица версионности атрибута Значение версионного атрибута

Таблица версионности атрибута Дата начала действия значения атрибута PK

Таблица версионности атрибута Дата окончания действия значения атрибута

Таблица дополнительных атрибутов Идентификатор объекта PK

Таблица дополнительных атрибутов Идентификатор доп. атрибута PK

Таблица дополнительных атрибутов Значение доп. атрибута

Заключение

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

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

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

Литература

1. Амириди, Ю.В. Почему банки переплачивают за хранилище данных? [Электронный ресурс] / Банкир.ру // 2015. - Режим доступа: http://bankir.ru/publikacii/20150826/pochemu-banki-pereplachivayut-za-khranilishche-dannykh-10006670/

2. Codd, E. Providing OLAP (on-line analytical processing) to user-analysts / Codd E., Codd S., Salley C. // London. - Arbor Sotware Corp. Papers. - 1993

3. Inmon, W. H. Building The Data Warehouse / Inmon W. H. / / третье издание. - Джон Уайли Энд Санз Инк. -Нью Йорк. - 2002

4. Kimball, R. The Data Warehouse Toolkit. второе издание. Полное руководство по размерному моделированию / Кимболл Р., Росс М. / / Wiley Computer Publishing. -2002

Framework for designing a logical data warehouse model Solyanov K.S., Statsyuk L.V.

Financial University under the Government of the Russian Federation, GBOU School № 56 named after him. Acad. V. A. legasova

Data warehouses (DW) remain relevant today due to their role in building the organization's information and analytical infrastructure in the era of digital transformation. This article discusses the problem of designing a logical data model for a system of this class. The complexity of design is due to the fact that there is no unambiguous definition of the optimal model; its quality depends on a number of factors. The article discusses the approach of data normalization, which many mistakenly identify with the optimization of data storage structures. The article also describes the framework for designing a logical data model of DW, which includes several levels: components, business objects, entities, and attributes. In addition, the framework describes rules and standards that simplify the design process and improve the quality of the final data model and the entire DW as a whole. Key words: Data storage, logical data model, design, framework,

digital transformation References

1. . Amiridi, Yu. V. Why do banks overpay for data storage? [Electronic resource] / <url> / / 2015. - Access mode: http://bankir.ru/publikacii/20150826/pochemu-banki-pereplachivayut-za-khranilishche-dannykh-10006670/

2. Codd, E. Providing OLAP (on-line analytical processing) to user-analysts / Codd E., Codd S., Salley C. // London. - Arbor Sotware Corp. Papers. - 1993

3. Inmon, W.H. Building the Data Warehouse / Inmon W.H. // Third Edition. - John Wiley & Sons Inc. - New York. - 2002

4. Kimball, R. The Data Warehouse Toolkit. Second Edition. The Complete Guide to Dimensional Modeling / Kimball R., Ross M. // Wiley Computer Publishing. - 2002

X X О го А С.

X

го m

о

ю 00

2 О

м о