 |
Установки параметров драйвера INTERBASE
Дата добавления: 2014-11-24 | Просмотров: 1512
|
|
VERSION - неизменяемый параметр. Содержит версию драйвера InterBase.
TYPE - значение SERVER указывает, что работа с БД происходит с использованием SQL-сервера.
DLL - неизменяемый параметр, для внутреннего использования. Содержит имя библиотеки динамического вызова (DLL, dynamic link library) для работы с 16-разрядными вызовами.
DLL32 - неизменяемый параметр, для внутреннего использования Содержит имя библиотеки динамического вызова (DLL, dynamic link library) для работы с 32-разрядными вызовами.
TRACE MODE - числовое значение, определяющее способ трассировки информации в системный журнал.
BATCH COUNT - число записей, изменяемых в рамках неявной транзакции. Перед изменением записей автоматически стартует транзакция на сервере. После изменения этого числа записей транзакция на сервере автоматически подтверждается. Более подробно о явном и неявном старте и подтверждении транзакций см. раздел книги, посвященный управлению транзакциями. Использование BATCH COUNT дает возможность изменить число записей в пакете обновлений для каждой подтвержденной транзакции, если размер подобного пакета на сервере недостаточно велик. По умолчанию - число записей, умещающихся в пакете длиной 32 К.
ENABLE BCD - Указывает на необходимость для BDE переводить целые и десятичные значения полей в значения BCD.
ENABLE SCHEMA CACHE - при значении TRUE позволяет хранить сведения о структуре, удаленной БД на клиентском компьютере в каталоге, определяемом параметром SCHEMA CACHE DIR. Хранение структуры БД хорошо тем, что в этом случае BDE не нужно всякий раз считывать данную информацию из удаленной БД, что экономит время и ресурсы. Однако хранение структуры БД возможно лишь для БД, чья структура (состав таблиц, столбцов, индексов и др.) не изменяется во времени. В противном случае выдается ошибка.
SCHEMA CACHE TIME - в случае хранения сведений о структуре БД параметр указывает, с какой периодичностью BDE обновляет сведения о структуре БД. Значения:
• 0 - хранение схемы БД не используется;
• 1 (по умолчанию) - после закрытия БД в приложении (т.е. после разрыва соединения с БД);
• число в диапазоне 1..2 147 483 647 - число секунд для обновления
сведений о структуре БД.
LANGDRIVER - Языковый драйвер, используемый для кодировки символьных полей и определяющий также порядок сортировки символьных значений. Для русскоязычных приложений рекомендуется Pdox ANSI Cyrillic. Для этого драйвера без ошибок работают символьные функции преобразования строчных/заглавных букв AnsiUpperCase и AnsiLowerCase.Pdox ANSICyrillic совместим с кодировкой символов InterBase WIN 1251 и порядком сортировки символов (collation order) PXW_CYRL. Эти значения указываются в БД в атрибутах: DEFAULT CHARACTER SET для баз данных, CHARACTER SET и COLLATE для доменов и столбцов.
МАХ ROWS - указывает максимальное число записей, которые драйвер пытается считать из удаленной БД при посылке каждого SQL-запроса к серверу, с учетом запросов на чтение структуры БД и проверки соответствия значений столбцов накладываемым на них ограничениям. Используется для предотвращения безграничного расхода системных ресурсов, например, при выдаче оператора "SELECT *..." для большой по объему таблицы БД. Малое значение МАХ ROWS может привести к тому, что таблица БД не сможет быть открыта, поскольку запрос чтения структуры таблицы может возвратить больше записей, чем указано в МАХ ROWS. Однако МАХ ROWS никак не воздействует на не-обновляемые запросы. По умолчанию принято (-1), что означает отсутствие лимита на количество считываемых строк.
В случае, если количество возвращаемых строк больше установленного лимита, выдается ошибка DBIERR_ROWFETCHLIMIT. Поэтому следует перенастраивать такие приложения для использования DBIERR.ROWFETCHLIMIT вместо DBIERR_EOF (конец данных). OPEN MODE - устанавливает режим чтения-записи данных из (в) БД (значение READ/WRITE, по умолчанию) и режим "только для чтения" (READ ONLY).
SERVER NAME - для удаленных БД содержит имя сетевого сервера и путь к БД на сетевом сервере. Вид указания имени сервера и пути зависит от используемого сетевого протокола. Для протокола TCP/IP при расположении БД на сервере, который работает под управлением Windows NT/95, указание пути к удаленной БД производится в формате ИмяСервера:Путь\ИмяБД.gdb, например:
mdl:c:\ptoject\bd\mon.gdb
При этом должны быть соответствующим образом настроены файлы HOSTS и SERVICES на компьютере, имеющем доступ к удаленной БД (более подробно см. раздел, посвященный введению в технологию "клиент-сервер", где, в частности, обсуждаются вопросы связи БД InterBase и клиентских приложений, созданных с помощью Delphi). SQLPASSTHRU MODE - важнейший в рамках технологии "клиент-сервер" режим, определяющий, каким образом происходит взаимодействие BDE с сервером на уровне транзакций приложения клиента.
Значение параметра определяет, может ли BDE передавать серверу собственные команды для управления запросами, или нет. В последнем случае используется Passthrough SQL - операторы SQL, выполняемые при помощи компонента TQuery клиентского приложения. Также данный параметр определяет режимы использования неявного старта и подтверждения транзакций. Более подробно с данной проблематикой можно ознакомиться в разделе книги, посвященном управлению транзакциями.
Параметр SQLPASSTHRU MODE может принимать следующие значения:
• SHARED AUTOCOMMIT - PassthroughSQL и команды BDE используют одно и то же соединение с удаленной БД, реализуемое в приложении через один компонент TDatabase. В том случае, если в приложении транзакция явно не реализуется методом TDatabase-StartTransaction, происходит неявный старт транзакции и ее автоматическое подтверждение.
• SHARED NOAUTOCOMMIT - Passthrough SQL и команды BDE используют одно и то же соединение с удаленной БД, неявные транзакции стартуют аналогично режиму SHARED AUTOCOMMIT, однако их неявного подтверждения не происходит и это нужно делать явно. Поведение Passthrough SQL в этом случае зависит от сервера.
• NOT SHARED - Passthrough SQL и команды BDE не могут использовать одно и то же соединение с удаленной БД. Обновляемые запросы на SQL не поддерживаются псевдонимами БД, для которых установлен режим NOT SHARED.
SHARED AUTOCOMMIT и SHARED NOAUTOCOMMIT не поддерживают всех операторов Passthrough SQL. В режимах SHARED AUTOCOMMIT или SHARED NOAUTOCOMMIT не следует управлять транзакциями при помощи SQL-оператора SET TRANSACTION.
SQLQRYMODE определяет режим выполнения запросов SQL.
Возможные значения:
• NULL (по умолчанию) - для доступа как к локальным, так и серверным БД. Запросы вначале посылаются к SQL-серверу. Если тот не в состоянии выполнить запрос, он выполняется локально.
• SERVER - только серверные БД. Запрос посылается SQL-серверу. Если сервер не может выполнить запрос, локального выполнения не происходит.
• LOCAL - только локальные БД. Запрос всегда выполняется на клиентской машине, т.е. локально.
Заметим, что запрос может быть отвергнут сервером БД, если:
1. имеет место гетерогенный запрос, т.е. запрос к различным БД;
2. запрос состоит более чем из одного SQL-оператора;
3. сервер БД не поддерживает синтаксис операторов, присутствующих в запросе.
• USER NAME - определяет имя, которое выдается в качестве подсказки имени пользователя при запросе имени пользователя и пароля в момент соединения с БД.
Контрольные вопросы
- Для чего необходим компонент BDGrid? Его основные свойства?
- Что представляет собой набор библиотек BDE? Его назначение.
- Что такое репозиторий? Его роль в Delphi?
- Для чего нужен псевдоним БД?
- Какие компоненты относятся к визуальным, а какие к невизуальным компонентам? Перечислите их и кратко охарактеризуйте.
- Для чего необходим режим Sql Passthru Mode?
- Отличия драйверов Paradox от InterBase?
- Что такое псевдоним и как его определить?
- Нужна ли для просмотра БД в Delphi связь компонентов? Обоснуйте свой ответ на примере.
- Нарисуйте схему связи различных компонентов через их свойства для работы с БД.
САМОСТОЯТЕЛЬНАЯ РАБОТА №3 (8 часов)
ТЕМА:Архитектура баз данных. Классификация СУБД. Способы разработки приложений.
Архитектура базы данных. Физическая и логическая независимость
Терминология в СУБД, да и сами термины «база данных» и «банк данных» частично заимствованы из финансовой деятельности. Это заимствование — не случайно и объясняется тем, что работа с информацией и работа с денежными массами во многом схожи, поскольку и там и там отсутствует персонификация объекта обработки: две банкноты достоинством в сто рублей столь же неотличимы и взаимозаменяемы, как два одинаковых байта (естественно, за исключением серийных номеров). Вы можете положить деньги на некоторый счет и предоставить возможность вашим родственникам или коллегам использовать их для иных целей. Вы можете поручить банку оплачивать ваши расходы с вашего счета или получить их наличными в другом банке, и это будут уже другие денежные купюры, но их ценность будет эквивалентна той, которую вы имели, когда клали их на ваш счет.
В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД, изображенная на рис. 2.1:
Рис. 2.1 - Трехуровневая модель СУБД, предложенная ANSI
1. Уровень внешних моделей — самый верхний уровень, где каждая модель имеет свое «видение» данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению. Например, система распределения работ использует сведения о квалификации сотрудника, но ее не интересуют сведения об окладе, домашнем адресе и телефоне сотрудника, и наоборот, именно эти сведения используются в подсистеме отдела кадров.
2. Концептуальный уровень — центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира.
3. Физический уровень — собственно данные, расположенные в файлах или в страничных структурах, расположенных на внешних носителях информации.
Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных. Это именно то, чего не хватало при использовании файловых систем.
Классификация СУБД
В общем случае под СУБД можно понимать любой программный продукт, поддерживающий процессы создания, ведения и использования БД. Программы имеющие отношение к БД.
К СУБД относятся следующие основные виды программ:
Ø полнофункциональные СУБД;
Ø серверы БД;
Ø клиенты БД;
Ø средства разработки программ работы с БД.
Полнофункциональные СУБД (ПФСУБД) представляют собой традиционные СУБД, которые сначала появились для больших машин, затем для мини-машин и для ПЭВМ. Из числа всех СУБД современные ПФСУБД являются наиболее многочисленными и мощными по своим возможностям. К ПФСУБД относятся, например, такие пакеты как: Clarion Database Developer, DataBase, Dataplex, dBase IV, Microsoft Access, Microsoft FoxPro и Paradox R: BASE.
Обычно ПФСУБД имеют развитый интерфейс, позволяющий с помощью команд меню выполнять основные действия с БД: создавать и модифицировать структуры таблиц, вводить данные, формировать запросы, разрабатывать отчеты, выводить их на печать и т. п. Для создания запросов и отчетов не обязательно программирование, а удобно пользоваться языком QBE (Query By Example - формулировки запросов по образцу). Многие ПФСУБД включают средства программирования для профессиональных разработчиков.
Некоторые системы имеют в качестве вспомогательных и дополнительные средства проектирования схем БД или CASE-подсистемы. Для обеспечения доступа к другим БД или к данным SQL-серверов полнофункциональные СУБД имеют факультативные модули.
Серверы БД предназначены для организации центров обработки данных в сетях ЭВМ. Эта группа БД в настоящее время менее многочисленна, но их количество постепенно растет. Серверы БД реализуют функции управления базами данных, запрашиваемые другими (клиентскими) программами обычно с помощью операторов SQL.
Примерами серверов БД являются следующие программы: NetWare SQL (Novell), MS SQL Server (Microsoft), InterBase (Borland), SQLBase Server (Gupta), Intelligent Database (Ingress).
В роли клиентских программ для серверов БД в общем случае могут использоваться различные программы: ПФСУБД, электронные таблицы, текстовые процессоры, программы электронной почты и т. д. При этом элементы пары "клиент - сервер" могут принадлежать одному или разным производителям программного обеспечения.
В случае, когда клиентская и серверная части выполнены одной фирмой, естественно ожидать, что распределение функций между ними выполнено рационально. В остальных случаях обычно преследуется цель обеспечения доступа к данным "любой ценой". Примером такого соединения является случай, когда одна из полнофункциональных СУБД играет роль сервера, а вторая СУБД (другого производителя) - роль клиента. Так, для сервера БД SQL Server (Microsoft) в роли клиентских (фронтальных) программ могут выступать многие СУБД, такие как: dBASE IV, Biyth Software, Paradox, DataEase, Focus, 1-2-3, MDBS III, Revelation и другие.
Средства разработки программ работы с БД могут использоваться для создания разновидностей следующих программ:
· клиентских программ;
· серверов БД и их отдельных компонентов;
· пользовательских приложений.
Программы первого и второго вида довольно малочисленны, так как предназначены, главным образом, для системных программистов. Пакетов третьего вида гораздо больше, но меньше, чем полнофункциональных СУБД.
К средствам разработки пользовательских приложений относятся системы программирования, например Clipper, разнообразные библиотеки программ для различных языков программирования, а также пакеты автоматизации разработок (в том числе систем типа клиент-сервер). В числе наиболее распространенных можно назвать следующие инструментальные системы: Delphi и Power Builder (Borland), Visual Basic (Microsoft), SILVERRUN (Computer Advisers Inc.), S-Designor (SDP и Powersoft) и ERwin (LogicWorks).
По характеру использования СУБД делят на персональные и многопользовательские.
Персональные СУБД обычно обеспечивают возможность создания персональных БД и недорогих приложений, работающих с ними. Персональные СУБД или разработанные с их помощью приложения зачастую могут выступать в роли клиентской части многопользовательской СУБД. К персональным СУБД, например, относятся Visual FoxPro, Paradox, Clipper, dBase и др.
Многопользовательские СУБД включают в себя сервер БД и клиентскую часть и, как правило, могут работать в неоднородной вычислительной среде (с разными типами ЭВМ и операционными системами). К многопользовательским СУБД относятся, например, СУБД Oracle и Informix.
По используемой модели данных СУБД (как и БД), разделяют на иерархические, сетевые, реляционные, объектно-ориентированные и другие типы.
С точки зрения пользователя, СУБД реализует функции хранения, изменения (пополнения, редактирования и удаления) и обработки информации, а также разработки и получения различных выходных документов.
Для работы с хранящейся в базе данных информацией СУБД предоставляет программам и пользователям следующие два типа языков:
· язык описания данных - высокоуровневый непроцедурный язык декларативного типа, предназначенный для описания логической структуры данных;
· язык манипулирования данными - совокупность конструкций, обеспечивающих выполнение основных операций по работе с данными: ввод, модификацию и выборку данных по запросам.
Функции СУБД, используют следующие основные функции более низкого уровня, которые назовем низкоуровневыми:
· управление данными во внешней памяти;
· управление буферами оперативной памяти;
· управление транзакциями;
· ведение журнала изменений в БД;
· обеспечение целостности и безопасности БД. Дадим краткую характеристику необходимости и особенностям реализации перечисленных функций в современных СУБД.
Реализация функции управления данными во внешней памяти в разных системах может различаться и на уровне управления ресурсами (используя файловые системы ОС или непосредственное управление устройствами ПЭВМ), и по логике самих алгоритмов управления данными. В основном методы и алгоритмы управления данными являются "внутренним делом" СУБД и прямого отношения к пользователю не имеют. Качество реализации этой функции наиболее сильно влияет на эффективность работы специфических ИС, например, с огромными БД, со сложными запросами, большим объемом обработки данных.
Необходимость буферизации данных и как следствие реализации функции управления буферами оперативной памяти обусловлено тем, что объем оперативной памяти меньше объема внешней памяти.
Буферы представляют собой области оперативной памяти, предназначенные для ускорения обмена между внешней и оперативной памятью. В буферах временно хранятся фрагменты БД, данные из которых предполагается использовать при обращении к СУБД или планируется записать в базу после обработки.
Механизм транзакций используется в СУБД для поддержания целостности данных в базе. Транзакцией называется некоторая неделимая последовательность операций над данными БД, которая отслеживается СУБД от начала и до завершения. Если по каким-либо причинам (сбои и отказы оборудования, ошибки в программном обеспечении, включая приложение) транзакция остается незавершенной, то она отменяется.
Говорят, что транзакции присущи три основных свойства:
· атомарность (выполняются все входящие в транзакцию операции или ни одна);
· сериализуемость (отсутствует взаимное влияние выполняемых в одно и то же время транзакций);
· долговечность (даже крах системы не приводит к утрате результатов зафиксированной транзакции)
Контроль транзакций важен в однопользовательских и в многопользовательских СУБД, где транзакции могут быть запущены параллельно. В последнем случае говорят о сериализуемости транзакций. Под сериализацией параллельно выполняемых транзакций понимается составление такого плана их выполнения (сериального плана), при котором суммарный эффект реализации транзакций эквивалентен эффекту их последовательного выполнения.
При параллельном выполнении смеси транзакций возможно возникновение конфликтов (блокировок), разрешение которых является функцией СУБД. При обнаружении таких случаев обычно производится "откат" путем отмены изменений, произведенных одной или несколькими транзакциями.
Ведение журнала изменений в БД (журнализация изменений) выполняется СУБД для обеспечения надежности хранения данных в базе при наличии аппаратных сбоев и отказов, а также ошибок в программном обеспечении.
Журнал СУБД - это особая БД или часть основной БД, непосредственно недоступная пользователю к используемая для записи информации обо всех изменениях базы данных. В различных СУБД в журнал могут заноситься записи, соответствующие изменениям в СУБД на разных уровнях: от минимальной внутренней операции модификации страницы внешней памяти до логической операции модификации БД (например, вставки записи, удаления столбца, изменения значения в поле) и даже транзакции.
Для эффективной реализации функции ведения журнала изменений в БД необходимо обеспечить повышенную надежность хранения и поддержания в рабочем состоянии самого журнала. Иногда для этого в системе хранят несколько копий журнала.