Студопедия  
Главная страница | Контакты | Случайная страница

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

Технические аспекты многомерного хранения данных

 

Как уже говорилось выше, средства OLAP-анализа могут извлекать данные и непосредственно из реляционных систем и из многомерных СУБД. Выбор модели хранения данных это нетривиальный вопрос.

Реляционные СУБД (РСУБД)

 

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

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

Примером такого реально существующего ограничения является предположение о том, что данные в реляционной базе не упорядочены (или, более точно, упорядочены случайным образом). Но выполнение большинства аналитических функций (например построение Прогноза), наоборот, невозможно без предположения об упорядоченности данных. Естественно, при использовании реляционной базы имеется возможность после выборки данных из базы, выполнить их сортировку и затем построить Прогноз. Но это потребует дополнительных затрат времени на сортировку; сортировка должна будет проводиться каждый раз при обращении к этой функции, и, самое главное, такая функция может быть определена и применена только в пользовательском приложении, но не может быть встроенной функцией языка SQL.

Во-вторых, для обеспечения приемлемого времени ответа, при использовании РСУБД, нужно уже на этапе проектирования знать обо всех возможных типах запросов, необходимых срезах и уровнях агрегации данных.

Основой традиционного реляционного подхода является нормализация (декомпозиция) таблиц, подразумевающая устранение избыточности в основных ключах таблиц и устранение транзитивных зависимостей между реквизитами, образующими таблицу. Это позволяет минимизировать суммарный объем данных в БД и решить проблемы, связанные с различного рода аномалиями, возникающими при удалении и модификации данных в ненормализованных таблицах. И хотя в процессе нормализации утрачиваются и семантические связи, существующие между реквизитами, это не особенно критично для традиционных СОД. Те немногие связи, которые необходимы для реализации конкретного приложения, известны заранее и легко реализуются с помощью механизма внешних ключей. Для аналитических систем эта проблема более критична. Здесь обычно даже нельзя заранее определить, какие связи между различными реквизитами будут применяться более часто, а какие не будут использоваться вообще. Все зависит от неординарности мышления конкретного аналитика, ситуации на рынке, в фирме и многих других факторов.

 




Дата добавления: 2015-09-12; просмотров: 14 | Поможем написать вашу работу | Нарушение авторских прав

Хранилище данных | OLAP - инструмент анализа | Многомерное представление OLAP |


lektsii.net - Лекции.Нет - 2014-2024 год. (0.005 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав