Студопедия

КАТЕГОРИИ:

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника



Загрузка Хранилища




Читайте также:
  1. АВТОМАТИЧЕСКИЕ СИСТЕМЫ УПРАВЛЕНИЯ МИКРОКЛИМАТОМ В ОВОЩЕХРАНИЛИЩАХ
  2. Вопрос: Загрузка анодной печи.
  3. Вопрос: Загрузка конвертера
  4. Загрузка пластиковой нити в Joysmaker
  5. Информационные хранилища
  6. Концепции хранилища данных (ХД)
  7. Методы удаления и захоронения твердых и жидких отходов. Наземные свалки и полигоны. Подземные хранилища.
  8. Перезагрузка
  9. С грузами в расчете на 1 м2 площади) хранилища со стеллажными кранами-штабелерами при установке поддонов стороной 1200 мм вдоль стеллажей

При заполнении ХД необходимо определить спектр задач, которые будут решаться с его помощью и круг пользователей.

При описании технологии заполнения Хранилища различают три взаимосвязанные задачи:

  • Сбор Данных (Data Acquisition),
  • Очистка Данных (Data Cleansing) и
  • Агрегирование Данных (Data Consolidation).

 

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

1. поддерживаются интерфейсы всех крупных производителей серверов баз данных (Oracle, Informix, ADABAS и т. д.);

2. практически всегда имеется ODBC-интерфейс;

3. можно извлекать данные из текстовых файлов в формате CSV (comma separated values) и из некоторых структурированных файлов, например файлов dBase.

Набор имеющихся интерфейсов — важнейшая характеристика, которая часто позволяет оценить, для каких задач проектировался продукт. Так, если среди поддерживаемых интерфейсов имеются AS/400, 052/400, IMS, VSAM (как в популярном продукте PASSPORT фирмы Carleton), то он предназначен скорее для использования в системах, работающих на больших мэйнфреймах, чем в сети из ПК. Несколько иной набор интерфейсов предлагает, например, хорошо известный продукт InfoPump фирмы PLATINUM Technology, который обеспечивает поддержку LotusNotes, Microsoft Access, dBase и работу с текстовыми файлами. Крупные производители серверов либо имеют собственные средства сбора данных, либо устанавливают партнерские отношения с производителями таких средств и разрабатывают инструментарий промежуточного уровня для тиражирования «чужих» данных (таков, например, Replication Server фирмы Sybase).

 

 

 
 

 


 

 
 

 


Рис. 1.8. Склад данных с простой архитектурой клиент-сервер

 

Второй аспект процесса сбора данных, который автоматизирован в некоторых продуктах, - это организация процесса пополнения Хранилища. В том же InfoPump, например, имеется возможность строить расписание пополнения Хранилища данными либо на временной основе, либо с использованием механизма событий. Имеются и более сложные программные комбинации, например корпорация Software AG разработала собственное решение для сбора и очистки данных, называемое, SourcePoint,, которое на нижнем уровне использует PASSPORT, а функции организации расписаний реализует как надстройку над этим нижним уровнем. Помимо этого SourcePoint реализует параллельные извлечение, передачу данных и заполнение Хранилища.



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

Агрегация– отношение «часть - целое».

При заполнении Хранилища агрегированными данными мы должны обеспечить выборку данных из транзакционной базы данных и других источников в соответствии с метаданными, поскольку агрегирование происходит в терминах бизнес-понятий. Так, например, агрегированная величина «объем продаж продукта Х в регионе Y за последний квартал» содержит понятия «продукт» и «регион», которые являются бизнес-понятиями данного предприятия. Следует подчеркнуть, что задача выборки необходимых данных не может быть решена полностью автоматически: возможны коллизии (отсутствие необходимых данных, ошибки в данных и т. п.), когда вмешательство человека окажется необходимым. Далее, предполагая, что объектом анализа являются числовые показатели, связанные с бизнес-понятиями, такие как ОБЪЕМ ПРОДАЖ или ПРИБЫЛЬ, когда необходимо определить правила вычисления этих показателей для составных бизнес-понятий, исходя из их значений для более простых бизнес-понятий. Это и есть правила агрегирования.



Простейшей архитектурой системы на основе ХД является архитектура клиент-сервер. Традиционно само хранилище размещается на сервере (или на серверах), а анализ данных выполняется на клиентах. Некоторое усложнение в эту схему вносят Витрины Данных. Они также размещаются на серверах, но, учитывая взаимодействия между Витринами, приходится вводить так называемые переходники (Hub Servers), через которые идет обмен данными между Витринами.

Переход к базам данных клиент-сервер – относительно небольшой скачок в развитии хранилища данных. На рис. 1.8 и 1.9 показаны две альтернативные архитектуры хранилища данных, основанные на современной модели клиент-сервер.

На рис. 1.8 приложение EIS, написанное на языке Xbase осуществляет доступ к централизованному SQL-хранилищу данных посредством прикладного программного интерфейса ODBC. В такой среде довольно легко реализовать простейшую модель клиент-сервер, где один сервер обслуживает несколько клиентов.

На рис. 1.9 представлен более сложный вариант архитектуры клиент-сервер.

Доступ к логически централизованному на множестве платформ, осуществляется так же, как и в примере на рис. 1.8. Однако внутри хранилища данных для доступа к его распределенным компонентам применяется комбинация интерфейсов IDAPI и DRDA API. В таком случае приложение, выполняющееся над хранилищем данных, выступает в двоякой роли: как сервер для комплекса приложений EIS и как клиент, запрашивающий информацию у других серверов хранилища данных.

 

 

 

 

 

 


 

                           
 
     
     
   
 
 
 
   
     
 
 
 

 

 


IDAPI

 

IDAPI

 

                   
   
     
   
 
     
 
 
 

 


DRDA

 
 


 
 

 

 


Рис.1.9. Распределенный склад данных со сложной архитектурой клиент-сервер

 


Дата добавления: 2014-10-31; просмотров: 24; Нарушение авторских прав





lektsii.com - Лекции.Ком - 2014-2020 год. (0.011 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав
Главная страница Случайная страница Контакты