Основные элементы и операции OLAP
В основе OLAP лежит понятие гиперкуба, или многомерного куба данных, в ячейках которого хранятся анализируемые данные.
Факт - это числовая величина которая располагается в ячейках гиперкуба. Один OLAP-куб может обладать одним или несколькими показателями.
Измерение (dimension) - это множество объектов одного или нескольких типов, организованных в виде иерархической структуры и обеспечивающих информационный контекст числового показателя. Измерение принято визуализировать в виде ребра многомерного куба.
Объекты, совокупность которых и образует измерение, называются членами измерений (members). Члены измерений визуализируют как точки или участи, откладываемые на осях гиперкуба.
Ячейка (cell) - атомарная структура куба, соответствующая полному набору конкретный значений измерений.
Иерархия - группировка объектов одного измерения в объекты более высокого уровня. Например - день-месяц-год. Иерархии в измерениях необходимы для возможности агрегации и детализации значений показателей согласно их иерархической структуре. Иерархия целиком основывается на одном измерении и формируется из уровней.
В OLAP-системах поддерживаются следующие базовые операции:
поворот;
-
проекция. При проекции значения в ячейках, лежащих на оси проекции, суммируются по некоторому предопределенному закону;
-
раскрытие ( drill-down ). Одно из значений измерения заменяется совокупностью значений из следующего уровняиерархии измерения; соответственно заменяются значения в ячейках гиперкуба;
-
свертка ( roll-up/drill-up ). Операция, обратная раскрытию;
-
сечение ( slice-and-dice ).
Типы OLAP. Преимущества и недостатки
Выбор способа хранения данных зависит от объема и структуры детальных данных, требований к скорости выполнения запросов и частоты обновления OLAP-кубов. В настоящее время применяются три способа хранения данных:
MOLAP (Multidimensional OLAP)
Детальные и агрегированные данные хранятся в многомерной базе данных. Хранение данных в многомерных структурах позволяет манипулировать данными как многомерным массивом, благодаря чему скорость вычисления агрегатных значений одинакова для любого из измерений. Однако в этом случае многомерная база данных оказывается избыточной, так как многомерные данные полностью содержат детальные реляционные данные.
Преимущества MOLAP.
-
Высокая производительность. Поиск и выборка данных осуществляется значительно быстрее, чем при многомерном концептуальном взгляде на реляционную базу данных.
Структура и интерфейсы наилучшим образом соответствуют структуре аналитических запросов.
-
Многомерные СУБД легко справляются с задачами включения в информационную модель разнообразных встроенных функций.
Недостатки MOLAP.
-
MOLAP могут работать только со своими собственными многомерными БД и основываются на патентованных технологиях для многомерных СУБД, поэтому являются наиболее дорогими. Эти системы обеспечивают полный цикл OLAP-обработки и либо включают в себя, помимо серверного компонента, собственный интегрированный клиентский интерфейс, либо используют для связи с пользователем внешние программы работы с электронными таблицами.
-
По сравнению с реляционными, очень неэффективно используют внешнюю память, обладают худшими по сравнению с реляционными БД механизмами транзакций.
Отсутствуют единые стандарты на интерфейс, языки описания и манипулирования данными.
-
Не поддерживают репликацию данных, часто используемую в качестве механизма загрузки.
ROLAP (Relational OLAP)
ROLAP-системы позволяют представлять данные, хранимые в классической реляционной базе, в многомерной форме или в плоских локальных таблицах на файл-сервере, обеспечивая преобразование информации в многомерную модель через промежуточный слой метаданных. Агрегаты хранятся в той же БД в специально созданных служебных таблицах. В этом случае гиперкуб эмулируется СУБД на логическом уровне.
Преимущества ROLAP.
-
Реляционные СУБД имеют реальный опыт работы с очень большими БД и развитые средства администрирования. При использовании ROLAP размер хранилища не является таким критичным параметром, как в случае MOLAP.
-
При оперативной аналитической обработке содержимого хранилища данных инструменты ROLAP позволяют производитьанализ непосредственно над хранилищем (потому что в подавляющем большинстве случаев корпоративные хранилища данныхреализуются средствами реляционных СУБД).
-
В случае переменной размерности задачи, когда изменения в структуру измерений приходится вносить достаточно часто,ROLAP системы с динамическим представлением размерности являются оптимальным решением, так как в них такие модификации не требуют физической реорганизации БД, как в случае MOLAP.
-
Системы ROLAP могут функционировать на гораздо менее мощных клиентских станциях, чем системы MOLAP, поскольку основная вычислительная нагрузка в них ложится на сервер, где выполняются сложные аналитические SQL-запросы, формируемые системой.
-
Реляционные СУБД обеспечивают значительно более высокий уровень защиты данных и хорошие возможности разграничения прав доступа.
Недостатки ROLAP.
Ограниченные возможности с точки зрения расчета значений функционального типа.
-
Меньшая производительность, чем у MOLAP. Для обеспечения сравнимой с MOLAP производительности реляционные системы требуют тщательной проработки схемы БД и специальной настройки индексов. Но в результате этих операцийпроизводительность хорошо настроенных реляционных систем при использовании схемы "звезда" сравнима с производительностью систем на основе многомерных БД.
HOLAP (Hybrid OLAP)
Детальные данные остаются в той же реляционной базе данных, где они изначально находились, а агрегатные данные хранятся в многомерной базе данных.
Моделирование многомерных кубов на реляционной модели данных
Схема звезда. Преимущества и недостатки
Схема типа звезды (Star Schema) - схема реляционной базы данных, служащая для поддержки многомерного представления содержащихся в ней данных.
Особенности ROLAP-схемы типа "звезда" (рис.15).
Рисунок 15 - Схема типа «звезда». Преимущества и недостатки
-
Одна таблица фактов (fact table), которая сильно денормализована. Является центральной в схеме, может состоять из миллионов строк и содержит суммируемые или фактические данные, с помощью которых можно ответить на различные вопросы.
-
Несколько денормализованных таблиц измерений (dimensional table). Имеют меньшее количество строк, чем таблицы фактов, и содержат описательную информацию. Эти таблицы позволяют пользователю быстро переходить от таблицы фактов к дополнительной информации.
-
Таблица фактов и таблицы размерности связаны идентифицирующими связями, при этом первичные ключи таблицыразмерности мигрируют в таблицу фактов в качестве внешних ключей. Первичный ключ таблицы факта целиком состоит изпервичных ключей всех таблиц размерности.
-
Агрегированные данные хранятся совместно с исходными.
Преимущества.
Благодаря денормализации таблиц измерений упрощается восприятие структуры данных пользователем и формулировка запросов, уменьшается количество операций соединения таблиц при обработке запросов. Некоторые промышленные СУБД и инструментыкласса OLAP / Reporting умеют использовать преимущества схемы "звезда" для сокращения времени выполнения запросов.
Недостатки.
Денормализация таблиц измерений вносит избыточность данных, возрастает требуемый для их хранения объем памяти. Если агрегаты хранятся совместно с исходными данными, то в измерениях необходимо использовать дополнительный параметр - уровень иерархии.
Схема типа снежинки (Snowflake Schema) - схема реляционной базы данных, служащая для поддержки многомерного представления содержащихся в ней данных, является разновидностью схемы типа "звезда" (Star Schema).
Особенности ROLAP-схемы типа "снежинка" (рис.16)
Рисунок 16- Схема типа «снежинка»
-
Одна таблица фактов (fact table), которая сильно денормализована. Является центральной в схеме, может состоять из миллионов строк и содержать суммируемые или фактические данные, с помощью которых можно ответить на различные вопросы.
-
Несколько таблиц измерений (dimensional table), которые нормализованы в отличие от схемы "звезда". Имеют меньшее количество строк, чем таблицы фактов, и содержат описательную информацию. Эти таблицы позволяют пользователю быстро переходить от таблицы фактов к дополнительной информации. Первичные ключи в них состоят из единственного атрибута (соответствуют единственному элементу измерения).
-
Таблица фактов и таблицы размерности связаны идентифицирующими связями, при этом первичные ключи таблицыразмерности мигрируют в таблицу фактов в качестве внешних ключей. Первичный ключ таблицы факта целиком состоит изпервичных ключей всех таблиц размерности.
-
В схеме "снежинка" агрегированные данные могут храниться отдельно от исходных.
Преимущества.
Нормализация таблиц измерений в отличие от схемы "звезда" позволяет минимизировать избыточность данных и более эффективно выполнять запросы, связанные со структурой значений измерений.
Недостатки.
За нормализацию таблиц измерений иногда приходится платить временем выполнения запросов.
Тема 2. Информационные массивы, информационные хранилища и склады данных (2 часа)
Проблема создания и сжатия больших информационных массивов, информационных хранилищ и складов данных.
Концепция систем складирования данных
Информационная технология складирования данных (data warehousing) родилась в недрах компании IBM и была окончательно сформулирована Б. Инмоном и Р. Кимбаллом в 90-х годах прошлого столетия как метод решения информационно-аналитических задач в области принятия и поддержки решений. Возникнув на стыке технологии баз данных (БД), систем поддержки принятия решений (СППР - DSS) и компьютерного анализа данных, в дальнейшем концепция складирования данных претерпела эволюцию, поскольку оказалась пригодной для широкого круга приложений в бизнесе, науке и технологии.
Основным посылом разработки концепции складирования данных явилось осознание руководством организаций потребности в анализе накопленных электронных массивов данных. На рис. 17 показана упрощенная принципиальная схема функционирования организации и место анализа непрерывно поступающей информации.
Рисунок 17 -. Упрощенная принципиальная схема функционирования организации
Во всем мире организации накапливают или уже накопили в процессе своей административно-хозяйственной деятельности большие объемы данных, в том числе и в электронном виде. Эти коллекции данных хранят в себе большие потенциальные возможности по извлечению новой аналитической информации, на основе которой можно и необходимо строить стратегию организации, выявлять тенденции развития рынка, находить новые решения, обусловливающие успешное развитие в условиях конкурентной борьбы. Для некоторых организаций такой анализ является неотъемлемой частью их повседневной деятельности, другие начинают активно приступать к такому анализу.
Системы, построенные на основе информационной технологии складирования данных, обладают рядом характерных особенностей, которые выделяют их как новый класс информационных систем (ИС). К таким особенностям относятся предметная ориентация системы, интегрированность хранимых в ней данных, собираемых из различных источников, инвариантность этих данных во времени, относительно высокая стабильность данных, необходимость поиска компромисса в избыточности данных.
Рисунок 18 - Особенности систем складирования данных
Хранилище данных (ХД — data warehouse) является местом складирования собираемых в системе данных и информационным источником для решения задач анализа данных и принятия решений. Как правило, объем информации в ХД является достаточно большим. Упрощенно можно сказать, что хранилище данных управляет данными, которые были собраны как из операционных систем организации (OLTP-систем - On-Line Trasactions Processing), так и из внешних источников данных, и которые длительный период времени хранятся в системе. Более точное определение будет дано позже, после обсуждения истории создания концепции складирования данных.
Одной из главных целей создания систем складирования данных является их ориентация на анализ накопленных данных, т.е. структуризация данных в ХД должна быть выполнена таким образом, чтобы данные эффективно использовались в аналитических приложениях ( analytical applications ).
Заметим, что задачи анализа накопленных данных решали и до создания концепции складирования данных. В распоряжении аналитиков и сейчас имеется большой набор пакетов программ. Главным отличием использования концепции складирования данных является структуризация, систематизация, классификация, фильтрация и т. п. больших массивов электронной информации в виде, удобном для анализа, визуализации результатов анализа и производства корпоративной отчетности.
Фундаментальные требования к разработке операционных систем обработки данных и систем анализа данных различны: операционным системам нужна производительность, в тот время как системам анализа данных нужны гибкость и широкие возможности для получения результата.
Еще одной причиной стало интенсивное использование систем поддержки и принятия решений (СППР - DSS) и управленческих информационных систем (ИСР - EIS, информационная система руководителя). СППР обычно фокусируются на более детальном представлении информации и ориентированы больше на менеджеров среднего уровня. ИСР обеспечивают более высокий уровень консолидации и многоаспектного (многомерного представления) взгляда на данные, поскольку руководители высокого уровня нуждаются в большем многообразии представления тех же самых данных для детального анализа.
В настоящее время системы складирования данных обеспечивают аналитические инструменты для решения таких задач, но их разработка строится не на специфических требованиях аналитиков или исполнителей, а основывается на структуре бизнеса организации. С этой точки зрения системы складирования данных дали новый виток в развитии СППР и ИСР.
Не следует забывать также о факторах, связанных с техническим прогрессом в области разработки аппаратного обеспечения ЭВМ и развитием компьютерных технологий в разработке программного обеспечения. Это обстоятельство привело к снижению цен на комплектующие с одновременным ростом их мощности, созданию дружественных интерфейсов для пользователей.
Наиболее важным фактором в развитии складирования данных стало увеличение мощности аппаратной платформы компьютеров. Параллельно росла вычислительная мощность ПК и развитое программное обеспечение, которые позволили разработать и внедрить архитектуру клиент/сервер. Создание серверных операционных систем, таких как Windows и Unix, повысило надежность в функционировании и дало мощные возможности распределенной вычислительной среде. Эти технологические факторы способствовали быстрому развитию систем складирования данных.
Создание и распространение Интернет/Интранет привело к тому, что бизнес стал перемещаться в Интернет. Сегодня одной из наиболее значительных областей компьютерной индустрии является разработка интранет-приложений.
Изменение экономических условий побудили большие корпорации к объединению (консолидации) своих усилий. Появление таких механизмов, как реинжениринг бизнес-процессов (business process reengineering) и перестраиваемость бизнеса (downsizing), вынудило руководителей переоценить практику ведения бизнеса. Пересмотр процедур ведения бизнеса и изменения в финансовых потоках сыграли важную роль в развитии концепции складирования данных.
На рис.19 просуммированные основные факторы, способствующие созданию и развитию концепции систем складирования данных и хранилищ данных.
Рисунок 19 - Основные факторы, повлиявшие на разработки концепции хранилищ данных
Рассмотрим основные элементы концепции складирования данных.
Извлечение данных из операционных систем
Главный элемент концепции складирования данных состоит в том, что к данным, сохраняемым для анализа, может быть обеспечен наиболее эффективный доступ только при условии выделения их из операционной (транзакционной) системы, т.е. данные из операционной системы должны быть вынесены в отдельную систему складирования данных.
Нужно отметить, что с развитием концепции позиция отделения данных для анализа от данных в OLTP-системе претерпела мало изменений. Она стала более формальной и обогатилась за счет применения средств многомерного анализа данных.
Необходимость интегрирования данных из нескольких OLTP-систем.
Системы складирования данных наиболее полезны, когда данные могут быть извлечены более чем из одной OLTP-системы. Когда данные должны быть собраны от нескольких бизнес-приложений, естественно предположить, что это нужно сделать в месте, отличном от места локализации исходных приложений.
Целью многих систем складирования данных является обзор деятельности типа "год за годом". Например, аналитик может попытаться оценить влияние новой компании маркетинга, проходящей в течение определенных периодов, рассматривая продажи в течение тех же самых периодов. Способность устанавливать и понимать корреляцию между деятельностью различных подразделений в организации часто приводится как один из самых главных аргументов о пользе систем складирования данных.
Система складирования данных не только может работать как эффективная платформа для консолидации данных из различных источников, но может также собирать многократные версии данных из одного приложения.
Можно выделить следующие причины для разделения данных систем складирования данных и систем операционной обработки данных (рис.20http://www.intuit.ru/studies/courses/599/455/lecture/5750?page=2 - image.1.5).
Различие целевых требований к системам складирования данных и OLTP-системам.
Необходимость собирать данные в ХД из различных информационных источников, т.е. если данные генерируются в самой OLTP-системе, то для системы складирования данных в большинстве случаев данные генерируются вне ее.
Данные, попадая в ХД, остаются в большинстве случаев неизменными.
Данные в ХД сохраняются длительное время.
Рисунок 20 - Основные причины разделения данных для анализа и оперативной обработки
Логическое преобразование данных OLTP-систем и моделирование данных
Основные типы программно-аппаратной архитектуры хранилища данных
На рис.21 приведена типовая обобщенная концептуальная схема для архитектуры ХД. В конкретных решениях по архитектуре ХД некоторые компоненты схемы могут отсутствовать.
Рисунок 21 - Типовая обобщенная концептуальная схема для архитектуры ХД
Компоненты типовой архитектуры хранилища данных
Программное обеспечение промежуточного слоя. Основное назначение этих компонент состоит в обеспечении доступа к сети и доступа к данным. Сюда можно отнести сетевые и коммуникационные протоколы, драйверы, системы обмена сообщениями и т.д. Поддержка такого программного обеспечения обычно выполняется информационными службами организации.
Базы данных систем оперативной обработки данных (OLTP) и данные внешних источников. Для OLTP-систем характерна целевая направленность на эффективную обработку структур данных в рамках относительно небольшого числа четко определенных типовых транзакций. Количество таких транзакций может быть очень большим, число их типов незначительно. Направленность на быстрое выполнение транзакций делает такие системы малопригодными для решения аналитических задач. Транзакции для построения аналитических выборок по своей природе отличаются от транзакций OLTP-систем. В OLTP-системах выполнение таких выборок может приводить к снижению производительности.
Предварительная обработка и загрузка данных. Предварительная обработка, связанная с фильтрацией, очисткой и преобразованием данных из OLTP-систем и внешних источников, обычно выполняется в некотором промежуточном файле, который называется иногда загрузочной секцией. После обработки данные загружаются в ХД. Эта компонента включает в себя набор программных средств для выполнения указанных выше функций.
Хранилище данных. Представляет собой ядро системы складирования данных. Это могут быть один или несколько серверов БД для поддержки ХД.
Метаданные. Метаданные представляют собой репозиторий, который играет роль справочника о данных. Он включает терминологию предметной области, сведения об источниках данных, описание источников исходных данных, сведения об алгоритмах обработки исходных данных и т.д.
Уровень доступа к данным. Этот компонент включает в себя программное обеспечение, которое обеспечивает взаимодействие конечных пользователей с данным ХД. В настоящее время универсальным средством общения служат SQL и его расширения.
Уровень информационного доступа. Обеспечивает непосредственное общение пользователя с ХД. В качестве таких средств могут выступать стандартные пакеты MS Office, Lotus Notes или специальные программные продукты.
Уровень администрирования. Компоненты этого уровня отслеживают выполнение процедур обновления ХД, включающих процедуры подкачки данных, обновления индексов, суммирования и агрегации данных, репликацию данных в распределенной вычислительной среде, авторизацию пользователя и разграничение доступа.
Типы хранилищ данных
Финансовые хранилища данных
В большинстве случаев финансовые ХД организации строят в первую очередь. Создание финансового ХД - необходимый компонент финансовой инфраструктуры любой организации.
Финансовые данные всегда находятся в центре внимания руководства организации. Поэтому привлечь интерес к созданию такой информационной системы данных очень легко.
Финансовая активность большинства организаций (за исключением финансово-кредитных учреждений) невелика, поэтому объемы финансовых данных не очень большие, скорость поступления данных также невелика. Финансовые данные хорошо структурированы. Поэтому имеющиеся программно-аппаратные средства позволяют создать и поддерживать компактные финансовые ХД.
Финансы охватывают все аспекты функционирования организации и имеют один общий знаменатель - деньги.
Финансовые данные по своей природе имеют структуру, на которую напрямую влияет повседневная практика обработки финансовой информации.
По этим причинам финансы становятся самой предпочтительной областью построения корпоративного ХД. Однако финансовые ХД имеют серьезные, присущие только этому типу проблемы. Первая проблема заключается в следующем. Руководство организации ожидает, что сведения из финансовых ХД будут с точностью до одной копейки совпадать с данными существующей финансовой среды. Ожидание того, что информация в финансовом ХД должна точь-в-точь совпасть с цифрами из текущего финансового отчета, является глубоко ошибочным. Люди (то есть финансовые работники), которые так думают, просто не понимают, что, когда данные переходят из операционной среды в финансовое ХД, происходит их трансформация. А когда данные перетекают из мира приложений в реальный мир организации, их рассматривают в другом измерении. При такой трансформации происходит следующее.
Меняются отчетные периоды. В операционной среде отчетный период завершается в конце месяца, а в ХД отчетный период заканчивается на корпоративном календаре, например, 15-го числа месяца.
Меняются схемы группировки и кодирования счетов. В операционной среде данные рассчитываются в соответствии с планом бухгалтерских счетов, а в финансовой среде всей организации может быть совершенно другой набор схемы группировки и кодирования.
Меняются классификации данных.
Меняются валюты. Операционные денежные средства соответствуют той валюте, в которой они обращаются: рубли, доллары, евро, фунты и так далее. В глобальной среде деньги преобразуются к одной общей валюте.
Как видно, существует много причин, почему данные, находящиеся в ХД, отличаются от данных операционных систем. Финансовые работники думают иначе, и поэтому необходимо им разъяснять, что такое трансформация и что означают различные измерения данных.
Хранилища данных в области страхования
ХД в области страхования, за некоторыми небольшими исключениями, похожи на все другие. Первое исключение (характерное для западных компаний) заключается в том, что продолжительность существования имеющихся ХД очень велика. Такие ХД содержат данные, которые являются очень старыми (до начала XX века)
Второе отличие этих ХД определяется датами, сведения о которых хранятся в этой сфере деятельности. Среда страхования - по каким бы то ни было причинам - отличается наличием огромного числа дат, связанных с бизнесом, большим, чем в каком-либо другом виде деятельности. Так, в сфере розничной торговли имеется несколько важных дат: дата продажи, дата появления на складе, возможно, дата производства. В банковском деле существенна дата транзакции. В телекоммуникации - дата телефонного звонка. В страховании же присутствуют даты всевозможных типов.
Наконец, третье отличие заключается в том, что эти ХД используют свой рабочий цикл деловой активности. Большинство организаций имеет весьма ограниченный и короткий экономический цикл. Так, в банках это - обналичивание чека. В торговле - покупка изделия. В телефонной компании - звонок. В страховании им может быть заявка на страховое возмещение, которая может быть удовлетворена спустя пять лет, или закрытие полиса может сопровождаться двухмесячной отсрочкой. В итоге скорость, с которой функционирует страхование, отличается от скорости, характерной для других отраслей.
Эта разница в скорости отражается в ХД, как в зеркале. В других ХД транзакции просто собираются и обрабатываются. В области страхования транзакция может откладываться на неопределенный срок, а ее различные части могут отражаться в ХД, т.е. существенным становится не только сама операция, но и ее состояние. Результатом этого является совершенно особый подход при проектировании и внедрении таких ХД.
Хранилища данных для управления персоналом
ХД для управления людскими ресурсами имеют весьма существенные отличия от других ХД. Первое отличие - число предметных областей. Такое ХД неизбежно имеет одну важную предметную область - это работник. Практически все остальное подчинено этой области или занимает второстепенное положение. Большинство же других ХД имеют несколько базовых предметных областей.
Основное отличие ХД для управления людскими ресурсами состоит в том, что они используют очень мало транзакций. Так, имеется дата, когда субъект становится работником; дата, когда человек увольняется; годовые прибавки и повышения. Но, кроме транзакций фонда заработной платы и прочих редких, сгенерированных работником, транзакций, в таком ХД практически больше ничего и нет. Сравните сферу управления людскими ресурсами с коммуникацией или банковской средой, и разница в числе транзакций станет очевидной.
Эта разница в числе транзакций является причиной возникновения определенной сложности, которая заключается в том, что в области управления человеческими ресурсами наблюдается тенденция к объединению операционной обработки людских ресурсов и обработки людских ресурсов для систем принятия решения в одну среду. В других же отраслях соблазн совершить такую архитектурную ошибку весьма невелик.
Хранилища данных с возможностями обнаружения новых данных (Data Mining)
ХД, поддерживающие технологию обнаружения новых данных (Data Mining), являются гибридом классических ХД. Они используются для выполнения мощной статистической обработки данных. Эти ХД являются:
очень детальными;
глубоко историческими;
оптимизированными для статистического анализа.
Кроме того, для таких ХД характерна ориентация на какой-либо проект. Это означает, что, в отличие от всех других типов ХД, в большинстве случаев их перестают использовать сразу по завершении анализа, ради которого они создавались.
Еще одно важное отличие ХД с возможностями анализа заключается в том, что оно очень часто включает внешние данные. Такие данные очень полезны с точки зрения прогнозирования изменения бизнес-данных, которое не так легко увидеть без их участия.
Хранилища данных в области телекоммуникаций
Отличительная особенность этих ХД состоит в том, что они в значительной степени определяются данными, касающимися факта телефонных разговоров. Разумеется, в отрасли телекоммуникации присутствует множество других типов данных. Но ни одна другая область ХД не предопределяется в такой степени размером одной предметной области — деталями на уровне разговора.
Существуют несколько способов хранения подробностей на уровне телефонного разговора:
хранение деталей на уровне разговора только за несколько месяцев;
хранение множества деталей на уровне разговора, размещенных на различных носителях;
резюмирование или агрегирование деталей на уровне разговора;
хранение только отобранных деталей на уровне разговора, и так далее.
К сожалению, несмотря на разнообразие методов обработки, для данного ХД обработка может быть выполнена только над деталями на уровне разговора. А работа на итоговом или агрегированном уровне просто невозможна.
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
«Дальневосточный федеральный университет»
(ДВФУ)
ШКОЛА ЕСТЕСТВЕННЫХ НАУК
МАТЕРИАЛЫ ПРАКТИЧЕСКИХ ЗАНЯТИЙ (ЛАБОРАТОРНЫХ РАБОТ)
по дисциплине «Базы данных»
Специальность 080801.65 – «Прикладная информатика (в экономике)»
Форма подготовки – очная
г. Владивосток
2012
|
