9 Июнь 2008

4. Организация взаимодействия серверной и клиентской частей. Технология ODBC.

написано в рубрике: Базы данных +УБД (Т) — Метки: , , — Михаил @ 21:00

Технология ODBC

Технология ODBC (Open DataBase Connectivity - совместимость открытых баз данных) разработана фирмой Microsoft для обеспечения возможности взаимосвязи между различными СУБД. Открытый интерфейс ODBC доступа к базам данных из приложений представляет собой интерфейс прикладного программирования в виде библиотеки функций, вызываемых из различных программных сред и позволяющих приложениям унифицировано обращаться на SQL к базам данных различных форматов.

Программные средства поддержки ODBC корпорация Microsoft обычно поставляет вместе с СУБД. На сегодня ODBC является стандартом, используемым целым рядом продуктов, в частности, PowerBuilder, FoxPro, Visual C++, Visual Basic, Delphi, Microsoft Access и многими другими.

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

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

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

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

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

Технология ODBC фирмы Microsoft предоставляет общий интерфейс для доступа к гетерогенным SQL-совместимым базам данных, причем в этой технологии язык SQL используется как стандартный механизм доступа к данным. Предоставляемый интерфейс (построенный на языке С) обеспечивает высокую степень взаимодействия: одно приложение может обращаться к разным SQL-совместимым СУБД посредством общего кода. Это позволяет разработчику создавать и распространять приложения «клиент/сервер» без учета особенностей конкретной СУБД.

Источники данных и ODBC

При использовании в клиентском приложении средств ODBC осуществляется обращение к определенному источнику данных, а через него - к СУБД, которую он представляет. При установке средств ODBC устанавливается общая подсистема ODBC и определяются пары «драйвер - база данных», которым задаются имена, используемые при установке соединения с базой данных. Соответствующие пары называются DSN (Data Sours Name) - имена источников данных или поименованные источники данных.

Создание источника данных выполняется с помощью утилиты ODBC Data Sours Administrator, вызываемой из окна панели управления. В состав параметров источника данных входят: имя и описание источника данных; сервер, с которым устанавливается соединение; метод аутентификации; имя базы данных.

Существует три основных вида источников данных: пользовательский, файловый и системный.

Пользовательские источники данных Доступ к источникам данных, перечисленных в списке на вкладке User DSN (Пользовательский источник данных) окна ODBC Data Sours Administrator (Администрирование источников данных ODBC), производится только от имени учетной записи того пользователя, который их создал. Настройка пользовательских источников данных сходна с настройкой системных источников данных.. Если в сообщении об ошибке говорится об отсутствии источника данных, прежде всего необходимо проверить, не пользовательский ли это DSN. Если это так, то необходимо преобразовать его в файловый или системный источник данных.

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

Если необходимо использовать источник данных на другом компьютере, первое, что нужно сделать для этого – убедиться, что на этом компьютере установлен соответствующий драйвер. Например, нельзя использовать файловый источник данных для Access, если на компьютере отсутствует драйвер ODBC для Microsoft Access.

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

1. Архитектура «клиент-сервер». Уровни систем «клиент-сервер».

написано в рубрике: Базы данных +УБД (Т) — Метки: , — Михаил @ 20:58

Распределенные системы - это системы “клиент-сервер”. Существует по меньшей мере три модели “клиент-сервер”:

· Модель доступа к удаленным данным (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), которые и составляют предмет нашей профессиональной деятельности и базовый инструментарий при реализации больших проектов.

Технология клиент-сервер

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

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

Уровни системы клиент-сервер

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

· GUI - графический пользовательский интерфейс. Состоит из окон, экранов и т. д.

· бизнес-логика - это часть программы, имеющая дело с расчетами.

· база данных, СУБД, занимающаяся хранением и получением данных.

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

Двухуровневая система

В основе своей двухуровневая система имеет GUI и бизнес-логику с прямым доступом к базе данных. GUI находится на системе клиента, а база данных - либо у клиента, либо на сервере. Обычно GUI пишется на C++, Visual Basic, Access Basic и т.д. Типичными базами данных являются MIcrosoft Access, Personal Oracle и т.д.

Трехуровневые системы

Большинство клиент-серверных приложений следуют сегодня трехуровневой стратегии, при которой GUI, бизнес-логика и базы данных логически разбиты на три слоя. Здесь GUI пишется на Visual Basic, C++ или Power Builder, средствами разработки среднего слоя также служит C++ или Visual Basic. В качестве базы данных используются Oracle, Microsoft SQLServer и т.д. Трехуровневая концепция дала начало эпохе серверов баз данных, серверов приложений и клиентских GUI-машин. Такие операционные системы как UNIX, Windows NT и Solaris правят в мире серверов баз данных и приложений. Клиентские операционные системы (Windows) популярны среди разработчиков GUI. Двухуровневая архитектура может быть дополнена третьим программным уровнем во избежание встраивания логики приложения как в клиентскую часть, так и в базу данных. В трехуровневой архитектуре большая часть логики приложения зафиксирована на среднем уровне. В подобной архитектуре при изменении направления деловой активности или бизнес-процессов меняется только программное обеспечение программного слоя.

Многоуровневые системы

Сейчас, во времена Internet и Java изменились взгляды на отношения клиента и компьютерной сети. Апплеты Java с их объектами и методами привели к возникновению идеи многоуровневой клиент-серверной системы. Теоретически апплет Java может содержать бизнес-логику, GUI или СУБД. Каждый апплет можно рассматривать как отдельный слой. Концепция объектно-ориентированных многоуровневых систем возникла до появления Internet и Java. Архитектуры CORBA фирмы OMG и OLE (теперь ActiveX) фирмы Microsoft являются первыми модульными объектно-ориентированными системами, работающими на разных платформах. Internet и Java упростили реализацию этой концепции. Конструкция и реализация систем прошли путь от двух и трехуровневой архитектуры до современных межсетевых многоуровневых архитектур, основанных на апплетах Java.

© Проект «Студенты-Программеры»., 2008. Все права защищены.
Перепечатка материалов только при наличии активной ссылки на источник.
Powered by WordPress