Балакина Е.П., Логинова Л.Н. Управление данными в Delphi

Подождите немного. Документ загружается.

1. Введение

Для доступа к данным в приложениях Delphi существуют

традиционные инструменты, такие как Borland Database Engine

(BDE) и ODBC

(Open DataBase Connectivity).

В середине 1990-х годов, с развитием и распространением

технологии COM (Component Object Model), компания Microsoft

объявила о постепенном переходе от ODBC к использованию новой

технологии OLE DB

(Object Linking and Embedding, Database).

Считается, что OLE DB является интерфейсом системного уровня,

который используется системными программистами. Чтобы

облегчить работу с OLE DB, был создан дополнительный прикладной

уровень, который получил название ADO (ActiveX Data Objects). По

своим возможностям технология ADO напоминает BDE: так же как и

BDE, ADO поддерживает навигацию, манипулирование наборами

данных, обработку транзакций, кэшируемые обновления.

ADO обладает рядом достоинств:

o в компонентах ADO не возникает известных проблем с

кириллицей,

o так как ADO является разработкой Microsoft, то требуемое

программное обеспечение включено во все поставки

современных версий Microsoft.

Однако технология ADO обладает некоторыми недостатками,

например, не все источники данных могут работать со всеми типами

данных.

2. Компоненты ADO

Для работы с ADO в Delphi предусмотрены компоненты,

расположенные на странице библиотеки ADO (см. рис. Рис. 1). Они

инкапсулируют такие объекты ADO как Connection, Command и

RecordSet.

Система управления базами данных

Открытый интерфейс доступа к базам данных, разработанный фирмой Microsoft

Набор интерфейсов, основанных на COM, которые позволяют приложениям обращаться к

данным, хранимым в разных источниках информации или хранилищах данных с помощью

унифицированного доступа.

Рис. 1

Связь с базой данных в технологии ADO осуществляется

цепочкой:

Набор данных Источник данных Компонент управления и

отображения данных.

Компоненты ADO используются для связи с набором данных;

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

визуализации и управления данными используется компонент

DataSourse. Для визуализации и управления данными применяются

компоненты DBGrid, DBText, DBNavigator и многие другие.

В технологии ADO используются следующие компоненты:

 ADOTable

 ADOQuery

 ADOStoredproc

 ADOConnection

 ADODataSet



ADOCommand

2.1. Компонент ADOConnection

Данный компонент связывается с набором данных

ADO.

Компонент ADOConnection позволяет вам должным образом

настроить процедуру аутентификации, контролировать транзакции,

напрямую выполнять команды, адресованные БД, кроме того, он

позволяет сократить количество подключений, существующих в

рамках приложения.

Для использования данного компонента необходимо

разместить его на форме (см рис. Рис. 2) и настроить его свойство

ConnectionString.

Под набором данных понимается база данных

Рис. 2

Настроить свойство ConnectionString можно двумя способами:

1. Задать определенные параметры свойства ConnectionString в

Инспекторе Объектов (Оbject Inspector),

2. Вызвать редактор строки подключения

2.1. Рассмотрим соединение с базой данных через свойство

ConnectionString. Данное свойство представляет собой строку,

содержащую в себе несколько параметров соединения, которые

разделяются друг от друга точками с запятой:

Provider – имя провайдера, используемое для соединения,

File name – имя файла, содержащего информацию о соединении,

Remote provider – имя провайдера, используемое со стороны клиента,

Remote Server – путь и имя сервера.

Кроме этих параметров, строка соединения может включать в

себя и другие параметры, такие как идентификатор, пароль и другое.

2.2. Описанный в п.2.1 способ задания связи с базой данных довольно

сложен. Настроим компонент ADOConnection на связь с базой данных

через редактор строки подключения. Для этого необходимо либо

нажать двойным щелчком по компоненту ADOConnection, либо

нажать на кнопку с многоточием около свойства ConnectionString в

Инспекторе Объектов (Оbject Inspector). В появившемся окне (см.

рис. Рис. 3) расположены две радиокнопки:

- данная опция позволяет связывать базу данных с

компонентом ADOConnection через файл связи udl,

- позволяет в режиме диалога настроить связь

базу данных и компонента ADOConnection.

Рис. 3

При выборе первой радиокнопки

необходимо указать Data Link File –файл связи с данными. Это файл

должен содержать информацию о базе данных, с которой мы

собираемся работать. Файл может иметь любое расширение, но

обычно это файл с расширением .udl, оформленный в виде ini-файла

Файл можно создать в любом текстовом редакторе, в теле файла

необходимо описать такие параметры как имя провайдера

, имя

набора данных (базы банных) и др., например:

[oledb]

Provider=Microsoft.Jet.OLEDB.4.0;

Data Source=F:\new.mdb

После сохранения файла с расширением .udl и закрытия,

пиктограмма файла связи данных принимаем вид:

ini-файл (от англ. Initialization file)H—файл конфигурации, который содержит данные настроек

приложения.

Провайдер - это часть программного обеспечения, в которой реализованы интерфейсы OLE

DB, обеспечивают доступ к источникам данных.

При выборе второй радиокнопки и

нажатии на кнопку появляется окно реактора строки

подключения

(см. рис. Рис. 5).

Рис. 4

В окне редактора строки подключения необходимо указать

провайдера. Для работы с системой управления базами данных

Microsoft Access необходимо указать провайдера

, затем перейти на вкладку

«Подключение» (см рис.HРис. 5), которая определяет необходимые

связные параметры для выбранного провайдера: путь к базе данных, а

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

случае, если пароль не нужен, необходимо выбрать «Пустой пароль»,

для сохранения введенного пароля выбрать «Разрешить сохранение

пароля». с помощью кнопки «Проверить подключение» можно

протестировать созданную связь. Для провайдера MicrosoftJet 4.0

OLE DB Provider этих данных вполне достаточно, для других

провайдеров может потребоваться задать ряд дополнительных

Данное окно так же появляется при двойном нажатии на файл связи данных.

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

пароль для доступа к серверу БД и т. п.

На вкладке «Дополнительно» с помощью флажков можно

указать, какой режим доступа к набору данных разрешен:

 Read—только чтение;

 ReadWrite — чтение и запись;

 Share Deny None — режим совместной работы невозможен;

 Share Deny Read — нельзя совместно использовать данные,

открытые в режиме чтения;

 Share Deny Write — нельзя совместно использовать данные,

открытые в режиме записи;

 Share Exclusive — нельзя совместно использовать данные,

открытые в режиме чтения и/или записи;

 Write – только запись.

Рис. 5

На вкладке «Все» приведены параметры, заданные явно и по

умолчанию. В случае необходимости значения параметров можно

изменить, для этого необходимо сначала указать какой параметр

желаете изменить, а потом нажать на кнопку «Изменить значение».

Соединение с базой данных осуществляется с помощью

метода Open, содержащего два параметра: UserID– идентификатор

пользователя, Password – пароль пользователя. Эти параметры не

являются обязательными. Необходимость ввода пароля и

идентификатора пользователя задается в свойстве LoginPromt. При

необходимости задания пароля свойство LoginPromt=true; в

противном случае LoginPromt=false; в этом случае пароль можно не

задавать ни в строке соединения, ни при вызове метода Open. Закрыть

соединение с базой данных можно с помошью метода Close.

Для проверки соединения компонента ADOConnection с базой

данных можно использовать свойство KeepConnection: равно true при

наличии соединения, в противном случае KeepConnection=false.

Другим способом соединения или разрыва соединения с базой

данных является установка свойства Connected соответственно в true

или false.

Соединение с базой данных может работать в синхронном или

асинхронном режиме - свойство ConnectOptions:

ConnectOptions=coСonnectUnspecified в синхронном режиме,

ConnectOptions=coAsyncСonnect в асинхронном режиме.

Синхронное соединение всегда ожидает результат последнего

запроса, асинхронное соединение может выполнять новые запросы,

не дожидаясь ответа от предыдущих запросов.

2.1.1. Курсоры

В основе ADO лежит объект Recordset, который является

результатом ADOTable или ADOQuery команды. Когда ADO-

приложение получает строки из базы данных, то объект ADO

Recordset формирует необходимую информацию и операции,

допустимые для получаемых данных (добавление, удаление,

изменение). При этом ADO использует курсоры, чтобы хранить набор

строк для обработанной записи. Так же курсор содержит в себе

текущую позицию в записи (recordset). Обычно, при разработке

приложения, курсоры используются при создании записей, а так же

при перемещении по записям (вперёд или назад).

Курсоры различаются по расположению и типу.

Расположение курсора задается свойством CursorLocation,

которое определяет способы извлечения и изменения данных При

расположении курсора на стороне сервера необходимо задать

свойство CursorLocation=clUseServer, в случае если курсор

расположен на стороне клиента - CursorLocation= clUseСlient.

Выбор типа курсора влияет на функциональность и

производительность базы данных.

Примечание: Клиентский курсор обслуживается механизмом

ADO Cursor Engine. Этот механизм является превосходным

примером провайдера обслуживания OLE DB: он

обеспечивает обслуживание для других провайдеров OLDE

DB. Механизм ADO Cursor Engine управляет обработкой

данных на стороне клиента. При открытии набора данных все

данные результирующего набора перекачиваются с сервера на

клиентский компьютер. После этого данные хранятся в

памяти, их обновление и обработка осуществляется с

использованием ADO Cursor Engine. Преимущество состоит в

том, что после передачи данных на сторону клиента любые

манипуляции с этими данными выполняются значительно

быстрее. Кроме того, так как манипуляции выполняются в

памяти, механизм ADO Cursor Engine обладает более

широкими возможностями, чем любой из курсоров,

работающих на стороне сервера.

Курсор на стороне сервера управляется самой

системой RDBMS. В клиент-серверной архитектуре,

основанной на таких продуктах, как SQL Server, Oracle или

InterBase, это означает, что управление курсором

осуществляется на удаленном серверном компьютере. Если

речь идет о настольной базе данных, такой как Access или

Paradox, серверный курсор управляется программным

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

курсор расположен на «сервере», однако физически база

данных вместе с курсором располагается на клиентском

компьютере. Как правило, серверные курсоры загружаются

быстрее, чем клиентские курсоры, так как при открытии

набора данных с серверным курсором нет необходимости

перемещать все данные на сторону клиента. Благодаря этому

серверные курсоры лучше подходят для обслуживания

больших наборов данных, то есть тогда, когда клиентский

компьютер не обладает объемом памяти, достаточным для

хранения всего набора данных.

Еще одной характеристикой, на которую следует

обратить внимание при выборе местоположения курсора,

является масштабируемость. Серверные курсоры

располагаются на стороне сервера. Чем больше пользователей

подключается к базе, тем больше курсоров создается на

сервере. С каждым новым курсором нагрузка на сервер

возрастает. Таким образом, при увеличении количества

пользователей общая производительность системы может

существенно понизиться. Используя курсоры на стороне

клиента, вы можете существенно повысить масштабируемость

приложения. Открытие клиентского курсора обойдется

дороже, так как в процессе открытия все данные передаются

на сторону клиента, однако обслуживание клиентского

курсора менее обременительно для сервера, ведь основная

связанная с этим нагрузка возлагается на клиентский

компьютер.

Тип курсора влияет на то, как будут происходить

чтение и обновление данных. По типу различают следующие

курсоры:

 Unspecified (неуказанный) – неопределенный- данный тип

курсора практически не используется в Delphi;

 Forward-only (только вперед) – данные курсоры

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

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

начала к концу. Курсор считывает количество записей,

указанное в свойстве CacheSize

, с сервера (по умолчанию

CacheSize =1). Данный тип курсора не совсем подходит для

формирования пользовательского интерфейса, в котором

пользователь обладает возможностью контролировать

направление перемещения. Однако, его можно вполне

применять для выполнения пакетных операции,

формирования отчетов, других действий, которые не

сохраняют информацию о состоянии, — в любой из этих

ситуаций вы начинаете с начала набора данных и

перемещаетесь по направлению к концу набора данных. По

достижении конца набор данных закрывается.

 Static (статический) - набор данных полностью перемещается

на сторону клиента, обращение к нему осуществляется при

помощи окна размером CacheSize. В результате пользователь

получает возможность перемещаться по набору данных в

обоих направлениях. Недостаток заключается в том, что

данные являются статическими — обновления, добавления и

удаления записей, выполняемые другими пользователями, не

видны для статического курсора, так как данные курсора уже

прочитаны.

 Keyset (набор ключей) – при данном типе курсора при

открытии набора данных с сервера читается полный список

всех ключей. Набор ключей хранится на стороне клиента до

закрытия курсора. Когда приложение нуждается в данных,

провайдер OLE DB читает строки таблицы, используя для

этой цели имеющийся у него набор ключей. В результате

клиент всегда имеет дело с обновленными данными. Однако,

после открытия курсора в этот набор нельзя добавить новые

ключи и нельзя удалить ключ из набора ключей, что и

определяет понятие статичности, т.е. если один пользователь

добавляет в таблицу новые записи, эти изменения не будут

видны для другого пользователя. Удаленные записи

становятся недоступными, а любые изменения в первичных

Свойство CacheSize указывает сколько записей заносится в локальный буфер оперативной

памяти (в локальном кэше).