Лекции - Корпоративные информационные системы и технологии

Подождите немного. Документ загружается.

Одна мощная универсальная ЭВМ была единственной платформой, выполняющей все

алгоритмы логики приложения (рис. 2). У централизованной архитектуры множество

достоинств: простая разработка приложений, легкость обслуживания и управления.

Именно они и обеспечили столь долгую жизнь «унаследованных» систем. Смерть

универсальных ЭВМ неоднократно провозглашалась после появления четырех- и

восьмиразрядных ПК в начале 80-х годов (компьютеры PET и VIC-20 компании

Commodore, TRS-80 компании Radio Shack и множество других машин на базе

процессоров Z-80, а также 6502 и 6800 производства Motorola). Однако они

продолжали работать, переваривая десятки миллионов транзакций в день,

приспосабливаясь к постоянно увеличивающимся нагрузкам.

Разделение файлов

Рис. 3. Архитектура разделения файлов

Едва появившись, ПК принесли ожидание того, что большое число маленьких машин

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

универсальную ЭВМ. Архитектура разделения файлов, ставшая первым шагом к

реализации этого притязания, включает множество настольных ПК и файловый сервер,

связанных сетью (рис. 3). Файловый сервер загружает файлы из разделяемого

местоположения, а прикладные программы исполняются полностью на настольных ПК.

Подобная архитектура была особенно популярна при использовании продуктов

наподобие dBASE, FoxPro и Clipper. Первоначально сети персональных компьютеров

были основаны на метафоре совместного использования файлов, потому что это было

просто. Однако она хорошо работала лишь в некоторых случаях. Во-первых, все

приложения должны вписаться в единственный ПК. Во-вторых, совместное

использование и конфликты обновления чрезвычайно снижают производительность.

Наконец, учитывая пропускную способность сети, объем данных, которые могут

передаваться, также невелик. Все эти факторы крайне ограничивают число

параллельных пользователей, которое способна поддерживать архитектура разделения

файлов [6-8].

2.3 Модель для моделирования приложений в информационных

системах

Разрабатывая новую основу для проектирования и построения приложений,

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

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

важность поддержки понимания архитектуры приложений на каждой стадии

обдумывания крупных приложений. Напоминание об этом уже было и до применения

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

Рис. 14.3 представляет трехслойную архитектуру приложения как трехстадийный

процесс – планирование, проектирование, разработка. Этот процесс концептуально

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

IE. Рассмотрим детально эти стадии, одну а одной:

• Концептуальная. Первой стадией в любом проекте является обзор

требований и разработка общего проекта. Это эквивалентно ранним

планам этажа, с множеством позиций от плана к плану, которые

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

документа этот проект рассматривает обширные потоки работ от офиса к

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

интерфейсов. На уровне процесса рассматриваются высокоуровневые

кружки и линии, которые вышестоящее руководство и консультанты по

Концептуальная Логическая Физическая

Документы Поток работ Поток форм Формы

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

Модель

компонентов

Программы

База данных Модель данных Схема БД

Таблицы,

индексы

Рис. 14.3. Этапы планирования, проектирования и

разработки приложений

управлению так любят рисовать. На уровне БД рассматривается

высокоуровневая, интегрированная основа предприятия и подразделений.

• Логическая. Данное проектирование принимает во внимание детальные

правила описания процесса и улучшает проект, показывая, как эти правила

можно приспособить. На уровне процесса высокоуровневые объекты

разбиваются на более детальные процессные действия и диаграммы

запрос/действие, которые показывают, как более крупные блоки работают.

На уровне рабочего стола должны быть смакетированы последователь-

ности спроектированных форм, показывающие точную последователь-

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

БД высокоуровневая модель приобретает вид системы логически

связанных реляционных таблиц с использованием программных триггеров

и хранимых процедур конкретной СУБД.

• Физическая. Представляет собой этап проектирования, на котором

логическая модель данных погружается в установленную СУБД на

конкретных программно-аппаратных средствах сервера БД, а приложение -

на рабочую станцию и (для трехуровневых приложений) сервер

приложений.

2.4 Сетевые базы данных. Основные функции СУБД

Основные концепции обработки сетевых баз данных в среде локальной

вычислительной сети сформировались в 1988-1989 гг. и заключаются в

следующем:

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

взаимодействия «рабочая станция – сервер». При этом база данных общего

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

(локальные) базы данных хранятся и обрабатываются локально на рабочих

станциях;

б) сетевые операции доступа к базе данных, обмена по сети фрагментами баз

данных, обеспечение надежности и целостности базы данных реализуется на

базе специального механизма транзакций и соответствующего протокола

выполнения транзакций;

в) стандартным средством обслуживания базы данных, доступа к ней и

получения результатов является SQL – стандартный реляционный язык

пользователя для взаимодействия с базой данных;

г) центральным исполнительным элементом сетевой базы данных является

SQL-сервер, реализующий высоконадежный протокол обработки

транзакций, сетевые операции доступа к базе данных и реляционный язык

запросов.

В результате применения этих концепций проектировщики

информационных систем получают в свое распоряжение новую архитектуру

распределенных информационных систем (РИС). Для современных систем

класса РИС характерными свойствами являются:

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

базами данных: а) возможность распределения баз данных между

файл-серверами; б) организация дублированных копий баз данных и

обеспечение высокой надежности хранения информации; в) широкие

возможности распределения рабочих станций между

производственными участками без изменений в архитектуре и

режимах использования РИС;

- высокий уровень средств пользователя (конечного пользователя,

администратора системы и оператора) при работе с базой данных: а)

язык запросов 4-го поколения (типа SQL); б) прозрачность доступа к

сетевой базе данных; в) системная поддержка целостности базы

данных, помехоустойчивости и высокой интегрированности узловых

фрагментов базы данных;

- высокий уровень развития инструментальных средств организации баз

данных и создания приложений: а) языки программирования высокого

уровня; б) словари/справочники данных; в) средства анализа

производительности и эффективности использования дискового

пространства.

Рассмотрим реализацию указанных концепций и свойств в совместном

проекте фирм Ashton-Tate, Microsoft and Sybase – системе SQL Server.

SQL-Server

Данная система относится к классу реляционных СУБД, обеспечивающих

многопользовательскую обработку распределенной базы данных. База данных

функционирует в среде локальной сети ПЭВМ под управлением Oracle,

Informix,OS/2 или MS SQL-server.

SQL-server основан на архитектуре «клиент – сервер», в которой могут

поддерживаться «фронтальные» буфер-процессоры для различных

пользовательских СУБД, табличных процессоров и расчетных программ.

Фронтальные процессоры – это прикладные программы, действующие на

стороне пользователя, т.е. отвечающие за функции клиента в модели «клиент –

сервер».

Фронтальные процессоры действуют, как правило, на рабочих станциях и

манипулируют локальными данными. Вторую компоненту базовой модели

«клиент – сервер» реализует процессор заднего плана (back-end), т.е. компонент

в модели «клиент – сервер».

В рекламных материалах по SQL-server объявляется, что совместно с SQL-

server могут работать такие известные системы как Paradox, DataEase,

DB/ACCESS, Lotus 1-2-3, MDBS, OpenAccess, Clipper и др. Доступ к различным

прикладным системам осуществляется при помощи SQL-языка, средствами

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

данными. В отличие от обычных файл-серверов SQL-сервер выполняет

детальный поиск данных, сортировку, арифметическую обработку и полный

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

трафик по пересылке наборов данных между сервером и рабочей станцией.

Еще одно преимущество SQL-сервера связано с возможностью реализации

нескольких серверов баз данных на одной локальной сети. Благодаря этому все

базы данных и отдельные базы могут быть дублированы на нескольких файл-

серверах. Таким образом, повышается общая надежность сетевой базы или

реализуются специальные технологии обслуживания базы данных.

2.5 Понятие транзакции. Механизм транзакций в СУБД

Значительные достоинства сетевых баз данных связаны, прежде всего, с

высоким уровнем стандартизации основных архитектурных решений и

технологий. Проектировщики сетевых баз данных освобождаются от

необходимости решать многие задачи структурно-функционального характера:

выбор соотношений между центральными и локальными операциями обработки

баз данных, синхронизация распределенных процессов обработки данных,

защита данных и поддержка целостности данных, организации коммуникаций в

локальной сети и т.п. Это означает, что при проектировании сетевой базы

данных проектировщик может больше внимания уделять прикладным вопросам

представления информации в базе данных, технологии решения прикладных

задач, вопрос организации эффективного сервиса для конечных потребителей.

Например, главными сетевыми стандартами баз данных в среде NetWare

являются: а) файловая система, механизмы защиты данных, управление

многопользовательским доступом и протоколы передачи данных – собственные

механизмы операционной системы NetWare; б) единая архитектура сетевых

взаимодействий на базе модели «клиент – сервер»; в) стандартный серверный

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

стандартный язык SQL; г) стандартный механизм обработки транзакций.

Аналогичным образом построены другие сетевые системы, которые

используют ОС типа UNIX, Linux, Windows с такими механизмами, как

обработка процессов, *.dll-библиотеки, Registry.

Таким образом, механизм транзакций – это общий метод сетевого

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

может быть определена на уровне SQL-команд, например, в виде некоторой

цепочки SQL-команд по доступу к базе данных, чтению определенных записей

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

транзакции (т.е. всех входящих в нее операций) от начала до конца. Если после

выполнения транзакции возникают сбои (отказы) или тупиковые ситуации, то

транзакция «откатывается» назад и состояние базы данных не меняется.

Возможности администратора баз данных

Администратор сетевой базы данных отвечает за ее общую доступность,

целостность и сохранность информации. При этом важно обеспечить такие

режимы административного обслуживания базы данных, которые в

минимальной степени затрудняют или прерывают работу пользователей и

разработчиков.

Серверы баз данных реализуют эти требования на основе ряда новых

концепций:

Динамическое архивирование данных. Архивные копии базы данных

создаются без приостановки обработки текущей базы. Команды типа DUMP

DATABASE воспринимается SQL-сервером и реализует мгновенную

«фотографию» базы данных.

Автоматическое восстановление баз данных. В случае серьезного

физического сбоя или отказа аппаратуры база данных восстанавливается на

основе последней копии и журнала базы данных. SQL-сервер реализует

автоматическое восстановление информации (автоматическое восстановление

также выполняется при каждом запуске SQL-сервера).

Мониторинг и управление работой SQL-сервера. Администратор

использует различные утилиты, а также специальные команды SQL для

создания групп пользователей, назначения паролей доступа, измерения

активности использования ресурсов и выбора опций и параметров обработки

баз данных.

Обеспечение защиты данных. Администратор имеет средства контроля

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

т.п.). Вся информация, контролирующая доступ, хранится в он-лайн

словаре/справочнике данных. Фактически эти средства расширяют аналогичные

«штатные» возможности NetWare, Ethernet, TolkenRing и др..

2.6 Многопользовательский доступ к СУБД

СУБД коллективного доступа осуществляют одновременный доступ многих

пользователей к данным в клиент-серверной архитектуре приложений с

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

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

Клиент СУБД. Специальная программа доступа к СУБД, использующая

"закрытый " интерфейс, через который (и только через него!) проходят SQL-запросы от

приложений к БД.

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

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

статус и может быть открыт другими станциями, желающими вступить во

взаимодействие. Каждая станция может организовать очередь сообщений для обмена

через пайп (до 6 сообщений). Потоковый обмен ведется по запросу принимающей

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

в любой момент времени.

Семафоры. Обеспечивают механизмы синхронизации процессов. Семафоры

создаются и обслуживаются файл-серверами и поэтому доступны для каждой рабочей

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

файлам, управления вызовом программ, контроля выполнения различных процессов в

сети. Семафоры – это именованные объекты, которые открываются и закрываются со

стороны рабочей станции. К уже открытым семафорам могут иметь доступ другие

станции, которые обращаются к семафору только по имени.

Семафоры – это универсальный и исключительно гибкий механизм для

управления работой распределенных сетевых процессов.

Интеграция системных и прикладных программ

Прикладные программы (помещаемые в среду NetWare, Ethernet, TаlkenRing и

др.), в архитектуре "клиент-сервер" могут иметь ряд свойств, которые необходимо

поддерживать (обслуживать) средствами сетевых управляющих программ. К таким

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

прикладная программа разделяемые данные; в) есть ли данные, которые не должны

быть доступны другим программам.

Например, NetWare обеспечивает интеграцию прикладных программ и поддержку

различных свойств на уровне системного супервизора. Пользователь может в

программе установки снабдить супервизор установочными параметрами: директориями

и параметрами доступа к файлам, именами групп пользователей файлов и их

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

супервизора как единого координирующего и управляющего механизма. При этом

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

NetWare или разрабатывать свой «прикладной» супервизор. Предпочтительным

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

стандартном сервисе NetWare.

В состав системного сервиса входят: а) средства программирования на языке

высокого уровня; б) системные диагностические сообщения; в) системные утилиты; г)

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

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

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

прикладная программа взаимодействует с таблицами и сообщениями супервизора,

анализирует операционную среду, выдает пользователям только определенные

диагностические сообщения. На уровне командного файла формируются обращения

прикладной программы к системным утилитам и специальным контрольным

операциям.

Полный перечень современных технологий интеграции в современных

корпоративных сетях описан в разделе 3.4 Конспекта.