9. Разновидности и архитектуры информационных приложений

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

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

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

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

9.1. Обзор рынка готовых информационных приложений

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

Вообще, в компьютерном мире понятие стороннего поставщика (third-partycompany) имеет очень большое значение, поскольку значительная часть прикладного программного обеспечения производится именно небольшими независимыми софтверными компаниями.

9.1.1. Информационные приложения, поставляемые крупными компаниями производителями вычислительной техники и СУБД (Oracle, Hewlett-Packard, IBM, Microsoft и т.д.)

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

Начнем с компании Oracle. Представители этой компании любят представлять набор производимых продуктов в виде перевернутой пирамиды с вершиной внизу и основанием наверху. Вершине пирамиды соответствует базовый комплект серверов баз данных, предлагаемых компанией. В середине пирамиды располагаются средства проектирования и разработки баз данных и информационных систем (в частности, Designer/Developer 2000). Наконец, основанию пирамиды соответствуют готовые компоненты информационных приложений и законченные решения. Такая картина правильно отражает соотношения объемов и числа продуктов. Конечно, серверы баз данных - это наиболее сложные и ответственные продукты. Но их число и объем кода не очень велики. Средства проектирования и разработки опираются на использование серверов; эти продукты менее сложны, но более объемны. Наконец, приложения создаются с использованием средств проектирования и разработки; приложений много, и суммарный объем кода очень велик.

Oracle предлагает приложения (естественно, основанные на использовании серверов баз данных Oracle) для использования в следующих предметных областях:

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

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

В частности, имеются решения HP для применения в следующих сферах:

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

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

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

9.1.2. Приложения, предлагаемые третьими компаниями (пример: Catalyst компании SunMicrosystems)

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

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

9.2. Инструментальные средства создания пилотных версий приложений и разработки их законченных вариантов

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

9.2.1. Что такое "быстрая разработка приложений" (rapidapplicationdevelopment)

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

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

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

9.2.2. Пригодны ли средства быстрой разработки только на стадии пилотного проекта?

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

Заметим, что большая часть современных языков и инструментальных средств быстрой разработки приложений (например, Delphi компании Borland, PowerBuilder компании Sybase и т.д.) имеют несколько собственных интерфейсов с распространенными серверами баз данных, либо могут работать с ними через драйверы ODBC. Поэтому с архитектурной точки зрения быстро разработанное приложение вполне может соответствовать модели "клиент-сервер". Если же в дополнение к средствам быстрой разработки применяются такие серверные средства как хранимые процедуры, ограничения целостности и триггеры, то часть логики приложения может быть перенесена на сервер баз данных (фактически, это позволяет сформировать третье звено общей цепочки - сервер приложений).

9.2.3. Тенденции к сближению языков быстрой разработки и языков программирования. Что это дает?

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

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

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

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

9.2.4. Особенности инструментальных средств, предназначенных для разработки Intranet-приложений

Об Intranet-приложениях уже достаточно много говорилось в этом курсе. Тем не менее, для полноты мы немного обсудим особенности инструментальных средств Intranet-приложений и в этом пункте.

Не будем обсуждать базовые механизмы организации Web-ориентированных Intranet-приложений и, в частности, средства их интеграции с другими серверами (включая, естественно, серверы баз данных). Коснемся только языка Java, наиболее популярного на сегодня инструмента Internet/Intranet, и сопоставим особенности реализации и использования Java с языками быстрой разработки, упоминавшимися в предыдущих пунктах этого раздела.

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

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

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

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

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

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

9.3.1. Информационные системы, использующие серверы приложений

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

Рис. 9.1. Общее представление информационной системы в архитектуре "клиент-сервер"

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

(Здесь опять проявляются недостатки в терминологии. Обычно, когда компания объявляет о выпуске очередного сервера баз данных, то неявно понимается, что имеется и клиентская составляющая этого продукта. Сочетание "клиентская часть сервера баз данных" кажется несколько странным, но нам придется пользоваться именно этим термином.)

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

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

Здесь необходимо сделать еще два замечания:

1. Обычно компании, производящие развитые серверы баз данных, стремятся к тому, чтобы обеспечить возможность использования своих продуктов не только в стандартных на сегодняшний день TCP/IP-ориентированных сетях, но и в сетях, основанных на других протоколах (например, SNA или IPX/SPX). Поэтому при организации сетевых взаимодействий между клиентской и серверной частями СУБД часто используются не стандартные средства высокого уровня (например, механизмы программных гнезд или вызовов удаленных процедур), а собственно функционально подобные средства, менее зависящие от особенностей сетевых транспортных протоколов.
2. Когда мы говорим об интерфейсе на основе языка SQL, нужно отдавать себе отчет в том, что несмотря на титанические усилия по стандартизации этого языка, нет такой реализации, в которой стандартные средства языка не были бы расширены. Необдуманное использование расширений языка приводит к полной зависимости приложения от конкретного производителя сервера баз данных.

Посмотрим теперь, что же происходит на стороне сервера баз данных. В продуктах практически всех компаний сервер получает от клиента текст оператора на языке SQL.

• Сервер производит компиляцию полученного оператора. На основе информации, содержащейся в таблицах-каталогах базы данных производится преобразование непроцедурного представления оператора в некоторую процедуру его выполнения.
• Далее (если компиляция завершилась успешно) происходит выполнение оператора. Рассмотрим возможные действия операторов SQL:
• Оператор может относиться к классу операторов определения (или создания) объектов базы данных (точнее и правильнее было бы говорить про элементы схемы базы данных или про объекты метабазы данных). В частности, могут определяться домены, таблицы, ограничения целостности, триггеры, привилегии пользователей, хранимые процедуры. В любом случае, при выполнении оператора создания элемента схемы базы данных соответствующая информация помещается в таблицы-каталоги базы данных (в таблицы метабазы данных). Ограничения целостности обычно сохраняются в метабазе данных прямо в текстовом представлении. Для действий, определенных в триггерах, и хранимых процедур вырабатывается и сохраняется в таблицах-каталогах процедурный выполняемый код. Заметим, что ограничения целостности, триггеры и хранимые процедуры являются, в некотором смысле, представителями приложения в поддерживаемой сервером базе данных; они составляют основу серверной части приложения.
• При выполнении операторов выборки данных на основе содержимого затрагиваемых запросом таблиц и, возможно, с использованием поддерживаемых в базе данных индексов формируется результирующий набор данных. Серверная часть СУБД пересылает результат клиентской части, и окончательная обработка производится уже в клиентской части приложения.
• При выполнении операторов модификации содержимого базы данных (INSERT, UPDATE, DELETE) проверяется, что не будут нарушены определенные к этому моменту ограничения целостности (те, которые относятся к классу немедленно проверяемых), после чего выполняется соответствующее действие (сопровождаемое модификацией всех соответствующих индексов и журнализацией изменений). Далее сервер проверяет, не затрагивает ли данное изменение условие срабатывания какого-либо триггера, и если такой триггер обнаруживается, выполняет процедуру его действия. Эта процедура может включать дополнительные операторы модификации базы данных, которые могут вызвать срабатывание других триггеров и т.д. Можно считать, что те действия, которые выполняются на сервере баз данных при проверке удовлетворенности ограничений целостности и при срабатывании триггеров, представляют собой действия серверной части приложения.
• При выполнении операторов модификации схемы базы данных (добавления или удаления столбцов существующих таблиц, изменения типа данных существующего столбца существующей таблицы и т.д.) также могут срабатывать триггеры, т.е., другими словами, может выполняться серверная часть приложения.
• Аналогично, триггеры могут срабатывать при уничтожении объектов схемы базы данных (доменов, таблиц, ограничений целостности и т.д.).
• Особый класс операторов языка SQL составляют операторы вызова ранее определенных и сохраненных в базе данных хранимых процедур. Если хранимая процедура определяется с помощью достаточно развитого языка, включающего и непроцедурные операторы SQL, и чисто процедурные конструкции (например, языка PL/SQL компании Oracle), то в такую процедуру можно поместить серьезную часть приложения, которое при выполнении оператора вызова процедуры будет выполняться на стороне сервера, а не на стороне клиента.
• При выполнении оператора завершения транзакции сервер должен проверить соблюдение всех, так называемых, отложенных ограничений целостности (к таким ограничениям относятся ограничения, накладываемые на содержимое таблицы базы целиком или на несколько таблиц одновременно; например, суммарная зарплата сотрудников отдела 999 не должна превышать 150 млн. руб.). Снова к проверке отложенных ограничений целостности можно относиться как к выполнению серверной части приложения.

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

Рис. 9.2. Тонкий клиент и толстый сервер в клиент-серверной архитектуре

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

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

Рис. 9.3. Потолстевший клиент и толстый сервер в клиент-серверной архитектуре с поддержкой локального кэша на стороне клиентов

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

Рис. 9.4. Информационная система в архитектуре "клиент-сервер" с выделенным сервером приложений

Информационные системы в трехзвенном (или многозвенном исполнении) могут создаваться на основе использования промежуточного программного обеспечения мониторов распределенных транзакций, например, Tuxedo компании BEASystems, Inc. или Encina компании TransarcCorp.

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

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

Назад | Содержание | Вперед