Так как между двумя сущностями возможны связи в обоих на­ правлениях, то существуют еще два типа связи: многие - к - одному (М 1) и многие - ко - многим (М N).

Существуют и более сложные связи:

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

- тренарные связи (врач может назначить нескольких пациентов на несколько анализов, анализ может быть назначен несколькими врачами нескольким пациентам и пациент может быть назначен на несколько анализов несколькими врачами):

6.5. Классификация архитектур проектирования программного обеспечения

Подходы к организации систем управления с точки зрения программного обеспечения базируются на общей архитектуре “клиент - сервер”. Различие состоит только в том, что делают клиенты и серверы.

Классификация архитектур проектирования программного обеспечения систем управления не является абсолютно жесткой. В

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

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

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

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

Компании, производящие развитые серверы баз данных, стремят­ ся к тому, чтобы обеспечить возможность использования своих про­ дуктов не только в стандартных на сегодняшний день TCP/IP-ори­ ентированных сетях, но и в сетях, основанных на протоколах SNA

или IPX/SPX.

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

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

- при выполнении операторов определения (или создания) объектов базы данных, в частности, могут определяться домены,

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

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

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

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

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

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

и непроцедурные операторы SQL, и чисто процедурные конструкции (например, языка PL/SQL компании Oracle). В такую процедуру можно поместить серьезную часть приложения, которое при выпол­ нении оператора вызова процедуры будет выполняться на стороне сервера, а не на стороне клиента;

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

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

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

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

“клиенты” становятся более требовательными к техническим ресур­ сам, однако при этом и ресурсы сервера не уменьшаются.

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

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

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

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

Развитие глобальных вычислительных сетей Internet (e-mail, ftp, telnet, Gopher, www и т.д.) естественным образом повлияло на тех­ нологию создания корпоративных систем управления, породив новую архитектуру под названием Intranet. Intranet-система представляет собой корпоративную автоматизированную систему, в которой ис­ пользуются методы и средства Internet. Такая система может быть локальной, изолированной от глобальной вычислительной сети.

В //7/гаяе/-системе могут использоваться все возможные службы Internet, однако наибольшее внимание привлекает служба www (World Wide Web). Это обусловлено следующим:

- во-первых, применяя документы HTML, можно сравнительно просто разработать удобную для использования информационную структуру, которая в дальнейшем будет обслуживаться одним из готовых ^6-серверов;

- во-вторых, наличие нескольких готовых к использованию клиентских частей - браузеров (“обходчиков”) избавляет разра­ ботчиков от необходимости создавать собственные интерфейсы, предоставляя пользователям удобные и развитые механизмы доступа к информации. Структурная схема простой организации Intranet- системы приведена на рис. 6.7.

Рис. 6.7. Структурная схема простой организации Intranet-системы

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

Для того чтобы изменить информационное наполнение веб­ сервера, необходимо приостановить работу системы, внести изме­ нения в #7Ш ,-описания и только затем продолжить нормальное функционирование.

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

Использование внешних процедур обеспечивает также возмож­ ность модификации документов, поддерживаемых w ft-сервером, создание временных “виртуальных” HTML-страниц.

Основным программным продуктом, в среде которого разра­ батываются прикладные программы в Intranet, является язык Java. Мобильные коды (апплеты), полученные в результате компиляции Ляга-программы, могут быть привязаны к ЯГЖ-документу. В этом случае они поступают на сторону клиента вместе с документом и выполняются либо автоматически, либо по явному указанию. Апплет может быть специализирован как шлюз к серверу баз данных. Струк­ турная схема автоматизированной системы на базе /л/галеЛ-системы с использованием апплетов представлена на рис. 6.9.

Рис. 6.9. Доступ к базе данных на стороне клиента

Intranet-системы

Intranet является удобным и мощным средством разработки и использования СУ. Единственным недостатком подхода можно счи­ тать постоянное изменение механизмов и отсутствие стандартов.

Выбор архитектуры программного обеспечения и операци­ онной системы

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

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

Кроме выбора платформы, необходимо выяснить:

-будет ли это архитектура “файл - сервер”, “клиент - сервер” или Intranet;

-будет ли применяться 3-уровневая архитектура: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;

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

-будет ли база данных однородной, т.е. будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);

-будут ли для достижения должной производительности ис­ пользоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

Эти решения обычно принимаются на начальном этапе проек­ тирования (на этапе структурного анализа).

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