Классификация приложений для работы с базами данных

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

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

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

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

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

Те программы которые раньше назывались локальными (независимо от способа связи с СУБД), чаще всего сейчас входят в число одноуровневых приложений, так как обработка данных в них ведется в единственном месте. Клиент/серверные приложения стали делиться на двухуровневые (классический клиент/сервер) и трехуровневые (клиент/сервер с ПО промежуточного слоя).

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

Терминология

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

Объединение — это логическое отношение между двумя таблицами на основе внешнего ключа.

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

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

Словарь данных — специализированная база данных, используемая в приложениях Delphi для хранения наборов атрибутов. Также в него могут входить и структуры баз данных целиком. Словарь данных не может хранить данные об объектах окружающего мира.

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

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

Процессор баз данных Borland Database Engine (ВДЕ) 1. Архитектура ВДЕ является важнейшей составляющей частью механизма доступа к данным реализованного в Delphi.

Архитектура ВДЕ основана на драйверах которые обеспечивают обмен данными с конкретными СУБД. Ядро процессора БД составляет совокупность динамических библиотек, содержащих механизмы обмена данными, управления запросами, поддержки национальных языков и т. д. Назначение всех динамических библиотек представлено в таблице1.

В состав ВДЕ включены стандартные драйверы, обеспечивающие доступ к СУБД Paradox, dBase, Foxpro и текстовым файлом. Помимо этого в ВДЕ имеется простой механизм подключения любых драйверов ОДБС (например, Microsoft Access) т создание на их основе пакетов ОДВС.

Доступ к данным серверов SQL обеспечивает отдельная система драйверов-SQL Links. С их помощью в Delphi можно разрабатывать приложения для серверов Dracle 8, Sybase, ДВ2 и, естественно, Interbase.

Эта особенность архитектуры ВДЕ обеспечивает ряд существенных преимуществ.

1. Реальное разделение программного кода и механизм доступа к данным. Причем сам доступ также осуществляется на нескольких уровнях -ВДЕ, драйвера, сервера БД. Приложение Delphi для работы с БД можно настроить на использования с любой СУБД, для которой имеется соответствующий драйвер, буквально за несколько минут. При этом перекомпиляция самой программы не требуется. Плата за такую великолепную переносимость — скорость обмена данными через ВДЕ и драйверы несколько меньше чем напрямую между приложением и СУБД.

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