Многомерное концептуальное представление данных. Это требование возникает по той причине, что бизнес-пользователь естественно представляет историю и деятельность своей корпорации многомерными (например, одно измерение - время, другое - заказчики, третье - производимая продукция и т.д.). OLAP-модели должны поддерживать это представление и, естественно, оно должно хотя бы в какой-то мере опираться на возможности аналитической базы данных.
Прозрачность. Для бизнес-пользователя не должно быть существенно, где конкретно расположены средства динамического анализа данных. При разработке OLAP-систем следует придерживаться подхода открытых систем, что позволит размещать средства анализа в любом узле корпоративной сети.
Доступность. Логическая схема, с которой работает OLAP-система, должна отображаться в схемы разнородных физических хранилищ данных. При доступе к данным должно поддерживаться их единое и согласованное представление.
Согласованная эффективность производства отчетов. Эта эффективность не должна деградировать при увеличении числа измерений.
Архитектура "клиент-сервер". Серверный компонент OLAP-системы должен быть достаточно развитым, чтобы разнообразные клиенты могли подключаться к нему с минимальными усилиями и затратами на дополнительное "интегрирующее" программирование.
Родовая многомерность. Структурные и операционные возможности работы с каждым измерением данных должны быть эквивалентны. Для всех измерений должна существовать только одна логическая структура. Любая функция, применимая к одному измерению, должна быть применима к любому другому измерению.
Управление динамическими разреженными матрицами. Сервер OLAP-системы должен уметь эффективно хранить и обрабатывать разреженные матрицы. Физические методы доступа должны быть разнообразны, включая прямое вычисление, B-деревья, хэширование или комбинации этих методов.
Поддержка многопользовательского режима. OLAP-система должна поддерживать многопользовательский доступ к данным (по выборке и изменению), обеспечивая целостность и безопасность данных.
Неограниченные операции между измерениями. При выполнении многомерного анализа данных все измерения создаются и обрабатываются единообразно. OLAP-система должна быть в состоянии выполнять соответствующие вычисления между измерениями.
Интуитивное манипулирование данными. Манипуляции, подобные смене пути анализа или уровня детализации, должны выполняться с помощью прямого воздействия на элементы OLAP-модели без потребности использовать меню или другие вспомогательные средства.
Гибкая система отчетов. Бизнес-пользователь должен иметь возможность манипулировать данными, анализировать и/или синтезировать, а также просматривать их таким образом, как ему захочется.
Неограниченное число измерений и уровней агрегации. OLAP-сервер должен поддерживать не менее 15 измерений для каждой аналитической модели. Для каждого измерения должно допускаться неограниченное число определяемых пользователями агрегатов.
Основным выводом из материала этого раздела является то, что подход складов данных еще слишком молод, чтобы вокруг него сложился круг общепринятых понятий, терминов, технологических приемов. Тем не менее, он кажется настолько важным и перспективным, что многие компании (в том числе и ведущие производители СУБД) ведут активную работу, чтобы быть в авангарде этого направления. Существующие идеи и реализации мы рассмотрим в пятой части курса.
5. Логическая трехзвенная модель Web-приложений
Современный подход разработки web-приложений, работающих с базами данных, основан на так называемой трехзвенной модели. В соответствии с этой моделью приложение логически разделяется на три функциональных уровня (Рисунок 12).
Рисунок 12
– Логическая трехзвенная модель Web-приложений.
Представления данных (Presentation) – интерфейс взаимодействия пользователя и приложения:
Ввод данных пользователем;
Пересылка входных данных компонентам, которые работают с функциональной логикой приложения (business-objects);
Получение результирующих данных от бизнес объектов;
Представление этих результатов в требуемом виде.
Функциональная логика приложения (Business) – множество бизнес-объектов, которые выполняют требуемые операции над данными пользователя и местом их хранения (базой данных), т.е. которые реализуют функциональную часть приложения– часть, для которой создавалось приложение.
Хранилище (Data) – сохранение данных, выборка, вставка, удаление и возможная модификация, целостность, резервное копирование и.т.д.– например база данных.
Трехзвенная логическая модель приложения может быть физически представлена в виде распределенного хранения и обработки данных на нескольких машинах.
Некоторые хранилища могут использоваться несколькими приложениями с дополнительными расходами по изменению уровня функциональной логики (использованием различных бизнес-объектов) и изменению уровня представления. Как правило, хранилищами являются сервера баз данных (OLTP, OLAP).
С введением такого деления на уровни критические ресурсы скрываются от пользователя (например, соединение с базами данных или транзакции).
Уровни представления данных и функциональной логики могут формироваться как на стороне сервера, так и на стороне клиента, и зависят от того, где возможно использование различных технологий и инструментария.
Достарыңызбен бөлісу: |