42321

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

Лабораторная работа

Информатика, кибернетика и программирование

Архитектура баз данных Современная система управления базами данных такая как InterBse SQL Server пакета Delphi или Microsoft SQL Server 2000 может поддерживать хранение и обработку множества баз данных к которым одновременно могут обращаться множество пользователей. Прежде чем учиться управлению этими базами данных познакомимся с их структурой то есть с представлением базы данных на логическом и физическом уровнях. При этом будет рассмотрен список объектов поддерживаемых базами данных InterBse SQL Server 6 сокращённо...

Русский

2013-10-29

361.5 KB

10 чел.

PAGE  16

   Лабораторная работа № 3

   «Архитектура баз данных

    и способы доступа к ним в пакете Delphi»

1. Архитектура баз данных

 Современная система управления базами данных, такая как InterBase SQL Server пакета Delphi или Microsoft SQL Server 2000, может поддерживать хранение и обработку множества баз данных, к которым одновременно могут обращаться множество пользователей. Прежде чем учиться управлению этими базами данных, познакомимся с их структурой, — то есть с представлением базы данных на логическом и физическом уровнях. При этом будет рассмотрен список объектов, поддерживаемых базами данных InterBase SQL Server 6 (сокращённо InterBase), а также взаимосвязи между этими объектами.

 Структуру базы данных можно описывать с двух сторон — логической и физической. Логическая структура базы данных представляет собой совокупность логических объектов баз данных, таких как таблицы, хранимые процедуры, правила, умолчания и т. д., а также связей между ними. Физическая же структура включает в себя описание файлов для хранения баз данных, журналов транзакций и т. п. Начнем рассмотрение с логической архитектуры.

1.1 Логическая архитектура баз данных

 Во всякой СУБД данные логически организованы в так называемые объекты. Объекты представляют собой то, что может «ощутить» пользователь при работе с базой данных. Набор объектов в различных СУБД может отличаться. Даже разные версии одной и той же СУБД могут иметь разный набор объектов. Более того, архитектура одного и того же объекта в разных версиях также может быть
различной. Пользователь, работающий с СУБД воспринимает базу данных именно как совокупность её логических объектов. Поэтому, можно сказать, что
база данных (БД) данной СУБД в логическом смыслеэто некоторая именованная совокупность логических объектов данной СУБД. Отсюда следует, что любая база данных имеет уникальное имя (внутри СУБД). Часто, кроме имени БД имеет ещё и псевдоним (алиас) – дополнительное имя (см.ниже).

 Рассмотрим, какие логические объекты имеются в распоряжении пользователей при работе с базами данных InterBase.

  Таблицы (tables) представляют собой двумерные матрицы, в которых и хранятся данные (то есть, это единственный объект баз данных, предназначенный для хранения данных). Любая реляционная СУБД поддерживает таблицы. Таблица имеет имя — уникальный (внутри БД) идентификатор, по которому на неё можно сослаться.

 Таблицы имеют следующую структуру:

   Столбцы (column). Каждый столбец представляет собой атрибут или совокупность значений одного из атрибутов объекта (сущности), например идентификационные номера служащих, рост, цвет машин и т. п. Часто в отношении столбца используется термин поле с указанием имени, например «в поле Name». Поле отдельной строки таблицы является минимальным элементом таблицы. Каждый столбец в таблице имеет определенное имя, тип данных и размер. Имена столбцов должны быть уникальными в пределах таблицы.

   Некоторые столбцы могут быть вычисляемыми (computed).  Они предназначены не для хранения в них каких – либо данных, а для вычисления значений этих полей, в соответствии с выражениями, задаваемыми для них при определении структуры таблицы. Выражение может включать имена других столбцов таблицы, константы, вызовы функций, а также любые операторы. Использование переменных запрещается

   Строки (rows). Каждая строка (или запись) представляет собой совокупность
значений атрибутов конкретного экземпляра объекта (сущности), например, в строке может содержаться идентификационный номер служащего, размер оклада этого служащего, год его рождения, цвет глаз и т. п. Строки таблиц не именуются. Чтобы обратиться к конкретной строке, пользователю необходимо указать какой-то атрибут (или набор атрибутов), уникально её идентифицирующий. Обычно в качестве такого атрибута выступает первичный ключ. Также можно обращаться более чем к одной строке, указывая логическое условие. Сервер будет работать с теми строками, значения в столбцах которых удовлетворяют указанному условию.

.

  Для создания таблицы средствами InterBase используется команда CREATE TABLE.

  Если необходимо изменить какие-то параметры таблицы, необходимо воспользоваться командой ALTER TABLE. С помощью этого оператора можно добавлять и удалять поля таблицы, изменять тип данных полей, добавлять и удалять ограничения.

  Для удаления таблицы применяется команда DROP TABLE.

  В реальной работе с БД часто возникает необходимость создания временных таблиц – для проведения сложных сортировок, хранения промежуточных результатов при сложных расчётах и т.п. Располагать временные таблицы в серверной БД неудобно, так как в условиях многопользовательской работы трудно обеспечить уникальность имени временной таблицы. Поэтому, в InterBase предусмотрена возможность создания внешних таблиц, которые выполняют роль временных таблиц для серверной БД. При создании внешней таблицы все содержащиеся в ней данные помещаются в отдельный файл, однако сама таблица остаётся связанной с той БД, которая была активна на момент создания внешней таблицы. Сервер разрешает вставлять записи во внешнюю таблицу, но не разрешает изменять или удалять её записи. Для внешней таблицы нельзя создавать индексы. Создаётся внешняя таблица, если в операторе создания таблицы указать ключевое слово EXTERNAL. При удалении базы данных, с таблицей которой связана внешняя таблица, файл внешней таблицы не удаляется. После использования временная внешняя таблица может быть удалена командой DROP TABLE.

  Хранимые процедуры (stored procedures)это подпрограммы, принимающие и возвращающие параметры и способные выполнять запросы к БД, условные ветвления и циклическую обработку данных. Хранимые процедуры пишутся на специальном алгоритмическом языке с использованием операторов SQL. В них программируются часто повторяемые последовательности запросов к БД. Процедур хранятся на в самой БД на сервере в откомпилированном виде под присвоенными им именами. Пользователи работают с процедурами, обращаясь к ним по имени. Такое обращение называется вызовом хранимой процедуры. В случае вызова процедуры сервер выполняет набор команд, представляющих собой тело хранимой процедуры. Назначение хранимых процедур – ускорение работы клиентских приложений с удалённой БД.

  Для создания хранимых процедур используется команда CREATE PROCEDURE. Язык создания процедур включает в себя, как правило, все инструкции SQL для манипуляции данными и ряд расширений: условные операторы, операторы циклов различных видов, возможности обработки исключительных ситуаций.

  Хранимые процедуры состоят из заголовка и тела. В заголовке указываются: имя процедуры (уникальное среди имён процедур и таблиц в БД); список входных параметров и их типов данных, которые процедура принимает из вызывающей программы (может отсутствовать); список выходных параметров и их типов данных, если процедура возвращает значения в вызывающую программу. Тело процедуры содержит: список локальных переменных и типов данных (если они используются в теле процедуры); блок инструкций на языке процедур и триггеров, заключённый между ключевыми словами BEGIN и END. Блок может включать в себя другие блоки, реализующие несколько уровней вложенности.

  Опреатор, запускающий хранимую процедуру на выполнение зависит от типа процедуры. Процедуры выбора выполняются при обращении к ним с помощью оператора выборки данных SELECT. Для вызова выполняемых процедур необходимо использовать оператор EXECUTE.

  Для удаления хранимых процедур используется оператор DROP PROCEDURE.

  Триггеры (triggers) — специальный тип хранимых процедур, автоматически запускаемых и выполняемых сервером до или (и) после удаления, добавления или изменения данных (записи) в таблице. В некотором смысле триггеры являются аналогами обработчиков событий языка Object Pascal.

  Триггер создаётся оператором CREATE TRIGGER. Формально триггер отличается от хранимой процедуры только заголовком. Заголовок триггера содержит: имя триггера (уникальное в БД); имя таблицы, с которой триггер связан; инструкции, которые определяют, когда триггер будет выполняться (при выполнении какого оператора манипулирования данными и в какой момент времени – до или после выполнения оператора). Тело триггера аналогично телу хранимой процедуры.

  Модифицировать триггеры нельзя. Можно удалить триггер и создать новый под тем же именем.

  Для удаления триггеров используется оператор DROP TRIGGER.

  Представления (views)так называемые виртуальные таблицы, отображающие результат выборки данных. Если говорить о природе представлений, то они являются всего-навсего запросом SELECT, сохраненным под определённым именем (поэтому часто представление называют сохраненными запросами), который выполняется всякий раз, когда происходит обращение к представлению. Результат выполнения этого запроса в является содержанием представления. Пользователь может работать с доступным через представление набором данных как с обычной таблицей (конечно, за некоторыми исключениями). Применение представлений ускоряет выполнение запросов (они создаются и работают на сервере) и освобождает клиентское приложение от необходимости такие запросы выдавать. Работа с представлением из клиентского приложения ничем не отличается от работы с обычной таблицей. В одном представлении могут объединяться записи из одной или более таблиц или других представлений. Таблицы (или представления), на основе которых формируются представления называются базовыми таблицами (базовыми представлениями).Сервер автоматически поддерживает представления. При изменении данных в базовых таблицах представления изменяется и содержание представления. Изменение данных в представлении тоже приводит к изменению данных в таблицах, на основе которых это представление создано.

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

 Представления используются, в основном, в двух целях:

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

   Для формирования итоговых данных. В этом случае представления используются для формирования итоговых результатов при формировании отчётов, когда требуется часто распечатывать отчёт, формируемый на основе таблиц с часто изменяемой информацией. Так как представление может быть создано на основе запроса, содержащего предложения группировки, то можно создать представление, получающее информацию из ряда базовых таблиц и группирующих её необходимым образом, а при выводе отчёта обращаться к этому представлению как к обычной таблице. В этом случае не нужно будет каждый раз при выводе отчета формировать сложный SQL-запрос. Кроме того, в этом случае часть логики окажется вынесенной на сторону сервера базы данных, так как формирование отчета не будет зависеть от клиентского приложения.

Для создания представлений используется оператор CREATE VIEW. Представление может быть создано на основе одной или нескольких таблиц и/или других представлений. Оператор выборки, содержащийся в CREATE VIEW  может быть любой сложности, он может содержать любые условия отбора и предложения группировки.

После создание представления с ним можно работать как с обычной таблицей, имеющей имя, заданное в качестве имени представления. Некоторым исключением являются представления, содержащие предложения группировки. Для таких представлений нет никаких ограничений по выборке данных, но применение к ним операторов манипулирования данными (подмножества команд DDL) недопустимо.

Удаление представлений выполняется с помощью оператора DROP VIEW, при вызове которого могут указываться параметры RESTRICT или CASCADE. Данные параметры определяют действия при удалении представления, на которое ссылаются другие представления и/или ограничения. При использовании варианта RESTRICT в этом случае будет выдано сообщение об ошибке, и удаление не будет выполнено. Если же используется режим CASCADE, то выполнение оператора DROP VIEW приведет к удалению всех представлений, использующих удаляемое представление в качестве базового, и ограничений.

 Удаление представления не приводит к удалению данных, на которые это представление ссылается. Удаляется лишь запрос на выборку данных, на основе которого было создано представление.

  Индексы (indexes)дополнительные структуры, призванные повысить производительность работы с данными таблиц при выборке, сортировке и поиске.

  Индекс создаётся оператором CREATE INEX. Параметры оператора ASK или DESC определяют будет ли создаваемый индекс «по возрастанию» или «по убыванию». Параметр UNIQUE определяет создание уникального индекса.

  Удаление индекса производится командой DROP INDEX. Удаление индексов никак не влияет на информацию, содержащуюся в индексированных полях.

  Как говорилось ранее, в реальной работе иногда возникает необходимость вставки (изменения, удаления) в ту или иную таблицу БД сразу множества записей. В этом случае можно (желательно) временно отключить индекс оператором ALTER INDEX с параметром INACTIV. После завершения пакетной операции индекс можно вновь включить оператором ALTER INDEX с параметром ACTIV. Пакетные операции с отключённым индексом (индексами) реализуются быстрее, поскольку каждая единичная операция не вызывает перестройки индекса (индексов). Включение индекса после завершения пакетной операции ведёт к его пересчёту и способствует его оптимизации (один раз за всю пакетную операцию). Однако, в условиях многопользовательской работы отключение и повторное включение индексов при проведении пакетных операций проблематично, так как с одним и тем же индексом могут работать одновременно более одного пользователя: индекс нельзя отключить если он используется в каком-либо запросе. Нельзя отключать также уникальные индексы, так как в этом случае в столбцы этого индекса могут быть внесены неуникальные значения и включение индекса приведёт к ошибке. Поэтому, на практике, для улучшения производительности какого-либо индекса, администратор БД должен время от времени (когда все пользователи отключены от сети) удалять этот индекс, а затем создавать его заново.

  Пользовательские типы данных (user-defined data types)типы данных, создаваемые пользователями на основе встроенных типов данных. В InterBase - это предопределённые типы данных – домены. Доменами называются заранее созданные описания столбцов. Домены должны иметь уникальные имена. Созданный домен хранится в БД и может использоваться вместо типа столбца.

  Домен создаётся командой CREATE DOMAIN. При помощи ключевого слова COLLATE можно определить порядок сортировки символов в столбце, который будет ассоциирован с данным доменом (например, в соответствии нарастанием кодов символов в той или иной таблице кодировки символов).

  Изменение существующего домена может быть произведено оператором ALTER DOMAIN. Надо помнить, что все сделанные изменения будут автоматически учтены для всех столбцов, определённых с использованием этого домена.

  Функции пользователя (user-defined functions, UDF)функции, создаваемые пользователем, в которых может реализовываться функциональность, отсутствующая в стандартных фунциях InterBase. Например, в UDF можно реализовать извлечение из значения даты номера дня, года, определение длины символьного значения, усечение пробелов, различные математические алгоритмы и т.п. Пользовательская функция может быть написана на любом алгоритмическом языке, позволяющем разрабатывать DLL (Dynamic Link Library – библиотека динамической компановки), например на Object Pascal. После создания UDF помещается в одну из DLL под своим именем. DLL хранятся на клиенте, там же, где исполняемый модуль приложения. Во время работы приложения соответствующая DLL будет загружена в память только в том случае, кода приложение обратится по имени к хранящейся в ней UDF. После этого соответствующая UDF запустится на выполнение. Основным явным преимуществом UDF перед хранимыми процедурами является то, что первые могут использоваться в выражениях. К неявными достоинствам использования UDF относятся уменьшение размеров исполняемого файла приложения и занимаемых им ресурсов, а также то, что управление динамическими библиотеками осуществляется не приложением, а операционной системой и то, что внесение изменений в DLL не требуют перекомпиляции всего проекта создания приложения. Кроме того, функции DLL могут использовать несколько процессов одновременно, поскольку работают на уровне ОС.

  Ограничения (constraints) на значения отдельных столбцов. Условия ограничений могут быть разнообразны – от требования удовлетворения вводимых значений определённому диапазону или соответствия некоторой маске, до требуемого отношения (требуемой связи) с одной или несколькими записями другой таблицы (или многих таблиц). Ограничения призваны обеспечить логическую целостность данных и ссылочную целостность данных.

  Ограничения логической целостности данных (ограничения на значения столбца) реализуются при помощи ключевого слова (спецификатора) CHECK и указания соответствующего условия (условий) проверки. Спецификатор CHECK может указываться либо в операторе создания таблицы, при определении её столбцов (для любых необходимых столбцов), либо в операторе создания домена (для этого домена).  Говорят, что в этом случае условия целостности определяются на уровне столбцов. Условия ограничения могут быть самыми разнообразными. Например: значение цифрового поля должно лежать в каком-либо диапазоне, или строковые значения столбца должны заканчиваться определённым символом, или значения столбца должны совпадать с одним из значений определённого столбца определённой таблицы, или строка в значении столбца должна начинаться с определённого символа и т.п. Условия ограничения целостности для любого количества столбцов  таблицы могут быть оформлены в виде единого  логического объекта – именованного ограничения логической целостности таблицы. Для этого используется ключевое предложение CONSTRAINT <имя ограничения> CHECK <условия ограничения>. Параметр <условия ограничения> состоит из условий ограничения для отдельных столбцов, объединённых логическими операторами .AND. или .OR.. Говорят, что в этом случае условия целостности определяются на уровне таблицы. В этом случае при возникновении ошибки нарушения логической целостности, в сообщении об этой ошибке, будет указано имя нарушенного ограничения целостности, что удобно. InterBase будет автоматически отслеживать вводимые в столбцы значения и будет отвергать те из них, которые не удовлетворяют наложенным столбецы ограничениям.

  Ограничения ссылочной целостности обеспечиваются  созданием и поддержкой СУБД связей (отношений подчинённости) между таблицами БД путём определения первичных ключей (primary keys) в родительских таблицах и внешних ключей (foreign  keys) в дочерних таблицах (см. лабораторную работу №2).  Первичные ключи определяются спецификатором PIMARY KEY, а внешние – спецификатором FOREIGN KEY.

  Аналогично ограничениям логической целостности ограничения первичного ключа могут задаваться на уровне столбца или на уровне таблицы. Если они задаются на уровне столбца, то спецификатор PIMARY KEY (<имя столбца>), указывается в строке оператора CREATE TABLE, определяющей столбец первичного ключа таблицы. Таким образом проще всего определять простой первичный ключ. Если первичный ключ таблицы составной, то его надо определять на уровне таблицы. Определение на уровне таблицы ограничения первичного ключа  осуществляется после определения всех столбцов таблицы при помощи того же спецификатора PIMARY KEY (<имя столбца1>, …(<имя столбцаN>), в котором через запятую указываются все столбцы, входящие в составной первичный ключ, в том порядке, в котором они должны входить в ключ. Столбцы, входящие в первичный ключ должны быть уникальными (для каждого из них должго быть заранее определено ограничение NOT NULL).

  Внешние ключи таблицы определяются при помощи спецификатора FOREIGH KEY <имя внешнего ключа> (список полей внешнего ключа) REFERENCES <имя родительской таблицы> (список полей родительской таблицы). Списки полей, указываемые в для внешнего и родительского-первичного ключа должны быть совместимы: количество полей в них должно быть одинаково; порядок следования полей в списках должен совпадать, причём совпадение определяется не именами полей, а типами данных и размерам полей. Каждый внешний ключ определяется отдельно. Созданные таким образом на уровне таблицы внешние ключи являются безымянными ограничениями ссылочной целостности. Для того, чтобы создать именованное ограничение ссылочной целостности в виде внешнего ключа необходимо использовать связку CONSTRAINT <имя ограничения целостности> FOREIGH KEY <имя внешнего ключа> (список полей внешнего ключа) REFERENCES <имя родительской таблицы> (список полей родительской таблицы), в которой определяются имя ограничения ссылочной целостности и само это ограничение.

 Каждый спецификатор CONSTRAINT может определить имя одного ограничения целостности (логической или ссылочной).

  Генераторы – используются для создания и использования уникальных значений нужных полей.  В таблицах InterBase нет автоинкрементного типа данных. Обычно, в реляционных и объектно- реляционных СУБД, данные этого типа служат для построения искусственных (суррогатных) первичных ключей, однозначно определяющих любую запись в таблице (например, в таблице СУБД Paradox). Чтобы помещать в какой-либо столбец уникальные значения, в InterBase предусмотрен специальный механизм генераторов. Генератор – это хранящаяся в БД программа, выдающая при каждом обращении к ней уникальное число. Для каждого автоинкрементного столбца в БД СУБД InterBase должен быть создан свой генератор. Для создания генератора используется команда CREATE GENERATOR <имя генератора>. Затем надо установить начальное значение генератора (если этого не сделать – начальное значение будет нулевым) оператором SET GENERATOR <имя генератора> TO <начальное значение генератора>. После этого надо создать триггер, который срабатывал бы при создании каждой новой записи. В триггере должен быть определён вызов соответствующего автоинкрементному столбцу генератора и занесение в поле этого столбца сгенерированного уникального числа. Для этих же целей можно использовать специально созданную и вызываемую в момент создания новой записи хранимую процедуру. (См. В.Фаронов «Программирование баз данных в Delphi 6», стр.204 и SQL Reference Help of Delphi 6.0 Enterprise).

 BLOB-поля. В составе записи БД могут определяться BLOB-поля (Binary Large Object – большой двоичный объект), предназначенный для хранения больших объёмов данных в виде последовательности байтов. Таким образом могут храниться текстовые и графические документы, файлы мультимедиа, звуковые файлы и т.д. Интерпретация BLOB-поля выполняется в приложении, однако разработчик может определить так называемые BLOB-фильтры для автоматического преобразования содержимого BLOB-поля к другому виду.

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

  Умолчания (defaults) — самостоятельные объекты базы данных, которые так же как ограничения целостности, могут связываться со столбцами таблиц и пользовательскими типами данных. Значения по умолчанию могут быть указаны непосредственно при формировании структры таблицы или пользовательского типа данных.

Для задания значения по умолчанию используется спецификатор DEFAULT <значение по умолчанию>, который указывается а команде CREATE TABLE при описании поля, для которого устанавливается значение «по умолчанию». Значение NULL фактически является значением по умолчанию, принятым для каждого поля таблицы, для которого не задано ограничение NOT NULL и которое не имеет другого значения по умолчанию.

1.2 Физическая архитектура баз данных

 1.2.1 Некоторые технические характеристики

 SQL-сервер InterBase был разработан в начале 80-х годов группой разработчиков из американской корпорации DEC. В дальнейшем разработка сервера велась независимой компанией InterBase Software и впоследствии слившейся с ней компанией Ashton-Tate. Корпорация Borland приобрела права на InterBase у компании Ashton-Tate после слияния с ней.

 Сервер InterBase активно используется в государственном и военном секторах США, что, видимо, и стало преградой для его продвижения в Россию. Интерес к этому серверу возрос только в последнее время в связи с включением его локальной (а начиная с Delphi 3 и пользовательской) версии в состав Delphi Client/Server Suite и Delphi Enterprise. Внимание разработчиков БД сервер InterBase привлек,
во-первых, потому, что это «родной» продукт
Borland (а средства разработки приложений этой компании давно зарекомендовали себя с положительной стороны), во-вторых, потому, что сервер InterBase весьма прост в установке, настройке и администрировании по сравнению с другими SQL-серверами, и, в-третьих, потому что он обладает прекрасными функциональными возможностями.

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

Таблица 1. Технические характеристики сервера InterBase

_________________________________________________________________________________________

Характеристика_____________          Значение________________________________________________

Максимальный размер одной БД          Рекомендуется не выше 10 Гбайт, однако известны случаи объёма

                                                                 одной БД в 10-20 Гбайт

Максимальное количество таблиц в одной БД    65 536

Максимальное количество полей          1 000

(столбцов) в одной таблице

Максимальное количество записей       Не ограничено

(строк) в одной таблице

Максимальная длина записи                  64 Кбайт (кроме BLOB-полей)

Максимальная длина поля                      32 Кбайт (кроме BLOB-полей)

Максимальная длина BLOB-поля          Не ограничена

Максимальное количество индексов в БД         65 536

Максимальное количество полей в индексе       16

Максимальный уровень вложенности   16

SQL-запроса

Максимальный размер хранимой           48 Кбайт

процедуры или триггера

Максимальное количество UDF в базе данных   Длина имени UOF — не более 31 символа, каждая UDF-функция

                                                                  должна иметь уникальное имя, поэтому максимальное

                                                                  количество UDF ограничивается только требованием

                                                                  уникальности имени

__________________________________________________________________________________________

 1.2.2 Физическая организация базы данных InterBase

 База данных InterBase состоит из последовательно, начиная с 0, пронумерованных страниц. Нулевая страница является служебной и содержит информацию, необходимую для соединения с БД. Размер страницы — 1 (по умолчанию), 2, 4 или 8 Кбайт. Размер страницы задается при создании БД, но может быть изменен при сохранении и восстановлении базы. Одна страница читается сервером за один
логический доступ к БД.

 Объем буфера ввода-вывода для операций чтения-записи определяется в количестве страниц (по умолчанию — 75). Если БД будет чаще читаться, объем буфера следует увеличить. Если в нее будет чаще осуществляться запись, размер буфера можно уменьшить.

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

 InterBase размещает на одной своей странице все версии одной записи таблицы базы данных. После удаления записей на странице образуются «дырки». При добавлении новой записи анализируется размер максимальной «дырки», и, если он меньше длины добавляемой записи, происходит сжатие страницы, в процессе которой «дырки» объединяются. Если освободившегося пространства не хватает для размещения новой записи, та записывается с новой страницы. Загрузка страницы считается
нормальной в случае, если «дырки» занимают не более 20 % объема страницы.

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

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

 Для удаления мусора БД сохраняется на дисковом носителе и затем восстанавливается из сделанной резервной копии с помощью утилиты IB Console (для предыдущих версий InterBase — с помощью утилиты InterBase Server Manager). Этот процесс гарантирует удаление всего мусора, так как в момент сохранения и восстановления БД не должно быть активных подключений к БД со стороны других пользователей и потому не может быть активных транзакций. Кроме того, в InterBase предусмотрено автоматическое удаление мусора на фоне активных транзакций. Интервал, через который происходит автоматическое удаление мусора, по умолчанию составляет 20 000 транзакций. Это значение может быть изменено с помощью утилиты IBConsole (InterBase Server Manager). При автоматической очистке удаляются только те версии записей, для которых нет активных
транзакций. В результате могут быть удалены не все старые версии.

 Не проведение в течение длительного промежутка времени принудительной очистки страниц БД InterBase может привести к существенному (в десятки раз) снижению производительности
сервера. При активной работе с БД рекомендуется производить принудительную очистку БД
InterBase от мусора не реже 2-3 раз в неделю (или даже ежедневно).

 Разные СУБД по разному организуют и хранят таблицы и вспомогательные объекты своих баз данных. Например, реляционные БД Paradox, dBase, Clipper, FoxPro используют для каждой таблицы и для каждого индекса отдельный файл. Кроме того, в отдельных файлах могут храниться формы отчётов (входных и выходных), сценариии компиляции объектных модулей (модулей в двоичных объектных кодах) и их компановки в исполняемый файл, исходные тексты модулей, статические и/или динамически подключаемые библиотеки подпрограмм, memo-поля и т.п. В этом случае база данныхэто каталог, в котором хранятся файлы таблиц, индексов и вспомогательных объектов БД.

 В Microsoft Access таблицы БД и её вспомогательные объекты хранятся в одном файле. В этом случае база данныхэто имя файла с путем доступа к нему. СУБД Sybase и Microsoft SQL, хранят все данные на отдельном компьютере в виде одного основного и ряда вспомогательных файлов. Здесь БД – это каталог или несколько каталогов, в каждом из которых может быть свой набор файлов.

 В СУБД InterBase таблицы БД, индексы и вспомогательные объекты (хранимые процедуры, триггеры и т.п.) «по умолчанию» хранятся в одном файле, имеющем расширение имени .GDB. Но в случаях, когда размер базы данных очень велик, а размеры доступного дискового пространства ограничены, БД может храниться не в одном, а внескольких файлах, которые могут располагаться на физически разных носителях (на разных «Винчестерах», даже на разных компьютерах). Самый первый файл БД в этом случае называется первичным (он должен иметь расширение .GDB), а остальные вторичными (они должны иметь расширения .GDn, где n – номер вторичного файла). Спецификатор  STARTING AT PAGE [целое число] указывает, номер первой страницы вторичного файла в БД. Спецификатор LENGTH [=] [целое число] указывает длину файла в страницах. Например:

 CREATE DATABASE “D:\BD\SKLAD.GDB”

 FILE “D:\BD\SKLAD.GD1” STARTING AT PAGE 1001 LENGTH 500

 FILE “D:\BD\SKLAD.GD1”;

 Здесь определяется БД D:\BD\SKLAD.GDB, состоящая из трёх файлов: первичного D:\BD\SKLAD.GDB (длиной 1000 страниц), и двух вторичных - D:\BD\SKLAD.GD1 (длиной 500 страниц) и D:\BD\SKLAD.GD2 (неопределённой длины). Если для предыдущего первичного или вторичного файла не указана длина, то для вторичного файла БД необходимо определить номер её первой страницы в БД. То есть, в СУБД InterBase база данных – это один или несколько файлов, в котором(рых) хранятся таблицы, индексы и другие объекты БД.

2. Организация связи с базами данных в Delphi

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

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

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

 Для организации работы с данными таблиц БД в объектно-реляционных СУБД (таких как Oracle, MS SQL, Sybase, InterBase) такой информации мало. Обычно, чтобы такие СУБД и их приложения могли работать с данными таблиц, кроме определения полного пути к БД и имени файла (или имён файлов) таблиц БД необходимо определить такие параметры как: тип СУБД базы данных (тип базы данных), имя владельца БД, размер страницы БД в байтах, кодовую страницу национального алфавита и т.п. Эти параметры задаются в операторах создания БД, и при обращении к соответствующей БД используются для получения разрешения на работу с данной БД запрашивающемому её пользователю и для правильной организации работы СУБД или её приложения с БД (для того, чтобы работающая СУБД или приложение какой-либо СУБД могли использовать для работы с БД нужный драйвер для доступа к её таблицам, если БД является базой данных другой СУБД;  для обеспечения возможности правильного извлечения информации из таблиц БД; для правильного отображения текстовой информации в символах национального алфавита; для правильной сортировки данных и т.п.).

 Можно отметить, что перечисленные выше параметры, необходимые для организации работы c той или иной БД той или иной СУБД не имеют прямого отношения к приложению работающему с базами данных. Если базы данных одной и той же или различных СУБД  имеют идентичную структуру и в них используются одинаковые типы данных, то конкретному приложению всё равно, с какой из этих баз данных работать, при условии, что СУБД, для которой написано приложение, может работать с базами данных другой СУБД (как говорят, если в данной СУБД имеются технологии доступа к БД других СУБД, или, как минимум драйверы доступа к БД других СУБД).

 Несмотря на это, если идти обычным путём, то для того, чтобы приложение могло работать с той или иной БД, необходимо предварительно каждый раз перекомпилировать это приложение, каждый раз указывая в его исходном тексте параметры (о которых говорилось выше) той базы данных, с которой оно должно работать.

 Чтобы облегчить организацию работы в этом случае в пакете разработки приложений Delphi (а также в ряде реляционных СУБД и в других пакетах разработки приложений для объектно-реляционных СУБД) используется так называемый псевдоним (или алиас) БД. Псевдоним (alias) содержит всю информацию, необходимую для обеспечения доступа к базе данных: имя БД, её расположение, тип БД (её СУБД), имя её владельца (только он и администратор баз данных смогут работать с БД), размер страницы БД, имя кодовой страницы национального алфавита, и др. Количество и тип параметров, определяемых при создании псевдонима (алиаса), зависят от того, алиас БД какой СУБД определяется. Эта информация вводится только один раз при создании псевдонима и запоминается в специальной служебной базе данных Delphi - репозитории. А в приложении для связи с базой данных используется псевдоним (вместо имени файла БД). В этом случае приложению безразлично, где физически расположена та или иная база данных и каковы её особенности. Приложение обращаетя напрямую к алиасу, из которого узнаёт с какой базой данных какой СУБД ему придётся работать и значения параметров, которые необходимо использовать для правильной организации работы с этой БД. При смене системы имён каталогов, сервера, типа БД и т.п. ничего в приложении переделывать не надо. Достаточно, чтобы администратор базы данных ввёл соответствующую информацию в соответствующий псевдоним, с которым работает приложение. По аналогичной схеме может быть реализована работа различных приложений с одной и той же базой данных, или работа различных версий одного и того же отлаживаемого приложения с одной и той же базой данных.

 

 Необходимо обратить внимание, что алиас, это объект СУБД, а не базы данных. Поэтому пользоваться им можно только на этапах создания и отладки приложений СУБД (работающих с БД) в среде пакета разработки приложений самой этой СУБД (например в среде пакета Delphi при разработке приложений для СУБД InterBase, или в среде пакета Oracle Development Kit при разработке приложений для СУБД Oracle).

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

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

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

 CREATE  DATABASE  "BAZA.GDB"  PAGE_SIZE  4096;

 Увеличение размера страницы может привести к ускорению работы с БД, поскольку:

• уменьшается глубина индексов (число шагов, за которое при помощи индекса будут найдены требуемые записи);

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

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

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

DEFAULT  CHARACTER  SET  <имя кодовой страницы национального набора символов>

Например:

CREATE  DATABASE  "BAZA.GDB"   ...   DEFAULT  CHARACTER  SET  WIN1251;

 В дальнейшем всем создаваемым символьным столбцам таблиц БД (типы CHAR, VARCHAR) ставится в соответствие указанный набор символов, например, объявление в одной из таблиц базы данных BAZA.GDB столбца

 FAMILIA  VARCHAR(25);

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

FAMILIA  VARCHAR(25)   CHARACTER  SET  WIN1251;

  Изменить кодировку, принятую для БД описанным выше способом «по умолчанию», для определённых доменов и столбцов можно при их определении.

  Для БД, в которых столбцы будут хранить русские слова, рекомендуется кодировка
WIN1251 (либо CYRL). К сожалению, на уровне создания БД невозможно установить по умолчанию
порядок сортировки символов
(collation order). Его определяют при объявлении
доменов и отдельных столбцов
.

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

CREATE  DATABASE  "D:\BD\SKLAD.GDB"    USER  "XXX"  PASSWORD  "YYY"

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

2.2 Технологии доступа Delphi к базам данных

 2.2.1 Технология BDE

 Традиционно, для взаимодействия приложения, созданного в среде разработки Delphi, с базами данных используется Borland Database Engine (BDE) — процессор баз данных фирмы Borland. BDE служит посредником между приложением и базами данных. Он предоставляет пользователю единый интерфейс для работы, развязывающий пользователя от конкретной реализации базы данных. Благодаря этому не надо менять приложение при смене реализации базы данных. Если для работы с базами данных используется BDE, то приложение Delphi не обращается непосредственно к базе данных, а только к BDE, который в свою очередь, используя свои или внешние драйверы, взаимодействует с базами данных. BDE предоставляет возможности унифицированного подключения к локальным базам данных реляционных субд Paradox, dBase, Access, FoxPro, к системе драйверов Microsoft ODBC, к обычному ASCII-тексту и к наиболее распространённым SQL-серверам баз данных.

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

В процессе работы BDE использует вспомогательные файлы языковой поддержки, информацию о настройках среды, о местонахождении базы данных, о собственнике базы данных и т. д. Информация обо всём этом хранится в псевдониме (алиасе) базы данных, который передаётся в BDE. Но самое главное заключается в том, что BDE по псевдониму находит подходящий для указанной базы данных драйвер. Драйвер — это вспомогательная программа,  которая понимает, как общаться с базами данных или SQL-серверами определенного типа. На рис 1.1 показано как BDE взаимодействует с различными базами данных. Чёрным цветом изображено всё, что непосредственно входит в состав BDE. Цветом выделены внешние, по отношению к BDE, не входящие в него элементы.

                                                                                   Рис 1.1

 В BDE есть две группы внутренних (встроенных) драйверов.

1). Группа драйверов обеспечивающих доступ к наиболее часто используемым локальным (работающим в архитектуре «файл-сервер») СУБД: Paradox, dBase, FoxPro  и к текстовым файлам ASCII. Локальные драйвера устанавливаются автоматически, при инсталляции BDE.

2). Доступ к наиболее распространённым SQL-серверам обеспечивает отдельная система драйверов – SQL Links. С их помощью может быть установлена связь со следующими SQL-серверами: Oracle (ver.7, 8), Sybase (db_lib, ct_lib), MS SQL Server, Informix, DB2, InterBase. Все перечисленные SQL-серверы работают, естественно, в архитектуре «клиент-сервер».

 Если собственного драйвера нужной СУБД или нужного SQL-сервера нет ни в той ни в другой группе, то BDE использует внешнюю динамическую библиотеку драйверов Microsoft ODBC, которая, являясь неотъемлемой частью Windows, автоматически устанавливается при инсталляции Windows. ODBC (Open Database Connectivity) — это DLL, аналогичная по функциям BDE, но разработанная фирмой Microsoft. Поскольку Microsoft включила поддержку ODBC в свои офисные продукты и ODBC содержит драйверы практически к любым СУБД и SQL-серверам, фирма Borland включила в BDE программу, позволяющую использовать ODBC (диспетчер ODBC). Правда, работа через ODBC осуществляется несколько медленнее, чем при использовании собственных драйверов локальных СУБД и SQL-серверов. Но, благодаря возможности работы через ODBC, масштабируемость Delphi существенно увеличилась и приложения Delphi могут работать с любой сколько-нибудь значительной СУБД.

 BDE поддерживает SQL — стандартизованный язык запросов,позволяющий обмениваться данными с SQL-серверами, такими, как Sybase, Microsoft SQL, Oracle, InterBase. Эта возможность ис-
пользуется особенно широко при работе на платформе клиент/сервер. Каждый из
SQL-серверов, поддерживаемых BDE работает со своей собственной версией языка SQL, имеющей иногда довольно много существенных отличий от стандарта SQL92. Поэтому, в BDE используется собственный внутренний встроенный (embedded) диалект языка SQL, удовлетворяющий стандарту SQL92. На этом языке составляются SQL-запросы к базам данных, которые затем передаются эмулятору SQL-запросов, встроенному в ядро BDE. Эмулятор интерпретирует запросы embedded SQL и эмулирует SQL-запросы на диалекте того SQL-сервера, с которым устанавливается связь. Полученный таким образом SQL-запрос, с помощью соответствующего драйвера SQL Links передаётся нужному SQL-серверу. Такой механизм позволяет использовать запросы SQL не только для работы с «клиент-серверными» базами данных (через SQL-серверы), но и для работы с локальными («файл-серверными») базами данных, которые, в принципе, не могут работать с SQL-запросами. При получении ядром BDE SQL-запроса, адресованного к «файл-серверной» базе данных, этот запрос перенаправляется эмулятору SQL-запросов, который интерпретирует запрос и на его основе автоматически формирует двоичный код в формате локальной базы данных, с которой устанавливается связь, соответствующий SQL-запросу, который затем при помощи необходимого драйвера передаётся локальной базе данных. Следует отметить, что не во всех случаях эмуляция SQL-запроса, адресованного к локальной базе данных, возможна. В этом случае BDE либо генерирует ошибку, либо не выполняет никаких действий.

Чтобы приложение, взаимодействующее с БД при посредстве BDE могло нормально работать, BDE должен быть предварительно установлен на компьютере, на котором будет работать приложение, независимо от того, устанавливается не этом компьютере Delphi или нет. Это требование считается основным недостатком метода доступа к БД с помощью BDE. Однако, при использовании BDE можно пользоваться и алиасами БД.

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

 2.2.2  Технология ADO. Начиная с версии 5 в Delphi есть возможность работы с базами данных, минуя BDE. Это разработанная в Microsoft технология ActiveX Data Objects (ADO). ADO — это пользовательский интерфейс к любым типам данных, включая реляционные и не реляционные базы данных, электронную почту, системные, текстовые и графические файлы. Связь с данными осущест-
вляется посредством так называемой технологии
OLE DB, основанной на COM.

Использование ADO обеспечивает более эффективную работу с данными. Для использования этой возможности на компьютере должна быть установлена система ADO 2.1 или более старшая версия (она автоматически устанавливается при установке Delphi. Базовый же набор интерфейсов OLE DB имеется в каждой современной операционной системе Microsoft. Поэтому, для обеспечения доступа к данным (не только той или иной базы данных, но и, просто, к каким-то другим данным) в приложении достаточно лишь правильно указать провайдер соединения ADO. После этого программу приложения можно свободно использовать на любом компьютере, работающем под управлением Windows, на котором есть соответствующая база данных. Не требуется наличия на этом компьютере ни BDE, ни Delphi.

                                                  Рис. 1.2 Схема доступа к данным через ADO

 OLE DB – это упрощенная СОМ-спецификация и API для доступа к данным. OLE DB – это независимая от любой конкретной СУБД система. Драйверы, которые называются в OLE DB-провайдерамиDelphi они называются провайдерами ADO) могут работать практически со всеми источниками данных. Поэтому технология ADO и интерфейсы OLE DB обеспечивают для приложений единый способ доступа к источникам данных различных типов (Рис.1.2).

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

OLE DB представляет собой набор специализированных объектов СОМ, инкапсулирующих стандартные функции обработки данных, и специализированные функции конкретных источников данных и интерфейсов, обечивающих передачу данных между объектами. Согласно терминологии ADO, любой источник данных (база данных, электронная таблица, файл) называется хранилищем данных, с которым при при помощи провайдера данных взаимодействует приложение.

В результате приложение обращается не прямо к источнику данных, а к объекту OLЕ DB, который "умеет" представить данные (например, из файла электронной почты, или из таблицы базы данных) в виде таблицы БД или результата выполнения запроса SQL.

ADO в целом включает в себя не только сами объекты OLE DB, но и механизмы, обеспечивающие взаимодействие объектов с данными и приложениями. На этом уровне важнейшую роль играют провайдеры ADO, координирующие работу приложений с хранилищами данных различных типов. Провайдеры ADO обеспечивают соединение приложения, использующего данные с источником данных (сервером SQL, локальной СУБД, файловой системой и т. п.) посредством соответствующих COM-объектов. Для каждого типа хранилища данных должен существовать свой провайдер ADO.

Провайдер «знает» о местоположении хранилища данных и его содержимом (ему надо сообщить эту информацию), умеет обращаться к данным с запросами (при помощи соответствующих объектов СОМ) и интерпретировать возвращаемую служебную информацию и результаты запросов с целью их передачи приложению.

При работе в технологии ADO в Delphi всегда можно выбрать необходимый провайдер ADO из списка установленных в данной операционной системе Windows при её инсталляции провайдеров. В списке провайдеров присутствует даже провайдер работающей с ODBC. Им можно воспользоваться, если отсутствует провайдер для нужного хранилища данных. В этом случае для связи приложения с хранилищем данных соответствующий СОМ-объект использует драйвер ODBC.

При инсталляции Microsoft ActivX Data Objects в операционной системе Windows устанавливаются следующие стандартные провайдеры:

1). Microsoft Jet OLE DB Provider обеспечивает соединение с данными СУБД Access.

2). Microsoft OLE DB Provider for Microsoft Indexing Service обеспечивает доступ только для чтения к файлам и Internet-ресурсам Microsoft Indexing Service.

3). Microsoft OLE DB Provider for Microsoft Active Directory Service обеспечивает доступ к ресурсам службы каталогов (Active Directory Service).

4). Microsoft OLE DB Provider for Internet Publishing позволяет использовать ресурсы, предоставляемые Microsoft FrontPage, Microsoft Internet Information Server, HTTP-файлы.

5). Microsoft Data Shaping Service for OLE DB позволяет использовать иерархические наборы данных.

6). Microsoft OLE DB Simple Provider предназначен для организации доступа к источникам данных, поддерживающим только базисные возможности OLE DB.

7). Microsoft OLE DB Provider for ODBC обеспечивает доступ к данным, которые уже «прописаны» при помощи драйверов ODBC. Однако, реальное использование столь экзотических вариантов соединений проблематично. Драйверы ODBC и так славятся своей медлительностью, а дополнительный слой сервисов (провайдер, СОМ-объекты) ещё более замедляет работу приложения с данными.

8). Microsoft OLE DB Provider for Oracle обеспечивает соединение с SQL-сервером Oracle.

9). Microsoft OLE DB Provider for SQL Server обеспечивает соединение с Microsoft SQL Server.

В настоящее время технология ADO рассматривается как основная технология доступа к данным в Delphi 6 и Delphi 7.

 

  2.2.3  Технология InterBase Express (IBX). Начиная с версии 5 в Delphi, введена ещё одна возможность прямого общения с базами данных, минуя BDE. Это технология InterBase Express, обеспечивающая прямое общение с базами данных SQL-сервера InterBase, который входит в комплект поставки пакета Delphi. Преимущество технологии заключается в том, что она основана на прямом обращении к API сервера InterBase. Благодаря этому существенно возрастает скорость работы приложения с данными. Относительный недостаток технологии в том, что она не работает ни с какими другими источниками данных, кроме баз данных SQL-сервера InterBase.

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

Механизм доступа к данным InterBase Express использует для обращений к серверу возможности клиентского ПО InterBase, которое должно быть инсталлировано на компьютере-клиенте. Если с данного  компьютера доступны базы данных какого-либо сервера InterBase, то клиентское ПО InterBase
может обращаться к этому серверу. При этом не требуется использование
BDE или любого другого механизма доступа к данным.

  2.2.4  Технология dbExpress. В последних версиях Delphi появилась технология доступа к данным dbExpress. Эта новая технология обеспечивает взаимодействие приложения только с SQL-серверами баз данных. DbExpress использует для получения данных исключительно SQL-запросы. Основной недостаток технологии заключается в том, что она не предусматривает возможности прямого редактирования данных (поскольку на клиентской стороне отсутствует кэширование данных). Однако, несмотря на этот весьма существенный недостаток (который может быть обойдён некоторым косвенным образом) пользователь получает лёгкий и быстрый механизм доступа к данным.

 В bdExpress для каждого SQL-сервера, с которым может работать эта технология, есть свой специальный драйвер, который напрямую взаимодействует с клиентским программным обеспечением этого сервера на компьютере-клиенте. В пакет Delphi входят драйверы для следующих SQL-серверов баз данных: DB2, InterBase, MySQL и Oracle. Драйверы реализованы в виде динамических библиотек, которые могут быть прикомпилированы непосредственно к исполняемому файлу приложения. После этого приложение можно переносить на любой другой компьютер, на котором не установлен Delphi, но обязательно должна быть установлена клиентская часть того сервера SQL-сервера баз данных, с которым должно работать приложение.

Примечание:

 До версии Delphi 5, способ доступа к базам данных при помощи BDE рассматривался как основной.  Это наиболее универсальная технология доступа к данным, по скорости работы уступающая только технологиям IBX и dbExpress при работе с SQL-серверами баз данных. В то же время, это единственная технология, позволяющая напрямую работать с широкоиспользуемыми локальными базами данных. И в этом случае по скорости работы технология BDE не имеет себе равных. Однако слабым местом технологии является необходимость установки на компьютере, на котором работает приложение, BDE. Это отнимает около 15 Мбайт дискового пространства. Кроме этого технология требует создания и специальной настройки псевдонимов (алиасов). Поэтому, после того как в Delphi 6 основной технологией доступа была объявлена технология ADO, доступ к базам данных посредством BDE считается альтернативным, а в 2002 году фирма Borland объявила а прекращении поддержки этой технологии доступа. Однако, и в Delphi 6 и в Delphi 7 эта технология присутствует и отлично работает. Просто считается, что она завершила своё развитие и не нуждается в дальнейшем совершенствовании.

Так как технология ADO основана на стандартных интерфейсах СОМ, которые являются системным механизмом Windows, то это сокращает общий объём работающего программного кода и позволяет легко распространять приложения БД на компьютерах работающих под Windows без необходимости установки на них каких-либо вспомогательных программ и библиотек (типа BDE). В настоящее время это самая универсальная технология доступа к данным. Она является основной технологие доступа к данным для приложений Delphi. Однако и у этой технологии есть недостатки. К ним можно отнести необходимость настройки подключаемого провайдера, а также снижение скорости работы приложения с данными, вследствие многозвенности процесса обмена данными между приложением и хранилищем данных в этой технологии. В зависимости от вида приложения и сложности обработки данных, скорость работы с данными может уменьшаться от 2 до 10 раз (по сравнению с технологией BDE).

 Технология IBX работает быстро и чётко, но только с SQL-сервером InterBase. Недостатками её является неуниверсальность и необходимость установки на клиентской машине клиентской части сервера SQL.

 Технология dbExpress является наилучшим решением только для приложений, в которых необходим быстрый и необременительный просмотр данных серверов SQL.

3. SQL-сервер InterBase и его основные компоненты

  SQL-сервер InterBase предназначен для хранения и обработки больших объемов информации в условиях одновременной работы с БД множества клиентских приложений. Масштаб информационной системы при этом произволен - от системы уровня рабочей группы (под управлением Novell Netware или Windows 32 на базе IBM-совместимых ПК) до системы уровня большого предприятия (на базе серверов IBM, Hewlett-Packard, SUN).

Для доступа к БД используется утилита Windows Interactive SQL (WISQL). Она работает с БД напрямую через InterBase API, минуя BDE. С помощью WISQL можно писать любые запросы к серверу, будь то создание БД, таблиц, изменение структуры данных, извлечение данных из БД или их изменение, а также назначение прав доступа к информации для отдельных пользователей.

Для управления SQL-сервером в целом и отдельными БД в частности используется утилита InterBase Server Manager. С ее помощью можно определять параметры SQL-сервера, производить сохранение, восстановление БД, сборку «мусора», определять новых пользователей, их пароли и т. д.

Для просмотра БД, работы с таблицами, индексами, доменами, ограничениями и др. могут использоваться утилиты Database Desktop (весьма ограниченно) и SQL Explorer.

Для просмотра и анализа реальных процессов, происходящих на сервере при реализации пользовательского запроса, используется утилита SQL Monitor.

В Delphi 6 некоторые из этих функций перенесены в утилиту IBConsole.

4. Delphi и InterBase

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

Создание программ в архитектуре клиент-сервер имеет следующую специфику:

 не рекомендуется использовать компонент ТТаbе, поскольку он требует передачи всех данных результата выполнения запроса к серверу клиенту; в отличие от этого компонент TQuery получает от сервера только ту их часть, которая должна быть визуализирована;

 изменение записей БД следует производить не методами Insert, Edit, Delete,Post, Cancel, которые оперируют с одной (текущей) записью, а при помощи SQL-операторов INSERT,   UPDATE,  DELETE,  которые  оперируют  сразу множеством записей;

необходимо особое внимание уделять управлению транзакциями и в первую очередь - выбору адекватного потребностям программы уровня изоляции транзакций;

 бизнес-правила, где это возможно, нужно переносить на сервер, разгружая от них клиентское приложение;

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

следует везде, где это необходимо, явно вызывать методы TDatabase.StartTransaction   и   TDatabase.Commit   для   старта   и   подтверждения   транзакций; подтверждение единичных изменений БД неявно стартуемыми и завершаемыми (в режиме SQLPASSTHRU = SHARED AUTOCOMMIT) транзакциями ведет к возрастанию загрузки сети и, как следствие, к замедлению работы, часто весьма
существенному;

 необходимо уделять существенное внимание оптимизации запросов к БД, особенно при чтении данных (SELECT), поскольку оптимально построенный запрос может выполняться в несколько раз быстрее и требовать меньшего количества ресурсов.

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

Задание

Выберите из приведённой ниже таблицы номера вопросов, соответствующие номеру вашей подгруппы (бригады). В файле «Вопросы к LabRab1_3.doc» найдите вопросы, имеющие  выбранные вами номера. Занесите в отчёт ваши вопросы и только правильные варианты ответов на эти вопросы.

Номер подгруппы

(бригады)

Номера вопросов в файле Вопросы к LabRab1_3.doc

1

1, 7, 13, 19, 25

2

2, 8, 14 ,20

3

3, 9, 15, 21

4

4, 10, 16, 22

5

5, 11, 17, 23

6

6, 12, 18, 24

7

1, 8, 15, 22

8

2, 7, 14, 21

9

2, 9, 16, 23

10

3, 10, 17, 24

11

4, 11, 18, 21

12

5, 12, 17, 25

13

5,10,15,20

14

4,9,16,21

15

6,12,18,25

Примечание: правильных или неправильных вариантов ответа на каждый вопрос может быть

    несколько.




 

А также другие работы, которые могут Вас заинтересовать

526. Параллельное хеширование на GPU в реальном времени 84 KB
  Эффективный алгоритм параллелизма данных для построения больших хеш-таблиц на миллионы элементов в режиме реального времени. Гибридная хеш-таблица основана на современных идеях из теории хеширования. Компромисс между сроками строительства, временем доступа и рационального использования пространства.
527. Тест стиральных Порошков-концентратов 83 KB
  Активную основу стирального порошка составляют поверхностноактивные вещества (сокращенно ПАВ), их доля – 1525%, самый простой пример ПАВ – мыло. Задача ПАВ состоит в смачивании загрязненной ткани моющим раствором и ослаблении связи загрязнения и ткани.
528. Деятельность отдела по подбору персонала ОАО Альфа-Банк 94 KB
  Во время прохождения практики у меня была возможность непосредственно ознакомиться со структурой реально работающей организации, специализацией отдела, где я работал, а также проявить себя как молодого специалиста. В данном отчете представлены различные аспекты моей практики и мои впечатления о ней.
529. Пунктуаційні норми в писемному мовленні фахівців технічної сфери 96.5 KB
  Система правил письмового оформлення структури пропозиції. Утворення логіко-граматичного каркасу письмового висловлювання і точне вираження складних думок, які можуть бути виражені засобами усного мовлення.
530. Холодная штамповка. Формообразование заготовок из порошковых материалов 68.21 KB
  Формообразующие операции листовой штамповки. Схемы листовой штамповки при помощи эластичной среды и жидкости. Формообразование заготовок из порошковых материалов. Высокоскоростные методы штамповки.
531. Облік товарів у виробництві 78.5 KB
  Поняття, класифікація та оцінка товарів. Бухгалтерське відображення, операцій, пов'язаних з рухом товарів. Порядок списання товарів при їх вибутті. Торговельні, збутові підприємства на рахунку 28.
532. Изучение многовалютного алгоритма банкира 120 KB
  Изучение тупиковых ситуаций в операционных системах и алгоритма банкира, как средства обхода тупиков. Пример с участием пяти процессов и трех видов ресурсов, требуемых для завершения данных процессов.
533. Система Дело, клиент для мобильного телефона 124 KB
  Описание функций, преимуществ и недостатков. Пример встроенного инструментария. Руководитель может через удобный web-интерфейс удаленно контролировать работу исполнителей, а так же обеспечить формирование единого информационного пространства в рамках территориально распределенной организации.
534. Получение дешевой электроэнергии 92 KB
  Мы рассмотрели, каким способом можно создать такой аппарат; узнали сколько нужно потратить на него времени, денег, кто поможет собрать такой аппарат. Выбрали подходящий способ создания такого аппарата. Собрали этот аппарат. Проанализировали его эффективность в работе.