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

Понятие технологии сервера SQL

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

• организации данных — SQL позволяет определять и изменять структуру представления данных, а также устанавливать отношения;
• обработки данных — SQL позволяет изменять содержимое базы данных: добавлять новые данные, удалять или обновлять уже имеющиеся в ней данные;
• управления доступом — SQL позволяет ограничивать возможности пользователя по чтению и изменению данных (защита данных от несанкционированного доступа) и координировать их совместное использование пользователями, работающими параллельно.

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

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

Официальный стандарт языка SQL был опубликован Американским институтом национальных стандартов (ANSI) и Международной организацией по стандартам (International Standards Organization — ISO), а в 1992 г. значительно расширен. Стандарт X/OPEN для переносимой среды программирования на основе операционной системы UNIX также включает в себя SQL в качестве языка для доступа к базам данных. Консорциум поставщиков компьютерного оборудования и баз данных (SQL Access Group) определил для SQL стандартный интерфейс вызовов функций, который является основой протокола ODBC компании Microsoft и входит также в стандарт X/OPEN. Эти стандарты de facto являются официальным одобрением SQL, и именно они ускорили завоевание им рынка.
Многие из членов комитетов по стандартизации ANSI и ISO представляли фирмы — поставщиков различных СУБД, в каждой из которых был реализован собственный диалект SQL. Как и диалекты человеческого языка, диалекты SQL были в основном похожи друг на друга, однако несовместимы в деталях. Во многих случаях комитет просто игнорировал существующие различия и не стандартизировал некоторые части языка, определив, что они реализуются по усмотрению разработчика. Этот подход позволил объявить большое число реализаций SQL совместимыми со стандартом, однако сделал сам стандарт относительно слабым.

Организация SQL-сервера.

Физическая структура сервера. OLTP и DSS.

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

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

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

Один частный случай. В comp.databases.informix один из компьютерных экспертов, эксплуатировавших Informix на Sun Solaris утверждал, что несмотря на то что в Sun Solaris возможна реализация работы через raw devices, получаемая выгода невелика (прирост производительности составляет около ~20-30%). Это связано с тем, что по его словам, файловая система спроектирована достаточно эффективно. Также, он предупредил, что потенциальные проблемы могут перекрыть получившуюся выгоду, при этом описывалась ситуация, когда из-за ошибки при инсталляции на "сырой" раздел могла уничтожаться таблица разделов жесткого диска.

Raw access применяется для работы с OLTP. OLTP(Online Transaction Processing) - онлайновая обработка транзакций. Это такой способ организации работы СУБД при котором система работает с транзакциями небольшими по размерам, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа.

Примером может служить процессинговый центр банка по операциям с платежными картами. Данные информационной транзакции невелики - номер карты, номер банкомата, запрашиваемая сумма умещаются в 100-200 байт, но банкоматов и торговых точек, подключенных к платежной системе, может быть очень много (тысячи штук), поэтому количество транзакций также может быть очень большим. В особенности это касается пиковых часов, после окончания рабочего дня, когда люди идут по магазинам. И при этом система должна сохранять время ответа в пределах нескольких секунд!

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

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

Есть еще ряд специфичных приложений в которых работают сервера СУБД.

К ним относятся BPS (Batch processing System) - системы пакетной обработки. Принцип очень похож на работу старых компьютеров: есть некоторая очередь заданий, каждое из заданий выполняется с полным доступом к ресурсам и максимальной эффективностью.

Более интересным и современным является использование серверов СУБД в качестве медиасерверов MMS(Multi Media Servers), т.е. сервер используется для предоставления пользователям доступа к аудио и видео информации. Задача сервера СУБД в данном случае - обеспечение непрерывности мультимедиа потока во избежание рывков видео и прерывания звука вплоть до уровня передачи в канал.

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

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

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

Таблица - это основная единица хранения информации в системе. Таблицы в базе данных хранят все пользовательские данные. Кроме того, в системе есть специальные таблицы, к которым в обычных условиях пользователи доступа не имеют или имеют его только на чтение. Это системные таблицы(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.

Не нашли, что искали? Воспользуйтесь поиском по сайту: