Общая архитектура системы
На изображена общая архитектура СУБД Sedna , в которой выделяются следующие компоненты. Регулятор ( governer ) служит “управляющим центром” системы. Все остальные компоненты регистрируются у регулятора. Регулятор знает, с какими базами данных работает система, и отслеживает выполнение транзакций. Компонент слушатель ( listener ) создает для каждого нового авторизованного клиента экземпляр компонента подключение ( connection ) и устанавливает между ними прямую связь. В компоненте подключения инкапсулируется сессия клиента. Для каждой заявки клиента “начать транзакцию” (“ begin transaction ”) его компонент подключения создает экземпляр компонента транзакция ( transaction ). В этом компоненте инкапсулируются компоненты выполнения запросов: парсер ( parser ), оптимизатор ( optimizer ) и исполнитель ( executor ).
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Рис. 1. Архитектура СУБД Sedna
Парсер преобразует запрос в логическое представление, представляющее собой дерево операций, близких к тем, которые специфицированы в ядре XQuery ( XQuery Core ). Оптимизатор получает логическое представление запроса и производит план выполнения запроса, дерево низкоуровневых операций над физическими структурами данных. План выполнения интерпретируется исполнителем, который взаимодействует с соответствующим экземпляром менеджера базы данных.
В каждом экземпляре менеджера базы данных ( database manager ) инкапсулируется одна база данных. Менеджер базы данных включает менеджер индексов ( index manager ) , отслеживающий индексы, построенные над базой данных; менеджер буферов ( buffer manager ) , отвечающий за взаимодействия между дисковой и основной памятью; менеджер транзакций ( transaction manager ) , обеспечивающий корректность параллельного выполнения транзакций.
