Уровни хранилища данных

Корпоративное хранилище данных имеет проектную схему, которая позволяет ему соответствовать текущим и изученным методологиям хранения данных, где результатом является проектирование звездной схемы. Традиционный дизайн хранилища данных в основном связан с работой Ральфа Кимбалла и будет источником концентрации для последующего обсуждения, поскольку он относится к архитектуре системы. Наиболее острым из терминов, введенных Кимбаллом, является термин измерений и таблиц типов фактов как способ, которым данные должны быть организованы для последующей организации в витрины данных и отчетности.
Кроме того, обеспечивается способ перемещения данных из операционного источника, такого как транзакционные базы данных, в само хранилище данных. Сами данные перемещаются через инструмент, известный как “ETL", который означает извлечение, преобразование и загрузку (что само по себе означает шаги, предпринятые с данными для создания хранилища данных). После того, как данные загружены достаточно, данные в соответствующих таблицах дают пользователям возможность сообщать свои данные по мере необходимости.
Первоначальное построение и повторяющиеся обновления данных эволюционировали с течением времени, чтобы предложить эффективный способ загрузки данных. В рамках хранилища данных существуют четыре отдельных и отличных компонента, которые следует рассматривать при изучении среды хранилища данных—операционные исходные системы, промежуточная область данных, область представления данных и инструменты доступа к данным.
Операционный источник - это транзакционные производственные базы данных, которые обычно являются местом хранения всех наших данных. Далее, промежуточная область данных-это база данных, недоступная для пользователей, но это первая остановка для данных из транзакционной системы, где данные собираются вместе через ETL и удовлетворяют своим преобразованиям, прежде чем они продолжают поступать в фактическое хранилище данных.
Область представления данных – это фактическое хранилище данных, заполненное данными, содержащимися в таблицах измерений и фактов, стандартный метод форматирования хранилищ данных. Наконец, крайне важно, чтобы уровень представления существовал, чтобы предоставить пользователям опыт, который дает им данные в формате, необходимом для эффективного принятия решений.
Физическая архитектура хранилища данных начинается на промежуточном уровне модели хранилища данных. Как правило, ETL, представляющий собой инструмент, который извлекает, преобразует и загружает данные из источников данных, представляет собой визуальное приложение, использующее различные графические инструменты пользовательского интерфейса для транспортировки данных из источника в пункт назначения в пределах хранилища.
Для большинства приложений ETL он должен был бы сидеть на графической операционной системе, такой как Windows или Linux, в то время как некоторые из них могли бы работать на операционной системе UNIX. При рассмотрении базы данных, которая будет выступать в качестве хранилища данных, было бы наиболее разумно расположить эту базу данных в той же общей области, что и само хранилище данных, чтобы данные не перемещались так далеко или через серверы.
В зависимости от используемой базы данных это может быть что угодно – от сервера Windows до сервера Linux или HP-UNIX. Поскольку эти базы данных могут быть большими, поскольку они могут быстро копировать большую часть данных из транзакционных баз данных, это необходимо учитывать наряду с пространством, необходимым для основного хранилища данных.
Самое важное аппаратное обеспечение этого проекта зависит от решений, которые будут поддерживать, возможно, самую большую базу данных, которая будет существовать в рамках всей компании

. Оборудование из памяти, процессоров и особенно хранилища должно быть в верхней части списка приоритетов при покупке оборудования для развертывания.
Предприятия должны учитывать не только то, что база данных нуждается сегодня для установки проекта, но и то, что в будущем потребуется улучшить базу данных склада. Основные поставщики реляционных баз данных по-прежнему являются предпочтительными платформами, охватывающими около 80 процентов рынка DW/BI.
Хотя, вероятно, очевидно, какие системы баз данных он имеет в виду, крайне важно убедиться, что эти системы могут справиться с потенциальным размером и потребностями хранения, которые будут необходимы, возможно, в терабайтном диапазоне в сочетании с разумным разделением диска. Когда вы думаете о пространстве для хранения данных, компании также должны предоставить, рассмотреть план резервного копирования и восстановления для этого склада, тем более, что создание резервных копий файлов может быть очень большим по размеру.
Наконец, уровень доступа к данным потребует совершенно другой среды. Хотя возможны одни и те же перекрывающиеся технологии, не следует размещать эти компоненты в одном и том же месте, поскольку системы и уровень хранилища данных должны существовать отдельно друг от друга. В случае уровня доступа к данным снова возникнет необходимость в сервере приложений. Однако при использовании механизма OLAP может потребоваться наличие места для хранения связанной базы данных интеллектуального анализа данных для кубов и других связанных частей этой службы.
Для уровня данных существуют серверы для обработки доступа к данным из интернета, управления запросами, корпоративной отчетности, аутентификации, баз данных метаданных и многого другого. Несмотря на это, большая часть потребностей на этом уровне относится к приложениям и веб-частям, которые предоставляют пользователям ясный и чистый доступ к своим данным, поддерживая инструмент. Выбор также может существовать для платформы, такой как приложение SAP Business Objects, которое может легко работать в UNIX или Windows.
3.2 Загрузка и обработка ETL
Одной из наиболее важных частей хранилища данных является извлечение, преобразование и загрузка данных из оперативных транзакционных баз данных в само хранилище данных. Хотя можно создать ETL, который бы выполнял свою задачу в качестве посредника между транзакционной базой данных и конечной «звездной схемой» хранилища данных, логично извлечь данные и временно сохранить их перед преобразованием.
Эта область хранилища данных, известная как область «Постановка данных» или Оперативное хранилище данных, существует только для извлечения данных из операционной системы, а затем для перегруппировки и очистки (также называемой преобразованием) данных перед загрузкой в ​​организованное хранилище данных. Хранилище данных, особенно для предприятия, имеет данные, поступающие из нескольких источников, и это может привести к тому, что ETL будет работать гораздо дольше, чем было бы целесообразно иметь хранилище данных в первую очередь.
Следовательно, быстрое извлечение всех исходных данных имеет смысл в этом масштабе. Как только данные поступают из транзакционных баз данных, хранение всех данных вдали от бизнес-операций и в уединенном месте дает ETL возможность организовывать и преобразовывать в удобное для себя время. После того, как данные пройдут преобразования разумным образом, данные затем пройдут простой этап ETL, где будут загружены таблицы измерений и фактов хранилища данных. Вероятно, нет лучшей аналогии этой части хранилища данных, чем определение Кимбалла области размещения данных процесса ETL