Клиент-серверная архитектура

Ознакомление с понятием клиент-серверной архитектуры. Рассмотрение структуры локальной вычислительной сети. Характеристика особенностей репликации данных. Анализ операций, которые составляют процесс проектирования базы данных в клиент-серверной среде.

Рубрика Программирование, компьютеры и кибернетика
Вид шпаргалка
Язык русский
Дата добавления 25.04.2016
Размер файла 1,4 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

1. Что понимается под клиент-серверной архитектурой? Что такое сервер и клиент

Под сервером обычно понимают процесс, который обслуживает информационную потребность клиента. В различных архитектурах в качестве процесса может быть поиск или обновление в базе данных, и тогда сервер называется сервером базы данных, или процесс может выполнять некоторая процедура обработки данных, и тогда сервер называется сервером приложения. Клиентом является приложение, посылающее запрос на обслуживание сервером. Задачей клиента являются инициирование связи с сервером, определение вида запроса на обслуживание, получение от сервера результата обслуживания, подтверждение окончания обслуживания.

Клиент-серверная архитектура реализует многопользовательский режим работы и является распределенной, когда клиенты и серверы располагаются на разных узлах локальной или глобальной вычислительной сети.

Рис. 1. Структура локальной вычислительной сети

2. Какие существуют уровни представления клиент-серверной архитектуры

В общем случае схема клиент-серверной архитектуры включает три уровня представления: уровень представления (презентации) данных пользователем; уровень обработки данных приложением и уровень взаимодействия с базой данных.

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

3. Какие существуют варианты клиент-серверной архитектуры

Клиент-серверная архитектура в вычислительной сети может быть реализована по-разному. Выбор конкретной схемы определяется различными вариантами территориального распределения удаленных подразделений предприятия, требованиями эксплуатационной надежности, быстродействием, простотой обслуживания. Рассмотрим различные схемы клиент-серверной архитектуры (рис.2).

Рис. 2. Варианты клиент-серверной архитектуры КЭИС

4. Какие преимущества обеспечивает клиент-серверная архитектура

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

5. Что такое репликация данных и какие существуют режимы ее осуществления

Для сокращения объема передачи данных по каналам связи в распределенной информационной системе предлагается репликация данных, то есть тиражирование данных на взаимодействующих серверах баз данных с автоматическим поддержанием соответствия копий данных. При этом возможны следующие режимы репликации:

· синхронный режим, когда тиражируемые данные обновляются по мере возникновения необходимости одновременно на серверах баз данных во всех копиях. Требуемое быстродействие каналов для синхронного режима - единицы Мбит в секунду;

· асинхронный режим, когда тиражирование данных выполняется в строго определенные моменты времени, например каждый час работы информационной системы. Требуемое быстродействие каналов для асинхронного режима - единицы Кбит в секунду. Асинхронный режим может вызывать откладывание выполнения транзакций до момента обновления данных.

6. Какие операции выполняются на стадии техно-рабочего проектирования клиент-серверной архитектуры

Рассмотрим технологическую сеть техно-рабочего проектирования трехуровневой клиент-серверной КЭИС (рис. 3).

Разработка общей структуры корпоративной информационной системы (П1)

Эта операция выполняется на основе описания предметной области D1 и технического задания D4, а также универсумов сетевых операционных систем и технических платформ (U1), серверов БД (U2), программных средств разработки КЭИС (U3). Выходом данной технологической операции служат описание выбранной конфигурации технических средств и сетевой операционной системы D3, описание выбранного сервера БД - D2, описание выбранных программных средств разработки КЭИС -D5, описание функциональной структуры КЭИС - D6.

Рис.3. Технологическая сеть техно-рабочего проектирования трехуровневой клиент-серверной КЭИС

7. Какие операции включает проектирование базы данных в клиент-серверной среде

Разработка управляющих элементов G5, к которым относятся хранимые процедуры и триггеры, осуществляется на основе структуры базы данных D7 с учетом ее SQL-описания БД G4 и возможностей средств СУБД сервера БД G2. В результате получается готовая для эксплуатации схема базы данных с управляющими элементами, которая документируется в D10.

Рис.4.Технологическая сеть проектирования базы данных в клиент-серверной среде:

Хранимая процедура представляет собой вариант программного наполнения базы данных, основная функция которой -функциональное расширение схемы БД. Хранимая процедура выполняет то или иное логическое действие. Например, администратор банковской системы создает хранимую процедуру, которая реализует функцию «занести на счет номер X сумму Y». серверный репликация вычислительный сеть

Разработчик приложения пользуется этой процедурой, но не знает, как именно она работает. Это дает следующие преимущества:

· когда меняется алгоритм данного действия, то администратор меняет только эту хранимую процедуру и все приложения сразу начинают работать по-новому;

· независимо от типа рабочего места, использующего хранимую процедуру, одно и то же действие выполняется одинаково, что повышает надежность разработанной системы;

· хранимая процедура пишется одним человеком, а используется многими, следовательно, повышаются темпы разработки КЭИС;

· повышается скорость обработки запросов пользователей за счет того, что действия по анализу хранимой процедуры выполняются единожды при определении этой процедуры.

Триггер БД - это механизм «событие - действие», который автоматически выполняет некоторый набор SQL-операторов, когда происходит некоторое событие. Событиями, на которые можно установить триггер, являются модификации данных. Причем триггер связан с конкретной таблицей БД. Триггер хранится как объект в базе данных. Создание триггеров позволяет установить правила обеспечения ссылочной целостности сервера БД.

8. Что представляет собой система оперативной обработки транзакций (OLTP-система)

Проектирование систем оперативной обработки транзакций

Клиент-серверная архитектура КЭИС упрощает взаимодействие пользователей с информационной системой и между собой в процессе выполнения деловых процессов или длинных транзакций. Под длинной транзакцией будем понимать совокупность операций делового процесса, требующих обращения к КЭИС, каждая из которых не имеет ценности без выполнения всей совокупности. Под короткой транзакцией или просто транзакцией будем понимать отдельное обращение к одному из компонентов КЭИС или обращение клиента к серверу. С помощью обработки длинных транзакций КЭИС позволяет управлять достаточно сложными цепочками операций делового процесса как единым целым. Такие информационные системы называют системами оперативной обработки транзакций (OLTP - OnLine Transaction Processing).

Основой современных систем оперативной обработки транзакций является управление рабочими потоками (workflow), в которых пользователи-клиенты взаимодействуют между собой и со множеством программных приложений через специальную управляющую программу. Системы оперативной обработки транзакций могут распространяться и на межорганизационное взаимодействие предприятий с помощью специально разработанных Интернет-приложений в глобальной вычислительной сети.

9. Каковы особенности создания систем управления рабочими потоками

Основными особенностями системы управления рабочими потоками являются:

· наличие программы-менеджера рабочего потока, управляющей переходами между шагами задания и документирующей исполняемые процессы;

· поддержка маршрутной карты предприятия, определяющей схему прохождения работ в деловом процессе;

Рис. 5. Многоуровневая клиент-серверная архитектура на основе использования СУРП

· обеспечение выбора исполнителей процессов по модели организационной структуры предприятия;

· обработка событий: временных (deadline) и завершения операций, условий (триггеров) подключения процессов; наличие средств электронной почты для обмена сообщениями между исполнителями и передача списка заданий от руководителей;

· автоматический контроль исполнения работ и информирование руководителей;

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

· открытые интерфейсы с внутренними и внешними приложениями, подключение транзакций по Интернету;

· сбор статистики о выполнении деловых процессов;

· подключение стандартных процедур и шаблонов оформления документов.

Центральным компонентом СУРП является менеджер рабочих потоков, который выполняет следующие функции:

· создание шагов задания;

· оценку условий выполнения шага заданий;

· обработку возникающих событий и принятие решений по сообщениям;

· контроль сроков выполнения шагов заданий (события по таймеру);

· передачу управления между приложениями;

· синхронизацию несколько одновременно выполняющихся процессов;

· распределение результатов выполнения шага задания по получателям;

· ведение журнала операций.

10. Каковы особенности создания Интернет-приложений

Использование Интернет-приложений

Многоуровневая клиент-серверная архитектура распространяется на Интернет-приложения, связывающие множество участников делового процесса, территориально удаленных друг от друга в рамках как одного, так и нескольких предприятий на основе применения сетевого протокола TCP/IP. Эти приложения разрабатываются для таких предметных областей, как управление финансами, логистикой, персоналом, учет и отчетность и др. Достоинство распределенных приложений заключается в устранении промежуточных звеньев делового процесса, когда пользователь, минуя обращения к тому или иному подразделению предприятия, напрямую обращается к информационной системе для выполнения требуемой функции. Причем обращение может быть выполнено из любого места, в любой день и в любое время суток в удобной для пользователя форме, используя обычную программу навигации (браузер) и мультимедийное представление информации в Интернете.

Типичными Интернет-приложениями являются:

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

· «предприятие - предприятие», осуществление сделок закупки-продажи товаров, выполнение совместных проектов. В первом случае между предприятиями осуществляется обмен документов: договоров, заказов, счетов, накладных, платежных поручений. Причем в отличие от традиционного электронного обмена данными (EDI - Electronic Data Interchange) возможна такая синхронизация транзакций, что два деловых процесса закупки и продажи по сути сливаются в один общий процесс. В случае осуществления проектов взаимная деятельность предприятий расширяется до проектирования изделий и планирования производства и образования совместных виртуальных предприятий. При этом обычно используется международный стандарт для обмена данными по моделям продукции STEP (Standard for the Exchange of Product model data);

· «работник (подразделение) - работник (подразделение)», приложения Интранета предполагают применение технологии Интернета для связи между сотрудниками одного предприятия. При этом используются описанные выше системы управления рабочими потоками.

В корпоративной информационной системе R/3 (SAP) для реализации распределенных деловых процессов с помощью Интернет-приложений разработан специальный механизм Application Link Enabling (ALE), с помощью которого свободно связываются друг с другом программные компоненты, относящиеся к различным информационным системам. В частности, для взаимодействия программных компонентов предлагается использовать стандартные интерфейсы BAPI (Business Application Programming Interface). Подробнее использование интерфейсов BAPI будет рассмотрено в п. 14,3. В системе R/3 в настоящее время разработано более 25 Интернет-приложений и более 100 BAPI интерфейсов к ним.

11. Что представляет собой система оперативного анализа данных (OLAP-система)

Проектирование систем оперативного анализа данных

Современные системы поддержки принятия решений и информационные системы руководителей основаны на применении специализированных информационных хранилищ (ИХ) и технологий оперативного анализа данных (ОLAP) .

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

Рис. 6. Многоуровневая клиент-серверная архитектура для Интернет-приложений в системе R/3

12. Каковы особенности организации информации в информационных хранилищах

К особенностям хранимой информации в ИХ относятся:

· интеграция или обобщение данных в ИХ из транзакционных баз данных по всем бизнес-процессам и структурным подразделениям предприятия в виде единого многомерного информационного пространства. Например, организуется хранение показателей объемов производства, сбыта, сервиса и т.д. в продуктовом, территориальном, отраслевом, временном и других разрезах;

· произвольность агрегации данных на основе отделения от фактических данных независимых и равноправных измерений информационного пространства (признаков анализа информации, разрезов) в виде иерархий агрегации. Например, региональный признак анализа представляется в виде иерархии агрегации: «область - район - город - село», временной признак «год - квартал - месяц - день» и т.д.;

· обязательное хранение временного признака в данных, дающего возможность отслеживать динамику изменения показателей в течение длительного периода времени;

· непротиворечивость данных во всех используемых источниках в течение определенного периода времени (например, дня), которая позволяет обеспечить единую точку зрения всех пользователей на экономическую систему;

· обеспечение множества представлений структуры информационного хранилища для различных категорий пользователей: руководителей, аналитиков, менеджеров направлений деятельности. Отбор набора показателей и признаков анализа определяет предметную ориентированность информационного хранилища или организацию витрин данных.

13. Какие требования предъявляются к архитектуре информационных хранилищ

С технологической точки зрения к архитектуре ИХ предъявляются общие требования [104 ].

· Единообразно определенная структура многомерных данных с равноправными измерениями информационного пространства.

· Пользователь не должен знать о том, где хранятся данные, как они организованы и как обрабатываются.

· Поддержка многопользовательского режима оперативного анализа в среде «клиент-сервер».

· Легкая адаптация к новым информационным потребностям путем добавления новых показателей и измерений.

· Автоматическое обновление информации из оперативных баз данных.

· Выполнение запросов без ограничений на количество измерений и уровней их агрегации примерно с одинаковым временем реакции на запрос.

· Удобный, «интуитивный» интерфейс пользователя, обеспечивающий простоту манипулирования данными.

Архитектура системы оперативного анализа данных представлена на рис. 8.

14. Каковы основные компоненты архитектуры информационного хранилища

Рассмотрим состав основных подсистем информационного хранилища.

Подсистема хранения данных

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

· физической структуры, называемой MOLAP (Multidimensional OLAP), в которую с определенной периодичностью загружаются данные из файлов-источников, принадлежащих базам оперативных данных (например, один раз в день). Типичным инструментальным средством, поддерживающим MOLAP, являются Oracle Express (Oracle), Power Play (Cognos Corp), DataDirect (INTERSOLV);

Рис. 8. Архитектура информационного хранилища

· виртуальной структуры, называемой ROLAP (Relational OLAP), которая динамически используется при запросах, вызывающих физическое манипулирование с файлами-источниками из реляционных баз оперативных данных (формирование ответа на запрос к ИХ «на лету»). ROLAP-система рассматривается просто как надстройка над реляционными базами данных, обеспечивающая удобный интерфейс пользователя. Типичными инструментальными средствами, поддерживающими ROLAP, являются MetaCube (Informix), Business-Objects (BusinessObjects) и др.;

· o гибридной структуры, называемой HOLAP (Hybrid OLAP), которая используется при построении многоуровневых информационных хранилищ, применяемых на разных уровнях управления больших корпораций. Типичным инструментальным средством, поддерживающим HOLAP, является SAS System (SAS Institute).

Подсистема метаинформации (репозиторий)

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

Важнейшей функцией репозитория является представление схем отображения структуры данных файлов-источников на структуре данных ИХ, в соответствии с которой осуществляется периодическая загрузка MOLAP-хранилища или непосредственная реализация запросов «на лету» в ROLAP-хранилищах.

В репозиторий задается также схема отображения структуры ИХ на схемах представлений данных пользователей или витринах данных. Через репозиторий осуществляется интерпретация запросов к ИХ на проведение оперативного анализа данных.

Отображение данных между источниками данных и ИХ, ИХ и представлением данных осуществляется либо через механизм межуровневого взаимодействия, либо через процедуры преобразования данных.

Подсистема преобразования данных (загрузки хранилища)

Подсистема загрузки ИХ создается только для MOLAP-систем. Для ROLAP-систем в процессе выполнения запросов осуществляется преобразование данных из файлов-источников. В том и другом случае требуется выполнение следующих основных функций:

· сбор данных (Data Acquisition);

· очистка данных (Data Cleaning);

· агрегирование данных (Data Consolidation).

Сбор данных предполагает передачу данных из источников в ИХ в соответствии со схемой отображения, представленной в репозиторий.

В процессе очистки данных осуществляются проверка непротиворечивости (целостности), исключение дублирования данных, отбраковка шумовых (случайных) данных, восстановление отсутствующих данных, приведение данных к единому формату.

В случае необходимости агрегирования данных осуществляется суммирование итогов по заданным в репозитории признакам агрегации.

Подсистема представления данных (организации витрин данных)

Под витриной данных (Data Mart) понимается предметно-ориентированное хранилище, как правило, агрегированной информации, предназначенное для использования группой пользователей обычно из 10 - 15 человек в рамках конкретного вида деятельности предприятия, например маркетинга, инжиниринга, финансового менеджмента и т.д.

Как правило, витрины данных являются подмножествами общего хранилища компании, которое служит для них источником. В принципе витрины данных могут создаваться независимо друг от друга и общего хранилища, однако в этом случае возникает проблема согласования множества представлений данных. Обычно общее информационное хранилище и витрины данных разрабатываются параллельно.

Подсистема оперативного анализа данных

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

В рамках пользовательского интерфейса для оперативного анализа данных используются следующие базовые операции.

· Поворот. Добавление нового признака анализа.

· Проекция. Выборка подмножества по задаваемой совокупности измерений. При этом значения в ячейках, лежащих на оси проекции, суммируются.

· Раскрытие (drill-down). Осуществляется декомпозиция признака агрегации на компоненты, например, признак года разбивается на кварталы. При этом автоматически детализируются числовые показатели.

· Свертка (roll-up/drill-up). Операция, обратная раскрытию. При этом значения детальных показателей суммируются в агрегируемый показатель.

· Сечение (slice-and-dice). Выделение подмножества данных по конкретным значениям одного или нескольких измерений.

Подсистема интеллектуального анализа данных (извлечения знаний)

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

Типичными задачами интеллектуального анализа данных являются:

· установление корреляций, причинно-следственных связей и временных связей событий, например определение местоположения прибыльных предприятий;

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

· прогнозирование развития ситуаций, например прогнозирование цен, объемов продаж, производства.

К основным методам интеллектуального анализа данных относятся:

· методы многомерного статистического анализа;

· индуктивные методы построения деревьев решений;

· нейронные сети.

Подсистема «Информационная система руководителя»

Информационная система руководителя предназначена для лиц, непосредственно принимающих решения. Поэтому интерфейс таких систем должен быть в наибольшей степени упрощенным. Обычно в качестве интерфейса руководителям предприятий предлагается набор стандартных отчетов и графиков, настраиваемых на потребности руководителя через систему меню. Часто в качестве интерфейса предлагаются диаграммы Ишикава («скелета рыбы»), представляющие собой саморазворачивающееся дерево показателей, в котором листья ветвей раскрашиваются в разные цвета, символизирующие характер состояния показателя (нормальный, тревожный, кризисный). Лист любой ветви дерева показателей может быть развернут в таблицу значений показателя или график. Подобные диаграммы применяются в таких корпоративных ЭИС, как R/3 и BAANIV.

Подсистема WEB-публикации. Подсистема WEB-публикации предполагает преобразование полученной из ИХ информации в HTML-вид, доступный для ее просмотра удаленными клиентами с помощью широко распространенных броузеров Интернета.

15. Каковы основные технологические операции проектирования информационного хранилища

Технология проектирования ИХ

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

П1. Идентификация проблемной области

На основе материалов предпроектного обследования (Д1) осуществляется параметризация проекта создания информационного хранилища и выделяются все необходимые материальные, финансовые, людские и временные ресурсы на выполнение проектных работ, т.е. составляются техническое задание (Д2) и технико-экономическое обоснование проекта (ДЗ). В частности, в рамках технического задания в разрезе конкретных видов деятельности или бизнес-процессов формулируются цели и задачи, области применения и пользователи ИХ, устанавливаются источники исходных данных, определяются информационные потребности пользователей.

Цели и задачи. Цели построения информационного хранилища во многом определяют характер используемых источников данных, направлений и методов анализа извлекаемой информации. В качестве целей создания ИХ могут выступать:

· реинжиниринг и непрерывный инжиниринг процессов и структуры управления предприятием;

· повышение качества и оперативности обоснования управленческих решений на стратегическом, тактическом и оперативном уровнях;

Рис. 9. Технологическая сеть проектирования информационного хранилища

· упрощение управленческого документооборота для процесса принятия управленческих решений и др.

К важнейшим задачам, которые решаются с помощью ИХ, относятся:

· бизнес-планирование - обоснование принятия стратегических решений;

· контроллинг - анализ финансово-хозяйственной деятельности и выявление резервов совершенствования бизнес-процессов предприятия;

· оперативный мониторинг и сравнительный анализ (benchmarking) важнейших показателей деятельности предприятия.

Круг пользователей: руководители; референты руководителей, подготавливающие информацию для принятия решений; менеджеры функциональных подразделений; аналитики.

Области применения: анализ и прогнозирование осуществления основных бизнес-процессов в разрезах типов клиентов, продуктов, используемых технологий, каналов распределения, направлений функциональной деятельности (продаж, производства, закупок, финансов, персонала) и др.

Перечень источников данных:

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

· внешние источники: официальные статистические данные о деятельности отрасли, смежных отраслях, состоянии финансов; нормативная государственная информация; маркетинговая информация о зондировании рынка, состоянии конкурентов; коммерческие базы данных специализированных компаний в области информационного бизнеса, например Reuters.

Для каждого источника данных определяются параметры: территориальное расположение, административное подчинение, периодичность обновления, конфиденциальность и достоверность хранимой информации, форматы данных и характеристики программно-технической среды, объемы данных.

Информационные потребности пользователей. Для обоснования информационных потребностей выполняется анализ функций работников в рамках конкретных видов деятельности (бизнес-процессов), например бизнес-планирования, бюджетирования, маркетинга и т.д. В результате выявляется перечень регламентированных информационно-справочных документов и предполагаемых направлений формирования произвольных запросов.

П2. Разработка концептуальной модели ИХ

Этап разработки концептуальной модели ИХ соответствует этапу логического проектирования, который выполняется на основе технического задания Д2 и технико-экономического обоснования ДЗ. На выходе этого этапа получаются логическая структура данных ИХ Д4, схема преобразования данных Д5, логическая структура данных витрин Д6 и схема представления данных Д7.

Проектирование логической структуры ИХ осуществляется на основе анализа статистики использования конкретных информационно-справочных документов в процессе решения основных задач принятия решений. В результате выполнения операции производятся:

· отбор признаков анализа;

· построение схем агрегации показателей;

· построение схем обобщения признаков;

· определение временного горизонта хранения показателей;

· отбор первичных и производных показателей для хранения;

· выбор типа логической структуры ИХ;

· распределение показателей по типам логической структуры.

Основными методами выполнения операции отбора и структуризации показателей и признаков являются матричные, графо-аналитические и тезаурусные методы, описанные в п. 4.1. В частности, большое значение имеет формирование объемно-частотных характеристик использования типов показателей и признаков их группировки в различных типах информационно-справочных запросов. На этой операции происходит также обобщение непосредственно сформулированных пользователями типов запросов к ИХ.

Сложность структуры данных показателей предопределяет выбор ее типа: «звезды» с однородной структурой признаков для всех показателей или «расширенной снежинки» с применением нескольких типов хранилищ показателей. В последнем случае осуществляется распределение показателей по типам хранилищ.

Проектирование процессов извлечения и схемы преобразования данных производится путем анализа выявленных на этапе идентификации проблемной области источников данных. На выходе операции формируется уточненный состав источников данных с определенными схемами фильтрации и агрегации данных для помещения в ИХ.

В частности, на этом этапе осуществляется анализ альтернативных источников данных, например выбор из числа коммерческих баз данных, а также устанавливаются схемы преобразований исходных данных в хранимые структуры ИХ. Сложность схем отображения источников данных в структуру хранилища предопределяет выбор типа ИХ: MOLAP, ROLAP, HOLAP.

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

Данная операция может предшествовать разработке структуры информационного хранилища, когда сначала создаются структуры витрин данных, например, по основным видам деятельности или структурным подразделениям, а затем эти структуры данных интегрируются в общую структуру ИХ.

В рамках логически спроектированных витрин данных осуществляется выбор методов анализа данных для конкретных категорий пользователей. В частности, выявляется потребность в применении определенных видов статистического и интеллектуального анализа данных.

ПЗ. Формализация ИХ

Этап формализации завершает техническое проектирование информационного хранилища. На основе спроектированной на предшествующей операции архитектуры ИХ (Д4 - Д6) и универсумов программно-технических средств (Ul - U2) осуществляется выбор схемы размещения ИХ в сетевой вычислительной среде (Д7) и программно-технических средств реализации ИХ (U3 - U4).

Выбор схемы размещения ИХ в сетевой вычислительной среде осуществляется в зависимости от выбранного типа организации и предполагает определение числа уровней хранения:

· структура данных реализована централизованно на одном MOLAP-сервере;

· структура данных распределена на нескольких серверах в соответствии с ROLAP-организацией;

· наиболее оперативные и агрегированные данные хранятся на быстродействующем MOLAP-сервере, а детальные данные в ROLAP-хранилище - на менее производительных серверах.

Определение требований к конфигурации и числа клиентских мест выполняется на основе структуры витрин данных, выявленных категорий пользователей и используемых методов интеллектуального анализа, которые в совокупности определяют требования подключения к OLAP-серверу. Для каждого пользователя устанавливаются права доступа к ИХ.

Выбор программно-технических средств ИХ (серверов, клиентских мест, телекоммуникационного оборудования, инструментальных программных средств) выполняется на основе требований к физической конфигурации системы в части объемов памяти, быстродействия, надежности и выбранной клиент-серверной архитектуры ИХ.

Расчет объемов ИХ осуществляется путем суммирования объемов хранимых данных на всех MOLAP-серверах с учетом необходимого индексирования (специальных индексирующих таблиц для доступа к основным данным), а также объемов метаинформации репозитория для MOLAP и ROLAP-организации. Объемы ИХ рассчитываются на текущий момент времени и на перспективу с учетом внедрения всех компонентов системы.

П4. Реализация проекта ИХ

Этап реализации проекта ИХ выполняется на основе выбранных программных (U3) и технических средств (U4), а также построенных на этапе концептуального моделирования компонентов ИХ (Д4 - Д6) и схемы размещения ИХ (Д7) путем наполнения репозитория (G1), настройки или программирования других инструментальных средств (G2), наполнения информационного хранилища для MOLAP-структуры (G3), создания проектной документации (Д8).

Наполнение репозитория ИХ осуществляется путем ввода определений:

· структуры ИХ, источников и витрин данных;

· правил ввода данных в ИХ из одного источника, из нескольких источников, при отсутствии данных;

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

· параметров использования методов интеллектуального анализа данных.

Разработка и отладка программных компонентов производятся в основном путем параметрической настройки ППП (см. гл. 14). В случае функциональной неполноты выбранного инструментального программного средства в части процедур начальной и периодической загрузки данных, а также процедур анализа данных выполняется программирование отдельных программных модулей.

Наполнение ИХ предполагает автоматическую загрузку информации из источников данных в ИХ с MOLAP-организацией, которая повторяется с заданной в репозитории периодичностью. Эта операция в последующем предполагает очистку ИХ от ненужных и устаревших данных; управление данными на различных уровнях хранения; автоматическое обновление агрегированных данных.

П5. Внедрение и опытная эксплуатация

Заключительный этап создания ИХ предполагает комплексное тестирование всех компонентов ИХ (Gl - G3) с исправлением всех возникающих ошибок (G4 - G6), последующим обучением пользователей и постоянным администрированием в соответствии с установленными правилами и документацией проекта (Д8).

Размещено на Allbest.ru


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.