МЕНЮ


Фестивали и конкурсы
Семинары
Издания
О МОДНТ
Приглашения
Поздравляем

НАУЧНЫЕ РАБОТЫ


  • Инновационный менеджмент
  • Инвестиции
  • ИГП
  • Земельное право
  • Журналистика
  • Жилищное право
  • Радиоэлектроника
  • Психология
  • Программирование и комп-ры
  • Предпринимательство
  • Право
  • Политология
  • Полиграфия
  • Педагогика
  • Оккультизм и уфология
  • Начертательная геометрия
  • Бухучет управленчучет
  • Биология
  • Бизнес-план
  • Безопасность жизнедеятельности
  • Банковское дело
  • АХД экпред финансы предприятий
  • Аудит
  • Ветеринария
  • Валютные отношения
  • Бухгалтерский учет и аудит
  • Ботаника и сельское хозяйство
  • Биржевое дело
  • Банковское дело
  • Астрономия
  • Архитектура
  • Арбитражный процесс
  • Безопасность жизнедеятельности
  • Административное право
  • Авиация и космонавтика
  • Кулинария
  • Наука и техника
  • Криминология
  • Криминалистика
  • Косметология
  • Коммуникации и связь
  • Кибернетика
  • Исторические личности
  • Информатика
  • Инвестиции
  • по Зоология
  • Журналистика
  • Карта сайта
  • Принципы проектирования и использования многомерных баз данных

    Более того, для решения большинства аналитических задач, скорее всего,

    потребуется использование внешних по отношению к РСУБД, специализированных

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

    (например построение прогноза) невозможно без предположения об

    упорядоченности данных. Но в РСУБД предполагается, что данные в БД не

    упорядочены (или, более точно, упорядочены случайным образом). Естественно,

    здесь имеется возможность после выборки данных из БД выполнить их

    сортировку и затем аналитическую функцию. Но это потребует дополнительных

    затрат времени на сортировку. Сортировка должна будет проводиться каждый

    раз при обращении к этой функции, и, самое главное, такая функция может

    быть определена и использована только во внешнем по отношению к РСУБД

    пользовательском приложении и не может быть встроенной функцией языка SQL.

    Не менее важно и то, что многие критически необходимые для оперативных

    систем функциональные возможности, реализуемые в РСУБД, являются

    избыточными для аналитических задач. Например, в аналитических системах

    (табл. 3) данные обычно загружаются достаточно большими порциями из

    различных внешних источников (оперативных БД, заранее подготовленных

    плоских файлов, электронных таблиц). И, как правило, время и

    последовательность работ по загрузке, резервированию и обновлению данных

    могут быть спланированы заранее. Поэтому в таких системах обычно не

    требуются и, соответственно, не предусматриваются, например, развитые

    средства обеспечения целостности, восстановления и устранения взаимных

    блокировок и т.д. А это не только существенно облегчает и упрощает сами

    средства реализации, но и значительно снижает внутренние накладные расходы

    и, следовательно, повышает производительность при выполнении их основной

    целевой функции - поиске и выборке данных.

    |Характеристика |Оперативные |Аналитические |

    |Частота обновления |Высокая частота, маленькими |Малая частота, большими |

    | |порциями |порциями |

    |Источники данных |В основном внутренние |В основном внешние (по |

    | | |отношению к аналитической |

    | | |системе) |

    |Возраст данных |Текущие (за период от |В основном исторические (за |

    | |нескольких месяцев до одного |период в несколько лет, |

    | |года) |десятки лет) и прогнозируемые|

    |Уровень агрегации |Детализированные данные |В основном агрегированные |

    |данных | |данные |

    |Назначение |Фиксация, оперативный поиск и|Работа с историческими |

    | |обработка данных |данными, аналитическая |

    | | |обработка, прогнозирование и |

    | | |моделирование |

    Таблица 3. (Характеристики данных в системах, ориентированных на

    оперативную и аналитическую обработку данных).

    Многомерная модель данных

    "Многомерный взгляд на данные наиболее характерен для пользователя,

    занимающегося анализом данных" - это утверждение сегодня стало уже почти

    аксиомой. Однако, что такое многомерное представление, откуда появляется

    многомерность в трехмерном мире, чем оно отличается и чем оно лучше

    ставшего уже привычным реляционного представления? И наконец, откуда среди

    нас появились люди, мыслящие в четырех и более измерениях, и как это им

    удается - именно эти вопросы возникают практически у любого, впервые

    прочитавшего это утверждение.

    На самом деле все сказанное в этом утверждении - чистая правда, и

    пользователю, занимающемуся анализом, действительно присуща многомерность

    мышления. Весь вопрос в том, что понимать под Измерением.

    Двухмерное представление данных конечному пользователю

    Достаточно очевидно, что даже при небольших объемах данных отчет,

    представленный в виде двухмерной таблицы (Модели автомобиля по оси Y и

    Время по оси X), нагляднее и информативнее отчета с реляционной построчной

    формой организации (рис. 1).

    Реляционная модель

    |Модель |Месяц |Объем |

    |"Жигули" |Июнь |12 |

    |"Жигули" |Июль |24 |

    |"Жигули" |Август |5 |

    |"Москвич" |Июнь |2 |

    |"Москвич" |Июль |18 |

    |"Волга" |Июль |19 |

    Многомерная модель

    | |Июнь |Июль |Август |

    |"Жигули" |12 |24 |5 |

    |"Москвич" |2 |18 |No |

    |"Волга" |No |19 |No |

    Рисунок 1. (Реляционная и многомерная модели представления данных).

    А теперь представим, что у нас не три модели, а 30 и не три, а 12

    различных месяцев. В случае построчного (реляционного) представления мы

    получим отчет в 360 строк (30х12), который займет не менее 5-6 страниц. В

    случае же многомерного (в нашем случае двухмерного) представления мы

    получим достаточно компактную таблицу 12 на 30, которая вполне уместится на

    одной странице и которую, даже при таком объеме данных, можно реально

    оценивать и анализировать.

    И когда говорится о многомерной организации данных, вовсе не

    подразумевается то, что данные представляются конечному пользователю

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

    да и пользователю более привычно и комфортно иметь дело с двухмерным

    табличным представлением и двухмерной бизнес-графикой.

    Закономерен вопрос: "Где же здесь многомерность, откуда она берется и

    куда исчезает?" Ответ прост. Когда говорится о многомерности, имеется в

    виду не многомерность визуализации, а многомерное представление при

    описании структур данных и поддержка многомерности в языках манипулирования

    данными.

    Многомерное представление при описании структур данных

    Основными понятиями, с которыми оперирует пользователь и проектировщик в

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

    . измерение (Dimension);

    . ячейка (Cell).

    Иногда вместо термина "Ячейка" используется термин "Показатель"

    (Measure).

    Измерение - это множество однотипных данных, образующих одну из граней

    гиперкуба. Например - Дни, Месяцы, Кварталы, Годы - это наиболее часто

    используемые в анализе временные Измерения. Примерами географических

    измерений являются: Города, Районы, Регионы, Страны и т.д.

    В многомерной модели данных Измерения играют роль индексов, используемых

    для идентификации конкретных значений (Показателей), находящихся в Ячейках

    гиперкуба.

    В свою очередь, Показатель - это поле (обычно цифровое), значения

    которого однозначно определяются фиксированным набором Измерений. В

    зависимости от того, как формируются его значения, Показатель может быть

    определен, как:

    . Переменная (Variable) - значения таких Показателей один раз вводятся

    из какого-либо внешнего источника или формируются программно и затем в

    явном виде хранятся в многомерной базе данных (МБД);

    . Формула (Formula) - значения таких Показателей вычисляются по

    некоторой заранее специфицированной формуле. То есть для Показателя,

    имеющего тип Формула, в БД хранится не его значения, а формула, по

    которой эти значения могут быть вычислены.

    Заметим, что это различие существует только на этапе проектирования и

    полностью скрыто от конечных пользователей.

    В примере на рис. 1 каждое значение поля Объем продаж однозначно

    определяется комбинацией полей:

    Модель автомобиля;

    Месяц продаж.

    Но в реальной ситуации для однозначной идентификации значения Показателя,

    скорее всего, потребуется большее число измерений, например:

    Модель автомобиля;

    Менеджер;

    Время (например Год).

    Измерения:

    Время (Год) - 1994, 1995, 1995

    Менеджер - Петров, Смирнов, Яковлев

    Показатель:

    Объем Продаж

    И в терминах многомерной модели речь будет идти уже не о двухмерной

    таблице, а о трехмерном гиперкубе:

    первое Измерение - Модель автомобиля;

    второе Измерение - Менеджер, продавший автомобиль;

    третье Измерение - Время (Год);

    на пересечении граней которого находятся значения Показателя Объем

    продаж.

    Заметим, что, в отличие от Измерений, не все значения Показателей должны

    иметь и имеют реальные значения. Например, Менеджер Петров в 1994 г. мог

    еще не работать в фирме, и в этом случае все значения Показателя Объем

    продаж за этот год будут иметь неопределенные значения.

    Гиперкубические и поликубические модели данных

    В различных МСУБД используются два основных варианта организации данных:

    . Гиперкубическая модель;

    . Поликубическая модель.

    В чем состоит разница? Системы, поддерживающие Поликубическую модель

    (примером является Oracle Express Server), предполагают, что в МБД может

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

    различными Измерениями в качестве их граней. Например, значение Показателя

    Рабочее Время Менеджера, скорее всего, не зависит от Измерения Модель

    Автомобиля и однозначно определяется двумя Измерениями: День и Менеджер. В

    Поликубической модели в этом случае может быть объявлено два различных

    гиперкуба:

    Двухмерный - для Показателя Рабочее Время Менеджера;

    Трехмерный - для Показателя Объем Продаж.

    В случае же Гиперкубической модели предполагается, что все Показатели

    должны определяться одним и тем же набором Измерений. То есть только из-за

    того, что Объем Продаж определяется тремя Измерениями, при описании

    Показателя Рабочее Время Менеджера придется также использовать три

    Измерения и вводить избыточное для этого Показателя Измерение Модель

    Автомобиля.

    Операции манипулирования Измерениями

    Формирование "Среза". Пользователя редко интересуют все потенциально

    возможные комбинации значений Измерений. Более того, он практически никогда

    не работает одновременно сразу со всем гиперкубом данных. Подмножество

    гиперкуба, получившееся в результате фиксации значения одного или более

    Измерений, называется Срезом (Slice). Например, если мы ограничим значение

    Измерения Модель Автомобиля = "ВАЗ2108", то получим подмножество гиперкуба

    (в нашем случае - двухмерную таблицу), содержащее информацию об истории

    продаж этой модели различными менеджерами в различные годы.

    Операция "Вращение". Изменение порядка представления (визуализации)

    Измерений (обычно применяется при двухмерном представлении данных)

    называется Вращением (Rotate). Эта операция обеспечивает возможность

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

    Например, если менеджер первоначально вывел отчет, в котором Модели

    автомобилей были перечислены по оси X, а Менеджеры по оси Y, он может

    решить, что такое представление мало наглядно, и поменять местами

    координаты (выполнить Вращение на 90 градусов).

    Отношения и Иерархические Отношения. В нашем примере значения Показателей

    определяются только тремя измерениями. На самом деле их может быть гораздо

    больше и между их значениями обычно существуют множество различных

    Отношений (Relation) типа "один ко многим".

    Например, каждый Менеджер может работать только в одном подразделении, а

    каждой модели автомобиля однозначно соответствует фирма, которая ее

    выпускает:

    Менеджер ->Подразделение;

    Модель Автомобиля ->Фирма-Производитель.

    Заметим, что для Измерений, имеющих тип Время (таких как День, Месяц,

    Квартал, Год), все Отношения устанавливаются автоматически, и их не

    требуется описывать.

    В свою очередь, множество Отношений может иметь иерархическую структуру -

    Иерархические Отношения (Hierarchical Relationships). Вот только несколько

    примеров таких Иерархических Отношений:

    День -> Месяц -> Квартал -> Год;

    Менеджер -> Подразделение -> Регион -> Фирма -> Страна;

    Модель Автомобиля -> Завод-Производитель -> Страна.

    И часто более удобно не объявлять новые Измерения и затем устанавливать

    между ними множество Отношений, а использовать механизм Иерархических

    Отношений. В этом случае все потенциально возможные значения из различных

    Измерений объединяются в одно множество. Например, мы можем добавить к

    множеству значений Измерения Менеджер ("Петров", "Сидоров", "Иванов",

    "Смирнов"), значения Измерения Подразделение ("Филиал 1", "Филиал 2",

    "Филиал 3") и Измерения Регион ("Восток", "Запад") и затем определить между

    этими значениями Отношение Иерархии.

    Операция Агрегации. С точки зрения пользователя, Подразделение, Регион,

    Фирма, Страна являются точно такими же Измерениями, как и Менеджер. Но

    каждое из них соответствует новому, более высокому уровню агрегации

    значений Показателя Объем продаж. В процессе анализа пользователь не только

    работает с различными Срезами данных и выполняет их Вращение, но и

    переходит от детализированных данных к агрегированным, т.е. производит

    операцию Агрегации (Drill Up). Например, посмотрев, насколько успешно в

    1995 г. Петров продавал модели "Жигули" и "Волга", управляющий может

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

    Подразделения, где Петров работает. А затем получить аналогичную справку по

    Региону или Фирме.

    Операция Детализации. Переход от более агрегированных к более

    детализированным данным называется операцией Детализации (Drill Down).

    Например, начав анализ на уровне Региона, пользователь может захотеть

    получить более точную информацию о работе конкретного Подразделения или

    Менеджера.

    Проектирование многомерной БД

    Данная работа ни в коем случае не посвящена рассмотрению методологии

    проектирования МБД, и здесь излагаются только самые общие элементы подхода

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

    только позволит наиболее полно понять как достоинства, так и ограничения

    многомерного подхода, но и послужит хорошей основой для быстрого построения

    систем.

    Определение вопросов

    Основное назначение МСУБД - реализация систем, ориентированных на

    динамический, многомерный анализ исторических и текущих данных, анализ

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

    большой степени ориентированы на обработку произвольных, заранее не

    регламентированных запросов, и при их разработке фактически отсутствует

    этап проектирования регламентированных пользовательских приложений

    (наиболее ответственный и трудоемкий в традиционных оперативных системах).

    Проектирование МБД обычно начинается с определения вопросов (табл. 4), с

    которыми конечные пользователи хотели бы обратиться к системе. Причем на

    этом этапе интерес представляют даже не сами тексты вопросов, а понимание

    того, о каких личностях, местах, событиях и объектах в них спрашивается.

    |Подразделение |Менеджер |Временной |Вопрос |

    | | |интервал | |

    |Отдел |Петров |3 года |На сколько процентов увеличились |

    | | | |продажи "Жигулей" в Западном регионе |

    | | | |после январской рекламной кампании в |

    | | | |еженедельнике "Западный Вестник"? |

    |Финансовый |Смирнов |5 лет |Какие региональные подразделения |

    |отдел | | |превысили в третьем квартале |

    | | | |запланированные расходы на командировки|

    | | | |и как это соотносится с ростом их |

    | | | |прибыли (в абсолютных и относительных |

    | | | |величинах)? |

    |Коммерческий |Левшин |10 лет |Какие два варианта скидок наиболее |

    |отдел | | |эффективны в Западном регионе в летний |

    | | | |период при продаже автомобилей |

    | | | |"Жигули", на основе данных за последние|

    | | | |10 лет? |

    |Отдел развития |Васильева |5 лет |Как повлияло на объемы продаж открытие |

    |бизнеса | | |двух новых отделений в Южном регионе и |

    | | | |на какой процент могут увеличиться |

    | | | |продажи в Северном регионе, если в этом|

    | | | |году там будет открыто 3 новых офиса? |

    Таблица 4. (Список потенциальных вопросов менеджеров фирмы).

    Рассмотрим в качестве примера вопрос сотрудника коммерческого отдела

    ("Какие два варианта скидок наиболее эффективны в Западном регионе в летний

    период при продаже автомобилей "Жигули", на основе данных за последние 10

    лет?"). Как было сказано выше, на этом этапе мы не собираемся

    программировать этот вопрос, тем более, что инструментальные средства

    конечного пользователя позволят легко сформулировать его в интерактивном

    режиме, без написания строк кода. Сейчас нам важнее понять, какие данные

    должны быть в МБД, оценить временные интервалы, которые должны отражаться,

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

    После того как первичный анализ вопросов выполнен, и получено

    представление о том, какие данные потенциально могут выступать в качестве

    Показателей и Измерений (табл. 5), можно переходить к проектированию ее

    структуры - определению конкретных Измерений, их взаимосвязей и уровней

    агрегации хранимых данных.

    |Наименование |Временной |Количество строк|Тип |Источник |

    |информации |интервал | | | |

    |Месяц |10 лет |12 * 10 |Измерение |Оперативная |

    | | | | |система "Продажи",|

    | | | | |архив |

    |Регион |10 лет |5 |Измерение |- "" - |

    |Модель |10 лет |200 |Измерение |- "" - |

    |автомобиля | | | | |

    |Типы скидок |10 лет |4 |Измерение |- "" - |

    |Объем продаж |10 лет |200 * 12 * 10 * |Показатель |- "" - |

    |в USD | |5 * 4 | | |

    Таблица 5. (Данные, необходимые для ответа на вопрос аналитика

    коммерческого отдела).

    Критерии выбора уровня агрегации

    Если спросить пользователя, какой уровень детализации ему желателен, он

    не задумываясь ответит - максимально возможный. Однако стоит оценить,

    сколько такое решение может стоить, и попытаться определить возможный

    экономический эффект от наличия данных на каждом новом уровне детализации.

    Например, выбрав в качестве уровня агрегации Год, вы получите возможность

    проанализировать общие тенденции автомобильного рынка и спрогнозировать

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

    Неделю, вы, кроме того, сможете спрогнозировать спрос на конкретные модели

    в конкретные моменты времени. И хотя автомобили - товар не сезонный, скорее

    всего, весной и летом их покупают больше, чем осенью и зимой. Это позволит

    отследить возможные сезонные колебания, рациональнее формировать свой склад

    и более эффективно проводить политику формирования сезонных скидок и

    распродаж. А если в систему введена информация о затратах на маркетинг,

    появится возможность проследить эффект от каждого конкретного

    маркетингового мероприятия.

    Выбор в качестве уровня агрегации Номер Контракта/Счета позволит перейти

    на качественно новый уровень анализа. На этом уровне можно будет учитывать

    взаимосвязи между конкретным Автомобилем, Менеджером и Покупателем. А

    поскольку при покупке автомобиля заполняется множество документов, то

    доступна достаточно детальная информация о каждом конкретном Покупателе

    (Возраст, Пол, Место жительства, Вид оплаты и т.д.). Теперь вы сможете

    проанализировать не только рынок, но и заглянуть внутрь своей фирмы и

    всесторонне проанализировать эффективность работы каждого Менеджера и

    Подразделения. Но наиболее ценное, что вы получаете, - это информация о

    Регионах и Покупателях. Например, вы не только сможете оценить, какие

    Модели автомобилей пользуются наибольшим спросом в конкретном регионе

    сегодня, но на основе анализа истории и структуры автомобильного рынка в

    более развитых, с точки зрения автомобилизации, регионах попытаться оценить

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

    Однако переход на каждый следующий уровень детализации и добавление новых

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

    размера целевой МБД и соответствующему удорожанию и усложнению аппаратного

    решения.

    Рассмотрим в качестве примера Показатель Объем продаж. Анализ предметной

    области показывает, что он однозначно определяется комбинацией четырех

    Измерений:

    1. Неделя

    2. Филиал

    3. Фирма-Производитель

    4. {Тип скидки}

    Выбрав уровень детализации:

    1. День (365 * 10 = 3650 различных значений),

    2. Менеджер (300 различных значений),

    3. Модель Автомобиля (100 различных значений),

    4. Тип Скидки (4 различных значения),

    получим куб, состоящий из 438000000 ячеек. Но в основе используемого в

    МСУБД способа хранения данных лежит предположение о том, что внутри, в

    данном случае четырехмерного гиперкуба, нет пустот. Данные в МСУБД

    представлены в виде разреженных матриц с заранее фиксированной

    размерностью. При этом значения Показателей хранятся в виде множества

    логически упорядоченных блоков (массивов), имеющих фиксированную длину,

    причем именно блок является минимальной индексируемой единицей.

    Таким образом, в нашей БД будет сразу же зарезервировано место для всех

    438 млн. значений Показателя Объем Продаж. Причем цифры "300 менеджеров" и

    "100 моделей автомобилей" вовсе не означают того, что сегодняшняя

    номенклатура фирмы - 100 различных моделей, которые продают 300 человек.

    Цифра 300 говорит о том, что в фирме за 10 лет ее существования работало

    300 различных менеджеров. Сегодня же их может быть, например, всего 30.

    Попробуем оценить, какой процент ячеек в нашем случае будет содержать

    реальные значения. Предположим, что в среднем в фирме постоянно работает

    около 30 менеджеров, менеджер продает в день 10 различных моделей и при

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

    скидки. Тогда 3650 * 30 * 10 * 1 = 1095000. То есть только 0,25% ячеек куба

    будет содержать реальные значения данных. И хотя в МСУБД обычно

    предполагается, что блоки, полностью заполненные неопределенными

    значениями, не хранятся, как правило, это не обеспечивает полного решения

    проблемы.

    Загрузка данных

    Как уже было сказано выше, основное назначение МСУБД - работа с

    достаточно стабильными во времени данными, и данные в таких системах

    достаточно редко вводятся в интерактивном режиме. Обычно загрузка

    выполняется из внешних источников: оперативных БД, электронных таблиц или

    из заранее подготовленных плоских файлов.

    В OLAP системах загрузка данных может производиться практически из

    различных внешних источников данных, включая:

    различные РСУБД;

    плоские файлы с фиксированной структурой записей;

    электронных таблиц (Lotus 1-2-3, Ecxell и т.д.);

    в интерактивном режиме через специально написанные пользовательские

    приложения.

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

    так и загружаться динамически, в тот момент, когда к ним обратится

    пользователя. Таким образом, имеется возможность постоянно хранить в МБД

    только ту информацию, которая наиболее часто запрашивается пользователями.

    Для всех остальных данных хранятся только описания их структуры и программы

    их выгрузки из центральной (обычно реляционной) БД. И хотя при первичном

    обращении к таким виртуальным данным, время отклика может оказаться

    достаточно продолжительным, такое решение обеспечивает высокую гибкость и

    требует более дешевых аппаратных средств. А если впоследствии оказывается,

    что интенсивность обращения к данным, имеющим статус временных, высока, их

    статус может быть легко изменен.

    Заключение

    В заключение необходимо сказать, что было бы не совсем правильно

    противопоставлять или говорить о какой-либо серьезной взаимной конкуренции

    реляционного и многомерного подходов. Правильнее сказать, что эти два

    подхода взаимно дополняют друг друга. Как отметил Э. Кодд [1], реляционный

    подход никогда не предназначался для решения на его основе задач, требующих

    синтеза, анализа и консолидации данных. И изначально предполагалось, что

    такого рода функции должны реализовываться с помощью внешних по отношению к

    РСУБД, инструментальных средств.

    Но именно на решение таких задач и ориентированы МСУБД. Область, где они

    наиболее эффективны, это хранение и обработка высоко агрегированных и

    стабильных во времени данных. И их применение оправдано только при

    выполнении двух требований.

    Уровень агрегации данных в БД достаточно высок, и, соответственно, объем

    БД не очень велик (не более нескольких гигабайт).

    В качестве граней гиперкуба выбраны достаточно стабильные во времени

    Измерения (с точки зрения неизменности их взаимосвязей), и, соответственно,

    число несуществующих значений в ячейках гипрекуба относительно невелико.

    Поэтому уже сегодня МСУБД все чаще используются не только как

    самостоятельный программный продукт, но и как аналитические средства

    переднего плана, к системам Хранилищ Данных или традиционным оперативным

    системам, реализуемым средствами РСУБД.

    [pic]

    Рисунок 1.(Многоуровневая архитектура).

    Причем такое решение позволяет наиболее полно реализовать и использовать

    достоинства каждого из подходов: компактное хранение детализированных

    данных и поддержка очень больших БД, обеспечиваемые РСУБД и простота

    настройки и хорошие времена отклика, при работе с агрегированными данными,

    обеспечиваемые МСУБД.

    Литература

    1. Codd, S.B. Codd, C.T. Salley. Providing OLAP (On-Line Analytical

    Processing) to User-Analysts: An IT Mandate. - E.F.Codd & Associates,

    1993.

    2. Guide to OLAP Terminology. - Kenan Systems Corporation, 1995

    Страницы: 1, 2


    Приглашения

    09.12.2013 - 16.12.2013

    Международный конкурс хореографического искусства в рамках Международного фестиваля искусств «РОЖДЕСТВЕНСКАЯ АНДОРРА»

    09.12.2013 - 16.12.2013

    Международный конкурс хорового искусства в АНДОРРЕ «РОЖДЕСТВЕНСКАЯ АНДОРРА»




    Copyright © 2012 г.
    При использовании материалов - ссылка на сайт обязательна.