Норенков И.П. - Основы автоматизированного проектирования (1060628), страница 68
Текст из файла (страница 68)
е. одновременно используются модели DBS и RDA.Помимо проблемы распределения серверных функций между узлами сетиимеется проблема разделения этих функций между многими пользователямиАС. Эта проблема решается либо по схеме «один к одному», либо по многопотоковой схеме. В первой из них для каждого активного пользователя создается своя копия СУБД. Во второй СУБД должна быть реентерабельнойпрограммой, обслуживающей одновременно многих пользователей.ю-2755 Методическое и программное обеспечение автоматизированных системРаспределенные базы данныхВ крупных АС, построенных на основе корпоративных сетей, не всегда удается организовать централизованное размещение всех баз данных и СУБД наодном узле сети. Поэтому появляются распределенные базы данных (РБД).При построении РБД приходится решать ряд сложных проблем, связанныхс минимизацией трафика, обеспечением интероперабельности обработки данных и целостности данных.Минимизация трафика нужна в связи с тем, что при обслуживании запроса могут потребоваться данные из многих узлов, пересылаемые по сети.
Возможности минимизации видны из примера обработки данных нескольких таблиц из разных узлов. Очевидно, что целесообразна однократная пересылкатаблиц (причем таблиц именно меньшего размера) на один узел, на котором ибудет обрабатываться запрос.Интероперабелъностъ выражает способность взаимодействия программ,работающих в гетерогенных сетях (в разных операционных средах или с разными СУБД). Интероперабельность обеспечивается или с помощью программшлюзов (конверторов) для каждой пары взаимодействующих сред, или с помощью единого унифицированного языка взаимодействия.
Таким языком длядоступа к базам данных является язык SQL, Интероперабельность на его основе имеет место в системе ODBC (Open Data Base Connectivity), пример реализации которой показан на рис. 5.13. В примере СУБД FoxPro находится влокальном узле, а СУБД Ingres и Informix - в удаленных узлах. Прикладнаяпрограмма имеет ODBC-интерфейс, не зависимый от особенностей различных СУБД. Менеджер драйверов реализует на базе унифицированного языкаSQL все нюансы доступа к базам данных, общие для разных СУБД. Драйверконкретной СУБД преобразует инвариантные к СУБД запросы в форму, принятую в данной СУБД. В трехзвенной структуре менеджер драйверов можетбыть размещен на промежуточном сервере.Обеспечение целостности в РБД намного сложнее, чем в одноузловых базах данных. Различают два подхода к построению РБД: 1 ) тиражирование (репликация), при котором на нескольких серверах (в узлах) сети расположены копии базы данных; 2) полномасштабная распределенность, при которой разныечасти базы данных находятся на разных серверах сети (классическая распределенность).КлиентСерверыДрайверIngres- ПрограммасвязиКоммуникационный серверДрайвер- ПрограммасвязиКоммуникационный сервер! InformixFoxProДрайверFoxProРис.
5.13. Структура системы ODBC276Ingres5.6. Системные среды автоматизированных системПрименяют два способа тиражирования.Способ, называемый репликацией первой копии, основан на выделении среди серверов с копиями базы данных одного первичного сервера (репликатора).Внесение изменений пользователями возможно только в базы данных первичного сервера, который в дальнейшем осуществляет тиражирование. Тиражирование - это перенос изменений баз данных из первичного сервера во всевторичные (локальные) серверы, которые используются клиентами только длячтения данных. Репликатор реагирует на события, фиксируемые триггерами,периодически пересылает обновленные данные в копии базы данных.
Недостаток способа - невысокая надежность, присущая любым централизованнымструктурам.Надежность повышается при использовании способа голосования: изменения посылаются не в один первичный, а в некоторые N серверов. При этомлюбой запрос на чтение направляется к некоторым М серверам, причемN + М > К, где К- общее число серверов. Принимается последняя по времениобновления версия ответа.Тиражирование вносит избыточность в хранимые данные, появляются трудности с разрешением конфликтов ввиду возможных несогласованных изменений в локальных базах данных. Однако по сравнению с классическими РБД, вкоторых данные не дублируются, заметно уменьшается трафик, надежнее ипроще работа с локальными базами данных.
Обеспечение надежности и удобства работы особенно актуально в случае ненадежных и медленных каналовсвязи, что имеет место во многих сетях в России.В классических распределенных СУБД (РСУБД) необходимо управлятьодновременным доступом, что должно гарантировать целостность (сериализуемость) баз данных. Наиболее широко используются алгоритмы управления, основанные на механизме блокировки. При этом блокировкой называютситуацию, при которой некоторая транзакция объявила о желании получить полномочия на доступ к странице памяти и, следовательно, другие транзакции неимеют права занимать этот ресурс.Одним из способов управления является централизованное блокирование,при котором на одном из узлов поддерживается единая таблица блокировок.Такой узел устанавливает очередность выполнения транзакций, что исключаетконфликты.
Однако при централизованном управлении невысока надежность итребуется мощный сервер.В РСУБД с репликацией нет проблемы согласования при записи действиймногих узлов. Собственно тиражирование чаще всего выполняется по правилуполной эквивалентности — обновленные данные сразу же после изменившей ихтранзакции рассылаются по всем локальным базам данных. Чтение же выполняется из базы данных одного конкретного узла, наиболее близкого к пользователю в функциональном или географическом смысле.Сложнее решать проблемы распределенного управления, что требуется вРСУБД без тиражирования. Одним из распространенных протоколов распределенного управления является протокол двухфазной фиксации транзакций. На2775.
Методическое и программное обеспечение автоматизированных системпервой фазе инициатор транзакции (координатор) рассылает участникам выполнения транзакции оповещения о блокировке. В ответ узлы сообщают освоей готовности или неготовности. На второй фазе координатор сообщает либоо «глобальной фиксации», т. е.
о выполнении транзакции, либо об откате транзакции. Неприятности возможны при сбоях, которые могут оставить некоторыйузел в заблокированном состоянии: он не может ни выполнять транзакцию, ниотменять ее в одностороннем порядке.Интеллектуальные средства поддержкипринятия решенийВ общем случае полная формализация управления проектированием не может быть достигнута, поэтому полезную роль играют системы DSS (DecisionSupport Systems) поддержки решений, принимаемых людьми.
В качестве таких систем часто используют хранилища данных и OLAP-средства (On-LineAnalytical Processing).OLAP-средства должны обеспечивать оперативный доступ к данным, наоснове которого выявляются зависимости между параметрами (измерениямив многомерной модели приложения). В OLAP-системах на реляционных СУБДаналитическая обработка, или, другими словами, многомерный динамическийанализ данных, требует просмотра большого числа записей из разных таблиц.Поэтому производительность оказывается невысокой.
В специализированныхOLAP-системах, обеспечивающих более быстрый многомерный анализ, но сболее существенными ограничениями на объем базы данных, данные хранятся в виде гиперкубов или поликубов - многомерных таблиц с постоянным илипеременным числом ячеек соответственно. Пример OLAP-системы - OracleExpress, которая помогает менеджерам и аналитикам получать данные в видеразрезов таких многомерных таблиц, готовить отчеты, обосновывать решения.В составе подсистем управления методологией проектирования полезноиметь средства консультирования по принятию проектных решений. Они могутбыть представлены в виде множества модулей, объединяемых гипертекстовой оболочкой. Каждый модуль содержит некоторый совет по выбору решения, преодолению противоречий, возникающих в процессе проектирования.
Здесьуместно использование методов и приемов решения изобретательских задач.Интеграция ПО в САПРИнтеграция ПО базируется на идеях объектно-ориентированного программирования. Следует различать синтаксический и семантический аспекты интеграции. Синтаксическая интеграция реализуется с помощью унифицированных языков и форматов данных, технологий типа ODBC для доступа к общемубанку данных или компонентно-ориентированных (CBD - Component-BasedDevelopment) технологий.
Семантическая интеграция подразумевает автоматическое распознавание разными системами смысла передаваемых между нимиданных и достигается значительно труднее. Для создания ПО САПР, так же278J б Системные среды автоматизированных системкак и других сложных автоматизированных информационных систем, определяющее значение имеют вопросы интеграции ПО. Теоретической базой длясоздания технологий интеграции ПО в САПР являются:1) методология автоматизированного проектирования, в соответствии с которой осуществляются типизация проектных процедур и маршрутов проектирования в различных предметных областях, выявление типичных входных ивыходных данных процедур, построение информационных моделей приложенийи их обобщение, сравнительный анализ альтернативных методов и алгоритмоввыполнения типовых процедур;2) объектно-ориентированная методология, в соответствии с которой множества сущностей, фигурирующих в процессах проектирования, подразделяются на классы, в классах появляются свои процедуры и типы данных с отношениями наследования.
Эти классы могут быть инвариантными и прикладными.Их обобщение и унификация приводят к появлению таких понятий и средств,как интегрированные ресурсы и прикладные протоколы, фигурирующие в стандартах STEP, или унифицированные программные компоненты типа графических ядер конструкторских САПР. Именно наличие типовых процедур и единообразное толкование атрибутов объектов в рамках конкретных протоколовпозволяют разным программным системам «понимать» друг друга при взаимодействии.Наряду с типовыми графическими ядрами известны типовые ПМК имитационного моделирования, конструирования деталей и механизмов, технологической подготовки производства и др. Возможность использования типовыхпрограмм в составе программных комплексов обусловлена именно унификацией интерфейсов при обменах данными.В некоторых маршрутах проектирования обмены данными должны происходить с высокой частотой, что обусловливает специфические требования кинтерфейсам.
Примером могут служить задачи имитационного моделирования, в которых требуется имитировать взаимодействие процессов, описываемых с помощью различного МО (например, на сосредоточенном и распределенном иерархических уровнях или с помощью аналоговых и дискретныхмоделей). Для таких задач при моделировании характерно воспроизведениевременной последовательности событий, происходящих в анализируемых взаимодействующих системах. Соответственно взаимодействие программ моделирования может происходить через фиксированное число временных шаговили по мере совершения тех или иных событий в моделируемых системах.Так, в программах смешанного аналого-дискретного моделирования электронных устройств аналоговая часть моделируется с помощью программы анализа электронных схем, а дискретная часть - с помощью программы логического моделирования.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
