Содержание к диссертации
Введение
Глава 1. Анализ и исследование существующих систем хранения и обработки информации 16
1.1. Реляционные модели хранения и обработки информации 16
1.2. Переход к нереляционным моделям 19
1.3. Многомерное представление данных 22
1.3.1. OLAP технология 23
1.3.2. Сравнение OLTP и OLAP систем 24
1.3.3. Система поддержки принятия решений 25
1.3.4. Многомерное представление данных 26
1.3.5. Преимущества использование хранилищ данных .. 33
1.4. Материализованное представление данных 38
1.5. Выводы 40
Глава 2. Модели и алгоритмы обработки данных с использованием реляционных и мноромерных баз данных . 41
2.1. Добыча данных 41
2.2. Классификации 43
2.2.1. Классификационные правила 44
2.2.2. Методы Naive Bayes 45
2.2.3. Деревья решений 48
2.3. Регрессионый анализ 51
2.4. Ассоциативные правила 54
2.5. Кластерный анализ 66
2.6. Методы прогнозирования 75
2.7. Выводы 83
Глава 3. Разработка хранилища данных для хранения объектной информации 85
3.1. Разработка хранилища данных 85
3.1.1. Архитектура хранилища данных 86
3.1.2. Независимые витрины данных 87
3.1.3. Двухуровневое хранилище данных 88
3.1.4. Трехуровневое хранилище данных 89
3.1.5. Характеристика хранилища данных 91
3.2. Концептуальное моделирование хранилища данных 92
3.2.1. Переход от модели сущностей к многомерной модели 94
3.2.2. Выявление иерархии при многомерном моделировании 95
3.3. Построение многомерной модели 97
3.3.1. Алгоритмы определения классов иерархии 98
3.3.2. Объединение в классы иерархии 99
3.3.3. Схема фактов для предметной области сети магазинов 100
3.3.4. Схема реализации модели 101
3.4. Математическая модель многомерного представления данных 102
3.4.1. Основные понятия многомерной модели 103
3.4.2. Пример измерения «География» 107
3.4.3. Операции на кубе 111
3.5. Выводы 117
Глава 4. Разработка системы поддержки принятия решений 118
4.1. Концептуальная модель системы 118
4.2. Требование к системе 123
4.3. Алгоритм загрузки данных в ХД 124
4.4. Безопосность СППР 128
4.5. Методы повышения эффективности обработки данных 12 9
4.5.1. Использование материализованного представления 130
4.5.2. Разделение таблиц и параллельность выборки. 132
4.5.3. Индексирование данных 134
4.6. Выбор СУБД 13 6
4.7. Выводы 138
4.8. Основные результаты работы 138
Список использованной литературы 140
Приложения 149
- Переход к нереляционным моделям
- Преимущества использование хранилищ данных
- Архитектура хранилища данных
- Методы повышения эффективности обработки данных
Введение к работе
Актуальность темы. В настоящее время базы данных широко используются в нашей повседневной жизни. Любая, успешно работающая организация, хранит свои данные и обрабатывает их с использованием современных систем управления базами данных. Они повсеместно используются для получения сведений о сотрудниках, о товарах, о продажах, бухгалтерских данных, данных бизнеса и т.д. Но информация сама по себе без обработки не представляет интерес, поэтому работа с базами данных всегда требует совершенствования способов хранения данных, а также сокращения времени выборки данных, необходимых для получения своевременной и необходимой информации.
Важным фактором в современных рыночных условиях является оперативное принятие деловых решений. Однако многие предприятия сталкивается с таким препятствием, как большой объём и высокая сложность данных. Решением данного вопроса может стать создание системы поддержки принятия решений (СППР) на основе хранилищ данных (ХД). Хранилище данных представляет собой накопитель информации из других систем (баз данных, файлов, электронных таблиц и др.), на основе которых строятся процессы принятия решений и анализа данных.
Системы поддержки принятия решений (СППР) – это системы, обладающие средствами ввода, хранения и анализа данных, относящихся к определённой предметной области, с целью поиска решений.
Основная задача СППР – предоставление аналитикам инструмента для выполнения анализа данных. СППР не гарантирует правильных решений, а только поставляет аналитику данные в виде таблиц, отчётов, графиков и т.п. для изучения и анализа.
Исследованию СППР на основе ХД посвящены работы Э.Спирли, Р.Кимбала, А.А.Барсегяна, И.А.Чубуковой, М.С. R.Agrawal, P.Vassiliadis, С.Хайкина, И.С.Ризаева, А.Н.Кузьмина, Л.Ю.Емалетдиновой, Н.М.Вдовичева и др.
Трудно переоценить актуальность построения системы принятия решений (СППР) для крупных банков, предприятий нефтяной, газовой отрасли, машиностроении, металлургии, торговле и т.д. Конечно, СППР, основанная на технологии хранилищ данных или витрин данных (а большинство СППР базируются именно на них), будет быстрее окупаться на крупных предприятий или организациях с развитой филиальной сетью и разнообразной деятельностью, внедряющих корпоративные информационные системы.
Объект исследования. Системы хранения, обработки и извлечения информации из баз данных и хранилищ данных.
Предмет исследования. Модели и алгоритмы систем поддержки принятия решений на основе многомерных моделей баз и хранилищ данных.
Научная задача. Разработка новых аналитических моделей и алгоритмов интеллектуального анализа данных и программного комплекса системы поддержки принятия решений на основе многомерных моделей хранилищ данных
Цель и задачи исследований. Целью работы является повышение эффективности обработки и хранения больших объемов информации за счет использования технологии хранилищ данных.
Для достижения поставленной цели необходимо решить следующие задачи:
1. Проанализировать и исследовать существующие способы хранения и обработки информации.
2. Разработать модели и алгоритмы интеллектуального анализа данных с целью прогнозирования и поддержки принятия решений.
3. Создать методику разработки концептуальной модели многомерного представления данных для эффективного хранения и быстрого выполнения запросов при хранении объектной информации.
4. Провести экспериментальные исследования моделей и алгоритмов с помощью разработанных программ интеллектуального анализа данных и системы поддержки принятия решений в среде СУБД ORACLE на основе концепции хранилищ данных
Методы исследования. При решении поставленных задач использовались математические модели и методы системного и интеллектуального анализа данных, теории вероятностей, теории множеств, теории нейронных сетей, классические методы линейного и целочисленного программирования, системного программирования.
Научная новизна работы.
1. Предложено использование математической модели на основе теории множеств для интеллектуального анализа данных с целью решения задач классификации различных объектов. Разработаны алгоритмы разбиения клиентов на классы с использованием метода “классификационных правил”, в случае учета нескольких независимых переменных наивный метод Байеса для получения таблицы решений.
-
Разработан алгоритм вычисления ассоциативных правил с учетом распределенного хранения информации с целью ускорения процесса выполнения таких правил.
-
Разработан модифицированный алгоритм кластеризации на основе k-среднего и предложен метод исправления результатов кластеризация для категориальных объектов на основе информационного подхода, с применением критерия энтропии.
-
Разработана структура трехслойной нейронной сети с вычислением весовых коэффициентов для прогнозирования и принятия решений.
-
Разработана методика построения многомерной модели хранилища данных, а также дано формализованное описание гиперкуба и возможных операций над кубом данных.
Практическая ценность диссертации состоит в следующем:
-разработан программный комплекс системы поддержки принятия решений и прогнозирования с использованием многомерных моделей для интеллектуального анализа данных;
- разработаны алгоритмы и комплексы программ на языке PL/SQL в среде СУБД ORACLE для решения задач классификации, кластеризации, поиска ассоциативных правил для крупных информационных предприятий;
- разработана структура трехслойной нейронной сети для решения задач прогнозирования для торговых организаций, банковских структур, и др.;
- разработаны методы увеличения быстродействия выполнения запросов за счет использования материализованного представления, индексов и параллельного выполнения транзакций при разделении данных.
Результаты работы. Результаты выполненных исследований и разработок использовались:
- в Торговом доме «Лес Парк Сад», занимающегося оптовой и розничной продажей товаров;
- в научно-техническом центре ООО фирмы «ЛУН-М», занимающегося формированием комплектующих технических средств для подъемных кранов;
- в учебном процессе кафедры Автоматизированных систем обработки информации и управления в форме электронного учебного пособия «Лабораторный практикум СУБД ORACLE» по дисциплине «Распределенные базы данных» для студентов специальности 230102, кроме того, разработанные методы и алгоритмы по классификации, кластеризации, прогнозированию на основе нейронных сетей рекомендованы студентам для выполнения курсовых и дипломных работ.
Апробация работы. Основные результаты диссертации докладывались и обсуждались на следующих международных и всероссийских конференциях:
Всероссийская научно-практическая конференция. “Наука и профессиональная деятельность”. (Нижнекамск. 2008,2009,2010);
Международная конференция. Инфокоммуникационные технологии глобального информационного общества. (Казань, 2008, 2009); XVI Международной конференции по вычислительной механике и современным прикладным программным системам. (Крым, Алушта 2009); Седьмая международная конференция «Исследование, разработка и применение высоких технологий в промышленности» (Санкт-Петербург, 2009); Международная молодежная научная конференция “Туполевские чтения”.(Казань, КГТУ им.А.Н.Туполева, 2008, 2009).
Публикации. Содержание диссертации опубликовано в 16 работах, включая 8 статей, в том числе две статьи в изданиях, входящих в перечень ВАК (Вестник КГТУ им. А.Н.Туполева).
Структура и объем работы.
Диссертационная работа состоит из введения, четырех глав, заключения, списка литературы и приложений. Работа содержит 146 страниц основного текста, 50 рисунков, 27 таблиц. и 5 приложений. Список литературы включает 93 наименования.
Переход к нереляционным моделям
При достаточно больших объемах информации, для получения агрегированных данных может потребоваться выборка из многих таблиц с использованием методов реляционной алгебры и это может потребовать достаточно длительного времени, что не всегда устраивает аналитиков.
Однако многие статистические данные могут быть заранее рассчитаны, и храниться в таблицах в виде агрегированных данных. Такие таблицы в общем случае уже не будут нормализованными, и не будут представлять реляционную модель. Но такой подход может значительно увеличить скорость выборки при больших объемах информации. Рассмотрим следующий пример. Необходимо получить ответ на вопрос типа, какие товары (продукты) покупают клиенты в торговых центрах.
В языке программирования SQL существует оператор "CUBE", с помощью которого, можно создать нереляционную таблицу с целью хранения всех результатов группирования: create table групп_таб as select Название, Дата , count( ) from Продажа, ОперацииПродажа group by cube (Название , Дата); Такой пример показывает, что не всегда реляционные модели данных занимают ведущее место и даже, их главное свойство "третья нормальная форма" является недостатком.
Аналитики или менеджеры обычно предпочитают просматривать данные в более простом виде, чтобы можно было легко читать их и быстро принимать решения. Поэтому они предпочитают таблицы следующего вида .
В таблице (см.табл.1.6) атрибуты «Название» и «Время» однозначно определяют любую строку. Но для выборки данных по нескольким аспектам, с условием итоговых подсчетов, с помощью существующего языка SQL может оказаться достаточно трудным. Поэтому кросс-таблицу удобнее представить в виде куба.
Такой куб может быть многомерным, если возьмем три аспекта (город, товар, время) получим трехмерный куб (см.рис.1.3). При включении четвертого аспекта, например, «отдел» получим четырехмерный куб. Но могут быть добавлены еще аспекты: вид продажи, поставщик и т.д. Размер куба данных можно определить по формуле TTt (dj +1) 5 где і — измерения (количество аспектов), dj- количество различных значений кортежей по указанному аспекту. Необходимо отметить, что реляционные модели данных, обладают рядом недостатков. - Существует достаточно много запросов, которые достаточно трудно или невозможно писать на языке "SQL" [84]. - Язык запросов "SQL" не подходит для статистического анализа. - Большие организации, имеющие большие внутренние объёмы данных и данные от многих внешних источников не всегда могут получить исчерпывающий результат. - В реляционной базе данных существуют связи между объектами, но нет связей между записями внутри объектов. - Время анализа данных с целью принятия решения увеличивается в зависимости от объема данных, поскольку информация хранится в нормализованном виде.
Поэтому естественно возникает вопрос: «Для каких целей строится информационная система? ». И при этом существуют два ответа: Либо для обработки транзакций (on-line transaction processing - OLTP), либо для аналитической обработки (on-line analytical processing - OLAP). Основные отличительные черты между OLTP и OLAP можно резюмировать следующим образом [1,64,66].
Термин OLAP был предложен в 1993 г. Эдвардом Коддом (Е. Codd — автор реляционной модели данных) По Кодду OLAP-технология — это технология комплексного динамического синтеза, анализа и консолидации больших объемов многомерных данных. Он же сформулировал 12 принципов OLAP, которые позже были переработано в так называемый тест FASMI[1]: Fast (быстрый) — предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа; Analysis (анализ) — возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде; Shared (разделяемый) — многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа; Multidimensional (многомерный) — многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (ключевое требование OLAP); Information (информация) — возможность обращаться к любой нужной информации независимо от ее объема и места хранения. В самом общем виде OLAP - многомерное представление куба данных. OLAP-технология представляет для анализа данные в виде многомерных (и, следовательно, нереляционных) наборов данных, называемых многомерными кубами (гиперкуб, метакуб, кубом фактов), оси которого содержат параметры, а ячейки — зависящие от них агрегатные данные. При этом гиперкуб является концептуальной логической моделью организации данных, а не физической реализацией их хранения, поскольку храниться такие данные могут и в реляционных таблицах ("реляционные БД были, есть и будут наиболее подходящей технологией для хранения корпорационных данных" — Е. Codd).
Преимущества использование хранилищ данных
Хранилище данных имеет преимущества в отличие от использования оперативных систем или баз данных, в [46] приведены следующие из них: В отличие от оперативных систем, хранилище данных содержит информацию за весь требуемый временной интервал - вплоть до нескольких десятилетий - в едином информационном пространстве, что является идеальной основой для выявления трендов, сезонных зависимостей и других важных аналитических показателей. Как правило, информационные системы предприятия хранят и представляют аналогичные данные по-разному. Например, одни и те же показатели могут храниться в различных единицах измерения. Одна и та же продукция или одни и те же клиенты могут именоваться по-разному. В системах хранилищ несоответствия в данных устраняются на этапе сбора информации и погружения ее в единую базу данных. При этом организуются единые справочники, все показатели в которых приводятся к одинаковым единицам измерения. Очень часто оперативные системы вследствие ошибок операторов содержат некоторое количество неверных данных. На этапе помещения в хранилище данных информация предварительно обрабатывается. Данные по специальной технологии проверяются на соответствие заданным ограничениям и при необходимости корректируются (очищаются). Технология обеспечивает построение аналитических отчетов на основе надежных данных и своевременного оповещения администратора хранилища об ошибках во входящей информации. Универсализация доступа к данным. Хранилище данных предоставляет уникальную возможность получать любые отчеты о деятельности предприятия на основе одного источника информации. Это позволяет интегрировать данные, вводимые и накапливаемые в различных оперативных системах, легко и просто сравнивать их. При этом в процессе создания отчетов пользователь не связан различиями в доступе к данным оперативных систем. Ускорение получения аналитических отчетов. Получение отчетов при помощи средств, предоставляемых оперативными системами, является неэффективным способом. Эти системы затрачивают значительное время на агрегирование информации (расчет суммарных, средних, минимальных, максимальных значений). Кроме того, в текущей базе оперативной системы находятся только самые необходимые и свежие данные, в то время как информация за прошлые периоды помещается в архив. Если данные приходится получать из архива, продолжительность построения отчета возрастает еще в два-три раза. Следует также учитывать, что сервер оперативной системы зачастую не обеспечивает необходимую производительность при одновременном построении сложных отчетов и вводе информации. Это может катастрофически сказываться на работе предприятия, так как операторы не смогут оформлять накладные, фиксировать отгрузку или получение продукции в то время, когда выполняется построение очередного отчета. Хранилище данных позволяет решать эти проблемы. Во-первых, работа сервера хранилища не мешает работе операторов. Во-вторых, в хранилище помимо детальной информации содержатся и заранее рассчитанные агрегированные значения. В-третьих, в хранилище архивная информация всегда доступна для включения в отчеты. Все это позволяет значительно сократить время создания отчетов и избежать проблем в оперативной работе.
Как видно из перечисленных преимуществ использования технологии хранилищ данных, большая их часть может существенно упростить, повысить скорость и качественно улучшить процесс Data Mining. Таким образом, комплексное внедрение этих технологий дает разработчикам и пользователям неоспоримые преимущества перед использованием разрозненных баз данных различных информационных систем при создании систем поддержки принятия решений.
При использовании хранилища данных, с целью анализа данных для поддержки принятия решения, потребуется собрать данные из одной или нескольких баз данных в одном месте, т.е. в хранилище данных. А это требует выполнения процессов "extract, transform, load". Что вызывает ряд проблем, например, какие данные из оперативных источников загрузить в хранилище данных и как можно извлекать их без отрицательного влияния на работы источника данных, определить время копирования данных из источников в зависимости от их стоимости с точки зрения аналитиков.
Но одной из важных проблем при переносе данные в ХД является их очистка. С одной стороны, данные загружаются из различных источников, поэтому вероятность попадания «грязных данных» весьма высока. С другой, стороны «грязные данные» могут стать причиной принятия неверных решений. Такая проблема возникает тогда, когда данные берутся из не единого источника и вследствие, отсутствия стандартов на формат данных или нарушения целостности данных. Например, можно найти значения «Ж» и «М» для определения пола клиента в одной БД, а в другой эти значения могут иметь формат «Женский» и «Мужеской».
Схема «звезда» представляет собой модель, используемую для отображения данных систем поддержки принятия решений. Основными составляющими такой схемы являются таблица факта и таблицы измерений. Ее идея заключается в том, что имеются таблицы для каждого измерения, а все факты помещаются в одну таблицу, индексируемую множественным ключом, составленным из ключей отдельных измерений (рис. 1.7). Каждый луч схемы звезды задает, в терминологии Кодда, направление консолидации данных по соответствующему измерению. [81].
В сложных задачах с многоуровневыми измерениями может возникнуть необходимость произвести расширение схемы «звезда» путем преобразования ее в схему «снежинка» (snowflake schema) [81]. Схема «снежинка» является вариантом схемы «звезда». В этом случае некоторые таблицы нормализуются, что приводит к расщеплению данных и формированию дополнительных таблиц. В результате таких преобразований возникает схема по форме аналогичная снежинке (рис. 1.8). Это позволяет добиться лучшей производительности, но зато приводит к избыточности данных и к значительным усложнениям в структуре базы данных, в которой оказывается огромное количество таблиц фактов.
Применение материализованных представлений может резко повысить эффективность запросов, а также значительно уменьшить нагрузку на систему. Это объясняется тем, что в этом случае потребуется меньшее количество логических чтений для удовлетворения запросов, чем тот же запрос будет работать в среде базовых таблиц.
Архитектура хранилища данных
В соответствии с определением хранилища данных оно должно обладать следующими основными функциями: 1. Сбором данных, то есть извлекать данные из различных источников, преобразовывать и загружать их в хранилище данных с помощью различных инструментов. 2. Хранением данных: хранить данные. 3. Анализом данных. И в соответствие с этим можно выделить следующие модели хранилищ данных. Самой простой моделью является виртуальная модель хранилища данных (ВХД)[22] — это система, которая работает с различными источниками данных и эмулирует работу обычного хранилища данных, извлекая, преобразуя и интегрируя данные непосредственно в процессе выполнения запроса. Такой подход представляется как процесс доступа конечных пользователей к оперативной базе данных непосредственно для принятия решений. Такая модель имеет следующие преимущества: Минимизируется объем требуемой дисковой и оперативной памяти, поскольку отсутствует необходимость хранения исторических данных и многочисленных агрегированных данных для различных уровней обобщения данных. Наличие в ВХД развитого семантического слоя позволяет аналитику полностью абстрагироваться от проблем, связанных с процессом извлечения данных из разнообразных источников, и сосредоточиться на решении задач анализа данных. Появляется возможность анализа данных в OLTP- системе сразу после их поступления без ожидания загрузки в хранилище.
Но такой подход имеет ряд недостатки по сравнению с ХД: Нет, автоматической поддержкой целостности. Сложная работа с историческими данными. Данные в разных источниках могут храниться в различных форматах, что может привести к ошибкам при выполнении запросов. Поэтому предпочтительней для построения СППР воспользоваться технологией на основе хранилищ данных. На сегодняшний день можно выделить три наиболее популярных архитектурных принципа для построения систем поддержки принятия решений: 1- Независимые витрины данных. 2- Двухуровневое хранилище данных. 3- Трехуровневое хранилище данных. Витрина данных - это упрощенный вариант ХД, содержащий только тематически объединенные данные[1].
Такие виды хранилищ используются в крупных организациях с большим количеством независимых подразделений, зачастую имеющих свои собственные отделы связанных с информационными технологиями. Преимущества таких архитектур заключаются в следующем: витрины данных можно внедрять достаточно быстро, витрины проектируются для ответов на конкретный ряд вопросов, данные в витрине оптимизированы для определенных групп пользователей, что облегчает процедуры их наполнения, а также способствует повышению производительности.
Но такой вариант имеет недостатки: данные хранятся многократно в различных витринах данных, что приводит к дублированию информации и, как следствие, к увеличению расходов на хранение и возможным проблемам, связанным с необходимостью поддержания непротиворечивости данных; потенциально является достаточно сложным процесс наполнения витрин данных при большом количестве источников данных; данные не консолидируются на уровне предприятия и, следовательно, отсутствует единая картина бизнеса.
Такие виды хранилищ используются в крупных организациях, тогда когда собранная информация из различных подразделений, считается достаточно близкой или взаимосвязанной. При этом аналитики используют схожие данные для выполнения своих анализов. Преимущества таких архитектур: данные хранятся в единственном экземпляре; минимальные затраты на хранение данных; отсутствуют проблемы, связанные с синхронизацией нескольких копий данных; данные,консолидируются на уровне предприятия, что позволяет иметь единую картину бизнеса.
Хранилище данных представляет собой; единый: централизованный источник: информации: длял всей; организации. Витрины данных отражают подмножества данных: из хранилища; организованные для; решения: задач отдельных подразделений компании.. Конечные пользователи/имеют возможность доступа к детальным данным хранилища, в случае если данных в витрине- недостаточно; а также для получения: более полной; картины.; состояния бизнеса. Преимущества; создание и наполнение витрин данных упрощено, поскольку наполнение происходит из единого стандартизованного надежного источника очищенных нормализованных данных; имеется (построена) общая структура данных предприятия; витрины данных синхронизированы и совместимы с общей структурой данных предприятия; существует возможность сравнительно легкого расширения хранилища и добавления новых витрин данных; гарантированная производительность.
Методы повышения эффективности обработки данных
Как было показано4 выше, данные ХДі делятся нш три? основные категории (детальные, агрегированные и метаданные); Для повышения производительности ХД требуется разработать способы,хранения для;каждой категории, при этом необходимо учесть, что. эти способы могут быть разными; и что подходит для одной категории, могут быть не пригодным для? другой. Например, Bree индекс хорошо подходит для индексирования детальныхданных, но плохо подходит для агрегированных данных. Рассмотрим, как строится кросс-таблица с данными куба (рис.4.5). Бледно серым цветом отображены ячейки, содержащие агрегированные результаты (по измерению товары); черным цветом, отображены ячейки, содержащие агрегированные результаты (по измерениям город и дата); серым цветом отображены ячейки с фактами куба. Москва Казань Самара 1-1-2007 Компьютер Принтер Фотоаппарат Сканер 2-1-2007 Компьютер Принтер Фотоаппарат Сканер Рис.4.5. Кросс-таблица При этом нужно отметить то, что полученная таблица будет сильно разреженной. Например, пусть в измерение «товар» включено 5022 меток, измерение «город» состоит из 620 меток, измерение «время» состоит из 366 меток. Здесь рассматривается конкретный пример продажи товаров для 2000 года. Это означает, что количество элементов в таблице будет равно: М = 5022 620 366 = 1139 592 240 (+ 2065959)
Дополнительное числовое значение (2065959), полученное путем агрегирования, необходимо добавить к вычисленной сумме. Но заполненных элементов в таблице будет всего 375192 (0,033%), что составляет менее одного процента. Причем, чем больше количество измерений и меток, тем более разреженной будет таблица. Поэтому нужно принимать специальные механизмы для работы с разреженными таблицами.
Мы предлагаем использовать методику для хранения только тех строк и столбцов, в которых есть не нулевые значения. Для этого предлагаем использование особого вида хранения данных, которое называется материализованным представлением, оно обеспечивает и сжатие, и повышение скорости выполнения запросов.
Запросы, осуществляемые на больших базах данных, нередко связаны с необходимостью выборки из различных таблиц, объединяемых в процессе запроса. Такие запросы довольно часто встречаются при работе с ХД, и это требует длительного времени, поэтому луче хранить результаты запросов, используя материализованные представления. Обычно данные при материализованном представлении — это агрегированные данные, являющиеся результатом выполнения операций группирования, таких как sum, count, avg В качестве примера, рассмотрим следующий запрос, который вычисляет сумму продаж в зависимости от города и времени (месяц), используя детальные данные в связанных таблицах фактов и измерений (Sales, Customers, Times): Select month, year, city, sum (amount_sold) From sales, times, customers Where sales.cust_id = customers. cust_id And sales, time id = times, time id Group by month, year, city Order
Хранилища данных часто содержат таблицы очень большой размерности, которые требуют больших временных затрат при управлении. Можно указать следующие временные затраты: - Сканирование больших таблиц и объединение нескольких таблиц. - Создание больших индексов. - Массовые операции, связанные с добавлением, обновлением или удалением данных. - Агрегирование и копирование.
Для обеспечения хорошей производительности запросов предлагается делить большие таблицы на маленькие и работать с полученным результатом в параллельном режиме. Но при таком делении необходимо выбирать только те таблицы или элементы таблиц; к-; которым идет наиболее, частое обращение.
Данные в ХД большей частью используются для принятия решения, для выполнения которых формируются запросы. В этом случае нет необходимости в выполнении таких операций как добавление, обновление или удаление во время выполнения запросов [46,64,84]. С целью определения использования методов индексации для массивов данных, необходимо провести анализ: а) Характеристики столбцов данных, подлежащих индексированию: Столбец имеет свои особенности, которые необходимо учесть для выбора правильного индекса. Можно указать следующие характеристики: - Мощность (Cardinality) данных. Мощность данных столбца это число различных значений в столбце. Необходимо знать, какова мощность индексируемого столбца (низкая или высокая), так как, эффективность работы при индексации зависит от мощности данных. - Распределение. Распределение связано с частотой встречаемости каждого отдельного значения столбца. В зависимости от распределения производится выбор типа индекса. - Диапазон значений также влияет на выбор типа индекса. Например, если столбцов высокой мощности не много, то лучше для индексирования использовать индекс типа Bitmap. Не зная подобной информации, мы можем воспользоваться индексом В-Тгее, и в результате ухудшить производительность системы. б) Понимание данных при организации запросов на языке SQL. Знание, какие именно поля (столбцы) будут запрошены, нам облегчает выбор соответствующих типов индексов для них. Например, какие поля (столбцы), с наибольшей вероятностью, будут участвовать совместно в запросах и как часто они используются при применении операций группирования в предложениях ORDER BY, или GROUP BY?
В зависимости от таких свойств и организации могут быть применены различные индексы, например Bree или Bitmap. В общем, случае «Bitmap 134 индекс» больше подходит для ХД, поскольку большинство запросов используют условия с учетом просмотра атрибутов, которые могут иметь достаточно низкую мощность. Этот вид индекса особенно походит, когда мы используем модель, построенную по схеме «звезда» [81,73]. Или когда речь идет о данных с немногочисленными уникальными значениями, такими как название продукта или города. Чтобы получить максимальную производительность, лучше использовать индекс «Bitmap», который может быть применен для внешнего ключа таблицы фактов. Но тогда когда требуется индексировать столбец или множество столбцов с уникальными значениями, то вариант с применением индекса «Вree» может оказаться лучше[73].
