Трёхуровневая архитектура хранилища данных с интерфейсом запросов



Скачать 67.46 Kb.
Дата23.11.2012
Размер67.46 Kb.
ТипДокументы

СЭТС/Социально-экономические и технические системы: исследование, проектирование, организация

© Камская государственная инженерно-экономическая академия (КамПИ) 2003-2006 / 2номер 2006 г. /


главный инженер Кузьмин А.Н.

ОИиАБР Приволжского отделения № 6670 Сбербанка России
ТРЁХУРОВНЕВАЯ АРХИТЕКТУРА ХРАНИЛИЩА ДАННЫХ С ИНТЕРФЕЙСОМ ЗАПРОСОВ

Для реализации систем поддержки принятия решений (СППР) в корпоративных структурах предлагается использовать трёхуровневую архитектуру хранилища данных с интерфейсом запросов (рис. 1). При возникновении необходимости рассмотрения новой предметной области данная архитектура обеспечит возможность расширения и быстрого добавления зависимых тематических хранилищ данных (ХД).



Рис.1. Трёхуровневое хранилище данных с интерфейсом запросов


Данная архитектура близка к стандартному архиву с интерфейсом управления запросами, предложенному Э. Спирли в [1], но в то же время она сохраняет возможность создания запросов непосредственно витрине данных либо общему ХД (сохранение этой возможности необходимо для тех случаев, когда в интерфейсе управления запросами отсутствуют необходимые конструкции).

К основным доводам в пользу выбора архитектуры трёхуровневого ХД с интерфейсом запросов также можно отнести:

  • большое количество различных источников данных (внешние источники: биржевые курсы, валютные курсы и т.п.; рабочие системы: данные балансовых отчётов, экономические данные и т.д.);

  • централизованное общее руководство банковскими проектами;

  • корректное заполнение ХД и витрин данных из промежуточной области.

Основным недостатком является неизбежная избыточность данных (одни и те же данные могут частично дублироваться во всех трёх уровнях хранилища, рабочих системах и внешних источниках).

Архитектуру, представленную на рис. 1, формально можно описать при помощи следующей математической модели:

, где ,



, где ,

(М.1)

: gif" align=bottom>, где ,

: , где

: , где



, где , ,

, где - множество натуральных

чисел

В модели (М.1) приняты следующие обозначения:

– количество рабочих источников данных;

– количество внешних источников данных;

– количество зависимых хранилищ данных;

– количество всех возможных запросов, определённых над множеством всех зависимых тематических хранилищ данных ;

– количество всех возможных запросов, определённых над множеством всех отношений хранилища данных ;

– количество всех возможных запросов, определённых над множеством всех функций интерфейса запросов ;

– количество правил, по которым информация из рабочих систем переносится в промежуточную область;

– количество правил, по которым информация из внешних систем переносится в промежуточную область;

– количество правил, по которым информация из промежуточной области переносится в общее ХД;

– количество правил, по которым информация из ХД переносится в зависимые тематические хранилища;

– количество пользователей общего ХД и зависимых тематических хранилищ;

– множество всех отношений промежуточной области;

– множество всех отношений, составляющих общее ХД;

– множество всех рабочих систем;

– множество всех внешних источников;

– множество всех зависимых ХД;

– множество всех пользователей;

– множество функций, являющееся интерпретацией интерфейса управления запросами.

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

Список сопоставлений представляет собой отношение, содержащее следующие сведения:

  1. код подсистемы;

  2. наименование сведения;

  3. наименование отношения, в котором содержится данное сведение;

  4. наименование атрибута отношения;

  5. тип атрибута.

В списке сопоставлений метаданные описываются терминами, понятными конечным пользователям. Поэтому у пользователей-аналитиков складывается впечатление о создании запросов именно в терминах и им не известно о существовании таких преобразований, как «Термины» «Метаданные» (или «Метаданные» «Термины»), производимых для формирования SQL-команд (или последующего вывода результатов). Поддержку актуальности списка сопоставлений должны осуществлять администраторы хранилища данных.

Для создания математической модели работы интерфейса запросов введём следующие обозначения:

– количество всех пользователей, работающих с интерфейсом управления запросами;

– количество всех подсистем, сведения о которых имеются в интерфейсе запросов;

– количество всех сведений, доступных из интерфейса управления запросами для -й подсистемы;

– множество всех реализованных для интерфейса запросов подсистем;

– множество всех пользователей;

– множество всех сведений, доступных из интерфейса запросов для -й подсистемы;

– множество всех сведений, доступных из интерфейса управления запросами;

– множество всех операций (запросов) пользователей к интерфейсу запросов, порождающее множество всех ответов ;

– количество всех возможных запросов, определённых над множеством всех отношений списка сопоставлений.

Считая, что преобразования «Термины» → «Метаданные» и «Метаданные» → «Термины» определены во множестве всех запросов , интерфейс запросов можно описать следующей системой:

(М.2)

, где ,

: , где , ,

, где – множество натуральных чисел.

Алгоритм работы интерфейса обработки запросов можно записать в виде следующей последовательности шагов:

Шаг 1. Получение информации от пользователей.

Шаг 2. Сопоставление информации, полученной в Шаге 1, со структурой отношений в хранилище в соответствии с имеющимися метаданными. Если поступившей информации и метаданных недостаточно для построения SQL-запроса, то возврат к Шагу 1, иначе – Шаг 3.

Шаг 3. Построение SQL-запроса для ХД и последующее его выполнение.

Шаг 4. Преобразование результата выполнения SQL-запроса к понятному пользователю виду.

Шаг 5. Вывод результатов запросов для принятия дальнейших решений.

На рис. 2 проиллюстрирована попытка получения информации о сумме платежа при помощи интерфейса управления запросами, зная только назначение платежного документа. Назначение платежного документа является единственным сравнительно произвольным полем для заполнения, поэтому этот атрибут не включен в перечень доступных сведений подсистемы «Межбанковские расчёты» интерфейса управления запросами.

Рис. 2. Попытка получения информации о сумме платежа при помощи интерфейса запросов, зная только назначение платежного документа



Литература:

  1. Спирли Э. Корпоративные хранилища данных: планирование, разработка, реализация Т.1- М.–С. Пб. – Киев: Издательский дом «Вильямс», 2001.

  2. Хоббс Л., Хилсон С., Лоуенд Ш. Oracle 9iR2: Разработка и эксплуатация хранилищ баз данных- М.: Кудиз-Образ, 2004.

  3. Шаша Д., Бонне Ф. Оптимизация баз данных: принципы, практика, решение проблем- М.: Кудиз-Образ, 2004.

  4. Кузьмин А.Н. Проблемы реляционных баз данных в банковских системах, математические модели хранилищ данных и параллельной загрузки, Препринт 06П1- Казань: Изд-во КГТУ им. А.Н. Туполева, 2006.

  5. Бусленко Н.П. Моделирование сложных систем- М.: Наука, 1978.

Похожие:

Трёхуровневая архитектура хранилища данных с интерфейсом запросов iconПроектирование архитектуры системы. Классическая трехуровневая архитектура
Типичная архитектура информационных систем, включающая интерфейс пользователя и хранение данных на постоянным носителем, называется...
Трёхуровневая архитектура хранилища данных с интерфейсом запросов iconМоделирование процессов обработки запросов к базе данных "библиотека" средствами теории масового обслуживания
Одной из задач при эксплуатации баз данных (БД) является настройка оборудования и соответствующего программного обеспечения, обеспечивающего...
Трёхуровневая архитектура хранилища данных с интерфейсом запросов iconГенералова бд
Трехуровневая система организации бд. Модели данных. Классификация моделей данных. Семантические модели данных. Модель полуструктурированных...
Трёхуровневая архитектура хранилища данных с интерфейсом запросов iconРазработка системы управления хранилищем динамических данных
Рассмотрены и протестированы существующие локальные системы хранения данных. Разработан прототип модуля менеджера хранилища данных...
Трёхуровневая архитектура хранилища данных с интерфейсом запросов iconОптимизация хранилища данных с представлением структуры в виде матроида средствами алгебры кортежей
Зачастую ошибки проектирования обнаруживаются только на этапе разработки или тестирования, однако часть ошибок можно обнаружить и...
Трёхуровневая архитектура хранилища данных с интерфейсом запросов iconНаучная работа по информатике «Использование баз данных и субд для обработки экономической информации»
В состав банка данных входят одна или несколько баз данных, справочник баз данных, субд, а также библиотеки запросов и прикладных...
Трёхуровневая архитектура хранилища данных с интерфейсом запросов iconЯзык поисковых запросов
Язык запросов — это искусственный язык, на котором делаются запросы к базам данных и другим информационным системам, особенно к информационно-поисковым...
Трёхуровневая архитектура хранилища данных с интерфейсом запросов iconВопросы к государственному междисциплинарному экзамену по специальности 230101 «Вычислительные машины, комплексы, системы и сети» на 2011 год
База данных: понятие, уровни представления базы данных. Преимущества базы данных перед файловой организацией данных. Система управления...
Трёхуровневая архитектура хранилища данных с интерфейсом запросов iconОбразовательная программа по курсу: «Хранилища данных и информационно-аналитические системы»

Трёхуровневая архитектура хранилища данных с интерфейсом запросов iconСоздание запросов в субд access
Запрос — объект базы данных, используемый для выборки или модификации хранимых данных
Разместите кнопку на своём сайте:
ru.convdocs.org


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