Лекция №11 olap, oltp краткое описание: Транзакции. Oltp. Многомерная модель данных. Olap



Скачать 200.27 Kb.
Дата15.04.2013
Размер200.27 Kb.
ТипЛекция
Лекция №11 - OLAP, OLTP

Краткое описание: Транзакции. OLTP. Многомерная модель данных. OLAP

Содержание


  • 1 Транзакции

    • 1.1 Свойства транзакций

    • 1.2 Реализация защиты от сбоев

  • 2 OLTP(OnLine Transaction Processing)

    • 2.1 Использование

    • 2.2 Требования

    • 2.3 Преимущества и недостатки

  • 3 OLAP(OnLine Analytical Processing)

    • 3.1 Действие OLAP

    • 3.2 Правила для систем OLAP

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

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

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

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

Вопросы

Транзакции

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

Транзакция является логической единицей работы, выполняемой в базе данных. Она может быть представлена отдельной программой, частью программы или даже отдельной командой (например, командой INSERT или UPDATE языка SQL) и включать произвольное количество операций, выполняемых в базе данных. С точки зрения администратора базы данных эксплуатация любого приложения может расцениваться как ряд транзакций, в промежутках между которыми выполняется обработка данных, осуществляемая вне среды базы данных. Для иллюстрации понятия транзакции рассмотрим два отношения:

Staff (staffNo, fName, IName, position, sex, DOB, salary, branchNo)

PropertyForRent (propertyNo, street, city, postcode, type, rooms, rent, ownerNo, staffNo, branchNo)

Простейшей транзакцией, выполняемой в подобной базе данных, может быть корректировка зарплаты определенного работника, указанного его табельным номером х. Обобщенно подобная транзакция может быть записана, как показано в таблице (вариант А). В этой главе мы будем обозначать операции чтения или записи элемента данных х с помощью выражений read(x) и write(х). При необходимости к имени элемента данных могут добавляться дополнительные уточнители. Например, в столбце Вариант А используется обозначение read (staffNo = х, salary), указывающее, что требуется считать элемент данных salary для записи, в которой ключевое значение равно х.
В данном примере транзакция состоит из двух операций, выполняемых в базе данных (read и write), и одной операции, выполняемой вне базы данных (salary = salary*1. 1).

Вариант А

Вариант Б

read(staffNo = x, salary)

salary = salary * 1.1

write (staffNo = x, new_salary)

delete(staffNo = х)

for all PropertyForRent records, pno

begin

read(propertyNo = pno, staffNo)

if (staffNo = x) then

begin

staffNo = newStaffNo

write(propertyNo = pno, staffNo)

end

end

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

Любая транзакция всегда должна переводить базу данных из одного согласованного состояния в другое, хотя допускается, что согласованность состояния базы может нарушаться в ходе выполнения транзакции. Например, в процессе выполнения транзакции, представленной в столбце Вариант Б таблицы, возникает ситуация, когда одна из строк отношения PropertyForRent содержит новое значение атрибута staffNo — newStaffNo, тогда как остальные строки все еще содержат прежнее значение х. Однако после завершения выполнения транзакции во все требуемые строки должно быть помещено новое значение — newStaffNo.

Любая транзакция завершается одним из двух возможных способов. В случае успешного завершения результаты транзакции фиксируются (commit) в базе данных, и последняя переходит в новое согласованное состояние. Если выполнение транзакции не увенчалось успехом, она отменяется. В этом случае в базе данных должно быть восстановлено то согласованное состояние, в котором она находилась до начала данной транзакции. Этот процесс называется откатом (roll back), или отменой транзакции. Зафиксированная транзакция не может быть отменена. Если окажется, что зафиксированная транзакция была ошибочной, потребуется выполнить другую транзакцию, отменяющую действия, выполненные первой транзакцией. Такая транзакция называется компенсирующей. Но аварийно завершившаяся транзакция, для которой выполнен откат, может быть вызвана на выполнение позже и, в зависимости от причин предыдущего отказа, вполне успешно завершена и зафиксирована в базе данных.

Ни в одной СУБД не может быть предусмотрен априорный способ определения того, какие именно операции обновления могут быть сгруппированы для формирования единой логической транзакции. Поэтому должен применяться метод, позволяющий указывать границы каждой из транзакций извне, со стороны пользователя. В большинстве языков манипулирования данными для указания границ отдельных транзакций используются операторы BEGIN TRANSACTION, COMMIT и ROLLBACK (или их эквиваленты). Если эти ограничители не были использованы, как единая транзакция обычно рассматривается вся выполняемая программа. СУБД автоматически выполнит команду COMMIT при нормальном завершении этой программы. Аналогично, в случае аварийного завершения программы в базе данных автоматически будет выполнена команда ROLLBACK.

Порядок выполнения операций транзакции принято обозначать с помощью диаграммы переходов. Пример такой диаграммы приведен на рисунке. Следует отметить, что на этой диаграмме, кроме очевидных состояний ACTIVE, COMMITTED и ABORTED, имеются еще два состояния, описанные ниже.

  • PARTIALLY COMMITTED.

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

  • FAILED.

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

Свойства транзакций

Существуют определенные свойства, которыми должна обладать любая из транзакций. Ниже представлены четыре основных свойства транзакций, которые принято обозначать аббревиатурой ACID (Atomicity, Consistency, Isolation, Durability — неразрывность, согласованность, изолированность, устойчивость), состоящей из первых букв названий этих свойств.

  • Неразрывность.

Это свойство, для описания которого применимо выражение "все или ничего". Любая транзакция представляет собой неделимую единицу работы, которая может быть либо выполнена вся целиком, либо не выполнена вообще. За обеспечение неразрывности отвечает подсистема восстановления СУБД.

  • Согласованность.

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





Диаграмма перехода для некоторой транзакции

  • Изолированность.

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

  • Устойчивость.

Результаты успешно завершенной (зафиксированной) транзакции должны храниться Б базе данных постоянно и не должны быть утеряны в результате последующих сбоев. За обеспечение устойчивости отвечает подсистема восстановления.

Реализация защиты от сбоев

  • Упреждающая журнализация

СУБД ведёт журнал транзакций, где указывается вся информация о транзакции.

  • Теневые страницы

  • Сегмент отката

  • MVCC

Система, при которой, при изменении данных, предыдущие данные сохраняются.

OLTP(OnLine Transaction Processing)

OLTP (OnLine Transaction Processing)онлайновая обработка транзакций. Способ организации БД, при котором система работает с транзакциями небольшими по размерам, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа.

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

Использование

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

Требования

  • Сильно нормализованные модели данных.

  • При возникновении ошибки, транзакция должна целиком откатиться и вернуть систему к состоянию, которое было до начала транзакции.

  • Обработка данных в реальном времени.

Преимущества и недостатки

OLTP-системы оптимизированы для небольших дискретных транзакций. А вот запросы на некую комплексную информацию (к примеру поквартальная динамика объемов продаж по определённой модели товара в определённом филиале), характерные для аналитических приложений (OLAP), породят сложные соединения таблиц и просмотр таблиц целиком. На один такой запрос уйдет масса времени и компьютерных ресурсов, что затормозит обработку текущих транзакций.

OLAP(OnLine Analytical Processing)

OLAP (англ. OnLine Analytical Processing, аналитическая обработка в реальном времени) — технология обработки информации, включающая составление и динамическую публикацию отчётов и документов. Используется аналитиками для быстрой обработки сложных запросов к базе данных. Служит для подготовки бизнес-отчетов по продажам, маркетингу, в целях управления, т.н. data mining — добыча данных (способ анализа информации в базе данных с целью отыскания аномалий и трендов без выяснения смыслового значения записей).

Действие OLAP

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

OLAP делает мгновенный снимок реляционной БД и структурирует её в пространственную модель для запросов. Заявленное время обработки запросов в OLAP составляет около 0.1 % от аналогичны х запросов в реляционную БД.

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

Например, все клиенты могут быть сгруппированы по городам или по регионам страны (Запад, Восток, Север и т. д.), таким образом, 50 городов, 8 регионов и 2 страны составят 3 уровня иерархии с 60 членами. Также клиенты могут быть объединены по отношению к продукции; если существуют 250 продуктов по 2 категориям, три группы продукции и 3 производственных подразделения, то количество агрегатов составит 16560. При добавлении измерений в схему, количество возможных вариантов быстро достигает десятков миллионов и более.

OLAP-куб содержит в себе базовые данные и информацию об измерениях (агрегатах). Куб потенциально содержит всю информацию, которая может потребоваться для ответов на любые запросы. Из-за громадного количества агрегатов, зачастую полный расчёт происходит только для некоторых измерений, для остальных же производится «по требованию».

Вместе с базовой концепцией существуют три типаOLAP — OLAP со многими измерениями (Multidimensional OLAP — MOLAP), реляционный OLAP (Relational OLAP — ROLAP) и гибридный OLAP (Hybrid OLAP — HOLAP). MOLAP — это классическая форма OLAP, так что её часто называют просто OLAP. Она использует суммирующую БД, специальный вариант процессора пространственных БД и создаёт требуемую пространственную схему данных с сохранением как базовых данных, так и агрегатов. ROLAP работает напрямую с реляционным хранилищем, факты и таблицы с измерениями хранятся в реляционных таблицах, и для хранения агрегатов создаются дополнительные реляционные таблицы. HOLAP использует реляционные таблицы для хранения базовых данных и многомерные таблицы для агрегатов. Особым случаем ROLAP является ROLAP реального времени (Real-time ROLAP — R-ROLAP). В отличие от ROLAP в R-ROLAP для хранения агрегатов не создаются дополнительные реляционные таблицы, а агрегаты рассчитываются в момент запроса. При этом многомерный запрос к OLAP-системе автоматически преобразуется в SQL-запрос к реляционным данным.

Каждый тип хранения имеет определённые преимущества, хотя есть разногласия в их оценке у разных производителей. MOLAP лучше всего подходит для небольших наборов данных, он быстро рассчитывает агрегаты и возвращает ответы, но при этом генерируются огромные объёмы данных. ROLAP оценивается как более масштабируемое решение, использующее к тому же наименьшее возможное пространство. При этом скорость обработки значительно снижается. HOLAP находится посреди этих двух подходов, он достаточно хорошо масштабируется и быстро обрабатывается. Архитектура R-ROLAP позволяет производить многомерный анализ OLTP-данных в режиме реального времени.

Сложность в применении OLAP состоит в создании запросов, выборе базовых данных и разработке схемы, в результате чего большинство современных продуктов OLAP поставляются вместе с огромным количеством предварительно настроенных запросов. Другая проблема — в базовых данных. Они должны быть полными и непротиворечивыми.

Правила для систем OLAP

В 1993 году Э.Ф. Кодд сформулировал двенадцать основных правил, которые должны служить основой для выбора наиболее подходящих инструментов OLAP. Публикация этих правил была результатом исследования, проведенного в интересах компании Arbor Software (создателей пакета Essbase), и привела к появлению формального определения требований, предъявляемых к инструментам OLAP. Вот эти правила:

  1. Многомерная концепция данных.

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

  1. Прозрачность.

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

  1. Доступность.

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

  1. Постоянная скорость выполнения запросов.

Производительность не должна падать при росте числа измерений.

  1. Клиент/сервер архитектура.

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

  1. Различное число измерений.

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

  1. Динамическое представление разреженных матриц.

Под разреженной матрицей понимается такая матрица, не каждая ячейка которой содержит данные. OLAP-системы должны содержать средства хранении и обработки разреженных матриц больших объемов.

  1. Многопользовательская поддержка.

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

  1. Неограниченные многомерные операции.

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

  1. Интуитивно понятные инструменты манипулирования данными.

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

  1. Гибкая настройка конечных отчетов.

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

  1. Отсутствие ограничений.

Не должны иметься какие-либо ограничения на количество измерений и уровней агрегации данных.

Сравнение OLTP- и OLAP-технологий

Технологии

Назначение

Типы запросов

Типы вопросов

Время отклика

Типичные операции

OLTP (оперативность)

Обработка текущих хозяйственных операций, хранение оперативных данных

Предсказуемые (регламентированные)

Сколько? Как? Когда?

Не регламентируется

Регламентированный отчет, диаграмма

OLAP(аналитика)

Многомерный анализ, моделирование

Произвольные

Почему? Что будет, если?

Секунды

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

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

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

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

Достаточно очевидно, что даже при небольших объемах данных отчет, представленный в виде двухмерной таблицы (Модели автомобиля по оси Y и Время по оси X), нагляднее и информативнее отчета с реляционной построчной формой организации (Таблица):

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

Модель

Месяц

Объем

"Жигули"

Июнь

12

"Жигули"

Июль

24

"Жигули"

Август

5

"Москвич"

Июнь

2

"Москвич"

Июль

18

"Волга"

Июль

19

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

 

Июнь

Июль

Август

"Жигули"

12

24

5

"Москвич"

2

18

No

"Волга"

No

19

No

А теперь представим, что у нас не три модели, а 30 и не три, а 12 различных месяцев. В случае построчного (реляционного) представления мы получим отчет в 360 строк (30х12), который займет не менее 5-6 страниц. В случае же многомерного (в нашем случае двухмерного) представления мы получим достаточно компактную таблицу 12 на 30, которая вполне уместится на одной странице и которую, даже при таком объеме данных, можно реально оценивать и анализировать.

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

Закономерен вопрос: "Где же здесь многомерность, откуда она берется и куда исчезает?" Ответ прост. Когда говорится о многомерности, имеется в виду не многомерность визуализации, а многомерное представление при описании структур данных и поддержка многомерности в языках манипулирования данными.

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

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

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

  • ячейка (Cell).

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

Измерение - это множество однотипных данных, образующих одну из граней гиперкуба. Например - Дни, Месяцы, Кварталы, Годы - это наиболее часто используемые в анализе временные Измерения. Примерами географических измерений являются: Города, Районы, Регионы, Страны и т.д.

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

В свою очередь, Показатель - это поле (обычно цифровое), значения которого однозначно определяются фиксированным набором Измерений. В Oracle Express Server, в зависимости от того, как формируются его значения, Показатель может быть определен, как:

  • Переменная (Variable) - значения таких Показателей один раз вводятся из какого-либо внешнего источника или формируются программно и затем в явном виде хранятся в многомерной базе данных (МБД);

  • Формула (Formula) - значения таких Показателей вычисляются по некоторой заранее специфицированной формуле. То есть для Показателя, имеющего тип Формула, в БД хранится не его значения, а формула, по которой эти значения могут быть вычислены.

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

В предыдущем примере каждое значение поля Объем продаж однозначно определяется комбинацией полей:

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

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

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

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

  • Менеджер;

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

Измерения:

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

 

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

Показатель:

Объем Продаж





Измерения и Показатели (Ячейки)


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

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

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

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

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







Неопределенные значения показателей

Заметим, что, в отличие от Измерений, не все значения Показателей (рисунок) должны иметь и имеют реальные значения. Например, Менеджер Петров в 1994 г. мог еще не работать в фирме, и в этом случае все значения Показателя Объем продаж за этот год будут иметь неопределенные значения.
Гиперкубические и поликубические модели данных

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

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

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

В чем состоит разница? Системы, поддерживающие Поликубическую модель (примером является Oracle Express Server), предполагают, что в МБД может быть определено несколько гиперкубов с различной размерностью и с различными Измерениями в качестве их граней. Например, значение Показателя Рабочее Время Менеджера, скорее всего, не зависит от Измерения Модель Автомобиля и однозначно определяется двумя Измерениями: День и Менеджер. В Поликубической модели в этом случае может быть объявлено два различных гиперкуба:

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

 

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

В случае же Гиперкубической модели предполагается, что все Показатели должны определяться одним и тем же набором Измерений. То есть только из-за того, что Объем Продаж определяется тремя Измерениями, при описании Показателя Рабочее Время Менеджера придется также использовать три Измерения и вводить избыточное для этого Показателя Измерение Модель Автомобиля.

Вопросы

    • Дайте определение транзакции.

    • Перечислите основные требования к транзакциям.

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

    • Что включает в себя реализация защиты от сбоев?

    • Дайте сравнительный анализ OLTP- и OLAP-технологий.


Похожие:

Лекция №11 olap, oltp краткое описание: Транзакции. Oltp. Многомерная модель данных. Olap iconOlap-технологии для анализа бизнес-процессов компании
В работе приводится описание решений olap-технологии, пример использования и полученные результаты применения olap-кубов
Лекция №11 olap, oltp краткое описание: Транзакции. Oltp. Многомерная модель данных. Olap iconУстановка программного продукта olap и работа с демонстрационной бд
Парус-olap в качестве альтернативы Вы можете запустить на выполнение файл Setup exe из каталога Setups/olap 7 компакт-диска
Лекция №11 olap, oltp краткое описание: Транзакции. Oltp. Многомерная модель данных. Olap iconСеминар №7 Технология olap и многомерные модели данных
Технология olap ориентирована, главным образом, на обработку нерегламентированных запросов к хранилищам данных
Лекция №11 olap, oltp краткое описание: Транзакции. Oltp. Многомерная модель данных. Olap iconВведение в olap: часть Основы olap
В качестве примеров реализации мы будем использовать в основном olap-технологии фирмы Microsoft (главным образом Analysis Services...
Лекция №11 olap, oltp краткое описание: Транзакции. Oltp. Многомерная модель данных. Olap iconOlap технологии
В отличие от традиционных реляци­онных субд, концепция olap 1не так широко известна, хотя загадочный термин "кубы olap" слышали,...
Лекция №11 olap, oltp краткое описание: Транзакции. Oltp. Многомерная модель данных. Olap iconУниверсальных, полезных бесплатных комплексных информационных систем автоматизации для предприятий малого бизнеса «кис lack»
...
Лекция №11 olap, oltp краткое описание: Транзакции. Oltp. Многомерная модель данных. Olap iconИспользование olap-технологии в crm-программном комплексе
Цель данной статьи описать возможности использования olap отчетов в работе управленцев и аналитиков компании. Статья построена на...
Лекция №11 olap, oltp краткое описание: Транзакции. Oltp. Многомерная модель данных. Olap iconЛекция №07 Модели данных
Описание: Иерархическая модель данных. Режимы исключения. Сетевая модель данных. Объектно-ориентированная модель данных. Объектно-реляционная...
Лекция №11 olap, oltp краткое описание: Транзакции. Oltp. Многомерная модель данных. Olap iconЛекция №04 Жизненные циклы бд краткое описание
Краткое описание: Жизненные циклы информационных систем. Цели и задачи проектирования. Проектирование баз данных (о трех этапах)....
Лекция №11 olap, oltp краткое описание: Транзакции. Oltp. Многомерная модель данных. Olap icon1Общие сведения о olap- технологии
Пользователь получает естественную, интуитивно понятную модель данных, организуя их в виде многомерных кубов (Cubes)
Разместите кнопку на своём сайте:
ru.convdocs.org


База данных защищена авторским правом ©ru.convdocs.org 2016
обратиться к администрации
ru.convdocs.org