Помещение данных в единое хранилище(Warehousing)



Скачать 58.33 Kb.
Дата10.05.2016
Размер58.33 Kb.
Помещение данных в единое хранилище(Warehousing)


  • Наиболее типичный способ интеграции информационной базы: копирование источников в единую базу и попытка поддержания их в актуальном состоянии.

  • Обычный метод: периодичное обновление хранилища, например, каждую ночь.



OLTP(OnLine Transaction Processing – обработка транзакций) против OLAP(OnLine Analytic Processing – анализ данных)


  • Большинство операций над базой данных являются операциями обработки транзакций в реальном времени (OLTP).

  • Короткие, простые запросы, вовлекающие один или небольшое число кортежей.

  • Примеры: ответы на запросы Web интерфейса, запись продажи в кассе магазина, продажа авиабилетов.




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

  • Обновления относительно редки и/или ответ на запрос не зависит от абсолютной актуальности данных.

  • Например, Amazon.com анализирует покупки всех своих клиентов, чтобы выяснить множество наиболее предпочтительных покупок.

  • Аналитик в большой торговой сети магазинов ищет товары, покупки которых растут в определенном географическом районе.



  • Типичная архитектура базы данных: локальные БД, по одной на магазин, обрабатывают транзакции в реальном времени(OLTP), в то время как единое хранилище данных, интегрирующее информацию от всех магазинов, проводит аналитическую обработку(OLAP).

  • Наиболее сложные OLAP запросы возникают при т.наз. data mining (из словаря: информационная проходка, способ анализа информации в базе данных с целью отыскания аномалий и трендов без выяснения смыслового значения записей)

Звездообразные схемы БД.


Обычно, в хранилище имеются данные двух типов:

  1. Фактические данные: Очень большие собрания фактов, таких как продажи всех товаров в торговой сети за определенный период (год).

  • Часто изменяются только вставкой новых данных, т.е. однажды появившиеся факты остаются.

  1. Размерности: Меньшего размера, в основном, статическая информация, являющаяся частью фактов.

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



  • Фактические данные будут храниться в таблице со схемой: Sales(bar, beer, drinker, day, time, price)

  • Размерности могут включать отношения: одно - для баров, одно - для пива, одно – для посетителей.

Bars(bar, addr, lic)

Beers(beer, manf)

Drinkers(drinker, addr, phone)


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


  1. ROLAP (Relational OLAP): реляционная СУБД, настроенная для звездообразной схемы, например, использующая специальные индексные структуры, такие как:

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

  1. MOLAP (Multidimensional OLAP): специальная модель данных, основанная на «кубическом» представлении фактов.



ROLAP

Типичные запросы начинаются с полного соединения звездообразной схемы, например:


SELECT *

FROM Sales, Bars, Beers, Drinkers

WHERE Sales.bar = Bars.bar

AND Sales.beer = Beers.beer

AND Sales.drinker = Drinkers.drinker;


  • Типичный OLAP запрос:

    1. выполнит все части соединения,

    2. отфильтрует интересующие нас кортежи, основываюсь на данных факт-таблиы и таблиц-размерностей

    3. сгруппирует по одной или большему количеству размерностей.

    4. выполнит агрегирование результатов.

Пример.
Для каждого бара в Palo Alto найти общий объем продаж каждого пива произведенного Anheuser-Busch.

Проблемы эффективности.




  • Если факт-таблица большая, выполнение запросов может требовать слишком много времени.




  • Материализованные представления могут помочь повысить скорость ответов на запросы.

Пример.
Для вопроса предыдущего примера может помочь следующее материализованное представление:


CREATE VIEW BABMS(bar, addr, beer,manf, sales) AS

SELECT bar, addr, beer, manf, SUM(price) AS sales

FROM Sales NATURAL JOIN Bars NATURAL JOIN Beers

GROUP BY bar, addr, beer, manf;




MOLAP

Основан на «кубе» данных: ключи таблиц-размерностей образуют координатные оси «куба».




  • Для нашего примера мы бы могли иметь 4 размерности: бар, пиво, посетитель и время.

  • Зависимые атрибуты (цены продаж в нашем случае) будут представлять «ячейки куба».

  • «куб» также включает агрегаты(обычно – суммы ячеек) по всем своим граням.




  • Пример: В случае нашего 4-х мерного куба мы имеем суммы по каждому бару, каждому пиву, каждому посетителю, и по каждому моменту времени (обычно сгруппированным по дням)

  • Кроме того, на ребрах куба мы имеем суммы по каждому подмножеству(паре, тройке и т.д.) размерностей: по каждому бару и пиву, по каждому пиву, посетителю и дню, ...

Slicing и Dicing.




  • Расщепить(Slice) = выбрать значение по одной размерности, например, определенный бар,

  • Создать сетку(Dice) = тоже самое по другой размерности, например определенному пиву.



Drill-Down и Roll-Up.


  • Идти вглубь(Drill-down) = де агрегировать = разбить агрегат на составляющие.

  • Пример: определив, что бар Joe в Palo Alto продает много пива произведенного Anheuser-Busch, разбить эту информацию по сортам пива.

  • Свернуть(Roll-up) = агрегировать по одной размерности.

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

Эффективность выполнения запросов.


Также как и для ROLAP, могут помочь материализованные представления.


  • Можно считать, что «куб» включает материализованные представления, являющиеся агрегатами по одной или более размерностям.

  • Размерности не обязательно агрегировать полностью по всевозможным подмножествам.

  • Пример: материализованное представление может агрегировать по посетителю полностью, по пиву – совсем не агрегировать, по времени – по каждому дню, по барам – по городу, где бар расположен.

  • Время является особенной размерностью, поскольку естественной группирование по неделям и месяцам является несоизмеримым (в том смысле, что информацию по неделям нельзя агрегировать в информацию по месяцам).



Анализ данных(Data Mining).
Крупномасштабные запросы, предназначенные для выявления закономерностей в данных.

  • Важный пример: «ассоциативные правила» или «частые наборы элементов».


Данные о покупательских корзинах.
Важным источником информации для ассоциативных правил являются покупательские корзины.

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

  • Это дает на данные в виде схемы Baskets(bid,item).

  • Торговые менеджеры хотели бы знать, какие товары покупаются вместе.

  • Например, если гамбургер и кетчуп покупаются вместе, то поместить их на стеллажах рядом, с картофельными чипсами посередине.

  • При этом можно объявить дешевую распродажу на гамбургеры и немного поднять цену на кетчуп.

Первая проблема: Найти часто покупаемые пары товаров

При заданном пороговом значении s, мы можем запросить:


  • Найти пары товаров, присутствующих вместе, по крайней мере, в s корзинах.

SELECT b1.item, b2.item

FROM Baskets b1, Baskets b2

WHERE b1.bid = b2.bid

AND b1.item < b2.item

GROUP BY b1.item, b2.item

HAVING COUNT(*) >= s;

Априорный прием.


Вышеприведенный пример является слишком трудоемким для больших объемов данных.

  • Априорный алгоритм использует тот факт, что пара (i; j) может встречаться не менее s раз только в случае, когда оба значения i и j встречаются не менее s раз.

  • Более эффективным способом выявления частоты пар является создание промежуточного отношения Baskets1.

INSERT INTO Baskets1(bid, item)

SELECT * FROM Baskets

WHERE item IN ( SELECT item

FROM Baskets

GROUP BY item



HAVING COUNT(*) >= s

);
Затем выполнить запрос над отношением Baskets1 вместо Baskets.


База данных защищена авторским правом ©bezogr.ru 2016
обратиться к администрации

    Главная страница