OLTP и OLAP системы

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

Сильно нормализованные модели данных хорошо подходят для OLTP -приложений – On - Line Transaction Processing (OLTP ) – приложений оперативной обработки транзакций. Типичными примерами OLTP -приложений являются системы складского учета, заказов билетов, операционные банковские системы и другие. Основная функция подобных систем заключается в выполнении большого количества коротких транзакций. Сами транзакции являются достаточно простыми, но проблемы состоят в том, что таких транзакций очень много, выполняются они одновременно и при возникновении ошибок транзакция должна откатиться и вернуть систему в состояние, в котором та была до начала транзакции. Практически все запросы к базе данных в OLTP -приложениях состоят из команд вставки, обновления и удаления. Запросы на выборку, в основном, предназначены для предоставления пользователям выборки данных из различного рода справочников. Таким образом, большая часть запросов известна заранее ещё на этапе проектирования системы. Критическим для OLTP -приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP -приложениях, тем оно быстрее и надежней. Отступления от этого правила могут происходить тогда, когда уже на этапе разработки известны некоторые часто возникающие запросы, требующие соединения отношений и от скорости выполнения которых существенно зависит работа приложений.

Другим типом приложений являются OLAP -приложения – On - Line Analitical Processing (OLAP ) – приложения оперативной аналитической обработки данных. Это обобщенный термин, характеризующий принципы построения систем поддержки принятия решений – Decision Support System (DSS ), хранилищ данных – Data Warehouse , систем интеллектуального анализа данных – Data Mining . Такие системы предназначены для нахождения зависимостей между данными, для проведения динамического анализа по принципу «что если…» и тому подобных задач. OLAP -приложения оперируют с большими массивами данных, накопленными на предприятии или взятыми из других источников. Такие системы характеризуются следующими признаками:

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

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

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

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

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

Характеристика	OLTP	OLAP
Назначение системы	Регистрация, оперативный поиск и обработка транзакций, регламентированный анализ	Работа с историческими данными, аналитическая обработка, прогнозирование, моделирование
Хранимые данные	Оперативные, детализированные	Охватывающие большой период времени, агрегированные
Тип данных	Структурированные	Разнотипные
"Возраст" данных	Текущие (несколько месяцев)	Исторические (за годы) и прогнозируемые
Частота обновления данных	Высокая, небольшими "порциями"	Малая, большими "порциями"
Уровень агрегации данных	Детализированные данные	В основном - агрегированные данные
Преобладающие операции	Ввод данных, поиск, обновление	Анализ данных
Способ использования данных	Предсказуемый	Непредсказуемый
	На уровне транзакции	На уровне всей базы данных
Вид деятельности	Оперативная, тактическая	Аналитическая, стратегическая
Приоритеты		Гибкость Автономность пользователя
	Большое количество работников исполнительного звена	Относительно малое количество работников руководящего звена

Сравнение OLTP и OLAP

Характеристика	OLTP	OLAP
Характер запросов	Много простых транзакций	Сложные транзакции
Хранимые данные	Оперативные, детализи-рованные	Охватывающие большой период времени, агреги-рованные
Вид деятельности	Оперативная, тактическая	Аналитическая, страте-гическая
Тип данных	Структурированные	Разнотипные
Системная характеристика	Учетная система (OLTP)	OLAP
Взаимодействие с пользователем	На уровне транзакции	На уровне всей базы данных
Данные, используемые при обращении пользователя к системе	Отдельные записи	Группы записей
Время отклика	Секунды	От нескольких секунд до нескольких минут
Использование аппаратных ресурсов	Стабильное	Динамическое
Характер данных	Главным образом первичные (самый низкий уровень детализации)	В основном производные (сводные значения)
Характер доступа к базе данных	Предопределенные или статические пути доступа и отношения данных	Неопределенные или динамические пути доступа и отношения данных
Изменчивость данных	Высокая (данные обновляются с каждой транзакцией)	Низкая (во время запроса данные обновляются редко)
Приоритеты	Высокая производительность Высокая доступность	Гибкость Автономность пользователя

Сравнение нормализованных и ненормализованных моделей

Анализ критериев для нормализованных и ненормализованных моделей данных

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

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

У слабо нормализованных отношений единственное преимущество - если к базе данных обращаться только с запросами на выборку данных, то для слабо нормализованных отношений такие запросы выполняются быстрее. Это связано с тем, что в таких отношениях уже как бы произведено соединение отношений и на это не тратится время при выборке данных.

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

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

Сильно нормализованные модели данных хорошо подходят для так называемых OLTP-приложений (On-Line Transaction Processing (OLTP )- оперативная обработка транзакций ). Типичными примерами OLTP-приложений являются системы складского учета, системы заказов билетов, банковские системы, выполняющие операции по переводу денег, и т.п. Основная функция подобных систем заключается в выполнении большого количества коротких транзакций. Сами транзакции выглядят относительно просто, например, "снять сумму денег со счета А, добавить эту сумму на счет В". Проблема заключается в том, что, во-первых, транзакций очень много, во-вторых, выполняются они одновременно (к системе может быть подключено несколько тысяч одновременно работающих пользователей), в-третьих, при возникновении ошибки, транзакция должна целиком откатиться и вернуть систему к состоянию, которое было до начала транзакции (не должно быть ситуации, когда деньги сняты со счета А, но не поступили на счет В). Практически все запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления, удаления. Запросы на выборку в основном предназначены для предоставления пользователям возможности выбора из различных справочников. Большая часть запросов, таким образом, известна заранее еще на этапе проектирования системы. Таким образом, критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP-приложении, тем оно, как правило, быстрее и надежнее. Отступления от этого правила могут происходить тогда, когда уже на этапе разработки известны некоторые часто возникающие запросы, требующие соединения отношений и от скорости выполнения которых существенно зависит работа приложений. В этом случае можно пожертвовать нормализацией для ускорения выполнения подобных запросов.

Другим типом приложений являются так называемые OLAP-приложения (On-Line Analitical Processing (OLAP ) - оперативная аналитическая обработка данных ). Это обобщенный термин, характеризующий принципы построения систем поддержки принятия решений (Decision Support System - DSS ), хранилищ данных (Data Warehouse ), систем интеллектуального анализа данных (Data Mining ). Такие системы предназначены для нахождения зависимостей между данными (например, можно попытаться определить, как связан объем продаж товаров с характеристиками потенциальных покупателей), для проведения анализа "что если…". OLAP-приложения оперируют с большими массивами данных, уже накопленными в OLTP-приложениях, взятыми их электронных таблиц или из других источников данных. Такие системы характеризуются следующими признаками:

• Добавление в систему новых данных происходит относительно редко крупными блоками (например, раз в квартал загружаются данные по итогам квартальных продаж из OLTP-приложения).
• Данные, добавленные в систему, обычно никогда не удаляются.
• Перед загрузкой данные проходят различные процедуры "очистки", связанные с тем, что в одну систему могут поступать данные из многих источников, имеющих различные форматы представления для одних и тех же понятий, данные могут быть некорректны, ошибочны.
• Запросы к системе являются нерегламентированными и, как правило, достаточно сложными. Очень часто новый запрос формулируется аналитиком для уточнения результата, полученного в результате предыдущего запроса.
• Скорость выполнения запросов важна, но не критична.

Данные OLAP-приложений обычно представлены в виде одного или нескольких гиперкубов, измерения которого представляют собой справочные данные, а в ячейках самого гиперкуба хранятся собственно данные. Например, можно построить гиперкуб, измерениями которого являются: время (в кварталах, годах), тип товара и отделения компании, а в ячейках хранятся объемы продаж. Такой гиперкуб будет содержать данных о продажах различных типов товаров по кварталам и подразделениям. Основываясь на этих данных, можно отвечать на вопросы вроде "у какого подразделения самые лучшие объемы продаж в текущем году?", или "каковы тенденции продаж отделений Юго-Западного региона в текущем году по сравнению с предыдущим годом?"

Физически гиперкуб может быть построен на основе специальной многомерной модели данных (MOLAP - Multidimensional OLAP ) или построен средствами реляционной модели данных (ROLAP - Relational OLAP ).

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

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

Сильно нормализованные модели данных хорошо подходят для OLTP-приложений – On-Line Transaction Processing (OLTP) – приложений оперативной обработки транзакций. Типичными примерами OLTP-приложений являются системы складского учета͵ заказов билетов, операционные банковские системы и другие. Основная функция подобных систем заключается в выполнении большого количества коротких транзакций. Сами транзакции являются достаточно простыми, но проблемы состоят в том, что таких транзакций очень много, выполняются они одновременно и при возникновении ошибок транзакция должна откатиться и вернуть систему в состояние, в котором та была до начала транзакции. Практически всœе запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления и удаления. Запросы на выборку, в основном, предназначены для предоставления пользователям выборки данных из различного рода справочников. Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, большая часть запросов известна заранее ещё на этапе проектирования системы. Критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP-приложениях, тем оно быстрее и надежней. Отступления от этого правила могут происходить тогда, когда уже на этапе разработки известны некоторые часто возникающие запросы, требующие соединœения отношений и от скорости выполнения которых существенно зависит работа приложений.

Другим типом приложений являются OLAP-приложения – On-Line Analitical Processing (OLAP) – приложения оперативной аналитической обработки данных. Это обобщенный термин, характеризующий принципы построения систем поддержки принятия решений – Decision Support System (DSS), хранилищ данных – Data Warehouse, систем интеллектуального анализа данных – Data Mining. Такие системы предназначены для нахождения зависимостей между данными, для проведения динамического анализа по принципу «что если…» и тому подобных задач. OLAP-приложения оперируют с большими массивами данных, накопленными на предприятии или взятыми из других источников. Такие системы характеризуются следующими признаками:

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

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

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

Запросы к системе являются нерегламентированными и достаточно сложными;

скорость выполнения запросов важна, но не критична.

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

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

- Пути обеспечения надежности системы водоснабжения

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

- I. Концепция безопасности системы защиты

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

- После принятия основных решений по конструкции системы отопления

ПРОЕКТИРОВАНИЕ СИСТЕМЫ ВОДЯНОГО ОТОПЛЕНИЯ ЗДАНИЯ Начертите схемы тепловых узлов при подключении системы отопления по открытой и закрытой схемам. Вопросы для самопроверки При теплоснабжении нескольких зданий. Насосы и другое оборудование устанавливают... [читать подробенее]

- Требования по обеспечению пожарной безопасности системы предотвращения пожара.

Основы обеспечения пожарной безопасности технологических процессов. Вопрос 2.Пожарная профилактика объекта (25мин.) Пожарная профилактика включает в себя комплекс организационных и технических мероприятий, направленных на обеспечение безопасности людей,... [читать подробенее]

- Ткани и системы органов животных

Ткани животных . У животных также выделяют несколько типов тканей. Важнейшими из них являются следующие. Эпителиальныеткани - это пограничные ткани, покрывающие организм снаружи, выстилающие внутренние полости и органы, входящие в состав печени, легких, желез.... [читать подробенее]

В геномах высших эукариот присутствуют многочисленные повторяющиеся последовательности ДНК. У человека, например, такие повторы занимают более 40 % всего генома. И этого следует, что при образовании DSBs вероятность одновременного образования нескольких разрывов по... [читать подробенее]

- Определение групп крови системы АВО цоликлонами анти-А, анти-В и анти-АВ

ОПРЕДЕЛЕНИЕ ГРУПП КРОВИ Согласно этому правилу всем больным можно переливать кровь О(1) группы, так как она не содержит агглютиногенов, а реципиентам АВ(1У) группы можно переливать кровь других групп, так как она не содержит агглютиногенов. Отсюда введены понятия...

 OLTP и OLAP системы В предыдущем подразделе отмечалось, что для адекватного представления предметной области, простоты разработки и поддержания базы данных отношения должны быть приведены к третьей нормальной форме (существуют формы нормализации и более высоких порядков, но на практике они используются достаточно редко), то есть быть сильно нормализованными. Однако слабо нормализованные отношения также имеют свои достоинства, основным из которых является то, что если к базе данных обращаться в основном только с запросами, а модификации и добавление данных проводить очень редко, то их выборка производится значительно быстрее. Это объясняется тем, что в слабо нормализованных отношениях уже как бы произведено их соединение и на это не тратится процессорное время. Выделяют два класса систем, для которых в большей степени подходят сильно и слабо нормализованные отношения. Сильно нормализованные модели данных хорошо подходят для OLTP-приложений - On-Line Transaction Processing (OLTP) - приложений оперативной обработки транзакций. Типичными примерами OLTP-приложений являются системы складского учета, заказов билетов, операционные банковские системы и другие. Основная функция подобных систем заключается в выполнении большого количества коротких транзакций. Сами транзакции являются достаточно простыми, но проблемы состоят в том, что таких транзакций очень много, выполняются они одновременно и при возникновении ошибок транзакция должна откатиться и вернуть систему в состояние, в котором та была до начала транзакции. Практически все запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления и удаления. Запросы на выборку, в основном, предназначены для предоставления пользователям выборки данных из различного рода справочников. Таким образом, большая часть запросов известна заранее ещё на этапе проектирования системы. Критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP-приложениях, тем оно быстрее и надежней. Отступления от этого правила могут происходить тогда, когда уже на этапе разработки известны некоторые часто возникающие запросы, требующие соединения отношений и от скорости выполнения которых существенно зависит работа приложений. Другим типом приложений являются OLAP-приложения - On-Line Analitical Processing (OLAP) - приложения оперативной аналитической обработки данных. Это обобщенный термин, характеризующий принципы построения систем поддержки принятия решений - Decision Support System (DSS), хранилищ данных - Data Warehouse, систем интеллектуального анализа данных - Data Mining. Такие системы предназначены для нахождения зависимостей между данными, для проведения динамического анализа по принципу "что если..." и тому подобных задач. OLAP-приложения оперируют с большими массивами данных, накопленными на предприятии или взятыми из других источников. Такие системы характеризуются следующими признаками: * добавление в систему новых данных происходит относительно редко крупными блоками, например, один раз в месяц или квартал; * данные, добавленные в систему, как правило, никогда не удаляются; * перед загрузкой данные проходят различные подготовительные процедуры, связанные с приведением их к определенным форматам и тому подобное; * запросы к системе являются нерегламентированными и достаточно сложными; * скорость выполнения запросов важна, но не критична. Базы данных OLAP-приложений обычно представлены в виде одного или нескольких гиперкубов, измерения которого представляют собой справочные данные, а в ячейках самого гиперкуба хранятся значения этих данных. Физически гиперкуб может быть построен на основе специальной многомерной модели данных - Multidimensional OLAP (MOLAP) или представлен средствами реляционной модели данных - Relational OLAP (ROLAP). В системах OLAP, использующих реляционную модель данных, данные целесообразно хранить в виде слабо нормализованных отношений, содержащих заранее вычисленные основные итоговые данные. Избыточность данных и связанные с ней проблемы здесь не страшны, так как их обновление происходит достаточно редко и вместе с обновлением данных осуществляется пересчет итогов. Характеристики и круг задач, эффективно решаемых каждой технологией, поясняется следующей сравнительной таблицей: ХарактеристикаOLTPOLAPНазначение системыРегистрация, оперативный поиск и обработка транзакций, регламентированный анализРабота с историческими данными, аналитическая обработка, прогнозирование, моделирование Хранимые данныеОперативные, детализированныеОхватывающие большой период времени, агрегированныеТип данныхСтруктурированныеРазнотипные"Возраст" данныхТекущие (несколько месяцев)Исторические (за годы) и прогнозируемыеЧастота обновления данныхВысокая, небольшими "порциями"Малая, большими "порциями"Уровень агрегации данныхДетализированные данныеВ основном - агрегированные данныеПреобладающие операцииВвод данных, поиск, обновлениеАнализ данныхСпособ использования данныхПредсказуемыйНепредсказуемыйВзаимодействие с пользователем На уровне транзакции На уровне всей базы данных Вид деятельностиОперативная, тактическаяАналитическая, стратегическаяПриоритетыВысокая производительность Высокая доступностьГибкость Автономность пользователяКатегория пользователейБольшое количество работников исполнительного звенаОтносительно малое количество работников руководящего звена Сравнение OLTP и OLAP Характеристика OLTP OLAPХарактер запросовМного простых транзакцийСложные транзакцииХранимые данныеОперативные, детализи-рованныеОхватывающие большой период времени, агреги-рованныеВид деятельностиОперативная, тактическаяАналитическая, страте-гическаяТип данныхСтруктурированныеРазнотипныеСистемная характеристикаУчетная система (OLTP)OLAPВзаимодействие с пользователем На уровне транзакции На уровне всей базы данных Данные, используемые при обращении пользователя к системеОтдельные записиГруппы записейВремя откликаСекундыОт нескольких секунд до нескольких минутИспользование аппаратных ресурсовСтабильноеДинамическоеХарактер данных Главным образом первичные (самый низкий уровень детализации)В основном производные (сводные значения)Характер доступа к базе данныхПредопределенные или статические пути доступа и отношения данных Неопределенные или динамические пути доступа и отношения данных Изменчивость данныхВысокая (данные обновляются с каждой транзакцией)Низкая (во время запроса данные обновляются редко)Приоритеты Высокая производительность Высокая доступностьГибкость Автономность пользователя

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

Сильно нормализованные модели данных хорошо подходят для так называемыхOLTP-приложений (On-Line Transaction Processing (OLTP )-оперативная обработка транзакций ). Типичными примерами OLTP-приложений являются системы складского учета, системы заказов билетов, банковские системы, выполняющие операции по переводу денег, и т.п.

Основная функция подобных систем заключается в выполнении большого количества коротких транзакций. Сами транзакции выглядят относительно просто, например, "снять сумму денег со счета А, добавить эту сумму на счет В".

Проблема заключается в том, что, во-первых, транзакций очень много, во-вторых, выполняются они одновременно (к системе может быть подключено несколько тысяч одновременно работающих пользователей), в-третьих, при возникновении ошибки, транзакция должна целиком откатиться и вернуть систему к состоянию, которое было до начала транзакции (не должно быть ситуации, когда деньги сняты со счета А, но не поступили на счет В). Практически все запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления, удаления. Таким образом, критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP-приложении, тем оно, как правило, быстрее и надежнее.

Другим типом приложений являются так называемыеOLAP-приложения (On-Line Analitical Processing (OLAP ) -оперативная аналитическая обработка данных ). Это обобщенный термин, характеризующий принципы построениясистем поддержки принятия решений (Decision Support System -DSS ),хранилищ данных (Data Warehouse ),систем интеллектуального анализа данных (Data Mining ). Такие системы предназначены для нахождения зависимостей между данными (например, можно попытаться определить, как связан объем продаж товаров с характеристиками потенциальных покупателей), для проведения анализа "что если…".

OLAP-приложения оперируют с большими массивами данных, уже накопленными в OLTP-приложениях, взятыми их электронных таблиц или из других источников данных. Такие системы характеризуются следующими признаками:

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

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

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

Запросы к системе являются нерегламентированными и, как правило, достаточно сложными.

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

Данные OLAP-приложений обычно представлены в виде одного или нескольких гиперкубов, измерения которого представляют собой справочные данные, а в ячейках самого гиперкуба хранятся собственно данные. Например, можно построить гиперкуб, измерениями которого являются: время (в кварталах, годах), тип товара и отделения компании, а в ячейках хранятся объемы продаж. Такой гиперкуб будет содержать данных о продажах различных типов товаров по кварталам и подразделениям. Основываясь на этих данных, можно отвечать на вопросы вроде "у какого подразделения самые лучшие объемы продаж в текущем году?", или "каковы тенденции продаж отделений Юго-Западного региона в текущем году по сравнению с предыдущим годом?"

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

• < Назад
• Вперёд >