Кострицкий ДС - InterBase/FireBird. Общие сведения.

InterBase/FireBird. Общие сведения.

Основные принципы построения БД

mail to: kostritsky@mail.ru
kostritsky@gmail.com

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

Сейчас вас ждет знакомство с новой СУБД под названием FireBird.Почему именно с ней. У неё есть несколько важных преимуществ:
1) Она бесплатная (в отличии от ACCESS)
2) Более профессиональная
3) Более надежна в плане безопасности
4)Кроме того она пользуется популярностью в мире. Правительство США использует именно её.

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

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

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

выражение IN (подзапрос)
выражение =ALL (подзапрос)
выражение =SOME (подзапрос)
выражение =ANY (подзапрос)

Вроде бы всё. Последние две конструкции -- полные синонимы, но ANY лучше не употреблять, особенно если хорошо знаете английский. Потому что штука весьма двусмысленная.
Во всех перечисленных конструкциях подзапрос может возвращать более одной записи. Хотя поле по-прежнему должно быть только одно. Так как сравнивается с одним значением внешнего запроса.
Некоторые граждане, в том числе в su.dbms.interbase, предлагали, в качестве доработки к IB сделать возможность извлекать несколько полей, и сравнивать их со списком значений за один приём. Чтож, операция действительно была бы полезна, но на суть того, что описано выше и ниже это не повлияет.
Далее о подзапросах первого вида будем говорить, что они существуют в скалярном контексте, а второго вида -- во множественном. Принципы терминологии взяты из языка Perl.
Кроме этого существует конструкция EXISTS(подзапрос), однако в нашем случае она не представляет интереса, о чём ниже. Всё то, что я написал в этом разделе может показаться второстепенным. Однако это совершенно не так, и у меня были веские основания начать именно с этого. Потому что обработка тех и других видов подзапросов в InterBase различается радикальным образом.

Распространённые заблуждения

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

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

Некоррелированный подзапрос выполняется один раз

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

Как оно работает на самом деле

Итак, вернёмся к нашим контекстам. В скалярном контексте InterBase действительно принимает во внимание, коррелированный подзапрос, или нет. Если нет, то запрос вызывается единожды, результат (одно значение) запоминается, и используется при отработке внешнего запроса примерно так же, как обычный параметр.
В списочном же контексте (чаще всего - в IN (...)), подзапрос всегда вызывается на каждую итерацию внешнего запроса. Точнее тогда, когда для текущей записи проверены прочие условия, чтобы исключить излишние вызовы. Провернуть предыдущую схему InterBase не в состоянии, вероятно по той причине, что запоминать придётся не одно значение, а список, причём потенциально неограниченной длинны.
Отсюда же следует, что если бы InterBase умел это делать, то мог бы достаточно легко преобразовывать множественные подзапросы в соединения, которые он как правило в состоянии реализовать достаточно эффективно. В самом деле, подзапрос внутри IN (...) возвращает таблицу с одним полем, и при дальнейшей обработке внешний запрос фактически соединяется с этой таблицей. Видимо у InterBase сложности с сохранением этой самой промежуточной таблицы, так что он предпочитает другую стратегию -- на каждой итерации вычислять те значения, которые ему требуются.
И вот здесь мы как раз и натыкаемся на достаточно оригинальную (на мой взгляд) оптимизацию. InterBase действительно вычисляет такие подзапросы помногу раз, но при этом учитывает контекст, так что порой достигается эффективность не уступающая раскрутке подзапроса в соединение. Хотя к сожалению это возможно далеко не во всех случаях.
Когда подзапрос вызывается конструкцией типа значение IN (select поле ...), то, если внимательно подумать, нам и не нужны все записи подзапроса. Нужно найти те, у которых поле имеет значение. А это значит, что оптимизатор может со спокойной душой добавить подзапросу в where дополнительное условие ...) and поле=значение. А это, в свою очередь вполне может привести к тому, что по данному полю будет использован индекс, или оно послужит основой для других способов оптимизации.
И кстати, данная оптимизация не делается для подзапросов в скалярном контексте. Они отрабатываются совершенно независимо. Хотя в них она могла быть тоже отнюдь не бесполезной. Ещё одна загадка природы.
И теперь настало время ещё раз вспомнить про EXISTS(...). По своей природе данная конструкция предназначена для вызова коррелированных подзапросов, и эти подзапросы внутри неё ведут себя в соответствии с вызовом во множественном контексте. Хотя выполнение каждого вызова, естественно, прекращается при получении первой же записи. Именно исходя из этого и следует оценивать трудоёмкость EXISTS.

Как оптимальное решение в качестве сервера баз данных предлагается InterBase фирмы "Borland". Эффективность выбора InterBase в качестве встроенного сервера баз данных обусловлена рядом характеристик:
использование архитектура множественных поколений записей (MGA - Multi-Generational Architecture) решает наиболее насущную проблему реализации серверов баз данных - проблему безблокировочного управления доступа к данным. Эта технология обеспечивает согласованность данных в случае сбоя и перезагрузки операционной системы. Использование MGA позволяет проводить резервное архивирование данных без остановки сервера и отключения пользователей. Оптимизация размеров базы данных достигается на основе автоматических механизмов "сборки мусора" (garbage collection) без необходимости периодически производить операции архивирования и восстановления;
наиболее точное соответствие входному уровню стандарта SQL-92 делает InterBase сервером, легко сочетающимся с другими продуктами и технологиями в области обработки данных;
нетребовательность InterBase к аппаратным ресурсам сервера уникальна для индустрии;
простота инсталляции и минимальные потребности в администрировании снимает с конечного пользователя существенную часть затрат, обусловленную содержанием высококвалифицированного штата администраторов баз данных.

Эти и другие возможности InterBase делают его идеальным сервером для использования в корпоративной среде и встраивания в тиражируемые программные комплексы.

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

1. Адекватность информации состоянию предметной области.
2. Надежность функционирования.
3. Быстродействие и производительность.
4. Простота и удобство использования (дружелюбность интерфейса).
5. Массовость использования.
6. Защита информации.
7. Возможность расширения.

Используемая литература:

http://www.ibase.ru
http://firebird.sourceforge.net
http://www.elprise.ru

Продолжение данной темы можно найти по следующей ссылке:

http://www.masters.donntu.ru/2007/fvti/benesko/