Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
Шрифт:
Помимо основных (major) версий ODS существуют еще вспомогательные (minor) версии, которые зависят от конкретной версии сервера базы данных, создавшего их. Основные номера версии записываются в целой части числа, которое обозначает версию, а минорные - в дробной. Например, версия сервера 4.0 создает базы данных, которые имеют ODS 8.0, a InterBase 4.2 - 8.2. Переход между минорными версиями "снизу вверх" осуществляется автоматически. Например, достаточно открыть базу с ODS 8.0, созданную сервером 4.0, при помощи InterBase 4.2 - и ODS этой базы будет иметь версию 8.2. Переход между основными версиями базы
Важным моментом в реализации поддержки ODS для версий InterBase 4.x и 5.x является совместимость серверов InterBase 4.x и InterBase 5.x с версией, на единицу меньшей, чем реализация конкретного сервера. InterBase поддерживает несколько возможных ODS и, в зависимости от ее версии ODS, при присоединении к конкретной базе данных выбирает поддержку нужной реализации ODS. Механизм принятия решения о том, какую реализацию поддержки ODS выбрать в данном конкретном случае, называется Y-Valve (автор Стива Тентона). Проще говоря, базу с ODS 8.x ("родной" для InterBase 4.0), можно открыть в InterBase 5.x и работать с ней.
Совместимость версий ODS идет "сверху вниз", т. е. сервер с более высокой версией и все его инструменты сумеют работать с базой данных, созданной ранними версиями сервера, но никак не наоборот. Попытавшись открыть базу, созданную в 6-й версии InterBase, при помощи InterBase 5.x, вы получите ошибку "Unsupported On-disk structure: Found ODS 10, supported ODS 9".
Также следует заметить, что бета-версия InterBase 6.0 поддерживала только ODS 10. В то же время Firebird 1.0 уже позволяет открывать базы как с ODS 8.хх, так и с 9.хх. Следует обратить внимание, что Firebird позволял только открывать базы данных с ODS 8 и 9, потому что гарантировать что-то при таком способе работы ничего нельзя. Т. е., несмотря на совместимость между версиями ODS "сверху вниз", перенос базы данных между версиями сервера лучше производить документированным способом.
Особенно важна версия ODS в вопросах, связанных с резервным копированием и извлечением базы данных, а также с восстановлением испорченных баз данных. Инструменты резервного копирования gbak и восстановления gfix следят за версией ODS и просто не станут работать, если версия ODS-базы, которую они должны обслуживать, больше версии, реализованной в них. Это значит, что gbak от 4.x не сможет создать резервную копию базы данных, если она создана сервером 5.x, однако наоборот - пожалуйста.
Мост между физической и логической структурой базы данных
Мы рассмотрели в общих чертах физическую структуру файлов базы данных. Теперь надо перейти к логической структуре базы данных. Чтобы переход произошел без каких-то "предельных переходов" в понятиях, оставив после себя ощущение непонятности материала и желание перечитать главу с самого начала, давайте построим некий логический "мост" между физическим и логическим уровнями представления информации в базе данных.
Все. что хранится на различных страницах базы данных,
Итак, попробуем рассмотреть процесс построения внутреннего образа базы данных.
* Сервер читает 1024 байта из начала файла и, если это действительно файл базы данных InterBase, определяет размер страницы этой базы и перечитывает всю заголовочную страницу целиком.
* С заголовочной страницы сервер извлекает номер страницы указателей, на которой хранятся ссылки на страницы данных, определяющие таблицу RDB$Pages.
* Сервер переходит к этой странице указателей и начинает считывать из указанных там страниц данных информацию. Он заполняет данными первую таблицу RDB$Pages. Эта таблица является чем-то вроде мостика между физическими объектами - страницами файлов базы данных и логическими - таблицами. Структура RDB$Pages, как и других системных таблиц, жестко "прошита" в InterBase.
* Получив данные о распределении страниц по отношениям (relations, в сущности, это то же самое, что и обычные таблицы, и для упрощения можно мысленно подменять эти понятия), InterBase начинает формировать структуры данных: сначала системные таблицы, ограничения и индексы, а потом уже пользовательские объекты.
* После инициализации системных и пользовательских метаданных (так называют таблицы, ограничения, индексы и все остальные объекты базы данных), InterBase возвращает пользователю, попросившему открыть базу данных, handle этой базы данных (некоторые используют термин "рукоятка" или просто транскрипцию английского слова - "хэндл"). В сущности, handle - это некоторый идентификатор, который указывает InterBase, с какой именно базой данных работать, поскольку одновременно могут работать несколько пользователей, а значит, могут быть открыты несколько баз данных.
* После этих операций база данных считается открытой и сервер готов выполнять запросы пользователей к ней.
Теперь, когда проложен некоторый "мост", связывающий физическую и логическую структуру базы данных, можно переходить к особенностям логической структуры.
Логическая структура базы данных InterBase
Логическая структура - понятие достаточно расплывчатое, поэтому мы попробуем постепенно освоить ключевые идеи, надеясь, что позже они создадут интуитивно понятное ощущение. Первое, что мы рассмотрим из относящегося к логической структуре базы данных, это системные таблицы и их содержимое.
Системные таблицы описывают метаданные, как системные, так и пользовательские. Вообще говоря, термин "метаданные" означает "данные, описывающие множество данных". Приставка "мета-" означает "описывает множество". Например, метаязык - это язык, описывающий множество языков. Метаданные описывают пользовательские данные, т. е. таблицы, триггеры, представления, хранимые процедуры и т. д.
– все, что реализует правила хранения и обработки той информации, ради хранения и обработки которой и создается конкретная база данных.