Память на сервере (все платформы)

Оценка памяти сервера включает множество факторов.

* Работа сервера Firebird. Сервер Firebird осуществляет эффективное использование ресурсов сервера. Суперсервер (Superserver) после старта использует приблизительно 2 Мбайта памяти. Классический сервер (Classic server) в POSIX не использует памяти, пока не установлено клиентское соединение. В Windows небольшие сервисы прослушивают запросы на соединения.

* Клиентские соединения. Каждое соединение с Суперсервером добавляет приблизительно 115 Кбайт, больше или меньше, в соответствии со стилем и характеристиками клиентских приложений, а также спроектированной схемой базы данных. Каждое соединение с Классическим сервером использует приблизительно 2 Мбайта (в зависимости от количества применяемых соединением таблиц, триггеров, процедур и других объектов - может быть и до 30-40 Мбайт. Для баз данных среднего размера - от 4 до 15 Мбайт).

* Кэш базы данных. Значение по умолчанию может конфигурироваться - в страницах базы данных. Суперсервер использует единый кэш (с размером по умолчанию 2048 страниц) для всех соединений и автоматически увеличивает кэш при необходимости. Классический сервер создает индивидуальный кэш (по умолчанию 75 страниц) на каждое соединение.

На основании существующих оценок отводите 64 Мбайта RAM для сервера и 16 Мбайт для локального клиента. Чем больше клиентов вы добавляете, тем больше памяти будет использовано. Базы данных с большим размером страниц используют ресурсы из большего участка памяти, чем базы данных с меньшим размером страниц. Использование ресурсов для Классического сервера увеличивается линейно с каждым новым подключением клиента; для Суперсервера ресурсы разделяются между несколькими подключениями, и будут динамически увеличиваться при необходимости. Firebird 1.5 будет использовать для сортировки, если она необходима, дополнительную RAM. Использование памяти более подробно обсуждается в главе 6.

 

Инсталляционные диски

Сервер Firebird - и любые базы данных, которые вы создаете или с которыми соединяетесь, - должны находиться на жестком диске, который физически подключен к машине. Вы не можете разместить компоненты сервера или любой базы данных на назначенном диске, в разделяемой файловой системе или в сетевой файловой системе.

CD-ROM

Вы не можете запускать сервер Firebird с CD-ROM. При этом вы можете соединяться с базой данных только для чтения, находящейся на устройстве CD-ROM, физически подключенным к серверу.

Дисковое пространство

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

* Сервер. Минимальная инсталляция сервера требует дискового пространства в пределах от 9 до 12 Мбайт в зависимости от платформы и архитектуры.

* Клиентская библиотека. Требует 350 Кбайт (встроенная: 1.4-2 Мбайт).

* Инструменты командной строки. Требуют приблизительно 900 Кбайт.

* Утилиты администратора базы данных. Требуют 1-6 Мбайт в зависимости от выбранных утилит. См. список свободно распространяемых и коммерческих утилит в приложении 5.

 

Минимальные требования к машине

Минимальные требования зависят от того, как вы планируете использовать систему. Вы можете запустить сервер и разрабатывать схемы баз данных на персональном компьютере с минимальной конфигурацией- даже на "быстром" 486 или на Pentium II с 64 Мбайт RAM будет работать Firebird 1.0.x- но такая конфигурация не позволит использовать многие возможности при работе в сети. Для версии 1.5 и более поздних процессор 586 с 128 Мбайт RAM может рассматриваться как минимум. Windows более требовательна к CPU и оперативной памяти, чем Linux, в которой запускается сервер на консольном уровне. Версии операционной системы влияют на требования: некоторые платформы UNIX требуют больше ресурсов как для сервера, так и для клиента, а требования некоторых версий Windows неприменимы к указанным характеристикам, независимо от требований программного обеспечения.

Поддержка SMP и HyperThreading

Суперсервер и Классический сервер Firebird могут использовать разделяемую память мультипроцессоров в Linux. В Windows поддержка SMP (симметричный мультипроцессор) доступна только для Классического сервера.

Технология HyperThreading ненадежна, похоже, она зависит от нескольких условий, включая платформу операционной системы, поставщика оборудования и версию сервера. Некоторые пользователи сообщают об успешном использовании, другие имеют проблемы. Если у вас есть машина с такими возможностями, проверьте вначале выбранный вами сервер на эту возможность и будьте готовы отменить ее на уровне BIOS, если увидите замедление в работе.

Характеристики процессора могут быть сконфигурированы на уровне сервера в firebird.config (версия 1.5) или в ibconfig/isc config (версия 1.0.x). В Windows для Суперсервера версий 1.0.x и 1.5 маска свойств CPU должна быть установлена в "единственный CPU" для SMP-машины. (См. разд. "Файл конфигурации Firebird" в главе 36.)

Операционная система

В табл. 1.1 показаны минимальные требования к операционной системе для выполнения серверов Firebird. При этом всегда смотрите файл README в каталоге /doc в вашем комплекте поставки для получения последней информации по операционной системе.

Таблица 1.1. Минимальные требования Firebird к операционной системе

 

Содержание комплекта

Каждый инсталляционный комплект содержит все компоненты, нужные для инсталляции Firebird.

* Исполняемая программа сервера Firebird.

* Множество других программ, нужных при инсталляции и/или во время выполнения задач.

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

* Файл безопасности баз данных (isc4.gdb для версии 1.0.x; security.fdb для версии 1.5).

* Одна или более версий клиентской библиотеки для установки на сервере и на клиентской рабочей станции.

* Инструменты командной строки.

* Стандартные библиотеки внешних функций и скрипты их описания (*.sql).

* Пример базы данных.

* Заголовочные файлы С (не нужны начинающим!).

* Текстовые файлы, содержащие самые последние замечания для использования в процессе инсталляции и конфигурирования.

* Заметки по релизу и различные файлы README (необходимы для прочтения).

 

Соглашения по именованию в комплекте инсталляции

Имена файлов комплекта поставки для разных платформ не являются одинаковыми. Увы, они даже не являются "последовательно неодинаковыми"; при создании дистрибутива часто нужно приспосабливаться к специфическим для платформы соглашениям или просто следовать их собственным правилам. Тем не менее некоторые элементы в именах файлов могут быть вам полезны для идентификации того комплекта, который вам нужен.

Классический сервер или Суперсервер?

Обычно первой частью имени является строка "Firebird".

* Если релиз для Windows поддерживает Классический сервер, он будет включен в тот же инсталлятор, что и Суперсервер.

* Для платформ POSIX, которые поддерживают обе архитектуры, отдельные инсталляторы поставляются для Классического сервера и Суперсервера. Имя установочного пакета будет начинаться с "FirebirdCS" (для Классического сервера) или с "FirebirdSS" (для Суперсервера).

* Для меньших платформ архитектура может быть менее очевидной, и первая часть имени может быть названием ОС или аппаратной платформы.

Номера версий

Имена всех комплектов поставки должны содержать разделенную точками строку чисел в следующем порядке: номер версии, номер релиза, номер подрелиза. Например, "1.0.3"- это третий подрелиз от начального (код С) релиза Firebird версии 1, в то время как "1.5.0" - начальный подрелиз релиза 5 (код C++) версии 1. Большинство комплектов поставки также содержат абсолютный номер создания (например, 1.0.3.972 или 1.5.2.4731). Для некоторых малых платформ, особенно тех, которые имеют собственные правила именования и созданы различными компиляторами, номера версий могут быть менее очевидными.

64-битовый ввод/вывод

Для платформ, которые требуют специальной компоновки для поддержки 64-битового ввода/вывода, вам нужно посмотреть на инфикс "6410" где-нибудь в строке имени. Он не будет присутствовать в именах комплектов поставки для операционных систем, которые осуществляют автоматическую поддержку 64-битового ввода/вывода.

Не пытайтесь инсталлировать комплект, отмеченный как "6410", на версии, где ОС, файловая система или аппаратура не поддерживают 64-битовый ввод/вывод.

Архитектура CPU

Архитектура CPU обычно включается в имя строки инсталляционного комплекта. Например, инсталлятор RPM для UNIX обычно включает указание на набор микросхем (например, i686). Список файлов отображает в списке загрузки обычно наиболее полезный указатель минимального набора микросхем, поддерживаемого инсталляционным пакетом. Комплект для Solaris предполагает наличие процессора Intel, если в имени комплекта поставки не присутствует "SPARC".

 

Зеркальные сайты

Когда вы найдете требуемый комплект поставки, щелкните мышью по гиперссылке - имени файла. Вы перейдете на список зеркальных сайтов, как показано на рис. 1.1.

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

 

Сжатые файлы (tarballs)

В дистрибутивах Linux, которые не могут выполнять пакеты RPM, и во многих разновидностях UNIX используйте сжатые файлы (обычно .tar.gz или .bz2), т. к. они дают опытному пользователю Linux больший контроль над процессом инсталляции. Соответствующая утилита распаковки понадобится на вашем сервере для распаковки комплекта поставки в вашей файловой системе. Вы найдете детальные инструкции в официальных замечаниях по релизу, README-файлах и замечаниях к поставке. Знающие пользователи могут также просмотреть и настроить инсталляционные скрипты, чтобы сделать их работоспособными в менее общих версиях Linux.

! ! !

СОВЕТ. Скрипты поставляются для командной строки. В некоторых случаях в замечаниях к поставке могут быть инструкции, как изменять скрипты и выполнять некоторые ручные настройки. Скрипты описываются далее в этой главе.

. ! .

В любом случае прочтите все поставляемые текстовые файлы, а также соответствующие темы в официальных замечаниях по релизу, которые относятся к той версии Firebird, которую вы собираетесь инсталлировать. Могут существовать серьезные отличия между совместимыми с POSIX ОС дистрибутивами и релизами, особенно в случае открытых исходных текстов. Где только возможно, в комплекте поставки для каждой версии Firebird в замечаниях по релизу делается попытка документировать вопросы, связанные с различными версиями ядра и дистрибутивами.

! ! !

СОВЕТ. Если вы не нашли замечания по релизу в вашем комплекте поставки, обратитесь к главной странице сайта IBPhoenix (http://www.ibphoenix.com) и загрузите замечания по релизу оттуда.

. ! .

 

Реализация NPTL для высших версий Linux

Новая библиотека потоков POSIX (Native POSIX Thread Library, NPTL) в Red Hat 9 (и, возможно, в более поздних дистрибутивах Linux) создает проблемы с Суперсервером и локально скомпилированными программами, а также с утилитами. Утилита gbak сообщает об ошибке "broken pipe". Для устранения этой ошибки выполните следующие шаги:

1. Проверьте, что запущен сервер. В /etc/init.d/firebird выполните:

LD_ASSUME_KERNEL-2.2.5

export LD_AS SOME_KERNEL

2. Вам нужно установить переменную окружения в соответствии с локальным окружением, так что добавьте следующее в /etc/profile, чтобы быть уверенным, что каждый пользователь может ее использовать в утилитах командной строки. После

HISTSIZE=1000

добавьте

LD_ASSUME_KERNEL=2.2.5

С помощью следующей строки экспортируйте ее:

export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUT_RC LD_ASSUME_KERNEL

 

Сжатые файлы

Если комплект поставки для Windows содержит ZIP-файлы, вам нужно иметь утилиты (например, WinZip, PKZip или WinRAR) для просмотра содержимого и/или распаковки файлов перед инсталляцией. Такой комплект поставки (не для начинающих) содержит следующее:

* версия 1.5 ZIP полной поставки клиент-сервер Firebird-1.5.2.473l_win32.zip. Может быть распакован в стандартный каталог без инсталляции в системе. Некоторые программы инсталляции должны запускаться после распаковки. Инструкции включены в различные текстовые файлы в подкаталоге /doc;

* отдельный комплект поставки встраиваемого сервера версии 1.5 для Windows. Имя файла релиза комплекта поставки - Firebird-1.5.2.4731_embed_win32.zip.

! ! !

ПРИМЕЧАНИЕ. Не существует встраиваемого сервера для версии 1.0.x.

. ! .

 

Серверы

На платформах, имеющих сервисы - Windows NT, 2000 и XP - сервер Firebird инсталлируется по умолчанию для запуска как сервис. Сервис инсталлируется и запускается автоматически по окончании процедуры инсталляции, а также при первоначальной загрузке серверной машины. Как остановить и запустить сервер вручную см. главу 4.

Младшие из платформ Windows - Windows 95, 98 и ME - не поддерживают сервисы. После инсталляции сервер Firebird будет запускаться как приложение, защищенное программой Guardian. Если приложение сервера будет по разным причинам аварийно завершено, Guardian постарается заново запустить его. Для сервера, запущенного как сервис, рекомендуется также использовать Guardian.

Не пытайтесь инсталлировать Классический сервер, если у вас уже установлен Суперсервер, или наоборот.

 

Клиентские библиотеки

Копии клиентских библиотек устанавливаются:

* для Firebird 1.0.x имя клиентской библиотеки gds32.dll; она устанавливается в системный каталог C:\WINNT\system32 для Windows, имеющей сервисы, и в C:\Windows для других версий Windows;

* для Firebird 1.5 и последующих версий имя клиентской библиотеки fbclient.dll; по умолчанию она устанавливается в каталог /bin корневого каталога Firebird. По умолчанию утилиты загружают ее именно оттуда, а не из системного каталога.

! ! !

ПРИМЕЧАНИЕ. Для обычных клиентских приложений, включающих множество компонентов базы данных и инструменты администратора, размещение и именование клиентской библиотеки не являются столь строгими. См. в главе 7 альтернативные варианты инсталляции клиентской библиотеки - на сервере и на клиентских рабочих станциях - для совместимости со многими графическими инструментами и другими существующими приложениями.

. ! .

 

Сетевой протокол

Предполагается, что вы будете использовать рекомендованный протокол TCP/IP для вашей сети клиент-сервер, чтобы получить все преимущества независимой от платформы сети.

! ! !

СОВЕТ. Чтобы получить информацию об использовании протокола NetBEUI (Named Pipes, Именованные каналы) во всех версиях Windows, см. разд. "Сетевые протоколы" в главе 2.

. ! .

! ! !

ВНИМАНИЕ! Firebird не поддерживает IPX/SPX и не работает на Novel Netware 3 и 4.

. ! .

 

Тестирование сервера

Обычно первое, что вы захотите сделать после завершения инсталляции, - это проверить обращение к серверу. Это даст вам реальную возможность убедиться, что ваша клиентская машина может видеть хост в вашей сети. Предположим, что IP-адрес вашего сервера в домене, видимый вашему клиенту, 192.13.14.1. Перейдите в командную строку и введите следующую команду:

ping 192.13.14.1

Замените в этом примере IP-адрес на реальный IP-адрес вашего сервера.

! ! !

СОВЕТ. Если вы получили сообщение об истечении времени ожидания, обратитесь к главе 2 и приложению 2 для дальнейших инструкций. Если вам нужна более подробная информация об установках серверных IP-адресов, см. разд. "Сетевой адрес для сервера" в главе 2.

. ! .

Если вы соединяетесь с сервером с локального клиента - т. е. клиент запущен на той же машине, что и сервер, - вы можете обратиться к виртуальной заглушке TCP/IP:

ping localhost

ИЛИ

ping 127.0.0.1

 

Проверка, что сервер Firebird запущен

Классический сервер POSIX

Используйте команду ps в командной строке для просмотра запущенных процессов. Если какие-нибудь клиенты соединены с классическим процессом Firebird, вы должны увидеть один процесс с именем fb_netserver (или gds_inet_server для Firebird 1.0.x) для каждого соединенного клиента. Команда ps имеет несколько переключателей, однако следующий вариант дает подходящий список. Команда grep фильтрует вывод так, что вы будете видеть только процессы Firebird.

[xxx]$ ps -aux | grep fb

На рис. 1.4 запущены три клиентских процесса.

Рис. 1.4. Список классических процессов, полученный с помощью ps

Суперсервер POSIX

Поскольку Суперсервер разветвляется на потоки для каждого соединения, будет интересным задать переключатель -f [ork] среди других переключателей для отображения его процессов и потоков. Вы получите форматированное отображение разветвленных процессов, похожее на представленное на рис. 1.5:

[xxx]$ ps -auxf | grep fb

Рис. 1.5. Список процессов и потоков Суперсервера, полученный с помощью ps

Та же команда ps должна отображать один процесс с именем fbguard (или ibguard), если сервер был запущен с переключателем -f[orever], и один главный процесс с именем fbserver (или ibserver). Должен быть, по меньшей мере, один дочерний поток с именем fbserver (или ibserver), разделенный на несколько потоков. Эта первая группа является "выполняющимся сервером" без клиентских соединений, за исключением тех, которые использует сервер для прослушивания портов и сборки мусора. Далее будет группа потоков для каждого соединения.

! ! !

ПРИМЕЧАНИЕ. Префикс "fb" относится к Firebird 1.5, a "gdb" и "ib"- к Firebird 1.0.x. Используйте ps -aux | grep gds, если у вас запущена версия 1.0.x.

. ! .

Windows NT 4, 2000 и XP

Для серверных платформ Windows запустите апплет Firebird Server Control с Панели управления (Control Panel).

Апплет Server Control

На рис. 1.6 показан апплет Firebird Server Control, запущенный под Windows 2000 Server. Если вы использовали инсталлятор, этот апплет будет установлен на вашу Панель управления. Его внешний вид может изменяться в зависимости от варианта сервера Windows.

Рис. 1.6. Апплет Firebird Server Control

Вы можете использовать этот апплет для запуска и остановки сервиса и для модификации режимов запуска и выполнения. Не рекомендуется изменять режим на Run as an application (Выполнять как приложение) для многопользовательского использования в целях безопасности - вы должны оставлять подключение к серверу, чтобы сервер Firebird оставался запущенным.

Апплет Service

Если у вас нет апплета Control Panel, вы можете использовать апплет Services (рис. 1.7) в Инструментах администрирования. В Windows NT 4 вы можете получить доступ к этому апплету напрямую через Панель управления.

Рис. 1.7. Апплет Services на серверных платформах Windows

На рис. 1.7 показаны имена сервисов Firebird 1.5- для Guardian и сервера. Имена сервисов могут отличаться в зависимости от версий, Guardian может вовсе не появляться в списке. Пользователь с привилегиями администратора может, щелкнув правой кнопкой мыши по имени сервиса, остановить или запустить сервис. Если вы используете Guardian, остановите этот сервис, чтобы остановить и Guardian, и сервер.

В Windows 2000 и Windows Server 2003 Guardian скорее удобен, чем необходим, поскольку эти две операционные системы имеют средства просмотра и повторного запуска сервисов. Рекомендуется оставлять Guardian активным на других платформах, если пользователь SYSDBA недоступен для рестарта сервера вручную в случаях, когда он был остановлен по различным причинам.

Другие апплеты Панели управления

Если вам нужен апплет Firebird Manager и вы не нашли его инсталлированным на Панели управления вашего сервера Windows, или если вам нужен апплет с языком, отличным от английского, загрузите его с сайта Firebird: http://www.ibphoenix.com. Закройте окно Панели управления и скопируйте файл CPL непосредственно в ваш системный каталог Windows.

Windows 9х, ME и XP Home Edition

Windows 9х, ME и XP Ноте Edition не поддерживают сервисы. Сервер Firebird должен быть запущен как приложение, контролируемое программой Guardian. Если вы используете инсталляционный комплект, который устанавливает, но не запускает автоматически Guardian и сервер Firebird, вы можете сделать это вручную, как показано далее.

1. Найдите исполняемый файл программы Guardian (ibguard.exe) и создайте для него ярлык в области запуска меню кнопки Пуск.

2. Откройте диалоговое окно Свойства для этого ярлыка и перейдите к полю, где располагается командная строка.

3. Отредактируйте командную строку так, чтобы она выглядела следующим образом:

fbguard.exe -a

4. Сохраните и закройте диалог Свойства.

5. Сделайте двойной щелчок по ярлыку для запуска Guardian. Guardian запустит fbserver.exe.

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

Апплет Server Control

Некоторые версии апплета Server Control могут быть установлены на платформе Windows, не поддерживающей сервисы. Если инсталлятор устанавливает его на вашей машине, то он может быть использован так же, как было описано для версий, поддерживающих сервисы. Невозможно только выбрать вариант Run as a service (Запускать как сервис), даже если он отображается на экране. В Windows версии Ноше, чтобы исключить путаницу, апплеты бывают скрытыми или отображаются недоступными (серым цветом).

 

Пример структуры встроенной инсталляции

Приведем пример структуры каталогов и содержание файлов конфигурации для инсталлированного приложения встраиваемого сервера:

D:\my_app\MyApp.exe

D:\my_app\gds32.dll

D:\my_app\fb\firebird.conf

D:\my_app\fb\aliases.conf

D:\my_app\fb\firebird.msg

D:\my_app\fb\intl\fbintl.dll

D:\my_app\fb\UDF\fbudf.dll

Файл firebird.conf:

RootDirectory = D:\my_app\fb

Файл aliases.conf:

MyApplication = D:\databases\MyDB.fdb

 

Пользователи

Имя пользователя и пароль по умолчанию

Пользователь SYSDBA имеет все привилегии доступа к серверу. Программа инсталляции создаст пользователя SYSDBA в базе данных безопасности (security.fdb).

Для версий под Windows и версии 1.0.x под Linux пароль masterkey.

! ! !

СОВЕТ. Фактически пароль - masterke, т. к. все символы после восьмого игнорируются.

. ! .

В версии 1.5 и более поздних под Linux инсталлятор в процессе установки генерирует случайный пароль, помещает его в базу данных безопасности и сохраняет в текстовом файле SYSDBA.password. Запомните этот пароль или используйте для доступа к базе данных безопасности, чтобы изменить его на что-нибудь более простое для запоминания.

! ! !

ВНИМАНИЕ! Если ваш сервер совсем не защищен в Интернете, вы должны изменить этот пароль немедленно.

. ! .

Как изменить пароль пользователя SYSDBA

Если вы работаете в Linux или другой системе, которая может выполнять SH- скрипты, измените текущий каталог на ../bin в вашем каталоге инсталляции и найдите скрипт с именем changeDBAPassword.sh. Все, что вам нужно сделать, - это запустить скрипт и ответить на подсказки. Когда вы в первый раз запустите скрипт, вам будет нужно ввести пароль, который инсталлятор записал в файл SYSDBA.password; он находится в корневом каталоге Firebird:

[bin]# sh changeDBAPassword.sh

ИЛИ

[bin]# ./changeDBAPassword.sh

Прямое использование gsec

Следующая процедура будет работать под Windows и Linux. В Linux, чтобы запустить gsec, вы должны войти в операционную систему как суперпользователь (root). Пусть вы решили изменить у SYSDBA пароль с masterkey на icuryy4me (в Firebird 1.5 для Linux инсталлированный пароль не masterkey, он может оказаться совсем невразумительным!). Вам нужно выполнить следующие шаги:

1. Перейдите в окно командной строки на вашем сервере и сделайте текущим каталог, в котором находятся ваши утилиты командной строки. Обратитесь к табл. 1.2-1.5, чтобы определить их положение.

2. Для Windows наберите следующее, рассматривая символы, как чувствительные к регистру:

gsec -user sysdba -password masterkey

Для платформ POSIX наберите:

./gsec -user sysdba -password masterkey

Теперь вы должны увидеть подсказку утилиты gsec:

GSEC>

3. Наберите команду:

GSEC> modify sysdba -pw icuryy4me

4. Нажмите клавишу . Новый пароль icuryy4me будет зашифрован и сохранен, a masterkey не будет больше действовать.

5. Теперь завершите программу gsec:

GSEC> quit

Поскольку Firebird игнорирует все символы в пароле после восьмого, icuryy4m будет работать так же, как и icuryy4monkey.

! ! !

СОВЕТ. Полные инструкции по использованию gsec находятся в главе 34.

. ! .

Пользователи и группы в Linux/UNIX

Начиная с Firebird 1.5, пользователь root больше не является пользователем по умолчанию, который может запускать сервер. Это означает, что вам нужно поместить пользователей, не являющихся root, в группу firebird, чтобы предоставить им возможность доступа к базам данных.

Чтобы добавить пользователя (например, sparky) в группу firebird, пользователю root нужно ввести:

$ usermod -G firebird sparky

Теперь sparky может соединиться с базой данных Firebird и начать работу с ней.

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

$ groups

! ! !

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

. ! .

 

Инструмент администратора

Инсталляционный комплект Firebird не содержит инструментов администратора с графическим интерфейсом. У него есть набор инструментов командной строки (исполняемые программы), которые расположены в каталоге /bin каталога инсталляции Firebird. Их использование подробно описано в части IX.

Отличные инструменты графического интерфейса, доступные для использования на клиентских машинах Windows, слишком многочисленны, чтобы их здесь описать. Небольшое количество графических инструментов написано на Borland Kylix для использования на клиентских машинах под Linux, они находятся на разных стадиях завершения.

Список наиболее известных инструментов администратора для Firebird представлен в приложении 5. Для получения самого последнего списка зайдите на http://www.ibphoenix.com, выберите ссылку Contributed из области загрузки и нажмите на ссылку Administration Tools.

! ! !

СОВЕТ. Вы можете использовать клиентские инструменты администратора в Windows для доступа к серверу Linux и наоборот.

. ! .

 

Размещение на диске по умолчанию

Таблицы в этом разделе описывают размещение компонентов для Windows и Linux на диске по умолчанию. Информация дается в контексте двух версий:

* версии, предшествующие Firebird 1.5;

* версии Firebird 1.5 и последующие.

Разница является существенной. Версии, предшествующие Firebird 1.5, используют размещение, имена компонентов и ссылки на ресурсы, как и InterBase 6.x и более ранние версии InterBase. Следовательно, не существует возможности запускать и сервер Firebird, и сервер InterBase этих версий на одной и той же машине.

В пересмотре основного кода, который начался с версии 1.5, старые ссылки на постороннюю информацию InterBase были удалены, а многие из главных компонентов были переименованы. Firebird 1.5 дает возможность запускать также и сервер InterBase. Это верно и для Firebird 2.

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

Таблица 1.2. Инсталляция Firebird 1.5 для Linux и некоторых платформ UNIX

Таблица 1.3. Инсталляция Firebird 1.5 для 32-битовых платформ Windows

Таблица 1.4. Инсталляция Firebird 1.0.3 для Linux и некоторых платформ UNIX

Таблица 1.5. Инсталляция Firebird 1.0.3 для 32-битовых платформ Windows

Пора дальше

Firebird состоит из программы сервера и клиентских приложений; между сервером и каждым клиентом располагается сетевой протокол. Если вы использовали соответствующий инсталлятор для вашей платформы и использовали значения по умолчанию, вероятно, вам больше ничего не потребуется делать, и можно сразу приступать к началу работы. Вы можете пропустить две следующие главы и перейти к "основам", описанным в главе 4. Если вас интересуют сетевые протоколы или вам кажется, что у вас есть проблемы, связанные с сетевыми протоколами, прочтите следующую главу, и, возможно, просмотрите некоторые советы по конфигурированию в главе 3.

 

Клиент-сервер

Средства локального доступа.

* Локальная заглушка TCP/IP. Для многоуровневых серверных приложений и других клиентов доступ к локальному серверу на любой поддерживаемой платформе осуществляется через протокол TCP/IP: даже при отсутствии сетевой карты соединение может быть выполнено через специальный сервер localhost с IP-адресом 127.0.0.1.

! ! !

ВНИМАНИЕ! Соединение с localhost невозможно для приложений встраиваемого сервера.

. ! .

* Режим локального соединения Windows. Для клиентов Windows, использующих Суперсервер Firebird на той же самой физической машине, Firebird поддерживает режим локального соединения, используя межпроцессную передачу данных для моделирования сетевого соединения без интерфейса физической сети и сетевого протокола. Это полезно при доступе к базе данных в процессе разработки, для приложений встраиваемого сервера и для консольных инструментов клиента, но в этом варианте не поддерживается механизм событий Firebird и параллельная работа клиентской части из разных потоков приложения.

Средства локального соединения клиент-сервер являются ограниченными и не должны использоваться при поставках программ. Распространяйте автономные приложения клиент-сервер, Web-приложения и другие уровни серверов с использованием для соединения локально закольцованного протокола TCP/IP.

* Прямое локальное соединение в POSIX. Может ли локальный клиент соединяться с базой данных в Linux и в некоторых других системах POSIX, зависит, в первую очередь, от варианта сервера, который вы инсталлировали (Классический сервер или Суперсервер), и, во вторую очередь, от типа клиентского соединения.

Суперсервер совсем не принимает локальных соединений через обычный клиентский API. Путь для соединения всегда должен включать имя хоста TCP/IP. Тем не менее он принимает локальные соединения от "встроенных приложений" (приложений, написанных с использованием встроенного SQL - Embedded SQL, ESQL). Инструменты командной строки, gsec, gfix, gbak и gstat, которые являются встроенными приложениями, могут выполнять локальные соединения с Суперсервером.

Если у вас запущен Классический сервер, с локального клиента возможно прямое соединение.

 

Встраиваемый сервер

Начиная с Firebird 1.5, пакеты Firebird для Windows включают полную функциональность встраиваемого сервера (клиент и сервер соединяются как динамическая библиотека). Это идентично обычной модели клиент-сервер, за исключением того, что здесь не поддерживается сетевой протокол: соединение осуществляется в стиле "локальной Windows" для эмуляции сетевого соединения.

! ! !

ВНИМАНИЕ! Встраиваемый сервер не поддерживает пароль безопасности доступа Firebird.

. ! .

 

Местонахождение файла HOSTS

Перечислим, где можно найти файл HOSTS.

* В Linux и многих версиях UNIX файл HOSTS обычно расположен в /etc/. Помните, что имена файлов являются чувствительными к регистру на платформах семейства UNIX.

* В Windows NT/2000 файл HOSTS располагается в C:\WMNT\system32\drivers\etc\.

* В Windows 95/98/ME/XP/Server2003 файл HOSTS располагается в C:\Windows.

! ! !

СОВЕТ. Если файл HOSTS отсутствует, вы найдете файл с именем Hosts.SAM в том же месте. Скопируйте этот файл и переименуйте в HOSTS.

. ! .

Примеры записей файла:

10.12.13.2 db_server # Firebird-сервер (в LAN)

65.215.221.149 apress.com # (сервер в WAN)

127.0.0.1 localhost # локальная заглушка (в Windows)

127.0.0.1 localhost.localdomain # локальная заглушка(в Linux)

Откройте и отредактируйте файл HOSTS в текстовом редакторе. Создание записей простое. Тем не менее обеспечьте, чтобы:

* IP-адрес, если это не 127.0.0.1 (localhost), был действительным, сконфигурированным для хоста в вашей сети;

* имя сервера было любым уникальным именем в вашей сети;

! ! !

СОВЕТ. Серверная машина под Windows, которая была установлена в Windows Networking (Named Pipes) с именем хоста //Server_name, будет распространять это имя как имя хоста TCP/IP.

. ! .

* комментарии после символа # необязательны, но рекомендуются;

* формат записей одинаков, независимо от того, под какой системой запущен хост - Windows или Linux/UNIX.

! ! !

ВНИМАНИЕ! После того как вы отредактировали файл HOSTS, проверьте, что ваш редактор сохранил HOSTS без расширения имени файла. Если необходимо, удалите любое расширение, переименовав файл.

. ! .

 

Синтаксис строки соединения

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

TCP/IP

Строка соединения TCP/IP содержит два элемента: имя сервера и абсолютный путь диска/файловой системы, такой, как его видит сервер. Формат следующий:

* для соединения с сервером Linux:

имя-сервера: /путь-файловой-системы/файл-базы-данных

Вот пример для Linux или другой операционной системы семейства UNIX для сервера с именем hotchicken:

hotchicken:/opt/firebirdl5/examples/LeisureStore.fdb

! ! !

ВНИМАНИЕ! Помните, что для этих платформ все имена файлов являются чувствительными к регистру.

. ! .

* для соединения с сервером Windows:

имя-сервера:Диск: \путь-файловой-системы\файл-базы-данных

Пример:

hotchicken:С:\Program Files\Firebirdl5\examples\LeisureStore.fdb

Прямая наклонная черта также допустима в Windows:

hotchicken:С:/Program Files/Firebirdl5/examples/LeisureStore.fdb

Локальное соединение в Windows

Соединение встроенного клиента или локального внешнего клиента в локальном режиме Windows:

C:\Program Files\Firebirdl5\examples\LeisureStore.fdb

Сеть Windows (Named Pipes/WNet)

Соединение удаленного клиента сервера Windows с использованием протокола Named Pipes:

\\имя-сервера\Диск:\путь\файл-базы-данных

где \\имя-сервера - правильный идентификатор имени узла серверной машины в сети Windows, не может быть разделяемым или назначенным диском. Например,

\\hotchicken\c:\databases\LeisureStore.fdb

Несовместимые строки соединения для подключений Windows

Суперсервер для Windows устанавливает исключающую блокировку на файл базы данных, когда активируется первое клиентское подключение, чтобы защитить базы данных от старой ошибки.

Ошибка в пути соединения

Windows воспринимает две формы абсолютного локального пути к файлу - один (правильный в соответствии со стандартом DOS), имеющий вид устройство:\путь- к-базе-данных, и другой: Устройство: путь-к-базе-данных (отсутствует обратная наклонная черта после обозначения дискового устройства).

Если сервер получил два клиентских запроса на соединение, первое, использующее стандартную форму пути, и второе, с использованием второй формы, он будет трактовать эти два соединения, как если бы они были соединениями с двумя разными базами данных. Результатом параллельных операций DML в подобном случае будет разрушение базы данных.

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

! ! !

СОВЕТ. Настоятельно рекомендуется использовать алиасы базы данных (см. разд. "Алиасы базы данных" е главе 4) для всех соединений. Убедитесь также, что файл aliases.conf содержит один и только один алиас для каждой базы данных.

. ! .

 

Как сервер устанавливает прослушиваемый порт

Исполняемая программа сервера имеет необязательный переключатель в командной строке (-р), который можно использовать для указания номера порта или имени сервиса порта, который будет прослушиваться сервером. Если присутствует этот переключатель, то номер порта 3050 или имя сервиса порта (gds_db) будут заменены на значение аргумента, указанного в переключателе -р.

Затем- или вначале, если не установлен переключатель -р,- сервер версии 1.5 проверяет наличие параметров RemoteServicePort и RemoteServiceName В firebird.config.

* Если оба параметра закомментированы с использованием #, то принимаются значения по умолчанию, и никакие дальнейшие изменения не выполняются. Любой аргумент -р игнорируется, и "отсутствующие" аргументы сохраняют значение по умолчанию.

* Если RemoteServiceName (но не RemoteServicePort) не закомментирован, то имя сервиса порта заменяется, только если это имя не было уже перекрыто переключателем -р.

* Если RemoteServicePort и RemoteServiceName не закомментированы, ТО RemoteServiceName получает приоритет, если он не был перекрыт аргументом -р. Если же имя сервиса порта уже было изменено, то значение RemoteServiceName будет проигнорировано, и новое значение RemoteServicePort заменит предыдущее значение 3050.

* В этой точке, если замена номера порта или имени сервиса была выполнена, то оба сервера версий 1.0 и 1.5 выполняют проверку файла services на наличие записи с корректной комбинацией имени сервиса и номера порта. Если соответствие найдено, то все в порядке. Если нет, и имя сервиса порта не gds db, то сервер выдаст исключение и отменит запуск. Если имя сервиса порта gds db и ему не может быть назначен никакой другой порт, он будет использовать порт 3050 автоматически.

Если значение по умолчанию для номера порта или имени сервиса было изменено, то вам может понадобиться создать запись в файле services. Для понимания того, нужно ли это делать, выполните шаги, описанные далее в этой главе в разд. "Конфигурирование файла services".

Использование переключателя -p

Запуск сервера с необязательным переключателем -р дает вам возможность перекрывать значение по умолчанию для номера порта (3050) или имя сервиса порта (gds db), которые используются сервером для прослушивания запросов на соединение. Переключатель может перекрывать одно значение, но не оба. В Firebird 1.5 и следующих вы можете использовать переключатель -р в комбинации с конфигурацией в файле firebird.conf для получения возможности перекрывать и номер порта, и имя сервиса порта.

Синтаксис для TCP/IP

Шаблон синтаксиса для команд:

Команда-сервера <другие переключатели< -р номер-порта j имя-сервиса

Например, для запуска Суперсервера как приложения и замены имени сервиса с gds_db на fb_db введите:

fbserver -а -р fb_db

Для замены порта 3050 на 3051 введите:

fbserver -а -р 3051

Синтаксис для Wnet

Для сети Wnet замените аргумент переключателя -р на обратная черта-обратная черта-точка-@:

fbserver -а -р \\.@fb_db

ИЛИ

fbserver -а -р \\.@3051

Классический сервер в POSIX: демон inetd или xinetd

В Классическом сервере Firebird для Linux или UNIX демон inetd или xinetd сконфигурирован на прослушивание порта по умолчанию и имя сервиса по умолчанию. Инсталляционный скрипт запишет соответствующую запись в файл конфигурации /etc/inetd.conf или /etc/xinetd.conf.

Проблемы с подключением к Классическому серверу часто происходят по причине отсутствия или неправильной записи сервиса порта в этом файле. Вы можете проверить текущую запись, открыв файл в текстовом редакторе (например, vim) и скорректировав ее при необходимости. Следующий пример показывает, что вы должны увидеть в файле /etc/inetd.conf или /etc/xinetd.conf после инсталляции Классического сервера Firebird в Linux:

# default: on

# description: FirebirdSQL server

#

service gds_db

(

flags = REUSE KEEPALIVE

socket_type = stream

wait = no

user = root

# user = @FBRunUser@

log_on_success += USER1D

log_on_failure += USER1d

server = /opt/firebird/bin/fb_inet_server

disable = no

)

Если вы изменили сервис порта на значение, отличное от значения по умолчанию, вы должны соответственно изменить /etc/inetd.conf или /etc/xinetd.conf. Заново стартуйте xinetd (или inetd) с аргументом kill -HUP, чтобы убедиться, что демон будет использовать новую конфигурацию.

! ! !

ВНИМАНИЕ! Запросы на соединения будут неуспешными, если xinetd (или inetd) и fbserver (или ibserver) оба пытаются прослушивать один и тот же порт. Если ваша хост-машина имеет подобную дублирующую конфигурацию, то необходимо сделать такие установки, при которых каждая версия сервера имела бы свой собственный порт.

. ! .

Использование параметров файла конфигурации

В Firebird 1.5 и выше вы можете конфигурировать или RemoteServiceName, или RemoteServicePort в файле firebird.config для изменения номера порта по умолчанию (3050), или имени сервиса порта по умолчанию (gds_db), которые использует сервер для прослушивания запросов на соединение.

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

Если значения по умолчанию для номера порта или имени сервиса были изменены, то вам нужно создать запись в файле services.

! ! !

ВНИМАНИЕ! Если вы не закомментировали ни RemoteServiceName, ни RemoteServicePort, но оставили значения по умолчанию нетронутыми, они будут трактоваться как измененные. Необходимо создать запись в файле services для установок значений по умолчанию сервиса порта.

. ! .

 

Установка клиента для поиска порта сервиса

Если вы установили ваш сервер с инсталляционными значениями по умолчанию (сервис gds db прослушивает порт 3050), то конфигурирование не требуется. Если сервер прослушивает другой порт или используется другое имя сервиса порта, то приложение клиента и/или хост-машины требуют некоторых изменений конфигурации, чтобы помочь клиентской библиотеке Firebird найти прослушиваемый порт.

Строка соединения, используемая клиентом, может включать информацию для опроса прослушиваемого порта сервера разными путями. Клиенты Firebird 1.5 могут использовать локальную копию firebird.conf. Изменения также могут понадобиться и для файла services.

Использование строки соединения

Если были изменены только номер порта или имя сервера, включите альтернативный номер порта или имя сервера в строку соединения. Это работает для всех версий Firebird.

Синтаксис соединения TCP/IP

Для соединения с сервером базы данных, названным hotchicken, связанным с портом 3050 и сервисом fb_db, строка соединения в POSIX должна быть следующей:

hotchicken/fb_db:/data/leisurestore.fdb

Если же сервер имеет имя gds db, а номер порта 3051, то строка соединения должна быть следующей:

hotchicken/3051:/data/leisurestore.fdb

В Windows строка соединения должна быть:

hotchicken/3051:D:\data\leisurestore.fdb hotchicken/fb_db:D:\data\leisurestore.fdb

Обратите внимание, что разделитель между именем сервера и портом наклонная черта, а не двоеточие. Двоеточие требуется в строке физического пути после имени диска.

Синтаксис соединений Wnet

В сети Wnet используйте стиль нотаций UNC:

\\hotchicken@3051\d:\leisurestore.fdb

или

\\hotchicken@fb_db\d:\leisurestore.fdb

Если номер порта или имя сервиса были изменены, то вам нужно создать запись в файле services.

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

Для соединения через порт, не являющегося портом по умолчанию, с помощью алиаса базы данных добавьте номер порта или имя сервиса к имени сервера, а не к алиасу. Предположим, что алиас базы данных был сохранен в aliases.conf в виде:

hotstuff = /data/leisurestore.fdb

Строка соединения вашего приложения с сервером hotchicken будет следующей:

hotchicken/fb_db:hotstuff

или

hotchicken/3051:hotstuff

Использование копии firebird.conf

В Firebird 1.5 и выше вы можете скопировать на клиентскую сторону в корневой каталог Firebird файл firebird.conf и сконфигурировать RemoteServiceName или RemoteServicePort для помощи клиенту в поиске серверного порта.

Вы можете конфигурировать один из этих двух параметров; изменение значения другого параметра можно выполнить через строку соединения (см. ранее). Вы можете перекрыть значение только RemoteServiceName или RemoteServicePort без использования строки соединения.

Если вам не нужно передавать имя сервиса порта или номер порта в строке соединения, а сервер не использует значения по умолчанию для обоих параметров, вы можете конфигурировать оба RemoteServiceName и RemoteServicePort. Вы можете использовать эту технику, если вашему клиентскому приложению нужно сохранить возможность соединяться с серверами InterBase или Firebird 1.0.

Размещение данных Firebird на клиентах

Если вы используете на клиентских машинах файл firebird.conf, нужно, чтобы клиентская библиотека знала, где его найти. Вам необходимо создать корневой каталог Firebird и проинформировать систему о его местонахождении. Используйте для этого переменную среды FIREBIRD таким же образом, как и для серверов (см. главу 3). Клиенты Windows могут также использовать запись в реестре. При правильной установке клиента вы можете также сделать доступной локальную версию файла сообщений. Более подробную информацию см. в разд. "Инсталляция клиентов" в главе 7.

 

Конфигурирование файла services

Вам не нужно изменять запись сервиса порта для сервера или клиентов Firebird, если сервер использует значения по умолчанию, заданные при инсталляции - gds db для порта 3050. Если gds db - имя сервиса порта, который не может использовать любой другой порт, то он будет применять порт 3050 автоматически.

Если вы изменили номер порта или имя сервиса, вы должны сделать явные изменения для сервера и клиентов, чтобы отобразить эти изменения. В Linux и Windows данная информация хранится в файле services.

Местонахождение файла services

Местонахождение файла services на разных платформах:

* в Windows NT/2000/XP этот файл находится в C:\winnt\system32\drivers \etc\services;

* в Windows 95/98/ME файл находится в C:\Windows\services;

* в Linux/UNIX файл находится в /etc/services.

Записи файла services выглядят следующим образом:

gds_db 3050/t.cp # Firebird Server 1.5

Откройте файл в текстовом редакторе и добавьте новую строку или измените существующую запись gds db.

* Для сервера или клиента Firebird 1.0.x измените имя сервиса или номер порта для согласования с параметрами запуска сервера.

* Для сервера Firebird 1.5 или выше отредактируйте или добавьте нужную строку. Если у вас инсталлирован сервер Firebird 1.0 или InterBase на том же хосте, сохраните нужные для них записи и добавьте новую запись для согласования с параметрами запуска сервера.

! ! !

ПРИМЕЧАНИЕ. Если данная строка является последней в файле services, то рекомендуется в конце файла добавить пустую строку.

. ! .

 

Если ping выдает ошибку

Если вы получили нечто вроде

Bad IP address hotchicken (Неверный IP-адрес hotchicken)

то имя хоста в записи файла для имя-сервера (в этом примере hotchicken) может быть отсутствует или неверно написано. К примеру, все идентификаторы в Linux/UNIX являются чувствительными к регистру. Другая причина может заключаться в том, что имя хоста вашего сервера просто не было сконфигурировано.

Если вы увидите:

Request timed out

то это означает, что адрес IP, на который ссылается имя хоста в вашем файле, не может быть найден в подсети. Проверьте следующее:

* нет ошибок в имени хоста в записи файла;

* сетевой кабель подключен, провод и контакты не повреждены и не ржавые;

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

• Ограничения подсети: TCP/IP может быть сконфигурирован для ограничения трафика между подсетями. Если ваша клиентская машина является частью сложной сети или подсети, уточните у сетевого администратора, имеет ли она неограниченный доступ к серверу.

! ! !

ВНИМАНИЕ! WNet не позволяет направлять сетевой трафик между подсетями.

. ! .

• Система сетевой защиты (firewall): ваша проверка соединения может дать ошибку, если сервер базы данных находится под программной или аппаратной системой сетевой защиты, которая блокирует порт 3050 или сконфигурированный вами порт.

 

Проблемы с событиями

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

В Firebird 1.0.x ваш сетевой администратор должен установить некий способ, чтобы гарантировать наличие доступного порта, который всегда свободен, открыт и является статическим. Проблема может быть решена тем или иным образом в большинстве сетей.

Firebird 1.5 упрощает дело. Он делает возможным явно задавать IP-адрес в сети для трафика событий. Используйте параметр RemoteAuxPort в файле firebird.conf с целью статической установки IP-адреса для интерфейса (карта, маршрутизатор, шлюз и т.д.), который будет доступен для направления событий.

Более подробно о событиях Firebird см. главу 32.

 

Другие сетевые проблемы

Если дела идут плохо, вы можете найти немало советов в приложении 2.

Пора дальше

Куда дальше? Если у вас все в порядке с установками сети, и вам не терпится идти дальше, переходите прямо к главе 4 для изучения "основ", которые помогут вам соединиться с базой данных. Если же вы инсталлировали Firebird в мультипроцессорной системе, или вы подозреваете, что некоторые элементы конфигурации вашей машины могут вызвать проблемы, читайте дальше. Несмотря на то, что редко бывает нужным изменять конфигурацию Firebird для основных операций, в главе 3 описывается несколько опций конфигурации, которые могут помочь вам избавиться от головной боли.

 

POSIX

В Linux и UNIX самый простой путь установления переменных окружения - добавить их определения в общесистемный профиль значений по умолчанию.

Пользователь root также может:

* выдать команды setenv() из командной строки wu командного скрипта;

* для временного использования установить и экспортировать переменную из командной строки, например, export ISC_USER=SYSDBA.

 

ISC_USER и ISC_PASSWORD

Эффект этой опасной пары переменных окружения - дать доступ с правами пользователя SYSDBA к серверу Firebird и его базам данных через утилиты командной строки или клиентские приложения любому, кто может соединиться с хост-машиной. Они удобны для разработчиков.

Если вы не указываете имя пользователя и пароль при локальном соединении с базой данных, или когда вы запускаете утилиты командной строки, такие как gbak, gstat или gfix, Firebird проверяет, установлены ли переменные окружения ISC_USER и ISC PASSWORD. Если установлены, Firebird позволяет вам соединиться без указания пароля. Никогда не оставляйте эти переменные установленными на сервере, который содержит важные базы данных, если помещение, где располагается сервер, не является физически хорошо защищенным!

 

Переменная FIREBIRD (или INTERBASE)

Если установлена переменная окружения FIREBIRD (INTERBASE для версии 1.0.x), то она используется и при инсталляции, и в процессе работы на всех платформах для указания корневого каталога сервера Firebird. Если она присутствует, то перекрываются все другие установки - значения по умолчанию инсталляционного пакета, установки в реестре Windows, конфигурация в firebird.conf, значения глобальных путей операционной системы и т.д.

В процессе инсталляции она указывает на каталог, в котором должен быть установлен Firebird. Значение переменной должно задавать полный путь, который существует в физической файловой системе на хост-машине. При старте сервер читает значения в файле конфигурации firebird.conf (или ib_config/isc_config в версии 1.0.x), который должен находиться в каталоге, назначенном переменной FIREBIRD (ИЛИ INTERBASE). Этот каталог должен быть родительским для каталога bin, где размещаются двоичные файлы Firebird. Здесь также по умолчанию находятся файлы сообщений и замков: firebird.msg (interbase.msg) и hostname.lck.

! ! !

ПРИМЕЧАНИЕ. Вы можете указать другое размещение файлов firebird.msg (interbase.msg) и firebird.lck (interbase.lck), установив переменные окружения FIREBIRD_MSG (INTERBASE_MSG) и FIREBIRD_LOCK (INTERBASE_LOCK). см. следующие разделы.

. ! .

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

* /opt/firebird - для платформ Linux/UNIX;

* C:\Program FilesXFirebird (версия 1,0.x) или C:\Program Files\Firebird\Firebird_1_5 (версия 1.5) - для платформ Windows.

В табл. 1.2-1.5 в главе 1 указаны точные пути. Если Firebird установлен в каталоге, отличном от каталога по умолчанию, и задана переменная FIREBIRD, то клиентская библиотека будет читать значение переменной для определения пути инсталляции.

В Windows клиентские приложения могут также найти путь инсталляции, читая в реестре поле Defauitmstance, которое создается, если проводилась инсталляция только клиента.

HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird Server\Instances

Более подробное обсуждение способов поиска сервером размещения этих файлов см. далее в этой главе в разд. "Корневой каталог Firebird". Информацию об установках только клиента см. в разд. "Установка клиентов" главы 7.

 

FIREBIRD_TMP

По умолчанию Firebird будет использовать глобальное пространство временных файлов, обычно задаваемое как системное значение по умолчанию переменной окружения TMP (обсуждается далее). Переменная окружения FIREBIRD_TMP (В версии 1.0.x - INTERBASE TMP) задает пользовательское размещение для файлов сортировки Firebird. Значение должно указывать полный путь, который существует в физической файловой системе хост-машины.

Доступны также другие способы определения размещения этих файлов. Конфигурирование параметра TempDirectories (TMP_DIRECTORY в версии 1.0.x) описано в разд. "Файл конфигурации Firebird" и разд. "Параметры для конфигурирования пространства временной сортировки" главы 36.

 

*_LOCK и *_MSG

FIREBIRD_LOCK (INTERBASE_LOCK В версии 1,0.x) устанавливает расположение файла блокировок. FIREBIRD_MSG (INTERBASE_MSG в версии 1.0.x) устанавливает расположение файла сообщений Firebird.

Эти две переменные независимы друг от друга, они могут указывать различные размещения файлов. Значение должно указывать полный путь, который существует в физической файловой системе хост-машины.

 

TMP

Пространство сортировки на серверной машине

Пространство сортировки - это место на диске, где сервер сохраняет промежуточные результаты (во временных файлах) для запросов, которые требуют сортировки или используют агрегатные функции. Firebird 1.0.x для этого использует только дисковые файлы. Firebird 1.5, если может, сохраняет эти файлы в RAM и отправляет их на диск только в том случае, если оперативная память исчерпана.

Глобальная переменная окружения TMP (или TEMP В некоторых системах) указывает каталог на сервере, где приложения должны сохранять временные файлы. Firebird попытается сохранить временные файлы сортировки именно здесь, если не определена переменная окружения FIREBIRD_TMP (см. разд. "FIREBIRD TMP") и в файле конфигурации Firebird не указано пространство сортировки (см. переменные TempDirectories и TMP_DIRECTORY В главе 36).

Файлы скриптов isql на клиенте

Интерактивная утилита командной строки isql предоставляет возможность записывать последовательность интерактивных команд SQL в файл скрипта при использовании переключателя OUTPUT. На клиентской машине переменная TMP задает расположение этих файлов скриптов, если не было указано другого абсолютного пути. Если переменная TMP не установлена, то клиент Firebird использует любой другой временный каталог, который будет найден в локальной системе, обычно tmp в файловой системе клиента Linux/UNIX или C:\Temp в клиенте Windows.

 

Файл конфигурации Firebird

Firebird не требует постоянной сложной реконфигурации, которая необходима другими тяжеловесными РСУБД. Тем не менее целый ряд вариантов конфигурирования доступен для настройки сервера Firebird и хост-системы, на которой он выполняется, под ваши специальные требования.

Файл конфигурации Firebird называется firebird.conf для всех версий Firebird 1.5 и выше. В предыдущих версиях его имя зависело от операционной системы:

* isc config - в Linux/UNIX;

* ibconfig - в Windows.

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

Когда стартует сервер Firebird, он читает файл конфигурации и настраивает свои флаги времени выполнения (runtime flags), если файл конфигурации содержит значения, отличные от установленных по умолчанию. Данные из файла больше не будут считываться, пока не произойдет новый запуск сервера. Параметры конфигурации по умолчанию и их значения содержатся в файле конфигурации и закомментированы символом #. Нет необходимости убирать комментарий, чтобы сделать значения по умолчанию видимыми процедуре запуска сервера.

 

Изменение параметров конфигурации

Нет необходимости изменять значения по умолчанию, если только вы не собираетесь настроить некоторые из них. Это не рекомендуется делать, если вы не в полной мере понимаете, к чему это может привести.

Отдельные установки конфигурации по умолчанию, которые могут быть полезными для некоторых существующих приложений или инсталляций не по умолчанию, обсуждаются здесь вкратце. Полное описание параметров конфигурации см. в главе 36. Файл конфигурации можно редактировать любым текстовым редактором (например, vim в Linux или Блокнот в Windows). Не копируйте этот файл с машины Windows в Linux и наоборот, поскольку эти системы по-разному сохраняют символы перевода строки.

Записи параметров в файле firebird.conf представлены в форме:

имя_параметра = значение

где имя_параметра - строка, содержащая имя параметра (без пробелов), а значение - это число, логическая константа (1=Истина, 0=Ложь) или строка, которые задают значение параметра.

Для задания параметру значения, отличающегося от значения по умолчанию, удалите символ примечания (#) и отредактируйте значение.

Имена параметров и синтаксис в файле ibconfig/isc_config для Firebird 1,0.x отличаются от того, что может содержаться в firebird.conf. Формат, размер и количество параметров являются более ограниченными.

Формат в ibconfig/isc conflg:

имя_параметра значение

где промежуток между именем и значением может быть символами табуляции и пробелами (по желанию, как больше нравится). Каждая строка в файле ограничена 80 символами. Неиспользуемые параметры и инсталляционные значения по умолчанию закомментированы с помощью символа #.

Помните, что в Linux параметры чувствительны к регистру.

! ! !

ПРИМЕЧАНИЕ. Вы можете редактировать файл конфигурации и когда сервер запущен. Для активации изменений нужно остановить и заново запустить сервер.

. ! .

Корневой каталог Firebird

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

1. На любой платформе сервер в первую очередь смотрит глобальную переменную окружения FIREBIRD. Если он находит эту переменную, ее значение будет использовано без всяких условий.

2. Если переменная окружения FIREBIRD отсутствует, то для платформ Windows сервер отыскивает ключ в реестре

HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird Server\Instances

и смотрит поле oefauitinstance. Если он находит в данном поле правильный путь к каталогу, то использует это значение. Другие платформы не имеют подобного указателя.

3. Если корневой каталог все еще не найден, то предполагается, что временный корневой каталог располагается на один уровень выше каталога запущенного процесса (,.\ для Windows и ../ или ссылка на /proc/self/exe для POSIX, если доступно).

4. Теперь процедура запуска ищет в этом каталоге файл firebird.config. Если файл firebird.config найден, то процедура отыскивает параметр RootDirectory. Если параметр присутствует, его значение становится окончательно корневым каталогом, иначе промежуточное значение из n.3 становится окончательным значением.

! ! !

ВНИМАНИЕ! Если файл firebird.config не был найден на уровне, предшествующем запускаемому процессу, это может означать, что корневой каталог не был определен по причине нестандартной инсталляции. Сервер должен найти корневой каталог файлов. Если вам встретилась ошибка безопасности или ошибка файловой системы в процессе соединения или во время выполнения, вы должны пересмотреть ваши пути инсталляции, чтобы убедиться, что все действия, описанные в данном разделе, правильно определили корневой каталог файлов и подкаталоги.

. ! .

Параметры, связанные с доступом к файлам

Firebird имеет несколько параметров для защиты его файлов и баз данных от разрушающего или неавторизованного доступа. Если вы перемещаете приложение работы с базой данных или используете инструмент администратора для Firebird 1.5, вам следует обратиться к разд. "Файл конфигурации Firebird" в главе 36 для получения детальной информации об указанных далее параметрах.

* RootDirectory - может быть использован для изменения абсолютного пути к корневому каталогу в локальной файловой системе. Он должен оставаться закомментированным, если только вы не захотите изменить процедуру запуска, перекрыв путь к корневому каталогу инсталляции сервера Firebird (см. n. 3 в предыдущем разделе).

* DatabaseAccess - в Firebird 1.0.x сервер может соединяться с любой базой данных в его локальной файловой системе и всегда доступен приложениям, передающим абсолютный путь к файлу в файловой системе. Этот параметр был введен в версии 1.5, чтобы обеспечить более четкое управление безопасностью при доступе к файлам базы данных, а также для поддержки средства алиасов баз данных.

Инсталляция по умолчанию устанавливает значение параметра в Full, чтобы имитировать поведение Firebird версии 1,0.x. Альтернативные режимы могут ограничить доступ сервера только к базам данных с алиасами или к базам данных, размещенных в указанных каталогах файловой системы.

! ! !

ВНИМАНИЕ! Настоятельно рекомендуется установить этот режим и сделать доступным средство алиасов баз данных. Информацию об алиасах базы данных см. в главе 4.

. ! .

* ExtemaiFiieAccess - заменяет параметр EXTERNAL_FILE_DIRECTORY, введенный в версии 1,0. Этот параметр обеспечивает три уровня безопасности для External Files (внешние файлы - текстовые файлы фиксированного формата, к которым возможен доступ, как и к таблицам базы данных). Если вы переносите базу данных, в которой определены внешние файлы таблиц, вам нужно установить этот параметр для версии 1.5, потому что он отключен по умолчанию. Конфигурация необязательная, тем не менее рекомендуется для версии 1.0.x.

* UDFAccess - предназначен для защиты местоположения кода внешних модулей. Он заменяет не только необязательный параметр версии 1.0.x externai_function_ directory, но также и форму представления значения. Firebird 1.5 инсталлируется с отключенным по умолчанию доступом к библиотекам внешних функций, в то время как большинство серверов до этого давали полный доступ.

* TempDirectories (TMP_DIRECTORY в версии 1.0.x)- конфигурирование этого параметра является одним из способов задания размещения временного пространства сортировки для сервера, указав местоположение на диске. Синтаксис Firebird 1.5 отличается от синтаксиса Firebird 1.0.x.

Другие полезные параметры

Следующие параметры могут быть полезными в некоторых аппаратных конфигурациях.

* cpuAffinityMask (CPU_AFFINITY в версии 1.0.x)- может быть использован для назначения процессоров, которые Суперсервер в Windows будет использовать на машинах SMP. Эта проблема известна как эффект "see-saw", когда операционная система постоянно переключает выполнение Суперсервера между процессорами на некоторых машинах SMP. Свойство CPU должно быть установлено для одного процессора, если вам встретилась такая проблема.

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

* LockMemSize- параметр специфичен для Классических серверов; он определяет количество байтов разделяемой памяти, которая отводится для таблицы памяти, используемой менеджером блокировки. Вам может понадобиться изменить это количество, если вы встретите в Классическом сервере ошибку "Lock manager is out of room" (Менеджеру блокировки не хватает памяти). В связи с этой проблемой см. также параметр LockHashsiots.

* sortMemBiocksize и sortMemOpperLimit - эти два параметра были добавлены в версию 1.5, чтобы позволить устанавливать и ограничивать объем оперативной памяти, которую использует сервер при внутренней сортировке. Для Классического сервера этот размер по умолчанию слишком велик, чтобы поддерживать достаточно большое количество соединений.

* DummyPacketinterval(DUMMY_PACKET_INTERVAL в 1.0.x)- параметр - пережиток 16-битовых систем; он может стать причиной проблем в 32-битовых Windows. Это был старый параметр времени ожидания InterBase, предполагалось устанавливать количество секунд (целое число), в течение которых сервер должен был ожидать от клиента сообщений, после чего сервер должен был посылать пустой пакет для получения подтверждения. По умолчанию он установлен в 0 для Firebird 1.5(неактивен) и в 60 для Firebird 1.0.x. Он должен быть неактивным (установленным в 0) для всех систем Windows. Также настоятельно рекомендуется отключать его для других операционных систем.

* RemoteBindAddress - по умолчанию могут соединиться клиенты из любой сети, из которой сервер принимает трафик. Этот параметр позволяет связать сервис Firebird с исходными запросами через один IP-адрес (например, сетевая карта) и отклонять запросы соединения от любых других сетевых интерфейсов. Это помогает решать проблемы некоторых сетей, где сервер является хостом для нескольких подсетей. Не поддерживается в версии 1.0.x.

* compieteBooieanEvaiuation - параметр может быть использован для преобразования логики вычисления логических значений в виде сокращенного вычисления булевских выражений, используемой в Firebird 1.5 и выше, в полное вычисление булевских выражений, используемое в Firebird 1.0.x.

* oldparameterordering- восстанавливает старый способ обработки порядка параметров для запросов с подзапросами - сначала параметры подзапроса, затем параметры внешнего запроса. Firebird 1.5 по умолчанию обрабатывает параметры в точном порядке их следования, что может быть несовместимо со старыми версиями различных компонентов доступа, которые ориентировались на поведение InterBase/Firebird 1.0.

Пора дальше

Теперь нам больше ничего не осталось, кроме как соединиться с базой данных и начать выполнять серьезные эксперименты. Глава 4, последняя в нашем "учебном лагере", даст вам возможность соединиться с примером базы данных или с любой другой совместимой с Firebird базой данных, которая может находиться на вашем сервере.

 

Суперсервер

Каталог инсталляции по умолчанию /opt/firebird. В каталоге /bin находится в двоичном формате сервер Firebird fbserver (ibserver для Firebird 1.0.x), который запускается как процесс-демон в Linux/UNIX. Он запускается автоматически после инсталляции посредством RPM или скрипта и каждый раз при перезагрузке сервера запуском скрипта демона firebird, находящегося в /etc/rc.d/init.d (или /etc/init.d в SuSE), который вызывает утилиту командной строки Firebird Manager - fbmgr.bin. Firebird Manager может быть использована из командной строки для запуска и остановки процесса вручную.

Запуск сервера

Если вы по разным причинам запустили Firebird вручную, соединитесь с ним как пользователь root или firebird. Запомните, какую учетную запись вы использовали при запуске fbserver, потому что все созданные объекты будут принадлежать пользователю с этой учетной записью. Если позже другой пользователь запустит процесс с использованием другой учетной записи пользователя, то эти объекты будут ему недоступны.

Настоятельно рекомендуется создать системного пользователя с именем firebird и запускать сервер Firebird с этой учетной записью.

Для запуска процесса выполните из командной строки следующую команду:

./fbmgr.bin -start -forever

Для версий Firebird, предшествующих 1.5, выполните:

./ibmgr -start -forever

Переключатель -forever означает, что Guardian будет управлять запуском. При использовании Guardian процесс сервера будет заново запущен, если он по каким-либо причинам завершится аварийно.

Для запуска сервера без использования Guardian введите:

./fbmgr.bin -start -once

Для версий Firebird, предшествующих 1.5, выполните:

./ibmgr -start -once

Переключатель -once означает, что если сервер будет аварийно завершен, перезапустить его можно будет только вручную.

Остановка сервера

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

Переключатель -shut отменяет все текущие транзакции и прекращает работу сервера немедленно.

Вам не требуется быть подключенным как пользователь root для остановки сервера Firebird fbmgr, но вы должны иметь полномочия пользователя SYSDBA. Выполните следующую команду.

./fbmgr.bin -shut -password <пароль SYSDBA>

Используйте команду для версий, предшествующих 1.5:

./ibmgr.bin -shut -password <пароль SYSDBA>

Управляемое завершение работы

На этой платформе Firebird не имеет утилиты для подсчета количества пользовательских соединений с базой данных для Суперсервера. Если вам нужно предоставить клиентам интервал времени для завершения работы и корректного отключения, завершайте работу индивидуальных баз данных с использованием инструмента gfix с переключателем -shut и одним из доступных аргументов для управления отключением. (См. разд. "Останов базы данных" в главе 39.)

Другие команды fbmgr

Синтаксис

Из командной строки:

./fbmgr.bin -команда [-режим [параметр] ...]

Альтернативно вы можете стартовать интерактивную сессию fbmgr или ibmgr из командной строки (например, перейдя в режим с подсказкой). Наберите:

./fbmgr <нажмите Return/Enter>

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

FBMGR>

В режиме с подсказкой синтаксис команд:

FBMGR> команда [-режим [параметр] ...]

Например, вы можете запустить сервер одним из следующих способов. Из командной строки:

./fbmgr -start -password пароль В режиме с подсказкой:

FBMGR> start -password пароль

Переключатели fbmgr

В табл. 4.1 представлен список переключателей fbmgr и ibmgr, доступных из командной строки и из режима с подсказкой.

Таблица 4.1. Переключатели fbmgr/ibmgr

 

Классический сервер

Классический сервер Firebird использует процессы xinetd или inetd для обработки поступающих запросов. (Применяемый процесс зависит от версии Linux.) Нет необходимости явно запускать сервер. Процесс xinetd или inetd запускается автоматически; когда он получает запрос от клиента Firebird на соединение, он порождает копию процесса fbinetserver для этого клиента.

Как сервер прослушивает запросы на соединение

Если Классический сервер Firebird был установлен инсталлятором, использующим скрипты или RPM, то файл конфигурации запуска для fb inet server с именем firebird должен быть добавлен в сервисы, о которых знает [x]inetd. В большинстве дистрибутивов Linux этот файл размещается в каталоге /etc/xinetd.d. Чтобы [x]inetd "слушал" запросы на соединение от клиентов для вашего Классического сервера Firebird, скрипт firebird должен находиться в том же каталоге, где стартует процесс [x]inetd.

! ! !

СОВЕТ. Если [x]inetd запущен, и ни одного запроса на соединение клиента не последовало вовсе, проверьте, действительно ли скрипт firebird находится там, где он должен быть. Если нет, то вы можете выделить скрипт firebird.xinetd из файлового комплекта инсталляции, скопировать в нужный каталог и переименовать в firebird. Чтобы [x]inetd "видел" сервис Firebird, остановите и заново запустите [x]inetd.

. ! .

Остановка и запуск [x]inetd и его сервисов

Демон [x]inetd сам является сервисом, который по запросу управляет другими сервисами, например Классическим демоном Firebird. Остановка [x]inetd приведет к тому, что все процессы, которыми он управляет, будут также остановлены. Его запуск или повторный запуск приведет к возобновлению прослушивания запросов и запуску управляемых им процессов.

Если все сервисы в каталоге ../rc.d являются безопасными для остановки, соединитесь как пользователь root и остановите [x]inetd следующей командой из командной строки:

ft service xinetd stop или командой:

# service inetd stop

Если [x]inetd не был сконфигурирован для автоматического перезапуска после остановки, запустите его командой:

# service xinetd restart

Остановка процесса Firebird

Если вам нужно остановить вышедший из-под контроля процесс Firebird в Классическом сервере, вы можете это сделать. Найдите ошибочный процесс, выполнив команду top из командной строки. Эта утилита отображает список наиболее интенсивно использующих CPU процессов, постоянно обновляя этот список. Любой экземпляр fb inet server с необычным использованием ресурсов должен появиться в этом списке.

Выберите идентификатор (process ID, PID) ошибочного процесса fb_inet_server из самой левой колонки в списке. Вы можете использовать этот PID в команде kill для посылки сигнала ошибочному процессу. Например, для PID 12345 вы можете попытаться остановить процесс, выдав:

# kill 12345

Если процесс остается видимым в списке утилиты top, вы можете попытаться форсировать остановку процесса:

# kill -9 12345

! ! !

ВНИМАНИЕ! Проявляйте величайшую осторожность при использовании команды kill, особенно если вы подключились как пользователь root.

. ! .

 

Суперсервер

Выполняемая программа Суперсервера Firebird - fbserver.exe. Хотя он может запускаться и как самостоятельная программа, он также может находиться под управлением Guardian - fbguard.exe. Guardian обеспечивает возможность эмулировать автоматический рестарт сервисов в Windows и POSIX, запущенных с переключателем -forever. Если приложение fbserver.exe аварийно завершается, Guardian пытается заново его запустить. Рекомендуется использовать Guardian на хостах, работающих на платформах Windows 95/98 и ME, а также NT/XP, если сервер выполняется как приложение.

В Windows NT и Windows 2000 программа сервера Firebird может выполняться как сервис и как приложение. Инсталляция по умолчанию устанавливает сервер Firebird - и Guardian, если выбран - для автоматического выполнения как сервисы. Вариант выполнения для обоих может быть изменен, чтобы они выполнялись как приложения.

В Windows 95/98, ME и XP Home Edition Firebird может выполняться только как приложение. Если Firebird выполняется как приложение, на панели задач появляется соответствующая иконка. Некоторые задачи администрирования могут быть выполнены вручную при щелчке правой кнопкой мыши на этой иконке.

 

Выполнение Firebird как сервиса в Windows NT, 2000 и XP

Если данный компьютер используется как сервер БД, то вам настоятельно рекомендуется выполнять сервер Firebird как сервис.

! ! !

ПРИМЕЧАНИЕ. Пользователи, выполняющие миграцию с InterBase 6.0 или более раннего, должны обратить внимание, что не требуется выполнения Firebird как приложения на хост-машинах SMP, чтобы установить наличие только одного процессора. Опция сервиса Firebird по использованию количества процессоров содержится в файле конфигурации. Более подробную информацию см. в разд. "Файл конфигурации Firebird" главы 36.

. ! .

Запуск и остановка сервиса вручную

Для остановки сервиса вручную откройте окно командной строки и введите следующую команду:

NET STOP FirebirdServer

Дня старта или рестарта сервера вручную введите команду:

NET START FirebirdServer

! ! !

ВНИМАНИЕ! Поскольку команды NET возвращают сообщения в окно командной строки, не пытайтесь запустить их в окне Выполнить (Run) через кнопку Пуск (Start).

. ! .

Использование утилиты instsvc

Альтернативный, "родной" для Firebird способ запуска и остановки сервисов Firebird и Guardian - использование утилиты instsvc.exe, которая находится в каталоге \bin в корневом каталоге Firebird. Утилита instsvc.exe применяется системой для запуска сервиса Firebird- и Guardian, если выбран- когда выполняется первоначальная загрузка хост-сервера. Поскольку с самого начала не ожидалось частого использования ее людьми - это команда в стиле DOS, содержащая переключатели.

! ! !

ПРИМЕЧАНИЕ. Firebird 1.5 содержит дополнительный необязательный переключатель для соединения, чтобы позволить скриптам инсталлятора добавить возможность создания "реального пользователя"- подключенного пользователя для установки сервиса при загрузке системы. Это рекомендуется сделать, т. к. скрипты создают пользователя Firebird с ограниченными привилегиями; соответственно устанавливается инсталляция сервиса. (См. разд. "Защита, основанная на платформе" в главе 33.)

. ! .

Останов и рестарт сервиса с использованием instsvc

Откройте окно командной строки и перейдите к каталогу \bin, находящемуся в корневом каталоге установки Firebird. Для останова сервиса Firebird введите:

C:\Program Files\Firebird\Firebird_1_5\bin> instsvc stop

Для старта (рестарта) сервиса Firebird используйте одну командную строку, изменив, при необходимости, приоритет процесса:

C:\Program Files\Firebird\Firebird_1_5\bin> instsvc start

[-boostpriority | -regularpriority]

! ! !

ПРИМЕЧАНИЕ. Эти команды не выполняют, соответственно, деинсталляцию и инсталляцию сервиса.

. ! .

 

Апплеты Firebird Manager

Когда Firebird выполняется как сервис, небольшое количество административных задач, включая останов и рестарт, может быть решено с использованием апплета Firebird Manager на Панели управления. Самый простой апплет инсталлируется при установке Firebird. Более сложные апплеты, включая версии языков, можно загрузить из Firebird CVS с сайта SourceForge или с различных сайтов, связанных с Firebird.

 

Запуск сервера как приложения вручную

Если Суперсервер не запущен, или Классический сервер не инициализирован, он может быть запущен вручную при выборе в меню Firebird - Пуск | Все программы | Firebird (Start | Programs | Firebird).

Альтернативно можно стартовать сервер или Guardian из командной строки. Вызовите окно командной строки и перейдите к каталогу \bin в каталоге инсталляции Firebird. Выполните следующие действия в соответствии с тем, собираетесь ли вы использовать Guardian или будете запускать сервер без возможности автоматического рестарта.

Суперсервер

Программа Guardian называется fbguard.exe в Firebird 1.5 и idguard.exe в более ранних версиях. Используйте следующую команду для старта Guardian:

fbguard.exe -a

ibguard.exe -а /* для версии 1.0.x */

Guardian размещает свою иконку на системной панели и автоматически стартует Суперсервер.

Имя программы сервера для Суперсервера fbserver.exe (ibserver.exe в Firebird l.O.x). Для запуска Суперсервера напрямую, минуя защиту Guardian, используйте команду:

fbserver.exe -a

ibserver.exe -а /* для версии 1.0.x */

Сервер стартует и размещает свою собственную иконку на системной панели.

Классический сервер

! ! !

ПРИМЕЧАНИЕ. Этот текст относится к Firebird 1.5 и следующим. Классический сервер для Windows не поддерживается в более ранних версиях.

. ! .

Основное преимущество выполнения Классического сервера в Windows - его возможность использовать мультипроцессорные системы. Эта функция недоступна в случае Суперсервера для многих систем SMP. Тем не менее, поскольку использование памяти Классическим сервером находится в прямой зависимости от количества одновременных подключений, может оказаться невозможным устанавливать систему на сайтах, где ресурсы сервера не обеспечивают поддержки большого количества пользователей в системе.

Процесс, который является "ушами" для запросов клиентов на соединение с Классическим сервером, является начальным экземпляром программы fb_inet_server.exe. Если начальный экземпляр fb_inet_server.exe не запущен, то не будет возможно соединение клиент-сервер; при попытке соединения вы получите сообщение об ошибке "Unable to connect to the server. Database cannot be found" (Невозможно соединиться с сервером. База данных не может быть найдена).

Когда клиенты соединяются с базой данных, для каждого клиентского соединения запускается один экземпляр fb_inet_server.exe (1.2 Мбайт) и, если сконфигурировано, один экземпляр Guardian на все экземпляры fb_inet_server.exe. Для каждого соединения выполняется собственное выделение кэш-памяти.

Классический сервер и Guardian

Случайно или умышленно, инсталлятор Firebird 1.5.0 имеет небольшую, но приводящую в замешательство аномалию. Если вы не отметите в процессе инсталляции режим Use Guardian (Использовать Guardian), инсталлятор поместит версию для Суперсервера программы Guardian в каталог \bin, и он никогда не будет работать с Классическим сервером. Если вы отметите этот режим, то в процессе инсталляции получите сообщение об ошибке, однако инсталлированная версия Guardian будет прекрасно работать с Классическим сервером. Вы можете проверить, правильная ли у вас версия, попытавшись запустить Guardian. Если вы увидите диалоговое окно сообщения об ошибке, содержащее слово "fbserver", значит, вы не выбрали поддержку Guardian в процессе инсталляции.

В любом случае Guardian является лишним для Классического сервера. Вы ничего не потеряете, если не будете его инсталлировать. Я рекомендую игнорировать Guardian для Классического сервера.

Для запуска начального экземпляра Классического сервера как приложения вручную вызовите окно командной строки, перейдите в каталог \bin и наберите:

fb_inet_server.exe -a

Иконка сервера должна появиться на системной панели. Ваш сервер теперь готов к получению запросов на соединение.

Вы можете альтернативно выбрать режим Use Guardian в процессе инсталляции. Вы также можете стартовать Guardian из того же каталога:

fbguard.exe -с -a

В этом случае иконка Guardian появится на системной панели, однако она не может быть использована для отмены инициализации сервера (см. ранее в разд. "Классический сервер" замечание о Классическом сервере).

 

Останов сервера

Останов сервера- операция, которая по-разному воздействует на Суперсервер и Классический сервер.

Суперсервер

Щелкните правой кнопкой мыши по иконке Guardian или сервера и выберите в контекстном меню Shutdown (Остановить). Если выполняется Guardian, то сначала он остановит сервер, а затем закроется сам. Подключенные в этот момент пользователи потеряют всю неподтвержденную работу.

Классический сервер

В большинстве случаев нет необходимости "останавливать" Классический сервер. Выбор варианта Shutdown в контекстном меню иконки сервера предотвратит новые соединения с сервером, но это не будет воздействовать на подключенные процессы.

! ! !

ПРИМЕЧАНИЕ. Щелчок мышью по варианту Shutdown в контекстном меню Guardian ничего не выполняет.

. ! .

Очень редко бывает нужным (если вообще бывает) останавливать Классический сервер вручную, поскольку закрытие клиентского соединения завершает этот процесс чисто и корректно. Единственный способ остановить Классический сервер, который выполняется как приложение, - применение "грубой силы", через Диспетчер задач.

 

aliases.conf

Средство алиасов включает файл конфигурации aliases.conf. Он находится в корневом каталоге вашей инсталляции сервера и не должен перемещаться оттуда.

 

Переносимость

До реализации 1.5 все клиентские приложения соединялись с сервером, используя строку соединения, которая включала абсолютный путь к серверу. Формат абсолютного пути меняется в зависимости от того, выполняется ли сервер под Windows или на POSlX-совместимой платформе (Linux, UNIX и т.д.), а для серверов под Windows еще и от того, какой вид сетевого соединения используют клиенты - TCP/IP или NetBEUI.

Предположим, у вашего сервера имя hotchicken. Если сервер выполняется на POSIX- совместимой платформе; клиенты TCP/IP будут соединяться с базами данных, используя строку соединения следующего формата:

hotchicken:/opt/databases/Employee.fdb

Если же сервер работает под Windows, клиенты TCP/IP должны соединяться, используя другой формат пути:

hotchicken:D:\databases\Employee.fdb

Средства алиасов базы данных делают эту разницу для клиентов TCP/IP прозрачной. Абсолютный путь строки соединения помещается в файл алиасов, связывая этот путь с простым именем алиаса. Например, в файле aliases.conf для сервера под Linux наш пример может быть сохранен как

dbl = /opt/databases/Employee.fdb

Для сервера в Windows, инсталлированного для клиентов TCP/IP, это может быть

dbl = D:\databases\Employee.fdb

Независимо от того, где установлен сервер - под Windows или POSIX - строка соединения для клиентов становится одинаковой:

hotchicken:dbl

Тем не менее это средство не является столь изящным, если вы хотите сделать строку соединения вашего приложения прозрачной как для соединений TCP/IP, так и NetBEUI. Нотация UNC для сервера под Windows для клиентов NetBEUI предполагает совместимость, однако если алиас базы данных идентичен, то серверная часть не является переносимой:

\\hotchicken\dbl в сравнении с:

hotchi cken:dbl

 

Управление доступом

Основное преимущество средства алиасов в том, что оно может быть использовано в комбинации с параметром DatabaseAccess = NONE из файла firebird.conf для ограничения доступа к файлам баз данных - доступ разрешен только к файлам, указанным в aliases.conf.

Алиасы баз данных появились в Firebird 1.5. Для их использования отредактируйте файл aliases.conf в корневом каталоге инсталляции Firebird, используя текстовый редактор, такой как Блокнот (в Windows) или V1 (Linux).

Структура файла aliases.conf

Инсталлированный файл aliases.conf выглядит приблизительно таким образом:

#

# List of known database aliases

# ---------------------------------------------

#

# Examples:

#

# dummy = c:\data\dummy.fdb

#

Как и во всех файлах конфигурации Firebird, символ # является маркером комментариев. Для конфигурирования алиаса просто удалите символ # и замените строку dummy на соответствующий путь к базе данных:

# fbdbl и aliases.conf находится на сервере Windows:

fbdbl = c:\Firebirdl5\sample\Employee.fdb

# fbdb2 и aliases.conf находится на сервере Linux

fbdb2 = /opt/databases/killergames.fdb

#

При каждом запросе на соединение, содержащем путь, заданный в формате алиаса, сервер обращается к файлу aliases.conf. Вы можете редактировать aliases.conf и когда сервер выполняется. Изменения не будут влиять на текущие соединения, но новые соединения будут использовать новые или измененные алиасы.

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

Для соединений TCP/IP, использующих предыдущий пример aliases.conf, измененная строка соединения в вашем приложении будет иметь следующий формат:

Имя_сервера:имя_алиаса

Например,

hotchicken:fbdb2

Для соединений Windows Named Pipes строка выглядит следующим образом:

\\hotchicken\fbdb2

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

 

fbmgr/ibmgr

fbmgr/ibmgr является командой и интерфейсом командной строки для демона Суперсервера в Linux для запуска и останова Суперсервера Firebird в Linux. Скрипт командной строки fbmgr (ibmgr в версии 1.0.x) предоставляет интерфейс для выполняемого модуля сервера fbmgr.bin (ibmgr.bin в версии 1.0.x). Детальное описание представлено в этой главе.

 

instsvc.exe

Это интерфейс командной строки сервиса Суперсервера на платформах Windows NT для инсталляции, запуска и останова Суперсервера Firebird в Windows. Детальное описание представлено в этой главе.

 

gbak

Эта утилита предназначена для резервного копирования и восстановления баз данных. Поскольку она работает на уровне структур и форматов данных, gbak является единственной корректной утилитой для копирования. Она также обнаруживает разрушения базы данных, освобождает дисковое пространство, появившееся в результате удалений, разрешает незавершенные транзакции, позволяет разделять базы данных на несколько файлов. Она также используется для создания переносимой копии с целью восстановления вашей базы данных на другой аппаратной платформе или для обновления ODS (On-Disk Structure) вашей базы данных.

! ! !

ВНИМАНИЕ! Никогда не используйте утилиты копирования файлов типа tar/gzip, WinZip, Microsoft Backup, средства копирования файловой системы или утилиты сторонних разработчиков для копирования и переноса баз данных, если сервер работает или у вас нет твердой уверенности, что база данных не повреждена. Базы данных, которые переносятся как копии файлов, будут содержать неубранный мусор.

. ! .

Подробности использования gbak см. в главе 38.

 

gsec

Этот инструмент поддержки списка пользователей и их паролей является интерфейсом командной строки для базы данных security.fdb; он управляет записями пользователей на сервере Firebird. Подробности использования gsec см. в главе 34.

 

gfix

Это набор общих вспомогательных утилит для изменения свойств баз данных, устранения небольших повреждений базы данных, выполнения различных задач чистки и т.д. Утилита также предоставляет средство администратора для отключения конкретных баз данных до завершения работы сервера. Она может быть использована вместе с утилитой gbak для восстановления некоторых типов нарушений в базе данных (см. разд. "Ремонт базы данных" приложения 4).

Подробности использования gfix см. в главе 39.

 

gstat

Этот инструмент получения статистики собирает и отображает статистические сведения по индексам и данным базы данных. Подробную информацию об использовании gstat см. в разд. "Темы оптимизации" главы 18.

fb_lock_print

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

Подробности использования fb_lock_print см. в главе 40.

 

Запуск isql

Есть несколько различных способов соединения с базой данных при использовании isql. Один способ- стартовать утилиту из командной строки в интерактивном режиме. Для начала в окне командной строки перейдите к каталогу /bin корневого каталога инсталляции Firebird, где инсталлирована программа isql, и запустите isql следующим образом.

Для сервера POSIX:

[chick@hotchicken]# ./isql <нажмите Return/Enter> Для сервера Windows:

C:\Program Files\Firebird\Firebird_1_5\bin>isql <нажмите Return/Entei>

Утилита выведет следующее сообщение:

Use CONNECT or CREATE DATABASE to specify a database (Используйте CONNECT или CREATE DATABASE для указания базы данных)

 

Использование isql

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

 

Оператор CONNECT

Оператор CONNECT является стандартным оператором SQL для соединения с базой данных. Здесь предполагается, что вы пока не изменили пароль у пользователя SYSDBA. Если вы это уже сделали (что рекомендуется), то используйте ваш пароль пользователя SYSDBA.

Каждый из операторов командной строки в следующих примерах является одним оператором.

Для соединения с сервером Linux/UNIX введите:

SQL> CONNECT 'hotchicken:/opt/firebird/examples/employee.fdb' user 'sysdba' password 'masterkey';

Для соединения с сервером Windows:

SQL> CONNECT

'WINSERVER:С:\Program Files\Firebird\Firebird_1_5\examples\employee.fdb'

user 'SYSDBA' password 'masterkey';

! ! !

ПРИМЕЧАНИЕ. В Классическом сервере под Linux и в Суперсервере под Windows существует возможность соединения с базой данных локально, например:

CONNECT '/opt/firebird/examples/employee.fdb' - Linux Классический сервер.

CONNECT 'c:\Program Files\Firebird\Firebird_1_5\examples\employee.fdb' - Windows Суперсервер.

. ! .

Убедитесь, что вы заканчиваете каждый оператор SQL символом точка с запятой (;). Если вы забудете это сделать, то увидите следующее в подсказке продолжения утилиты isql:

CON>

Когда вы увидите подсказку продолжения, просто введите точку с запятой и нажмите клавишу . В этот момент isql проинформирует вас, что вы соединены:

DATABASE 'hotchicken:/opt/firebird/examples/employee.fdb', User: sysdba SQL>

Если сервер работает под Windows, вы увидите следующее:

DATABASE "WINSERVER:С:\Program Files\Firebird\Firebird_1_5\examples\employee.fdb",

User: sysdba

SQL>

Продолжим играть с базой данных employee.fdb. Вы можете использовать isql для запроса данных, получения информации о метаданных, создания объектов базы данных, выполнения скриптов определения данных и многого другого.

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

SQL> QUIT;

 

Создание базы данных с использованием isql

Существует более одного способа создания базы данных с использованием isql. Здесь приведен один простой способ интерактивного создания базы данных - тем не менее для работы с серьезной базой данных вы должны создавать и поддерживать объекты метаданных, используя скрипты определения данных (они также называются скриптами DDL, скриптами SQL, скриптами метаданных и скриптами схемы). Эта тема детально рассматривается в разд. "Скрипты схемы"главы 14.

Если сейчас вы соединены с базой данных через утилиту isql, отсоединитесь с помощью следующей команды:

SQL> QUIT;

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

[chick@hotchicken]# ./isql

Use CONNECT or CREATE DATABASE to specify a database

Для сервера Windows:

С:\Program Files\Firebird\Firebird_1_5\bin>isql Use CONNECT or CREATE DATABASE to specify a database

 

Оператор CREATE DATABASE

Теперь вы можете создать вашу новую базу данных интерактивно. Предположим, что вы хотите создать базу данных test.fdb на сервере Windows и сохранить ее в каталоге data на диске D:

SQL> CREATE DATABASE 'D:\data\test.fdb' user 'SYSDBA' password 'masterkey';

База данных будет создана, и через некоторое время снова появится подсказка. Теперь вы соединены с новой базой данных и можете продолжать создавать в ней тестовые объекты.

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

SQL> SELECT * FROM RDB$RELATIONS; <нажмите Enter>

Экран будет заполнен большим количеством данных! Этот запрос выбирает все строки из системной таблицы, в которой Firebird сохраняет метаданные для таблиц. "Пустая" база данных не является пустой - она содержит базу данных, которая будет заполняться метаданными, как только вы начнете в ней создавать объекты.

! ! !

СОВЕТ. Почти все объекты метаданных в базах данных Firebird имеют идентификаторы, начинающиеся с символов "RDB$".

. ! .

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

SQL> QUIT;

Полную информации по использованию isql см. в главе 57.

Пора дальше

Часть II рассказывает об архитектуре клиент-сервер. В главе 5 рассматривается терминология и различные модели реализации сетей клиент-сервер. В главах 6 и 7 более подробно рассматриваются серверы и клиенты Firebird соответственно.

 

Масштабируемость

Появление сравнительно недорогих компьютерных сетей между 1980-ми и 1990-ми годами вызвало увеличенный спрос на масштабируемые информационные системы с дружественным пользователю интерфейсом. Программное обеспечение электронных таблиц и настольных баз данных, а также графический интерфейс дали пользователям, не являющимся специалистами, понимание мощности использования компьютеров. Когда совместное использование файлов в сетях и различного вида программного обеспечения стало стандартной практикой на больших предприятиях, заказчики запросили большего. Настольные и основанные на локальных сетях (Local Area Network, LAN ) системы управления данными также стали использоваться и в весьма малых бизнесах. Сегодня практически немыслимо проектировать информационную систему предприятия для монолитной модели на мэйнфрейме с текстовым терминалом.

Масштабируемость оценивается в двух размерностях: горизонтальной и вертикальной. Горизонтальная масштабируемость - способность системы добавлять дополнительных пользователей без воздействия на возможности программного обеспечения или используемые ресурсы. Вертикальная масштабируемость связана с тем, что будет сделано для переноса системы на более простые или более сложные платформы и конфигурации аппаратных средств в ответ на изменение требований нагрузки и доступа. Диапазон меняется от нижнего уровня - например, сделать систему доступной для пользователей мобильных устройств - до верхнего уровня, который не имеет концептуальных ограничений.

 

Функциональная совместимость

Архитектура клиент-сервер для систем баз данных развивалась как ответ на уязвимость, низкий уровень нагрузки и ограничения по скорости модели базы данных совместного доступа к файлам в компьютерных сетях при потребности увеличения количества пользователей. Острая необходимость в этом совпала с параллельной разработкой языка SQL. Оба направления отчасти были стратегиями нейтрализации зависимости аппаратного обеспечения мэйнфреймов и программного обеспечения, которая преобладала в 1980-x годах. Настоящая архитектура баз данных клиент- сервер является неоднородной и функционально совместимой (интероперабельной) - она не ограничивается одной платформой аппаратных средств или одной операционной системой. Эта модель позволяет клиентам и серверам независимо размещаться в узлах сети на аппаратных средствах и в операционных системах, соответствующих их функциям. Приложения клиентов могут одновременно связываться с множеством серверов, выполняющихся в различных операционных системах.

 

Защита данных

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

 

Распределение функций

Модель клиент-сервер позволяет отдельным фрагментам работы системы быть эффективно распределенными между компонентами аппаратуры и программного обеспечения. Сервер базы данных заботится о хранении, управлении и поиске данных, а через хранимые процедуры, триггеры и другие вызываемые процессы он обеспечивает большое количество возможностей обработки данных системы. Процесс клиента является "острием" приложений, транслируя их запросы в структуры коммуникации, которые формируют протоколы для доступа к базам данных и к данным.

Приложения являются динамическим уровнем в этой модели. Они обеспечивают потенциально бесконечное множество интерфейсов, через которые люди, машины и внешние программные процессы взаимодействуют с клиентским процессом. В этой части клиентский модуль представляется приложениям через понятный, предпочтительно стандартизованный, независимый от языка программирования интерфейс прикладного программирования (Application Programming Interface, API).

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

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

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

 

Двухуровневая модель

Рис. 5.1 иллюстрирует классическую двухуровневую модель клиент-сервер. Промежуточный уровень, который может присутствовать или отсутствовать, представляет собой драйвер, такой как ODBC, JDBC, PHP, или компонент доступа к данным, который интегрирован с программным кодом приложения. Возможны и другие уровни на клиентской стороне. Приложения также могут быть написаны с использованием прямого доступа к API без промежуточного уровня.

Рис. 5.1. Двухуровневая модель клиент-сервер

 

Многоуровневая модель

Увеличение возможностей масштабирования и требования большей функциональной совместимости приводят к модели с большим количеством уровней, как показано на рис. 5.2. Клиентский интерфейс перемещается в центр модели; он объединяется с одним или более уровнями сервера приложений. В этом центральном комплексе будут расположены средства промежуточного уровня и сетевые модули. Уровень приложения становится некоторым видом суперклиента базы данных - иногда обслуживая множество серверов баз данных - и сам становится Proxy-сервером (сервером-посредником) для запросов к базам данных от приложений. Он может быть размещен на том же аппаратном оборудовании, что и сервер базы данных, но также может выполняться и на своем оборудовании.

Рис. 5.2. Многоуровневая модель клиент-сервер

 

Стандартизация

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

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

 

Абстракция хранимых данных

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

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

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

* Большие составные символьные ключи, составленные из столбцов реальных данных.

* Недостатки нормализации, приводящие к большому количеству записей содержащих много повторяющихся групп и редко требуемой информации.

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

Это не говорит о том, что старые настольные системы не были хорошими. Они вполне успешно выполняли свои задачи. Технология клиент-сервер просто очень сильно отличается от "настольных" баз данных. Эта технология меняет масштаб управления информацией с "обратиться к файлу такому-то и выбрать" на "хранить, управлять и манипулировать". Она переносит приложение клиента с роли настольной системы, как главного действующего лица, на роль переносчика сообщений. Эффективные клиентские интерфейсы являются легкими и очень элегантными в том, как они выполняют желания пользователя и выдают ему нужную информацию.

Отбрасывание идеологии электронных таблиц

Общей характеристикой приложений настольных баз данных является то, что они предоставляют интерфейс в виде таблицы: данные представляются в виде строк и столбцов с полосами прокрутки и другими элементами навигации для просмотра с первой строки до последней. Часто эти таблицы представляют собой визуальную структуру, которая в точности воспроизводит структуру метаданных исходных таблиц. Обычная ловушка- импортировать такие таблицы в систему клиент-сервер и считать, что задача миграции выполнена.

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

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

Таблицы для вывода

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

Пользовательский интерфейс

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

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

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

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

Модель хранения реляционных данных

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

Первичный ключ

В процессе логического анализа первичный ключ (primary key) устанавливается для всех сгруппированных данных. Логический первичный ключ помогает определить, какой элемент (или группа элементов) способен однозначно идентифицировать группу связанных данных. Физическое проектирование таблиц будет отображать логическую группировку и уникальность характеристик модели данных, хотя структуры таблиц и ключевые столбцы, созданные в черновом варианте, не часто в точности соответствуют модели. Например, в таблице Employee уникальный ключ состоит из полей имени и фамилии и др. Поскольку составной уникальный ключ в модели данных включает элементы большого размера, которые могут приводить человека к ошибкам, в таблицу должен быть добавлен столбец в качестве суррогатного первичного ключа.

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

Отношения

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

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

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

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

 

"Руки прочь" от доступа к данным

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

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

 

Множество пользователей и параллельность

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

Транзакции

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

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

Транзакции завершаются, когда приложение обращается к клиенту, чтобы он запросил сервер подтвердить (commit) всю работу, выполненную с момента старта транзакции (даже если ничего не выполнялось, кроме чтения), или в случае ошибок отменить всю работу (rollback). Правило атомарности гласит: "Если одно из изменений оканчивается неудачей и требует отмены по причине невозможности подтверждения, то все ожидающие завершения изменения в этой транзакции также должны быть отменены". Отмена включает любые изменения, которые были сделаны триггерами и хранимыми процедурами в процессе выполнения этой транзакции.

! ! !

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

. ! .

Транзакции настолько важны в системах клиент-сервер, что в настоящем руководстве им посвящены три главы. 25, 26 и 27.

Пора дальше

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

 

Двухуровневая архитектура клиент-сервер

На рис. 6.1 изображена гибкая система, где множество серверов Firebird выполняются на платформах с различными операционными и файловыми системами. Здесь присутствует смесь рабочих станций, на которых выполняются удаленные клиенты, каждый на своей платформе. Здесь же существуют шлюзы для других сетей. Сервер Windows обслуживает повседневную обработку деловых данных и располагает большим объемом дискового пространства. Для клиентов Windows возможно общение с сервером Windows с использованием протокола Named Pipes - обычно называемым NetBEUI, - хотя такой протокол должен быть заменен по возможности на TCP/IP.

Сервер Linux может обслуживать системы сетевой защиты, шлюзы, вспомогательные базы данных и другие системы клиент-сервер, включая электронную почту, Интернет и сервисы файлов, такие как NFS и Samba.

Рис. 6.1. Двухуровневая топология клиент-сервер в Firebird

Неоднородная сеть обслуживания баз данных является общей средой для Firebird. В небольших сетях с единственным сервером, где местный администратор может не входить в штат сотрудников, существует тенденция переносить сервер базы данных с одного узкоспециализированного хоста, работающего под Windows, на дешевую машину Linux с хорошей оперативной памятью и быстрым доступом к данным. Поддержка недорогая, что делает возможным передачу большинства административных функций другим организациям. Системы, подобные этой, могут расти без каких-либо сложностей.

 

Однопользовательская модель

Все серверы Firebird могут работать с локальными клиентами. Протоколы соединения и режимы меняются в соответствии с выбранной вами моделью сервера. Однопользовательские инсталляции делятся на две категории:

* Независимый сервер. В этой модели сервер инсталлируется и запускается на машине. Локальные соединения осуществляются с использованием протоколов в стиле сетевых, используя обычные клиентские библиотеки.

* Встраиваемый сервер. Никакой сервер не инсталлируется. Сервер находится в DLL, похожей на клиентскую библиотеку, и загружается приложением. Приложение вместе с DLL сервера выполняется как единственный процесс на одно соединение. Когда приложение завершается, то фактически завершается и работа сервера.

Клиент-сервер

В автономной модели клиент-сервер локализованное клиентское подключение к выполняющемуся серверу выполняется с использованием локального протокола. Сервер может прослушивать подключения от удаленных клиентов во время подключенного локального клиента. Рис. 6.2 иллюстрирует этот режим.

Рис. 6.2. Автономные серверы

Первый пример показывает модель локального подключения. В Firebird 1.5 и ниже подсистема IPSERVER моделирует сетевое подключение в том же блоке пространства общения между процессами. В версии 1.5 и выше вместо локального протокола используется более быстрая и надежная подсистема XNET. Функциональный эквивалент локального подключения используется Классическим сервером в POSIX.

В двух других примерах в Windows, Linux или на любой другой поддерживаемой платформе Суперсервер использует локальную "заглушку" (loopback) протокола TCP/IP. Это обычное подключение TCP/IP к специальному IP-адресу 127.0.0.1, который большинство подсистем TCP/IP инсталлирует по умолчанию для локального хоста (localhost). В Linux Классический сервер версии 1.5 может применяться в этом режиме при использовании клиентской библиотеки libfbclient.so.

Встраиваемый сервер

Встраиваемые серверы поддерживаются на платформах Windows и Linux/UNIX, хотя реализация моделей различна. Под Windows библиотека встроенного сервера, который выполняется как единый процесс, называется fbembed.dll. В Linux/UNIX это стандартный режим локального подключения для Классического сервера. Библиотека libfbclient.so запускает один процесс Классического сервера (fb_inet_server или ib inet server) и напрямую соединяется с базой данных. Процесс не является исключительным - удаленные клиенты могут одновременно соединяться с базой данных, используя fbclient.so, другую библиотеку libfbclient.so или fbembed.dll.

Более подробно встроенные серверы обсуждаются в главе 7.

 

Серверы Firebird в среде DTP

Детальное обсуждение среды распределенной обработки транзакций (Distributed Transaction Processing, DTP) не является целью данной книги. Достаточно сказать, что Суперсервер или Классический сервер Firebird хорошо подходят к различным сценариям DTP.

Open Group, определившая стандарт x/Open для DTP, предоставила три программных компонента для системы DTP. Спецификация XA определяет интерфейс между менеджером транзакций и менеджером ресурсов (Resource Manager, RM). Система имеет один RM-модуль для каждого сервера; требуется каждый RM для регистрации менеджера транзакций.

На рис. 6.3 показано, как сервер Firebird может быть представлен в XA-совместимой среде DTP. Модуль сервера приложения базы данных представляет собой мост между приложениями пользователя высокого уровня и RM, инкапсулирующим соединение XA. RM выполняет роль клиента связи с сервером базы данных для доступа к данным.

Инкапсуляция соединения XA дает возможность разработчику приложения создавать и выполнять операторы SQL в RM. Разграничение транзакций, которое требуется средствам двухфазного подтверждения для всех серверов, регулируется глобальным

монитором обработки транзакций (Transaction Processing Monitor, TPM). Транзакции с несколькими базами данных, находящиеся под управлением менеджера транзакций, выполняются с помощью процесса двухфазного подтверждения. В первой фазе транзакции подготавливаются для подтверждения; во второй фазе транзакции либо полностью подтверждаются, либо откатываются. TPM проинформирует вызывающий модуль, если транзакция не будет по разным причинам завершена.

Рис. 6.3. Firebird в распределенной среде выполнения транзакций

TPM согласовывает распределенные транзакции в системах множества баз данных, так что одна транзакция может использовать один или более процессов и изменять одну или более баз данных. Монитор хранит информацию обо всех доступных и включенных в транзакции RM.

Среда поддерживает множество баз данных для одного сервера и множество серверов, которые не обязательно все должны быть серверами Firebird. Версия 1.5 и выше Firebird не поддерживает использование одной базы данных несколькими серверами или обслуживание базы данных, находящейся вне компьютера, где установлен сервер Firebird.

Основы сервера транзакций

Сервер транзакций Microsoft (Microsoft Transaction Server, MTS) с COM+ является одним из таких сценариев. MTS/COM+ обеспечивает среду для объединенных в пул процессов, которая осуществляет использование и управление компонентами бизнес- логики, включая контроль системы, безопасность и мониторинг выполнения. Одной из наиболее значимых возможностей является декларативное управление транзакциями. Транзакции, инициированные в MTS/COM+, управляются координатором распределенных транзакций (Microsoft Distributed Transaction Coordinator, DTC), менеджером ресурсов XA. Родной интерфейс Firebird требует провайдера ODBC или OLE DB, который поддерживает как двухфазное подтверждение транзакций Firebird, так и контекст вызова MTS/COM+.

 

Терминальные серверы

Firebird успешно используется в средах MTS и IBM Citrix. Во всех случаях используется протокол TCP/IP для соединений по сетевым IP-адресам.

! ! !

ВНИМАНИЕ! Весьма нежелательно инсталлировать на одном и том же узле терминальный сервер и сервер базы данных. Тем не менее в ситуациях, когда сервер приложения выполняется на том же узле, что и сервер базы данных, соединение должно осуществляться с использованием IP-адреса этого узла или по имени localhost.

. ! .

 

Хранимые процедуры

Язык процедур Firebird (PSQL) реализует расширения его языка SQL, предоставляя логику условий, структуры управления потоками выполнения, обработку исключений (как встроенных, так и определенных пользователем), локальные переменные, механизм событий и возможность получать входные аргументы почти всех типов данных, существующих в Firebird. Он реализует мощную структуру управления потоком для обработки курсоров, что позволяет помещать наборы данных напрямую в память клиента без необходимости создания временных таблиц. Такие процедуры вызываются клиентом оператором SELECT; разработчикам они известны как селективные процедуры.

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

 

Триггеры

Триггеры являются особыми процедурами, созданными для определенных таблиц с целью автоматического выполнения в процессе завершения добавлений, изменений или удалений на сервере. Любая таблица может иметь произвольное количество триггеров, которые будут выполняться до или после добавлений, изменений или удалений. Порядок выполнения определяется параметром позиции в объявлении триггера. Триггеры имеют некоторые расширения языка, недоступные для хранимых процедур или в динамическом SQL. Например, контекстные переменные OLD и NEW, при использовании которых в качестве префикса к имени столбца можно получить доступ к существующему (старому, old) и требуемому (новому, new) значению столбца. Триггеры могут вызывать хранимые процедуры, но не другие триггеры.

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

 

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

Для сохранения своего малого объема Firebird поставляется с весьма скромным арсеналом встроенных (родных) функций трансформации данных. Пользователи могут писать свои собственные функции на известном им языке, таком как C/C++, Pascal или Object Pascal, для получения аргументов и возвращения единственного результата. Как только внешняя функция (UDF) будет определена в базе данных, она тут же станет доступной как допустимая функция SQL для приложений, хранимых процедур и триггеров.

Firebird поставляет две готовые к использованию библиотеки UDF: ib udf, доступную как для Windows, так и для Linux, и fbudf, доступную в настоящий момент для Windows и Linux в версии 1.5 и доступную только для Windows в версии 1.0.x. Firebird отыскивает UDF в библиотеках, находящихся в каталоге /udf каталога инсталляции или в других каталогах, указанных в параметре udfAccess (версия 1.5) или externai_function_directory (версия 1.0.x) в файле конфигурации Firebird.

 

Динамические приложения клиент-сервер

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

Клиентские приложения используют динамический SQL (DSQL) для создания запросов во время выполнения. Клиент Firebird объявляет API как библиотеку функций, которые передают сложные структуры записей, формируют протокол на уровне данных для связи между приложением и сервером.

! ! !

ПРИМЕЧАНИЕ. Программирование с использованием API - большая тема. Ее описание выходит за рамки данной книги. Но поскольку динамический SQL сам не предоставляет некоторых функций, здесь описываются отдельные функции API, чтобы помочь вам понять, как драйверы и интерфейсные компоненты делают их доступными в соответствующих средах проектирования.

. ! .

 

Ядро API Firebird

Программирование с использованием API необходимо при написании драйверов для создания сценариев в таких языках, как PHP и Python, и при разработке объектно- ориентированных классов доступа к данным для объектно-ориентированных языков типа Java, C++ и Object Pascal. Приложения также могут быть написаны с прямыми вызовами функций API без посредничества драйверов. Эти приложения "прямого API" могут быть мощными, гибкими, быстро-выполняемыми, небольшого размера и с прекрасным управлением распределением памяти.

Функциональные категории ядра API

Функции API (все их имена начинаются с isc) делятся на восемь категорий.

* Соединение с базой данных и отсоединение от базы данных - например,

isc_attach_database().

* Запуск, подготовка, подтверждение и откат транзакций - например,

isc_start_transaction().

* Вызовы выполнения операторов - например, isc_dsql_describe().

* Вызовы BLOB - например, isc_biob_info().

* Вызовы для массивов - например, isc_array_get_slice().

* Безопасность базы данных - например, isc_attach_database().

* Информационные вызовы - например, isc_database_info().

* Преобразования даты и целых - например, isc encode date().

Более подробную информацию по программированию прямого API см. в "API Guide" документации по InterBase 6, опубликованной фирмой Borland.

Интерфейсы приложений при использовании API

Приложения, которые используют общие интерфейсы типа ODBC или JDBC, основаны на операторах DSQL, располагающихся ниже пользовательских интерфейсов, таких как построители запросов и др.

В связи с увеличением числа инструментов быстрой разработки приложений (Rapid Application Development, RAD) за последнее десятилетие инкапсуляция функций API в "обертку" классов и компонентов разработчикам под Firebird предоставлены разнообразные привлекательные средства создания приложений.

Объектно-ориентированные классы

Объектно-ориентированные классы и компоненты доступа к данным инкапсулируют вызовы функций и структуры данных API. Все они имеют свойства и методы, которые анализируют и выполняют синтаксический разбор запрашиваемых операторов, а также управляют возвращаемыми результатами. Богатые классы включают методы и свойства, которые поддерживают специальные возможности Firebird, такие как распределенные транзакции, обработка массивов, параметризованные операторы. Большинство наборов компонентов реализует, по меньшей мере, один класс компонента- контейнера для буферизации одной или более строк, возвращаемых клиенту в виде результирующего набора. Некоторые реализуют продвинутые техники, такие как прокручивание курсоров, "живые данные", обратные вызовы и управление транзакциями.

Драйвер JayBird Туре 4 ("родной") JDBC поставляет интерфейс, предназначенный для независимой от платформы разработки на Java с использованием Firebird. Некоторые наборы компонентов устанавливаются в качестве интерфейса разработчиками, использующими Delphi, Kylix и C++ Builder для написания клиентов баз данных Firebird. Двумя лучшими наборами компонентов являются IB Objects и FIBPlus. Доступны некоторые другие наборы компонентов, осуществляющие минимальную поддержку возможностей Firebird. Более подробную информацию см. в приложении 3.

 

Встроенные приложения Firebird

Firebird предоставляет две различные встраиваемые модели: приложения встроенного SQL (Embedded SQL) и встраиваемые серверы.

Приложения встроенного SQL

В этой модели программа приложения включает в себя интерфейс клиент-сервер и уровень приложения конечного пользователя- все в одном исполняемом модуле. Операторы SQL находятся непосредственно в исходном коде программы, написанной на С, C++ или другом языке программирования. Затем исходный код приложения обрабатывается препроцессором gpre, который отыскивает блоки кода, содержащие операторы SQL. Он подставляет макровызовы функций, которые функционально эквивалентны функциям динамической библиотеки API. Когда работа препроцессора завершается, все выполненные преобразования операторов SQL компилируются вместе с приложением. Такие операторы перед компилированием называются статическим SQL.

В таком стиле приложений доступно специальное расширенное подмножество исходных команд, похожих на SQL. Встроенный SQL (Embedded SQL, ESQL) предоставляет программисту простой язык высокого уровня в виде "черного ящика", в то время как gpre выполняет всю работу по преобразованию сложных языковых структур в эквивалентные вызовы API. Эти статические операторы дают незначительное увеличение скорости по сравнению с динамическим SQL, поскольку не требуют дополнительных затрат на синтаксический разбор и интерпретацию операторов SQL во время выполнения.

Язык и техники ESQL подробно не обсуждаются в данной книге. Документ "InterBase Embedded SQL Guide" ("Руководство по встроенному SQL InterBase", EmbedSQL.pdf), доступный в Borland, содержит описания, необходимые для разработки встроенных приложений Firebird.

Приложения встраиваемого сервера

В модели встраиваемого сервера не существует преобразований операторов SQL. Клиент и сервер объединяются в одну компактную динамическую библиотеку для получения независимого приложения. Приложение загружает библиотеку во время запуска точно так же, как обычное приложение Firebird будет загружать клиентскую библиотеку, функции API вызываются во время выполнения. При этом нет необходимости инсталлировать внешний сервер, потому что такой клиент внутренне связывается со своим собственным экземпляром серверного процесса Firebird. Когда приложение завершается, оно выгружает встраиваемый сервер, так что не сохраняется никакого серверного процесса.

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

Встраиваемый сервер под Windows

Библиотека встраиваемого сервера fbembed.dll, включенная в инсталлятор Firebird 1.5 для Windows, имеет архитектуру, аналогичную Firebird SuperServer. Если вы планируете инсталлировать и использовать fbembed.dll, обратите внимание на специальные инструкции по размещению библиотек и исполняемых программ Firebird. Измененные файлы README и другие заметки обычно размещаются в каталоге /doc серверной инсталляции.

Вы можете инсталлировать встраиваемый сервер и выполнять приложения встраиваемого сервера на машине Windows, на которой также находится Суперсервер или Классический сервер Firebird, хотя удаленные клиенты не могут соединяться с базой данных, с которой работает приложение встраиваемого сервера. В релизе 1.5, где не лучший протокол IPSERVER все еще используется для связи клиента и сервера, возможно использование библиотеки встраиваемого сервера в качестве клиента других серверов. В более поздних версиях, где протокол IPSERRVER заменен на XNET, это невозможно.

Firebird 1.0.x не содержит варианта встраиваемого сервера для Windows.

Встраиваемый сервер под Linux/UNIX

Встраиваемый сервер является "родным" режимом доступа локального клиента к Классическому серверу Firebird в Linux/UNIX, включая и версию Firebird 1.0.x. Библиотека встраиваемого сервера для локального доступа- libfbembed.so для Firebird 1.5 и выше и libgds.so для Firebird 1.0.x.

Как и версия IPSERVER для Windows, встроенный клиент в Linux/UNIX может так же работать, как удаленный клиент с другим Классическим сервером Firebird. При этом клиент не будет потокобезопасным (thread-safe). Для многопоточных приложений необходимо использовать обычный клиент libfbclient.so. В Firebird 1.0.x удаленный клиент поставляется в комплекте Суперсервер для Linux и двусмысленно назван libgds.so, как и встроенный клиент Классического сервера.

! ! !

ВНИМАНИЕ! Клиент Суперсервера для Linux является клиентом, поддерживающим потоки для многопоточных приложений, однако он не поддерживает выполнения нескольких потоков в одном и том же соединении с базой данных. Отдельные экземпляры соединения должны быть созданы для каждого потока.

. ! .

 

Сервисы API

Открытый код InterBase 6 - на основе которого был разработан Firebird - обрабатывает в первую очередь обращения к функциям интерфейса API для некоторых действий сервера, таких как копирование/восстановление, получение статистических данных и управление пользователями. Многие из этих обращений предоставляют программный интерфейс для инструментов командной строки. Небольшое количество функций сервера низкого уровня включает также некоторые функции, перекрывающие функции ядра API.

Некоторые организации разработали и распространяют сервисные компоненты, инкапсулирующие вызовы функций сервисов API из среды разработки Delphi, Kylix и C++ Builder. Большинство из них доступны для свободной загрузки с сайтов авторов или сообщества Firebird. Более подробную информацию см. в приложении 3.

В Firebird 1.0.x сервисы API и сервисные компоненты работают только с серверами типа Суперсервер. В Firebird 1.5 Classic сервисы API полностью поддерживаются только начиная с версии 1.5.2. В версиях 1.5.0 и 1.5.1 Classic поддерживаются только некоторые функции - такие как вызов модулей gbak (копирование/восстановление) и gfix (обслуживание базы данных).

 

Инсталляция клиента Linux/UNIX

Операционные системы POSIX являются весьма своеобразными. Присутствующие в этом разделе советы должны быть полезными в качестве руководства по инсталляции клиентов для большинства разновидностей Linux и UNIX, однако это область, где сомнения являются несомненными!

1. Подключитесь к клиентской машине как пользователь root и найдите клиентскую библиотеку в инсталляции сервера:

• в Firebird 1,0.x ее имя libgds.so.0, размещение по умолчанию /usr/lib;

• в Firebird 1.5 двоичные файлы удаленного клиента libfbclient.so. 1.5.0 инсталлированы по умолчанию в /opt/firebird/lib.

! ! !

ВНИМАНИЕ! В поставке Классического сервера есть клиентская библиотека с именем libfbembed.so.1.5, которая может быть использована для встроенных приложений. Не используйте ее для удаленных клиентов.

. ! .

2. Скопируйте библиотеку в /usr/lib на клиенте и создайте символическую ссылку на нее, используя следующие команды:

• для версии 1.0x:

ln -s /usr/lib/libgds.so.0 /usr/lib/libgds.so

• для версии 1.5 (две ссылки):

In -s /usr/lib/libfbclient.so.1.5 /usr/lib/libfbclient.so.0 In -s /usr/lib/libfbclient.so.0 /usr/lib/libfbclient.so

3. Создайте каталог/opt/firebird (/opt/interbase для версии 1.0.x) на клиенте для файла сообщений и скопируйте этот файл из корневого каталога Firebird на сервере:

• для версии 1,0.x скопируйте interbase.msg в /opt/interbase/;

• для версии 1.5 и выше скопируйте firebird.msg в /opt/firebird/.

4. В системном профайле оболочки по умолчанию или вызовом setenvo создайте переменную окружения, которая позволит найти утилиту для сообщений API:

• для версии 1.0.x создайте переменную INTERBASE и свяжите ее с /opt/interbase/;

• для версии 1.5 и выше создайте переменную FIREBIRD и свяжите ее с /opt/firebird/.

 

Инсталляция клиента Windows

Firebird 1.0.x

В Windows клиентская библиотека всегда по умолчанию инсталлировалась в системный каталог. По умолчанию это C:\WINNT\system32 для Windows NT и 2000, C:\Windows\system32 для Windows XP и Server 2000 и C:\Windows\ или C:\Windows\system для Windows 9х и ME. В Firebird 1.0.x в качестве временной меры сохраняются старые имена и местоположение.

Использование инсталлятора Firebird

Самый простой способ инсталлировать клиента Firebird 1.0.x- это скопировать инсталлятор Firebird на компакт-диск или флэш-память и запустить его на клиентской машине, выбрав установку только клиента в диалоговом окне инсталлятора. Вы можете инсталлировать клиента с инструментами командной строки или без них. Большинству клиентов не нужны эти инструменты; не рекомендуется устанавливать их на клиентских рабочих станциях, где не требуется доступ администратора к серверу.

Инсталлятор создаст корневой каталог по умолчанию в C:\Program Files\Firebird; это размещение вы можете изменить в соответствующем диалоге инсталлятора. Сюда он запишет файл сообщений interbase.msg и, если были выбраны для инсталляции инструменты командной строки, создаст каталог \bin, куда поместит эти инструменты.

Он запишет в системный каталог gds32.dll и, если библиотека времени выполнения Microsoft С старая или вовсе отсутствует, запишет туда же msvcrt.dll.

Под конец он запустит программу instreg.exe для инсталляции ключей в системном реестре. Если вы выбрали каталог инсталляции по умолчанию, ключ будет

HKLM\Software\Borland\InterBase. Если какие-нибудь выполняющиеся программы были перезаписаны в процессе инсталляции, вам будет предложено перезагрузить машину.

Инсталляция клиента вручную

Инсталляция клиента вручную требует выполнения всех предыдущих шагов. Вам нужно скопировать файлы gds32.dll, interbase.msg и instreg.exe на дискету или флэш- память. Также скопируйте из системного каталога msvcrt.dll, если на ваших клиентах она не установлена.

Создав корневой каталог Firebird, скопируйте туда interbase.msg. Затем запустите с диска instreg.exe, набрав в окне командной строки:

А:\> instreg.exe 'C:\Program Files\Firebird'

Если вы создали корневой каталог Firebird где-нибудь в другом месте, укажите этот путь как аргумент корневого каталога.

Скопируйте gds32.dll и, если нужно msvcrt.dll, в системный каталог.

! ! !

ПРИМЕЧАНИЕ, msvcrt.dll является библиотекой времени выполнения для многих программ, скомпилированных компилятором Windows С. gds32.dll - это имя клиентской библиотеки для серверов InterBase, а также Firebird 1.0.x. В случае если вы не можете скопировать одну из библиотек или обе по причине их использования другой программой, необходимо остановить ту программу и повторить процесс копирования. Если все еще невозможно переписать библиотеки по причине того, что аварийно завершившаяся программа не выгрузила их, перезагрузите компьютер в безопасном режиме и выполните этот шаг.

. ! .

Firebird 1.5 и выше

Firebird версии 1.5 и последующие клиентские инсталляции поставляются с большим количеством режимов с целью избежать "ужаса DLL" в системном каталоге Windows.

До тех пор, пока сторонние инструменты, драйверы и компоненты не научатся понимать изменения в клиентской части Firebird 1.5, Firebird 1.5 будет поддерживать собственные "ужасы DLL". Инсталляция клиента по умолчанию почти наверняка будет несовместимой с программным обеспечением, созданным с использованием таких RAD-продуктов Borland, как Delphi или C++ Builder.

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

Использование инсталлятора Firebird

Хотя существуют другие варианты, рекомендуемый способ инсталляции клиента - использование инсталляционной программы Firebird 1.5.

Если вы используете инсталлятор, то первый выбор, который вы должны сделать - размещение корневого каталога для инсталляции клиента (рис. 7.1). Рекомендуется выбрать значение по умолчанию (C:\Program Files\Firebird\Firebird_1_5), тогда будет проще в будущем выполнять обновления. Тем не менее при необходимости вы можете указать размещение на свой вкус.

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

Рис. 7.1. Выбор размещения корневого каталога инсталляции

Затем вы должны принять решение о выборе режима инсталляции - нужно ли устанавливать клиента с инструментами командной строки или без них, как показано на рис. 7.2.

Большинству клиентов эти инструменты не нужны; не рекомендуется инсталлировать их на клиентской рабочей станции, если нет необходимости администратору получать доступ к серверу. Для минимальной инсталляции выберите вариант Minimum client install - no server, no tools (Минимальная установка клиента - без сервера, без инструментов) и щелкните по кнопке Next.

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

Предыдущие инсталляторы устанавливали старую клиентскую библиотеку gds32.dll в системный каталог вместе с библиотекой времени выполнения для языка С msvcrt.dll, если она отсутствовала.

Рис. 7.2. Выбор инсталляции только клиента

Рис. 7.3. Выбор "версии" и размещения для клиента

В версии 1.5 инсталлятор устанавливает все DLL - новую клиентскую библиотеку fbclient.dll и (если требуется) библиотеку времени выполнения для С и C++ msvcp60.dll - в каталог \bin в корневом каталоге Firebird.

* (A) Reallocation of the client library (Изменение размещения клиентской библиотеки). Если вам нужна совместимость с программным обеспечением, которое ожидает найти клиентскую библиотеку в системном каталоге, отметьте эту позицию.

* (В) Name of the client library (Имя клиентской библиотеки). Если вашему программному обеспечению или компонентам нужна клиентская библиотека с именем gds32.dll, отметьте эту позицию. Инсталлятор сгенерирует специальную копию fbclient.dll с именем gds32.dll и установит строку внутренней версии для совместимости с драйверами InterBase фирмы Borland и компонентами. Размещение этого файла зависит от состояния первой позиции (А).

Щелкните по кнопке Next для инсталляции.

Инсталляция клиента вручную

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

* %system%\gds32.dll (C:\WINNT\system32 или C:\Windows)

* firebird.msg

* bin\fbclient.dll

* bin\msvcrt.dll (при необходимости)

* bin\msvcp60.dll (при необходимости)

* bin\instreg.exe

* bin\instclient.exe

* bin\fbclient.local

* bin\msvcrt. local

* bin\msvcp60. local

На клиенте выполните следующие шаги:

1. Создайте корневой каталог Firebird и скопируйте туда firebird.msg.

2. В этом каталоге создайте каталог bin.

3. Скопируйте файлы из каталога \bin дискеты в этот новый каталог \bin.

4. Запустите программу instreg.exe из нового каталога \bin в окне командной строки. Очень важно запустить эту программу из каталога \bin корневого каталога Firebird, где расположена программа instreg.exe. Например, если корневой каталог Firebird находится в C:\Firebird_Client, введите:

С:\Firebird_Client\bin> instreg.exe install

5. Если у вас есть приложение, которому нужна клиентская библиотека с именем gds32.dll, то вам необходимо выполнить программу instclient.exe. Инструкции в следующем разделе.

Выполнение instclient.exe

Программа instclient.exe может быть выполнена, когда вам требуется клиентская версия, к которой осуществляют доступ существующие программы, драйверы или компоненты, которые ожидают, что имя клиентской библиотеки gds32.dll, или что она располагается по системному пути Windows. Это программа командной строки, которая находится в каталоге \bin в корневом каталоге вашей инсталляции сервера

Firebird. При необходимости скопируйте данный файл в соответствующий каталог на клиентскую машину.

Инсталляция клиента в системный каталог

Откройте окно командной строки и перейдите в каталог \bin. Синтаксис инсталляции клиента:

instclient.exe {i[nstall]} [-f[orce]] {fbclient | gds32}

Требуются параметры i (или install) и один из параметров fbclient или gds32.

Если программа найдет, что файл, который вы пытаетесь инсталлировать (fbclient.dll или gds32.dll), уже находится в системном каталоге, она не будет выполняться. Чтобы программа записывала файл, даже если найдет его копию, используйте переключатель -f (или -force).

Ваша операционная система может потребовать перезагрузку машины для завершения инсталляции.

! ! !

ВНИМАНИЕ! Если вы выбираете форсированную инсталляцию, вы рискуете разрушить клиента, который был инсталлирован для использования с другим программным обеспечением, которое было создано для соединения с сервером Firebird 1.0 или InterBase.

. ! .

Запрос к инсталлированному клиенту

Программа instclient.exe может быть использована для получения информации о выполняющихся на этой машине клиентах Firebird 1.5. Синтаксис запроса о клиентах:

instclient.exe {q[uery] fbclient | gds32}

На рис. 7.4 показана возвращаемая информация.

Рис. 7.4. Запрос с помощью instclient.exe

Использование instclient.exe для деинсталляции клиента версии 1.5

Для удаления клиента Firebird 1.5, инсталлированного в системный каталог, используйте следующий синтаксис:

instclient.exe {r[emove] fbclient | gds32}

 

Список имен и размещение клиентской библиотеки

В табл. 7.1 представлены имена клиентской библиотеки и размещение по умолчанию на клиентах Firebird.

Таблица 7.1. Имена и размещение по умолчанию клиентов Firebird

Пора дальше

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

 

Временные значения

CURRENT_CONNECTION и CURRENT_TRANSACTION не имеют смысла вне текущего соединения и контекста транзакции соответственно. Сервер Firebird сохранит самые последние значения этих идентификаторов в заголовочной странице базы данных. После восстановления базы данных из резервной копии эти значения будут заново установлены в ноль.

CURRENT_TIMESTAMP записывает время сервера на момент старта операции. Для всех записей, вставляемых или обновляемых одним оператором, значение этой переменной будет одним и тем же.

Хотя CURRENT_TIME хранится на сервере как время после полуночи, ее тип TIME, а не интервал времени. Для получения интервала времени используйте TIMESTAMP при старте и завершении и вычтите время старта из времени завершения. Результатом будет интервал времени в днях.

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

 

Примеры использования

Следующий оператор возвращает время сервера в момент, когда сервер обслуживает запрос клиента Firebird:

SELECT CURRENT_TIME AS TIME_FINISHED FROM RDB$DATABASE;

В следующем операторе добавления идентификатор текущей транзакции, текущие серверные дата и время, а также имя пользователя системы будут записаны в таблицу:

INSERT INTO TRANSACTIONLOG(TRANS_ID, USERNAME, DATESTAMP) VALUES (

CURRENT_TRANSACTION,

CURRENT_USER,

CURRENT_TIMESTAMP) ;

 

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

В диалектах базы данных 1 и 3 литерал даты должен быть преобразован в тип данных TIMESTAMP:

SELECT CAST ('NOW' AS TIMESTAMP) AS TIME_FINISHED FROM RDB$DATABASE;

Следующий оператор UPDATE устанавливает значение столбца даты в серверную дату плюс один день в диалекте 1:

UPDATE TABLE_A

SET UPDATE_DATE = 'TOMORROW'

WHERE KEY_ID = 144;

Вот та же самая операция в диалекте 3 с преобразованием типа:

UPDATE TABLE_A

SET UPDATE_DATE = CAST('TOMORROW' AS DATE)

WHERE KEY_ID = 144;

 

Неявное преобразование типов

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

* В диалекте 1 для некоторых выражений Firebird выполняет автоматическое преобразование данных в эквивалентные типы данных (неявное преобразование типов). Здесь также может быть использована функция CAST(), хотя в большинстве случаев она не нужна.

* В диалекте 3 в условиях поиска требуется функция CAST() для явной трансляции одного типа данных в другой для операций сравнения.

Например, сравнение столбца типа DATE или TIMESTAMP с '12/31/2003' в диалекте 1 приводит к неявному преобразованию строкового литерала '12/31/2003' в тип данных DATE.

SELECT * FROM TABLE_A

WHERE START_DATE < '12/31/2003';

В диалекте 3 требуется явное преобразование:

SELECT * FROM TABLE_A

WHERE START_DATE < CAST ('12/31/2003' AS DATE);

В выражениях, где смешиваются целые данные и числовые строки, в диалекте 1 строки неявно преобразуются в целое, если это возможно. В следующей операции:

3 + '1'

диалект 1 автоматически преобразует символ "1" в SMALLINT, в то время как диалект 3 вернет ошибку. Он требует явного преобразования типов:

3 + CAST('1' AS SMALLINT)

Оба диалекта вернут ошибку в следующем операторе, потому что Firebird не может преобразовать символ "а" в целое:

3 + 'а'

 

Явное преобразование типов: CAST()

В тех случаях, когда Firebird не может выполнить неявное преобразование типов, вы должны выполнить явное преобразование типов посредством функции CAST(). Используйте CAST() для преобразования одного типа данных в другой в операторе SELECT обычно в предложении WHERE для сравнения различных типов данных. Синтаксис функции:

CAST (значение | NOLL AS тип данных)

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

 

Изменение типа данных столбца

Используйте предложение ALTER COLUMN В операторе ALTER TABLE, например:

ALTER TABLE table1 ALTER COLUMN field1 TYPE char(20);

Информацию об изменении столбцов таблицы см. в разд. "Изменение таблиц" главы 16.

 

Изменение типа данных домена

Используйте предложение TYPE В операторе ALTER DOMAIN для изменения типа данных домена, например,

ALTER DOMAIN MyDomain TYPE VARCHAR(40);

На рис. 8.1 показаны допустимые преобразования типов данных. Более подробную информацию об изменении атрибутов домена см. в главе 13.

 

ODS и диалект

Структура данных на диске (On-Disk Structure, ODS) идентифицирует базу данных в отношении версии релиза сервера Firebird или InterBase, который создает и восстанавливает базу данных. ODS базы данных влияет на совместимость с версиями сер- вера. Файл, подходящий для обновления ODS, может быть создан резервным копированием базы данных (backup) с использованием утилиты gbak той версии, в которой была создана база данных. Утилита должна быть использована с переключателем -t[ransportable]. Когда файл резервной копии будет восстановлен с использованием gbak новой версии, восстановленная база данных будет иметь новую версию ODS. Такое невозможно выполнить для "понижения" ODS для любой базы данных.

Использование gbak подробно обсуждается в главе 38.

Обновление ODS не изменяет диалект

Обновление ODS не влияет на диалект SQL базы данных: база данных диалекта 1 останется базой данных диалекта 1.

Базы данных Firebird

Firebird 1.0.x имеет ODS, обозначаемый как ODS-10. Firebird 1.5 имеет ODS-10.1. Чтобы преобразовать базу данных ODS-10, созданную в Firebird 1.0.x в ODS-10.1, вам просто нужно сделать ее резервную копию и восстановить эту копию с использованием gbak из Firebird 1.5. По умолчанию серверы Firebird версий 1.0.3+ и 1.5 создают базы данных диалекта 3. Для проверки ваших баз данных см. разд. "Как определить диалект" далее в этой главе.

Базы данных InterBase 6.0.x

OpenSource InterBase версий 6.0.x имеют ODS-10. Тем не менее для обновления баз данных InterBase 6.0.x до любой версии Firebird рекомендуется использовать gbak из InterBase 6.0 с переключателем -t[ransportable]. Файл резервной копии должен быть затем восстановлен с использованием gbak соответствующей версии сервера Firebird.

Если база данных InterBase 6.0 была создана с установками по умолчанию, то, вероятно, она имеет диалект 1. См .разд. "Как определить диалект" далее в этой главе.

Базы данных InterBase 5.x

Базы данных InterBase 5 имеют ODS-9 (9.0 и 9.1). Серверы Firebird могут открывать их, читать как базы данных диалекта 1, но дальнейшая работа с этими базами данных в InterBase 5.x не рекомендуется.

! ! !

ПРИМЕЧАНИЕ. Сервер Firebird не может создавать базы данных с ODS-9. Базы данных диалекта 1, созданные сервером Firebird, не могут быть использованы сервером InterBase 5.x.

. ! .

Не существует такой вещи, как база данных ODS-9 диалекта 1 или диалекта 3. Для обновления базы данных ODS-9 до Firebird используйте программу gbak из InterBase 5.x, запущенную с сервера InterBase 5.6 с переключателем -t[ransportable]. Обновление базы данных InterBase 5.x до Firebird не преобразует ее в диалект 3 базы данных. Ее SQL диалект будет 1, и это обновление является необратимым.

 

Где учитывается диалект

Концепция диалекта различает способ поддержки типов данных и возможности языка, доступные в базах данных с ODS-9 (диалект 1) и ODS-10 и выше (диалект 3). Сам сервер не имеет "диалекта" - диалект базы данных сохраняется как атрибут базы данных. Он является интерфейсом клиента, который определяет, какой набор возможностей запрашивается у базы данных. При некоторых условиях, если вы как разработчик приложений или пользователь инструментов администратора используете его неправильно, вы получите ошибочные данные, сохраняемые в базе, что может привести к некорректной работе приложений и базы данных.

Здесь удобно обратиться к экземпляру клиентского соединения, выполненного с помощью библиотеки API или пользовательского драйвера языка, такого как JayBird (Java), ODBC или провайдер .NET, как "клиент диалекта 1" или "клиент диалекта 3". Это означает, что интерфейс клиента будет установлен для получения возможностей диалекта 1 или 3.

Что можно отбросить

Следующий список иллюстрирует некоторые отличия диалекта 1 от диалекта 3.

* Диалекты 1 и 3 хранят большие масштабируемые числа по-разному. В диалекте 3 все типы с фиксированной точкой (NUMERIC и DECIMAL), имеющие точность больше 10, являются 64-битовыми целыми с описанием, которое включает некоторые атрибуты для определения точности и масштаба. В диалекте 1 числа с фиксированной точкой хранятся как 16- или 32-битовые целые, а числа с точностью, превышающей 10, преобразуются для хранения в 64-битовый тип числа с плавающей точкой DOUBLE PRECISION. Ваши данные, вероятно, вызовут ошибку переполнения, если клиент диалекта 3 выдаст запрос на сохранение числа в базе данных диалекта 1, или сгенерируют ошибочный результат, когда клиент диалекта 1 выдаст запрос на операции с числами в базе данных диалекта 3.

* Генераторы в диалекте 3 являются 64-битовыми целыми, в то время как в диалекте 1 генераторы - 32-битовые целые.

* Арифметические операции в диалекте 3 были взяты из стандарта SQL-92, в то время как диалект 1 использует нестандартные правила. Например, деление целого на целое в диалекте 3 возвращает усеченное целое, в то время как в диалекте оно вернет число с плавающей точкой двойной точности. Если ваше приложение сохраняет результат выражения, включающего подобную арифметическую операцию, "ошибочные" результаты будут сохранены без возбуждения исключения.

* Оба диалекта имеют тип данных даты и времени с именем DATE, но это разные типы. В диалекте 1 тип DATE эквивалентен типу TIMESTAMP диалекта 3, а в диалекте 3 DATE является типом, хранящим только дату; этот тип не поддерживается в диалекте 1.

* Диалект 3 поддерживает тип TIME (время дня), который отсутствует в диалекте 1.

* В базах данных диалекта 3 Firebird поддерживает соглашения ANSI SQL по идентификаторам с разделителями, которые заключаются в двойные кавычки; такие

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

* Диалект 3 имеет больше зарезервированных ключевых слов, чем диалект 1. Существующие базы данных диалекта 1, которые используют новые ключевые слова в качестве идентификаторов, не будут работать с клиентом диалекта 3.

* Диалекты 1 и 3 ведут себя по-разному в случае неявного преобразования типов. Это может стать проблемой, если вы хотите конвертировать существующую базу данных в диалект 3 и изменять использующие ее приложения.

Диалект 2

Не существует такого предмета, как "база данных диалекта 2". Диалект 2 является клиентской установкой, которую вы можете использовать для проверки переходных требований типов данных при конвертировании базы данных диалекта 1 в диалект 3. Inprise Corporation (теперь Borland) разработала документ "Migration Guide" (Руководство по миграции) для InterBase 6.0 в 2000 году, где подробно описаны действия по конвертированию баз данных диалекта 1 в диалект 3. Этот документ в формате PDF доступен на некоторых сайтах сообщества Firebird.

 

Как определять диалект

Вызовите окно командной строки и перейдите в каталог /bin, где находятся инструменты командной строки Firebird. Запустите утилиту isql. Соединитесь с вашей базой данных:

SQL> CONNECT '/opt/firebird/examples/employee.fdb'

CON> user 'SYSDBA' password 'icur2yy4m';

SQL>

Затем введите следующую команду ISQL:

SQL> SHOW SQL DIALECT;

Client SQL dialect is set to: 3 and database dialect is: 3

(Диалект SQL клиента установлен в: 3, диалект базы данных: 3)

Это хорошо. Если вы найдете несоответствие, это ничему не повредит, если вы не будете пытаться добавлять или изменять данные. Вы должны принять меры, чтобы гарантировать использование клиентом корректного диалекта.

Изменение диалекта клиента в isql

Предположим, что сейчас в isql вы хотите закрыть ваше соединение с текущей базой данных и соединиться с другой базой данных, о которой вы знаете, что она в диалекте 1. Вот что вы делаете:

SQL> COMMIT;

SQL> SET SQL DIALECT 1;

WARNING: client SQL dialect has been set to 1 when connecting to Database

SQL dialect 3 database.

(Предупреждение: SQL-диалект клиента установлен в 1 при соединении с базой данных с SQL-диалектом 3)

SQL>

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

SQL> CONNECT 'RSERVER:D:\DATA\SAMPLE\legacy.gdb'

CON> user 'SYSDBA' password 'icur2yy4m';

SQL> SHOW SQL DIALECT;

Client SQL dialect is set to: 1 and database dialect is: 1

(Диалект SQL клиента установлен в: 1, диалект базы данных: 1)

Множество свободно распространяемых и коммерческих инструментов администратора с графическим интерфейсом предоставляют возможность интерактивной установки диалекта клиента. Компоненты доступа к базе данных и драйверы имеют свойства или другие механизмы для передачи диалекта структуре соединения API.

Пора дальше

Следующие четыре главы подробно описывают типы данных, поддерживаемые для каждой из основных категорий данных: числа, дата/время, символы и BLOB. Глава 13, последняя глава в этой части, описывает реализацию доменов в Firebird для объединения типа данных с группой атрибутов в одно воспроизводимое определение.

 

SMALLINT

SMALLINT является 2-байтовым целым, предоставляющим компактное хранение для целых чисел с ограниченным диапазоном значений. Например, SMALLINT может быть подходящим для хранения значений цветов в форме RGB, как показано в предыдущем примере создания домена.

SMALLINT часто используется для определения булевых значений, обычно 0 = ложь, 1 = истина. Пример такого использования можно найти в разд. "Объявление булевых доменов" главы 13.

 

INTEGER

INTEGER является 4-байтовым целым. В диалекте 1 генераторы (см. разд. "Генераторы" этой главы) генерируют значения типа INTEGER. Вы можете хранить такие целые в столбцах BIGINT без преобразования.

 

BIGINT, NUMERIC(18,0)

Доступны только в диалекте 3. Это 8-байтовое целое, полезное для хранения целых чисел с очень маленькими и очень большими значениями. В диалекте 3 генерируются числа типа BIGINT (см. разд. "Генераторы").

 

Автоинкремент или тип IDENTITY

Firebird не поддерживает типы автоинкремента или IDENTITY, которые вы могли встретить в других системах управления базами данных. Что у него есть, так это средство числовых генераторов и возможность поддерживать независимые, именованные серии чисел BIGINT. Каждая серия известна как генератор. Техника их использования для реализации и поддержки первичных ключей и других автоматических инкрементных серий описана в главе 31.

 

Генераторы

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

CREATE GENERATOR AGenerator;

Генераторам может быть присвоено любое начальное значение:

SET GENERATOR AGenerator ТО 1;

! ! !

ВНИМАНИЕ! Существуют строгие предупреждения по поводу переустановки значений генераторов, когда эти значения находятся в использовании - см. разд. "Предупреждения о переустановке значений генераторов" в этой главе.

. ! .

Получение следующего значения

Для получения следующего значения вызывайте функцию SQL GEN_ID(ИмяГенератора, n), где имягенератора - имя генератора, а n - целое (диалект 1) или NUMERIC(18,0) (диалект 3), определяющее значение шага. Запрос:

SELECT GEN_ID(AGenerator, 2) from RDB$DATABASE;

возвращает число, которое на 2 больше последнего сгенерированного числа, и устанавливает значение генератора в сгенерированное значение.

Текущее значение генератора

Следующая строка:

SELECT GEN_ID(AGenerator, 0) from RDB$DATABASE;

возвращает текущее значение генератора без его увеличения.

PSQL, язык программирования Firebird, позволяет напрямую присваивать сгенерированное значение переменной:

. . .

DECLARE VARIABLE MyVar BIGINT;

. . .

MyVar = GEN_ID(AGenerator, 1);

Более подробную информацию об использовании генераторов в модулях PSQL - в особенности в триггерах - см. в главе 29.

Использование отрицательного шага

Аргумент шаг в GEN_ID может быть отрицательным. Следовательно, можно устанавливать или переустанавливать текущее значение генератора, передавая отрицательный аргумент или в виде целой константы, или в виде целого выражения. Эта возможность иногда используется как "трюк" для установки значений генератора в PSQL, поскольку в PSQL не могут использоваться такие команды DDL, как SET GENERATOR.

Например, оператор:

SELECT GEN_ID (AGenerator, -GEN_ID (AGenerator, 0)) from RDB$DATABASE;

устанавливает значение генератора в ноль.

Предупреждения о переустановке значений генераторов

Основное простое правило по переустановке значений генераторов в работающей базе данных - будь то в SQL, PSQL или в некотором интерфейсе администратора - не делать этого.

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

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

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

 

Тип данных NUMERIC

Формат типа данных NUMERIC:

NUMERIC(p,s)

Например, NUMERIC (4,2) определяет число, состоящее не более чем из четырех цифр, включая две цифры справа от десятичной точки. Следовательно, числа 89.12 и 4.321 будут сохранены в столбце NUMERIC(4,2) как 89.12 и 4.32 соответственно. Во втором примере последняя цифра 10(^-3^) выходит за пределы масштаба и просто отбрасывается.

И все же возможно хранение в этом столбце числа с большей точностью, чем было объявлено. Максимально здесь может быть 327.67 - т. е. число с точностью 5. Поскольку база данных хранит фактическое число как SMALLINT, числа не начинают вызывать ошибки переполнения, пока внутренне хранимое число не станет больше 32,767 или меньше -32,768.

 

Тип данных DECIMAL

Формат типа данных DECIMAL:

DECIMAL(Р, S)

Как и в случае NUMERIC, DECIMAL(4,2) определяет число, состоящее, по меньшей мере, из четырех цифр, включая две цифры справа от десятичной точки. Тем не менее, поскольку Firebird сохраняет данные DECIMAL с точностью 4 и меньше как INTEGER, этот тип может в столбце DECIMAL(4,1) потенциально хранить число от 214 748 364 до -214 748 364.8 без появления ошибки переполнения.

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

Таблица 9.2. Диапазон и способ хранения в Firebird типов данных NUMERIC и DECIMAL

* Точные числа с точностью больше чем 9, могут быть объявлены в диалекте 1 базы данных без появления исключения. Эти числа будут храниться как DOUBLE PRECISION и будут подчиняться тем же самым ограничениям точности, что и любые числа с плавающей точкой. В процессе преобразования базы данных диалекта 1 в диалект 3 клиент диалекта 2, открыв таблицу, содержащую столбцы DECIMAL или NUMERIC с точностью, большей 9, получит сообщение об ошибке. Более подробную информацию о преобразованиях диалекта 1 в диалект 3 см. в разд. "Специальная тема миграции: диалекты SQL" главы 8.

 

Конвертированные базы данных

Если база данных диалекта 1 была обновлена до диалекта 3 с использованием создания резервной копии gbak, а затем восстановлена, то числовые поля, определенные с точностью, большей 9, сохранят тип данных DOUBLE PRECISION. Хотя они будут представлены так, как были вначале определены (например, NUMERIC (15,2)), они будут сохраняться и использоваться в вычислениях как DOUBLE PRECISION.

Более подробную информацию о преобразованиях баз данных диалекта 1 в диалект 3 см. в разд. "Специальная тема миграции: диалекты SQL" главы 8.

 

Специальные ограничения в статическом SQL

Включающий язык встроенных приложений не может использовать или распознавать малые точности типов данных NUMERIC или DECIMAL С дробной частью, когда они внутренне хранятся как типы SMALLINT или INTEGER. для устранения такой проблемы в любой базе данных, к которой предполагается доступ из таких встроенных приложений (ESQL):

* не определяйте столбцы или домены с типом NUMERIC или DECIMAL малой точности в базе данных диалекта 1. или храните данные как целые и пишите в приложениях код, учитывающий масштаб, или используйте DOUBLE PRECISION и применяйте подходящий алгоритм округления для вычислений;

* в базе данных диалекта 3 определяйте столбцы или домены любого размера типа NUMERIC и DECIMAL, используя точность не меньше 10, чтобы получить их внутреннее хранение как BIGINT. Указывайте масштаб, если вы хотите управлять точностью и масштабом. Используйте ограничения CHECK, если вам нужно контролировать диапазоны значений.

 

Поведение типов с фиксированной точкой в операциях

Деление

При выполнении деления типов с фиксированной точкой диалекты 1 и 3 ведут себя по-разному.

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

В диалекте 1 деление всегда создает частное типа DOUBLE PRECISION.

Примеры

В диалекте 3 частное от деления DECIMAL(12,3) на DECIMAL(9,2) будет DECIMAL(18,5). Масштабы суммируются:

SELECT 11223344.556/1234567.89 FROM RDB$DATABASE

Это дает 9.09090.

Посмотрим, чем отличается частное, когда этот же запрос выполняется в диалекте 1. Первый операнд трактуется как число DOUBLE PRECISION, потому что его точность (12) превышает максимум масштабируемого типа для диалекта 1. Частное также является числом DOUBLE PRECISION. Результат 9.09090917308727 по причине ошибок, присущих типам с плавающей точкой.

Для следующей таблицы, определенной в диалекте 3, операции деления дают различные результаты.

CREATE TABLE t1 (

i1 INTEGER,

i2 INTEGER,

n1 NUMERIC(16, 2),

n2 NUMERIC(16,2));

COMMIT;

INSERT INTO t1 VALUES (1, 3, 1.00, 3.00);

COMMIT;

Следующий запрос возвращает значение 0.33 типа NUMERIC(18,2), потому что сумма масштабов 0 (операнд 1) и 2 (операнд 2) равна 2:

SELECT i1/n2 from t1

Следующий запрос возвращает значение 0.3333 типа NUMERIC (18,4), потому что сумма масштабов двух операндов равна 4:

SELECT n1/n2 FROM t1

Деление целого на целое

Используя предыдущий пример, следующий запрос в диалекте 3 вернет целое 0, потому что каждый операнд имеет масштаб 0, следовательно, сумма масштабов будет 0:

SELECT i1/i2 FROM t1

В диалекте 1, как и в большинстве других СУБД, деление одного целого на другое целое даст результат с плавающей точкой типа DOUBLE PRECISION:

SELECT 1/3 AS RESULT FROM RDB$DATABASE

Это дает .333333333333333.

Хотя настоящее правило диалекта 1 является интуитивным для языков программирования, оно не соответствует стандарту SQL-92. Целые типы имеют масштаб 0. Для согласованности это требует, чтобы результат (частное) любой операции деления целого на целое соответствовал правилам масштабирования для чисел с фиксированной точкой и был бы целым.

Диалект 3 соответствует стандарту и усекает частное от операций деления целого на целое до целого. Следовательно, следующий оператор является неразумным:

SELECT 1/3 AS RESULT FROM RDB$DATABASE

Он вернет 0.

Если вам нужно сохранить дробную часть в результате (в частном) деления целого на целое в диалекте 3, убедитесь, что у одного из операндов присутствует нужный масштаб, или включите "множитель" в выражение, чтобы гарантировать масштаб результата.

Примеры:

SELECT 1.00/3 AS RESULT FROM RDB$DATABASE

Вернет .33.

SELECT (5 * 1.00)/2 AS RESULT FROM RDB$DATABASE

Этот вернет 2.50.

Диалект 1 базы данных с диалектом 3 клиента

База данных диалекта 1, которая была открыта клиентом диалекта 3, может преподнести некоторые сюрпризы в отношении деления целых чисел. Когда операция выполняет нечто, что приводит к проверке условия CHECK, или выполняется хранимая процедура или триггер, то осуществляемые действия основаны на диалекте, на котором CHECK, хранимая процедура или триггер были определены, а не на действующем диалекте, на котором приложение выполняет проверку, хранимую процедуру или триггер.

Например, в базе данных диалекта 1 таблица содержит столбцы MYCOL1 (INTEGER) и MYCOL2 (INTEGER) и следующее условие CHECK, которое было определено, когда база данных имела диалект 1:

CHECK(MYCOL1 / MYCOL2 >0.5)

Пусть теперь пользователь запускает isql или приложение, задав диалект 3. Программа пытается добавить строку в конвертированную базу данных:

INSERT INTO MYTABLE (COL1, COL2) VALUES (2,3);

Поскольку ограничение CHECK было определено в диалекте 1, оно вернет частное 0.666666666666667, и строка будет соответствовать условию CHECK.

Обратное также верно. Если то же ограничение CHECK было добавлено в базу данных диалекта 1 из клиента диалекта 3, то для ограничения будет сохранена арифметика диалекта 3. Предыдущий оператор INSERT не будет выполнен, потому что проверка вернет значение частного 0, которое нарушает это ограничение.

! ! !

СОВЕТ. Мораль всего этого: используйте базы данных диалекта 3 и всегда соединяйтесь с ними, применяя диалект 3. Если вы собираетесь использовать Firebird, то обновите все существующие базы данных до диалекта 3 - желательно описав новую базу данных и поместив в нее ваши старые данные - таким образом вы сохраните покой и сможете избежать уймы неприятных сюрпризов.

. ! .

Умножение и деление

Если оба операнда являются точными числами, умножение операндов даст точное число с масштабом, равным сумме масштабов операндов. Например,

CREATE TABLE t1 (

n1 NUMERIC(9,2),

n2 NUMERIC (9,3) ) ;

COMMIT;

INSERT INTO t1 VALUES (12.12, 123.123);

COMMIT;

Следующий запрос возвращает число 1492.25076, потому что n1 имеет масштаб 2, а n2 - масштаб 3. Сумма масштабов 5.

SELECT n1*n2 FROM t1

В диалекте 3 точность результата умножения чисел с фиксированной точкой будет равна 18. Нужно принять меры предосторожности, чтобы быть уверенным, что не будет переполнения результата при распространении масштаба в умножении.

В диалекте 1, если распространение масштаба приводит к тому, что вычисление даст результат с точностью больше 9, то результатом будет DOUBLE PRECISION.

Сложение и вычитание

Если все операнды являются точными числами, то сложение и вычитание операндов даст точное число с масштабом, равным максимальному масштабу операндов. Например,

CREATE TABLE t1 (

n1 NUMERIC(9, 2) ,

n2 NUMERIC(9, 3)) ;

COMMIT;

INSERT INTO t1 VALUES (12.12, 123.123);

COMMIT;

SELECT n1 + n2 FROM t1;

Этот запрос возвращает 135.243, выбирая максимальный масштаб операндов. Аналогично, следующий запрос возвращает число -111.003:

SELECT n1 - n2 FROM t1;

В диалекте 3 результат любого сложения или вычитания имеет тип NUMERIC(18,n). В диалекте 1 он имеет тип NUMERIC (9, n), где n - масштаб максимального операнда.

 

FLOAT

FLOAT является 32-битовым типом данных с плавающей точкой с приблизительно 7 цифрами точности - для надежности предполагайте 6 цифр. Число с 10 цифрами 25.33333312, добавленное в столбец FLOAT, сохраняется как 25.33333. Диапазон чисел от -3.402 x 10(^38^) до 3.402 x 10(^38^). Наименьшее положительное число, которое может быть сохранено, 1.175 * 10(^-38^).

 

DOUBLE PRECISION

DOUBLE PRECISION является 64-битовым типом данных с плавающей точкой с приблизительно 15 цифрами точности. Диапазон от -1.797 x 10(^308^) до 1.797 x 10(^308^). Наименьшее положительное число, которое может быть сохранено, 2.225 x 10(^-308^).

Арифметические операции над смешанными типами с фиксированной и плавающей точкой

Когда бинарная операция (сложение, вычитание, умножение и деление) включает в качестве операндов точные числа и числа с плавающей точкой, то результат будет типа DOUBLE PRECISION.

Следующий оператор создает столбец PERCENT_CHANGE, используя тип DOUBLE PRECISION:

CREATE TABLE SALARY_HISTORY

(

. . .

PERCENT_CHANGE DOUBLE PRECISION

DEFAULT О

NOT NULL

CHECK (PERCENT_CHANGE BETWEEN -50 AND 50),

. . .

) ;

Следующий оператор CREATE TABLE дает пример использования различных числовых типов данных: INTEGER для общего количества заказов, с фиксированной точкой DECIMAL для общей суммы продаж в долларах и FLOAT для скидки к продаже:

CREATE TABLE SALES

(. . .

QTY_ORDERED INTEGER

DEFAULT 1

CHECK (QTY_ORDERED >=1),

TOTAL_VALUE DECIMAL (9,2)

CHECK (TOTAL_VALUE >= 0),

DISCOUNT FLOAT

DEFAULT 0

CHECK (DISCOUNT >= 0 AND DISCOUNT <= 1));

Пора дальше

В следующей главе мы рассмотрим типы данных для хранения и обработки дат и времени в Firebird.

 

Доли секунды

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

 

Интервал времени

Ошибочно предполагать, что тип TIME может хранить интервал времени. Он не может. Для вычисления интервала времени вычтите более позднюю дату или время из более раннего. Результатом будет число NUMERIC(18,9), выражающее интервал в днях. Поскольку точность теряется, доли секунд надо рассматривать как миллисекунды, а не десятитысячные доли секунд. Используйте обычные арифметические операции для конвертирования дней в часы, минуты или секунды, как вам требуется.

Предположим, что столбцы STARTED и FINISHED имеют тип TIMESTAMP (DATE В диалекте 1). Для вычисления и сохранения в столбце TIME_ELAPSED типа DOUBLE PRECISION интервала времени в минутах вы можете использовать следующее:

UPDATE ATABLE

SET TIME_ELAPSED = (FINISHED - STARTED) * 24 * 60

WHERE ((FINISHED IS NOT NULL) AND (STARTED IS NOT NULL));

 

"Скользящее окно века" в Firebird

Независимо от того, как представлена часть года в литерале DATE или TIMESTAMP, в виде CCYY или YY, Firebird всегда сохраняет полное значение года. Он обращается к алгоритму получения части cc (столетие). Он также всегда включает столетие при поиске типов даты. Клиентские приложения отвечают за отображение года в виде двух или четырех цифр.

Для получения столетия Firebird использует алгоритм скользящего окна. Задача заключается в интерпретации двухсимвольного значения года как ближайшего к текущему году в интервале предшествующих и последующих 50 лет.

Например, если текущий год 2004, то двухсимвольные значения года будут интерпретироваться, как показано в табл. 10.3.

Таблица 10.3. Определение года по двухсимвольному виду, если текущим является 2004 год

* Кажущееся равенство в этом сравнении может ввести в заблуждение. 1954 год ближе к 2004, чем 2054, потому что все даты между 1954 и 1955 годами ближе к 2004, чем все даты между 2054 и 2055 годами.

 

Разделители в неамериканских датах

Ничто не вызывает больше затруднений для интернациональных пользователей, как ограничения в Firebird на использование наклонной черты (/) только для американского формата 'MM/DD/CCYY'. Хотя почти все другие страны используют формат 'DD/MM/CCYY', Firebird будет либо записывать неправильную дату, либо вызовет исключение для литерала даты, использующего соглашение 'DD/MM/CCYY'.

Например, литерал даты '12/01/2004' всегда будет сохраняться в смысле "1 декабря 2004 года", а '14/01/2004' вызовет исключение выхода за границы диапазона, потому что не существует месяца 14. Однако допускается 'CCYY/MM/DD': дата '2004/12/31' будет расшифровано как "31 декабря 2004 года".

Обратите внимание, что Firebird не учитывает локальные форматы даты Windows или Linux при интерпретации литералов даты (ни на сервере, ни на клиенте). Его интерпретация числовых форматов дат основывается на символе-разделителе. Если точка (.) используется в качестве разделителя, Firebird интерпретирует дату в виде неамериканской нотации DD.MM, в то время как любой другой разделитель предполагает американскую нотацию MM/DD. Чтобы убрать американскую интерпретацию даты, ваши приложения должны преобразовать введенную дату DD/MM/CCYY в литерал, где наклонная черта заменена на символ точки в качестве разделителя. Дата 'DD.MM.CCYY' правильная. Могут быть использованы и другие форматы литералов даты.

 

Пробелы в литералах даты

Пробелы или символы табуляции могут присутствовать между элементами. Дата должна быть отделена от времени, по меньшей мере, одним пробелом.

 

Заключение в апострофы литералов даты

Литералы даты должны быть заключены в апострофы (ASCII 39). Допустимы только апострофы, а не двойные кавычки.

 

Литералы месяца

В табл. 10.4 показаны литералы месяцев.

Таблица 10.4. Литералы месяцев и правильное английское написание

 

Примеры литералов даты

Двадцать пятое число (25) шестого месяца (июнь) 2004 года может быть представлено любым из следующих способов:

'25.6.2004' '06/25/2004' 'June 25, 2004'

'25.jun.2004' '6,25,2004' '25,jun,2004'

'25jun2004' '6-25-04' 'Jun 25 04'

'25 jun 2004' '2004 June 25' '20040625'

'25-jun-2004' '2004-jun-25' '20040625'

'25 JUN 04' '2004-06-25' '2004,25,06'

 

Общие правила для операций

Одно значение даты или времени может быть вычтено из другого, если:

* оба значения имеют один и тот же тип даты/времени;

* первый операнд является более поздним, чем второй.

Вычитание, использующее типы дата/время, дает результаты: масштабируемое DECIMAL в диалекте 3 и DOUBLE PRECISION В диалекте 1.

Типы данных дата/время не могут складываться друг с другом. Однако можно выполнить конкатенацию части даты и части времени, используя:

* дополнительный бинарный синтаксис для конкатенации пар полей или переменных;

* объединение строк для конкатенации литерала дата/время с другим литералом дата/время или с полем, или переменной типа дата/время.

Операции умножения и деления, включающие типы данных дата/время, недопустимы.

 

Выражения в качестве операндов

Операндом при увеличении или уменьшении значения TIMESTAMP, TIME, DATE или DATE в диалекте 1 может быть константа или выражение. Выражение может быть особенно полезным в ваших приложениях, когда вам надо увеличить или уменьшить значение в секундах, минутах, часах или, например, требуется половина дня, а не целое количество дней.

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

В табл. 10.8 показаны некоторые примеры.

Таблица 10.8. Примеры использования выражений в качестве операндов

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

 

Преобразование между типами дата/время

Обычно преобразование из одного типа дата/время в другой возможно, если исходный тип дата/время содержит подходящий вид данных для помещения в выходной тип дата/время. Например, TIMESTAMP содержит данные, которые можно преобразовать в тип только даты DATE или только время TIME, В то время как тип TIME не содержит достаточно данных для преобразования в тип DATE. Firebird предоставляет возможность преобразовывать тип DATE В TIMESTAMP, присваивая времени значение полночи, и тип TIME в TIMESTAMP, выбирая дату из контекстной переменной CURRENT_DATE (серверное время). В табл. 10.9 представлены правила преобразования.

Таблица 10.9. Преобразования между типами дата/время в диалекте 3

 

Преобразование типов даты в CHAR(n) и VARCHAR(n)

Используйте в операторах SQL-функцию CAST() для трансляции данных даты и времени в символьные типы данных.

Firebird преобразует типы дата и время в форматированные строки, в которых дата (если присутствует) представлена в установленном формате - в зависимости от диалекта - а время представлено в стандартном для Firebird формате: HH:MM:ss.nnnn. Необходимо использовать столбец, переменную типа CHAR или VARCHAR подходящего размера для получения желаемого вами результата.

Преобразование типов дата/время можно выполнять в оба строковых типа фиксированной длины CHAR и переменной длины VARCHAR. Поскольку размер преобразуемой строки заранее известен, CHAR имеет небольшое преимущество перед VARCHAR: использование CHAR при передаче по сети сэкономит вам два байта, которые добавляются к VARCHAR для хранения размера. "Правильный размер" зависит от диалекта, обратите на это внимание, VARCHAR может быть более подходящим при использовании в коде приложения, которое может обрабатывать оба диалекта.

Если символьное поле слишком мало для результата, то появится исключение переполнения. Пусть, вам нужно получить строку, содержащую только дату из TIMESTAMP. Использование для этого символьного контейнера меньшего размера не будет работать - CAST() не обрезает выходную строку. Необходимо выполнить двойное преобразование: вначале преобразование TIMESTAMP в DATE, а затем преобразование даты в символьный тип корректного размера - см. примеры в следующем разделе.

Диалект 3

Преобразование DATE или TIMESTAMP создает дату в формате ISO (CCYY-MM-DD). Полная длина выходной строки 10 символов для DATE и 11 - для TIMESTAMP (дата и один пробел перед временем). Нужно 13 символов для TIME или для времени в TIMESTAMP.

Например, выражение

SELECT CAST(timestamp_col as CHAR(24)) AS TstampTxt FROM RDB$DATABASE;

даст строку вроде следующей:

2004-06-25 12:15:45.2345

Это выдаст исключение переполнения:

SELECT CAST (timestamp_col as CHAR(20)) AS TstampTxt FROM RDB$DATABASE;

Двойное преобразование создает правильную строку:

SELECT FIRST 1 CAST (

CAST (timestamp_col AS DATE) AS CHAR(10)) FROM Table1;

Результатом будет:

2004-06-25

К сожалению, нет возможности путем прямого преобразования получить строку, содержащую дату плюс время без дробных долей секунды. Это может быть выполнено с использованием сложного выражения, включающего функции CAST() и EXTRACT(). Пример см. в одном из следующих подразделов разд. "Функция EXTRACT()".

Диалект 1

Дата в типе данных DATE диалекта 1 преобразуется в формат DD-MMM-CCYY, а не В формат ISO, как в диалекте 3. Например, вот это

SELECT CAST(dldate_col as CHAR(25)) AS DateTimeTxt FROM RDB$DATABASE;

даст

26-JUN-2004 12:15:45.2345

Следовательно, преобразование дат в диалекте 1 требует 11 символов вместо 10 плюс 1 символ пробела плюс 13 для времени - всего 25.

Более сложные выражения

Преобразование может использовать более сложные выражения в комбинации с другими выражениями, например:

SELECT CAST (10 + CAST(('TODAY') AS DATE) AS CHAR(25)) TEXTTIME FROM RDB$DATABASE;

или

SELECT CAST (10 + CURRENT_TIMESTAMP) AS DATE) AS CHAR(25)) TEXTTIME FROM RDB$DATABASE;

возвращает текстовую строку, показывающую дату на 10 дней позже текущей даты.

 

Преобразования между типами дата/время и другими типами данных

Любой символьный тип или выражение, чье содержание может быть выражено в правильном литерале даты, может быть преобразовано в соответствующий тип дата/время.

Типы данных времени и даты не могут быть участниками преобразований в типы или из типов SMALLINT, INTEGER, FLOAT, DOUBLE_PRECISION, NUMERIC, DECIMAL или BLOB.

 

Использование преобразований

Обмен данными дата/время с другими приложениями

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

Большинство включающих языков программирования не поддерживают типы данных DATE, TIME и TIMESTAMP, представляя их внутренне в виде строк или структур. Устройства ввода данных обычно сохраняют дату и время в строках различных форматов и стилях. Типы дата/время чаще всего являются несовместимыми в различных базах данных.

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

В некоторых случаях сохранение внешних данных в текстовых файлах в форматах литералов даты может быть лучшим решением. Firebird может открывать такие файлы, как входные таблицы в модулях на серверной стороне - хранимые процедуры или триггеры - и использовать CAST() и другие функции для обработки данных в столбцах даты/времени в родных таблицах. Более подробную информацию см. в разд. "Использование внешних файлов в качестве таблицы " главы 16.

Функция CAST() также может быть использована для подготовки внутренних данных для экспорта.

Использование в выражениях условия поиска

Такие ситуации появляются, когда использование CAST() в предложении WHERE с типами дата/время решает логические проблемы сравнения столбца одного типа со столбцом другого типа данных.

Предположим, что нам нужно объединить таблицу покупателей, которая содержит столбец BALANCE_DATE типа DATE с таблицей транзакций покупателя, которая имеет столбец TRANSUDATE типа TIMESTAMP. Нам нужно создать предложение WHERE, которое выбирает набор данных, содержащий неоплаченные транзакции для текущего покупателя, появившиеся не позднее BALANCE_DATE. Мы можем попытаться:

SELECT ...

WHERE COST_TRANS.TRANSDATE <= CUSTOMER.BALANCE_DATE ;

Этот критерий не даст нам того, что мы хотим! Он найдет все строки транзакций после полуночи даты BALANCE_DATE, потому что он вычислит BALANCE_DATE с временем 00:00:00. Любая транзакция после полуночи этой даты не будет соответствовать критерию поиска.

Что мы действительно хотим, так это включить все транзакции, где дата из TRANS DATE соответствует BALANCE_DATE. Преобразование TRANSUDATE в тип DATE сохраняет день:

SELECT ...

WHERE CAST (CUST_TRANS.TRANSDATE AS DATE) <= CUSTOMER.BALANCE_DATE;

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

Диалект 3 предоставляет более богатую поддержку типов дата/время, чем диалект 1. Одной из задач, которая, скорее всего, привлечет ваше внимание, если вы выполняете такое преобразование, является замена существующих в диалекте 1 столбцов типа DATE (который эквивалентен типу TIMESTAMP в диалекте 3) путем преобразования их в типы данных диалекта 3 DATE (только дата) или TIME (только время), CAST() легко выполняет эту работу.

Пример одного из стилей преобразования с использованием CAST() см. в конце этой главы.

 

Синтаксис

Синтаксис функции EXTRACT():

EXTRACT (элемент FROM поле)

элемент должен быть одним из допустимых элементов в типе данных поле. Не все элементы допустимы для всех типов данных дата/время. Тип данных элемента изменяется в соответствии с выделяемым элементом. Табл. 10.10 перечисляет элементы, доступные для каждого типа дата/время.

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

Табл. 10.10 показывает ограничения на аргументы и их типы данных при использовании функции EXTRACT().

Таблица 10.10. Аргументы, типы и ограничения функции EXTRACT()

* 0 = воскресенье ... 6 = суббота.

 

Объединение EXTRACT() с другими функциями

Далее следуют два примера использования функции EXTRACT() внутри CAST() для получения представлений даты, которые не могут быть получены использованием одной из функций.

Получение даты и времени без долей секунды

Хотя невозможно прямым преобразованием получить строку даты и времени без долей секунды, это может быть сделано при использовании выражения, включающего обе функции CAST() и EXTRACT().

Выделение строки времени

Эта техника больше нужна в диалекте 1, чем в диалекте 3. Тем не менее она может быть экстраполирована на любой тип даты или времени диалекта 3, если вам нужно сохранять время дня в виде строки.

Функция EXTRACT() делает возможным выделение отдельных элементов типов даты и времени в значения SMALLINT. Следующий триггер выделяет элементы времени из столбца диалекта 1 DATE с именем CAPTURE_DATE и преобразует их в CHAR (13), имитируя стандартный в Firebird литерал времени 'HH:MM:ss.nnnn'.

SET TERM ^;

CREATE TRIGGER BI_ATABLE FOR ATABLE

ACTIVE BEFORE INSERT POSITION 1

AS

BEGIN

IF (NEW.CAPTURE_DATE IS NOT NULL) THEN

BEGIN

NEW. CAPTURE_TIME =

CAST(EXTRACT (HOUR FROM NEW.CAPTUEE_DATE) AS CHAR(2)) || ':' ||

CAST(EXTRACT (MINUTE FROM NEW.CAPTURE_DATE) ASCHAR(2)) || ':' ||

CAST(EXTRACT (SECOND FROM NEW.CAPTURE_DATE) AS CHAR(7));

END

END ^

SET TERM ; ^

Пример преобразования типа дата/время

Строка CHAR (13), сохраняемая триггером в предыдущем примере, не имеет того "поведения," что тип TIME в диалекте 3. Тем не менее при простом преобразовании она может быть конвертирована напрямую в тип TIME диалекта 3 при последующем обновлении до диалекта 3.

Сначала мы добавляем новый временный столбец в таблицу для хранения конвертированной строки времени:

ALTER TABLE ATABLE

ADD TIME_CAPTURE TIME;

COMMIT;

Затем заполняем временный столбец строкой времени, выполняя преобразование в диалекте 1:

UPDATE ATABLE

SET TIME_CAPTURE = CAST (CAPTURE_TIME AS TIME)

WHERE CAPTURE_TIME IS NOT NULL;

COMMIT;

Следующая вещь, которую мы должны сделать, - это временно удалить в нашем триггере ссылку на строку времени диалекта 1. Это нужно, чтобы устранить проблемы зависимости при изменении старой строки времени.

SET TERM ^;

RECREATE TRIGGER BI_ATABLE FOR ATABLE

ACTIVE BEFORE INSERT POSITION 1

AS

BEGIN

/* ничего не выполняется */

END ^

SET TERM ;^

COMMIT;

Теперь мы можем удалить старый столбец CAPTURE_TIME:

ALTER TABLE ATABLE DROP CAPTURE_TIME;

COMMIT;

Создадим его опять, на этот раз как тип TIME:

ALTER TABLE ATABLE

ADD CAPTURE_TIME TIME;

COMMIT;

Перепишем данных из временного столбца в только что добавленный столбец

CAPTURE_TIME:

UPDATE ATABLE

SET CAPTURE_TIME = TIME_CAPTURE

WHERE TIME_CAPTURE IS NOT NULL;

COMMIT;

Удалим временный столбец:

ALTER TABLE ATABLE DROP TIME_CAPTURE;

COMMIT;

Под конец изменим триггер так, чтобы он теперь записывал значение CAPTURE_TIME как тип TIME:

SET TERM ^;

RECREATE TRIGGER BI_ATABLE FOR ATABLE

ACTIVE BEFORE INSERT POSITION 1

AS

BEGIN

IF (NEW.CAPTURE_DATE IS NOT NULL) THEN

BEGIN

NEW.CAPTURE_TIME = CAST (NEW.CAPTURE.DATE AS TIME);

END

END ^

SET TERM ;^

COMMIT;

Все эти шаги могут быть записаны в скрипте SQL. Подробности использования скриптов SQL см. в разд. "Скрипты схемы" главы 14.

 

Понимание функции EXTRACT()

Функция EXTRACT() вызывает исключение, если она получает пустой аргумент. Этот факт можно использовать в простых запросах для проверки условия NOT NULL или в выражениях подзапросов при декодировании полей типа дата/время. Тем не менее во внешних соединениях это не столь просто, потому что потоки внешнего соединения, которые не соответствуют условиям последнего, возвращают NULL в незаполненных полях.

Рекомендуется использовать подзапрос (см. главы 21 и 22), который ограничивает вызовы функции только при ненулевых значениях. В диалекте 3 есть другое решение: использовать выражение CASE (см. главу 21) для исключения вызова EXTRACT() при нулевых датах.

Пора дальше

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

 

Ограничитель строки

Ограничителем строк в Firebird является символ ASCII 39, или одиночная кавычка, или апостроф, например,

StringVar = 'This is a string.';

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

 

Конкатенация

Firebird использует стандартный в SQL символ для конкатенации (соединения) строк: двойной символ ASCII с кодом 124, известный как двойная вертикальная черта (||). Он может быть использован для конкатенации строковых констант, строковых выражений и/или значений столбцов, например:

MyBiggerString = 'You are my sunshine, ' || FirstName || ' my only sunshine.';

Символьные элементы могут соединяться с числами и числовыми выражениями для получения алфавитно-цифровых строк. Например, для конкатенации символа '#' с целым:

NEW.TICKET_NOMBER = '#' || NEW.PK_INTEGER;

! ! !

ВНИМАНИЕ! He используйте выражения конкатенации, где один из элементов может иметь значение NULL. Результатом любой конкатенации, содержащей NULL, будет NULL.

. ! .

 

Управляющие символы

Как правило, Firebird не поддерживает использование управляющих символов для включения непечатаемых кодов или последовательностей в строковые поля. Единственным исключением является "дублирование" символа апострофа (ASCII 39) для включения его в качестве хранимого символа и исключения его интерпретации как терминального ограничителя строки:

. . .

SET HOSTELRY = 'О''Flaherty''s Pub'

. . .

В строках можно хранить непечатаемые символы. Может быть объявлена функция UDF Asciichar (ascii_значение) в библиотеке ib udf, чтобы дать возможность передавать в строки такие символы или их последовательности. Следующий оператор выводит множество текстовых полей - например, во внешний файл - с символами возврата каретки и перевода строки в последнем поле:

INSERT INTO EXTFILE(DATA1, DATA1, DATA3, CRLF)

VALUES ('String1', 'String2', 'String3', Ascii_Char(13) || Ascii_Char(10));

По поводу объявления Asciichar (..) и других функций в библиотеке ib udf смотрите в подкаталоге ../UDF в корневом каталоге инсталляции Firebird скрипт с именем ib udf.sql. Подробности о внешних функциях см. в приложении 1.

 

Ограничения символьных типов

Ограничения многобайтовых наборов символов

Важно быть в курсе того, как многобайтовые наборы символов влияют на размеры текстовых элементов, особенно имеющих переменный размер. Например, в наборе символов UNICODE FSS даже 256-символьный столбец будет иметь больший размер - потенциально 770 байт- как для хранения данных, так и для поиска. Дальше в этой главе будет много сказано об осторожности, которую вы должны проявить, решая вопрос о хранении текстов для многобайтовых наборов символов.

Ограничения индексов

При решении вопросов размера, набора символов и последовательности сортировки для символьного столбца вам нужно убедиться, что индексируемые столбцы этих типов достаточно ограничены по размеру. В настоящее время (версия 1.5) общий размер любого индекса не может превышать 252 байта- заметьте, байтов, а не символов. Многобайтовые и многие более сложные однобайтовые наборы символов используют много больше байтов, чем простые наборы символов. Многосегментные индексы используют дополнительные байты, как и последовательности сортировки. Просчитайте количество байтов в процессе проектирования!

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

Использование памяти клиента

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

Рассмотрим, например, какое влияние окажет на рабочую станцию запрос, возвращающий 1024 строки, каждая из которых содержит один столбец, объявленный как VARCHAR(1024) . Даже с самым "скромным" набором символов этого столбца потребуется, по меньшей мере, 1 Мбайт памяти клиента. Для столбца Unicode умножьте эту величину на три.

 

Символьные данные фиксированной длины

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

Начальные символы пробелов (символ ASCII 32) во вводимых строках фиксированной длины являются значимыми, в то время как завершающие - нет. При сохранении строк фиксированной длины Firebird убирает конечные пробелы. Строки отыскиваются без избыточного расширения до объявленной длины.

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

 

CHAR(n), алиас для CHARACTER(n)

CHAR(n), алиас для CHARACTER(n), является основой символьного типа фиксированной длины, n представляет точное количество хранимых символов. Этот тип данных может хранить строки любого поддерживаемого набора символов.

! ! !

ПРИМЕЧАНИЕ. Если аргумент длины, n, в объявлении отсутствует, то предполагается CHAR(1). Допустимо объявлять односимвольные поля CHAR как просто CHAR.

. ! .

 

NCHAR(n), алиас для NATIONAL CHARACTER(n)

NCHAR (n), алиас для NATIONAL CHAR(11) , является специализированной реализацией типа CHAR(n) с предварительно установленным атрибутом набора символов iso8859_1. Естественно, недопустимо определять атрибут набора символов для столбца NCHAR, хотя последовательность сортировки - последовательность, в которой будут сортироваться символы для поиска упорядочения вывода, - может быть объявлена для столбца или домена, которые используют этот тип.

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

 

Символьные данные переменной длины

Строковые типы данных переменной длины в Firebird используются для хранения строк, длина которых может изменяться. Обязательный аргумент размера n ограничивает количество символов, которые могут храниться в столбце максимум n символами. Размер типа VARCHAR не может превышать 32 765 байтов, потому что Firebird добавляет два байта к размеру элемента для каждого объекта VARCHAR.

Выбор, хранение и поиск текстов переменной длины

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

Транспортировка в сети

До Firebird 1.5 найденные текстовые элементы данных переменной длины дополнялись на сервере до полного, объявленного размера до передачи клиенту. Начиная с Firebird 1.5, данные не дополняются. На момент написания этой книги такая возможность для текстов переменной длины не была выполнена для Firebird 1,0.x, что может повлиять на ваш выбор размера и типа столбца, если вы пишете приложения для удаленных клиентов, соединяющихся с сервером 1,0.x в медленной сети.

Хотя типы переменной длины могут хранить строки почти в 32 Кбайтах, на практике не рекомендуется использовать их для элементов данных, длиннее, чем 250 байт, особенно если их таблицы будут увеличиваться в размерах или если они часто будут субъектом запросов SELECT. Тип данных BLOB с подтипом SUB_TYPE 1 (текст) обычно лучше подходит для хранения больших строковых данных. Тексты BLOB подробно обсуждаются в следующей главе.

VARCHAR(n), алиас для CHARACTER VARYING(n)

VARCHAR(n), алиас для CHARACTER VARYING(n), является базовым строковым типом переменной длины, n представляет максимальное количество символов, которое может сохраняться в столбце. Этот тип хранит строки любого поддерживаемого набора символов. Если никакой набор символов не указан, атрибут примет значение набора символов по умолчанию, который был определен в операторе CREATE DATABASE в предложении DEFAULT CHARACTER SET. ЕСЛИ не существует набора символов по умолчанию, то столбец получит CHARACTER SET NONE.

NCHAR VARYING(n), алиас для NATIONAL CHAR VARYING(n)

NCHAR VARYING(N), алиас для NATIONAL CHAR VARYING(N), который в свою очередь является алиасом для NATIONAL.CHARACTER VARYING(N) - это специализированная реализация типа VARCHAR(n) с предварительно установленным атрибутом набора символов ISO8859_1. Недопустимо определять атрибут набора символов для столбца NCHAR VARYING, хотя последовательность сортировки - последовательность, в которой будут сортироваться символы для поиска упорядочения вывода - может быть объявлена для столбца или домена, которые используют этот тип.

 

Набор символов клиента

Что по-настоящему имеет значение в отношении наборов символов - это взаимодействие между сервером и клиентом. Клиентская библиотека Firebird должна передавать атрибут набора символов как часть параметров запроса на соединение.

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

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

Если наборы символов клиента и объекта одни и те же, то сервер предполагает, что получаемые им коды из этого набора символов, и сохраняет их без изменения. Неприятности возникают, если данные не являются такими, как об этом сообщил клиент. Когда данные выбираются, отыскиваются или восстанавливаются после резервного копирования, это приводит к ошибкам транслитерации.

Более подробную информацию об ошибках транслитерации и их исправлении см. в разд. "Транслитерация " далее в этой главе.

Приложения, подключающиеся к базе данных, должны передавать набор символов базы данных в API через блок параметров базы данных (Database Parameter Block, DPB) в параметре isc_dpb_ic_ctype. Приложение ESQL - включая утилиту isql - должно выполнить оператор SET NAMES непосредственно перед оператором CONNECT. Команда SET NAMES <набор-символов> используется для установки набора символов в утилите isql. Графический интерфейс инструментов администратора обычно предоставляет возможность выбора или явного указания клиентского набора символов.

Если вам нужно использовать язык, отличный от английского, потратьте некоторое время на изучение доступных наборов символов и выбора того, который наиболее соответствует вашим требованиям к вводу, хранению и выводу текстов. Не забудьте включить этот набор символов в атрибуты базы данных при создании базы данных. Синтаксис см. в разд. "Обязательные и необязательные атрибуты" главы 15. Список наборов символов, распознаваемых Firebird, см. в приложении 8.

 

Переопределение набора символов

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

! ! !

ВНИМАНИЕ! Когда столбцы используют значение набора символов по умолчанию для базы данных, изменение набора символов по умолчанию для базы данных повлияет только на вновь создаваемые столбцы и домены. Существующие столбцы сохранят имеющееся значение набора символов.

. ! .

 

Наборы символов Firebird

Firebird поддерживает увеличивающееся количество интернациональных наборов символов, включая 2- и 3-байтовые наборы Unicode. Во многих случаях возможен выбор последовательности подбора (сортировки). В этом разделе мы рассмотрим:

* происхождение наборов символов;

* глобальные наборы символов по умолчанию для базы данных;

* альтернативные наборы символов и последовательности сортировки для доменов и столбцов;

• последовательности сортировки для:

• текстовых значений в операциях сравнения;

• предложений ORDER BY и GROUP BY;

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

Набор символов является собранием символов, который включает, по меньшей мере, один репертуар символов. Репертуар символов является набором символов, используемым в конкретной культуре для публикаций, письменной коммуникации и - в контексте базы данных - для компьютерного ввода и вывода. Например, ISO Latin 1 является набором символов, который охватывает английский (А, В, С ... Z) и французский (А, А, А, В, С, Q, D ... Z) репертуары, делающие его полезным для обоих сообществ.

Именование наборов символов

Большинство наборов символов Firebird определены на основании стандартов и их имена близко соответствуют этим стандартам. Например, Microsoft определяет Windows 1251, a Firebird реализует его как WIN1251. Набор символов ISO8859_1 является "набором символов, определенным в стандарте ISO 8859-1, кодированным значениями, определенными в стандарте ISO 8859-1, каждое значение представлено одним 8-битовым байтом".

Алиасы

Имена алиасов наборов символов поддерживают разницу в именовании стандартов между платформами. Например, если вы найдете, что в операционной системе используется идентификатор WIN 1251 для набора символов WIN1251, вы можете использовать алиас, определенный в системной таблице RDB$TYPES, как описано в следующем разделе.

Хранение наборов символов и алиасов

Наборы символов в настоящий момент "зашиты" в базу данных с момента ее создания. Одной из системных таблиц, создаваемых автоматически, является RDB$CHARACTER_SET. Для отображения имен наборов символов с последовательностью сортировки каждого из них выполните запрос:

SELECT

RDB$CHARACTER_SET_NAME,

RDB$DEFAULT_COLLATE_NAME,

RDB$BYTES_PER_CHARACTER

FROM RDB$CHARACTER_SETS

ORDER BY 1 ;

Если требуется, алиасы помещаются в RDB$TYPES- другую системную таблицу, которая хранит список алиасов, используемых сервером базы данных. Для просмотра всех алиасов, которые были установлены во время создания базы данных, выполните следующий запрос, который фильтрует RDB$TYPES для просмотра только имен наборов символов:

SELECT

С. RDB$CHARACTER_SET_NAME,

T.RDB$TYPE_NAME

FROM RDB$TYPES T

JOIN RDB$CHARACTER_SETS С

ON C.RDB$CHARACTER_SET_ID = T.RDB$TYPE

WHERE T.RDB$FIELD_NAME = 'RDB$CHARACTER_SET_NAME'

ORDER BY 1 ;

! ! !

ПРИМЕЧАНИЕ. Для того чтобы использовать наборы символов, отличные от NONE, ASCII, OCTETS и UNICODE_FSS, необходимо иметь библиотеку fbintl в каталоге /intl корневого каталога Firebird.

. ! .

Ограничения хранения

Важно понимать, как ваш выбор набора символов влияет на хранение планируемых вами ограничений для данных. В случае столбцов CHAR и VARCHAR Firebird ограничивает максимальный объем памяти хранения любого поля в столбце значениями 32 767 и 32 765 соответственно. На самом деле требуемое фактическое количество может быть сильно ограничено.

Неиндексируемые столбцы, использующие последовательность сортировки по умолчанию, могут хранить не более (количество символов)*(количество байтов на символ) для типа данных. Например, VARCHAR(32765) с набором символов ISO_8859_1 может хранить не более 32 765 символов, тогда как при наборе символов UNICODE_FSS (который использует три байта на символ) максимальное количество 10 291 символ.

Если столбец предполагается индексировать и/или изменить предложением COLLATE, должно быть добавлено значительное количество "запасных" байтов. Даже наименее требовательный индекс - один столбец VARCHAR, использующий однобайтовый набор символов и последовательность сортировки по умолчанию - ограничен размером 252 байта для Firebird версии 1.5 и выше. Для столбцов с многобайтовыми наборами символов количество символов меньше, чем 252 / (количество байтов на символ). Многостолбцовые индексы требуют больше байтов, чем одностолбцовые, а те, которые используют последовательность сортировки не по умолчанию, требуют еще больше.

Более подробно об этих эффектах см. разд. "Последовательность сортировки и размер индекса" далее в этой главе.

! ! !

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

. ! .

Хранение столбцов BLOB, которые не являются индексируемыми, никак не ограничивается использованием набора символов.

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

Если вы не указываете набор символов по умолчанию для базы данных в объявлении CREATE DATABASE, то набор символов по умолчанию устанавливается в NONE. Набор символов NONE не предполагает никакого набора символов для текстовых столбцов, сохраняя данные точно в том виде, в каком они были введены. Если клиентское соединение не указывает набора символов, то данные также будут отыскиваться точно так, как они были введены. Алфавитно-цифровое упорядочение ограничено упорядочением кодов ASCII, а преобразование верхний/нижний регистр поддерживается только в кодах U.S.ASCII 65-90 и 97-102 соответственно.

Указывайте допустимый код набора символов в предложении DEFAULT CHARACTER SET:

CREATE DATABASE '/data/adatabase.fdb'

. . .

DEFAULT CHARACTER SET WIN1251;

Более подробную информацию об операторе CREATE DATABASE см. в главе 12.

Переопределение набора символов на уровне столбца

Атрибут набора символов может быть добавлен к индивидуальному определению домена, столбца таблицы или переменной PSQL типа CHAR, VARCHAR или BLOB SUB_TYPE 1 для перекрытия набора символов по умолчанию базы данных.

Например, следующий фрагмент скрипта создает базу данных с набором символов по умолчанию ISO8859_1 и таблицу, содержащую различные версии языка похожих данных в отдельных столбцах:

CREATE DATABASE '/data/authors.fdb' DEFAULT CHARACTER SET ISO8859_1;

CREATE TABLE COUNTRY_INTL(

CNTRYCODE BIGINT NOT NULL,

NOM_FR VARCHAR(30) NOT NULL,

/* использует набор символов по умолчанию */

NOM_EN VARCHAR(30), /* использует набор символов по умолчанию */

NOM_RU VARCHAR(30) CHARACTER SET WINI251,

NOM_JP VARCHAR(30) CHARACTER SET SJIS_0208

Другой фрагмент того же скрипта создает домен для хранения данных BLOB В наборе символов кириллицы:

CREATE DOMAIN MEMO_RU AS BLOB SUB_TYPE 1

CHARACTER SET WIN1251;

Позже в этом скрипте мы создаем таблицу, которая хранит некоторый текст в кириллице:

CREATE TABLE NOTES_RU (

DOC_ID BIGINT NOT NOLL,

NOTES MEMO_RU

);

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

CREATE PROCEDURE CONVERT_NOTES (

INPUT_TEXT VARCHAR(300) ) AS

DECLARE VARIABLE CONV_STRING WARCHAR(300)

CHARACTER SET WIN1251;

BEGIN

IF (INPUT JTEXT IS NOT NULL) THEN

BEGIN

CONV_STRING = _WIN1251 ' ' || : INPUT_TEXT;

/* использует INTRODUCER */

INSERT INTO NOTES_RU (DOC_ID, NOTES)

VALUES (GEN_ID (ANYGEN, 1) , :CONV_STRING) ;

END

END ^

Создание доменов объясняется в главе 13. Полный синтаксис оператора CREATE TABLE описан в главе 15. Объявление переменных в PSQL см. в главе 30.

Переопределение набора символов на уровне оператора

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

INTRODUCER - маркер набора символов

Маркер набора символов - также известный как INTRODUCER- состоит из имени набора символов, перед которым стоит символ подчеркивания. Он требуется для "представления" входной строки, когда приложение клиента соединено с базой данных с использованием набора символов, отличного оттого, который определен для столбца в базе данных.

Установите маркер слева от отмечаемого текстового значения. Например, маркером для ввода в UMCODE_FSS поле является _UNICODE_FSS:

INSERT INTO EMPLOYEE(Emp_ID, Emp_Name)

values(1234, _UNICODE_ESS 'Smith, John Joseph');

! ! !

СОВЕТ. Для ясности вы можете вставить пробел между маркером и строкой без какого-либо влияния на способ синтаксического анализа вводимого данного.

. ! .

Строковый литерал

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

... WHERE name = _ISO8859_1 'joe';

! ! !

СОВЕТ. Когда вы разрабатываете приложение со смешанными наборами символов, то удобно использовать маркеры, особенно если ваше приложение будет работать со многими базами данных и/или будет распространяться интернационально.

. ! .

Транслитерация

Преобразование символов из одного набора символов Firebird в другой - например, конвертирование из DOS437 в ISO8859_1 - является транслитерацией. Транслитерация в Firebird сохраняет точность символов: по определению она не подставляет никакого "заменителя" для входного символа, который не представлен в выходном наборе символов. Назначением такого ограничения является гарантия того, что возможна транслитерация одного и того же текста из одного набора символов в другой в любом направлении без потери символов в процессе транслитерации.

Ошибки транслитерации

Firebird выдает сообщение об ошибке, если символ во входном наборе не имеет точного представления в выходном наборе.

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

Исправление ошибок транслитерации

Как вы можете работать с группой символьных данных, которые вы сохранили с использованием неверного набора символов? "Трюк" заключается в использовании набора символов OCTETS в качестве "промежуточного аэродрома" между ошибочным и правильным кодированием. Поскольку OCTETS является специальным набором символов, который, не глядя, сохраняет то, что вы ему подсовываете (без транслитерации), он является идеальным для того, чтобы сделать символьные коды нейтральными в отношении кодовой страницы.

Предположим, ваша проблемная таблица имеет столбец COL ORIGINAL, который вы случайно создали с набором символов NONE, когда имели в виду CHARACTER SET WIN1251. Вы загрузили в этот столбец данные на русском языке, но каждый раз, когда вы пытаетесь получить из него данные, вы получаете противную ошибку транслитерации.

Вот что вам нужно сделать:

ALTER TABLE TABLEA

ADD COL_WIN1251 VARCHAR(30) CHARACTER SET WIN1251;

COMMIT;

UPDATE TABLEA

SET COL_WIN1251 = CAST(COL_ORIGINAL AS CHAR(30) CHARACTER SET OCTETS);

Теперь у вас есть временный столбец, созданный для хранения русских текстов, он хранит все из ваших "потерянных" текстов из неиспользуемого столбца COL ORIGINAL. Вы можете удалить столбец COL_ORIGINAL, а затем новый столбец COL_ORIGINAL С корректным набором символов. Просто скопируйте данные из временного столбца, и после подтверждения транзакции удалите временный столбец:

ALTER TABLE TABLEA

DROP COL_ORIGINAL;

COMMIT;

ALTER TABLE TABLEA

ADD COL_ORIGINAL VARCHAR(30) CHARACTER SET WIN1251;

COMMIT;

UPDATE TABLEA

SET СOL_ORIGINAL = COL_WIN1251;

COMMIT;

/* Было бы разумным сейчас посмотреть ваши данные! */

ALTER TABLE TABLEA

DROP COL_WIN1251;

COMMIT;

 

Набор символов для клиентского соединения

Когда клиентское приложение, например, isql, соединяется с базой данных, в протоколе соединения присутствует часть, которая информирует сервер о требуемом наборе символов. Набором символов соединения является нейтральный набор символов NONE, если не указано другое с использованием:

* SET NAMES во встроенном приложении или в isql;

* параметра isc_dpb_ic_ctype в блоке параметров базы данных (DPB) для API- функции isc_attach_database(). Классы RAD соединения с базой данных для Delphi, Java и других обычно представляют этот параметр как свойство.

Клиентское приложение задает набор символов до его соединения с базой данных. Например, следующая команда isql определяет, что isql использует набор символов ISO88591. По команде происходит соединение с базой данных autord.fdb из нашего предыдущего примера:

SET NAMES WIN1251;

CONNECT 'lserver:/data/authors.fdb' USER 'ALICE' PASSWORD 'XINEOHP';

 

Специальные наборы символов

Основное правило для наборов символов то, что каждый байт (пара или тройка байтов в случае многобайтовых наборов) специально определен по стандарту его реализации. Существует четыре особых исключения - NONE, OCTETS, ASCII и UNICODE FSS. В табл. 11.1 показаны специальные свойства этих наборов.

Таблица 11.1. Специальные наборы символов

ISO8859_1 (LATIN_1) и WIN1252

Набор символов ISO8859_1 часто указывается для поддержки европейских языков. ISO8859_1, также известный как LATIN1, является истинным подмножеством WIN 1252. Microsoft добавил символы в позиции, которые ISO специфицировал как не являются символами (не "неопределенные", но указанные как "не символы"). Firebird поддерживает как WIN 1252, так и ISO8859_1. Вы всегда можете выполнить транслитерацию из ISO8859_1 в WIN 1252, но транслитерация WIN 1252 в ISO8859_1 может вызвать ошибки.

Наборы символов для Microsoft Windows

Пять наборов символов поддерживают приложения клиентов Windows, такие как Paradox for Windows. Это наборы символов WIN1250, WIN1251, WIN1252, WIN1253 и WIN 1254.

Благодаря историческим связям Borland с Paradox и dBase, имена последовательностей сортировки этих наборов символов, специфичных для Paradox for Windows, начинаются с "PXW" и соответствуют языковым драйверам Paradox/dBase, поставляемым с ныне устаревшим Borland Database Engine (BDE).

Понимание наборов символов WINnnn

Последовательности сортировки PXW действительно реализуют сортировку для Paradox и dBase, включая все ошибки. Одно исключение: PXW_CSY исправлен в Firebird 1.0. Следовательно, базы данных InterBase, которые его используют, например в индексах, не являются совместимыми с Firebird.

Более подробную информацию о наборах символов Windows и сортировках Paradox for Windows см. в соответствующей документации по BDE и драйверам.

Список международных наборов символов и последовательностей сортировки, поддерживаемые Firebird, см. в приложении 8.

 

Последовательности сортировки

Каждый набор символов имеет последовательность сортировки (collate) по умолчанию, которая определяет, как символы сортируются и упорядочиваются. Последовательность сортировки определяет правила предшествования, которые Firebird использует для сортировки, сравнения и транслитерации символьных данных.

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

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

Отображение доступных последовательностей сортировки

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

SELECT

С. RDB$CHARACTER_SET_NAME,

CO.RDB$COLLATION_NAME,

CO.RDB$COLLATION_ID,

CO.RDB$CHARACTER_SET_ID,

CO.RDB$COLLATION_ID * 256+ CO.RDB$CHARACTER_SET_ID AS TEXTTYPEID

FROM RDB$COLLATIONS CO

JOIN RDB$CHARACTER_SETS С

ON CO.RDB$CHARACTER_SET_ID = C.RDB$CHARACTER_SET_ID;

Именование последовательностей сортировки

Многие имена последовательностей Firebird используют соглашение по именованию XX_YY, где XX - двухбуквенный код языка, a YY - двухбуквенный код страны. Например, DE_DE - имя последовательности для немецкого языка, используемого в Германии, FR_FR - для французского языка, используемого во Франции, FR_CA - для французского языка, используемого в Канаде.

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

В этом разделе описывается задание последовательности сортировки для наборов символов в доменах и столбцах таблиц, в строковых сравнениях, в предложениях ORDER BY и GROUP BY.

Последовательность сортировки для столбца

Когда в таблице создается столбец CHAR или VARCHAR с использованием CREATE TABLE или ALTER TABLE, последовательность сортировки для столбца может быть задана с использованием предложения COLLATE. Предложение COLLATE особенно полезно для таких наборов символов, как ISO8859_1 и DOS437, которые поддерживают множество различных последовательностей сортировки.

К примеру, следующий динамический оператор ALTER TABLE добавляет новый столбец в таблицу и задает и набор символов, и последовательность сортировки:

ALTER TABLE 'EMP_CANADIEN'

ADD ADDRESS VARCHAR(40) CHARACTER SET WIN1251 NOT NULL COLLATE PXW_CYRL;

Полный синтаксис ALTER TABLE см. В главе 16.

Последовательность сортировки для строковых сравнений

Может оказаться необходимым задать последовательность сортировки при сравнении значений CHAR или VARCHAR в предложении WHERE, если сравниваемые значения используют различные последовательности сортировки, и это влияет на результат.

Чтобы указать используемую последовательность сортировки для значения в процессе сравнения, задайте предложение COLLATE после значения. Например, следующий фрагмент предложения WHERE задает конкретную последовательность сортировки для значения столбца в левой части операции сравнения при сравнении с входным параметром:

WHERE SURNAME COLLATE PXW SYRL >= :surname;

В этом случае при несоответствии последовательностей сортировки могут быть различные кандидаты для "больше чем" при разных последовательностях сортировки.

Последовательность сортировки в критериях сортировки

Когда столбцы CHAR или VARCHAR упорядочиваются в операторе SELECT, может оказаться необходимым указать порядок сортировки для упорядочивания, особенно если столбцы в предложении упорядочивания используют различные последовательности сортировки.

Чтобы задать последовательность сортировки для использования в упорядочиваемых столбцах, в предложение ORDER BY добавьте COLLATE после имени столбца. Например, в следующем предложении ORDER BY задаются последовательности сортировки для двух столбцов:

. . .

ORDER BY SURNAME COLLATE PXW_CYRL, FIRST_NAME COLLATE PXW_CYRL;

Полный синтаксис предложения ORDER BY CM. в главе 23.

Последовательность сортировки в предложении GROUP BY

Когда столбцы CHAR или VARCHAR группируются в операторе SELECT, может оказаться необходимым указать порядок сортировки для группирования, особенно если столбцы в предложении группировки используют различные последовательности сортировки.

Чтобы задать последовательность сортировки для использования в группируемых столбцах, в предложение GROUP BY добавьте COLLATE после имени столбца. Например, в следующем предложении GROUP BY задаются последовательности сортировки для нескольких столбцов:

. . .

GROUP BY ADDR_3 COLLATE PXW_CYRL, SURNAME COLLATE PXW_CYRL, FIRST_NAME COLLATE

PXW_CYRL;

Полный синтаксис предложения GROUP BY CM. В главе 23.

Последовательность сортировки и размер индекса

Если для набора символов вы задаете недвоичную сортировку (отличную от сортировки по умолчанию), то размер индексного ключа может стать больше, чем хранимая строка, если сортировка включает правила предшествования второго, третьего или четвертого порядка.

Например, недвоичные сортировки для IS08859_1 используют полные словари с пробелами и знаками пунктуации с четырьмя порядками значений.

* Первый порядок: А отличается от В.

* Второй порядок: А отличается от А.

* Третий порядок: А отличается от а.

* Четвертый порядок: важным является тип знака пунктуации (дефис, пробел, апостроф).

Например:

Greenfly

Green fly

Green-fly

Greensleeves

Green sleeves

Green spot

Если же пробелы и знаки пунктуации трактуются как символы первого порядка, то тот же самый список будет отсортирован следующим образом:

Greenfly

Greensleeves

Green fly

Green sleeves

Green spot

Green-fly

Как недвоичные сортировки могут ограничить размер индекса

Когда создается индекс, он использует последовательности сортировки, определенные для каждого текстового фрагмента индекса. При использовании однобайтового набора символов ISO8859_1 с сортировкой по умолчанию структура индекса может содержать приблизительно 252 символа (меньше, если это многосегментный индекс). Если же вы выбираете недвоичную сортировку для ISO8859_1 (в том числе это относится к сортировке PXW_CYRL кодировки WIN1251), то структура индекса может содержать только 84 символа, несмотря на то, что символы в индексируемом столбце занимают только один байт каждый.

! ! !

ВНИМАНИЕ! Некоторые сортировки ISO8859_1, например DE_DE, требуют в среднем три байта на символ для индексируемого столбца.

. ! .

 

Пользовательские наборы символов и сортировки

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

Также можно реализовать пользовательские наборы символов и сортировки с использованием функций, определенных пользователем (UDF) для транслитерации входных данных. Сервер Firebird 1.5 автоматически использует UDF со специальными именами, чтобы их можно было распознать как наборы символов и сортировки. Имя 'USER_CHARSET_nnn' указывает набор символов, в то время как 'USER_TRANSLATE_nnn_nnn' и 'USER_TEXTTYPE_nnn' указывает набор символов плюс последовательность сортировки (nnn представляет трехсимвольное число, обычно в диапазоне от 128 до 254).

Это сложная тема, выходящая за пределы данной книги. Разработчик для fbintl2 встраиваемых пользователем наборов символов David Brookestone Schnepper создал свободно распространяемый комплект "сделай сам", который содержит пример кода С, отображения и инструкции, доступный на http://www.ibcoIlate.com. Поскольку комплект поставки содержит ясные инструкции по созданию наборов символов, он также будет вам полезным справочником, если вы планируете использовать подход UDF для реализации пользовательского набора символов.

Добавление собственных алиасов

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

Инсталляция пользовательских алиасов включает прямое добавление строки в таблицу RDB$TYPES. Получите идентификатор набора символов, для которого вы собираетесь создать алиас - в таблице RDB$CHARACTER_SETS это значение столбца RDB$CHARACTER_SET_ID - и убедитесь, что у вас правильный строковый литерал, который ваша операционная система распознает как набор символов, который вы хотите поддерживать.

Предположим, вы хотите добавить алиас для набора символов ISO8859_1, который ваша ОС сможет распознать по литералу 'LC_ISO88591'. Во-первых, получите идентификатор набора символов по запросу к таблице RDB$CHARACTER_SETS, используя утилиту isql или другой интерактивный инструмент запросов:

SELECT RDB$CHARACTER_SET_ID

FROM RDB$CHARACTER_SETS

WHERE RDB$CHARACTER_SET_NAME = 'ISO8859_1';

Этот пример вернет идентификатор набора символов "21". Затем подготовьте и выполните оператор INSERT для добавления вашего алиаса в таблицу RDB$TYPES:

INSERT INTO RDB$TYPES (

RDB$FIELD_NAME, RDB$TYPE, RDB$TYPE_NAME)

VALUES ('RDB$CHARACTER_SET_NAME', 21, 'LC_ISO88591');

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

Существует проблема типа "уловка-22", если ваша операционная система по- настоящему не может поддерживать набор символов или алиас для набора символов, который вам нужно использовать по умолчанию. Ваша база может "узнать" о вашем алиасе только после создания базы данных, когда таблица RDB$TYPES уже существует. Набор символов базы данных по умолчанию определяется в CREATE DATABASE, а в этот момент доступны только объявленные в системе алиасы. В тот момент, когда RDB$TYPES существует, уже поздно назначать набор символов по умолчанию.

Поскольку в настоящий момент Firebird не предоставляет способов изменения атрибута набора символов по умолчанию - это не поддерживается в синтаксисе ALTER DATABASE, - существует только один способ: сначала создать базу данных, а затем, до того, как что-нибудь с ней делать, установить, как был описан ваш алиас, подтвердить транзакцию и изменить напрямую заголовочную запись базы данных:

UPDATE RDB$DATABASE

SET RDB$CHARACTER_SET_NAME = 'LC_ISO88591';

COMMIT;

! ! !

ВНИМАНИЕ! Никогда не пытайтесь выполнить то же для любой базы данных, которая не является "пустой" - т. е. содержит определенные пользователем объекты.

. ! .

Пора дальше

Теперь мы переходим к типам данных, которые Firebird реализует посредством больших двоичных объектов (BLOB), включая текст, нетипизированные двоичные и пользовательские форматы и специализированные реализации BLOB, которые Firebird представляет как типы ARRAY.

 

Поддерживаемые типы BLOB

Firebird имеет два предварительно определенных типа BLOB, отличающиеся атрибутом подтипа (ключевое слово в SQL SUB_TYPE), как описано в табл. 12.1.

Таблица 12.1. Предварительно определенные подтипы BLOB

Подробнее о подтипах

Подтип BLOB является положительным или отрицательным целым, которое указывает природу данных, содержащихся в столбце. Помимо двух предопределенных типов для общего использования Firebird имеет множество подтипов, которые он применяет для внутренних целей. Все эти внутренние подтипы имеют положительные номера.

Пользовательские подтипы могут быть добавлены с отличающимися идентификаторами особых типов для объектов данных, таких как HTML, XML или текстовый процессор, картинки JPEG или PNG и т.д. - именно вам делать выбор. Отрицательные номера подтипов (от-1 до -32 768) резервируются для пользовательских подтипов.

Система подтипов BLOB также позволяет выполнять специфические преобразования одного подтипа в другой. Firebird осуществляет поддержку автоматического преобразования между парой подтипов BLOB в форме BLOB-фильтров. Фильтры BLOB являются специальным видом внешних функций с единственным назначением: получение объекта BLOB одного формата и преобразование его в объект BLOB другого формата. Возможно создание BLOB-фильтра для преобразования между пользовательским (отрицательным) и предварительно определенным подтипами - обычно TEXT.

Объектный код для BLOB-фильтров размещается в библиотеках коллективного доступа. Фильтр, вызываемый при необходимости динамически, распознается на уровне базы данных (не сервера) при его объявлении в метаданных:

DECLARE FILTER <имя-фильтра>

INPUT_TYPE <подтип> /* идентифицирует тип преобразуемого объекта */

OTPUT_TYPE <подтип> /* идентифицирует тип создаваемого объекта */

ENTRY_POINT '<имя-точки-входа>' /* имя экспортируемой функции */

MODULE_NAME '<имя-внешней-библиотеки>';

/* имя библиотеки BLOB-фильтра */

! ! !

ПРИМЕЧАНИЕ. Написание и использование BLOB-фильтров выходит за пределы тем настоящего руководства. Информацию по этой теме можно найти в базах знаний Firebird.

. ! .

Firebird не проверяет тип или формат данных BLOB. При планировании их хранения вы должны создать такой код вашего приложения, чтобы формат данных был согласован с их подтипом, неважно предварительно определенным или пользовательским.

 

Сегменты BLOB

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

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

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

Примеры синтаксиса

Следующий оператор определяет два столбца BLOB: BLOB1 подтипа 0 (по умолчанию) и BLOB2 подтипа 1 (TEXT, с набором символов по умолчанию):

CREATE TABLE TABLE2

(BLOB1 BLOB, /* SUB_TYPE 0 */

BLOB2 BLOB SUB_TYPE 1);

Следующий оператор определяет домен, являющийся текстовым BLOB для хранения текстов в наборе символов ISO8859_1:

CREATE DOMAIN MEMO

BLOB SUB_TYPE TEXT /*BLOB SUB_TYPE 1 */

CHARACTER SET ISO8859_1;

Фрагмент кода SQL показывает, как объявляется локальная переменная BLOB в модуле PSQL:

CREATE PROCEDURE ...

. . .

DECLARE VARIABLE AMEMO BLOB SUB_TYPE 1;

Размер сегмента

Когда в таблице определяется столбец BLOB, определение может включать ожидаемые размеры сегментов, которые будут записываться в столбец. Значение по умолчанию - 80 байт - совершенно случайное. Говорят, что такой размер был выбран, потому что это в точности длина строки текстового дисплея!

Установка размера сегмента не влияет на производительность при обработке BLOB на сервере Firebird: сервер совсем его не использует. Для приложений DSQL - которые пишет большинство людей - вы можете просто игнорировать его или, если это важно, установите его в некоторое значение, подходящее буферу, в котором ваше приложение сохраняет данные BLOB.

Для операций DML, выполняемых через API - SELECT, INSERT и UPDATE - длина сегмента указывается явно и может быть любого размера вплоть до максимума в 32 767 байт. Повторно используемые классы, драйверы и компоненты для таких сред разработки, как Delphi, C++ и Java, обычно сами заботятся о сегментации BLOB в их внутренних функциях и процедурах (например, в IBX и FIBPlus размер сегмента для чтения и записи BLOB равен 16 Кбайт и может быть изменен только глобально).

Встроенные приложения

В базах данных, используемых во встроенных приложениях, - здесь мы говорим о приложениях ESQL, написанных для обработки препроцессором gpre, - размер сегмента должен быть объявлен для указания максимального количества байтов, которое приложение собирается записать в любой сегмент столбца. Обычно приложение ESQL не должно ожидать записи сегмента, большего, чем указанная длина сегмента, определенная в таблице; получение такого сегмента переполняет внутренний буфер сегмента и разрушает память. Полезнее указывать относительно большой сегмент для уменьшения количества вызовов при поиске данных BLOB.

Следующий оператор создает два столбца BLOB: BLOBI С размером сегмента по умолчанию 80 и BLOB2 с заданным размером сегмента 1024:

CREATE.TABLE TABLE2 (BLOBI BLOB SUB_TYPE 0,

BLOB2 BLOB SEGMENT SUB_TYPE TEXT SEGMENT SIZE 1024);

В следующем фрагменте кода ESQL приложение вставляет сегмент BLOB. Длина сегмента указана в переменной включающего языка segment_iength:

INSERT CURSOR BCINS VALUES (:write_segment_buffer :segment_length);

 

Операции с полями BLOB

Поле BLOB никогда не обновляется. Каждое обновление, которое "изменяет" BLOB, приводит к конструированию нового BLOB, создавая и новый BLOB ID. Первоначальный BLOB становится устаревшим, когда подтверждаются обновления.

Столбец BLOB можно проверять на NULL/NOT NULL, но не существует внутренних функций сравнения одного BLOB С другим или сравнения BLOB со строкой. Некоторые UDF для BLOB, доступные на сайтах сообщества, включают сравнения двух BLOB на равенство.

Невозможно выполнить конкатенацию двух BLOB или BLOB со строкой (без использования сторонних UbF).

Входная строка для столбца BLOB

При получении данных для ввода столбцов BLOB для операций INSERT или UPDATE Firebird может взять строку как исходную и преобразовать ее в BLOB, например:

INSERT INTO ATABLE (PK, ABLOB) VALUES (99, 'This is some text.');

Обратите внимание, что передача хранимой процедуре строки как входного аргумента, который был определен как BLOB, вызывает исключение. Например, следующее не будет выполнено:

CREATE PROCEDURE DEMO (INPUTARG BLOB SUB_TYPE I) AS

BEGIN

END ^ COMMIT ^

EXECUTE PROCEDURE DEMO('Show us what you can do with this!')

Вместо этого выполните одно из следующих:

* определите ваш входной аргумент как VARCHAR, и пусть ваша процедура подставляет эту строку в операторы INSERT или UPDATE;

* пусть ваша клиентская программа выполняет конвертирование строки в текст BLOB. Это предпочтительное решение, если длина строки не известна.

 

Когда использовать типы BLOB

BLOB более предпочтительны, чем символьные типы, для хранения текстовых данных неопределенно большой длины. Поскольку он преобразуется в "бессмысленные фрагменты", к нему не относится ограничение размера строк в 32 Кбайта, пока клиентское приложение реализует подходящие техники передачи его в требуемом сервером формате для его сегментирования.

Поскольку данные BLOB хранятся вне обычной строки данных, они не загружаются автоматически, когда выбрана строка данных. Клиент запрашивает эти данные через BLOB ID. Следовательно, здесь имеется большой "выигрыш" по времени выборки строк с помощью SELECT по сравнению с трафиком, когда используются строковые типы для хранения больших текстовых элементов. С другой стороны, некоторые разработчики могут рассматривать это как недостаток, который требует дополнительной реализации "выборки по требованию".

При принятии решения об использовании BLOB для нетекстовых данных возникает ряд других вопросов. Удобство хранения изображений, звуковых файлов и полных документов должно быть сбалансировано с дополнительными расходами при создании резервных копий базы данных. Может оказаться неразумным стремление хранить большое количество огромных объектов, которые никогда не будут изменяться.

Безопасность

Идея о том, что большие двоичные и текстовые объекты являются более защищенными, когда хранятся в BLOB, чем когда хранятся в файлах файловой системы, является в некоторой мере иллюзией. Конечно, к ним несколько сложнее получить доступ из инструментов конечного пользователя. Однако в настоящий момент привилегии базы данных не применимы к типам BLOB и ARRAY вне контекста таблиц, с которыми они связаны. Не будет абсурдным предположить, что "злобные хакеры", которые получают доступ к файлу базы данных, смогут написать код приложения, который будет сканировать файл в поисках BLOB ID и читать напрямую данные из базы, как это делают внешние функции BLOB.

 

Типы ARRAY и SQL

Поскольку в Firebird не существует никакого синтаксиса динамического SQL для обработки типов ARRAY, выполнение DML и поиск таких типов из интерфейсов динамического SQL (DSQL) не является простым делом. API Firebird содержит структуры и функции, позволяющие динамическим приложениям работать с ними напрямую. Некоторые компоненты доступа к данным RAD (например, iBObject, использующиеся в продуктах Borland Delphi и Kylix) содержат классы, инкапсулирующие эту функциональность API в виде свойств и методов клиентской стороны.

ESQL, который не использует структуры и вызовы функций API, поддерживает некоторый статический синтаксис SQL для обработки типов ARRAY и интеграции их с массивами, объявленными во включающем языке.

Для динамических и статических приложений есть подходящее, хотя и не всегда осуществимое решение: чтение данных массива в хранимой процедуре и возвращение значений в том виде, в каком клиентское приложение может их использовать. Позже в разд. "Ограниченный доступ динамического SQL" будет приведен пример.

 

Когда использовать тип массива

Использование массивов является подходящим, когда:

* элементы данных естественно принимают вид множества данных одного типа;

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

* к каждому элементу также должен быть индивидуальный доступ;

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

 

Подходящие типы элементов

Массивы могут содержать элементы любого поддерживаемого Firebird типа за исключением BLOB. Массивы массивов не поддерживаются. Все элементы конкретного массива имеют один и тот же тип данных.

 

Определение массивов

Массив может быть определен как домен (с использованием CREATE DOMAIN) или как столбец в операторе CREATE TABLE или ALTER TABLE. Определение домена или столбца как массива похоже на определение любого другого такого объекта, здесь только добавляется указание размерности массива. Размерность массива заключается в квадратные скобки и следует за спецификацией типа данных.

Например, следующий оператор определяет обычный символьный столбец и столбец в виде одноразмерного символьного массива, содержащего восемь элементов:

CREATE TABLE ATABLE (ID BIGINT,

ARR_CHAR(14)[8]Трудно определить, какой возможен максимальный размер баз данных Firebird. Пользователи сообщают о базах данных в 900 Гбайт, которые еще "продолжают расти".
CHARACTER SET OCTETS);

/* хранит 1 строку по 8 элементов */

 

Многомерные массивы

Firebird поддерживает многомерные массивы размерностью от 1 до 16. Например, следующий оператор определяет три столбца целочисленных массивов с двумя, тремя и четырьмя размерностями:

CREATE TABLE BTABLE (

/* хранит 4 строки по 5 элементов = 20 элементов */

ARR_INT2 INTEGER[4,5],

/* 6 уровней, по 4 строки по 5 элементов = 120 элементов */

ARR_INT3 INTEGER [4,5,6],

/* 7 ярусов, по 6 уровней в 4 строки по 5 элементов = 840 элементов */

ARR_INT6 INTEGER[4,5,6,7] ) ;

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

Задание диапазона значений индексов для размерностей

Размерности массивов в Firebird задаются в виде верхней и нижней границ, называемых списком индексов. По умолчанию размерности основаны на 1 - первый элемент массива из n элементов имеет индекс 1, второй элемент имеет индекс 2, а последний элемент индекс n. Например, следующий оператор создает таблицу со столбцом, который является массивом четырех целых:

CREATE TABLE TABLEC (ARR_INT INTEGER[4]Заметьте, однако, что пользовательские библиотеки внешних функций не являются переносимыми между платформами. Необходимо создавать версии этих библиотек для каждой платформы, на которой может располагаться база данных. Все платформы, поддерживающие Windows, могут использовать те же библиотеки Windows; библиотеки разделяемых объектов для платформ POSIX не обязательно будут выполняться на всех платформах POSIX.
);

Индексы этого массива 1, 2, 3 и 4.

Пользовательские (явные) границы индексов

Пользовательская установка верхней и нижней границы может быть явно определена для каждой размерности массива при создании столбца ARRAY. Например, программисты С и Pascal, знакомые с массивами, основанными на нуле, могут создавать столбцы массивов с нулевой нижней границей для полного соответствия со структурой массивов в коде приложения.

Требуются нижняя и верхняя граница размерности при определении пользовательских границ. Используется следующий синтаксис:

[ нижняя:верхняя]

Следующий пример создает таблицу с одноразмерным, основанным на нуле столбцом массива:

CREATE TABLE TABLED

(ARR_INT INTEGER[0:3]);

/* индексы 0, 1, 2, и 3. */

Каждое задание границ размерности отделяется от следующего запятой. Например, следующий оператор создает таблицу со столбцом массива размерности два, где обе размерности основаны на нуле:

CREATE TABLE TABLEE

(ARR_INT INTEGER[0:3, 0:3]);

 

Хранение столбцов массивов

Как и другие типы данных, реализованные как BLOB, Firebird хранит идентификатор массива в столбце таблицы базы данных, который ссылается на страницу, содержащую фактические данные.

Обновления

Как и в случае других типов BLOB, сервер Firebird не может последовательно просматривать индивидуальные элементы при условном обновлении. При этом в одиночном операторе DML возможно изолировать один элемент или набор последовательных элементов, называемый фрагментом, и передавать этот фрагмент для обновления.

Добавления

Оператор INSERT не может оперировать с фрагментами. Когда строка добавляется в таблицу, содержащую столбцы массивов, необходимо конструировать и заполнять массив целиком до передачи его INSERT.

 

Доступ к данным массива

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

Дескриптор массива

API предоставляет структуру дескриптора массива для передачи серверу массива или фрагмента массива для чтения и записи в базу данных. Эта структура для программистов представлена в файле ibase.h (добавлены комментарии):

typedef struct {

short array_bound_lower;

/* нижняя граница массива или фрагмента */

short array_bound_upper;

/* верхняя граница массива или фрагмента */

} | SC_ARRAY_BOUND;

typedef struct {

unsigned char array_desc_dtype;

/* тип данных элементов */

char array_desc_scale;

/* масштаб для числовых типов */

unsigned short array_desc_length;

/* длина элемента массива в байтах */

char array_desc_field_name[32]Существует море литературы, содержащей описания техник эффективного анализа задач бизнеса для проектировщика реляционных баз данных, размышления об уровне нашей профессиональности. Автор особенно рекомендует Data Modeling Essentials: Analysis, Design and Innovation, 2nd Edition by Graeme C. Simsion (Coriolis, 2000).
;

/* идентификатор столбца */

char array_desc_relation_name[32]Существует море литературы, содержащей описания техник эффективного анализа задач бизнеса для проектировщика реляционных баз данных, размышления об уровне нашей профессиональности. Автор особенно рекомендует Data Modeling Essentials: Analysis, Design and Innovation, 2nd Edition by Graeme C. Simsion (Coriolis, 2000).
;

/* идентификатор таблицы */

short array_desc_dimensions;

/* количество размерностей */

short array_desc_flags;

/* 0=порядок по строкам, 1=порядок по столбцам */

ISC_ARRAY_BOUND array_desc_bounds[16]Хранимыми типами являются SMALLINT, INTEGER или BIGINT в зависимости от объявлен-
;

/* верхняя и нижняя границы для размерности до 16 */

} ISC_ARRAY_DE SC;

Документ по InterBase 6 "API Guide" (Руководство no API), опубликованный Borland, содержит детальные инструкции по манипулированию массивами с помощью структур API.

 

Ограничения доступа динамического SQL

Следующий пример является простой демонстрацией того, как приложение DSQL может получить ограниченный доступ к фрагменту массива через хранимую процедуру:

create procedure getcharslice(

low_elem smallint, high_elem smallint)

returns (id integer, list varchar(50))

as

declare variable i smallint;

declare variable string varchar(10);

begin

for select a1.ID from ARRAYS a1 into :id do

begin

i= low_elem;

list = '' ;

while (i <= high_elem) do

begin

select a2.CHARARRAY[:i] from arrays a2

where a2.ID = :id

into : string;

list = list||string;

if (i < high_elem) then

list = list ||',';

i = i + 1;

end

suspend;

end

end

Пора дальше

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

 

Идентификатор домена

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

CREATE DOMAIN D_TYPE_IDENTIFIER...

CREATE DOMAIN DESCRIPTION_D. . .

 

Тип данных домена

Tun данных является единственным обязательным атрибутом, который должен быть установлен для домена - все другие атрибуты необязательны. Он задает тип данных SQL, который будет применен для столбца, определенного с использованием этого домена. Может быть применен любой тип данных Firebird. Нельзя использовать домен как тип данных для другого домена.

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

CREATE DOMAIN DEPTARRAY AS CHAR(31) [4:5];

Следующий оператор создает домен BLOB текстового подтипа, которому назначен набор символов, перекрывающий набор символов базы данных по умолчанию. Фактически он создает специализированный тип примечания для хранения текста на японском языке:

CREATE DOMAIN DESCRIPT_JP AS BLOB SUB_TYPE TEXT

CHARACTER SET SJIS;

 

Атрибут DEFAULT

Домен может определять значение по умолчанию, которое сервер будет использовать при добавлении новой строки, если оператор INSERT не содержит этот столбец в списке столбцов. Значения по умолчанию могут сэкономить время и избавить от ошибок в процессе ввода данных. Например, для столбца DATE возможным значением по умолчанию может быть текущая дата, а для столбца userName (имя пользователя) можно указать контекстную переменную CURRENT_USER.

Значение по умолчанию может быть:

* константой. Значением по умолчанию является заданная пользователем строка, числовое значение или значение даты - часто используется для помещения "нулевого значения" в столбец, куда не могут помещаться пустые значения (NULL);

* CURRENT_TIMESTAMP, CURRENT_DATE, CURRENT_TIME или предварительно определенный литерал даты Firebird (см. главу 10);

* USER, CURRENT_USER или CURRENT_ROLE (если применяются роли);

* CURRENT_CONNECTION или CURRENT_TRANSACTION.

! ! !

ПРИМЕЧАНИЕ. Возможно указание в качестве значения по умолчанию NULL. Хотя это излишне, поскольку столбцы, допускающие пустое значение, в любом случае инициализируются по умолчанию значением NULL. Более того, явное указание значения по умолчанию NULL может привести к конфликтам, если столбец, использующий домен, должен быть определен с ограничением NOT NULL (CM. разд. "Атрибут NOT NULL" далее в этой главе).

. ! .

Следующий оператор создает домен, который должен иметь положительное значение больше 1000. Если в операторе INSERT не указан столбец, созданный на основе этого домена, столбцу будет назначено значение по умолчанию 9999:

CREATE DOMAIN CUSTNO

AS INTEGER

DEFAULT 9999

CHECK(VALUE > 1000);

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

Когда значения по умолчанию не работают

Распространенная ошибка предполагать, что значение по умолчанию будет использовано, когда Firebird получает значение NULL в столбце, имеющем значение по умолчанию. Чтобы быть уверенным в правильном использовании значений по умолчанию, нужно понимать, что значение по умолчанию будет применено:

* только при добавлении новой строки;

* только если оператор INSERT не включает столбец со значением по умолчанию в списке столбцов.

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

 

Атрибут NOT NULL

Включите этот атрибут в описание домена, если вы хотите, чтобы все столбцы, создаваемые на основе этого домена, имели непустое значение.

NULL - который является не значением, а состоянием, - всегда будет недопустимым для любого столбца, имеющего атрибут NOT NULL. Детальное обсуждение NULL см. в разд. "Рассмотрение NULL" главы 21.

! ! !

ВНИМАНИЕ! Вы не можете переопределить атрибут NOT NULL для домена. Рассмотрите преимущества невключения его в состав атрибутов домена, оставляя, таким образом, возможность добавить этот атрибут при определении столбца.

. ! .

 

Условия CHECK

Ограничение CHECK предоставляет атрибуты домена, ограничивающие содержимое данных, которое может быть сохранено в столбцах, использующих домен. Ограничение CHECK задает условие поиска (условие-поиска-домена), которое должно быть истинным до того, как данные могут быть помещены в эти столбцы.

Вот синтаксис ограничений CHECK:

<условие-поиска-домена> =

VALUE <оператор>

| VALUE [NOT] BETWEEN AND

| VALUE [NOT] LIKE [ESCAPE ]

| VALUE [NOT] IN ( [, ...])

| VALUE IS [NOT] NULL

| VALUE [NOT] CONTAINING

| VALUE [NOT] STARTING [WITH]

I(<условие-поиска-домена>)

I NOT<условие-поиска-домена>

<условие-поиска-домена> OR <условие-поиска-домена>

| <условие-поиска-домена> AND <условие-поиска-домена>

<оператор> ={=|<|>I<=|>=|!<|!>|<>|!=}

Ключевое слово VALUE

VALUE является заполнителем для любой константы, значения переменной или результата выражения, которые могут быть подставлены в синтаксисе SQL для сохранения данных в столбце, использующем домен. Ограничение CHECK указывает, что VALUE должно проверяться на ограничения, определенные в условиях. Если проверка не соответствует, то вызывается исключение.

Если значение NULL допустимо, то правило должно учитывать этот факт в ограничении CHECK, например:

CHECK ((VALUE IS NULL) OR(VALUE > 1000));

Следующий оператор создает домен, который запрещает вводить значение 1000 и меньше, при этом он также неявно запрещает NULL во множестве допустимых значений:

CREATE DOMAIN CUSTNO

AS INTEGER

CHECK(VALUE > 1000);

Следующий оператор ограничивает VALUE одним из четырех заданных значений:

CREATE DOMAIN PRODTYPE

AS VARCHAR(8) NOT NULL

CHECK(VALUE IN ('software', 'hardware', 'other', 'N/A'));

Условие проверки может быть выполнено в виде поиска указанного шаблона во вводимой строке. Например, следующее правило проверяет наличие круглых скобок в коде региона (например, (09)438894749):

CREATE DOMAIN TEL_NUMBER

AS VARCHAR (18)

CHECK(VALUE LIKE '(0%)%');

Подробнее о строковых шаблонах, которые вы можете использовать в выражениях, см. в примечаниях к оператору LIKE в разд. "Операторы SQL" главы 21.

Множество условий CHECK

Домен может иметь только одно предложение CHECK, однако множество условий может быть включено в это предложение с помощью операторов AND (И - конъюнкция) и OR (ИЛИ - дизъюнкция). Позаботьтесь о необходимых скобках в выражениях условий, чтобы исключить получение логических исключений при подготовке оператора DDL.

Например, следующий оператор будет ошибочным:

create domain rhubarb as varchar(20)

check(VALUE is not null) and(VALUE starting with 'J');

Он вызовет исключение с сообщением "token unknown" на слове "and". Правильный оператор заключает весь список условий во внешние скобки:

create domain rhubarb as varchar(20)

check ((value is not null) and(VALUE starting with 'J'));

! ! !

ПРИМЕЧАНИЕ. Предыдущий оператор проверяет, чтобы входное значение не было NULL. Это замечательно, однако использование ограничения NOT NULL напрямую является более мощным средством для интерфейса приложения. API может информировать клиентское приложение во время подготовки (prepare) об ограничении NOT NULL, В ТО время как триггеры проверки CHECK не будут вызываться, пока запрос DML не будет фактически отправлен на сервер.

. ! .

Подробности о STARTING WITH и других используемых в выражениях операторах SQL см. в главе 21.

Ограничение CHECK не может быть переопределено в определении столбца, хотя столбец может расширить использование ограничения CHECK домена, добавив свои собственные условия.

Зависимости в ограничениях CHECK

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

Конечно, домены не могут ссылаться на другие домены. При этом почти всегда возможно неудачное решение определять домен, который ссылается на столбец существующей таблицы. Например:

create domain rather_silly as char(3)

check(VALUE in (select substring(registration from 1 for 3)

from aircraft));

Концептуально использование выражений в доменах не является столь дикой идеей. Firebird позволяет это, однако не вникает в подробности и понимает такую конструкцию буквально, что является проблемой проектирования, а не проблемой используемой функциональности.

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

Отношения внешнего ключа существуют повсюду, в то время как область действия условия CHECK ограничивается вводом данных.

Ограничения CHECK с зависимостями внутри таблицы будут отменены при восстановлении базы данных из резервной копии, Они будут "молча" отменены при выборе данных, поскольку таблицы зависимостей не будут еще созданы. Чтобы сделать их опять действующими, нужно переустановить их вручную. Реализация таких проверок на уровне домена имеет потрясающие последствия.

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

! ! !

СОВЕТ. Другим пониманием данной техники является сложность (или невозможность) для вспомогательных программ извлекать непробиваемые бомбами скрипты SQL из системных таблиц. Может наступить такое время, когда ваша работа усложнится из-за необходимости правильного извлечения скриптов SQL из базы данных!

. ! .

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

 

Атрибут CHARSET/CHARACTER SET

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

 

Атрибут COLLATE

Предложение COLLATE в операторе создания домена задает явную последовательность сортировки для доменов CHAR и VARCHAR. Вы должны выбрать порядок сортировки, который поддерживается набором символов, объявленным наследуемыми и предполагаемым для домена.

Синтаксис определения COLLATE см. в главе 11. Список последовательностей сортировки, доступных для каждого набора символов, см. в приложении 8.

 

Пример

В некоторой базе данных есть домен SYSUSER, размером до 31 символа, имеющий значение по умолчанию, получаемое из контекстной переменной CURRENT_USER:

CREATE DOMAIN SYSUSER AS VARCHAR(31) DEFAULT CURRENT_USER;

Объявляемая таблица содержит столбец UPDATED_BY, который использует домен

SYSUSER:

CREATE TABLE LOANS (

LOAN_DATE DATE,

UPDATED_BY SYSUSER,

LOAN_FEE DECIMAL(15,2));

Клиент содержит оператор INSERT для таблицы LOANS:

INSERT INTO LOANS (LOAN_DATE, LOAN_FEE)

VALUES (116-MAY-20041, 10.75);

Поскольку этот оператор не содержит столбец UPDATED BY в списке столбцов, Firebird автоматически задает имя текущего пользователя ALICEFBIRD:

SELECT * FROM LOANS;

вернет

16-MAY-2004 ALICEFBIRD 10.75

! ! !

ПРИМЕЧАНИЕ. Здесь уместно напомнить, что значения по умолчанию для домена и столбца применяются только при добавлении и только если столбец, имеющий значение по умолчанию, отсутствует во входном списке оператора INSERT. Триггеры имеют более надежные способы реализации значений по умолчанию. Техники обсуждаются в главе 31.

. ! .

 

Переопределения в доменах

Столбцы, созданные с использованием доменов, могут переопределять некоторые наследуемые от домена атрибуты, заменяя наследуемый атрибут эквивалентным предложением атрибута. Определение столбца также может добавлять другие атрибуты. В табл. 13.1 описано, какие атрибуты могут, а какие не могут быть переопределены.

Таблица 13.1. Переопределение атрибутов доменов и столбцов

Следующий оператор демонстрирует, как расширяется список атрибутов столбца, основанного на домене, созданного в одном из предыдущих примеров:

CREATE DOMAIN TEL_NUMBER

AS VARCHAR(18)

CHECK(VALUE LIKE '(0%)%');

Скажем, мы хотим определить таблицу, содержащую столбец с номером телефона. Нам нужны атрибуты домена, но нам также необходимо обеспечить, чтобы нецифровые символы вводились в верхнем регистре:

CREATE TABLE LIBRARY_USER (

USER_ID INTEGER NOT NULL.

. . . <другие столбцы>,

PHONE_NO TEL_NUMBER,

CONSTRAINT CHK_TELNUM_UPPER

CHECK (PHONE_NO = UPPER(PHONE_NO))

);

Теперь у нас есть дополнительная проверка CHECK для этого столбца. Следующий оператор:

INSERT INTO LIBRARY_USER VALUES (USER_ID, PHONE_NO)

VALUES (99, '(09) 43889 wish');

будет ошибочным, потому что дополнительное ограничение CHECK требует, чтобы телефонный номер был '(09) 43889 wish'.

 

Когда домены не работают

Домен не может быть использован:

* в функции CAST (<имя_домена> AS <другой_тип>);

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

* при объявлении типа данных локальной переменной в триггере или хранимой процедуре;

* при определении типа данных элементов массива. При этом сам домен может быть массивом.

 

Примеры

Этот оператор устанавливает новое значение по умолчанию для домена BOOK_GROUP:

ALTER DOMAIN BOOK_GROUP SET DEFAULT -1;

В следующем операторе имя домена BOOK_GROUP заменяется на PUBL_GROUP:

ALTER DOMAIN BOOK_GROUP TO PUBL_GROUP;

 

Ограничения на изменение типов данных

Предложение TYPE в ALTER DOMAIN позволяет заменить тип данных на другой разрешенный тип данных. Разрешенные типы преобразований см. на рис. 8.1.

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

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

Следующий оператор меняет тип данных домена BOOK_TITLE С CHAR(80) на VARCHAR(100) :

ALTER DOMAIN BOOK_TITLE TYPE VARCHAR(100);

 

Язык определения данных

Основные структуры базы данных - ее таблицы, просмотры и индексы - создаются с использованием подмножества языка SQL Firebird, известного как язык определения данных (Data Definition Language, DDL). Оператор DDL начинается с одного из ключевых слов CREATE, ALTER, RECREATE или DROP, которые означают создание, изменение, пересоздание или удаление одного объекта, соответственно. База данных, ее объекты, правила и отношения объединяются для формирования структуры реляционной базы данных.

 

Системные таблицы

Firebird хранит метаданные в множестве таблиц, которые он создает прямо в базе данных, - в системных таблицах. Идентификаторы всех системных таблиц начинаются с символов "RDB$". Например, таблица, которая хранит определения и другую информацию о структурах всех таблиц в вашей базе данных, называется RDB$RELATIONS. Связанная с ней таблица RDB$RELATION_FIELDS хранит информацию и описания всех столбцов в каждой таблице.

Такая "база данных в базе данных" является высоко нормализованной. Операторы DDL разработаны для выполнения безопасных операций с таблицами метаданных и в полном соответствии с каскадными эффектами.

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

! ! !

ВНИМАНИЕ! Не рекомендуется пренебрегать операторами DDL и самостоятельно изменять системные таблицы с помощью кода приложений или через интерактивные инструменты. Системные таблицы являются "мета-метаданными" любой базы данных. Любое вмешательство человека, скорее всего, приведет к непредсказуемым повреждениям.

. ! .

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

 

Описание и анализ

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

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

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

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

 

Модель данных <> база данных

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

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

 

Одна база данных или много?

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

При проектировании принимайте во внимание, что Firebird не поддерживает запросы, соединяющие или объединяющие таблицы из различных баз данных. При этом он поддерживает одновременные запросы к множеству баз данных в контексте одной транзакции и при двухфазном ее подтверждении. Таким образом, приложения могут выполнять задачи, которые работают с образами данных из двух и более баз данных и выполняют операторы DML к одной базе данных, используя данные, прочитанные из другой. Подробности о транзакциях с несколькими базами данных и о двухфазном подтверждении см. в главе 27.

 

Физические объекты

Таблицы

Таблица базы данных обычно визуализируется в виде двумерного блока, состоящего из столбцов (вертикальная размерность) и строк (горизонтальная размерность). Хранимые атрибуты индивидуальных элементов данных задаются в столбцах (обычно связанных с или зависящих от другого столбца) и строках. Таблица может иметь любое количество строк (до 232) или совсем ни одной строки. Хотя каждая строка в одной таблице совместно использует спецификации ее столбцов с любой другой строкой, строки не зависят от других строк в той же таблице.

! ! !

СОВЕТ. Firebird поддерживает техники реализации ссылающихся на себя таблиц - структура строк, которая задает зависимости между строками в той же таблице. Подробности см. в разд. "Ссылающиеся на себя отношения" главы 17.

. ! .

Файлы и страницы

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

В рамках файла сервер Firebird управляет блоками диска одного размера, называемыми страницами базы данных. Он управляет некоторыми различными "типами" страниц в соответствии с хранимыми типами данных - например, обычные столбцы таблицы, BLOB, индексы. Когда требуется, сервер размещает новый блок в файловой системе хоста. Все страницы независимо от типа имеют одинаковый размер. Размер страницы должен быть указан в операторе CREATE DATABASE. Он может быть изменен только при выполнении резервного копирования и восстановления базы данных с новым размером страницы при использовании утилиты gbak.

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

Столбцы и поля

Обобщенно, столбец является совокупностью атрибутов, определяющих элемент данных, который может быть сохранен в одной указанной ячейке в структуре строки таблицы слева направо. При этом столбцы фактически не существуют в таблицах базы данных. Каждый раз, когда запрос обращается к серверу, этот запрос задает набор столбцов и одну или более операций, выполняемых над этими столбцами. Столбцы не обязательно должны располагаться в том же порядке слева направо, как они были определены в таблице. Например, оператор SELECT FIELD3, FIELD1, FIELD2 FROM ATABLE;

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

Некоторые люди используют термин "поле" вместо столбца, например: "У меня есть таблица TABLEI, содержащая три поля". Часто книги по реляционным базам данных не одобряют использование "поле" как замена для "столбец", предпочитая использовать "поле" в смысле "значение в столбце" или "ссылка на столбец".

В этой книге "поле" используется только как термин для обобщения концепции столбца, аргумента и локальной переменной и для ссылок на выходные элементы, создаваемые во время выполнения. "Столбец" используется для ссылок на физические столбцы, определенные для таблиц.

Ключи

Первичный ключ

Основной частью процесса проектирования базы данных является выделение в логической модели базы данных для каждой таблицы одного уникального столбца или структуры из нескольких столбцов, которая отличает каждую строку от любой другой строки в таблице. Такой уникальный столбец или комбинация столбцов является логическим первичным ключом (primary key). Когда вы создаете вашу физическую модель, вы используете ограничение PRIMARY KEY, чтобы сообщить СУБД, какой столбец или столбцы формируют такую уникальную идентификационную структуру. На таблицу вы можете определить только одно ограничение PRIMARY KEY. Синтаксис рассматривается в разд. "Ограничения" главы 16.

Другие уникальные ключи

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

Внешние ключи

"Кабелями", которые делают реляционную базу данных "реляционной", являются внешние ключи (foreign key). Это столбец или структура столбцов, которая в вашей модели данных является стороной "многие" в отношении один-ко-многим. При физическом проектировании внешний ключ соответствует столбцу или структуре столбцов первичного ключа таблицы стороны "один" в этом отношении.

В следующей простой модели для примера детальные строки заказа связаны с заголовком заказа через ключ ORDER_NUMBER.

Рис. 14.1. Простая связь

Такая модель требует, чтобы каждая строка заголовка имела уникальный ORDER_NUMBER и существовала, по меньшей мере, одна детальная строка заказа для каждой заголовочной строки заказа. Другие правила могут применяться к факту существования и к связи. Firebird предоставляет мощные процедуры триггеров для установки, согласования и применения правил к отношениям. Дополнительно он может автоматизировать множество типичных правил управления отношениями, включая ограничение FOREIGN KEY С дополнительными аргументами действий. Основой для такого ограничения являются сгенерированные системой триггеры ссылочной целостности. Поддержка ссылочной целостности в Firebird вкратце обсуждалась ранее в разд. "Ссылочная целостность" и будет детально рассмотрена в главе 17.

Суррогатные ключи

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

CREATE TABLE PERSON {

FIRST_NAME VARCHAR(30) NOT NULL,

LAST NAME VARCHAR(50) NOT NULL,

PHONE_NUMBER VARCHAR(18) NOT NULL,

ADDRESS_1 VARCHAR(50),

. . . );

Проектировщик принимает решение, что комбинация (FIRST_NAME, LAST_NAME, PHONE NUMBER) является хорошим кандидатом для первичного ключа. Люди могут использовать один и тот же телефонный номер, но весьма маловероятно, что два человека с одинаковыми именем и фамилией будут использовать один и тот же номер телефона, верно? Таким образом, проектировщик делает следующее:

ALTER TABLE PERSON

ADD CONSTRAINT PK_PERSON PRIMARY KEY

(LAST_NAME, FIRST_NAME, PHONE_NUMBER) ;

Первая проблема с этим первичным ключом в том, что каждый элемент имеет смысл. Каждый элемент поддерживается человеком и может быть изменен или записан с ошибками. Два ключа ('Smith', 'Mary', '43889474') и ('SMITH', 'Mary', '43889474') Не являются одинаковыми и оба могут быть помещены в эту таблицу. Какая запись будет изменена, если магу выйдет замуж или изменит номер телефона?

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

Реальные накладки могут появиться, если эти столбцы используют многобайтовые наборы символов или не двоичные порядки сортировки. Размеры индексов ограничены 252 байтами. Для ключей обязательно создаются индексы. Такой ключ будет невозможен просто по причине слишком большого размера.

Создание атомарного ключа

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

Решение заключается в добавлении дополнительного столбца в таблицы для использования в качестве искусственного или суррогатного первичного ключа - уникальный, ограниченного размера столбец, желательно генерируемый системой, который заменяет (замещает) функцию теоретического первичного ключа. Firebird предоставляет объекты GENERATOR, которые могут быть использованы для создания требуемых уникальных серий чисел BIGINT для первичного ключа размером 8 байт или меньше.

Общую технику реализации автоинкрементного первичного ключа (при отсутствии ручной работы) см. в разд. "Генераторы" главы 9 ив главе 31.

! ! !

ВНИМАНИЕ! Атомарность ключа должна поддерживаться в приложениях сокрытием его от пользователя или хотя бы его свойством только для чтения.

. ! .

Итог - суррогатные ключи против естественных ключей

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

Таблица 14.1. Суррогатные (искусственные) ключи в сравнении с естественными

Должны ли вы проектировать базу данных, смешивая естественные и искусственные ключи? Крайней точкой зрения является последовательный подход в проектировании - выберите естественные или искусственные ключи и применяйте это правило без исключений. Однако более умеренный подход может предоставить лучшее из обоих миров. Практичным является использование естественных ключей для стабильных "управляющих" таблиц соответствия, ключей, которые редко изменяются, никогда не участвуют в составных ключах и часто появляются в выходных данных.

! ! !

ВНИМАНИЕ! При проектировании ключей для базы данных Firebird помните, что ключи порождают индексы, а индексы в Firebird ограничены в размере до 252 байт. Сложные последовательности сортировки и многобайтовые международные наборы символов уменьшают количество символов в данных, которые могут быть использованы в качестве индексов.

. ! .

Ключи не являются индексами

Индексы не являются ключами. Ключи- ограничения на уровне таблицы. Сервер базы данных реагирует на объявление ограничений созданием множества объектов базы данных для их поддержки. Для ограничений первичных и уникальных ключей он создает уникальный индекс из столбца (столбцов), указанных в ограничениях. Для внешних ключей он создает неуникальный индекс из указанных столбцов, сохраняет записи для отношения и создает триггеры для выполнения нужных действий.

* Ключи являются ограничениями.

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

! ! !

ВНИМАНИЕ! Вы не должны создавать свои собственные индексы, которые дублируют создаваемые системой индексы для поддержания ограничений. Это является важной мерой предосторожности в отношении производительности, о чем неоднократно повторяется в разных местах книги. Разд. "Темы оптимизации" главы 18 объясняет, почему дублирование таких индексов может ухудшить производительность запросов.

. ! .

Ссылочная целостность данных

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

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

Индексы и планы запросов

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

Как средство управления реляционной базой данных, Firebird может связать почти любой объект столбца с почти любым другим объектом столбца (за исключением различных типов BLOB, включая массивы) с использованием ссылок на их идентификаторы. Однако при увеличении количества строк, связанных столбцов и таблиц в запросах производительность падает.

Когда столбцы, которые отыскиваются, соединяются и сортируются, индексированы удобным образом, производительность (время выполнения и использования ресурсов) может резко улучшиться. Необходимо также сказать, что слабое индексирование может резко ухудшить производительность!

Firebird использует алгоритмы оптимизации, которые в большой мере основаны на оценке затрат (cost-based). При подготовке запроса оптимизатор вычисляет относительные стоимости использования или игнорирования доступных индексов и возвращает клиенту план запроса, сообщая о своем выборе. Хотя можно разработать и передать оптимизатору ваш собственный план запроса- важное средство серверов реляционных СУБД, которые используют оптимизацию, основанную на правилах, - чаще всего оптимизатор Firebird знает лучше. Планы Firebird являются более полезными в выявлении и устранении проблем с индексами.

Проектирование и создание индексов рассматривается в главе 18.

Просмотры

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

Просмотры и другие наследуемые таблицы обсуждаются в главе 24 и должны изучаться вместе с другими главами части V.

Хранимые процедуры и триггеры

Хранимые процедуры и триггеры являются модулями компилированных, выполняемых кодов, которые выполняются на сервере. Исходный код пишется на расширении языка SQL, называемом процедурным SQL, или PSQL.

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

Триггеры являются специализированным видом модулей PSQL, которые могут быть объявлены для выполнения в одном или более из шести состояний/фаз операции (до и после добавления, изменения и удаления) в процессе операций манипулирования данными (DML) таблицы, которая владеет этими триггерами. Группы триггеров могут быть объявлены для каждой фазы для выполнения в определенной последовательности. Начиная с релиза 1.5, поведение любой или всех операций DML могут быть объединены с условиями выполнения в один модуль триггера "до" или "после". Триггеры не принимают входных аргументов и не возвращают выходных наборов.

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

PSQL имеет механизмы обработки исключений и внешних событий. Любое количество сообщений об исключениях может быть определено в качестве объектов базы данных с использованием операторов CREATE EXCEPTION. Внешние события создаются внутри модуля PSQL, а приложения могут устанавливать структуры для их "прослушивания".

Подробное обсуждение написания и использования модулей PSQL, исключений и событий см. в части VII.

 

Соглашения по именованию объектов базы данных и ограничения

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

* Начинайте каждое имя с буквенного символа (A-Z или a-z).

* Ограничивайте имена объектов 31 символом. Некоторые объекты, например имена ограничений, могут иметь длину до 27 символов.

* Допустимые символы для имен файлов базы данных - как и для всех объектов метаданных в Firebird - включают знаки доллара ($), подчеркивания (_), цифры от 0 до 9, буквы от А до Z и от а до z.

* Обеспечьте требования уникальности в базе данных:

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

• имена столбцов в таблице должны быть уникальными в этой таблице. Все другие идентификаторы объектов должны быть уникальными в базе данных.

* Исключите использование зарезервированных слов, пробелов, диакритических знаков и любых символов ASCII с кодом больше 127:

• в диалекте 1 они вообще не могут быть использованы;

• в диалекте 3 вы можете ограничить "неправильные" идентификаторы, используя пару символов двойной кавычки. Подробности будут дальше.

Идентификаторы с разделителями SQL-92

В базах данных диалекта 3 Firebird поддерживает соглашение ANSI SQL об идентификаторах с разделителями. Для использования зарезервированных слов, диакритических знаков, чувствительных к регистру строк или пробелов в имени объекта заключите имя в двойные кавычки. Теперь оно становится идентификатором с разделителями. Идентификаторы с разделителями должны всегда быть представлены с двойными кавычками.

! ! !

ПРИМЕЧАНИЕ. В диалекте 1 зарезервированные слова, диакритические знаки и пробелы недопустимы в именах объектов; идентификаторы, чувствительные к регистру, не поддерживаются.

. ! .

Имена, заключенные в двойные кавычки, являются чувствительными к регистру. Например,

SELECT "CodAR" FROM "MyTable"

отличается от

SELECT "CODAR" FROM "MYTABLE"

Заключать в кавычки или нет

Соглашение по двойным кавычкам для идентификаторов объектов было введено для совместимости со стандартами. Для тех, кто привык в прошлом в InterBase к нечувствительности к регистру, новая "возможность" будет в лучшем случае сбивать с толку, в худшем - раздражать.

Если вы определяете объекты в двойных кавычках, вы должны везде и всегда использовать их в двойных кавычках и обеспечивать соответствие регистра. Большинство опытных разработчиков Firebird рекомендует отказаться от них за исключением редких случаев, когда вам нужно использовать "неправильные" идентификаторы. Выбор за вами.

Исключение соответствия регистру

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

! ! !

СОВЕТ. Большинство графических инструментов базы данных Firebird предоставляет режим автоматического применения заключенных в кавычки идентификаторов. Один или два из этих инструментов фактически применяют идентификаторы в кавычках для всех объектов базы данных по умолчанию. Если у вас нет серьезных оснований использовать это, рекомендуется найти "отключающий переключатель" и отменить идентификаторы в кавычках.

. ! .

Соглашения по именованию файлов базы данных

Установленное соглашение по именованию файлов баз данных Firebird для любой платформы - использование трехсимвольного суффикса fdb для первичного файла, а для имен вторичных файлов f01, f02 и т.д. Это только соглашение - файлы Firebird могут иметь любое расширение или не иметь расширения вовсе.

По причине известных проблем с серверами XP, использующими SystemRestore для файлов с расширением gdb, разработчикам рекомендуется заменить традиционный суффикс файлов InterBase при миграции баз данных в Firebird.

Имя базы данных безопасности- security.fdb в релизе 1.5 и выше, isc4.gdb в релизе 1.0.x- не должно изменяться. К сожалению, у Firebird 1.0.x нет средств изменения требуемого суффикса gdb.

 

Скрипты Firebird

Скрипт для создания и изменения объектов базы данных иногда называют файлом определения данных или скриптом DDL. Скрипт DDL может содержать определенного рода операторы isql, а также некоторые из команд SET <параметр>. COMMIT также является допустимым оператором в скрипте.

! ! !

ПРИМЕЧАНИЕ. Утилита isql (интерактивный SQL) является программой командной строки, доступной на всех платформах; входит в состав комплекта поставки Firebird. Во всех случаях, кроме встроенного сервера для Windows, isql инсталлируется в каталог /bin корневого каталога Firebird. Полные инструкции см. в главе 37.

. ! .

Другие скрипты могут быть написаны для добавления основных, или "управляющих", данных в таблицы, изменения столбцов, преобразования данных и выполнения других задач, включающих манипулирование данными. Такие скрипты называются скриптами DML (для языка манипулирования данными, Data Manipulation Language).

Команды DDL и DML могут одновременно присутствовать в скриптах. Однако для устранения проблем с целостностью данных строго рекомендуется размещать операторы DDL и DML в отдельных скриптах. Обработка скриптов позволяет "изменять" скрипты, связывая один файл скрипта с другим с помощью оператора isql INPUT <спецификация_файла>.

Операторы скрипта выполняются в строгом порядке. Использование команды SET AUTODDL позволяет управлять подтверждением операторов или блоков операторов. Эта команда также позволяет откладывать подтверждение содержимого скрипта, пока не будет выполнен весь скрипт.

 

Зачем использовать скрипты?

Очень хорошей практикой является использование скриптов DDL для создания вашей базы данных и ее объектов. Перечислим несколько причин для этого.

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

* Управление разработкой базы данных. Представление всех описаний базы данных в скриптах позволяет создание схемы тесно интегрировать с циклами проектирования задач и пересмотра кода.

* Повторяемое и отслеживаемое создание метаданных. Полностью восстанавливаемая схема является требованием гарантированного восстановления системы после сбоев во многих организациях.

* Аккуратное конструирование и реконструирование метаданных базы данных. Опытные программисты Firebird часто создают набор скриптов DDL, разработанных для выполнения и подтверждения в нужном порядке. Это упрощает отладку и гарантирует, что объекты будут существовать, когда позже зависимые объекты будут на них ссылаться.

 

Что находится в скриптах DDL?

Операторы SQL

Скрипт DDL содержит один или более операторов SQL (CREATE, ALTER, DROP) для создания, изменения или удаления базы данных или любого другого объекта. Он может включать операторы DML, хотя рекомендуется использовать операторы DDL и DML в разных скриптах.

! ! !

СОВЕТ. Довольно общей является практика включения (INPUT) В цепочку скриптов DDL одного или более скриптов, содержащих операторы INSERT для ввода в некоторые таблицы статичных управляющих данных. Вы можете, например, включить операторы для добавления начальных строк в таблицу учетных записей. Убедитесь, что все операторы DDL подтверждаются до появления других операторов DML.

. ! .

Операторы процедурного языка (PSQL), определенные для хранимых процедур и триггеров, также могут быть включены в скрипты. Блоки PSQL получают специальную трактовку в скриптах в зависимости от символов терминатора операторов (см. далее разд. "Символы терминатора").

Комментарии

Скрипт может также содержать комментарии в двух вариантах.

Блок комментариев

Блок комментариев в скриптах DDL использует соглашения языка С:

/* Этот комментарий распространяется на множество строк в скрипте */

Блок комментариев может появиться в той же строке, что и оператор SQL или команда isql, и может быть произвольной длины. Он начинается символами /* и заканчивается символами */.

Линейные комментарии

Комментарий стиля /*...*/ также может быть встроен внутрь оператора как линейный комментарий:

CREATE TABLE USERS1 (

USER_NAME VARCHAR( 128 )

/* security user name */

, GROUP_NAME VARCHAR(128)

/* not used on Windows */

, PASSWD VARCHAR( 32 )

/* will be stored encrypted */

, FIRST_NAME VARCHAR(96) /* Defaulted */

, MIDDLE_NAME VARCHAR( 96 ) /* Defaulted */

, LAST_NAME VARCHAR( 96 ) /* Defaulted */

, EULL_NAME VARCHAR( 290 ) /* Computed */

) ;

Однострочные комментарии

В скриптах Firebird вы можете использовать альтернативное соглашение по комментированию одной строки - двойной минус:

-- комментарий

В релизе 1.0.x этот стиль комментария не может быть использован для линейного комментария или для "закомментирования" части строки.

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

CREATE TABLE MET_REPORT (

ID BIGINT NOT NULL, -- VARCHAR(40), невидим

WEATHER_CONDITIONS

BLOB SUB_TYPE TEXT,

LAST_REPORT TIMESTAMP) ;

Операторы isql

Команды isql SET AUTODDL, SET SQL DIALECT, SET TERM и INPUT являются допустимыми операторами в скриптах Firebird - подробности об этих командах см. в главе 37.

Символы терминатора

Все операторы, которые выполняются в скрипте, должны оканчиваться символом терминатора. Символ по умолчанию - точка с запятой (;).

Символ терминатора по умолчанию может быть изменен для всех операторов за исключением операторов языка процедур (PSQL) при использовании в скрипте команды SET TERM.

Терминаторы и язык процедур (PSQL)

PSQL не допускает никаких терминаторов за исключением точки с запятой (;). Такое ограничение необходимо, потому что CREATE PROCEDURE, RECREATE PROCEDURE, ALTER PROCEDURE, CREATE TRIGGER и ALTER TRIGGER вместе с их операторами PSQL являются сложными операторами с их собственными правилами. Компилятору нужно видеть точку с запятой для различения каждого оператора PSQL.

Следовательно, в скриптах необходимо переопределять используемый в командах скрипта терминатор перед началом операторов PSQL для хранимых процедур и триггеров. После последнего оператора END, когда завершается исходный текст процедуры, следует восстановить значение терминатора по умолчанию, используя другой оператор SET TERM. Пример:

CREATE GENERATOR GEN_MY_GEN ;

SET TERM ^^;

CREATE TRIGGER BI_TABLEA_0 FOR TABLEA

ACTIVE BEFORE INSERT POSITION 0

AS

BEGIN

IF (NEW.PK IS NOT NULL) THEN

NEW.PK = GEN_ID(GEN_MY_GEH, 1);

END ^^

SET TERM ; ^^

. . .

Любая строка может быть использована в качестве альтернативного терминатора, например:

SET TERM @ ! #;

CREATE PROCEDURE...

AS

BEGIN

. . . ;

. . . ;

END @!#

SET TERM ;@!#

/**/

COMMIT;

/**/

SET TERM +;

CREATE PROCEDURE...

AS

BEGIN

. . .;

. . . ;

END +

SET TERM ; +

/**/

COMMIT;

Оператор SQL без сообщений не выполняется, если его текст следует за символом терминатора в той же строке. Пробелы и комментарии могут следовать за терминатором, но не другие операторы.

Например, в следующей последовательности оператор COMMIT не будет выполняться:

ALTER TABLE ATABLE ADD F2 INTEGER; COMMIT;

в то время как последовательность далее правильная:

ALTER TABLE ATABLE ADD F2 INTEGER; /* счетчик бобов */

COMMIT;

 

Основные шаги

Основные шаги по использованию файлов скриптов описаны в следующих разделах.

Шаг 1: создание файла скрипта

Используйте любой подходящий текстовый редактор. На стадии обучения вы можете за каждым оператором DDL записывать оператор COMMIT, чтобы обеспечить видимость объекта последующим операторам. Когда вы получите больше опыта, вы научитесь подтверждать операторы в блоках, применяя SET AUTODDL ON и SET AUTODDL OFF с целью управления взаимозависимостями и при тестировании/отладке скриптов.

! ! !

ВНИМАНИЕ! Убедитесь, что каждый скрипт заканчивается символом перевода строки и, по меньшей мере, одной пустой строкой.

. ! .

Шаг 2: выполнение скрипта

Используйте команду INPUT в сессии isql, или кнопку Выполнить (Execute), или аналогичную в вашем инструменте управления базой данных.

isql в POSIX:

SQL> INPUT /data/scripts/myscript.sql;

isql в Win32:

SQL> INPUT d:\data\scripts\myscript.sql;

Шаг 3: просмотр результата и подтверждение изменений базы данных

Разные инструменты Firebird и версии isql возвращают различную информацию в случае ошибочного выполнения скрипта при наличии неверной команды. Средства,

добавленные после Firebird 1.0, обеспечивают более подробные сообщения об ошибках скрипта, чем предыдущие версии.

Как создавать скрипты

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

* в сессии интерактивной isql с использованием команды OOTPOT для передачи серий операторов DDL в файл;

* в текстовом редакторе ASCII, который выполняет переводы строки в соответствии с правилами командной строки операционной системы, где будет выполняться скрипт DDL;

* используя специализированные инструменты редактора скриптов, которые доступны среди инструментов администратора для Firebird сторонних разработчиков. См. список в приложении 5;

* используя инструмент CASE, который может выводить скрипты DDL в соответствии с соглашениями Firebird (InterBase).

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

* в Windows терминатор строки - символ возврата каретки плюс символ перевода строки (ASCII 13, за которым следует ASCII 10);

* в Linux/UNIX терминатор строки - символ перевода строки, или "новая строка" (ASCII 10);

* в Mac OS X терминатор строки- новая строка (ASCII 10), а в родных Macintosh это возврат каретки (ASCII 13).

! ! !

СОВЕТ. См. также в isql возможность извлечения метаданных, которая может быть полезной для извлечения схемы БД в формате скрипта.

. ! .

Некоторые инструменты редактирования имеют возможность сохранять данные в различных текстовых форматах. Это может быть полезным, например, при создании скриптов, совместимых с Linux, на машине Windows. При этом убедитесь, что вы используете редактор, который сохраняет только полный текст ASCII.

Подготовленный файл скрипта схемы должен начинаться с оператора CREATE DATABASE или, если база данных уже существует, с оператора CONNECT (включая имя пользователя и пароль в апострофах). Эти операторы задают базу данных, с которой оперирует файл скрипта. За ключевыми словами CREATE или CONNECT должна следовать полная спецификация файла базы данных в апострофах: полный абсолютный путь и имя файла базы данных.

! ! !

ПРИМЕЧАНИЕ. Не используйте алиасы в скриптах, которые создают базы данных.

. ! .

Пример:

SET SQL DIALECT 3 ;

CREATE DATABASE 'd:\databases\MyDatabase.fdb' PAGE_SIZE 8192

DEFAULT CHARACTER SET ISO8859_1 USER 'SYSDBA' PASSWORD 'masterkey';

или

CONNECT 'd:\databases\MyDatabase.gdb' USER 'SYSDBA' PASSWORD 'masterkey';

Подтверждение операторов в скрипте

Операторы DDL

Операторы в скриптах DDL могут подтверждаться одним или несколькими способами:

* включением в соответствующих местах скрипта операторов COMMIT, чтобы гарантировать доступность новых объектов базы данных всем последующим зависящим от них операторам;

* включением в начало скрипта следующего оператора:

SET AUTODDL ON;

Для отмены автоматического подтверждения операторов DDL в скрипте isql используйте:

SET AUTODDL OFF;

Ключевые слова ON и OFF необязательны. Сокращение SET AUTO может быть использовано в качестве двухстороннего переключателя. Для большей ясности рекомендуется использовать SET AUTODDL с явным указанием ключевых слов ON и OFF.

Автоматическое подтверждение isql

Если вы выполняете свой скрипт в isql, то изменения базы данных операторами определения данных (DDL)- например, операторами CREATE и ALTER- автоматически подтверждаются по умолчанию. Это означает, что другие пользователи базы данных видят изменения сразу после выполнения оператора DDL.

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

Операторы DML

Изменения базы данных, выполненные операторами манипулирования данными (DML) - INSERT, UPDATE и DELETE, - не станут постоянными, пока не будут подтверждены. Явно включите операторы COMMIT в ваш скрипт для подтверждения изменений DML.

Для отмены всех изменений базы данных после последнего COMMIT используйте ROLLBACK. Подтвержденные изменения не могут быть отменены.

Выполнение скриптов

Скрипты DDL могут быть выполнены в сессии интерактивного isql с использованием команды INPUT, как было описано ранее. Многие инструменты сторонних разработчиков позволяют выполнять и даже интеллектуально отлаживать скрипты в среде графического интерфейса.

 

Управление скриптами вашей схемы

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

Восстановление после сбоев

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

Управление разработкой

Скорее всего, несколько разработчиков будут создавать базу данных в течение ее жизненного цикла. Известно, что разработчики ненавидят написание системной документации! Хранение аннотированных записей скриптов о каждом изменении базы данных- включая те, которые использовались интерактивно через isql или инструмент сторонних разработчиков, - это безболезненное и безопасное решение, которое работает во всех случаях.

Извлечение метаданных

Некоторые инструменты администратора для Firebird, включая isql, могут выделять метаданные из базы данных и сохранять их в виде файла скрипта. Об использовании isql см. разд. "Извлечение метаданных" главы 37. Так как извлечение метаданных является удобным помощником в вашем использовании скриптов, существует множество причин трактовать эти инструменты как "ассистенты" и взять себе за правило вручную поддерживать ваши главные скрипты схемы.

* Firebird не хранит комментарии при сохранении определений метаданных. Многие системные таблицы имеют столбец BLOB, обычно называемый RDB$DESCRIPTION, в котором может сохраняться в виде единого целого часть предоставленного пользователем описания. При извлечении метаданных инструментом isql этот столбец не выводится, хотя некоторые инструменты сторонних разработчиков его поддерживают.

* Все инструменты извлечения метаданных генерируют только текущие метаданные. Не существует истории изменений - даты, причины или авторы изменений.

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

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

Создание скриптов вручную

Автор жестко пропагандирует поддержку полностью аннотированных скриптов схемы вручную и разделение их на несколько отдельных файлов. Пример набора скриптов в табл. 14.2 описывает и регенерирует базу данных с именем leisurestore.fdb.

Таблица 14.2. Пример набора скриптов для схемы

Цепочки скриптов

Устойчивый набор скриптов может быть соединен вместе в цепочку с использованием оператора isql INPUT В качестве последнего оператора в предыдущем скрипте. Например, для присоединения скрипта leisurestore_0.sql к leisurestore_01.sql завершите скрипт следующим образом:

. . .

COMMIT;

-- присоединение к операторам CREATE TABLE

INPUT 'd:\scripts\leisurestore_02.sql' ;

-- не забудьте добавить пустую строку!

Подход, основанный на главном скрипте

Оператор INPUT не обязательно должен быть последним в скрипте. Поэтому другим полезным подходом к поддержке набора скриптов является наличие "главного" скрипта, который вводит каждый дополнительный скрипт в нужном порядке. Это создает преимущества в поддержке больших наборов скриптов. Вы можете включить комментарии для сообщения о содержании каждого входного скрипта.

Пора дальше

А теперь - за создание баз данных! В следующей главе вы не только научитесь создавать базы данных, но также и сохранять их чистыми, безопасными и с хорошей производительностью. Существует не так много способов разрушения баз данных Firebird, однако раздел в конце этой главы описывает пять способов сделать это. Предупрежден, значит вооружен!

 

Размещение

До создания базы данных вы должны знать, где собираетесь ее создавать. Это не столь глупо, как звучит. Оператор CREATE DATABASE (альтернатива- CREATE SCHEMA) будет создавать файл или файлы с указанными вами именами, однако он не может создать каталоги и не может изменить полномочия доступа файловой системы. Этим деталям следует уделить внимание в первую очередь.

Дополнительно сервер Firebird 1.5 может быть сконфигурирован для ограничения размещения баз данных. Проверьте параметр DatabaseAccess в файле firebird.conf (см. главу 3), чтобы выяснить, где ваш сервер ограничен в доступе. Если у вас установки по умолчанию (Full), то вы можете создавать базу данных в любом месте. Иначе:

* установка Restrict указывает файловой системе иерархию, в которой разрешен доступ к базе данных. Убедитесь, что пользователь, запускающий ваш сервер, имеет достаточные полномочия для создания там файла (или, в случае встроенного сервера Windows, подключающийся пользователь);

* установка None позволяет серверу соединяться только с базами данных, находящимися в списке в aliases.conf. Вы можете создавать базу данных в любом месте, однако, за исключением создания, никакой клиент не будет иметь возможности соединиться с ней, если алиас БД и ее абсолютный адрес не будут присутствовать в aliases.conf.

! ! !

ВНИМАНИЕ! Настоятельно рекомендуется устанавливать режим DatabaseAccess в NONE и использовать средства алиасов базы данных. Более подробную информацию об алиасах базы данных см. в разд. "Алиасы базы данных" главы 4.

. ! .

 

ISC_USER и ISC_PASSWORD

На сервере можно установить две переменные окружения: ISC_USER и ISC_PASSWORD, чтобы избежать необходимости явно записывать пароли в скриптах. Вы можете делать все, что разрешено указанному пользователю. Эта возможность удобна для административных задач, однако она должна быть использована с большой осторожностью, потому что оставляет доступ к вашей базе данных открытым для любого локального пользователя, кто случайно натолкнется на ваше окно командной строки.

Если вы хотите играть с огнем, сделайте эти две переменные постоянными. Если же вы хотите иметь высокий уровень удобства и защищенности скриптов, временно устанавливайте их каждый раз при работе и не забывайте отменять установку при завершении работы с окном командной строки.

В Linux в том же окне командной строки, из которого вы запускали приложение, введите:

]# setenv ISC_USER=SYSDBA

]# setenv ISC_PASSWORD=masterkey

Для отмены установок используйте следующее:

]# setenv ISC_USER=

]# setenv ISC_PASSWORD=

или просто закройте окно.

В Windows в командной строке введите:

set ISC_USER=SYSDBA

set ISC_PASSWORD=masterkey

Для отмены введите:

set ISC_USER=

set ISC_PASSWORD=

 

Диалект

По умолчанию Firebird создает базу данных диалекта 3. Если вы хотите создать базу данных диалекта 1, первым оператором в вашем скрипте (или первым действием в вашем инструменте администратора) должен быть:

SET SQL DIALECT 1;

! ! !

ВНИМАНИЕ! Если isql в настоящий момент соединен с базой данных, он предложит вам подтвердить текущую транзакцию. Ответьте Yes (Да) для продолжения создания новой базы данных. Некоторые инструменты сторонних разработчиков вначале могут потребовать, чтобы вы отсоединились от базы данных.

. ! .

Следующий оператор - или первый для базы данных диалекта 3 - должен быть оператором CREATE DATABASE или CREATE SCHEMA такого синтаксиса:

CREATE {DATABASE | SCHEMA} 'спецификация-файла '

[USER 'имя-пользователя' [PASSWORD 'пароль']]

[PAGE_SIZE [=] целое]

[LENGTH [=] целое [PAGE[S]]]

[DEFAULT CHARACTER SET набор-символов]

[<вторичный-файл>] ;

<информация-о-файле> = LENGTH [=] целое [PAGE[S]]

STARTING [AT [PAGE]] целое [<информация-о-файле>]

<вторичный-файл> = FILE 'спецификация-файла' [<информация-о-файле>]

[<вторичный-файл> ]

! ! !

СОВЕТ. Используйте одиночные кавычки (апострофы) для таких строк, как имена файлов, имена пользователей и пароли.

. ! .

DATABASE или SCHEMA?

CREATE DATABASE и CREATE SCHEMA являются одним и тем же оператором. Это только вопрос ваших предпочтений.

 

Обязательные и необязательные атрибуты

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

Имя и путь к базе данных

Спецификация файла должна быть полным абсолютным путем к файлу. Путь должен иметь правильный формат в операционной системе.

Для POSIX:

CREATE DATABASE '/opt/databases/mydatabase.fdb'

Для Win32:

CREATE SCHEMA 'd:\databases\mydatabase.fdb'

Вы можете использовать наклонную черту (/) или обратную наклонную черту (\) в качестве разделителя каталогов. Firebird автоматически преобразует любой тип в тип, соответствующий серверу операционной системы.

Апострофы в спецификации файла являются обязательными. Все элементы спецификации файла чувствительны к регистру для платформ POSIX.

Создание удаленной базы данных

При создании базы данных с клиентской рабочей станции или локально в Суперсервере для Linux - интерактивно или с использованием скрипта - вы должны включить имя хоста.

Для POSIX:

CREATE DATABASE 'rayserver:/opt/databases/mydatabase.fdb'

Для локального Linux Суперсервера- как и в предыдущем случае или так:

CREATE DATABASE 'localhost:/opt/databases/mydatabase.fdb'

Для Win32:

CREATE SCHEMA 'NTServer:d:\databases\mydatabase.fdb'

Владение базой данных

Если вы подключены как пользователь SYSDBA, то SYSDBA будет владеть новой базой данных, независимо от того, как были заданы предложения USER и PASSWORD. Хотя указание владельца не является обязательным, очень желательно это сделать. При этом по причине безопасности вы, вероятно, захотите удалить из скрипта пароль пользователя перед архивацией скрипта с остальной системной документацией.

CREATE DATABASE '/opt/databases/mydatabase.fdb'

USER 'ADMINUSR' PASSWORD 'yyuryyub';

Размер страницы

Необязательный атрибут PAGE_SIZE (размер страницы) задается в байтах. Если вы его опустите, будет принято значение по умолчанию: 4096 байт в isql. Некоторые другие инструменты применяют свое значение по умолчанию, значит, есть веский аргумент указывать это значение в скрипте явно. Размер страницы может быть 1024, 2048, 4096, 8192 или 16 384. Любые другие значения будут преобразованы в ближайшее меньшее число из этого списка. Например, если вы укажете 3072, Firebird создаст базу данных с размером страницы 2048.

CREATE DATABASE '/opt/databases/mydatabase.fdh' USER 'ADMINUSR'

PASSWORD 'yyuryyub'

PAGE_SIZE 8192

Факторы, влияющие на выбор размера страницы

Выбор размера страницы не является вопросом применения некоторого "правила". Будет неплохо начать с размера по умолчанию - 4 Кбайт. Когда придет время настраивать базу данных для улучшения производительности, вы сможете поэкспериментировать, создавая резервную копию базы данных и восстанавливая ее с другим размером страницы. Подробности см. в главе 38.

Выбранный вами размер страницы может улучшить производительность или плохо на нее воздействовать в зависимости от множества факторов, главным образом, от структуры и порядка использования таблиц, к которым чаще всего осуществляется доступ. Каждая страница базы данных будет заполняться приблизительно на 80 процентов, следовательно, рассуждайте в терминах реального размера страниц, который должен составлять около 125 процентов от предполагаемого минимума.

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

Количество строк, которое можно предположить у ваших таблиц через некоторое время, может оказывать влияние. Если множество строк может разместиться на одной странице, больший размер страницы может уменьшить общее количество страниц данных и индексов, которые нужно прочесть в одной операции.

Набор символов по умолчанию

Строго рекомендуется, чтобы все - или почти все - ваши текстовые данные были в кодировке U.S. ANSII.

CREATE DATABASE '/opt/databases/mydatabase.fdb'

USER 'ADMINUSR' PASSWORD 'yyuryyub'

PAGE_SIZE 8192

DEFAULT CHARACTER SET ISO8859_1;

Подробнее о наборах символов см. в главе 11. Доступные наборы символов представлены в приложении 8.

 

Получение информации о базе данных

После того как вы создали базу данных и подтвердили создание (commit), вы можете в isql отобразить ее детали, используя команду SHOW DATABASE:

SQL> SHOW DATABASE;

Database: /opt/databases/mydatabase.fdb

Owner: ADMINUSR

PAGE_SIZE 8192

Number of DB pages allocated = 176

Sweep interval = 20000

Forced Writes are ON

Transaction - oldest = 5

Transaction - oldest active = 6

Transaction - oldest snapshot = 6

Transaction - Next = 9

Default character set: ISO8859_1

SQL>

Интервал очистки и транзакции

Информацию о чистке базы данных и интервале очистки см. в разд. "Гигиена базы данных" далее в этой главе.

Значения старейшей ("старейшей заинтересованной"), старейшей активной и следующей транзакций являются важными для производительности и поведения сервера. Подробности см. в части VI.

Принудительная запись

Принудительная запись (forced writes) является синонимом синхронной записи. На платформах, которые поддерживают асинхронную запись, базы данных Firebird создаются по умолчанию с принудительной записью. Фраза "отключение принудительной записи" означает переключение поведения при записи с синхронного на асинхронное.

* При включенной принудительной записи новые записи, новые версии записей и удаления физически записываются на диск сразу после завершения операции или, самое позднее, после подтверждения транзакции.

* Асинхронная запись приводит к тому, что новые или измененные данные хранятся в кэше файловой системы. Когда эти данные будут записаны на диск, зависит от поведения операционной системы.

! ! !

ПРИМЕЧАНИЕ. Платформа Windows 95 не поддерживает асинхронную запись.

. ! .

Обсуждение отключения принудительной записи и инструкции по ее установке при использовании gfix см. в главе 39.

 

Задание размера файла для однофайловой базы данных

Вы можете указать размер первичного файла в страницах следом за атрибутом PAGE_SIZE. Например, следующий оператор создает базу данных в файле размером 10 000 страниц:

CREATE DATABASE '/opt/databases/mydatabase.fdb'

USER 'ADMINUSR' PASSWORD 'yyuryyub'

PAGE_SIZE 8192

LENGTH 10000 PAGES

/* ключевое слово PAGES необязательно */

DEFAULT CHARACTER SET WIN1251;

Если база данных растет до размера большего, чем указанный размер файла, то Firebird расширяет первичный файл за пределы LENGTH, пока не будет достигнут предел, существующий для файловой системы, или не будет исчерпано дисковое пространство. Чтобы не допустить этого, вы можете хранить базу данных более чем в одном файле; дополнительные файлы называются вторичными файлами. Файлы могут размещаться на нескольких дисках.

 

Изменение базы данных

Оператор ALTER DATABASE используется для добавления одного или более вторичных файлов к существующей базе данных. Он требует исключительного доступа к базе данных - см. разд. "Исключительный доступ"главы 39.

База данных может изменяться ее создателем (владельцем), пользователем SYSDBA или - для Linux/UNIX - любым пользователем с привилегиями операционной системы root.

Синтаксис

Синтаксис ALTER DATABASE:

ALTER {DATABASE | SCHEMA}

ADD <предложение-добавления>;

<предложение-добавления> = FILE 'спецификация-файла'

<информация-о-файле> [<предложение-добавления>]

<информация-о-файле> = {LENGTH [=] целое [PAGE[S]] |

STARTING [AT [PAGE]] целое }

[<информация-о-файле>]

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

ALTER DATABASE

ADD FILE 'mydatabase.fd2' STARTING AT PAGE 10001

ADD FILE 'mydatabase.fd3' STARTING AT PAGE 20001 ;

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

Следующий пример задает длину вторичного файла, а не начальный номер страницы:

ALTER DATABASE

ADD FILE 'mydatabase.fd2' LENGTH 10000

ADD FILE 'mydatabase.fd3' ;

Результат несколько отличается от первого примера. В этом случае Firebird начнет использовать вторичный файл, когда первичный файл достигнет лимита файловой системы.

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

 

Ограничения и значения по умолчанию

Минимальный размер кэша- 50 страниц. Максимума не существует, пока выделяемый объем памяти не превышает доступный объем RAM.

Величиной выделяемого кэша по умолчанию является:

* Суперсервер. Для каждой выполняющейся базы данных 2048 страниц. Все пользователи совместно используют этот пул кэша.

Для оценки используемых ресурсов: одна выполняющаяся база данных с установками по умолчанию для PAGE_SIZE (4 Кбайт) и DefauitDbcachePages (2 Кбайт) требует 8 Мбайт памяти. Две базы данных, выполняющиеся с теми же установками, требуют 16 Мбайт и т.д. Используемый объем кэша по умолчанию вычисляется следующим образом:

PAGE_SIZE * DefaultDbCachePages * количество баз данных

* Классический сервер. Для каждого клиентского соединения 75 страниц кэша. Каждое соединение выделяет свой собственный кэш. Объем требуемой памяти является суммой требований к кэшу всех клиентских соединений со всеми базами данных. Используемый объем кэша вычисляется следующим образом:

PAGE_SIZE * DefaultDbCachePages * количество соединений

 

Вычисление размера кэша

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

Поскольку DbCache сконфигурирован в страницах, очевидно, что база данных с большим размером страницы потребляет больше памяти, чем база данных с меньшим размером страницы. Когда множество баз данных выполняется на одном и том же сервере, может оказаться желательным переопределить размер кэша на стороне сервера значением на уровне базы данных или в некоторых случаях на уровне приложения.

Приложение, которое интенсивно выполняет индексированные выборки, требует больше буферов, чем приложение, преимущественно выполняющее добавление данных.

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

Может случиться, что слишком много буферов кэша будет выделено из имеющейся RAM. При наличии большого количества одновременно выполняющихся баз данных запрос может затребовать больше RAM, чем доступно в системе. Кэш будет перекачиваться вперед и назад между RAM и диском, уничтожая преимущества кэширования. Другие приложения (включая сервер) будут испытывать недостаток в памяти, если кэш будет слишком велик.

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

Оценка требований к размеру

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

Нет необходимости иметь кэш, вмещающий всю базу данных. Найдите коэффициент уменьшения для каждой базы данных, оценивая ту часть, к которой, скорее всего, будет доступ в процессе обычного использования. Совет по оценке простой - не существует "правила". Пусть, когда мы говорим о "DbCachePage", мы имеем в виду размер кэша, но не обязательно при условии установок сервера по умолчанию для новых и неконфигурированных баз данных.

Коэффициент уменьшения r должен иметь значение между 0 и 1.

Размер базы данных в страницах может быть установлен следующим образом:

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

* для многофайловой базы данных возьмите значение STARTING AT первого вторичного файла и прибавьте значения LENGTH всех вторичных файлов.

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

Для каждой базы данных вычислите:

DbCachePages = r * размер

Вычислите и запишите это число для каждой базы данных.

! ! !

СОВЕТ. Храните эти записи в другой документации по базе данных для использования, при необходимости, в настройке кэша индивидуальной базы данных.

. ! .

Вычисление потребностей в RAM

Для вычисления требуемого объема RAM для кэша базы данных на вашем сервере возьмите значение PAGE SIZE для каждой базы данных и умножьте на значение DefaultDbCachePages. Просуммированные результаты для всех баз данных дадут приблизительные требования к минимальному объему RAM для кэширования баз данных.

 

Установка размера кэша на уровне базы данных

Существует несколько способов конфигурирования размера кэша для конкретной базы данных. Изменения не действуют до тех пор, пока не будет установлено новое соединение с Суперсервером Firebird или не будет соединен новый клиент с Классическим сервером.

Использование gfix

Рекомендуемый способ установки значения на уровне базы данных для перекрытия значения DefaultDbCachePages - использование утилиты командной строки gfix со следующими переключателями:

gfix -buffers n имя-базы-данных

где n- требуемое количество страниц базы данных. Этот способ позволяет точно задать размер кэша базы данных, уменьшая риск "недоиспользования" памяти или работы со слишком малым размером кэша, когда на сервере используются несколько баз данных с разными требованиями к размеру кэша. Установленный таким способом размер кэша будет использован до тех пор, пока не будет задано новое значение.

! ! !

ПРИМЕЧАНИЕ. Для запуска gfix вы должны быть пользователем SYSDBA или владельцем базы данных. Более подробную информацию об использовании gfix см. в главе 39.

. ! .

Использование инструмента запросов командной строки isql

У вас есть две возможности для увеличения количества страниц кэша в процессе одной сессии утилиты командной строки isql.

Первый вариант- включить количество страниц (n) как переключатель при запуске isql:

isql -с n имя-базы-данных

где n- количество используемых в сессии страниц кэша, которое временно перекрывает любое значение, установленное В DefaultDbCachePages (database_cache_pages) или в gfix. Должно быть больше 9.

В качестве альтернативы вы можете включить CACHE n В качестве аргумента оператора CONNECT при выполняющейся isql:

isql > connect имя-базы-данных CACHE n

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

Использование буфера параметров базы данных

В приложении размер кэша может быть установлен в буфере параметров базы данных (Database Parameter Buffer, DPB) с использованием параметра isc_dpb_num_buffers или isc_dpb_set_page_buf fers в соответствии с требованиями вашего сервера.

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

* isc_dpb_set_page_buffers - используется как в Классическом сервере, так и в Суперсервере. Этот параметр имеет тот же эффект, что и использование gfix для постоянного перекрытия DefaultDbCachePages.

! ! !

ВНИМАНИЕ! Будьте осторожны, предоставляя приложению конечного пользователя возможность модифицировать кэш. Хотя любой запрос на изменение размера кэша будет проигнорирован во всех запросах соединения, кроме первого, предоставление возможности изменения установок сервера пользователям, не являющимися техническими специалистами, может иметь непредсказуемые последствия для производительности и оказать воздействие на весь сервер.

. ! .

 

Изменение значений по умолчанию для сервера

Установка на сервере для DefaultDbCachePages значения, большего, чем значение DbCachePages, является избыточным. Когда вы меняете установки по умолчанию на уровне сервера в файле конфигурации, они становятся значениями по умолчанию для каждой новой сконфигурированной с нулевым значением кэша базы данных на этом сервере.

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

* для версии 1.5 уберите комментарий у DefaultDbCachePages и измените число;

* для версии 1.0.x в файле конфигурации это defauit_cache_pages. Если необходимо, уберите комментарий В строке и создайте запись default_cache_pages=nnnn, где nnnn - новый размер кэша.

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

Прагматичный подход

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

Хороший совет: не бросайтесь оптимизировать размер кэша для Firebird по принципу "обязан сделать". В процессе разработки используйте установки по умолчанию, а при установке системы просто проверьте, подходит ли объем доступной памяти RAM значениям по умолчанию.

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

При первом приближении к оптимизации вы можете увеличить значение по умолчанию для кэша до размера, который займет приблизительно две трети доступной свободной памяти RAM. Если установлен недостаточный объем RAM, поставьте больше.

После этого снова запустите мониторинг. Если описанная процедура не привела к улучшению дел, повторите упражнение.

 

Проверка размера кэша

Для проверки величины используемого кэша базы данных выполните следующие команды в isql:

ISQL> CONNECT имя-базы-данных;

ISQL> SET STATS ON;

ISQL> COMMIT;

Current memory = 415768

Delta memory = 2048

Max memory = 419840

Elapsed time = 0.03 sec

Buffers = 2048

Reads = 0

Writes 2

Fetches = 2

ISQL> QUIT;

После SET STATS ON пустая команда COMMIT указывает утилите isql на необходимость отображения информации об использовании памяти и буфера. Прочтите значение Buffers для определения текущего размера кэша в страницах.

 

Внешние файлы

Любые файлы, связанные с базой данных путем объявления

CREATE TABLE имя-таблицы EXTERNAL FILE 'имя-файла'

будут так же открываться, как файлы только для чтения, даже если для файла не установлен атрибут только для чтения.

 

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

Требуется исключительный доступ для переключения базы данных между режимами чтения/записи и только для чтения- см. разд. "Исключительный доступ" главы 39. Переключение режима может быть выполнено владельцем базы данных или пользователем SYSDBA.

Могут быть использованы утилиты gfix или gbak:

* Используя gbak, выполните резервное копирование базы данных и восстановите ее в режиме только для чтения посредством опции -c[reate], например:

gbak -create -mode read_only dbl.fbk dbl.fdb

* Используя gflx, выдайте команду-m[ode] read-only, например: gfix -mode read_only dbl. fdb

! ! !

СОВЕТ. Восстанавливайте базы данных только для чтения с полностраничным заполнением - используйте переключатель -use для указания "использовать полное пространство". В базе данных для чтения/записи страницы по умолчанию заполняются примерно на 80 процентов, поскольку это может помочь в оптимизации повторного использования страниц. Резервирование пространства не имеет смысла для базы данных только для чтения, а полностью заполненные страницы являются более компактными и более быстрыми.

. ! .

! ! !

СОВЕТ. Хотя сервер Firebird может управлять напрямую базами данных InterBase 5.x, эти базы данных не могут быть переведены в режим только для чтения. Вы можете обновить базу данных InterBase 5 до базы данных только для чтения Firebird, сделав транспортабельную резервную копию в gbak InterBase 5 и восстановив с использованием gbak Firebird, с переключателями -c[reate] и -mode read_only.

. ! .

 

Преимущества и ограничения теневого копирования

Основным преимуществом теневого копирования является то, что оно дает быстрый способ восстановления базы данных в случаях сбоев в аппаратном обеспечении. Активация теневой копии делает ее доступной немедленно. Теневое копирование выполняется незаметно для пользователей как дополнительный цикл в процессе записи данных с минимальным вниманием со стороны администратора базы данных.

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

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

Теневое копирование является методом восстановления "все или ничего". Оно не обеспечивает восстановления отдельных фрагментов или возврата к конкретной временной точке. Оно может существовать только в той же файловой системе, что и сервер; теневая копия должна находиться на фиксированных дисках, расположенных на сервере. Она не может записываться на совместно используемые, не относящиеся к локальной файловой системе или удаленные устройства.

! ! !

ПРИМЕЧАНИЕ. На системах, поддерживающих NFS (Networking File System), возможна поддержка теневых копий на файловой системе NFS. Причем это не рекомендуется, поскольку теневая копия станет изолированной - а следовательно, бесполезной - при потере соединения.

. ! .

Важные предостережения

Теневое копирование не является заменой резервного копирования. Не успокаивайте себя верой в то, что теневое копирование является способом замены регулярного резервного копирования и периодического восстановления базы данных.

* Файл теневой копии не менее уязвим от "бросков и стрел жестокой фортуны", чем любые другие файлы вашей файловой системы.

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

* Смерть диска или ненадежный модуль памяти способны принести огромный вред до того, как они полностью разрушат вашу базу данных. Каждый ошибочный фрагмент будет точно записан в теневую копию.

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

! ! !

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

. ! .

 

Реализация теневого копирования

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

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

Размещение и распределение файлов теневой копии

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

Дисковое устройство должно быть физически подключено к машине, на которой выполняется сервер Firebird. Файлы в наборе теневых копий могут находиться на разных дисках для улучшения ввода/вывода и выделения дискового пространства. Как и спецификации файлов базы данных, спецификации для теневых копий являются зависимыми от платформы.

Варианты теневой копии

Режим (AUTO или MANUAL)

Установка режима - автоматический (с или без атрибута условная, CONDITIONAL) или ручной - определяет, что произойдет, если теневая копия станет недоступной.

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

* В момент, когда теневая копия станет недоступной, появится окно, чтобы проинформировать об этом администратора базы данных.

* Если ставшая недоступной теневая копия была создана с атрибутом CONDITIONAL, Firebird автоматически создает новую теневую копию, если это возможно.

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

Режим MANUAL прекращает дальнейший доступ к базе данных в случае, когда теневая копия становится недоступной. Закройте ее, если продолжение теневого копирования является более важным, чем продолжение операций с базой данных.

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

Условное теневое копирование

Одной из причин, по которой теневая копия становится недоступной, является ситуация, когда она принимает на себя функции главной базы данных в случае "гибели" аппаратуры существующей базы данных - как-никак это основная идея теневого копирования!

! ! !

ВНИМАНИЕ! Атрибут CONDITIONAL должен также приводить к автоматическому созданию новой теневой копии, если существующая теневая копия становится операционной базой данных. Тем не менее практика показывает, что это происходит не всегда. Проверьте, работает ли это, как ожидалось, и будьте готовы использовать запасной вариант.

. ! .

Однофайловые теневые копии в сравнении с многофайловыми

По умолчанию теневая копия создается как "набор", содержащий один файл. Тем не менее набор теневой копии может включать в себя несколько файлов. Когда база данных- а следовательно, и ее теневая копия - увеличивается в размерах, теневая копия может быть переопределена и перегенерирована с большим количеством файлов, чтобы соответствовать требованиям увеличения пространства.

 

Создание теневой копии

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

Синтаксис:

CREATE SHADOW номер-набора [AUTO | MANUAL] [CONDITIONAL]

'спецификация-файла'

[LENGTH [=] целое [PAGE[S]]] [<вторичный-файл>];

<вторичный-файл> = FILE 'спецификация-файла'

[<информация-о-файле>] [<вторичный-файл>]

<информация-о-файле> =

{LENGTH [=] целое[PAGE[S]] | STARTING [AT [PAGE]]

целое} [<информация-о-файле>]

! ! !

СОВЕТ. Как и в операторе CREATE DATABASE, спецификация файлов для теневой копии всегда является зависимой от платформы.

. ! .

Однофайловая теневая копия

Предположим, у нас имеется сервер на Linux, соединенный с базой данных employee.gdb, которая размещена в каталоге примеров в корневом каталоге Firebird. Мы решили выполнять теневое копирование базы данных в разделе с именем /shadows. Для создания однофайловой теневой копии мы используем оператор

CREATE SHADOW 1 '/shadows/employee.shd';

Номер набора теневой копии может быть любым целым. Размер страницы не включен, следовательно, атрибут PAGE_SIZE будет взят из спецификации самой базы данных.

Используем команду isql SHOW DATABASE, чтобы убедиться, что теневая копия сейчас существует:

SQL> SHOW DATABASE;

Database: /usr/local/firebird/examples/employee.gdb

Shadow 1: '/shadows/employee.shd' auto

PAGE_SIZE 4096

Number of DB pages allocated = 392

Sweep interval = 20000

. . .

Многофайловая теневая копия

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

В следующем примере предположим, что мы соединены с базой данных employee.gdb, расположенной в каталоге по умолчанию Win32. Мы собираемся создавать теневую копию из трех файлов на дисках F, H и J, которые являются разделами жесткого диска файловой системы сервера.

! ! !

СОВЕТ. Размеры вторичных файлов теневой копии не обязательно должны соответствовать размерам вторичных файлов базы данных.

. ! .

Первичный файл (employee1.shd) имеет длину 10 000 страниц базы данных, а первый вторичный файл (employee2.shd) 20 000 страниц базы данных. Как и в случае с базой данных, последний вторичный файл теневой копии при необходимости будет увеличиваться, пока не будет исчерпано дисковое пространство раздела или пока не будет достигнут предел размера для файловой системы.

CREATE SHADOW 25 'F:\shadows\employeel.shd' LENGTH 10000

FILE 'H:\shadows\employee2.shd' LENGTH 20000

FILE 'J:\shadows\employee3.shd' ;

Мы можем также указать начальные страницы вторичных файлов, вместо абсолютного размера первичного и не последних вторичных файлов:

CREATE SHADOW 25 'F:\shadows\employeel.shd'

FILE 'H:\shadows\employee2.shd' STARTING AT 10001

FILE 'J:\shadows\eraployee3.shd' STARTING AT 30001;

Вы можете проверить в isql:

SQL> SHOW DATABASE;

Database: C:\Program\firebird\examples\employee.gdb

Owner: SYSDBA

Shadow 25: 'F:\SHADOWS\EMPLOYEEl.SHD' auto length 10000

file H:\SHADOWS\EMPLOYEE2.SHD starting 10001

file J:\SHADOWS\EMPLOYEE3.SHD starting 30001

PAGE_SIZE 1024

Number of DB pages allocated =462

Sweep interval = 20000

Ручной режим

В предыдущих примерах создавались теневые копии в режиме по умолчанию AUTO. Предположим, что теперь нам нужно, чтобы работа базы данных была остановлена каждый раз, когда работа с базой данных или ее теневой копией становится невозможной по различным причинам. В этом случае нам нужно создавать теневую копию в режиме MANUAL (см. предыдущие примечания в этом разделе). Для сообщения серверу Firebird, что мы хотим установить это правило, мы создаем теневую копию с использованием ключевого слова MANUAL в операторе CREATE SHADOW:

CREATE SHADOW 9 MANUAL '/shadows/employee.shd';

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

Условная теневая копия

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

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

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

Как было описано ранее в этом разделе, мы можем улучшить эту ситуацию, включив ключевое слово CONDITIONAL В определение теневой копии режима AUTO. Результатом будет то, что когда старая теневая копия станет недоступной, сервер Firebird выполнит все необходимые вспомогательные действия и автоматически создаст новую теневую копию, например:

CREATE SHADOW 33 CONDITIONAL '/shadows/employee.shd';