Программирование >>  Хронологические базы данных 

1 ... 268 269 270 [ 271 ] 272 273 274 ... 348


Итого

Итого

1000

1600

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

Многомерные базы данных

До сих пор предполагалось, что OLAP-данные хранятся в обычной базе данных, использующей язык SQL (не считая того, что пару раз мы все же касались терминологии и концепции многомерных баз данных ). Фактически мы неявно описывали так называемую систему ROLAP ( реляционную OLAP ). Однако многие считают, что использование системы MOLAP ( многомерной OLAP ) - более перспективный путь. В этом подразделе принципы построения систем MOLAP будут рассмотрены подробнее.

Система MOLAP подразумевает ведение многомерных баз данных, в которых данные концептуально хранятся в ячейках многомерного массива.

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

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

Если о совокупности данных имеется достаточно четкое представление, могут быть установлены и все существующие между данными связи. Более того, переменные такой совокупности (не в смысле обычных языков программирования), грубо говоря, могут быть разделены на зависимые и независимые. В предыдущем примере продукт, заказчик и период времени можно считать независимыми переменными, а количество - единственной зависимой переменной. В общем случае независимые переменные - это переменные, значения которых вместе определяют значения зависимых переменных (точно так, как, если воспользоваться реляционной терминологией, потенциальный ключ является множеством столбцов, значения которых определяют значения остальных столбцов). Следовательно, независимые переменные составляют размерность массива, с помощью которого организуются данные, а также образуют схему adpecaijuu для данного массива. Значения зависимых переменных, которые представляют реальные данные, сохраняются в ячейках массива.

Ячейки массива адресуются символически, а не числовыми индексами, которые обычно ассоциируются с массивалш.



Замечание. Различие между значениями независимых или размерных переменных и значениями зависимых или неразмерных переменных иногда характеризуют как различие между размещением и содержанием.

К сожалению, предыдущая характеристика многомерных баз данных слишком упрощена, поскольку большинство совокупностей данных изначально понимаемы не в полной мере. По этой причине мы обычно стремимся, в первую очередь, проанализировать данные, что позволяет лучше их понимать. Часто недостаточное понимание может быть настолько серьезным, что заранее невозможно определить, какие переменные независимые, а какие зависимые. Независимые переменные часто выбираются по текущему представлению о них (т.е. по предположению), а результирующий массив затем тестируется для проверки его соответствия требованиям заказчика (см. раздел 21.7). Подобный подход приводит к тому, что выполняется множество итераций процесса проб и ошибок. Поэтому система обычно допускает замену размерных и неразмерных переменных, и эту операцию называют заменой ведущих элементов (pivoting). Другие поддерживаемые операции включают транспозицию массива и раз.мерное переупорядочение. Имеются также возможности добавления размерностей.

Между прочим, из предыдущего описания должно быть ясно, что ячейки массива часто будут пустыми, поэтому массивы обычно являются разреженными. Предположим, например, что товар р не продавался заказчику с в течение всего времени t. Тогда ячейка {c,p,t) будет пустой (или в лучшем случае содержать значение нуль). Многомерные СУБД поддерживают различные методы хранения разреженных массивов в более эффективном сжатом представлении. К этому следует добавить, что пустые ячейки соответствуют отсутствующей информации , и, следовательно, системам необходимо предоставлять некоторую вычислительную поддержку для пустых ячеек. Такая поддержка действительно обычно имеется, и стиль ее, к сожалению, похож на стиль, принятый в языке SQL. Обратите внимание на тот факт, что если данная ячейка пуста, то информация или неизвестна, или не была введена, или непригодна, или уйму других причин (см. главу 18).

Независимые переменные часто связаны в иерархии, определяющие пути, по которым зависимые данные могут объединяться. Например, существует временная иерархия, связывающая секунды с минутами, минуты с часами, часы с днями, дни с неделями, недели с месяцами, месяцы с годами. Или другой пример: возможна иерархия, связывающая детали с комплектом деталей, комплект деталей с узлом, узел с панелью, панель с изделием. Часто одни и те же данные могут быть объединены многими разными способами, т.е. одна и та же независимая переменная может принадлежать многим различным иерархиям. Система предоставляет операторы для прохождения вверх (drill up) и прохождения вниз (drill down) по такой иерархии. Прохождение вверх означает переход от нижнего уровня объединения к верхнему, а прохождение вниз- в противоположном направлении. Для обработки иерархий имеются и другие операции, например операция для переупорядочения уровней иерархии.

Обратите внимание на отличие от реляционных систем. В настоящем реляционно.м аналоге этого примера в строке fc,p,t) не было бы пустой ячейки ; просто строка fc,p,t) отсутствовала бы. Поэто.му в реляционной модели нет необходимости в понятии разреженных массивов , или скорее разреженных таблиц , а значит, не нужны и искусные методы сжатия для представления таких таблиц.



Замечание. Между операциями пройти вверх и накопить есть одно различие: операция накопить - операция создания необходимых группирований и объединений, а операция пройти вверх - операция доступа к таким объединениям. Примером операции пройти вниз мог бы быть такой запрос: Дано итоговое количество поставок; получить итоговые количества для каждого отдельного поставщика. Конечно, для ответа на такой запрос должны быть доступны (или вычисляемы) данные более детальных уровней.

В продуктах многомерных баз данных также предоставляется ряд статистических и других математических функций, которые помогают формулировать и проверять гипотезы (т.е. предполагаемые связи). Также предоставляются инструменты визуализации и генерации отчетов, помогающие решать подобные задачи. Однако, к сожалению, для многомерных баз данных пока еще нет никакого стандартного языка запросов, хотя ведутся исследования с целью разработки исчисления, на котором такой стандарт мог бы базироваться [21.27]. Но ничего подобного теории нормализации, которая могла бы служить научной базой для проектирования многомерных баз данных, пока, к сожалению, нет.

Завершая этот раздел, отметим, что в некоторых продуктах сочетаются оба подхода- ROLAP и MOLAP. Такую гибридную систему OLAP называют HOLAP. Ведется много споров, чтобы установить, какой из этих трех подходов лучше, поэтому стоит и нам попытаться сказать по данному вопросу пару слов. В общем случае системы MOLAP обеспечивают более быстрые расчеты, но поддерживают меньшие объемы данных по сравнению с системами ROLAP, т.е. становятся менее эффективными по мере возрастания объемов данных. Системы ROLAP обеспечивают большие возможности масштабируемости, параллельности и управления в сравнении с аналогичными возможностями систем MOLAP.

21.7. Разработка данных

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

Замечание. Слово большие здесь нужно выделить особо. Базы для разработки данных часто чрезвычайно большие, поэтому очень важно, чтобы применяемые алгоритмы обеспечивали масштабируемость.

Рассмотрим не очень большую таблицу продаж SALES, показанную на рис. 21.5, в которой содержатся данные относительно определенных деловых сделок по продажам На основе этих данных требуется выполнить аначиз набора потребительских товаров.

Оптепиш, что ключ в этой таблице - {TXi, PRODUCT}, данные в таблице удовлетворяют функциональным зависимостям TXf-CUSTf и TX§->TIMESTAMP, а значит, она не приведена к нормальной форме Бойса-Кодда (БКНФ): версия таблицы, в которой столбец PRODUCT содержал бы значения-отношения (а столбец ТХ§ был бы ключом), могла бы быть в БКНФ и лучше бы под-ходипа для выполнения данных исследований (хотя, возможно, меньше подходила бы для других видов исследования).



1 ... 268 269 270 [ 271 ] 272 273 274 ... 348

© 2006 - 2024 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика