Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
sql.doc
Скачиваний:
1
Добавлен:
01.03.2025
Размер:
653 Кб
Скачать
☆

Комбинация многомерного и реляционного подхода: киоски данных.

HOLAP

Каждая из моделей имеетхранилища имеет свои преимущества и недостатки.

Многомерная модель позволяет производить быстрый анализ данных, но не позволяет хранить большие объёмы информации. Реляционная модель практически не имеет ограничений по бъёму данных, однако значительно уступает по скорости выполнения запросов многомерным СУБД.

Удачными оказываются проекты в которых можно совместить оба подхода.

Обычно отдельный аналитик или отдел обслуживает одно из направлений деятельности организации и для его работы ему не нужны все данных из базы. Выделение необходимых аналитику данных в отдельный набор можено реализовать многомерной СУБД. Такие хранилища данных называют киосками данных т. е. Это специализированное тематическое хранилище обслуживающее одно из направлений деятельности организацтции.

Логическая схема сппр.

Источники информации

OLTP системы

Электронные архивы

Поставщики информации

Загрузка данных

Приведение к единному формату

Агрегирование

Предобработка

Центральное хранилище

Реляциооная паралельная СУБД

Реляциооная паралельная СУБД

Реляциооная паралельная СУБД

Киоски данных

Многомерные СУБД

Многомерные СУБД

Многомерные СУБД

Анализ данных

Многомерные запросы

Статистический анализ

Экспертные системы

Пользователи

Аналитики

Приложения

МногомерныеСУБД:

EssBase

OracleExpress

Geutium

Доставка данных в хранилище.

Как правило составляется расписание пополнения хранилища, в соответствии с которым специальные программы организуют передачу данных в хранилище и их первичную обработу. (ETL)

Процесс загрузки подразумевает решение следующих задач:

  1. Приведение данных к единному формату — унификация типов данных и их представление, исключение управляющих кодов.

  2. Предобработка данных — исключение дубликатов устранение ошибочных значений, востановление пропущенных значений.

  3. Агрегирование

Методы аналитической обработки данных в хранилище.

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

Эти методы используются для решения следующих задач:

  1. Выделение данных групп сходных по некоторым признакам (кластерный анализ).

  2. Нахождение и апроксимация зависимостей, связывающих анализируемые параметры или события, а так же поиск параметров наиболее значимых в стерминах конкретной задачи.

  3. Поиск данных существенно отклоняющихся от выявленных закономерностей (анализ аномалий)

  4. Прогнозирование развития объектов различной природы на основе хранящейся информации об их состоиянии в прошлом.

28.11.2012

Понятие распределенных систем

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

Обычно в кач-ве единой модели использовалась реляционная модель данных.

Идею распределенных систем можно рассмотреть в трех контекстах:

1)Повторное использование существующих и доступных в сети ресурсов.

2)Облегчение разработки корпоративных ИС, отдельные компоненты к-х создаются разными, возможно территориально распределенными группами, каждая из к-х использует привычную для них технологию.

3)Контекст унаследованных систем (Legacy) – в достаточно длительно существующих корпорациях со временем накапливается значительное кол-во ИС в устаревших/устаревающих технологиях. Перевести эти ИС в новые технологии не всегда возможно и экономически выгодно, т.к. это м.б. дорого или систему нельзя отключить даже на короткое время.

Одной из наиболее признанных решений проблем унаследованных систем является объектно-ориентированных подход, а именно – «вокруг» системы создается объектная оболочка, к-я порождает новый объектный интерфейс системы с сохранением старого интерфейса.

Предложение OMG.

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

Основной задачей OMG явл-ся разработка арх. и методов реализации ПО, к-я в объектно-ориентированном стиле позволила бы реализовать интеграцию существующих и заново разрабатываемых информационно-измерительных ресурсов. Основной составляющей ресурса является Core Object Model и общая архитектура брокеро-объектных заявок.

Идея CORBA заключается в следующем: каждый объект, к-й д.б. включен в интегрированную систему добавляется специальный программный код; этот код генерируется автоматически за счет использования языка объектных интерфейсов IDL. Спецификация интерфейса на языке IDL обрабатывается специальным компилятором, к-й генерирует доп. программный код. Правила встраивания конструкции IDL определены для разных языков программирования.

Для взаимодействия объектов предполагается наличие специального ПО, называемого брокером объектных заявок или ORB. Этот ORB должен существовать как на стороне вызывающего объекта, так и на стороне вызываемого объекта.

Основная задача ORB состоит в том, чтобы доставить заявку на вызов метода вызываемого объекта и возвратить результаты в выполнение метода вызывающему объекту. При этом разработчик ничего не знает о том как реализован объект и где он физически расположен, ему известно лишь стандартное описание методов объекта.

Для вызова метода объекта-сервера объект клиент может использовать генерируемый компилятор IDL, т.н. СТАБ – локальный представитель вызываемого метода. Вызываемый объект принимает заявку через генерируемый компилятором IDL программный код, к-й называется «скелетон». Объекты-клиенты имеют возможность без изменения своего кода работать среди любого ORB, к-й поддерживает отображение ORB в соответствующий язык программирования.

Распределенные базы данных.

Системы распределенных БД состоят из набора узлов (сайтов), связанных вместе коммуникационной сетью, в к-й:

1)Каждый узел обладает своими собственными системами БД.

2)Узлы работают согласованно, поэтому пользователь может получить доступ к данным на любом узле сети, как будто все данных находятся на его собственном узле сети.

3)Локальный пользователь на своем локальном узле может выполнять операции с данными так как будто этот узле вовсе не является частью операционной системы.

Распределенная СУБД может рассматриваться как некий способ совместной работы отдельных локальных СУБД, расположенных на отдельных локальных узлах. Функции совместной работы поддерживает новый компонент ПО, расположенный на каждом узле.

Преимущества и недостатки распределенных СУБД.

Преимущества:

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

2)Разделяемость и локальная автономность – данные могут быть помещены на тот узел, на котором они чаще всего востребованы локальными пользователями. Локальные пользователи получают локальный контроль над этими данными и могут регулировать ограничения на их использование. Администратор глобальной базы данных отвечает за систему в целом.

3)Повышение доступности данных – централизованные СУБД прекращают функционирование в случае отказа сервера, а в распределенной же СУБД отказ одного из узлов сделает недоступными лишь некоторые узлы, тогда как система в целом сохранит свою работоспособность.

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

5)Повышение производительности, посравнению с централизованной СУБД. Размещение локальных СУБД в местах их наибольшего использования, позволяют распределить нагрузку минимизируя удалённое подключение.

6)Экономические выгоды. Система собранная из маломощьных компьютеров эквивалентная в сумме мощьности большого компьютера будет стоить дешевле.

7)Модульность системы. Существенно проще осуществлять расширение системы. Добавление в сеть нового узла не оказывает влияние на функционирование уже существующих.

Недостатки:

1)Повышение сложности. Распределённые субд способные скрыть от конечных пользователей распределённую природу используемых ими данных и обеспечить необходимый уровень производительности, надёжности и доступности, являються более сложными программными комплексами, чем централизованные СУБД. Поддержка репликации добавляет ещё 1 уровень сложности — программное обеспечение. Если репликация данных не будет поддерживаться на требуемом уровне, то система будет иметь более низкий уровень доступности данных, надёжности и поизводительности, чем централизованные системы и приемущества превратятся в недостатки.

2)Увеличение стоимости. Разворачивание распределённой СУБД потребует дополнительного оборудования для создания сетерых соединенний между узлами. Так же возрастают расходы на оплату трафика.

3)Проблема защиты. В централизованных системах доступ к данным легко контроллируеться, однако в распределённых системах потребуеться организовать контроль доступа не только к даддным реплицируемум на несколько разлиных узлов, но и защиту сетевых соединений.

4)Усложнение контроля за целостностью данных. Реализация ограничений поддержки целостности требует доступа к большому количеству данных, находящихся на разных узлах. Стоимость передачи данных может быть препятствием организации эфективной защиты от нарушения целостности данных.

5)Отсутствие стандартов.

6)Усложнение процедуры разработки базы данных. Помимо обычных трудностей требуеться принятие решения об организации фрагментации и репликации.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]