Документ Microsoft Word

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

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

 

 

 

 

 

 

 

 

 

 

Одной из оптимальных определений распределенных баз данных (РДБ) предложил Дэйт, установивший 12 свойств или качеств идеальной РДБ .

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

        Создание автоматизированных систем управления и информационных систем связано с широким внедрением сетей ЭВМ, распределенных баз данных и систем передачи информации. РБД отличает функциональная и структурная сложность [1], процесс их проектирования характеризуется большой длительностью, высокой трудоемкостью и значительными финансовыми затратами. Имеющийся в настоящее время аппарат для разработки логических и физических структур РБД недостаточно формализован и базируется в основном на использовании опыта и интуиции разработчиков, что не позволяет оптимизировать процессы проектирования и функционирования РБД. Более того, при проектировании никак не учитываются ни особенности химической технологии, ни, тем более, особенности работы цепочки взаимосвязанных и размещенных на значительной территории производств. Вопросы формирования методики синтеза эффективных структур распределенных баз данных для создания интегрированных АСУ предприятиями химической технологии в настоящее время разработаны недостаточно, решены только отдельные вопросы проектирования структур РБД, не содержащие общих подходов к созданию такого рода систем. Одной из важных компонент распределенных систем являются системы, которые обладают развитым аппаратом обработки больших объёмов информации, структурированной в базы данных. В настоящее время применение концепции баз данных в распределенных системах является общепринятым. По мере развития таких систем постоянно возрастают сложность решаемых ими задач и объёмы обрабатываемой информации [2]. При этом распределенные системы должны обладать средствами оперативной обработки больших объёмов информации. Современные тенденции развития информационной системы состоят в переходе от централизованных вычислительных систем к распределенным. Стратегии распределения данных по узлам сети диктуются как управленческими, так и производственными задачами конкретных химических производств.

Можно рассмотреть несколько альтернативных стратегий распределения данных [3,4,5], каждая из которых имеет как преимущества, так и недостатки. Основным преимуществом централизованной базы данных является простота. Все операции выполняются под контролем единственного узла. Все запросы на выборку и обновление данных направляются в центральный узел. Недостатком данной стратеги является то, что размер базы данных ограничивается объемом внешней памяти в центральном узле. Кроме того, центральный узел может стать узким местом всей системы с точки зрения надежности, поскольку база данных становится недоступной при появлении ошибки в системе связи и полностью выходит из строя при выходе из строя центрального узла. Это является недопустимым для экологически опасных химических производств.

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

Распределенные системы - это системы "клиент-сервер". Существует по меньшей мере три модели "клиент-сервер" (подробно о них рассказано в [2]):

• Модель доступа к удаленным данным (RDA-модель)

• Модель сервера базы данных (DBS-модель)

• Модель сервера приложений (AS-модель)

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

• Компонент интерфейса с пользователем

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

а между ними расположено программное обеспечение промежуточного слоя (middleware), выполняющее функции управления транзакциями и коммуникациями, транспортировки запросов, управления именами и множество других. Middleware - это ГЛАВНЫЙ компонент распределенных систем и, в частности, DDB-систем. Главная ошибка, которую мы совершаем на нынешнем этапе - полное игнорирование middleware и использование двухзвенных моделей "клиент-сервер" для реализации распределенных систем. Существует фундаментальное различие между технологией "SQL-клиент - SQL-сервер" и технологией продуктов класса middleware (например, менеджера распределенных транзакций Tuxedo System). В первом случае клиент явным образом запрашивает данные, зная структуру базы данных (имеет место так называемый data shipping, то есть "поставка данных" клиенту). Клиент передает СУБД SQL-запрос, в ответ получает данные. Имеет место жесткая связь типа "точка- точка", для реализации которой все СУБД используют закрытый SQL-канал (например, Oracle SQL*Net). Он строится двумя процессами: SQL/Net на компьютере - клиенте и SQL/Net на компьютере-сервере и порождается по инициативе клиента оператором CONNECT. Канал закрыт в том смысле, что невозможно, например, написать программу, которая будет шифровать SQL- запросы по специальному алгоритму (стандартные алгоритмы шифрования, используемые, например, в Oracle SQL*Net, вряд ли будут сертифицированы ФАПСИ).  В случае трехзвенной схемы клиент явно запрашивает один из сервисов (предоставляемых прикладным компонентом), передавая ему некоторое сообщение (например) и получает ответ также в виде сообщения. Клиент направляет запрос в информационную шину (которую строит Tuxedo System), ничего не зная о месте расположения сервиса. Имеет место так называемый function shipping (то есть "поставка функций" клиенту). Важно, что для Клиента база данных (в том числе и DDB) закрыта слоем Сервисов. Более того, он вообще ничего не знает о ее существовании, так как все операции над базой данных выполняются внутри сервисов.  Сравним два подхода. В первом случае мы имеем жесткую схему связи "точка-точка" с передачей открытых SQL-запросов и данных, исключающую возможность модификации и работающую только в синхронном режиме "запрос-ответ". Во втором случае определен гибкий механизм передачи сообщений между клиентами и серверами, позволяющий организовывать взаимодействие между ними многочисленными способами.  Таким образом, речь идет о двух принципиально разных подходах к построению информационных систем "клиент-сервер". Первый из них устарел и явно уходит в прошлое. Дело в том, что SQL (ставший фактическим стандартом общения с реляционными СУБД) был задуман и реализован как декларативный язык запросов, но отнюдь не как средство взаимодействия "клиент-сервер" (об этой технологии тогда речи не было). Только потом он был "притянут за уши" разработчиками СУБД в качестве такого средства. На волне успеха реляционных СУБД в последние годы появилось множество систем быстрой разработки приложений для реляционных баз данных (VisualBasic, PowerBuilder, SQL Windows, JAM и т.д.). Все они опирались на принцип генерации кода приложения на основе связывания элементов интерфейса с пользователем (форм, меню и т.д.) с таблицами баз данных. И если для быстрого создания несложных приложений с небольшим числом пользователей этот метод подходит как нельзя лучше, то для создания корпоративных распределенных информационных систем он абсолютно непригоден.  Для этих задач необходимо применение существенно более гибких систем класса middleware (Tuxedo System, Teknekron), которые и составляют предмет нашей профессиональной деятельности и базовый инструментарий при реализации больших проектов.

Заключение

Сегодня можно считать, что распределенные базы данных - тема достаточно локальная и далеко не так актуальная, как архитектура распределенных систем. В DDB-технологии за последние 2-3 года не было каких-либо существенных новаций (за исключением, быть может, технологии тиражирования данных). Можно считать, что в этой сфере информатики все более или менее устоялось и каких-либо революционных шагов не предвидится. Более интересное направление (включающее DDB) - архитектура, проектирование и реализация распределенных информационных систем. "Горячие" темы в этом направлении - системы с трехзвенной архитектурой, продукты класса middleware, объектно-ориентированные средства разработки распределенных приложений в стандарте CORBA. Их активное применение будет доминировать в отечественной информатике в ближайшие 3-5 лет и станет технологической базой реальных интеграционных проектов. Мне кажется, что революция произойдет в архитектуре корпоративных информационных систем. Технологический взрыв в Intertet, создание и супербурное развитие Всемирной паутины, технология Java, неизбежно отразятся на организации инфраструктуры корпораций. На мой взгляд, очевидные преимущества гипертекстовой организации данных (гибкость, открытость, простота развития и расширения) перед жесткими структурами реляционных баз данных, по своей природе плохо приспособленными для расширения, предопределяют использование HTML в качестве одного из основных средств создания информационного пространства компании. Подход, опирающийся на гипертексты, позволяет без особых проблем интегрировать уже существующие информационные массивы, хранящиеся в базах данных. То, что сейчас называют Intranet - это прообраз будущей корпоративной информационной системы.

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

• характеристик моделируемой предметной области;

• целей, потребностей и ограничений будущего проекта ИС, включая квалификацию участвующих в процессе проектирования специалистов;

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

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

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

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

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

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

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

• необходимость достаточно длительного сосуществования старых приложений и вновь разрабатываемых БД и приложений;

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

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

• функционирование в неоднородной операционной среде на нескольких вычислительных платформах;

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

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

Методология проектирования определяется как совокупность трех составляющих:

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

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

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

На выбор СП могут существенно повлиять следующие особенности методологии проектирования:

• ориентация на создание уникального или типового проекта;

• итерационный характер процесса проектирования;

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

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

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

Критерии выбора

Традиционно при обсуждении проблемы выбора СП (в особенности CASE-средств) большое внимание уделялось особенностям реализации той или иной методологии анализа предметной области (E-R, IDEF0, IDEF1Х, Gane/Sarson, Yordon, Barker и др.). Безусловно, богатство изобразительных и описательных средств дает возможность на этапах стратегического планирования и анализа построить наиболее полную и адекватную модель предметной области. С другой стороны, если говорить о конечных результатах - базах данных и приложениях, то обнаруживается, что часть описаний в них практически не отражается, оставаясь чисто декларативной (на выходе мы в любом случае получим описание БД в табличном представлении с минимальным набором ограничений целостности и исполнимый код приложений, большую часть которых составляют экранные формы, не выводимые непосредственно из моделей предметной области). Опытные аналитики и проектировщики всегда с большими или меньшими трудозатратами придут к нужному конечному результату независимо от того, какая конкретно методология или ее разновидность реализована в данном инструменте. Это, конечно, не означает, что методология не важна, напротив, отсутствие или неполнота описательных средств могут с самого начала значительно затруднить работу над проектом. Однако, зачастую на первом плане оказываются другие критерии, невыполнение которых может породить гораздо большие трудности. Может создаться впечатление, что если можно сформировать необходимую аппаратную платформу из компонентов различных фирм-производителей, то так же просто можно выбрать и скомплексировать разные инструментальные средства, каждое из которых является одним из мировых лидеров в своем классе. Однако в случае инструментальных средств в настоящее время, в отличие от оборудования, отсутствуют международные стандарты на основные свойства конечных продуктов (программ, баз данных и их сопряжение). Однако, поскольку составные части проекта должны быть интегрированы в единый продукт, следовательно, имеет смысл рассматривать не любые, а только сопряженные инструментальные средства, которые в принципе могут быть ориентированы - даже внутри одного класса - на разные методологии; при этом необходимо отбирать в состав комплекса СП средства, поддерживающие по крайней мере близкие методологии, если не одну и ту же. Исходя из перечисленных выше соображений, примем в качестве основных критериев выбора СП следующие критерии:

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

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

• декомпозиция проекта на составные части и интеграция составных частей;

• проектирование моделей приложений (логики приложений и пользовательских интерфейсов);

• прототипирование приложений;

• проектирование баз данных;

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

• разработка распределенных баз данных (с выбором оптимальных вариантов распределения);

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

• адаптация к различным системно-техническим платформам и СУБД;

• тестирование и испытания;

• сопровождение, внесение изменений и управление версиями и конфигурацией ИС;

• интеграция с существующими разработками (включая реинжиниринг приложений, конвертирование БД);

• администрирование ИС (оптимизация эксплуатационных характеристик);

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

• прогнозирование и оценка трудоемкости, сроков и стоимости разработки.

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

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

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

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

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

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