1 ОСНОВНЫЕ ПОНЯТИЯ В зависимости от взаимного

§ 1 ОСНОВНЫЕ ПОНЯТИЯ В зависимости от взаимного расположения программы, использующей данные, и самих данных различают: - локальные БД; - удалённые БД. Локальная база данных Данные локальной БД (файлы данных) и работающие с ними приложения, располага ются на одном (локальном) компьютере

Удаленная база данных Удалённая БД размещается на компьютере – сервере сети, а приложение, осуществляющее работу с этой БД, находится на компьютере пользователя. Программа работы с удаленной БД состоит из двух частей: клиентской и серверной.

Архитектура БД – организация взаимодействия аппаратных средств. Архитектуры БД: - двухуровневая ( три модели ); - трёхуровневая ( одна модель ). Хранимые процедуры – это подпрограммы, расположенные и выполняемые на сервере, которые вызываются из приложений клиента

Триггеры – это специальный вид хранимой процедуры, которая находится на сервере БД и вызывается автоматически при изменении записей в БД. В отличие от хранимых процедур, триггер нельзя вызвать из приложения клиента, передать ему какой-то параметр и получить от него результат. Триггер вызывается автоматически при редактировании записи таблицы БД, добавлении или удалении записей ДО или ПОСЛЕ этих событий.

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

§ 2 АРХИТЕКТУРЫ УДАЛЁННЫХ БД 1) Двухуровневые архитектуры Модель файлового сервера Модель удалённого доступа к данным Модель активного сервера БД модели управления БД в которых сервер играет пассивную роль модель управления БД в которой сервер играет активную роль 2) Трёхуровневая архитектура «Клиент-сервер»

Двухуровневые модели управления БД в которых сервер играет пассивную роль Это модели «файл-сервер» и «клиент-сервер» . В этих моделях функции управления информационными ресурсами находятся на клиентской части. Отличаются эти архитектуры способами обработки информации.

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

Недостатки архитектуры «файл-сервер» : - при передачи по сети файлов БД, сеть оказывается перегруженной, что является причиной её низкого быстродействия и плохой производительности при работе с БД; - приложения, работающие с УБД, не только обрабатывает данные, но и управляют самой БД. Т. к. управление БД осуществляется с разных ПК, увеличивается вероятность нарушения достоверности передаваемой информации, т. е. снижается надёжность работы системы.

Преимущества архитектуры «клиент-сервер» : - при передачи по сети запросов на языке SQL (объём которых существенно меньше) и только результатов обработки данных по запросам клиентов резко снижается нагрузка на сеть, а следовательно увеличивается возможность подключения к БД большего числа пользователей, а значит увеличивается производительности работы с БД; - приложения, работающие с УБД, не управляют самой БД, управлением занимается только «сервер» . И это обеспечивает высокую степень защиты данных и повышает надёжность работы системы;

- разработка серверной части осуществляется на языке SQL, что повышает надёжность и производительность обработки данных; - разработку клиентской части можно выполнять с применением прикладных программных продуктов (Visual Basic, Microsoft Access, Delphi ), что значительно сокращает время разработки.

Модель файлового сервера (File Server - FS) Клиентская часть приложения включает в себя следующие части: - презентационная логика; - бизнес-логика; - связующие функции; - логические БД; - СУБД; - база метаданных (выбранных данных). Серверная часть приложения включает в себя: - файлы БД; - система управления функциями.

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

Бизнес-логика – это часть кода приложения, которая определяет собственно алгоритмы решения конкретных его задач. Код записывается с использованием языков программирования ( С, С++, Visual Basic, Object Pascal, …)

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

КЛИЕНТ Презентационная логика Бизнес- логика Связующие функции Файловые команды СЕРВЕР База данных Система управления функциями Блоки данных Логические БД СУБД База метаданных Рисунок 1 – Структура модели файлового сервера

Модель удалённого доступа к данным (Remote Data Access - RDA) Клиентская часть приложения включает в себя следующие части: - презентационная логика; - бизнес-логика; - служебные функции. Серверная часть приложения включает в себя: - БД с данными; - СУБД; - логика баз данных (отвечает за обработку данных); - база метаданных (выбранных данных).

Алгоритм действия модели: 1 Клиент обращается к серверу с запросами на языке SQL. 2 Сервер обрабатывает данные запросов и транзакций и отправляет результат клиенту.

КЛИЕНТ Презентационная логика Бизнес- логика Служебные функции СЕРВЕР SQL-запросы Результаты База данных Логика БД СУБД База метаданных Рисунок 2 – Структура модели удалённого доступа к данным

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

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

Алгоритм действия модели: 1 Клиент обращается к серверу с командой запуска хранимой процедуры. 2 Сервер выполняет эту процедуру, регистрирует все изменения в БД и возвращает клиенту данные выполненного запроса. Централизованный контроль выполняется с использованием механизма триггеров. Триггеры – это специального вида процедуры, которые срабатывают при возникновении определённого события в БД.

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

- возвращает клиенту данные выполненного запроса; - обеспечивает выполнение всех функций СУБД (доступ к данным, контроль и поддержку целостности данных в БД, обеспечение корректной параллельной работы всех пользователей с единой БД). Модель активного сервера БД поддерживают большинство современных СУБД ( Informix, Ingres, Sybase, Oracle, My. SQL Server).

КЛИЕНТ Презентационная логика Служебные функции Вызов процедур Результаты СЕРВЕР База данных Хранимые процедуры Триггеры СУБД База метаданных Рисунок 3 – Структура модели активного сервера базы данных

Трёхуровневая модель управления БД Эта модель является расширением двухуровневой модели БД «клиент-сервер» . Между «клиентом» и «сервером» ( для разгрузки «сервера» ) введён дополнительный промежуточный уровень, который содержит сервер приложений. В этой модели часть средств и кода, предназначенных для организации доступа к данным и их обработке ( общие для всех клиентских приложений ) из приложения-клиента выделено в сервер приложений.

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

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

КЛИЕНТ Презентационная логика Служебные функции СЕРВЕР ПРИЛОЖЕНИЙ Бизнес – логика СЕРВЕР Хранимые процедуры Триггеры СУБД База данных Рисунок 4 – Структура трёхуровневой модели управления базы данных

§ 3 ТЕХНОЛОГИИ ДОСТУПА К УБД Программы, которые обеспечивают доступ к информации сервера БД, разрабатываются с применением различных технологий: ODBC, COM, BDE, ADO, CORBA, . . . Все эти технологии основаны на единых принципах – объектных моделях доступа к УБД, и разрабатываются соответственно на методах объектно-ориентированного программирования.

Технология ODBC ( Open Data. Base Connectivity – открытый доступ к базам данных ) Эта технология фирмы Microsoft предусматривает использование единого интерфейса для доступа к разнородным реляционным БД. При этом язык SQL рассматривается как стандартное средство доступа к данным.

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

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

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

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

Технология СОМ (Component Object Model – компонентная модель объектов) Эта технология разработана фирмой Microsoft как средство взаимодействия приложений ( в том числе составных частей ОС Windows) для управления объектами БД, расположенных в пределах локальной сети. На этой технологии построен метод управления удалёнными объектами OLE.

Метод OLE (Object Linking and Embedding – связывание и объединение объектов) – это протокол, обеспечивающий обмен данными между приложениями. С помощью OLE можно внедрять объекты различных приложений ( в том числе и БД) в файлы других приложений. Каждый объект OLE характеризуется двумя компонентами: информацией и адресом нахождения этой информации.

Технология ADO ( Active. X Data Object ) Эта технология разработана фирмой Microsoft для трёхуровневой архитектуры. Схема работы клиента с сервером БД в технологии ADO: - установка соединения с сервером; - получение необходимых данных; - закрытие соединения; - обработка данных; - установка соединения для передачи изменённых данных обратно на сервер.

Основу ADO составляют два модуля: - провайдер данных; - резидентная реляционная БД. Провайдер данных Он отвечает за связь приложения с источником данных и за манипуляцию данными.

Провайдер включает в себя объекты: а) Connection – используется для установления соединения с источником данных и для управления транзакциями. б) Command – позволяет манипулировать данными источника и выполнять хранимые процедуры. в) Data. Adapter – использует объект Command для выполнения SQL команд. г) Data. Reader – обеспечивает считывание данных из источника.

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

Основные плюсы технологии АDО: - поддерживает БД различных типов как локальных, так и клиент-серверных; - во всех ОС Windows встроены драйверы ADO Основной минус технологии АDО: появление новых версий ОС Windows с новыми встроенными драйверами ADO, несовместимыми со старыми.

Технология BDE ( Borland Database Engine ) Эта технология позволяет обращаться к локальным и файл-серверным форматам БД d. Base, Fox. Pro, Paradox, к различным серверам SQL… Основной минус технологии BDE: На компьютере пользователя программы по работе с БД должен быть установлен BDE. Т. е. при установке программы на компьютер клиента необходимо включить в состав инсталяционного пакета установку BDE