ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 03.02.2024
Просмотров: 22
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
При проектировании базы данных необходимо сделать выбор соответствующей модели. Реляционный тип обладает отработанной технологией оптимизации с использование различных способов ее осуществления. Важным преимуществом ROLAP является возможность работы с большими массивами данных. Но при этом конфигурация пользовательских запросов чрезмерно усложнена, что связано с применением концепции SQL. Только при помощи этого типа организации запросов можно обеспечить корректный доступ к крупной базе данных.
Эффективная работа с базой данных возможна лишь в случае оптимизации клиента, который позволяет отображать все данные заданной базы. Мощность сервера должна сочетаться с параметрами клиента, его многофункциональностью и простотой в эксплуатации. Это предопределяет требование к дополнительным усилиям по повышению производительности самого клиента [7].
Доступ к OLAP-данным обеспечивается инструментом запросов или генератором отчетов. Чем легче доступ и проще интерфейс, тем удобней будет использование данного инструмента. Классическое перемещение объектов в отчет при помощи перетаскивания мышью не только исключает непроизводительные затраты времени, но и уменьшают вероятность ошибки или некорректной работы. Следует разделять функциональные возможности традиционного генератора отчетов и OLAP-генераторов. Если первые ориентированы на ускорение формирования формализованных отчетов, то вторые обеспечивают их актуализацию.
Приложения, в отличие от предыдущих элементов, обладают большими функциональными характеристиками и более высокой производительностью по сравнению с генератором отчетов.
Внедрение современных хранилищ данных и использование средств Data Mining - необходимый элемент безопасности и конкурентоспособности компаний, поскольку обеспечивают не только накопление информации и ее обработку, но и комплексный анализ при сохранении заданного уровня конфиденциальности. Все данные при этом проходят проверку на подлинность и систематизируются.
Между инструментами OLAP и Data Mining есть определенные различия. Применение OLAP-систем позволяет аналитикам осуществить анализ данных наиболее оперативным и комплексным способом. При этом обеспечивается работа инструмента для визуализации срезов данных.
Инструмент Data Mining ориентирован на поиск и отображение неявных тенденций, вследствие чего анализ производится самой системой, поскольку аналитик не имеет реальной возможности адекватно оценить большие массивы информации и выявить скрытые связи и зависимости.
2 OLAP
2.1 Технология OLAP
Программные средства OLAP представляют собой очень эффективные элементы быстрого анализа объемной информации, содержащейся в специальном хранилище. Главной особенностью этой программы можно назвать тот факт, что она ориентируется не на профессиональных пользователей в сфере информационных технологий, а на обыкновенных руководителей, директоров, менеджеров кредитного отдела и других специалистов прикладных сфер на предприятии. Эта программа предназначена для общения специалистов не с компьютером, а с проблемами конкретной организации.
Структура OLAP представлена в форме куба, который сам по себе не пригоден для какого-либо анализа. У такого куба очень много граней, количество которых может достигать девятнадцати и более сторон. Исходя из этой особенности, следует сразу отметить, что при изучении информации многомерного куба сначала придется извлечь ее в простую двумерную таблицу. Такая операция носит название «разрезание куба» и имеет весьма образное представление. Другими словами, специалист как бы «разрезает» кубические измерения по конкретным меткам. Таким способом он получает двумерный кубический срез и далее работает с ним. Это можно сравнить с подсчетом годовых колец на срубленной древесине [16].
При создании «разреза» два измерения остаются цельными по количеству табличных измерений. Но бывает и так, что лишь одно измерение остается «не разрезанным». Это может быть в том случае, когда куб содержит несколько типовых значений числа, и они откладываются по одному конкретному табличному измерению.
При детальном и внимательном рассмотрении первой таблицы сразу заметно, что данные в ячейках не являются первичными, поскольку они получены за счет суммирования более мелких частей и чисел. Например, во многих случаях время делится на части (год на кварталы, месяцы, недели и дни). В качестве примера также можно привести структуру государственного строения, в которой оно формируется из отдельных регионов, городов и населенных пунктов. Помимо этого в каждом городе можно выделить районы и конкретные точки. Если взять структурное деление в сфере розничной торговли, то можно выделить товары, объединенные в группы.
В самом понятии системы OLAP такие многоуровневые построения называются четкой иерархией. Все средства системы призваны обеспечивать возможность для пользователя в любой момент перейти на конкретный уровень иерархии. Для одних и тех же частей может быть задействовано сразу несколько иерархий, например, - "день-неделя-квартал", либо "день-декада-месяц". Вся исходная информация всегда берется из нижних иерархических уровней, а далее складывается в единое целое для получения более обобщенных и завершенных уровней. Чтобы ускорить процесс перехода, числовые обозначения суммируются для различных уровней, а потом сохраняются в секторах куба [8].
Исходя из выше сказанного, можно выделить серьезный момент, - система OLAP очень эффективна и высокопроизводительна. Можно себе представить, что конкретно будет происходить в момент, когда специалист захочет получить конкретную информацию, если средства OLAP в компании отсутствуют. Сначала он должен собственными силами или с помощью программистов сформировать четкий SQL-запрос. После этого он получит всю интересующую информацию в виде отчета, а далее самостоятельно будет заносить их в электронную таблицу. Именно в этот момент начнутся самые серьезные трудности, поскольку специалист должен заниматься не SQL-программированием и ожиданием результатов, а выдавать определенный результат по времени. Конечно это негативно скажется на его профессиональной деятельности и значительно затянет время работы. Кроме того, одна единственная отчетная таблица точно не спасет гиганта мысли и процедуру придется провести несколько раз. Это произойдет по той причине, что грамотные специалисты не задают вопросы по мелочам, они сразу работают со всей информацией.
Поскольку техника постоянно совершенствуется, серверу реляционной СУБД, к которому обращаются специалисты, необходимо постоянно ускорять свою работу. Этот орган должен быстро и надежно предоставлять необходимую информацию и блокировать все посторонние запросы. [1]
Концепция OLAP специально была разработана для решения подобных проблем. Все кубы системы представляют собой своеобразные мета-отчеты. При разрезе мета-отчетов или кубов по конкретным измерениям специалист получает интересующую информацию в виде простых двумерных отчетов. Однако, это не совсем простые отчеты в привычном понимании. Они имеют вид упорядоченной структуры с определенными функциями.
Плюсы кубов системы OLAP очевидны, поскольку показатели запрашиваются из реляционной СУБД лишь один раз при формировании куба. В основном специалисты не работают с информацией, которая меняется очень часто. Поэтому уже сформировавшийся куб можно считать актуальным на протяжение долгого времени. За счет такой особенности исключены все возможные перебои с работой сервера реляционной базы данных. Он просто не получает множество запросов и не выдает миллионы строк с ответами. Вследствие этого скорость доступа и работы с информацией возрастает вместе с производительностью системы. Таким образом, в кубе идет подсчет промежуточных иерархий и формируется одна сумма агрегированных уровней на момент формирования куба. Если с самого начала его построения данные будут содержать информацию за один день по одному конкретному направлению (количеству товара, выручке), то в системе OLAP постепенно со временем будет происходить подсчет этих сумм по неделям, месяцам, годам или другим измерениям [19].
Конечно, за повышение эффективности работы таким способом придется платить. Иногда можно наблюдать такую картину, при которой структура данных системы OLAP «взрывается», т.е. переполняется и занимается в сотни раз больше места, чем имеющиеся исходные данные. Для того, чтобы избежать подобного явления, нужно точно знать, как работает этот механизм. Таким образом удастся формализовать знания и выделить четкие критерии OLAP без перевода на простой человеческий язык. Все эти 12 критериев были сформулированы еще в 1993 году Е. Коддом, который считается создателем концепции реляционных СУБД и самой OLAP. Со временем эти критерии были переработаны в тест FASMI, помогающий определить требования к продуктам OLAP. Сама же аббревиатура FASMI создана от обозначения каждого пункта тестирования:
• Analysis (Анализ). В приложении OLAP пользователь может провести числовой и статистический анализ;
• Fast (Быстрый). С помощью системы обеспечивается минимальный срок получения аналитической информации (не более 5 секунд);
• Multidimensional (Многомерность). Все данные представляются в виде многомерной модели;
• Shared (Разделяемый доступ). Многофункциональное приложение OLAP дает возможность работать сразу с несколькими видами данных одновременно;
• Information (Информация). С помощью OLAP пользователь способен получить требуемые данные из любого электронного хранилища куба [13].
Всю работу с системами OLAP можно формировать на основании двух схем, которые описаны ниже.
2.2 Сравнение технологий OLAP, OLTP и РБД
Параллельное применение учетной системы OLAP или прямая настройка аналитических функций на OLTP-базе, может быть осложнена следующими факторами:
1) запросы к информационной базе в OLAP бывают сложными и требуют много времени. Непосредственно прямой доступ к системе сильно уменьшает общую производительность оперативной системы ПК.
2) Часто в учетных системах информация может быть «загрязнена», несогласованна или неполноценна.
3) Различные учетные системы могут быть неоднородными по разновидности используемых концептуальных возможностей или синтаксических соглашений (кодирования, единиц измерений, наименований), поэтому их интеграция будет затруднительной.
4) Отсутствие общей модели данных размера компании. За счет проектирования баз системы учета могут использоваться разные информационные модели (иерархическая, «фирменная», реляционная, объектно-ориентированная, и прочие).
5) При обновлении OLTP- базы данные за учетный период утрачиваются. Таким образом, происходит остановка анализа временных тенденций. А это обстоятельство является значимым моментом для многих сфер бизнеса [11].
6) В оперативных системах отсутствуют методики четкого представления информации для разных групп пользователей в нужной форме.
7) База OLTP не сохраняет информацию в денормализованном виде, а это нужно для аналитической обработки. Изменение такой информации в процессе выполнения запросов оказывается сложнейшей задачей.
Кроме выше перечисленных концептуальных различий можно отметить и технологические проблемы. Их необходимо преодолевать для эффективного использования аналитических возможностей в отдельных учетных системах. К числу таких проблем относятся следующие трудности:
• отличие аппаратных платформ (сетей, компьютеров и периферии);
• использование разного ПО (операционных систем, СУБД, протоколов, языков программирования);
• геораспределение баз с информацией внутри организации и за ее пределами.
Часто средства OLAP используются в виде набора удобных многопользовательских приложений с поддержкой. Они помогают обеспечить оперативный доступ к разнообразным элементам базы вне зависимости от объема и сложности информации. Это достигается благодаря использованию сервера OLAP, который и представляет собой многопользовательский инструмент для действий с многомерной структурой данных. С помощью системы конструкция сервиса и структура данных оптимизируется должным образом. Благодаря этому можно спокойно проводить не регламентированные запросы и гибкие вычисления с последующим преобразованием информации.
Посредством работы с сервером OLAP можно организовать физическое сохранение многомерных обработанных данных. Это дает возможность быстро формулировать ответы на запросы пользователей. Кроме того, предполагается преобразование информации из реляционных баз в режиме реального времени в многомерные структуры.
Стоит рассмотреть подробнее процесс ведения совместной работы многомерных и реляционных средств. Продукты OLAP активно внедряются в действующую корпоративную структуру посредством интегрирования с реляционными системами. Сами администраторы информационных баз активно загружают данные в многомерный кэш, или же настраивают его для получения доступа непосредственно к SQL информации.
Архитектура системы параллельно использует реляционные и многомерные системы. Сама информация хранится в структуре OLAP или на сервере в виде КЭШа для информации. Можно использовать комбинацию двух подходов и снизить масштаб данных, перемещаемых в многомерную схему из реляционной и обратно.