Настройка драйверов и системной информации

После установки СУБД необходима ее настройка[17]. Обычно такая настройка сводится к установке и настройке драйверов СУБД, необходимых для работы с ней из других приложений, а также к заданию некоторых параметров СУБД, влияющих на ее функционирование.

В подавляющем большинстве случаев, основной драйвер для доступа к СУБД (по протоколу TCP/IP) устанавливается и настраивается автоматически в процессе инсталляции СУБД. Наибольшее распространение получили драйверы для следующих технологий доступа к СУБД (слайд 2):

– ODBC (Open Database Connectivity) – унифицированный доступ к СУБД из языка программирования высокого уровня;

– JDBC (Java Database Connectivity) – платформонезависимый доступ к СУБД из языка программирования Java;

– ADO (ActiveX Data Objects) – более современный доступ к базам данных, пришедший на смену ODBC.

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

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

Обычно настройка ODBC-драйвера сводится к созданию и настройке источника данных (базы данных) (слайд 3). Часть параметров может задаваться при соединении с сервером базы данных. Таким образом, часть настроек может задаваться статически, а часть – динамически. Причем эти множества настроек могут иметь пересечения, но в большинстве случаев не совпадают.

Управление такими источниками данных производится с помощью средства администрирования «Источники данных (ODBC)» (Пуск – Панель управления – Администрирование – Источники данных). При его запуске на экране появляется следующее окно (слайд 4). При нажатии на кнопку «Добавить» пользователю предоставляется возможность выбора ODBC-драйвера (из списка установленных). Затем появляется окно редактирования параметров источника данных (оно же возникает при нажатии на кнопку «Настройка» для существующего источника).

Внешний вид окна и состав параметров зависят от выбранной СУБД и могут сильно различаться (на слайде 5 приведен пример окна настройки СУБД Postgres v.8.2).

Однако в подавляющем большинстве случаев необходимо задать (слайд 6):

– логическое имя источника данных;

– логическое имя базы данных на сервере;

– имя (или ip-адрес) и номер порта сервера базы данных (в сети);

– логин и пароль пользователя (в базе данных), от имени которого будет осуществляться доступ.

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

Настройка JDBC-драйвера обычно устроена более сложно (слайд 7). Сам драйвер может представлять собой файл DLL или пакет языка Java (*.jar). При этом часть настроек задается в файле конфигурации, а часть может задаваться динамически при обращении к драйверу.

Для использования технологии ADO можно пользоваться и ODBC-драйверами. Однако в состав некоторых современных СУБД (например, Postgres) включаются специальные драйверы для использования с технологией ADO (слайд 8).

Для СУБД, не предоставляющих доступ к базе данных по технологии клиент-сервер, создание и настройка источников информации могут производиться несколько иным способом. Например, при настройке источника данных СУБД MS Access необходимо выбрать файл базы данных (*.mdb). Если такой файл размещен на сервере (или другой машине), к нему должен быть предоставлен доступ. В случае СУБД MS Visual FoxPro предоставляется выбор: указать при настройке источника данных файл базы данных (*.dbc) или указать путь к файлам – отдельным таблицам базы данных.

Создание таблиц

Как отмечалось выше, создание таблиц в базе данных возможно несколькими способами (слайд 10):

1) путем выполнения сценария;

2) через встроенные средства администрирования СУБД;

3) с помощью CASE-средств;

4) средствами языка программирования;

5) с помощью среды разработки языка программирования.

В промышленных условиях наибольшее распространение получил первый способ. Сценарий представляет собой текстовый файл, содержащий множество команд создания таблиц на языке SQL (create table) (слайд 11). Он запускается на выполнение с помощью средств администрирования, водящих в комплект поставки СУБД. В результате создается база данных с заданной структурой. В сценарий также могут помещаться команды создания триггеров, хранимых процедур, индексов, представлений и т.п. Обычно, в начале сценария обычно помещают команды удаления (drop table) одноименных таблиц. Это позволяет снизить трудоемкость изменения структуры базы данных. Достаточно отредактировать сценарий и снова запустить его.

Второй способ предполагает использование встроенных средств администрирования СУБД (в том числе визуальных). В некоторых СУБД такие визуальные средства входят в стандартный комплект поставки (например, в MS SQL Server, Oracle Database, MS Visual FoxPro и т.п.), а в других либо не поставляются вообще, либо поставляются сторонними разработчиками. Следует отметить, что в промышленных условиях этот способ чаще используется для оперативного изменения структуры базы данных.

Основой для третьего способа (слайд 12) служит то обстоятельство, что общие принципы структурного моделирования реляционных баз данных унифицированы, разработаны соответствующие стандарты (например, IDEF1x). Это позволило создать достаточно универсальные автоматизированные инструменты (CASE-средства) для управления структурой базы данных (например, AllFusion ERWin Data Modeler). Преимущество такого способа заключается в том, что CASE-средства как правило поддерживают несколько СУБД разных производителей, а также реализуют дополнительные механизмы (например, автоматизированное преобразование концептуальной информационной модели в структуру базы данных).

Четвертый способ предполагает управление структурой базы данных путем выполнения соответствующих SQL-команд (create table, alter table, drop table). Он является наиболее сложным и поэтому имеет ограниченное применение. Например, в специфических ситуациях, когда структуру базы данных необходимо корректировать в ходе эксплуатации приложения.

Последним пятым способом является применение встроенных средств управления структурой базы данных, которые входят в состав некоторых сред разработки. Например, в Borland Delphi v.7 имеется средство Database Desktop. Оно позволяет управлять структурой локальной базы данных. Средство SQL Explorer позволяет просматривать структуру баз данных, создавать новые базы данных, а также при необходимости управлять их структурой путем выполнения соответствующих SQL-команд.

Работа с запросами

Как отмечалось выше, запросы к базе данных можно выполнять следующими способами (слайд 13):

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

– с помощью параметризованных запросов.

В первом случае основное внимание разработчика сосредоточено на настройке (по большей части в визуальном режиме) соответствующих компонентов. Этот способ в чем-то напоминает метод формирования запросов в языке QBE (Query By Example).

Во втором случае используется компонент обработки запросов (например, типа TQuery). При этом основное внимание разработчика сосредоточено на построении SQL-выражения.

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

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

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

[2] Для реляционной СУБД MS SQL Server 2000 реализован импорт/экспорт документов, представленных в XML-формате, в том числе с использованием схем сопоставления, определяющих соотношение элементов XDR-схем таблицам, а атрибутов – столбцам.

[3] Применяемые формальные языки представления предметной области не позволяют описывать все отношения, которые проектировщик считает важными. С другой стороны, многие проекты (и, в частности, рассматриваемые примеры) воспринимаются как достаточно простые, а проектные решения кажутся очевидными. Кроме того, опытный программист всегда может предложить некоторый эмпирический и, возможно, действительно эффективный способ для целевого представления и обработки нужной информации. Однако это означает отказ от единого формализма, что при увеличении количества данных и связей значительно усложняет проблемы управления базой и в частности – понимание пользователем организации и методов доступа.

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

[5] Такое определение связи, как сущности особого рода, отражает существо реляционного подхода, для которого характерно единообразное представление сущностей всех типов, включая связи, посредством переменных-отношений.

[6] В большинстве CASE-систем принята упрощенная форма: эта ассоциация всегда должна быть бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).

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

[8] Строго говоря, делает модель неадекватной.

[9] Поскольку в модель предметной области добавляются сущности, не присутствующие в самой предметной области.

[10] Не путать со второй нормальной формой, обозначаемой 2НФ.

[11] Справедливости ражи, следует отметить, что на практике еще имеется ряд проблем применения ОО подхода. Однако он уже прочно занял свое место.

[12] Заинтересовавшемуся читателю можно рекомендовать для начала книгу: Теоретически основы проектирования оптимальных структур распределенных баз данных. Серия «Информатизация России на пороге XXI века» / В.В. Кульба., С.С. Ковалевский, С.А. Косяченко и др. – М.: СИНТЕГ, 1999. – 660 с.

[13] Если в документе одновременно используются HTML и XML, то принято вводить элементы XML строчными, а элементы HTML прописными буквами.

[14] В некоторых операционных системах, например IBM, файл на внешних носителях называют набором данных в отличие от логического файла.

[15] Адресация данных по имени поля.

[16] Можно пользоваться производными объектами, специализированными по типам данных (TIntegerField, TStringField и т.п.).

[17] Часть настроек выполняется в процессе установки СУБД.