Разработка информационного обеспечения

Обоснование выбора СУБД

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

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

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

В мире Open Source было сделано многое для создания функционально полноценной, гибкой и удобной в использовании системы управления базами данных — СУБД, которая смогла бы выдерживать большие нагрузки и еще иметь интерфейс доступа из популярных языков программирования, таких, как PHP и Perl. За долгое время развития систем хранения данных на этом рынке определились два сильнейших игрока, MySQL и PostgreSQL. Но постепенно в борьбу за право называться лучшей СУБД вступает третий игрок — СУБД Firebird. Сервер предлагает широкий набор функций, имеет отличный послужной список еще в бытность им СУБД InterBase. Как будет рассказано ниже, Firebird имеет внушительные возможности, доступные, как правило, только в коммерческих системах управления базами данных включая хранимые процедуры, триггеры, архивирование базы во время ее работы (hot backup — «горячая» архивация), репликацию и многое другое. Как и другие уже сложившиеся продукты, Firebird несет в себе наследство от своих предшественников, что может немного отпугнуть нового пользователя. Так что перед тем, как погрузиться в исследование особенностей, предоставляемых этим сервером баз данных, рассмотрим некоторые общие проблемы, которые могут возникнуть.

Сервер Firebird изначально начитал свою жизнь как продукт компании «Борланд» под названием InterBase. Когда была готова к выходу шестая версия этой СУБД, руководство «Борланд» решило, что разработка и дальнейшее развитие сервера нерационально, и выложило исходные коды на корпоративном портале под лицензией Open Source. Потом, однако, компания-производитель изменила свое решение, снова закрыла доступ к исходным кодам СУБД и чуть позже продолжила разработку. Отчасти, кстати, это было вызвано растущей популярностью Firebird. На сегодняшний день «Борланд» продолжает разработку InterBase с доступной на момент написания статьи версией 7.1. СУБД Firebird 1.0 являлась фактически исправленной версией InterBase 6.0 Open Edition. Поэтому первой полноценной, «чистой» версией Firebird можно считать версию 1.5.

Для не знакомого с сервером пользователя Firebird имеет две непривычных особенности. Первая — СУБД имеет две архитектуры, Сlassic и Super Server; вторая — наличие нескольких диалектов SQL, каждый из которых вносит свои особенности в работу. Рассмотрим сначала особенности архитектуры, а потом продвинемся к диалектам SQL и к тому, как они связаны с SQL Firebird.

Как уже говорилось, СУБД Firebird поставляется в двух вариантах, Classic Server и Super Server. Архитектура Classic Server может характеризоваться следующим образом каждому клиенту по собственному серверу. Это означает, что в классической архитектуре для каждого из клиентских подключений создается серверный процесс, обслуживающий одного клиента. Процессом запуска управляет внешний процесс, например, inetd или xinetd для ОС Unix.

Архитектура Super Server была разработана как направление для развития и разработки сервера Firebird в будущем. Даже компания «Борланд» еще до опубликования исходных кодов решительно заявляла о скором отказе от Classic Server и переходе на Super Server. Суперсервер обрабатывает все клиентские запросы в нескольких потоках одновременно внутри одного серверного процесса, и такая схема работы требует совсем немного ресурсов при создании новых подключений. Использование системных ресурсов и управление блокировками намного более эффективно происходит в архитектуре Суперсервер, потому что раздельные потоки не нуждаются в ожидании завершения обработки других потоков ядром сервера — это все происходит внутри одного процесса. Но при работе с сервером архитектуры Суперсервер программист должен учитывать, что любые пользовательские функции включая внешние программы, работающие с базой данных под управлением Суперсервера, должны быть написаны очень аккуратно и быть как можно более защищенными от сбоев, так как нарушения в их работе могут повлечь падение самого сервера и (возможно) нарушение целостности данных. Для тех, кто знаком с архитектурой СУБД Oracle, может быть проще разобраться с обработкой подключений, если рассматривать архитектуру Classic как соответствующую выделенным подключениям, в то время как работа Super Server больше походит на систему совместного использования подключений [9].

Средства доступа к серверу

Firebird поддерживает множество способов доступа, включая собственные наборы компонент для C/C++, Delphi, классы для Ada, ODBC, JDBC (Jaybird), драйверы для Python, PHP, драйвер OLE DB, dbExpress, провайдер данных .NET и прямой доступ с использованием клиентской библиотеки сервера (fbclient.dll или GDS32. dll).

Существует четыре различных взаимозаменяемых архитектуры сервера.

• · классик сервер (англ. ClassicServer) — один процесс на одно соединение; поддержка многопроцессорных машин;
• · суперсервер (англ. SuperServer) — все соединения используют один процесс, меньшие требования к памяти при большем быстродействии; для однопроцессорных машин;
• · суперклассик (англ. SuperClassic Server) — один процесс, но свой поток на каждое соединение. Данная архитектура введена в версии 2.5;
• · встраиваемая (англ. Embedded) версия — весь движок содержится в одной библиотеке с именем клиентской библиотеки сервера, идеально подходит для однопользовательских систем, не требует инсталляции.

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

IBExpert — GUI-оболочка, предназначенная для разработки и администрирования баз данных InterBase и Firebird, т. е. реляционная система управления базами данных .

Как основные достоинства IBExpert разработчики указывают.

• · поддержка InterBase версий 4. х, 5. х, 6. х, 7. х; Firebird 1. х, 2. x; Yaffil 1. х;
• · работа одновременно с несколькими базами данных;
• · отдельные редакторы для всех объектов БД с синтаксической подсветкой;
• · мощный SQL редактор с историей запросов и возможностью фонового выполнения запросов;
• · отладчик хранимых процедур и триггеров;
• · поиск в метаданных;
• · полное и частичное извлечение данных и метаданных;
• · анализатор зависимостей объектов баз данных;
• · отчеты по метаданным;
• · менеджеры пользователей и пользовательских привилегий;
• · экспорт данных в различные форматы.

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

Утилита IBExpert предназначена для администрации баз данных в СУБД Interbase и FireBird. Создание нового набора данных осуществляется с помощью пункта меню База данных/Создать базу.

В диалоговом окне, представленном на рисунке 2.1, вводится информация необходимая для создания базы данных.

Рисунок 2.1. Создание базы данных.

Раздел «Сервер» (удаленный/локальный) предназначен для выбора места создания файла базы данных. Выберите тип «локальный» для создания базы данных на локальной машине.

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

CREATE DATABASE 'd database est. gdb'.

USER 'SYSDBA' PASSWORD 'masterkey'.

PAGE_SIZE 16 384.

DEFAULT CHARACTER SET WIN1251;

В разделах «Имя сервера» и «протокол» вводится имя машины (например, A005), на которой расположен сервер баз данных Interbase или FireBird. Для локальной базы данных эти поля не нужны.

Поле вода «Файл БД» предназначен для указания пути к создаваемому файлу базы данных.

«Имя пользователя» — строка ввода имени администратора баз данных. По умолчанию администратором является пользователь с именем «SYSDBA», пароль — «masterkey».

В IB 6 появилось несколько расширений, как SQL так и типов данных, которые поддерживаются при помощи диалектов.

Диалект 1 — базы данных 4. x или 5. x, «импортированные» в 6.0 посредством backup в 4. x/5.x и restore в 6.0. Не содержат никаких отличий от 5.x. информационный автоматизированный база данный Диалект 2 — предназначен для проверки возможности перевода баз данных диалекта 1 в диалект 3.

Диалект 3 — «родной» формат IB 6, поддерживающий INT6, DATE, TIME, TIMESTAMP и прочие расширения.

Диалект 1 в версии 6 отличается от версии 5. x поддержкой следующих ключевых слов TIMESTAMP, TIME, EXTRACT, YEAR, MONTH, DAY, WEEKDAY, HOUR, MINUTE, SECONDS, ?TYPE?, CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP. Т. е. использование этих ключевых слов в качестве идентификаторов полей, таблиц и других объектов будет приводить к ошибке.

Кроме этого в диалекте 3 не поддерживается автоматическая конвертация типов в выражениях. Например, если раньше в SQL можно было написать 1+'3' и получить ответ 4, то в диалекте 3 будет выдано сообщение об ошибке.

Поле ввода «Кодировка» предназначена для выбора набора символов национального алфавита для текстовых полей базы данных. Русские символы Windows содержатся в кодировке Win1251.

Если файл базы данных перенесен на компьютер, где работает сервер БД, с другого компьютера (т.е. база данных существует, но сервер не имеет о ней информации), либо база данных создавалась на сервере, но при создании не была зарегистрирована (был выключен флажок «Регистрация базы данных (Register database)» при создании БД), то такую базу данных нужно регистрировать в утилите IB Expert. Это можно сделать с помощью экранной формы, показанной на рисунке 2.2.

Многие разделы формы совпадают с окном создания базы данных. Как минимум, необходимо заполнить поля «Описание базы данных» и «Версия сервера». Строка описания базы данных будет зафиксирована для идентификации вашего набора данных в окне «DataBase Explorer» оболочки IB Expert [10].

В разделе «Версия сервера» необходимо выбрать тип сервера, установленного на вашем компьютере (например, FireBird 1.5).

Рисунок 2.2. Регистрация базы данных в IB Expert.