РАЗРАБОТКА ПРОГРАММНОГО ПРИЛОЖЕНИЯ ДЛЯ УПРАВЛЕНИЯ СПЕЦИАЛИЗИРОВАННЫМ КОРПОРАТИВНЫМ ХРАНИЛИЩЕМ ДАННЫХ
РАЗРАБОТКА ПРОГРАММНОГО ПРИЛОЖЕНИЯ ДЛЯ УПРАВЛЕНИЯ СПЕЦИАЛИЗИРОВАННЫМ КОРПОРАТИВНЫМ ХРАНИЛИЩЕМ ДАННЫХ
Найзабаева Лязат Кыдыргалиевна
д-р техн. наук, ассоциированный проф. кафедры Информационные Системы, Международный Университет Информационных Технологий,
Республика Казахстан, г. Алматы
Кабдолдакызы Жулдызай
магистрант Международного Университета Информационных Технологий,
Республика Казахстан, г. Алматы
АННОТАЦИЯ
Многие современные организации стремятся найти способы принимать более быстрые и качественные решения, касающиеся их бизнеса. Одним из способов достижения этой цели является создание специализированных корпоративных хранилищ данных, предлагающего новые возможности, такие как поиск данных и специальные запросы к данным, собранным и интегрированным из многих компьютеризированных систем, используемых в организации. Таким образом, цель данной статьи в изучении процесса разработки программного приложения для управления специализированным корпоративным хранилищем данных. Объектом данной статьи является корпоративное хранилище данных.
Ключевые слова: хранилище данных, организация, программное обеспечение, прогресс.
Корпоративное хранилище данных представляет жизненно важный интерес для лиц, принимающих решения, что в свою очередь может уменьшить неопределенность при принятии решений. Взаимосвязь между хранилищем данных и бизнес-процессами может быть использована на этапе, предшествующем развертыванию проекта хранилища данных, то есть во время фактической разработки хранилища данных, как возможность изменить бизнес-процессы в организации. Сосредоточив внимание на этапе до развертывания, мы считаем, что затраты на разработку уменьшатся, поскольку потребности в изменениях, обнаруженные на ранней стадии проекта разработки хранилища данных, вероятно, будут обнаружены в любом случае, но на более поздней стадии, когда изменения в бизнес-процессах могут вызвать необходимость реструктуризации готового хранилища данных. Результатом ранней разработки может стать улучшение дизайна бизнес-процессов, что также может повысить производительность хранилища данных. Другим очевидным результатом может быть то, что лучше разработанные бизнес-процессы делают выполнение операций в организации более эффективным.
По мнению В.Е. Туманов, вероятность успешного создания хранилища данных повышается, если хорошо понимать бизнес и его конечных пользователей [1]. Без этого знания разработка хранилища данных, скорее всего, окажется для разработчиков бесполезным занятием. Способ сбора информации от работников, обладающих знаниями, сильно отличается от анализа потребностей организации, основанного на данных. Важно подчеркнуть, что разработчики корпоративного хранилища данных должны понимать ключевые факторы, которые ведут организацию вперед. Определенные бизнес-требования создают основу для следующих фаз жизненного цикла бизнес-размеров.
Поскольку конечной целью является разработка приложения для управления корпоративным хранилищем данных. Источники данных считаются важными, поскольку эти системы поддерживают бизнес-процессы, из которых собираются данные. Мы намерены рассмотреть и объяснить все этапы типичной архитектуры хранилища данных, представленной Паклин Н.Б., Орешков В.И., чтобы более широко ознакомить читателя с концепцией хранилища данных.
Рисунок 1. Архитектура хранилища данных [2]
Архитектура хранилища данных оснащена инструментами для сбора и извлечения данных из различных источников и их интеграции в хранилище данных. Загрузка данных в хранилище состоит из четырех различных операций:
1. Извлечение - это процесс, который касается того, какие данные должны храниться в хранилище. Интерес представляют только те данные, которые могут быть использованы для принятия решений и других типичных операций хранилища данных.
2. Преобразование извлеченных данных является следующим шагом для создания хранилища данных. Преобразование данных необходимо, поскольку часто данные содержат различные ошибки, например, разную длину полей и несоответствия. Существуют различные операции, связанные с этапом преобразования. Очистка данных - это исправление опечаток и нарушение ограничений целостности. Агрегирование данных означает, что данные хранятся на разных уровнях детализации, что повышает производительность хранилища данных при выполнении пользователем общих запросов по управлению.
3. После извлечения и преобразования данных чистые, согласованные и агрегированные данные загружаются в хранилище данных. Вывод хранилища данных в автономный режим облегчает загрузку данных, и обычно это делается ночью, когда хранилище данных не используется.
4. Последняя операция - это обновление хранилища. Обычно хранилище обновляется периодически, то есть каждое изменение в исходных системах не обновляется сразу, а сохраняется и загружается вместе с другими изменениями, произошедшими за определенный промежуток времени.
Так технологическая разработка состоит из двух этапов:
- проектирование технической архитектуры;
- выбор и установка продукта.
При проектировании технической архитектуры устанавливается общая архитектурная структура и видение хранилища данных. Это означает, что указывается фактический физический дизайн компонентов хранилища данных и определяется общая функция, цель хранилища данных. При разработке технической архитектуры для управления корпоративным хранилищем данных необходимо выделить три фактора:
- бизнес-требования для приложения;
- текущую техническую среду;
- планируемые стратегические направления.
Бизнес-требования содержат, как уже говорилось выше, хорошее понимание бизнеса и конечных пользователей. Текущая техническая среда также важна, поскольку необходимо иметь хорошее представление о том, как работают различные исходные системы, поскольку они являются источниками для управления хранилищем данных. При разработке архитектурного проекта для хранилища данных очень важно знать, как работают текущие системы в организации. Последний фактор - это запланированные стратегические решения, которые важны, поскольку разработчики архитектуры и видения хранилища данных должны быть уверены в том, каким образом предполагается использовать хранилище данных и какой тип поддержки для организации должно предложить хранилище данных. Эти три фактора должны рассматриваться одновременно, чтобы проектирование технической архитектуры было успешным. Вторая фаза технологического пути - выбор и установка продукта. На предыдущем этапе должен быть разработан проект технической архитектуры. На этапе выбора продукта и установки проект технической архитектуры используется в качестве основы для выбора конкретных компонентов архитектуры, таких как система управления базами данных (СУБД), аппаратная платформа, движки запросов и т.д. Разработчики должны оценить возможные альтернативы конкретных аппаратных компонентов, чтобы выяснить, какой компонент лучше всего соответствует потребностям проекта. После выбора подходящих компонентов они устанавливаются и тестируются, чтобы убедиться в приемлемости их интеграции с другими компонентами хранилища данных.
Второй путь в цикле бизнес разработки - это путь данных, который делится на три фазы.
1. Размерное моделирование - это первая фаза, и поскольку бизнес-требования сформулированы при достижении размерного моделирования, данные, необходимые пользователям, уже известны разработчикам. Задача фазы размерного моделирования заключается в разработке модели данных, которая поддерживает эти требования. Точилкина Т.Е., Громова А.А. приводят эмпирическое правило в отношении размерного моделирования и утверждают, что размерная модель хранилища данных должна быть основана на корпоративной модели данных, т.е. на исходных системах. Это гарантирует, что размерная модель будет улавливать общие потребности в информации в организации [3]. Лучший способ сделать это - построить матрицу, которая содержит ключевые бизнес-процессы. Эта матрица гарантирует, что разработанное хранилище данных будет расширяемым для всей организации. Когда матрица разработана, можно провести более детальный анализ операционных источников, которые будут использоваться хранилищем данных. Этот детальный анализ источников данных вместе с определением бизнес-требований даст информацию, необходимую для построения размерной модели хранилища данных. Конечным продуктом размерного моделирования является логическая модель базы данных, которая будет служить отправной точкой при создании физической базы данных.
2. Вторая фаза на пути данных в цикле бизнес-измерений - это физическое проектирование, которое фокусируется на определении физических структур, которые должны поддерживать модель измерений, которая является логической моделью базы данных. Физическое проектирование приложения для управления хранилища данных также включает в себя настройку среды базы данных. Еще одна вещь, которая решается на этом этапе - это индексирование и разделение физического хранилища данных.
3. Последняя фаза пути данных связана с загрузкой данных из исходных систем в хранилище данных. Эта фаза называется «постановка и разработка приложения» и, вероятно, является самой недооцененной задачей в проекте хранилища данных. Это рассуждение подтверждает Полубояров В.В., который утверждает, что операционные затраты, связанные с хранилищем данных, в пять раз превышают затраты на аппаратное и программное обеспечение [4].
По мнению Сарка Д. существуют две основные части, связанные с постановкой и разработкой данных. Первым этапом в прикладном направлении является спецификация пользовательских приложений для управления хранилищем. Подчеркивается важность определения соответствующих инструментов доступа, так лучшим способом измерения успеха приложения для управления хранилищем данных является степень, в которой конечные пользователи находят информацию в хранилище данных и передают эту информацию в организацию. Пользователей хранилища данных можно разделить на две категории. Одна категория включает более продвинутых пользователей, которых относительно немного и которые выполняют специальные запросы, что в свою очередь требует несколько сложного доступа к управлению хранилищем данных. Другая категория включает в себя более обычных бизнес-пользователей, которые не выполняют такой объем обработки AD-HOC запросов. Рекомендуется разработать набор стандартных конечных приложений для бизнес-пользователей, поскольку им вряд ли понадобятся какие-либо другие специальные функции. Спецификация приложения гарантирует, что разработчики и бизнес-пользователи имеют одинаковое представление о предполагаемом приложении для конечного пользователя [5].
Таким образом, разработка приложения для конечного пользователя - это вторая и последняя фаза на пути приложения для управления хранилищем данных. Поскольку предыдущая фаза была связана со спецификацией приложений для конечных пользователей, эта фаза сосредоточена на фактической разработке приложений на основе заданных спецификаций. Хорошим способом разработки стандартного приложения для конечных пользователей (работников) является использование передовых инструментов доступа к данным, что приведет к высокой производительности. Инструменты доступа к данным используются для разработки заданных результатов, которые будут использоваться бизнес-пользователями в организации. Еще одним преимуществом использования расширенных инструментов доступа к данным, кроме повышения производительности, является то, что конечные пользователи сами могут легко изменять и развивать существующие шаблоны отчетов, чтобы получить лучшую информацию, которая не указана в спецификации приложения конечного пользователя.
Подводя итог, можно сказать, что ранние фазы имеют решающее значение, поскольку важно, чтобы разработчики получили хорошее общее представление об организации и ее основных бизнес-процессах. Благодаря этому будет легче добиться хорошего соответствия между бизнесом и корпоративным хранилищем данных. Еще одним важным аспектом на ранних этапах является тщательное планирование всего проекта хранилища данных. В противном случае это может привести к тому, что необходимые ресурсы не будут запланированы, что, в свою очередь, замедлит проект разработки.
Список литературы:
- Туманов В.Е. Проектирование хранилищ данных для приложений систем деловой осведомленности 2-е изд., испр. - М.: Национальный Открытый Университет «ИНТУИТ», 2016. - 645 с.
- Паклин Н.Б., Орешков В.И. Бизнес аналитика: от данных к знаниям: учеб. пособие. 2-е изд. - СПб.: Питер, 2010. - 560 с.
- Точилкина Т.Е., Громова А.А. Хранилища данных и средства бизнес-аналитики: учебное пособие / Т.Е. Точилкина, А.А. Громова. - М.: Финансовый университет, 2017. – 478 с.
- Полубояров В.В. Использование Analysis Services для построения хранилищ данных. - М.: Национальный Открытый Университет «ИНТУИТ», 2010. - 54 с.
- Сарка Д. Реализация хранилищ данных: учебный курс Microsoft. - М.: Изд-во «Русская редакция», 2014. - 146 с.