Хранилище данных никогда не бывает статичным; это развивается, поскольку бизнес расширяется. По мере развития бизнеса его требования постоянно меняются, и поэтому хранилище данных должно быть спроектировано таким образом, чтобы соответствовать этим изменениям. Следовательно, система хранилища данных должна быть гибкой.
В идеале должен быть процесс доставки для доставки хранилища данных. Однако проекты хранилищ данных обычно страдают от различных проблем, которые затрудняют выполнение задач и результатов в строгой и упорядоченной манере, требуемой методом водопада. В большинстве случаев требования не поняты полностью. Архитектура, проектирование и сборка компонентов могут быть выполнены только после сбора и изучения всех требований.
способ доставки
Метод доставки — это вариант подхода совместной разработки приложений, принятого для доставки хранилища данных. Мы организовали процесс доставки в хранилище данных, чтобы минимизировать риски. Подход, который мы обсудим здесь, не сокращает общий масштаб времени доставки, но гарантирует, что преимущества для бизнеса будут предоставляться постепенно в процессе разработки.
Примечание. Процесс доставки разбит на этапы, чтобы снизить риск проекта и доставки.
Следующая диаграмма объясняет этапы процесса доставки —
ИТ стратегия
Хранилище данных — это стратегические инвестиции, которые требуют бизнес-процесса для получения выгод. ИТ-стратегия необходима для обеспечения и сохранения финансирования проекта.
Бизнес-кейс
Целью бизнес-кейса является оценка бизнес-преимуществ, которые следует извлечь из использования хранилища данных. Эти выгоды могут быть не поддаются количественной оценке, но прогнозируемые выгоды должны быть четко указаны. Если у хранилища данных нет четкого бизнес-обоснования, то на каком-то этапе в процессе доставки бизнес может столкнуться с проблемами доверия. Поэтому в проектах хранилищ данных нам необходимо понимать экономическое обоснование инвестиций.
Образование и прототипирование
Организации экспериментируют с концепцией анализа данных и изучают ценность наличия хранилища данных, прежде чем соглашаться на решение. Это решается путем прототипирования. Это помогает в понимании осуществимости и преимуществ хранилища данных. Деятельность по созданию прототипов в малых масштабах может способствовать процессу обучения, если:
-
Прототип решает определенную техническую задачу.
-
Прототип можно выбросить после того, как будет показана концепция осуществимости.
-
Действие обращается к небольшому подмножеству возможного содержимого данных хранилища данных.
-
График активности не является критическим.
Прототип решает определенную техническую задачу.
Прототип можно выбросить после того, как будет показана концепция осуществимости.
Действие обращается к небольшому подмножеству возможного содержимого данных хранилища данных.
График активности не является критическим.
Следующие пункты должны быть учтены, чтобы выпустить раннюю версию и обеспечить бизнес-преимущества.
-
Определите архитектуру, которая способна развиваться.
-
Сосредоточьтесь на бизнес-требованиях и технических этапах проекта.
-
Ограничьте область действия первой фазы сборки до минимума, обеспечивающего преимущества для бизнеса.
-
Понимать краткосрочные и среднесрочные требования к хранилищу данных.
Определите архитектуру, которая способна развиваться.
Сосредоточьтесь на бизнес-требованиях и технических этапах проекта.
Ограничьте область действия первой фазы сборки до минимума, обеспечивающего преимущества для бизнеса.
Понимать краткосрочные и среднесрочные требования к хранилищу данных.
Бизнес-требования
Чтобы обеспечить качественные результаты, мы должны убедиться, что общие требования понятны. Если мы понимаем бизнес-требования как для краткосрочных, так и для среднесрочных периодов, мы можем разработать решение для удовлетворения краткосрочных требований. Краткосрочное решение может быть затем превращено в полное решение.
На этом этапе определяются следующие аспекты:
-
Бизнес-правило, которое должно применяться к данным.
-
Логическая модель для информации в хранилище данных.
-
Профили запросов для немедленного требования.
-
Исходные системы, которые предоставляют эти данные.
Бизнес-правило, которое должно применяться к данным.
Логическая модель для информации в хранилище данных.
Профили запросов для немедленного требования.
Исходные системы, которые предоставляют эти данные.
Технический План
На этом этапе необходимо создать общую архитектуру, удовлетворяющую долгосрочным требованиям. На этом этапе также предоставляются компоненты, которые должны быть внедрены в короткие сроки, чтобы получить какую-либо выгоду для бизнеса. В проекте необходимо указать следующее.
- Общая архитектура системы.
- Политика хранения данных.
- Стратегия резервного копирования и восстановления.
- Архитектура сервера и витрины.
- План мощности для оборудования и инфраструктуры.
- Компоненты дизайна базы данных.
Сборка версии
На этом этапе производится первая поставка продукции. Этот производственный результат является наименьшим компонентом хранилища данных. Этот наименьший компонент добавляет выгоду для бизнеса.
Загрузка истории
Это фаза, на которой остаток требуемой истории загружается в хранилище данных. На этом этапе мы не добавляем новые объекты, но, вероятно, будут созданы дополнительные физические таблицы для хранения увеличенных объемов данных.
Давайте возьмем пример. Предположим, что фаза версии сборки предоставила хранилище данных анализа розничных продаж с историей за 2 месяца. Эта информация позволит пользователю анализировать только последние тенденции и решать краткосрочные проблемы. Пользователь в этом случае не может определить годовые и сезонные тренды. Чтобы помочь ему в этом, история продаж за последние 2 года может быть загружена из архива. Теперь данные 40 ГБ расширены до 400 ГБ.
Примечание. Процедуры резервного копирования и восстановления могут стать сложными, поэтому рекомендуется выполнять это действие в отдельной фазе.
Специальный запрос
На этом этапе мы настраиваем специальный инструмент запросов, который используется для управления хранилищем данных. Эти инструменты могут генерировать запрос к базе данных.
Примечание. Рекомендуется не использовать эти инструменты доступа, когда база данных существенно изменяется.
автоматизация
На этом этапе процессы оперативного управления полностью автоматизированы. Это будет включать —
-
Преобразование данных в форму, пригодную для анализа.
-
Мониторинг профилей запросов и определение соответствующих агрегатов для поддержания производительности системы.
-
Извлечение и загрузка данных из разных исходных систем.
-
Генерация агрегатов из предопределенных определений в хранилище данных.
-
Резервное копирование, восстановление и архивация данных.
Преобразование данных в форму, пригодную для анализа.
Мониторинг профилей запросов и определение соответствующих агрегатов для поддержания производительности системы.
Извлечение и загрузка данных из разных исходных систем.
Генерация агрегатов из предопределенных определений в хранилище данных.
Резервное копирование, восстановление и архивация данных.
Расширение сферы
На этом этапе хранилище данных расширяется для удовлетворения нового набора бизнес-требований. Область может быть расширена двумя способами —
-
Загружая дополнительные данные в хранилище данных.
-
Вводя новые витрины данных, используя существующую информацию.
Загружая дополнительные данные в хранилище данных.
Вводя новые витрины данных, используя существующую информацию.
Примечание. Этот этап следует выполнять отдельно, поскольку он требует значительных усилий и сложности.
Требования Эволюция
С точки зрения процесса доставки, требования всегда меняются. Они не статичны. Процесс доставки должен поддерживать это и позволять отражать эти изменения в системе.
Эта проблема решается путем проектирования хранилища данных на основе использования данных в бизнес-процессах, в отличие от требований к данным существующих запросов.
Архитектура предназначена для изменения и расширения в соответствии с потребностями бизнеса, процесс работает как процесс разработки псевдо-приложений, где новые требования постоянно включаются в деятельность по разработке и создаются частичные результаты. Эти частичные результаты возвращаются пользователям, а затем дорабатываются, обеспечивая постоянное обновление всей системы в соответствии с потребностями бизнеса.