СОДЕРЖАНИЕ:

Введение…………………………………………………………………………...1

1. Понятие и виды информационных систем…………………………………2-7

2. Специфика информационных программных систем………………………7-9

3. Задачи, решаемые информационными системами……………………….9-18

4. Требования к техническим средствам, поддерживающим ИС…………18-27

Заключение…………………………………………………………………...28-29

Список литературы……………………………………………………………..30
ВВЕДЕНИЕ

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

Однако почти сразу на появление компьютеров обратили внимание бизнесмены. Как правило, в гражданском бизнесе не требуются массивные расчеты за исключением таких отраслей, как, например, авиа- или автомобилестроение. В более распространенных видах гражданского бизнеса (банковское дело, биржевые операции, системы резервирования билетов или мест в гостиницах) основной проблемой всегда являлись объемы информации, которые необходимо собирать, надежно хранить и оперативно обрабатывать. Появление информационных систем, основным назначением которых является решение отмеченной проблемы, явилось ответом компьютерной индустрии на требования мира бизнеса.
1. ПОНЯТИЕ И ВИДЫ ИНФОРМАЦИОННЫХ СИСТЕМ

Информационная система — взаимосвязанная совокуп­ность средств, методов и персонала, используемых для хра­нения, обработки и выдачи информации в интересах дости­жения поставленной цели»

В Федеральном законе «Об информации, информатизации и защите информации» дается следующее определение: «Информационная система— организационно упорядочен­ная совокупность документов (массивов документов) и ин­формационных технологий, в том числе с использованием средств вычислительной техники и связи, реализующих ин­формационные процессы».

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

- одиночные;

- групповые;

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

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

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

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

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

По сфере применения информационные системы обычно подразделяются на четыре группы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- средний уровень представляет собой сервер приложений;

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

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

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

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

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

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

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

Экспертные системы (ЭС) - это компьютерные программы, созданные для выполнения тех видов деятельности, которые под силу человеку-эксперту. Они работают таким образом, что имитируют образ действий человека-эксперта, и существенно отличаются от точных, хорошо аргументированных алгоритмов и не похожи на математические процедуры большинства традиционных разработок.
2. СПЕЦИФИКА ИНФОРМАЦИОННЫХ ПРОГРАММНЫХ СИСТЕМ

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

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

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

И снова заметим, что вычислительные программные системы не обязательно обладают развитыми интерфейсами. Конечно, это зависит от степени отчуждаемости программного продукта. Если система предназначена для продажи, то она должна обладать хорошим интерфейсом хотя бы в целях маркетинга. Но, как правило, серьезные вычислительные программы почти уникальны. Расчеты выполняются либо разработчиками программ, либо людьми из того же окружения. Для них гораздо важнее быстродействие вычислений, чем удобство запуска программы, а наличие развитого интерфейса предполагает существенный расход компьютерных ресурсов. Как профессионалы компьютерного мира, эти люди могут справиться с некоторыми неудобствами при работе с компьютером.
3. ЗАДАЧИ, РЕШАЕМЫЕ ИНФОРМАЦИОННЫМИ СИСТЕМАМИ

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

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

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

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

Варианты решений:

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

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

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

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

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

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

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

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

Еще одно небольшое замечание относительно транзакций. СУБД может очень просто обрабатывать транзакции, выполняя их последовательно. Этого достаточно, чтобы обеспечить согласованность действий «параллельно» работающих операторов. Но реальной параллельности в этом случае, конечно, не будет. СУБД выстроит всех пользователей в общую очередь и будет пропускать по одному, даже если они вовсе не конфликтуют по данным. Развитые СУБД так не работают. Они стремятся максимально перемешивать запросы и операторы изменения базы данных, поступающие от разных транзакций, с тем лишь условием, что конечный результат выполнения всего набора транзакций будет эквивалентен результату их некоторого последовательного выполнения. В мире баз данных такая политика СУБД называется политикой полной сериализации смеси транзакций. Очевидно, что полная сериализация транзакций достаточна для достижения согласованности действий теперь уже действительно параллельной работы операторов информационной системы. Но полная сериализация транзакций не всегда является необходимой для требуемой согласованности действий. Существуют модели ослабленной сериализации, которая допускает еще большую параллельность и вызывает меньшие накладные расходы.

На первый взгляд кажется, что понятие транзакции чуждо персональным СУБД, с которыми в любой момент времени работает только один пользователь. Однако рассмотрим еще раз упоминавшуюся задачу надежного хранения данных. Что это означает более конкретно? Теперь, после того как мы ввели понятия целостного состояния базы данных и транзакции, под надежностью хранения данных мы понимаем гарантию того, что последнее по времени целостное состояние базы данных будет сохранено СУБД при любых обстоятельствах. Одно такое возможное обстоятельство мы уже упоминали: нарушение целостности базы данных при окончании транзакции.

Таким образом, основное условие жизнеспособности ИС – это поддержание целостности и достоверности ее данных.

Чтобы обеспечить целостность данных в случае различных сбоев существуют два основных решения.

1.     Традиционное решение - откат транзакции.

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

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

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

Рис. 1 Традиционная двухзвенная архитектура клиент-сервер.

Рис.2 Трехзвенная архитектура клиент-сервер с выделенным сервером приложений

Традиционным методом организации информационных систем является двухзвенная архитектура клиент-сервер (рис. 1). В этом случае вся прикладная часть информационной системы выполняется на рабочих станциях (т. е. дублируется), а на стороне сервера(ов) осуществляется только доступ к базе данных. Если логика прикладной части системы достаточно сложна, то такой подход порождает проблему "толстого" клиента. Каждая рабочая станция должна обладать достаточным набором ресурсов, чтобы быть в состоянии произвести прикладную обработку данных, поступающих от пользователя и/или из базы данных. Для того чтобы клиенты могли быть тонкими, а зачастую и для повышения общей эффективности системы все чаще применяются трехзвенные архитектуры клиент-сервер (рис. 2). В этой архитектуре кроме клиентской части системы и сервера(ов) базы данных вводится промежуточный сервер приложений. На стороне клиента выполняются только интерфейсные действия, а вся логика обработки информации поддерживается в сервере приложений.

Заметим, что некоторые черты трехзвенности могут присутствовать и в двухзвенной архитектуре. Если, например, используемый сервер баз данных поддерживает развитый механизм хранимых процедур (например, такой, как в Oracle V.7), то можно перебросить некоторую часть логики приложения на сторону баз данных. Заметим, что механизм хранимых процедур недостаточно полно специфицирован в текущем стандарте языка SQL. Как только вы решаетесь использовать действительно развитые средства, то немедленно привязываете свою информационную систему к конкретному производителю серверов баз данных. Развязаться будет очень трудно.

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

На первый взгляд упомянутая задача кажется не очень существенной. Можно полагать, что если информационная система обеспечивает полный набор функций и ее интерфейс обеспечивает доступ к любой из этих функций, то конечные пользователи должны быть удовлетворены. На самом деле это не так. Пользователи часто судят о качестве системы в целом, исходя из качества ее интерфейса. Более того, эффективность использования системы зависит от качества интерфейса. Поскольку, как отмечалось выше, задача построения эргономичного интерфейса не формализуется, мы больше не будем ее затрагивать.
4.     ПРОБЛЕМЫ ПОСТРОЕНИЯ ИС

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

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

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

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

Реляционная база данных - тип базы данных и системы управления базой данных, в которой информация записана в таблицах (ряды и колонки данных), а для поиска данных в таблице используются данные из колонок другой таблицы. В реляционной базе данных ряды таблиц представляют собой записи (наборы информации об отдельном элементе), а колонки - поля (отдельные атрибуты записи). При проведении поиска Реляционная база данных связывает информацию поля одной таблицы с информацией в соответствующем поле другой таблицы для обработки третьей таблицы, в которой комбинируются запрошенные данные из обеих таблиц. Например, если одна таблица содержит поля ДОЛЖНОСТЬ, ФАМИЛИЯ, ИМЯ СТАЖ, а другая содержит поля ОТДЕЛ. ДОЛЖНОСТЬ и ЗАРПЛАТА, то реляционная база может связать оба поля ДОЛЖНОСТЬ в две таблицы, чтобы найти такую информацию, как имена всех служащих, имеющих определенный стаж, или отделы, в которые были приняты служащие после определенной даты. Другими словами, реляционная база данных использует согласующиеся значения в двух таблицах, чтобы установить отношение информации в одной таблице к информации в другой таблице.

Несмотря на очевидную привлекательность объектно-ориентированных и объектно-реляционных СУБД, в ближайшие годы придется работать с хорошо отлаженными, развитыми, сопровождаемыми системами, поддерживающими стандарт SQL-92 (например, Oracle, Informix, CA-OpenIngres, Sybase, DB2). Просто потому, что должно пройти время, чтобы системы новых типов устоялись, обрели необходимую надежность, стали бы опираться на какие-либо стандарты и т. д.

Поэтому с большой вероятностью на следующей стадии проектирования будет нужно на основе имеющейся концептуальной схемы произвести набор определений схемы реляционной базы данных в терминах языка SQL. К сожалению, несмотря на наличие стандарта языка, на этой стадии иногда невозможно не учитывать специфику сервера баз данных, который будет использоваться. Вы спросите, почему "к сожалению"? Да потому, что на самом деле мы еще не дошли до той стадии, когда конкретные особенности сервера действительно необходимо учитывать. В принципе, на данной стадии мы все еще находимся на уровне абстрактной реляционной модели. Но все дело в том, что когда производители серверов баз данных провозглашают соответствие своих серверных продуктов стандарту языка SQL-92, то в основном они понимают соответствие так называемому "ядру" стандарта. К сожалению, ядро стандарта не включает средств определения схемы базы данных. Поэтому диалекты SQL, реализуемые разными производителями, различаются в деталях соответствующих языковых средств. По этой причине необходимо внимательно изучить "целевой" диалект SQL, если трансляция концептуальной схемы в реляционную производится вручную (например, на основе методологии, предлагаемой компанией Oracle), или указать название используемого серверного продукта, если применяется продукто-независимое CASE-средство (например, Silverrun).

На этой же стадии необходимо решить, какие таблицы будут реально хранимыми, а какие - представляемыми (view).

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

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



Рис. 3.Распределенная база данных с логически автономными разделами.


Рис. 4.Распределенная база данных с логически неавтономными разделами.

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

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

Язык SQL/92 позволяет определить ограничения целостности, относящиеся к общему состоянию базы данных и включающие ссылки на произвольное число таблиц. Семантика таких ограничений целостности может быть существенно шире, чем ограничения, задаваемые связями 1 к n и даже n к m (1-to-many и many-to-many). Поэтому часто ограничения общего вида не выводятся автоматически из концептуальной схемы базы данных, и их приходится добавлять к реляционной схеме вручную. Для того чтобы понять, какие ограничения общего вида должны быть включены в реляционные схемы разделов, приходится возвращаться к документу, содержащему анализ требований корпорации. Задача проектировщика состоит в том, чтобы, с одной стороны, выявить все необходимые ограничения целостности и, с другой стороны, не перегрузить базу данных необязательными ограничениями (любое дополнительное ограничение целостности вызывает дополнительные проверки на стороне сервера при выполнении операций изменения базы данных; проверки для ограничений общего вида могут быть весьма громоздкими). Конечно, если предполагается использование распределенной базы данных, то опять придется учитывать возможности сервера по части ссылок на объекты "чужих" разделов. Это может повлиять на выбор ограничений целостности и/или повлечь создание новой декомпозиции общей базы данных на разделы.

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

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

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

Наконец, в базе данных могут находиться хранимые процедуры. Интересно, что в стандарте SQL/92 вообще не встречается термин "хранимая процедура". В стандарте специфицированы два способа взаимодействия прикладной программы с сервером баз данных.

1.     Первый, наиболее часто используемый способ состоит во встраивании операторов языка SQL в программу, написанную на одном из традиционных языков программирования. В самом стандарте определены правила встраивания SQL в программы, которые написаны на языках Си, Паскаль, Фортран, Ада и т. д.

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

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

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

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

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

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

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

Понятно, что в любом случае в наше время неразумно программировать интерфейсные функции вручную. Нужно использовать имеющиеся полуфабрикаты. Но здесь существует широкий выбор: базовые библиотеки используемой оконной системы (например, X Toolkit Intrinsics в оконной системе X), универсальные инструментальные средства построения графического пользовательского интерфейса более высокого уровня (например, Motif или Tcl/Tk), языки и системы программирования 4-го поколения (например, PowerBuilder, Jam и т. д.). На наш взгляд, выбор определяется вкусом и привычками разработчика, а также общей ориентацией проекта. Например, если с самого начала проект был ориентирован на использование продуктов компании Oracle и ведется в интегрированной среде Designer/Developer 2000, то было бы странно покидать эту среду при разработке интерфейсов.

Что же касается обрабатывающих частей информационной системы, то все зависит от того, что они должны делать. Имеется масса примеров информационных систем, в которых вся обработка данных состоит в преобразовании их форматов при вводе и выводе, формировании отчетов и т. д. Такие функции можно фактически не программировать, поскольку любой 4GL может сгенерировать их автоматически по соответствующему описанию. Но если требуется более сложная обработка данных, то в любом случае потребуется явное программирование, и тогда уже неважно, на каком языке это программирование будет вестись. В частности, если вы используете Delphi для разработки интерфейсов, то для программирования разумно использовать Object Pascal (прекрасный язык, но пока жестко привязанный к Intel-платформам). В других случаях можно применять процедурную часть 4GL (обычно все они похожи на Basic) или C/C++ (как правило, стыковка 4GL с этими языками поддерживается).

Последнее замечание этого раздела. Мы описали одну из возможных схем проектирования и разработки информационной системы, представив весь процесс в виде последовательно выполняемых стадий.
ЗАКЛЮЧЕНИЕ

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

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

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

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

- Настольные;

- Сетевые;

- ИС масштаба предприятия.

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

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

- ИС автоматизирует применение математических методов к решению управленческих задач;

- ИС по крайней мере частично освобождает сотрудников от рутинного труда;

- ИС минимизирует вероятность появления ошибки в ходе передачи либо обработки информации;

- ИС снижает объем документов на бумаге;

- ИС совершенствует документооборот;

- ИС снижает затраты на производство товаров и услуг.
СПИСОК ЛИТЕРАТУРЫ:

1. Бородакий Ю.В., Лободинский Ю.Г. Информационные технологии. Методы, процессы, системы. – М.: Радио и связь, 2002 год.

2. Информатика: Учебник – 3-е перераб. Изд. / Под ред. Макаровой Н.В. – М.: Финансы и статистика. 2004 год.

3. Веретенникова Е.Г., Патрушина С.М., Савельева Н.Г.  Информатика: Учебное пособие. – Ростов-на-Дону: Изд. Центр «МарТ», 2003 год.

4. Захарова И.Г. Информационные технологии в образовании: Учебное пособие для студентов высших педагогических учебных заведений. М.: Изд. Центр «Академия», 2003 год.

5. Згадзай О.Э. и др. Информатика для юристов: Учебник Згадзай О.Э., Казанцев С.Я., Казанцева Л.А.; Под ред. Казанцева С.Я. – М.: Мастерство, 2001 год.

6. Сухомлин В.А. Введение в анализ информационных технологий. Учебник для вузов. М.: Изд-во «Горячая линия Телеком»; Серия: Высшая школа МГУ, 2003 год.

7. Советов Б.Я., Цехановский В.В. Информационные технологии. М.: Изд-во  «Высшая школа», 2007 год.

8. Филимонова Е.В. Информационные технологии в профессиональной деятельности: Учебник, Ростов-на-Дону: Изд-во «Феникс», 2004 год.

9. Угринович Н.Д. Информатика и информационные технологии: Учебник для  10-11 классов. М.: БИНОМ, Лаборатория знаний, 2003 год.

10.Хохлова Н.М. Информационные технологии (конспект лекций) – М.: Приор-Издат, 2004 год.