Логическая структура сервера. Составные компоненты.

Логическая структура СУБД - это те объекты СУБД, которыми сервер СУБД непосредственно манипулирует, но не в контексте операционной системы, а контексте базы данных и которые "видны" пользователю (таблицы, представления, индексы, кластеры, сохраненные процедуры и прочие).

Таблица - это основная единица хранения информации в системе. Таблицы в базе данных хранят все пользовательские данные. Кроме того, в системе есть специальные таблицы, к которым в обычных условиях пользователи доступа не имеют или имеют его только на чтение. Это системные таблицы(data dictionary (словарь данных) в терминологии Oracle и SMI (System Management Interface (интерфейс управления системой)) в терминологии Informix), в которых описана логическая структура всей СУБД, в частности, содержатся параметры пользователей, их права доступа, структуры пользовательских таблиц, тексты сохраненных процедур, триггеров и пр.

Данные в таблице хранятся в строках и столбцах. Каждый столбец имеет свое имя и присвоенный столбцу тип данных. Данные в столбце могут быть только одного типа, т.е. если столбец хранит данные типа DATE, то в него нельзя вставить данные типа FLOAT. Строка в таблице, по своей сути сходна с записью данных в файле DBF.

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

Insert into my_table (column_int)values (911); и Insert into my_table (column_int)values ('911');

С таблицами связаны правила целостности данных (data integrity rules), которые определяются ограничителями (constraint) и триггерами (trigger). О них речь пойдет дальше.

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

Представления часто используются для того, чтобы:

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

· Упростить представление данных, т.к. пользователь работает с представлением как с единой таблицей, в то время как оно может ссылаться одновременно на несколько таблиц.

· Выполнять дополнительную обработку данных из таблиц, скрывая ее от пользователя.

Использование представлений зависит от реализации SQL-сервера. В некоторых системах с представлениями можно работать только на чтение.

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

Синонимы - это алиасы для таблицы, представления или программного модуля. Синоним это ссылка на объект. Он используется для того, чтобы скрыть реальное имя объекта или реального пользователя объекта, обеспечения общего доступа к объекту или прозрачности доступа к объектам удаленной базы данных. Краткий пример - пользовательская программа выполняет запрос из некоторой таблицы XYZ. Если у нас в системе есть синоним XYZ, который указывает на самом деле на таблицу ABC в схеме пользователя JUSTAS на сервере rhka.org , то используется именно таблица JUSTAS.ABC, а не какая-то другая. Предположим, администратор решил вынести таблицу ABC в схему пользователя ALEX на другой сервер по имени center.com. Чтобы не переписывать клиентские программы администратор пересоздает синоним XYZ, который теперь указывает на ALEX.ABC@center.com. Клиентские программы в этом случае работают с данными с другого сервера. Понятно, что для успешной работы клиентской программы структура обоих таблиц должна совпадать.

Индексы создаются для ускоренного поиска по таблице. В целом идеология совпадает с идеями использования индексов в DBF-технологиях, за исключением того, что в случае с SQL, сервер целиком управляет индексом при операциях с таблицей (удаление/вставка/модификация) и нет необходимости специально перестраивать или корректировать индексы. Более того, при обработке запроса SQL-сервер сам может выбирать подходящий индекс из доступных для данной таблицы. Например, таблица XYZ содержит столбцы A,B,C,D,E,F,G и имеет 3 индекса по полям A,B,C затем D,E,F и F,G. При запросе select a,b,c from xyz будет задействован первый индекс. При запросе select f,g from xyz будет задействован третий индекс. При запросе select a,g from xyz индексы не будут задействованы вообще (строго говоря, это зависит от реализации), но запрос отработается, хотя и с меньшей скоростью. Последний случай крайне нежелателен в случае, если таблица содержит несколько сотен тысяч строк, в этом случае замедление будет очень заметно. Но обычно запросы, с которыми клиентские программы работают с сервером, известны заранее, поэтому на сервере должен быть создан соответствующий индекс.

Индексирование поддерживается всеми SQL-серверами.

Кластер (cluster). Предположим, что есть группа независимых таблиц, между которыми есть некоторая логическая связь. Например, одна таблица содержит характеристики клиентов, вторая содержит описания заказов этих клиентов , Наличие этой связи приводит к тому, что вероятность одновременного запроса данных из нескольких таблиц этой группы весьма велика. В случае если таблицы большие по размерам, то при отдельном их хранении на диске, суммарное время запроса также будет большим. Чтобы этого избежать применяется связка таблиц в кластеры. В кластере строки из разных таблиц чередуются. Такое хранение приводит к тому, что суммарное время запроса по нескольким таблицам существенно уменьшается. Для дальнейшего увеличения скорости запросов может использоваться индексирование или хеширование кластера. Использование кластеров зависит от реализации SQL-сервера. Они поддерживаются как Oracle7, так и Infromix DS. Практически кластеры используются редко, это связано с рядом ограничений.

Последовательность (sequence). Этот объект СУБД специфичен для Oracle. Последовательности представляют собой специальные объекты базы данных для генерации последовательных значений. Каждое следующее обращение к последовательности увеличивает ее текущее значение на шаг, определяемый при создании последовательности. Использование последовательностей зависит от реализации SQL-сервера. В Infromix DS последовательностей нет. Там используется специальный тип данных SERIAL, который при последовательной вставке в таблицу генерирует только целочисленные значения с шагом 1.