42319

Информационные системы и системы управления базами данных

Лабораторная работа

Информатика, кибернетика и программирование

Информационные системы и системы управления базами данных Введение Информационные системы взаимодействия видов транспорта ИСВВТ отличаются от других информационных систем ИС в основном решаемыми задачами. Поэтому в основе любой из них лежит среда хранения обработки и доступа к данным база данных;  информационные системы ориентируются на конечного пользователя не обладающего высокой квалификацией в области применения вычислительной техники. Системы управленя базами данных Любая ИС оперирует информацией о той...

Русский

2013-10-29

2.77 MB

20 чел.

PAGE  16

EMBED Word.Document.8 \s

   Лабораторная работа № 1.

   «Информационные системы и

   системы управления базами данных»

   

Введение

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

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

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

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

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

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

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

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

 Указанные общие свойства определяют то, что неотъемлемой частью любой информационной системы является система управления базой даныых (СУБДDataBase Management System, DBMS). Тип используемой СУБД обычно определяется масштабом информационной системы. Малые информационные системы могут использовать локальные СУБД, в корпоративных же системах обычно используются мощные клиент-серверные СУБД.

1. Системы управленя базами данных

Любая ИС оперирует информацией о той или иной части реального мира - предметной области. Предметная область рассматривается как некоторая совокупность реальных объектов (сущностей) и связей между ними. Каждый объект обладает определенным набором свойств (атрибутов). Например,
в системе автоматизации бухгалтерии организации требуется хранить сведения о сущностях - ее сотрудниках. К признакам (атрибутам) сущностей, которые будут актуальны для этой информационной системы, можно отнести следующие: личный номер, имя сотрудника, его должность, стаж работы и т. д. Предметная область может включать не только физические объекты, но и сведения о процессах и абстракциях.

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

Предметная область ИС "материализуется" в форме хранимой в памяти компьютера структурированной совокупности данных, которая характеризует состав объектов предметной области, их свойства и взаимосвязи. Такое отражение предметной области принято называть базой данных (БД).

 Система управления базами данных (СУБД, DBMS - DataBase Management Systems) как раз и является тем специальным программным инструментарием, основным назначением которого является создание базы данных, поддержание ее в актуальном состоянии и обеспечение эффективного доступа пользователей и их приложений к содержащейся в ней информации.

В настоящее время широко распространены три вида СУБД.

 1). Реляционные СУБД. Наиболее часто использовались на Западе с середины 70-х до середины 90-х годов 20-го века. Основаны на реляционной модели представления данных, предложенной математиком Э.Коддом в июне 1970 года. Первостепенное значение в таких СУБД уделяется средствам эффективной организации данных и манипулирования ими. Кодд показал, что любое представление данных сводится к  совокупности двумерных (плоских) таблиц особого вида, известного в математике как отношение (relation, отсюда и название – реляционные базы данных). Соответственно, при занесении информации о сложном объекте реального мира в реляционную базу данных обязательна процедура декомпозиции данных о нём для того, чтобы разместить их в плоских таблицах БД.

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

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

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

Инструментами для создания приложений (программ), манипулирующих данными в реляционных СУБД, а также служащим для создания интерактивного интерфейса взаимодействия пользователя с базой данных являются процедурные языки программирования третьего уровня, основанные на принципе модульного программирования. К реляционным СУБД относятся ранние версии DB2 (IBM), Oracle (Oracle), MS SQL Server (Microsoft), Sybase поддерживающие архитектуру ИС клиент-сервер, а также Clipper, Clarion, FoxPro и т.п., поддерживающие файл-серверную архитектуру ИС. Клиент-серверные реляционные СУБД (DB2, Oracle, MS SQL Server, Sybase) с момента своего создания поддерживали специализированные для каждой СУБД языки запросов (SEQUEL, QBE, QUEL) делающие возможным доступ к информации, хранящейся в базе данных этих СУБД даже для не профессиональных пользователей. Позже, название языка запросов SEQUELStructure English Query Language (разработка IBM) трансформировалось в SQL (Structure Query Language), который и получил наибольшее распространение. В 1986 году он был принят в качестве стандарта ANSI языков реляционных баз данных.

 К основным достоинствам реляционного модели базы данных можно отнести:

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

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

 наличие простого и в то же время мощного математического аппарата, опирающегося главным

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

реляционного подхода к организации баз данных;

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

конкретной физической организации баз данных во внешней памяти (чего требовали ранние СУБД, основанные на иерархической модели представления данных).

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

2). Объектно-ориентированные СУБД. Появились в начале 90-х годов, когда объектно-ориентированное программирование фактически вытеснило модульное программирование.

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

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

 возможность разбить систему на совокупность независимых сущностей (объектов) и провести их

 строгую независимую спецификацию (в том числе и семантическую – смысловую);

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

 элементов объектного подхода как  наследование и полиморфизм;

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

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

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

 области реального мира моделируемой ею предментной области реального мира).

 Объектная модель данных более близка сущностям реального мира. Объекты можно сохранить и использовать непосредственно, не раскладывая их по таблицам. Типы данных определяются разработчиком и не ограничены набором предопределенных типов как в реляционных СУБД. Использование объектной модели представления данных (а значит объектно-ориентированных СУБД) наиболее подходит для ИС корпоративного уровня, разработка которых ведётся методами объектного проектирования. На сегодняшний день наиболее популярны такие объектно-ориентированные СУБД как ObjectStore, Objectivity, O2, Jasmin).

При проектировании ИС на основе объектно-ориентированных СУБД широко используется методология и комплекс инструментальных средств быстрой разработки приложений – RAD (Rapid Application Development). На методологии RAD мы останавливаться не будем [см. 1, стр.61]. С прикладной точки зрения RAD – это комплекс специальных инструментальных средств быстрой разработки информационных систем, позволяющих оперировать определённым набором графических объектов, функционально отображающих отдельные информационные компоненты приложений.

Технология RAD предполагает ипользование методов объектно-ориентированного проектирования. Применение этих методов позволяет преодолеть одну из главных трудностей, возникающих при разработке сложных систем — колоссальный разрыв между реальным миром (предметной областью описываемой проблемы) и имитирующей средой.

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

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

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

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

Инструментальные средства RAD обладают удобным графическим интерфейсом пользователя и позволяют на основе стандартных объектов формировать простые приложения без написания кода программы. Это является большим преимуществом RAD, так как в значительной степени сокращает рутинную работу по разработке интерфейсов пользователя (при использовании обычных средств разработка интерфейсов представляет собой достаточно трудоёмкую задачу, отнимающую много времени). Высокая скорость разработки интерфейсной части приложений позволяет быстро создавать прототипы и упрощает взаимодействие с конечными пользователями.

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

3). Объектно-реляционные СУБД. Несмотря на перечисленные выше достоинства реляционных и объектно-ориентированных СУБД, и тот и другой тип обладают рядом недостатков. Для реляционных СУБД – это прежде всего сложность работы со сложными структурами данных (или типами данных) и сложности с декомпозицией данных (свойств, абстрактных характеристик, процессов) сложных объектов и систем. Для объектно-ориентированных СУБД – это сложность создания моделей реальных объектов, адекватно отображающих состояния и поведение соответствующих им объектов реального мира во взаимосвязи с другими окружающими их объектами, охватываемыми  предметной областью  (особенно в плане развития и изменения этих объектов с течением времени).

В частности, поэтому, не смотря на все достоинства объектно-ориентированных СУБД, их использование далеко не всегда оправданно. Чаще всего декомпозиция данных объекта не вызывает
никаких проблем и вполне логична. В этом случае использование реляционной модели может быть более эффективно.

С целью взаимодополнения возможностей реляционной модели представления данных и методов объектно-ориентированного программирования (проектирования), ведущие производители реляционных СУБД IBM и Oracle доработали свои продукты (DB2 и Oracle соответственно), добавив объектную надстройку над реляционным ядром системы. Таким образом, работая с этими СУБД, пользователь фактически использует реляционную модель данных. В большинстве случаев это значительно упрощает процесс создания логической (формальной) модели объектов предметной области и их взаимодействия между собой. Но при разработке приложений, работающих с данными баз данных таких СУБД, а также (что, может быть важнее) при разработке интерактивного пользовательского интерфейса для этих приложений, используются методы объектно-ориентированного программирования. Это даёт нибольшую эффективность программирования приложений и интерфейса и позволяет автоматически получать оптимальный, наиболее эффективный двоичный код исполняемых файлов приложений. Такие гибридные объектно-реляционные СУБД являются в настоящее время наиболее популярными во всём мире, и большинство аналитиков считает, что они и останутся таковыми в видимой перспективе.

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

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

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

Среди универсальных систем визуального программирования сейчас наиболее распространены такие, как Borland Delphi, Borland C++ и Visual Basic. Универсальными они называются потому, что не ориентированы на разработку только приложений баз данных — с их помощью могут быть разработаны приложения почти любого типа, в том числе и информационные приложения. Причём программы, разрабатываемые с помощью универсальных систем, могут взаимодействовать с базами данных практически любых реляционных и объектно-реляционных СУБД. Это обеспечивается как использованием драйверов ODBC или OLE DB (и то, и другое – разработка Microsoft), так и применением собственных специализированных средств (компонентов).

 Специализированные системы визуальной разработки ориентированы только на создание приложений баз данных. Причем, как правило, они привязаны ко вполне определенным системам управления базами данных. В качестве примера таких систем можно привести Power Builder фирмы Sybase (предназначенный для работы только с СУБД Sybase Anywhere Server) и Visual FoxPro фирмы Microsoft.

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

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

 Логика приложения, построенного с помощью RAD, является событийно-ориентированной. Это означает следующее: каждый объект, входящий в состав приложения, может генерировать события и реагировать на события, генерируемые другими объектами. Примерами событий могут быть: открытие и закрытие окон, нажатие кнопки, нажатие клавиши клавиатуры, движение мыши, изменение дан-
ных в базе данных и т. п.

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

Обработчики событий, связанных с управлением базой данных (DELETE, INSERT, UPDATE), могут реализовываться в виде триггеров на клиентском или серверном узле. Такие обработчики позволяют обеспечить ссылочную целостность базы данных при операциях удаления, вставки и обновления, а также автоматическую генерацию первичных ключей.

Системы визуальной разработки ИС на основе объектно-реляционных СУБД могут быть отнесены (с некоторыми существенными оговорками) к средствам CASE-технологии (Computer-Aided Software/System Engeneering), поскольку обычно к CASE-средствам относят любой программный продукт, автоматизирующий ту или иную совокупность процессов жизненного цикла программного обеспечения и обладающий следующими основными характерными особенностями [1, стр.156]:

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

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

 визуальной разработки графические средства описания и документирования ИС практически

 отсутствуют);

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

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

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

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

 сопровождение и реинжиниринг);

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

 (репозитория).

 Поскольку в настоящее время подавляющее большинство ИС во всём мире основаны на использовании объектно-реляционных (на Западе) и реляционных (пока ещё в России) СУБД, то в дальнейшем, будем рассматривать СУБД именно этих типов.

2. Информационные системы. Классификация информационных систем

Информационные системы могут классифицироваться по многим признакам. Рассмотрим наиболее важные с точки зрения данного практического курса способы классификации.

2.1.1 Классификация по масштабу

По масштабу информационные системы подразделяются на следующие группы (рис. 1):

 одиночные;

 групповые;

 корпоративные.

     Рис. 1. Деление информационных систем по масштабу

 Одиночные информационные системы

Одиночные информационные системы реализуются, как правило, на автономном персональном компьютере (компьютерная сеть в этом случае не используется). Такая система может содержать несколько приложений и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Приложения могут быть не связаны или связаны общим информационным фондом. То есть они могут работать либо каждое со своей базой данных (БД), недоступной другим приложениям, либо с одной и той же базой данных, доступной всем приложениям используемой в ИС СУБД, либо, работая каждое со своей БД, могут, при необходимости обращаться к БД других приложений, манипулируя с данными, хранящимися в них. Подобные приложения создаются с помощью так называемых настольных или локальных систем управления базами данных (СУБД). Среди локальных СУБД наиболее известными являются Clipper,  FoxPro, Paradox, Clarion, dBase и Microsoft Access.

Групповые информационные системы

Групповые информационные системы ориентированы на коллективное использование информации членами рабочей группы и чаще всего строятся на базе локальной вычислительной сети. При разработке таких систем до середины 90-х годов использовались локальные реляционные СУБД, работающие с файловыми серверами (файл-серверная архитектура ИС). В настоящее время для этого используются объектно-реляционные СУБД, работающие с серверами баз данных, называемыми  SQL-серверами (клиент-серверная архитектура ИС). Существует довольно большое количество таких СУБД (как коммерческих, так и свободно распространяемых), каждая из которых имеет и использует в работе свой собственный SQL-сервер. Среди них наиболее известны такие СУБД и, соответственно, SQL-серверы баз данных, как Oracle, DB2, Microsoft SQL Server, InterBase, Sybase, Informix. При правильной конфигурации и настройке такие системы могут успешно использоваться в качестве ИС малого и даже среднего по размеру предприятия.

Корпоративные информационные системы

Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. Строятся на основе локальных (на нижнем уровне), корпоративных и глобальных компьютерных сетей. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура клиент-сервер со специализацией серверов или же многоуровневая архитектура. Организация и работа таких систем построена на использовния тех же СУБД и серверов баз данных, работающих в архитектуре клиент-сервер, что и в групповых информационных системах. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и
Microsoft SQL Server.

 Для групповых и корпоративных систем существенно повышаются требования к надёжности работы и сохранности данных. Выполнение этих требований обычно обеспечивается механизмами поддержки категорийной целостности данных, ссылочной целостности и транзакций. В групповых ИС, основанных на использовании локальных СУБД (архитектура файл-сервер) задача создания таких механизмов и обеспечения их чёткого и безошибочного функционирования лежит на программисте - создателе приложений для таких ИС, поскольку эти механизмы отсутствуют в локальных СУБД. Степень сложности решения этой задачи нелинейно увеличивается с усложнением структуры ИС и уже для ИС малых предприятий она трудно разрешима.  Это является одним из основных препятствий для построения на базе локальных СУБД информационных систем уровня крупного предприятия, корпорации или ещё более высоких уровней сложности. В то же время механизмы поддержки целостности данных, ссылочной целостности, создания и управления транзакцями являются встроенными (внутренними) механизмами SQL-серверов (серверов баз данных) всех объектно-реляционных СУБД (архитектура клиент-сервер). Программисту – создателю приложений не надо даже задумываться над созданием таких механизмов и обеспеченем их нормальной работы. И это является одним из основных преимуществ современных объектно-реляционных СУБД над реляционными СУБД, дающее возможность относительно легко создавать на основе их использования ИС любого масштаба, от самых простых (локальных) до корпоративных (любого уровня сложности).

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

2.1.2 Классификация по сфере применения

По сфере применения ИС условно можно разделить на четыре группы (рис. 2):

 системы обработки транзакций;

 системы принятия решений;

 информационно-справочные системы;

 офисные информационные системы.

Рис. 2. Деление информационных систем по сфере применения

Системы обработки транзакций, в свою очередь, по оперативности обработки данных, разделяются на пакетные информационные системы и оперативные информационные системы. В информационных системах организационного управления преобладает режим оперативной обработки транзакций — OLTP (OnLine Transaction Processing), для отражения актуального состояния предметной области в любой момент времени, а пакетная обработка занимает весьма ограниченную часть.
Для систем
OLTP характерен регулярный (возможно, интенсивный) поток довольно простых транзакций, играющих роль заказов, платежей, запросов и т. п. Важными требованиями для них являются:

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

гарантированная доставка информации при удаленном доступе к БД по телекоммуникациям.

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

 Обширный класс информационно-справочных систем основан на гипертекстовых документах и мультимедиа. Наибольшее развитие такие информационные системы получили в сети Интернет.

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

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

 Информационные системы взаимодействия видов транспорта (ИСВВТ) как раз и являются такими сложными комбинированными ИС, которые, являясь по своей сути информационно-справочными, основываются на принципах офисных информационных систем,  работают в режиме OLTP (оперативной обработки транзакций), включают в себя элементы систем принятия решений (DSS) и достаточно широко используют средства Intranet (объекты и системы взаимодействия этих объектов, подобные аналогичным объектам в Internet, но в пределах конкретной ИС).

  1.  Классификация по способу организации

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

Таблица 1. Типовые функциональные компоненты информационной системы
Обозначение      Наименование         Характеристика

PS Presentation Services Обеспечиваются устройствами, принимающими ввод от

(средства пользователя и отображающими то, что сообщает ему

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

  соответствующей программной поддержки

PL Presentation Logic Управляет взаимодействием между пользователем

(логика и ЭВМ. Обрабатывает действия пользователя при выборе

представления) команды в меню, нажатии кнопки или выборе элемента

  из списка

BL Business Набор правил для принятия решений, вычислений

or Application Logic        и операций, которые должно выполнить приложение
(прикладная логика)

DL Data Logic (логика Операции с базой данных (SQL-операторы), которые

управления данными) нужно выполнить для реализации прикладной логики
управления данными

DS Data Services Действия СУБД, вызываемые для выполнения логики

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

  транзакций и т. п. СУБД обычно компилирует

  SQL-предложения

FS File Services Дисковые операции чтения и записи данных для СУБД

(файловые операции) и других компонентов. Обычно являются функциями
операционной системы (ОС)

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

 Одиночные информационные системы по способу организации могут быть выделены в отдельный класс автономных ИС. Реляционные СУБД, обычно используемые в таких системах, называются локальными или автономными (Clipper,  FoxPro, Paradox, Clarion, dBase, Microsoft Access). По аналогии, и базы данных этих СУБД в таких системах тоже называют локальными или автономными. В локальных ИС могут быть успешно использованы и не локальные по своей сути объектно-реляционные СУБД (такие как InterBase, VisualFoxPro и т.п), работающие в локальном режиме. Говорят, что в этом случае используется автономная архитектура ИС (автономная модель построения ИС). СУБД (любые) хранят данные в файлах своих баз данных локальной файловой системы того компьютера, на котором установлены. То есть система управления базами данных или машина баз данных (если она есть), осуществляющая доступ к этим данным, и все приложения ИС находятся на том же самом компьютере, на котором хранятся данные и с которым работает пользователь. Сеть не используется. Особенности доступа к данным в таких ИС были описаны выше (см. п.1.2.1, Одиночные ИС). Поэтому разработчику ИС или её приложения не приходится иметь дело с проблемой параллельного доступа, когда два человека пытаются одновременно изменить одну и ту же запись в какой либо базе данных. Все типовые функциональные компоненты автономной ИС реализуются на локальном компьютере, на котором эта ИС функционирует. В автономных ИС обычно нет приложений, требующих значительной вычислительной мощности, потому что значительная часть процессорного времени в них тратится на выполнение манипуляций с данными в базе данных и, в целом, теряется для приложения. Автономные ИС являются наиболее простыми информационными системами.

 

 Групповые и корпоративные информационные системы по способу организации подразделяются на следующие классы (рис.3):

 системы на основе архитектуры файл-сервер;

 системы на основе архитектуры клиент-сервер;

 системы на основе многоуровневой архитектуры;

 системы на основе Internet/Intranet-технологий.

 Рис. 3. Деление групповых и корпоративных информационных систем по способу организации

 Архитектура файл-сервер

Если ИС использует архитектуру файл-сервер то данные, хранящиеся в базе данных СУБД такой системы, могут быть доступны многим клиентам через вычислительную сеть, объединяющую множество компьютеров. Это очень удобно, так как изменения в такой базе данных видят все пользователи. Например, базу данных сотрудников крупного учреждения целесообразно делать именно такой, чтобы администраторы отдельных подразделений обращались к ней, а не заводили каждый свою локальную ИС.

ИС архитектуры файл-сервер традиционно создаются на основе использования локальных реляционных СУБД (Clipper,  FoxPro, Paradox, Clarion, dBase, Microsoft Access), хотя могут быть созданы и другими методами. Например, на основе использования машины баз данных (BDE) Delphi, находящейся на клиентской машине и базы данных какой-либо локальной СУБД, находящейся на файловом сервере сети (в этом случае используется подстановка - BDE выполняет на компьютере клиента функции локальной СУБД).

В файл-серверных ИС сама база данных в виде набора файлов в одном или нескольких каталогах хранится на одном из компьютеров сети, называемом в этом случае сетевым файловым сервером (или просто файл-сервером) в единственном экземпляре. Компьютеры пользователей ИС в этом случае называются клиентами. На каждом клиентском компьютере должна быть установлена копия локальной СУБД, используемой в ИС, которая реально работает с копией базы данных, физически находящейся на файловом сервере системы, считая, что файлы БД расположены на клиентском компьютере, и, не замечая того, что на самом деле – это копии реальных файлов базы данных системы, физически находящихся на винчестере файлового-сервера. То есть, для каждого клиента во время работы создается своя локальная копия данных имеющихся в БД на файловом сервере, с которой он и работает. Любые изменения данных в любой локальной копии БД на любой клиентской машине, влекут за собой изменение данных в реальной базе данных системы, находящейся на файловом сервере. При этом возникают (и должны быть решены создателем приложений такой ИС) проблемы, связанные с возможным одновременным доступом нескольких пользователей к одной и той же информации. Например, при проектировании приложений, работающих в таких ИС, программист должен самостоятельно решать такие проблемы: что делать, если пользователь прочёл некоторую запись и, пока он ее просматривает и собирается изменить, другой пользователь меняет или удаляет эту запись. Эти задачи решаются при помощи механизмов блокировок файлов баз данных и отдельных записей баз данных.

С точки зрения типовых  функциональных компонентов (см. табл. 1), ИС архитектуры файл-сервер не имеет сетевого разделения компонентов диалога PS и PL. Более того, на каждом клиентском компьютере реализуются и прикладная логика работающего приложения BL (бизнес-правила), и логика управления данными приложения DL, и операции с базой данных DS (в данном случае с клиентской копией базы данных), и логика представления PL, обеспечивающая средства представления PS, работающие на этом же клиентском компьютере необходимыми данными (что облегчает построение графического интерфейса). Файл-сервер только извлекает данные из файлов реальной базы данных, находящихся на его «винчестере» и перезаписывает эти файлы при изменении данных в клиентских копиях базы данных, то есть реализует функциональную компоненту FS (причём для этого автоматически используются ресурсы сетевой операционной системы, работающей на файловом сервере и никак не используются ресурсы СУБД и приложений ИС). Поэтому дополнительные пользователи и приложения добавляют лишь незначительную нагрузку на центральный процессор сети (файл-сервер). Каждый новый клиент добавляет вычислительную мощность к сети.

Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие программную подержку средств представления PS, логику диалога PL, а также логику обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля, либо в виде специального кода для интерпретации.

 Файл серверная технология хороша тем, что:

Структура приложений ИС файл-серверной архитектуры проста, поскольку все функции

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

запускаются (не надо думать над распределением этих функций между компьютерами сети,

в частности, между клиентами и сервером).

Отсутствие сетевого разделения компонентов диалога PS и PL существенно облегчает построение

графического интерактивного интерфейса взаимодействия пользователя и приложения ИС.

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

на файловом сервере, а с копиями БД на каждом клиентском компьютере, то вычислительная

мощность файл-сервера может быть относительно небольшой. (Например, если в сети работает не

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

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

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

Однако, файл-серверная архитектура имеет ряд существенных недостатков, которые обуславливают, особенно в последнее время, сокращение её применения при проектировании и создании ИС группового уровня и отказ от её использования в ИС корпоративного уровня. К этим недостаткам относятся:

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

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

записи, обновляются все записи данных локальной копии. Если записей в базе данных много, то

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

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

количества клиентов, работающих с базой данных, сетевой трафик резко возрастает, и легко может

произойти перегрузка сети, что влечёт за собой сбои, отказы и потерю данных. Естественно,

количество клиентов в такой сети невелико и равно, обычно, нескольким десяткам.

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

записей в базе данных, мощность файлового сервера (его быстродействие), мощность клиентских

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

 Одним из вариантов устранения данного недостатка является удаленное управление файл-серверными приложениями в сети. При этом  сервер сети, выполняет роль файлового сервера (как и в чистой архитектуре файл-сервер), то есть на его винчестере находится база данных ИС. Но, одновременно с этим на сервере работает программа, называемая телекоммуникационным сервером (или сервером доступа), в среде которого на сервере выполняются те приложения ИС, которые при чистой файл-серверной архитектуре выполнялись бы на компьютерах-клиентах и для каждого клиента системы работает своя копия локальной СУБД ИС. При этом сами клиентские приложения работают точно также, как если бы они работали  на компьютерах клиентах, не замечая того, что реально все они работают на сервере сети. В процессе их взаимодействия с базой данных точно также для каждого приложения создается своя копия базы данных и т.д. Говорят, что в программной среде такого сервера доступа эмулируется выполнение клиентских приложений. Особенность состоит в том, по линиям компьютерной сети сервер доступа передаёт и принимает только ту информацию, которая необходима для диалогового ввода-вывода на удалённых компьютерах клиентах. Сервер сети, поддерживающий такую ИС уже не является чистым файловым сервером, поскольку на нём не только хранятся данные (база данных ИС), но и реально выполняются приложения ИС. Поэтому он называется сервером приложений. Сетевой трафик при этом резко уменьшается (падает нагрузка на сеть), поскольку по линиям сети не надо постоянно перекачивать обновлённые копии базы данных для клиентов. Это даёт возможность использовать более дешёвые низкоскоростные сети (или, по меньшей мере, не менять имеющуюся сеть, даже при существенном росте количества информации в БД ИС и значительном росте количества пользователей). К тому же, на клиентских компьютерах в этом случае выполняются только функции ввода-вывода (PS), все остальные функциональные компоненты ИС, ранее выполняемые на клиентских компьютерах, теперь выполняются на сервере приложений. Это даёт возможность использовать в качестве копьютеров-клиентов маломощные недорогие компьютеры с ограниченным объёмом памяти, которые могут не иметь даже «винчестера». Однако, для того, чтобы сервер приложений мог нормально работать с достаточно большим количеством клиентов, приложения не должны быть слишком сложными, иначе велика вероятность перегрузки сервера, или же в качестве компьютера-сервера должен использоваться очень мощный аппаратный сервер, обладающий очень производительным процессором, огромной памятью и большим по объёму данных «винчестером» (нужна мощная аппаратная платформа для сервера приложений). Стоимость такого аппаратного сервера чрезвычайно высока и с лёгкостью может поглотить всю выгоду от экономии на сети и недрогих клиентских компьютерах. Именно поэтому, совокупная стоимость ИС с удалённым управлением приложениями при одинаковом (среднем) количестве клиентов сравнима со стоимостью ИС, имеющей обычную файл-серверную архитектуру, а при большом количестве клиентов, превышает её. Это существенно ограничивает сферу применеия ИС с удалённым управлением приложениями. Обычно такие ИС применяются там, где количество клиентов невелико и скорость обработки информации не является критическим фактором (не нужен мощный аппаратный сервер), либо там, где критическим фактором является пропускная способность сети или невозможна установка достаточно мощных компьютеров-клиентов, и имеется мощный аппаратный сервер (или есть возможность его приобретения).

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

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

Поскольку БД представляет собой набор файлов на сетевом сервере, доступ к таблицам

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

Недостаточно развитый аппарат транзакций локальных СУБД служит потенциальным источником

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

отката результатов серии объединенных по смыслу в единое целое операций над БД, когда

некоторые из них завершились успешно, а некоторые — нет. Это может нарушать ссылочную и

смысловую целостность БД.

Примечание: файл-серверная архитектура ИС привлекает своей простотой,

    доступностью, удобством использования, низкой стоимостью владения.

    Поэтому файл-серверные ИС до сих пор широко используются во всём

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

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

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

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

 Особенностью архитектуры клиент-сервер является использование выделенных  серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации. Сервер базы данных это программный сервер, являющий частью объектно-реляционной СУБД  устанавливаемой на аппаратном сервере сети во время инсталляции этой СУБД

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

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

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

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

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

Большинство конфигураций клиент-сервер использует так называемую двухуровневую модель (двухуровневую архитектуру клиент-сервер), в которой клиент обращается к услугам сервера базы данных. В классической двухуровневой модели компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PLони позволяют обеспечить графический интерфейс), логика BL и DL — на клиенте. Двухуровневое определение архитектуры клиент-сервер использует именно этот вариант: приложение работает у клиента, СУБД — на сервере (рис. 4.).

Рис. 4. Классический вариант двухуровневой клиент-серверной информационной системы

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

Для сокращения нагрузки на сеть и упрощения администрирования приложений
компоненты
BL и DL можно разместить на сервере. При этом вся логика принятия решений оформляется в виде хранимых процедур и триггеров выполняется на сервере БД. (Хранимая процедураэто процедура с операторами SQL для доступа к БД, хранящаяся на сервере БД, вызываемая клиентским приложением по имени с передачей требуемых параметров и выполняемая на сервере БД. Хранимые процедуры могут храниться в откомпилированном виде (в виде двоичных кодов), что повышает скорость их выполнения и сокращает нагрузку на сервер. Триггер – это разновидность хранимой процедуры. Но выполнение триггера происходит не в результате его вызова приложением по имени, а автоматически, при выполнении оговоренного заранее оператора манипулирования данными, вносящего изменения в БД. При этом триггер может исполняться как до, так и после выполнения оператора манипулирования данными.)

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

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

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

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

Двухуровневые схемы архитектуры клиент-сервер могут привести к некоторым проблемам в сложных информационных приложениях со множеством пользователей и запутанной логической структурой. Решением этих проблем может стать использование многоуровневой архитектуры.

 Преимущества классической архитектуры клиент-сервер:

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

Более низкая интенсивность сетевого трафика, по сравнению с архитектурой файл-сервер, за счёт посылки сервером клиенту только тех данных, которые он запрашивал; например, если необходимо сделать из таблицы объемом 100 000 записей выборку, результатом которой будут всего 2 записи, сервер выполнит запрос и перешлет клиенту только нужные ему 2 записи;

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

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

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

 Недостатки классической архитектуры клиент-сервер:

 В ИС архитектуры клиент-сервер возникает дополнительная проблема — спроектировать

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

Жёсткая привязка ИС к серверу. Выход из строя аппаратного сервера, на котором работает сервер

БД, означает отключение всей ИС  (в случае выхода из строя файлового сервера в ИС, имеющей

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

автономно).

Дополнительные требования к мощности (производительности) сервера (на нём, в крупной

корпоративной ИС могут работать одновременно несколько различных серверов БД и сервер

сетевой ОС), к надёжности его работы, к отказоустойчивости, объёмам и качеству дисковой

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

В ИС классической двухуровневой архитектуры клиент-сервер клиентские компьютеры должны

быть настолько мощными, чобы обеспечивать быстрое и надёжное выполнение не только

функциональных компонентов PS, PL, но и основных компонентов BL  и DL любых по сложности

приложений. То есть клиентские машины должны быть мощными полнофункциональными

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

архитектура клиент-сервер имеет ещё одно название – архитектура клиент-сервер с толстым

 клиентом. Толстый клиент – это мощный полнофункциональный дорогой компьютер-клиент.

 С учётом высокой стоимости  аппаратного сервера, клиент-серверной СУБД и самих приложений для ИС архитектуры клиент- сервер, стоимость владения такой ИС высока. В частности, это

объясняет то, что в России до сих пор  далеко не все корпоративные информационные системы

подуровня малых и средних предприятий, не говоря уж о ИС группового уровня, имеют

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

Для реализации ИС клиент-серверной архитектуры применяют так называемые промышленные СУБД (и, соответственно, их серверы баз данных), такие как Oracle, DB2, Sybase SQL Server, MS SQL Server, Informix,  InterBase.

 Многоуровневая архитектура

Многоуровневые (многоярусные) или распределённые ИС — это новый бурно развивающийся способ организации информационных систем в сети. Иногда (в частности, в документации Delphi) этот способ организации информационных систем называется multi-tier — многонитевые. В этом термине под нитью понимается один из множества потоков данных, посредством которых множество приложений одновременно обмениваются данными с базой данных СУБД таких ИС.

 Многоуровневая архитектура является развитием архитектуры клиент-сервер.

В классическом варианте ИС многоуровневой архитектуры имеет три уровня:

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

  То есть, нижний уровень представляет собой приложения клиентов, выделенные для выполнения функций и логики представлений PS и PL и имеющие программный интерфейс для вызова приложения на среднем уровне.

 На среднем уровне расположен сервер приложений. Сервер приложений – это аппаратный сервер

(компьютер), который размещается в узле сети, доступном всем компьютерам-клиентам ИС.

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

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

 На верхнем уровне расположен удаленный сервер базы данных (программный сервер базы данных

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

То есть, верхний уровень представляет собой удаленный специализированный сервер базы данных, выделенный для услуг обработки данных DS и файловых операций FS (без риска использования хранимых процедур).

 Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle, Sun, Borland и др.

Централизация логики приложения упрощает администрирование и сопровождение. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их специалистам узкого профиля. Наконец, изменения прикладной логики не затрагивают интерфейса, и наоборот. Но поскольку границы между компонентами PL,
BL и DL размыты, прикладная логика может появиться на всех трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с клиентами и другими серверами, может управлять транзакциями и гарантировать целостность распределенной базы данных.

Средства удаленного вызова процедур (технологии COM и CORBA) наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов.

Физически на нижнем уровене классических распределённых ИС находятся так называемые тонкие клиенты, то есть несложные, компактные, недорогие компьютеры, функциональность которых резко ограничена (нет флоппи-дисков, малые по объёму винчестеры, маломощные процессоры, малый объём памяти, ОС может быть прошита в ПЗУ). Они предназначены, в основном, для обеспечения работы специализированных клиентских приложений, отвечающих за ввод — вывод данных (то есть, работают, фактически, в режиме терминала). Средний (middleware) уровень — это серверы приложений, то есть значительно более мощные, надёжные и дорогие полнофункциональные машины, на которых выполняются основные приложения клиентов -  программы, критичные к загрузке процессора и объёму памяти. Верхний уровень — очень мощные, сверхнадёжные, специализированные аппаратные серверы, на которых  работают программные серверы баз данных СУБД, используемых в ИС.

Это наиболее сложная и гибкая архитектура ИС. Продукты для многоуровневой архитектуры, так называемые мониторы транзакций, являются относительно новыми. Эти инструменты в основном ориентированы на среду UNIX, однако  серверы приложений можно строить на базе
Microsoft Windows 2000 с использованием вызова удаленных процедур для организации связи клиентов с сервером приложений. Для этого в настоящее время можно использовать одну из двух технологий: СОМ (Component Object Model – компонентная модель объекта, Microsoft, США) или CORBA (Common Object Require Broker Architecture – архитектура с поставщиком требуемых общих объектов, OMG, Европа).

На практике, с одним и тем же сервером базы данных могут использоваться смешанные архитектуры (двухуровневые и трехуровневые, то есть с толстым клиентом и с тонким клиентом). С учетом глобальных связей архитектура может иметь и более трех звеньев. В настоящее время появились новые инструментальные средства для гибкой сегментации приложений клиент-сервер по различным узлам сети. На технологии COM основаны такие технологии Microsoft как OLE, Automation OLE, ActiveX, OCX, широко используемые в объектно-реляционных СУБД.

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

Пока на российском рынке доминирует классическая архитектура клиент-сервер.

 Internet/Intranet технологии

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

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

Благодаря интеграции Intranet-технологии и архитектуры клиент-сервер процесс внедрения и сопровождения корпоративной информационной системы существенно упрощается при сохранении достаточно высокой эффективности и простоты совместного использования информации. Однако, вследствие наличия в структуре ИС, построенной с использованием Intranet-технологии, дополнительных звеньев обработки информации (сервер динамических страниц, web-сервер), производительность таких систем ниже (иногда намного), чем у обычных ИС  многоуровневой архитектуры. Однако, такие системы позволяют ещё больше экономить на стоимости клиентских компьютеров, позволяя использовать в качесте тонких клиентов сверхкомпактные специализированные, обладающие низкой стоимостью, компьютеры. В таких тонких клиентах не только ОС, но и браузер зашит в ПЗУ, нет «винчестера» (так как приложения вообще не работают на таком тонком клиенте), нет вентиляторов, очень ограниченный объём памяти и маломощный процессор, но зато полный набор интерфейсов общения с внешним миром.

 В рамках данного курса лабораторных работ распределённые СУБД и СУБД, использующие Intranet-технологии рассматриваться не будут, поскольку это очень сложная тема.

Задание

Выберите из приведённой ниже таблицы номера вопросов, соответствующие номеру вашей подгруппы (бригады). В файле «Вопросы к LabRab1_1.doc» найдите вопросы, имеющие  выбранные вами номера. Занесите в отчёт только правильные варианты ответов на эти вопросы.

Номер подгруппы

(бригады)

Номера вопросов в файле Вопросы к LabRab1_1.doc

1

1, 7, 13, 19, 25, 31, 37

2

2, 8, 14 ,20 ,26 ,32 ,38

3

3, 9, 15, 21, 27, 33, 39

4

4, 10, 16, 22, 28, 34, 40

5

5, 11, 17, 23, 29, 35, 41

6

6, 12, 18, 24, 30, 36, 42

7

1, 8, 15, 22, 25, 36, 41

8

2, 7, 14, 21, 28, 35, 42

9

3, 10, 17, 24, 30, 32, 37

10

5, 12, 15, 19, 26, 33, 38

11

6, 11, 16, 21, 26, 31, 40

12

4, 11, 18, 23, 28, 33, 39

13

1, 9, 17, 22, 30, 31,39

14

2, 10, 18, 21, 26, 33, 40

15

5, 8, 17, 21, 25, 32, 38

Примечание: правильных или неправильных вариантов ответа на каждый вопрос может быть

    несколько.

Список литературы:

1). В.Н.Петров, «Информационные системы», учебник для вузов. - СПб.: Питер, 2003. – 688с.

2). В.В. Корнеев, А.Ф.Гареев, С.В.Васютин, В.В.Райх, «Базы данных. Интеллектуальная

обработка информации», - М.: - издатель Молгачёва С.В., Нолидж, 2001. - 496 с.

3). Л.Шкарина, «Язык SQL: учебный курс», - СПб.: Питер, 2001. – 592с.

4). Шумаков П.В., Фаронов В.В., «Delphi 5. Руководство разработчика баз данных», - М.:

- Нолидж, 2000. – 640с.

5). В.Фаронов, «Программирование баз данных в Delphi 6. Учебный курс», - СПб.: Питер,

2003. – 325с.

6). П.Дарахвелидзе, Е.Марков, «Программирование в Delphi 7», -СПб.: БХВ-Петербург, 2003.

  •  784 с.

7). А.Я.Архангельский, «Язык SQL в Delphi 5», - М.: Бином, 2000. – 208с.

8). Тейксейра Стив, Пачеко Ксавье, «Delphi 5. Руководство разработчика», т.1,2.: Уч. пос. – М.:

Издательский дом «Вильямс», 2000. – 992с.

9). Тейксейра Стив, Пачеко Ксавье, «Delphi 6. Руководство разработчика», т.1,2.: Уч. пос. – М.:

Издательский дом «Вильямс», 2002. – 1120с.

10). Т.А.Куправа «Создание и программирование баз данных средствами СУБД dBaseIII Plus, FoxBase Plus, Clipper», - М.: Мир, 1991. – 110с.

11). Г.Хансен, Д.Хансен «Базы данных: разработка и управление», - М.: «БИНОМ», 1999. –704с.


 

А также другие работы, которые могут Вас заинтересовать

78462. Синдром легочно-сердечной недостаточности (ЛСН, «легочное сердце»). Тромбоэмболия легочных артерий (ТЭЛА) 85.5 KB
  Классификация: Острое лёгочное сердце клинический симптомокомплекс возникающий прежде всего вследствие развития тромбоэмболии лёгочной артерии а также при ряде заболеваний сердечнососудистой и дыхательной систем. Основные причины: массивная тромбоэмболия в системе лёгочной артерии; клапанный пневмоторакс; тяжёлый затяжной приступ бронхиальной астмы; распространённая острая пневмония.; 3Васкулярные болезни первичная лёгочная гипертензия тромбоэмболия в системе лёгочной артерии васкулиты аллергический облитерирующий...
78463. Синдром дыхательной недостаточности. Основные причины ДН, клинические и функциональные критерии. Классификации различных видов ДН 128.5 KB
  Дыхательная недостаточность ДН – тяжелое нарушение обмена дыхательных газов или состояние характеризующееся ограничением способности легких обеспечивать нормальный газовый состав артериальной крови. Факторы снижающие вентиляторное обеспечение: Нарушение механики дыхания обструкция ВП: Бронхиальная астма ХОБЛ; Деформация грудной клетки: Кифосколиоз травмы грудной клетки; Уменьшение объема легких: Пневмония интерстициальные поражения легких большой плевральный выпот; Нарушение функции диафрагмальных нервов: Синдром...
78464. Рестриктивный тип дыхательной недостаточности. Клинические и функциональные признаки, характерные для ДН рестриктивного типа 70 KB
  Рестриктивный тип ДН – вариант вентиляционной (гиперкапнической) ДН, характеризующийся снижением способности легких, грудной клетки или плевры к расправлению во время вдоха.
78465. Обструктивный тип дыхательной недостаточности. Клинические и функциональные признаки, характерные для ДН обструктивного типа 85 KB
  Встречается при: Хронический бронхит; Бронхиальная астма; Эмфизема; ХОБЛ; Синдром бронхиальной обструкции; Стенозы трахеи и крупных бронхов; Бронхоэктатическая болезнь; Причины сужения просвета бронхов: бронхоспазм; аллергический отёк; воспалительный отёк; инфильтрация слизистой оболочки бронхов; закупорка бронхов мокротой; склероз бронхиальных стенок; деструкция каркаса бронхиальных стенок; Патогенез: Сужение просвета бронхов является причиной роста сопротивления потоку воздуха в бронхах что в свою очередь приводит к снижению...
78466. Дыхательная недостаточность по смешанному типу. Клинические и функциональные признаки, характерные для ДН смешанного типа 86.5 KB
  Пневмосклероз различной этиологии; Обструктивный тип ДН: Хронический бронхит; Бронхиальная астма; Эмфизема; ХОБЛ; Синдром бронхиальной обструкции; Стенозы трахеи и крупных бронхов; Бронхоэктатическая болезнь; Развивается при длительном течении сердечнолегочных заболеваний; Диагностика: признаки ДН клиника; исследование ФВД характеризуется снижением практически всех показателей...
78467. Тяжелое течение острой дыхательной недостаточности: астматический статус. Принципы диагностики и лечения 98.5 KB
  Возросшее сопротивление воздухоносных путей преодолевается за счет больших колебаний внутриплеврального давления чрезмерно низкого на вдохе и очень высокого на выдохе что приводит к резкому увеличению работы быстрому утомлению и снижению функции дыхательной мускулатуры; Клиника: I стадия относительной компенсации: выраженный приступ удушья не купирующийся ранее эффективными ЛС; мучительный приступообразный кашель без мокроты; вынужденное положение больного; диффузный цианоз; потливость; возбуждение больного; перкуторно:...
78468. Тяжелое течение острой дыхательной недостаточности: острый респираторный дистресс-синдром взрослых (ОРДСВ). Причины ОРДСВ 124 KB
  Острый респираторный дистресссиндром ОРДС – особая форма дыхательной недостаточности возникающая при острых повреждениях легких различной этиологии и характеризуется образованием в обоих легких диффузных легочных инфильтратов резким нарушением растяжимости легочной ткани развитием некардиогенного отека легких и выраженной гипоксемии резистентности к кислородотерапии.; При остром повреждении легкого происходит воспаление = Скопление активированных лейкоцитов и тромбоцитов = Протеолитические ферменты Простагландины Активные...
78469. Тяжелое течение острой дыхательной недостаточности: кардиогенный отек легких. Патогенетические и клинико-функциональные различия кардиогенного и некардиогенного отека легких 82.5 KB
  Патогенетические и клинико-функциональные различия кардиогенного и некардиогенного отека легких. Причины кардиогенного отека легких. Отек легких это острое состояние в основе которого лежит патологическое накопление внесосудистой жидкости в легочной ткани и альвеолах приводящее к снижению функциональных способностей легких.
78470. Клинико-рентгенологические признаки легочного инфильтрата. Наиболее частые причины легочного инфильтрата. Тактика ведения больных с легочным инфильтратом 102 KB
  Легочной инфильтрат - клинико-рентгенологический признак воспалительного изменения легочной паренхимы за счет экссудативно-пролиферативных процессов, сопровождающихся потерей воздушности, эластичности и уплотнением структур легочной ткани.