Хранилища данных

Лабораторная работа 12 — Организация хранилищ данных

Варианты заданий

Содержание отчета

Выполнение лабораторной работы

Выполнение репликации транзакций

Репликация выполняется автоматически, выполним вставку:

use main

go

insert into Студент (N_зач, ФИО, Группа) values (37, 'Волнушкин', '4831')

go

Так как группа 4831 относилась ко второму курсу, запись реплицируется в БД node. Вследствие того, что подписка была создана как немедленно объявляемая, для корректного выполнения репликации из БД node в БД main необходимо задать проверку подлинности SQL Server или Windows для пользователя, редактирующего подписчика (выполняется на подписчике в базе данных подписки):

use node

go

sp_link_publication 'AVB-XEON', 'main', 'Гастелло', 1

go

В БД main таблица Оценка, не заполнялась, выполним вставку:

use node

go

insert into Оценка (N_зач, Код_УП, Оценка, Зачет, Дата)

values (34, 1, 5, 0, '2009/05/01')

go

insert into Оценка (N_зач, Код_УП, Оценка, Зачет, Дата)

values (36, 2, 4, 0, '2009/01/05')

go

После выполнения команд соответствующие строки появляются в БД main. Выполним модификацию:

use node

go

update Студент set ФИО = 'Строчков' where ФИО = 'Сморчков'

go

После выполнения команды изменение отражается в БД main.

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

Содержание отчета:

— скрипты для создания объектов репликации;

— операторы модификации данных для тестирования репликации, наборы данных в таблицах.

Варианты заданий приведены в ПРИЛОЖЕНИИ.

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

Существовало несколько причин такого положения дел, среди которых отмечались:

(i) несовместимость проектов отдельных подсистем КИС (наследие эпохи «стихийной автоматизации», когда отдельные подсистемы создавались различными разработчиками с применение различных СУБД и систем программирования);

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

Ответом на данное положение дел со стороны разработчиков СУБД стала концепция хранилищ данных — DW (Data Warehouse) и появление специального класса серверов для реализации DW. Одним из первых подобных продуктов был Oracle Express Server, являвшийся многомерной СУБД для создания MDB (Multi-Dimensional Database), в котором физически хранение данных организовано в виде гиперкуба, имеющего N измерений (рис. 1).

Рис. 1.

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

Альтернативное решение было предложено в Sybase IQ, где данные, рассматриваемые пользователем в виде гиперкуба, находились в реляционной БД, в которой использовались существенно отличающиеся механизмы (по сравнению с реляционными СУБД), такие как вертикальное хранение (сначала данные 1-го столбца таблицы, затем 2-го и т. д.) и Bitmap индексы.

Появление концепции хранилищ данных привело к разделению современных ИС на два основных класса (рис. 2):

(i) системы OLTP (On-Line Transaction Processing), решающие в основном оперативные («учетные») задачи;

(ii) СППР (системы поддержки принятия решений) или DSS (Decision Support System).

Рис. 2.

Системы OLTP реализуются на основе файл-серверных или клиент-серверных архитектур, имеют нормализованные структуры баз данных, предназначены для автоматизации повседневных задач, решаемых персоналом «нижнего» звена (учет клиентов, договоров, заказов, взаиморасчетов, запасов и пр.).

В отличие от OLTP-систем, системы DSS ориентированы на руководство «верхнего» звена — старших менеджеров, принимающих стратегические решения по проблемам развития корпорации.

Подход, основанный на использовании MDB для построения DSS, получил название OLAP (On-Line Analytical Processing) или MOLAP (Multi-dimensional OLAP), а альтернативный, основанный на реляционных СУБД — ROLAP (relational OLAP).

Ниже в таблице дается краткое сравнение OLTP- и OLAP-технологий.

Таблица 1.

Сравнение OLTP- и OLAP-систем

Признак	OLTP	OLAP
Типы запросов	Статистические (подсчет суммарных итогов)	Аналитические (анализ тенденций, формирование прогнозов)
Типы отчетов	Стандартные (заранее регламентированные: за день, месяц, квартал, год и пр.)	Произвольные, динамические (последовательности итеративно уточняемых отчетов)
Уровень агрегации данных	Детализированные данные	В основном суммарные
Возраст данных	Оперативные и выгруженные из БД в архив	Исторические за большие временные периоды
Частота обновления, объем добавляемых данных	Высокая, добавление небольшими порциями	Низкая, загрузка больших информационных массивов, загруженные ранее данные не изменяются
Упорядоченность данных	Отсутствует	Данные упорядочены хронологически и по другим измерениям
Структура БД	Нормализованная, большое количество связанных таблиц	Ненормализованная, таблица фактов, ссылающаяся на несколько таблиц измерений (ROLAP)

Системы, основанные на хранилищах данных, в последствии стали рассматривать как предназначенные для сбора, интеграции и аналитической обработки информации, накопленной в различных источниках, таких как: оперативные БД (БД OLTP-систем), «плоские» файлы с наборами данных, данные внешних источников (например, данные доступные в глобальных сетях) и др. Важную роль в таких системах играют метаданные (базы метаданных) — знания о структуре существующих баз данных и информационных источников, типе и формате хранимой информации, связях между информационными объектами, семантике информационных объектов и их атрибутов, ограничениях на значения данных и ссылочной целостности и пр. (рис. 3).

Рис. 3.

В настоящее время для организации хранилищ данных реализованы семейства продуктов (IBM Business Intelligence, Oracle Business Intelligence, SAP BusinessObjects и др.), обеспечивающие решение следующих групп задач:

(i) проектирование и реализация хранилища данных;

(ii) работа с метаданными, подготовка и загрузка информации в хранилище — ETL (Extract, Transform, Load);

(iii) собственно выполнение аналитических запросов.

Процесс проектирования и реализации хранилища данных включает несколько этапов:

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

(ii) Анализ информационных источников: собирается информация о структурах имеющихся баз данных, строится/анализируется нормализованная модель данных.

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

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

(v) Построение таблиц фактов: определяется состав фактических показателей для различных сочетаний и/или уровней измерений.

Дата добавления: 2015-05-09