Многопользовательские субд и языки баз данных

Модели данных

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

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

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

Модель данных можно рассматривать как сочетание трех указанных ниже компонентов:

структурной части – набора правил, по которым может быть построена база данных;

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

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

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

Для трехуровневой архитектуры существуют следующие три связанные модели данных (объектные модели):

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

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

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

Концептуальная модель данных создается с помощью CASE-средства Silverrun ERX (ER – модель). Она содержит сущности, связи, атрибуты.

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

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

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

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

Существует три основных типа записей, определяющие три типа моделей: реляционная модель данных (relational data model); сетевая модель данных (network data model); иерархическая модель данных (hierarchical data model).

В реляционной модели данных единственное требование состоит в том, чтобы база данных с точки зрения пользователя выглядела как набор таблиц. Это требование относится только к внешнему и концептуальному уровням архитектуры ANSI/SPARC. В сетевой модели данные представлены в виде коллекций записей, а связи – в виде наборов (см. рис.5). Сетевую модель можно представить как граф с записями в виде узлов (вершин) графа, и наборов данных в виде его ребер. Иерархическая модель данных является подтипом сетевой модели. В ней данные представлены как коллекции записей, а связи – как наборы (см. рис.6). Однако узел может иметь только одного родителя.

Функции СУБД

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

Каталог, доступный конечным пользователям. СУБД должна иметь доступный конечным пользователям каталог, в котором хранится описание элементов данных, а также сами данные. Такой каталог называется системным – каталогом метаданных. C:\DATA\IB\ sqledu01 это каталог данных

Поддержка транзакций. СУБД должна иметь механизм, который гарантирует выполнение либо всех операций обновления данной транзакции, либо ни одной из них. Transaction = Transformation action. Например, добавление нового сотрудника в базу данных. Если во время выполнения транзакции произойдет сбой, например из-за выхода из строя компьютера, база данных попадает в противоречивое состояние, поскольку некоторые изменения уже будут внесены, а остальные – еще нет. Поэтому все частичные изменения должны быть отменены для возвращения базы данных в прежнее, непротиворечивое состояние.

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

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

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

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

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

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

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

Понятие целостности данных

Ограничения целостности данных представляют собой такие ограничения, которые вводятся с целью предотвратить помещение в базу противоречивых данных. Рассмотрение вопросов целостности данных является обязательным на внешнем уровне представления БД, Полное и точное представление пользователя можно получить только после определения ограничений, необходимых с точки зрения сохранения целостности данных. Существует пять типов ограничений целостности данных: обязательные данные; ограничения для атрибутов; целостность сущностей; ссылочная целостность; требования данного предприятия. Обязательные данные – некоторые атрибуты всегда должны содержать одно из допустимых значений. Эти атрибуты не могут иметь пустого значения. Так, каждый работник должен занимать ту или иную должность. Ограничения для атрибутов – каждый атрибут должен иметь набор допустимых значений. Набор допустимых значений атрибута носит название домен. Например, атрибут «Пол» имеет домен, состоящий из двух допустимых значений «М» и «Ж». Целостность сущностей – первичный ключ любой сущности не может содержать пустого значения. Сущность «отдел» должна содержать уникальное значение атрибута первичного ключа – «No отдела». Первичный ключ – это атрибут, который выбран для уникальной идентификации записей БД (в отношении). Ссылочная целостность – внешний ключ связывает каждую строку зависимого отношения с той строкой первичного отношения, которая содержит это же значение соответствующего первичного ключа. Понятие ссылочной целостности означает, что если внешний ключ содержит некоторое значение, то оно обязательно должно присутствовать в первичном ключе одной из строк родительского отношения. Каждый работник работает в одном из отделов предприятия. Требования данного предприятия – ограничения предприятия называются бизнес-правилами. Один работник не может участвовать в выполнении более трех проектов.

Компоненты СУБД

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

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

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

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

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

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

Компилятор языка DDL преобразует DDL-команды в набор действий по созданию таблиц, содержащих метаданные. Затем эти таблицы сохраняются в системном каталоге.

Контроллер словаря управляет доступом к системному каталогу и обеспечивает работу с ним. Системный каталог доступен большинству компонентов СУБД.

 

Языки баз данных

Внутренний язык СУБД для работы с данными состоит из двух частей: языка определения данных (DDL) и языка управления данными (DML). Язык DDL используется для определения схемы базы данных, а язык DML – для чтения и обновления данных, хранимых в базе. Эти языки называются подъязыками данных, поскольку в них отсутствуют конструкции для выполнения всех вычислительных операций, обычно используемых в языках программирования высокого уровня. Во многих СУБД предусмотрена возможность внедрения операторов подъязыка данных в программы, написанные на таких языках программирования высокого уровня, как Pascal или C. В этом случае язык высокого уровня принято называть базовым языком (host language). Перед компиляцией файла программы на базовом языке эти операторы подъязыка предварительно удаляются и заменяются на вызовы соответствующих функций СУБД. Затем этот предварительно обработанный файл компилируется обычным образом в объектный модуль, который затем компонуется с библиотекой, содержащей вызываемые в программе функции СУБД.

Язык определения данных – DDL, является описательным языком, который позволяет АБД или пользователю описать и поименовать сущности, необходимые для работы некоторого приложения, а также связи, имеющиеся между различными сущностями. Схема базы данных состоит из набора определений, выраженных на специальных языке определения данных – DDL. Язык DDL используется как для определения новой схемы, так и для модификации уже существующей. Этот язык нельзя использовать для управления данными. Результатом компиляции DDL-операторов является набор таблиц, хранимых в особых файлах, в которых хранятся данные, описывающие объекты базы данных – метаданные. Такой особый файл называется системным каталогом (иногда каталогом данных). Метаданные включают определения записей элементов данных, а также другие объекты, необходимые пользователям или для работы СУБД. Перед доступом к реальным данным, СУБД обычно обращается к системному каталогу.

Язык управления данными – DML, это язык, содержащий набор операторов для поддержки основных операций манипулирования данными, содержащимися в базе.

К операциям управления данными относятся: вставка в базу данных новых сведений; модификация сведений, хранимых в базе данных; извлечение сведений, содержащихся в базе данных; удаление сведений из базы данных.

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

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

 

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

Непроцедурные языки DML – это языки, которые позволяют указать лишь то, какие данные требуются, но не то, как их следует извлекать. Непроцедурные языки позволяют определить весь набор требуемых данных с помощью одного оператора извлечения или обновления. С помощью этих языков пользователь указывает, какие данные ему нужны без определения способа их получения. СУБД транслирует выражение на языке DML в процедуру (или набор процедур), которая обеспечивает манипулирование затребованным набором записей. Данный подход освобождает пользователя от необходимости знать детали внутренней реализации структур данных и особенности алгоритмов, используемых для извлечения и возможного преобразования данных. В результате работа пользователя получает определенную степень независимости от данных. Непроцедурные языки часто также называют декларативными языками. Реляционные СУБД обычно включают поддержку непроцедурных языков DML – чаще всего это бывает язык структурированных запросов SQL или язык запросов по образцу QBE (Query-by-Example). Непроцедурные языки обычно проще понимать и использовать, чем процедурные языки DML, поскольку пользователем выполняется меньшая часть работы, а СУБД – большая.

Использование SILVERRUN-BPM

Для моделирования процессов предметной области целесообразно использовать CASE- средство SILVERRUN-BPM (Business Process Modeling).

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

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

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

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

Компания занимается реализацией комплектующих для персональных компьютеров. Назначение разрабатываемого приложения: помощь компании в заключении договоров с клиентами на покупку комплектующих. Название приложения DEALER.

Назначение приложения — система DEALER обслуживает процесс торговли.

Функции приложения:

система регистрирует и хранит сведения о покупателях;

система регистрирует и хранит полные сведения о комплектующих для ПК;

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

Контекстная диаграмма

Анализ предметной области начинается с создания контекстной диаграммы с помощью CASE- средства SILVERRUN- BPM.

Основные элементы диаграмм CASE- средства SILVERRUN-BPM: Внешние объекты Процессы Потоки информации Накопители

Детализирующая диаграмма

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

Анализ информационных потоков показывает, что в модели должны быть три накопителя (рис.36):

складе

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

 

CONTENT QTY Количество покупаемых комплектующих

CONTENT SUMСебестоимость покупаемых комплектующих

Кроме того, с каждым накопителем необходимо связать структуру данных, которые будут в них храниться. На этом этапе следует определить все сущности и их атрибуты.

С накопителем CLIENT следует связать сущность CLIENT (табл. 23).

С накопителем DOGOV следует связать две сущности – DOGOV и CONTENT (табл. 24), при этом сущность CONTENT необходимо сделать слабой, т. к. перечень приобретаемых комплектующих не может существовать без (наличия) договора. Поэтому в структуре данных DOGOV необходимо предусмотреть подструктуру CONTENT.

После определения указанных выше объектов модели необходимо запустить на выполнение SILVERRUN-BPM и создать в нем концептуальную модель данных.

Использование SILVERRUN-ERX

CASE-инструмент SILVERRUN-ERX используется для построения ER диаграмм проектируемой БД.

Предусмотрена возможность построения этой диаграммы на основе структур данных, созданных на предыдущем этапе CASE-средством SILVERRUN-BPM. Необходимые данные извлекаются из словаря данных системы SILVERRUN.

Создание ER диаграммы являются первым шагом на пути разработки логической диаграммы БД.

Работа с CASE-инструментом SILVERRUN-ERX выполняется в следующем порядке:

После запуска на выполнение программы SILVERRUN-ERX необходимо из словаря данных системы загрузить информацию о всех структурах данных, созданных в SILVERRUN-BPM.

Для этого необходимо выполнить команду Util → WRM Dictionary. В главном меню должен появиться пункт WRM — Dictionary. С помощью этого пункта меню надо открыть словарь, созданный на предыдущем этапе. Для этого выполнить команду

WRM – Dictionary → Open WRM Dictionary

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

После этого следует изменить модель для использования ее SILVERRUN-ERX. Для этого необходимо выполнить команду

WRM – Dictionary → UpDate a Model,

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

Далее надо закрыть окно работы со словарем, выполнив команду WRM Dictionary → Close.

Затем необходимо в SILVERRUN–BPM поместить из преобразованной модели все структуры данных БД.

Следует выполнить команду меню Presentation → Pallets → Component: SR Store. Откроется окно с именами всех структур данных, созданных ранее. Щелкая правой кнопкой на каждой структуре данных, необходимо, удерживая кнопку нажатой, перетащить все структуры по очереди в окно SILVERRUN-ERX. Они все будут сосредоточены в центре окна. Поэтому их необходимо растащить и поместить каждую отдельно.

Начиная с этого момента, дальнейшую работу должен выполнять эксперт системы SILVERRUN-ERX. Поэтому необходимо выполнить команду меню Expert → Expert Mode, чтобы начал работу эксперт.

В начале эксперт должен нормализовать разработанную модель. Для этого следует выполнить команду Expert → Normalize Model. В результате действий по нормализации модели диаграмма изменится за счет возможного проявления дополнительных сущностей и связей между ними. Здесь снова необходимо растащить сущности и расположить их в удобном для вас порядке.

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

При ручной корректировке необходимо дважды щелкать на связях, кардинальность которых надо изменить и затем в открывшемся окне заменять данные в полях Min и Max. Необходимо также определить слабые сущности (около них надпись 1,1 выделена жирным шрифтом).

Эксперт может также проверить, все ли сущности имеют идентификаторы (ключевые атрибуты). Для этого нужно выполнить команду Expert → Search for Identifiers.

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

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

Для этого надо дважды щелкать на сущностях и в открывшемся окне заполнять внизу поле “Coded Name” для каждого выделяемого атрибута.

Наконец, необходимо сохранить разработанную модель в.erx файле, выполнив команду меню File → Save Model As (под именем dealer.erx).

Рис. 37. ER диаграмма системы Dealer

На рис.37 показана разработанная с помощью СASE-средства Silverrun-ERX ER диаграмма системы Dealer.

Использование SILVERRUN-RDM

С помощью SILVERRUN-RDM осуществляется создание логической диаграммы проектируемой БД, а также физической диаграммы с учетом конкретной используемой СУБД. Работа завершается созданием сценария, создания разрабатываемой БД на языке SQL. Этот сценарий затем можно выполнить в IBExpert’e и создать все таблицы и их атрибуты для СУБД InterBase.

Порядок работы с CASE-инструментом SILVERRUN-RDM.

Вначале ER модель надо преобразовать в логическую модель. Для этого следует запустить на выполнение приложение ERX-RDM Bridge. Затем следует нажать клавиши Alt-T и в диалоговом окне выбора файлов выбрать.erx файл для разрабатываемой БД (dealer.erx).

Новую модель надо сохранить в.rdm файле (под именем dealer.rdm). Затем необходимо закрыть приложение ERX-RDM Bridge.

Далее следует открыть приложение SILVERRUN-RDM и, выполнив команду меню File → Open, загрузить в него.rdm файл, созданный в предыдущем пункте. При этом будет открыто диалоговое окно выбора СУБД. Выбрать в нем строку IntrBase → IntrBase 4.1.

После загрузки.rdm файла, в окне редактора появится логическая диаграмма БД.

Затем необходимо сгенерировать типы данных (домены) для выбранной СУБД (InterBase).

Необходимо выполнить команду Projects → Target Systems.

В открывшемся окне следует выбрать (выделить) строку “ InterBase 4.1” и щелкнуть на кнопке Generate. Будут сгенерированы все типы доменов для выбранной СУБД.

Чтобы проверить, имеются ли сгенерированные данные, необходимо выполнить команду Projects → Domains. Будет выведен список всех типов данных для применяемой СУБД.

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

…

в поле Domain. После щелчка по этой кнопке откроется окно с перечнем возможных типов. Необходимо выделить нужный для данного атрибута тип и щелкнуть на кнопке ОК. Будет выполнен возврат к предыдущему окну, в котором необходимо определить, является ли данный атрибут обязательным к заполнению или нет (поле Null Value Possible), а также длину атрибута типа Char и VarChar.

После этого необходимо сгенерировать внешние ключи для всех таблиц. Необходимо выполнить команду Tools → Foreign Keys → Generate.

Далее следует выбрать в открывшемся окне строку «All Keys» и нажать ОК.

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

Для этого необходимо выполнить команду Tools → Generate → Direction Rules.

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

Tools → Generate → Сoded Names.

В открывшемся окне со списком возможных элементов необходимо выделить три строки

Combination (foreign)

Combination (other)

Combination (primary)

и установить для них тип «Partial». После этого необходимо нажать кнопку Generate.

На следующем шаге необходимо проверить целостность разработанной физической модели БД, выполнив команду Tools → Verify Integrity.

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

На следующем шаге надо определить владельца создаваемых таблиц БД.

Выполнить команду Project → Users и ввести имя «Администратор БД» и кодированное имя SYSDBA. Затем щелкать на прямоугольнике с именем каждой таблицы и устанавливать для них с помощью выпадающего списка имя «Администратор БД» в поле «Owner».

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

Далее следует выполнить команду Tools → Target System PlugIns → Forward Engineering.

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

В третьем окне необходимо выбрать слева имя SYSDBA, тогда справа должны появиться имена всех таблиц БД. Далее следует нажать кнопку Generate и сохранить сценарий в файле с необходимым именем (dealer.sql).

Рис. 38. Реляционная диаграмма системы Dealer

На рис. 38 представлена реляционная диаграмма системы Dealer.

Реляционные базы данных и СУБД InterBase

СУБД InterBase, ее основные возможности и область применения

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

В июле 2000 г фирма Borland выпустила версию InterBase 6.0 Open Edition с открытыми исходными кодами. Сразу после этого большая группа профессиональных разработчиков создала проект Firebird с открытыми исходными кодами, который явился первым в новом поколении потомков InterBase. В настоящее время проект Firebird, его разработчики, в группу которых входят добровольцы и наемные специалисты, получающие финансирование из сообщества и коммерческих источников, никак не связан с компанией Borland.

Несмотря на свою простоту, этот сервер сочетает в себе огромный спектр возможностей:

- InterBase является кроссплатформенным продуктом, поддерживающим большое количество различных операционных систем, включая MS Windows всех разновидностей, Linux и несколько Unix-платформ;

- InterBase отличается чрезвычайно низкими системными требованиями и при этом высокой производительностью и легкостью администрирования. С сервером InterBase можно работать, используя несколько сетевых протоколов:TCP/IP, NetBEUI, IPX/SPX;

- одной из основных особенностей сервера InterBase можно считать версионную архитектуру, которая обеспечивает уникальные возможности при многопользовательской работе — пишущие пользователи никогда не блокируют читающих. Версионная архитектура позволяет также отказаться от использования протоколов транзакции (transaction log), которые в других СУБД служат для восстановления БД после сбоев. СУБД InterBase автоматически восстанавливает в таких случаях целостность БД при очередном запуске на выполнение сервера СУБД;

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

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

- некоторые механизмы, такие, например, как двухфазное подтверждение транзакции, до сих пор остаются совершенно уникальными, представленными только в сервере InterBase;

- немаловажной особенностью сервера InterBase является возможность расширения стандартного набора SQL-функций при помощи пользовательских библиотек – UDF (User Defined Function), а так же механизмы обработки BLOB полей (Binary Large Objects) на сервере при помощи BLOB-фильтров;

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

Имеется семейство серверов InterBase, так как на сегодняшний день существует несколько клонов, основанных на исходном коде Borland InterBase 6.0, Borland InterBase версии 6.0, 6.5 и 7.0, Firebird версии 1.x и Yaffil1.0. Все указанные продукты имеют много общего.

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

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

Среди самых известных и популярных можно перечислить IBExpert, Ems Quick-Desk, IBAdmin.

Типы данных

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

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

В InterBase существует 12 типов данных, которые подразделяются на 6 следующих групп:

- для хранения целых чисел – Integer и Smallint;

- для хранения вещественных чисел – Float и Double Precision;

- для чисел с фиксированной точностью;

- для хранения даты, времени и даты / времени – Date, Time и Timestamp;

- для хранения символов – Character (сокращенно Char) и Varying Character (сокращенно Varchar);

- для хранения большого массива данных – BLOB (Binary Large Objects).

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

Целочисленные типы

К ним относятся Smallint и Integer. Smallint имеет длину 2 байта, Integer – 4 байта.

Область применения целочисленных типов: они нужны для полей, содержащих только целые числа (для хранения счетчиков, количества деталей и пр.). Обычно тип Integer имеют также поля, содержащие первичные ключи.

Вещественные типы данных

Это типы для чисел с плавающей точкой – Float и Double Precision. Тип Float имеет недостаточную точность для хранения большинства дробных значений. Не рекомендуется хранить в нем денежные величины – в переменных этого типа очень быстро нарастают ошибки округления, что может сильно удивить бухгалтера при подведении итогов. Поэтому лучшим выбором для хранения чисел в бухгалтерских системах или в системах для научных расчетов будет тип Double Precision.

Тип данных BLOB

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

У типа BLOB имеется возможность определять набор нескольких подтипов и специальных процедур, называемых фильтрами (BLOB filters), для работы с этими подтипами. В InterBase имеются подтипы:

subtype 0 — данные неопределенного типа,

subtype 1 — текст,

subtype 2 – BLR(Binary Language Representation) — это двоичное представление хранимых процедур, триггеров, запросов к серверу. Объем неограничен.

Массивы

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

Массивы реализованы на базе полей типа BLOB.

Они предоставляют удобный механизм для хранения однотипных объектов. Однако в большинстве случаев вместо массивов разработчики предпочитают держать множественные данные в подчиненных таблицах (master/detail).

Представления

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

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

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

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

Чтобы создать представление необходимо использовать предложение:

CREATE VIEW viewname [(view_column [, view_column...])]