Проектирование корпоративных информационных систем и управление

Рефераты по информатике » Проектирование корпоративных информационных систем и управление Скачать

Выполнил: Терин В.А. 03-432

Московский авиационный институт (Государственный технический университет)

Москва 2009 г

Общее представление о ИС

1.Специфика информационных программных систем

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

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

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

2.Задачи информационных систем

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

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

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

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

3.Проблемы построения ИС

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

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

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

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

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

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

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

Физическое проектирование включает два основных шага первый из которых как правило не зависит от особенностей выбранного серверного SQL-ориентированного продукта а второй зависит. На первом шаге этой стадии определяется набор требуемых индексов. Второй шаг состоит в определении областей внешней памяти в которых будут храниться фрагменты базы данных.

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

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

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

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

Общая классификация архитектур информационных приложений

Проектирование и разработка информационной системы может базироваться на разных архитектурных решениях.

Начать можно с традиционных архитектурных решений основанных на использовании выделенных файл-серверов или серверов баз данных. Затем рассматриваются варианты архитектур корпоративных информационных систем базирующихся на технологии Internet (Intranet-приложения). Следующая разновидность архитектуры информационной системы основывается на концепции "склада данных" (DataWarehouse) - интегрированной информационной среды включающей разнородные информационные ресурсы. Наконец последняя архитектура предназначена для построения глобальных распределенных информационных приложений с интеграцией информационно-вычислительных компонентов на основе объектно-ориентированного подхода.

1.Файл-серверные приложения

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

Основным достоинством является простота организации. Проектировщики и разработчики информационной системы находятся в привычных и комфортных условиях IBM PC в среде MS-DOS Windows или какого-либо облегченного варианта Windows NT. Имеются удобные и развитые средства разработки графического пользовательского интерфейса простые в использовании средства разработки систем баз данных и/или СУБД. Но во многом эта простота является кажущейся.

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

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

наличие транзакционного управления

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

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

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

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

2.Клиент-серверные приложения

Под клиент-серверным приложением понимается информационная система основанная на использовании серверов баз данных .

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

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

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

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

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

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

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

3. Intranet-приложения

Возникновение и внедрение в широкую практику высокоуровневых служб Всемирной Сети Сетей Internet (e-mail ftp telnet Gopher WWW и т.д.) естественным образом повлияли на технологию создания корпоративных информационных систем породив направление известное теперь под названием Intranet. По сути дела информационная Intranet-система - это корпоративная система в которой используются методы и средства Internet. Такая система может быть локальной изолированной от остального мира Internet или опираться на виртуальную корпоративную подсеть Internet. В последнем случае особенно важны средства защиты информации от несанкционированного доступа.

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

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

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

4 Склады данных (DataWarehousing) и системы оперативной аналитической обработки данных

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

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

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

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

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

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

Прозрачность.

Доступность

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

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

Родовая многомерность

Управление динамическими разреженными матрицами

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

Неограниченные операции между измерениями

Интуитивное манипулирование данными

Гибкая система отчетов

Неограниченное число измерений и уровней агрегации

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

5 . Интегрированные распределенные приложения

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

Решение проблемы интеграции неоднородных информационных ресурсов началось с попыток интеграции неоднородных баз данных. Направление интегрированных или федеративных систем неоднородных БД и мульти-БД появилось в связи с необходимостью комплексирования систем БД основанных на разных моделях данных и управляемых разными СУБД.

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

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

Согласованная с архитектурой OMA прикладная информационная система представляется как совокупность классов и экземпляров объектов которые взаимодействуют при поддержке брокера объектных заявок (ORB - Object Request Broker). ORB общие средства (Common Facilities) и объектные службы (Object Services) относятся к категории промежуточного программного обеспечения (middleware) и должны поставляться вместе. Объектные службы представляют собой набор услуг (интерфейсов и объектов) которые обеспечивают выполнение базовых функций требуемых для реализации прикладных объектов и объектов категории "общие средства" (например специфицированы служба именования объектов служба долговременного хранения объектов служба управления транзакциями и т.д.). Общие средства содержат набор классов и экземпляров объектов поддерживающих функции полезные в разных прикладных областях (например средства поддержки пользовательского интерфейса средства управления информацией и т.д.).

В основе OMA лежит базовая объектная модель COM (Core Object Model) в которой специфицированы такие понятия как объект операция тип подтипизация наследование интерфейс. Определены также способы согласованного расширения COM в разных объектных службах.

Интерфейсы объекта-клиента и объекта-сервера должны быть определены на специальном языке IDL (Interface Definition Language) который очень напоминает компонент спецификации класса (без реализации) языка Си++. Обращения к ORB могут быть сгенерированы статически при компиляции спецификаций IDL или выполнены динамически с использованием специфицированного в документах OMG API брокера объектных заявок. Правила построения и использования ORB определены в документе OMG CORBA (Common Object Request Broker Architecture).

Средства и методологии проектирования разработки и сопровождения файл-серверных приложений

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

1. Традиционные средства и методологии разработки файл-серверных приложений

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

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

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

Основные вехи на пути развития систем программирования:

Переход от одиночных утилит систем программирования к интегрированным диалоговым средам программирования (например семейство Turbo-продуктов фирмы Borland);

Развитие инструментальных наборов расширяющих возможности систем программирования в частности в области диалога (разного рода Tool Box);

Появление объектно-ориентированных диалектов языков Си и Паскаль;

Возникновение операционной среды Windows со встроенной поддержкой диалога и первых Windows-приложений с помощью SDK (Software Development Keet);

Создание объектно-ориентированных библиотек поддерживающих диалоговый режим работы в среде DOS и Windows (TurboVision Object Windows и MFC);

Появление систем программирования облегчающих создание приложений для DOS и Windows;

Развитие механизма встраивания и связывания объектов OLE 2;

Переход к визуальным системам программирования (Visual Си++ Delphi Visual Basic) которые ориентированы на разработку информационных приложений.

Поддержка диалогового режима развивалась совместно с развитием самих систем программирования и была естественным образом интегрирована с ними. Библиотеки же доступа к базам данных развивались своим путем. Наибольшее число библиотек доступа из языков программирования уровня 3GL к реляционным СУБД на персональных компьютерах поддерживает семейство xBase (Clipper FoxPro dBase). Из языков программирования чаще всего используется Си.

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

Приложения созданные с использованием инструментальных средств программирования приложений связанных с использованием баз данных на персональных компьютерах занимают существенную долю файл-серверных приложений. Если рассматривать только "реляционные" (вернее табличные) СУБД то семейство xBase-продуктов является явным лидером по использованию для разработки одиночных и групповых информационных приложений. Следующее место занимает СУБД Paradox а далее идут приложения базирующиеся на использовании системы управления записями Clarion. Особняком стоят такие пакеты как MS Access и Lotus Approach которые позволили взглянуть по-новому на возможности персональных СУБД и до сих пор не оценены по-настоящему как профессиональные средства разработки приложений. Можно отметить следующие вехи на пути развития инструментальных средств и самих СУБД на персональных компьютерах:

Появление компонентов Assistant и Application Generator в dBase III Plus упрощающих работу пользователя и позволяющих генерировать простейшие приложения или макеты приложений;

Выход в свет dBase-совместимых систем программирования (dBFast и Clipper) создающих исполняемый модуль приложения; разработка быстрого интерпретатора FoxBase для частично откомпилированного кода dBase-совместимых приложений;

Возникновение системы Paradox с оригинальным макроязыком PAL существенно ориентированной на конечного пользователя;

Развитие многопользовательских версий СУБД для локальных сетей персональных компьютеров дополненных средствами синхронизации на основе блокировок файлов и записей;

Появление системы dBase IV включающую диалоговую среду Control Center индексы встроенные в файл БД поддержку языка SQL и средства защиты БД;

Развитие Clipper с объектной ориентацией;

Обеспечение доступа из файл-серверных приложений к серверам БД (Borland SQL Link и Microsoft Connectivity Kit);

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

Появление в FoxPro развитой среды разработки ориентированной на разработку проектов и близкой по возможностям к средствам 4GL;

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

Первые версии инструментальных средств поддерживающие Windows-приложения а вместе с ними типы данных Blob (Binary Large Objects);

Появление универсальных интерфейсов к различным СУБД (Borland IDAPI и Microsoft ODBC);

Первый продукт MS Access направленный сугубо на создание Windows-приложений и содержащий средства объектно-ориентированного диалога событийно-управляемого программирования визуального конструирования интерфейса пользователя и многие другие черты присущие системам программирования 4GL и RAD;

Появление новых визуальных объектно-ориентированных инструментальных средств и СУБД на ПК (MS Access 2.0 Visual FoxPro CA-VisualObjects и Visual dBase).

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

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

Общая характеристика современных средств

В индустрии СУБД для персональных компьютеров отразились тенденции нормализации систем (Rightsizing). В последнее время в этой области происходили два встречных процесса: (1) разукрупнение серверов БД - появление новых версий серверов БД Informix Oracle и т.д. сначала в варианте для рабочих групп а потом облегченные версии для одиночных персональных компьютеров; (2) укрупнение СУБД для персональных компьютеров - новые "персональные" СУБД и связанные с ними инструментальные средства развивались в сторону "истинно реляционных" СУБД т.е. серверов БД приложений клиент-сервер и инструментальных средств программирования 4GL и быстрой разработки RAD.

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

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

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

Встроенная поддержка языка структурированных запросов SQL (Standard Query Language) закладывает возможность масштабирования создаваемых файл-серверных приложений до уровня приложений клиент-сервер.

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

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

Поддержка компонентно-ориентированного программирования дает возможность расширения приложений за счет использования готовых внешних визуальных объектов типа VBX и OCX (ActiveX).

"Истинно реляционная" база данных представляет собой объединенный набор файлов содержащий таблицы индексы и т.п. что облегчает сопровождение БД и приложений и является основой для поддержки целостности данных.

Поддерживается общий для информационной системы словарь данных (data dictionary) который содержит описание структуры БД типы полей правила поддержки ограничений целостности и т.п.

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

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

Хранение в БД описания проекта создаваемого приложения является прообразом репозитория инструментальных средств быстрой разработки RAD и CASE-систем.

Средства и методологии проектирования разработки и сопровождения приложений в архитектуре "клиент-сервер"

1. Базовые средства построения ИС в архитектуре "клиент-сервер"

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

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

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

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

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

Технологии и стандарты открытых систем обеспечивают реальную и проверенную практикой возможность производства системных и прикладных программных средств со свойствами мобильности (portability) и интероперабельности (interoperability). Свойство мобильности означает сравнительную простоту переноса программной системы в широком спектре аппаратно-программных средств соответствующих стандартам.

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

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

Вызовы удаленных процедур

Общим решением проблемы мобильности систем основанных на архитектуре "клиент-сервер" является опора на программные пакеты реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call). При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC в которых естественно содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов переводит вызов в последовательность сетевых взаимодействий. Тем самым специфика сетевой среды и протоколов скрыта от прикладного программиста.

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

Термин "сервер баз данных" обычно используют для обозначения всей СУБД основанной на архитектуре "клиент-сервер" включая и серверную и клиентскую части. Такие системы предназначены для хранения и обеспечения доступа к базам данных.

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

Страницы: 1 2 3 4 5