Студопедия КАТЕГОРИИ: АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Определение и типовые архитектуры хранилищ данных⇐ ПредыдущаяСтр 14 из 14
Концептуально модель хранилища данных можно представить в виде схемы на рис. 7. Данные из различных источников помещают в хранилище, а их описания — в репозиторий метаданных. Репозиторий— место для хранения данных, моделей, интерфейсов и программных реализаций. Метаданные – данные о данных: каталоги, справочники, реестры, базы метаданных, содержащие сведения о составе данных, содержании, статусе, происхождении, местонахождении, качестве, форматах и формах представления, условиях доступа, приобретения и использования, авторских, имущественных и смежных с ними правах на данные и другое. Конечный пользователь, используя различные инструменты (средства визуализации, построения отчетов, статистической обработки и т. д.) и содержимое репозитория, анализирует данные в хранилище. Результатом является информация в виде готовых отчетов, найденных скрытых закономерностей, каких-либо прогнозов. Так как средства работы конечного пользователя с хранилищем данных могут быть самыми разнообразными, то теоретически их выбор не должен влиять на структуру хранилища и функции его поддержания в актуальном состоянии. Физическая реализация данной концептуальной схемы может быть самой разнообразной.
В информационном хранилище используется методология метаданных, благодаря этому блоки базы превращаются в единый работоспособный объект. Все форматы представления метаданных жестко связаны с прикладной программой, которая их использует. Метаданные необходимы для описания каталогов и схем расположения данных. Метаданные позволяют также определять время, источник и приемник данных, алгоритм выполненного преобразования. Это нужно тогда, когда необходимо найти первичную информацию, на которой основывались обобщения. Информационные витрины обеспечивают сотрудников тематической информацией, касающейся финансов, материальных запасов, персонала и т. д. Витрины дают возможность обойтись без создания единого физического хранилища. Для каждого подразделения можно иметь свою витрину, на которой отображать всю информацию, необходимую этому подразделению. Виртуальное хранилище данных — это система, предоставляющая интерфейсы и методы доступа к регистрирующей системе, которые эмулируют работу с данными в этой системе, как с хранилищем данных. Виртуальное хранилище данных можно организовать, создав ряд «представлений» (view) в базе данных либо применив специальные средства доступа. Главными достоинствами такого подхода являются: простота и малая стоимость реализации, единая платформа с источником информации, отсутствие сетевых соединений между источником информации и хранилищем данных. Однако недостатков гораздо больше. Создавая виртуальное хранилище данных, пользователь создает не хранилище как таковое, а иллюзию. Структура хранения и само хранение не претерпевают изменений, и остаются проблемы: производительности, трансформации данных, интеграции данных с другими источниками, отсутствие истории, чистоты данных, зависимость от доступности и структуры основной базы данных. Двухуровневая архитектура хранилища данных подразумевает построение витрин данных (data mart) без создания центрального хранилища, при этом информация поступает из регистрирующих систем и ограничена конкретной предметной областью. При построении витрин используются основные принципы построения хранилищ данных, поэтому их можно считать хранилищами данных в миниатюре. Плюсы: простота и малая стоимость реализации; высокая производительность за счет физического разделения регистрирующих и аналитических систем, выделения загрузки и трансформации данных в отдельный процесс, оптимизированной под анализ структурой хранения данных; поддержка истории; возможность добавления метаданных. Построение полноценного корпоративного хранилища данных обычно выполняется в трехуровневой архитектуре. На первом уровне расположены разнообразные источники данных — внутренние регистрирующие системы, справочные системы, внешние источники (данные информационных агентств, макроэкономические показатели). Второй уровень содержит центральное хранилище, куда стекается информация от всех источников с первого уровня, и, возможно, оперативный склад данных, который не содержит исторических данных и выполняет две основные функции. Во-первых, он является источником аналитической информации для оперативного управления, и, во-вторых, здесь подготавливаются данные для последующей загрузки в центральное хранилище. Под подготовкой данных понимают их преобразование и проведение определенных проверок. Наличие оперативного склада данных просто необходимо при различном регламенте поступления информации из источников. Третий уровень представляет собой набор предметно-ориентированных витрин данных, источником информации для которых является центральное хранилище данных. Именно с витринами данных и работает большинство конечных пользователей. 4.4.3. Проектирование структуры реляционного хранилища данных Опыт построения КХД на крупных многофилиальных предприятиях показывает, что решающее значение для успешного хода данного процесса имеют организационные меры: • постоянная заинтересованность и поддержка со стороны спонсора проекта, при этом все спорные вопросы должны решаться административным методом в минимально короткие сроки; • централизация сбора данных, причем данные должны собираться по возможности неконсолидированные; • проведение работы с участием бизнес - подразделений, досконально знающих предметную область. Создание хранилища, вообще говоря, состоит из следующих этапов: анализа бизнес - задач в части определения необходимых для их решения данных, разработки модели данных (включающий агрегацию и консо-лидацию данных, а также устранение противоречий в них), разработки собственно базы данных на основе построенной модели, первоначальной загрузки данных в КХД (разовой) и организации процессов загрузки данных в КХД, а также выгрузки данных из КХД в витрины данных (наличие этого этапа зависит от типа концептуальной архитектуры). Создание модели данных КХД возможно только при непосредственном участии специалистов предметной области и никакие внешние консультанты, имеющие опыт создания СППР и КХД, но не знающие досконально особенности деятельности данного конкретного предприятия, на котором проводится автоматизация, здесь не помогут. Аналогично не решат всех проблем и типовые системы аналитики и шаблоны хранилищ данных. Они могут только помочь в этом процессе и сократить сроки создания системы и затраты на ее реализацию. Следование вышеуказанным организационным принципам построения КХД позволит наиболее эффективно решить многие проблемы, возникающие при построении хранилища, такие как отсутствие эффективного партнерства между ИТ и бизнесом, связанное с тем, что эти две категории сотрудников рассматривают все бизнес-процессы предприятия со своей позиции, часто говорят об одном и том же понятии разными терминами и не понимают до конца проблем, связанных не с их деятельностью. Кроме того, отсутствие ясности у конечного пользователя, какой именно результат он хочет по- лучить и почему этого нельзя добиться с использованием той или иной технологии – еще одна причина появления противоречий между бизнес-подразделениями и ИТ -структурами. Централизация сбора данных позволит минимизировать задержку данных при сборе и частично устранить несогласованные измерения и факты. К архитектурным принципам относятся принципы построения данных, принципы работы механизма запросов, принципы построения рабочих хранилищ, принципы построения метаданных, принципы масшта- бируемости, принципы управления хранилищем. Основанная на вышеуказанных принципах архитектура хранилища данных обеспечивает правила и подходы к построению концептуальной и логической моделей и их физической реализации. При любом выборе концептуальной архитектуры должны быть решены следующие вопросы: движения данных от источников к хранилищу; распределения и обработки данных для хранилища; описания метаданных, проектирования модели и собственно хранилища; обработки запросов и представления информации. Собственно архитектура хранилища данных делится на три части: архитектуру доступа, архитектуру данных и технологическую архитектуру. Архитектура доступа представляет собой описание способов, с помо- щью которых конечные пользователи получают доступ к данным из хранилища, а также к данным, помещаемым в хранилище. Архитектура данных – это описание структуры и жизненного цикла данных. Технологическая архитектура – это описание технологических деталей хранилища и его взаимодействий с унаследованными системами и существующими технологиями. Фактически же формулировка архитек-турных принципов зависит от среды, в которой должна быть построена архитектура. Если придерживаться вышеуказанных организационных принципов, то сформулированные выше архитектурные принципы нельзя рассматривать в качестве полного множества принципов для произвольного проекта, кроме того, конкретные принципы должны соответствовать конкретному проекту и методологии разработки и корпоративной культуре предприятия. Нужно учи- тывать следующие факторы: величину проектного бюджета, количество ИТ -специалистов, выделенных для участия в проекте, время, выделенное на выполнение проекта, структуру организации и опыт организации в области СППР и хранилищ данных. Итак, после того как обозначены архитектурные принципы, которые должны соблюдаться в ходе проекта построения КХД, выбирается концептуальная архитектура хранилища, наиболее полно им соответствую- щая. Затем идет этап построения логической модели, который служит началом процесса перехода архитектуры из абстрактного мира концептуаль-ных моделей в физический мир анализа аппаратного обеспечения, масшта- бируемости, времени ответа и пропускной способности. При проектировании этот уровень абстракции используется для отображения концептуальной модели на модель, в которой определение функциональных возможностей предваряет определение требований к аппаратному обеспечению. Выбор концептуальной архитектуры хранилища данных основан на последовательности компромиссов, учитывающих масштабы организации, требования и финансовые ограничения. Выбор логической модели также основан на генеральном плане развития ор- ганизационной ИТ -архитектуры и принятых в организации стандартах в области ИТ . Хранилище данных должно адаптироваться ивзаимодействовать со всеми остальными корпоративными системами. При оценке времени и ресурсов, необходимых для построения КХД, необходимо учесть следующие факторы: количество и типы пользователей КХД; расположение пользователей и количество мест их расположения; количество и типы источников данных; количество и типы баз данных-источников; количество и типы баз данных КХД; частоту загрузки данных в хранилище; выделенное время подготовки и загрузки данных; необходимое время подготовки и загрузки данных; сложность типичных незаплани-рованных запросов к хранилищу; сложность стандартных отчетов. Объем начального проекта определяется только исходя из решения наиболее важных бизнес-задач и консолидации данных в наиболее востребованных отчетах. Ни в коем случае не ставится задача одномоментно упорядочить все данные, имеющиеся в организации. Перед началом работ необходимо провести расчет трудоемкости и других ресурсных затрат на создание КХД в следующих трех вариантах: • реконструкции существующей модели данных; • разработки модели КХД с использованием какого- либо промышленного шаблона рассматриваемой предметной области; • разработки модели КХД с нуля под заказ. Итак, сначала необходимо провести анализ данных, которые будут храниться в КХД, провести их нормализацию, идентификацию и реструктуризацию для исключения повторов и агрегированных данных одновременно с самими данными. В результате структура хранилища должна быть такова, что данные должны быть организованы по принципу вложенности. Это самый длительный по времени период, не приносящий к тому же видимых результатов бизнес-подразделениям. Его можно сократить путем включения в первый этап только наиболее важных отчетов. Мировая практика показывает, что работы, связанные с разработкой модели данных, являются наиболее сложными и трудоемкими, а поэтому для сокращения срока работ по построению этой модели и снижения риска непостроения единой согласованной оптимальной модели КХД, лучшей практикой является использование какого- либо промышленного шаблона модели данных, ориентированного на конкретную предметную область модели в качестве альтернативы созданию собственной модели данных «с нуля» под заказ или собственными силами. Кроме того, мировой опыт построения таких систем говорит о том, что нужно разделять данные, используемые для оперативной обработки и для решения задач анализа. Это позволяет применять структуры данных, ко- торые удовлетворяют требованиям их хранения с учетом использования в вышеуказанных двух кардинально отличающихся системах. Такоеразделение позволяет оптимизировать структуру данных под задачи, для выполнения которых они используются. Но информация для проведения аналитических исследований в хранилище данных будет поступать и из транзакционных систем, возможно в некотором агрегированном виде, поэтому при построении всего КХД следует использовать промышленную модель данных, адекватную данной предметной области, которая будет объединяющей для данных OLTP и OLAP – приложений. И еще - в целях построения струк- туры данных, согласованной в части использования единой терминологии, необходимо иметь единый глоссарий терминов, взаимосвязь между которыми определена единым образом. Поэтому, если выбранный промышленный шаблон позволяет еще и разработать, и вести единый глоссарий терминов, однозначно увязанный с моднлью данных, это еще один аргумент использовать промышленный шаблон для построения модели данных. С учетом вышесказанного основополагающие принципы, которые следует соблюдать при построении КХД, сводятся к следующим: • наличию поддержки спонсора (заказчика), с самого начала заручиться поддержкой спонсора проекта. Заказчик должен уяснить, что построение КХД - процесс длительный и не приносящий скорых и явных результатов, но совершенно необходимый для формирования непротиворечивой информационной среды предприятия; • поэтапному построению КХД (сначала под одну задачу, затем под вторую и т.д.), так как невозможно одномоментно консолидировать все данные, имеющиеся в организации; • интеграции и дедубликации существующей информации, то есть в КХД не должно быть несогласованных измерений и фактов; • централизации процесса сбора данных; • хранению по возможности единственной версии «правды» и сбору только атомарных данных (в случае, если хранятся агрегированные данные – запрету drill-down); • очистке и аудиту данных перед и их загрузкой в КХД; • построению модели данных с непосредственным участием бизнес-пользователей и с использованием того или иного промышленного шаблона; • предоставлению данных пользователю в удобных форматах (из-за форматов, которые не устраивают конечного пользователя можно вообще его лишиться); • быстрой доставке данных (время реакции должно быть меньше 5 секунд, иначе пользователь будет избегать таких запросов). |
|||
Последнее изменение этой страницы: 2018-05-10; просмотров: 410. stydopedya.ru не претендует на авторское право материалов, которые вылажены, но предоставляет бесплатный доступ к ним. В случае нарушения авторского права или персональных данных напишите сюда... |