Информационные компоненты интеллектуальных систем (часть 2)

Определим формы представления данных. Приведем несколько наиболее распространенных определений базы данных (БД).

Определение 1. Базу данных можно определить как совокупность взаимосвязанных данных (простые или составные типы), которые хранятся вместе на одном носителе и описывают какую-то предметную область при наличии такой минимальной избыточности, которая допускает их оптимальное использование для одного или нескольких приложений. Различают иерархические, сетевые, реляционные, временные (темпоральные), постреляцийни (объектно-ориентированные, с гнездования), распределенные и многомерные базы данных.

Реляционной базой данных называют тройку:

DB = <r, R, Z>

где r – множество отношений базы данных, R – множество их схем, Z – множество ограничений целостности.

Использование базы данных предполагает работу с ней нескольких приложений (приложений), решающих задачи разных пользователей.

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

Определение 3. Консолидированная информация – полученные из нескольких источников и системно интегрированные разнотипных информационные ресурсы, которые в совокупности обладают признаками полноты, целостности, непротиворечивости и составляют адекватную информационную модель проблемной области с целью ее анализа, обработки и использования в процессах поддержки принятия решений.

Исходя из определения, представим формальную модель хранилища данных (СД). Им назовем шестерку

DW = <DB,rf,RF,rm,RM,func>, где DB – множество входных баз данных (реляционных, многомерных, объектно-ориентированных, ненормализованных т.д.) (или множество отношений, их схем и ограничений целостности, содержащие информацию из входящих баз данных), rf – множество отношений фактов, RF – схема rf, rm – множество отношений метаданных, RM – схема rm, func – множество процедур принятия решений.

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

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

И, в-третьих, традиционные базы данных зачастую является источником данных, попадающих в хранилище. Кроме того, хранилище может пополняться за счет внешних источников, например статистических отчетов. Данные, поступающие в базу данных из другой базы, есть небольшого объема (тысячи записей), имеют ту же схему данных и база данных-приемник. В отличие от них хранилища данных в определенные сроки получают значительно большие объемы данных, которые могут отличаться от приемника форматом, а иногда и типом, что требует применения дополнительных процедур трансформации и загрузки данных (так называемые процедуры ETL – Extract, Transform, Load).

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

Учитывая специфику, хранилищах данных имеет следующие особенности проектирования и постройки:

  • Получение информации из различных источников данных (в том числе и из реляционных баз данных) в детализированном и агрегированном виде (сохраняются результаты применения функций агрегации-суммы, среднего значння, максимума, минимума и т.п.);
  • Многомерное представление информации – игнорируются некоторые требования нормализации (соблюдают максимум 3-й нормальной форме), что значительно повышает скорость обработки информации, поскольку уменьшает количество операций соединения JOIN;
  • Наличие метаданных для описания источников метаданных и структуры самого хранилища данных – в базах данных также используют словари для описания структур данных, а в хранилищах данных метаданные (словари, данные о данных) должны строиться по классификационной схеме Захмана. По этой схеме описывающие объекты (что?), Субъекты (кто?), Местонахождение (где?), Время (когда?), Факторы влияния, факторы (почему?), Способы (как?)
  • Наличие пакетной загрузки данных в хранилище данных и выгрузки данных;
  • Наличие процедур анализа данных и получения новых данных;
  • Ориентированность данных на аналитическое, а не на статическую обработку.

Хранилища данных лучше приспособлены к хранению и аналитической обработки больших объемов данных и в основном является интеграцией реляционной и многомерной моделей. Сегодня есть такие архитектуры построения хранилищ данных: корпоративная информационная фабрика Билла Инмона, шина Ральфа Кимбалл, сведение данных корпорации TDAN. Они имеют развитые средства интеграции данных из различных источников и позволяют работать как с детализированной, так и агрегированной информации.

Парадигма для реляционных данных в хранилище данных (парадигма корпоративной информационной фабрики КИФ – Corporate Information Factory, CIF) разработана Инмоном и предполагает, что данные должны находиться на низком степени детализации и в третьей нормальной форме (3НФ, 3NF). Билл Инмон поддерживает повторный или спиральный подход к развитию большого хранилища данных. По этим подходом развитие хранилища происходит итерационно, т.е. в случае возникновения потребности добавляется одна таблица за один раз, что обеспечивает лишь незначительное изменение схемы данных. Поэтому такой подход к проектированию хранилища еще называют спиральным подходом.

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

Область представления пространственно структурирована, при этом она может быть централизованной или распределенной. Пространственная модель хранилища данных содержит ту же атомарном информацию, что и нормализованная модель, но информация структурирована по-другому, чтобы облегчить ее использование и выполнение запросов. Эта модель содержит как атомарные данные, так и обобщающую информацию (агрегаты в связанных таблицах или многомерных кубах) в соответствии с требованиями производительности или пространственного распределения данных. Запросы в процессе выполнения обращаются к все более низкого уровня детализации без дополнительного перепрограммирования со стороны пользователей или разработчиков приложения.

В отличие от подхода Билла Инмона, пространственные модели строятся для обслуживания бизнес-процессов (которые, в свою очередь, связаны с бизнес-показателями или бизнес-событиями), а не бизнес-отделов. Например, данные о заказах, которые должны быть доступны для загалькорпоративного использования, вносятся в пространственного хранилища данных только один раз, в отличие от КИФ-подхода, по которому их пришлось бы трижды копировать в витрины данных отделов маркетинга, продаж и финансов. После того, как в хранилище появляется информация об основных бизнес-процессы, консолидированные пространственные модели могут выдавать их перекрестные характеристики. Матрица корпоративного хранилища данных с архитектурой шины выявляет и усиливает связь между показателями бизнес-процессов (фактами) и описательными атрибутами (измерениями).

Гибридная архитектура, объединяющая особенности реляционной и многомерной моделей, предложенная Дугласом Хэкни. Другим названием модели является согласуемые витрина данных.

При такой архитектуре предусматривается двойное проектирование схемы хранилища данных-разработка нормализованного центрального (корпоративного хранилища) и многомерных (построенных по архитектуре шины) витрин данных. Корпоративное нормализованное хранилище позволяет корректно сохранять данные, а ненормализованных витрины – быстро выполнять запросы пользователей

Сводка данных (Data Vault) (ЗД) – предметно ориентирована, историческая и уникально связана множество нормализованных таблиц, которые поддерживают одну или более функциональных предметных областей. Это – гибридный подход, сочетающий лучшие особенности 3-й нормальной формы (3НФ) и схемы «звезда». Модель гибкая, масштабируемая, последовательная и приспособленная к потребностям различных предметных областей. Она отвечает потребностям хранилища данных и исключает потребность в использовании витрин данных и, в отличие от гибридного подхода Хэкни, не требует двойной работы для надстройки архитектуры шина над архитектурой корпоративной фабрики.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

%d такие блоггеры, как: