Анализ архитектур OLTP – систем

 

Наиболее распространёнными сегодня являются OLTP – системы или, просто, базы данных, и именно на их основе строятся все остальные типы информационных систем. Поэтому рассмотрим применяемые в САПР архитектуры OLTP – систем подробнее.

Все базы данных принято делить на две категории:

· централизованные;

· распределённые.

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

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

В свою очередь, централизованные базы данных делят также на две категории:

· с архитектурой “файл-сервер”;

· с архитектурой “клиент-север”, причём в рамках этой категории БД подразделяют на двухслойные (2-tier), трёхслойные (3-tier) и многослойные (n-tier).

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

Если БД и приложение-клиент выполнены в одной и той же СУБД (например, ACCESS, Visual FoxPro или Paradox), то часто такой комплекс называют локальной или настольной базой данных.

Кардинальных различий между локальной архитектурой и файл – серверной архитектурой нет. И в том и в ином случае в качестве СУБД применяются, так называемые, “персональные”, или “локальные”, или “настольные” СУБД, такие как Paradox, dBase, Access, FoxPro и другие. Просто локальные базы данных с возможностью доступа клиентов к файлам базы данных в пределах одного компьютера, с появлением сетевых компьютерных технологий превратились в системы коллективного доступа файл - серверной архитектуры с возможностью доступа клиентов к файлам БД с различных компьютеров.

Архитектуру файл-сервер применяют в локальных одно-ранговых сетях при небольшом (5-7) числе клиентов. Главными недостатками файл - серверной архитектуры являются:

· большой сетевой трафик в силу того, что каждый клиент вынужден создавать собственную копию БД на своём компьютере;

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

В основе архитектуры клиент-сервер лежит концепция, что кроме пассивной роли хранения данных центральный сервер должен быть самостоятельным приложением (или службой операционной системы) и выполнять определённую часть обработки данных, в частности, управлять контролем доступа к данным со стороны клиентов. Клиенты обращаются к центральному серверу посредством языка структурированных запросов (SQL, Structured Query Language), на котором описывается задача или список задач, подлежащих выполнению сервером. Сервер идентифицирует пользователя, проверяет его права, выполняет поставленную задачу и отправляет пользователю результирующий набор данных или информацию об изменённой структуре базы данных. Функциональные задачи всего приложения (бизнес – правила) решаются в составе приложения – клиента и последнего называют в таком случае “толстым клиентом”. Альтернативным вариантом клиент – серверной технологии с ”толстым клиентом” является вариант, когда функциональные задачи всего приложения также выполняются на сервере, а приложение – клиент осуществляет лишь предоставление информации конечному пользователю в требуемой форме. В таком случае приложение – клиент называется “тонким клиентом”.

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

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

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

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

Если приложение-клиент и база данных созданы в одной и той же среде: dBase, Paradox, Visual FoxPro, Oracle, то таким посредником является сама СУБД. Если приложение-клиент и база данных созданы в Access, то посредником между приложением и БД служит ядро Access, называемое машиной баз данных Jet. В случае создания приложения-клиента в Delphi посредником между этим приложением и БД служит, так называемая, машина баз данных Борланда (BDE-Borland Database Engine), являющаяся самостоятельным приложением операционной системы и представляющая собой набор драйверов для доступа к различным базам данных, управляемых программой-Администратором.

До недавнего времени универсальным и единственным посредником между приложением-клиентом, созданным в одной среде разработки и базой данных, созданной в другой среде (СУБД), являлось приложение Windows ODBC (Open Database Connectivity), так называемый открытый протокол Microsoft доступа к базам данных. Он представляет собой набор драйверов доступа к различным базам данных, управляемых своей программой-Администратором. В настоящее время этот стандарт вошёл в качестве составной части в более универсальную и широкую модель связи практически любых потребителей данных с практически любыми поставщиками данных, так называемую ADO OLEDB.

ADO создано с целью лёгкого её использования на уровне интерфейса приложений для любого OLE DB провайдера данных (программного продукта, предоставляющего доступ к данным по технологии OLE DB), включая реляционные и не реляционные базы данных, электронную почту (e-mail) и файловые системы, текст и графику, объекты специального назначения, а также существующие ODBC-источники данных. Другими словами, любые данные, существующие в виртуальном информационном пространстве предприятия, являются доступными посредством ADO-технологии доступа к данным.

ADO не зависит от языка программирования и использует сетевые ресурсы в минимальной степени. Эта модель имеет несколько слоёв между клиентским приложением и источником данных.

Главными характеристиками ADO являются:

· лёгкость в использовании;

· высокая производительность;

· программное управление курсорами;

· комплексные типы курсоров, включая пакеты и курсоры, как на стороне сервера, так и на стороне клиента;

· способность возвращать различные результирующие наборы данных по одному запросу;

· синхронное, асинхронное и событийно управляемое выполнение запроса;

· возможность многократного использования объектов с изменяемыми свойствами;

· совершенное управление кэшированием наборов данных;

· гибкость - эта технология работает как с существующими технологиями баз данных, так и всеми OLE DB провайдерами;

· великолепное выявление ошибок.

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

Объектная модель ADO представляет собой набор программируемых объектов, поддерживающих технологии Component Object Model (COM) и OLE Automation. Она является плоской (содержит несколько объектов одного уровня) и проще в использовании, чем предшествующие ей модели DAO и RDO.

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

При рассмотрении архитектуры клиент – сервер под сервером молчаливо понимается SQL –сервер баз данных, такой как, например: MS SQL Server, Oracle, DB2, Informix и т.п. В тоже же время, локальные СУБД, такие как Access и Visual FoxPro могут выступать в роли COM-серверов, предоставляя другим приложениям свои многочисленные сервисы, т.е. любое приложение, выступающее в роли клиента может управлять сервером, посредством выполнения его собственных команд. Такая технология, называемая OLE Automation, революционным образом изменила архитектуру программной среды поддержки принятия проектных решений и в дополнение к централизованной схеме: SQL-сервер – тонкие клиенты добавила возможность создавать противоположную схему: “сверх толстый клиент – COM серверы”. Соответственно являются корректными и все промежуточные решения.

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