Реферат: Принципы проектирования и использования многомерных баз данных
Конечно, средствами традиционных РСУБД и на основании данных, хранящихся в реляционной БД, можно построить заранее регламентированный аналитический отчет (табл. 2) и даже Прогноз об ожидаемом объеме продаж автомобилей на следующий год.
Характеристика | Статический анализ | Динамический анализ |
Типы вопросов | Сколько? Как? Когда? | Почему? Что будет если? |
Время отклика | Не регламентируется | Секунды |
Типичные операции | Регламентированный отчет, диаграмма | Последовательность интерактивных отчетов, диаграмм, экранных форм; динамическое изменение уровней агрегации и срезов данных |
Уровень аналитических требований | Средний | Высокий |
Тип экранных форм | В основном определенный заранее, регламентированный | Определяемый пользователем |
Уровень агрегации данных | Детализированные и суммарные | В основном суммарные |
Возраст данных | Исторические и текущие | Исторические, текущие и прогнозируемые |
Типы запросов | В основном предсказуемые | Непредсказуемые, от случаю к случаю |
Назначение | Работа с историческими и текущими данными, регламентированная аналитическая обработка и построение прогнозов | Работа с историческими, текущими и прогнозируемыми данными. Многопроходный анализ, моделирование |
Таблица 2. (Сравнение характеристик статического (регламентированного) и динамического анализа).
Но, как правило, после просмотра такого отчета у пользователя (аналитика) появится не готовый ответ, а новая серия вопросов. Однако, если бы ему захотелось получить ответ на новый вопрос, он может ждать его часы, а иногда и дни. Обычно каждый новый непредусмотренный заранее запрос должен быть сначала формально описан, передан программисту, запрограммирован и, наконец, выполнен. Но после того, как аналитик получит долгожданный ответ, достаточно часто оказывается, что решение не могло ждать и оно уже принято, или что случается еще чаще, произошло взаимное непонимание и получен ответ на не совсем тот вопрос. Впрочем, не намного меньшее время затрачивается и на получение ответа и на заранее описанный и запрограммированный запрос.
Более того, для решения большинства аналитических задач, скорее всего, потребуется использование внешних по отношению к РСУБД, специализированных инструментальных средств. Выполнение большинства аналитических функций (например построение прогноза) невозможно без предположения об упорядоченности данных. Но в РСУБД предполагается, что данные в БД не упорядочены (или, более точно, упорядочены случайным образом). Естественно, здесь имеется возможность после выборки данных из БД выполнить их сортировку и затем аналитическую функцию. Но это потребует дополнительных затрат времени на сортировку. Сортировка должна будет проводиться каждый раз при обращении к этой функции, и, самое главное, такая функция может быть определена и использована только во внешнем по отношению к РСУБД пользовательском приложении и не может быть встроенной функцией языка SQL.
Не менее важно и то, что многие критически необходимые для оперативных систем функциональные возможности, реализуемые в РСУБД, являются избыточными для аналитических задач. Например, в аналитических системах (табл. 3) данные обычно загружаются достаточно большими порциями из различных внешних источников (оперативных БД, заранее подготовленных плоских файлов, электронных таблиц). И, как правило, время и последовательность работ по загрузке, резервированию и обновлению данных могут быть спланированы заранее. Поэтому в таких системах обычно не требуются и, соответственно, не предусматриваются, например, развитые средства обеспечения целостности, восстановления и устранения взаимных блокировок и т.д. А это не только существенно облегчает и упрощает сами средства реализации, но и значительно снижает внутренние накладные расходы и, следовательно, повышает производительность при выполнении их основной целевой функции - поиске и выборке данных.
Характеристика | Оперативные | Аналитические |
Частота обновления | Высокая частота, маленькими порциями | Малая частота, большими порциями |
Источники данных | В основном внутренние | В основном внешние (по отношению к аналитической системе) |
Возраст данных | Текущие (за период от нескольких месяцев до одного года) | В основном исторические (за период в несколько лет, десятки лет) и прогнозируемые |
Уровень агрегации данных | Детализированные данные | В основном агрегированные данные |
Назначение | Фиксация, оперативный поиск и обработка данных | Работа с историческими данными, аналитическая обработка, прогнозирование и моделирование |
Таблица 3. (Характеристики данных в системах, ориентированных на оперативную и аналитическую обработку данных).
Многомерная модель данных
"Многомерный взгляд на данные наиболее характерен для пользователя, занимающегося анализом данных" - это утверждение сегодня стало уже почти аксиомой. Однако, что такое многомерное представление, откуда появляется многомерность в трехмерном мире, чем оно отличается и чем оно лучше ставшего уже привычным реляционного представления? И наконец, откуда среди нас появились люди, мыслящие в четырех и более измерениях, и как это им удается - именно эти вопросы возникают практически у любого, впервые прочитавшего это утверждение.
На самом деле все сказанное в этом утверждении - чистая правда, и пользователю, занимающемуся анализом, действительно присуща многомерность мышления. Весь вопрос в том, что понимать под Измерением.
Двухмерное представление данных конечному пользователю
Достаточно очевидно, что даже при небольших объемах данных отчет, представленный в виде двухмерной таблицы (Модели автомобиля по оси Y и Время по оси X), нагляднее и информативнее отчета с реляционной построчной формой организации (рис. 1).
Реляционная модель
Модель | Месяц | Объем |
"Жигули" | Июнь | 12 |
"Жигули" | Июль | 24 |
"Жигули" | Август | 5 |
"Москвич" | Июнь | 2 |
"Москвич" | Июль | 18 |
"Волга" | Июль | 19 |
Многомерная модель
Июнь |
Июль |
Август | |
"Жигули" |
12 |
24 |
5 |
"Москвич" |
2 |
18 |
No |
"Волга" |
No |
19 |
No |
Рисунок 1. (Реляционная и многомерная модели представления данных).