Эволюция серверов бд

Централизованная архитектура сервера БД

Характерно: функции сервера и прикладной программы совмещаются в единственном приложении. Практически эти функции не разделены.

Функции управления данными на следующем этапе выделяются в отдельное приложение. Появляется следующая стуктура:

Хотя сервер выделен в отдельную часть, ПП и сервер на одном том же компьютере. Данная архитектура получила название «Архитектура один-к-одному». Программные средства, реализующие серверные функции тиражируются. Тем не менее, этот шаг был важен, потому что появилась возможность перейти к следующему этапу – размещение ПП и сервера на разных компьютерах. Тиражирование осталось.

Дальше все серверные части сведены в единственное приложение, которые исполняется на отдельном компьютере и каждая прикладная программа связана с сервера отдельным потоком (нитью).

Сервер – единственное приложение и исполняется на отдельном процессоре. При многопроцессорной технике – мощности используются неэффективно.

Дальнейшее развитие – замена выделенного сервера на специальный диспетчер (виртуальный сервер).

Диспетчер теряет право распоряжаться данными и выполняет функции распределения запросов между СП.

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

Многопользовательская многопотоковая мультисерверная архитектура.

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

Самая современная и сама используемая.

Концепция активного сервера в составе современных информационных систем.

Основное требование для ИС:

1. Вся информация в их составе должна быть актуальной и обеспечение принципов целостности БД. Вся информация должна в любой момент времени соответствовать действительности.

2. БД должна отражать не только информацию структуру, но и функционал (правила и законы, по которым функционирует предметная область).

3. Постоянный контроль за состоянием информации в БД. Реакция со стороны контролирующих систем при изменениях.

4. Необходимо, чтобы при возникновении некоторой ситуации была определенная обработка этой ситуации.

5. Одной из проблем является преобразование и отслеживание типов данных.

Как эти проблемы решить в обычных ИС без активного сервера

(технология пассивного сервера или традиционная)

Знание или прикладная информация о предметной области реализуется с помощью обычных языков программирования высокого уровня. То есть прикладная часть фактически для предметной области пишется на обычных процедурных языках. Есть недостатки:

1. Реализация этих алгоритмов и правил перегружает прикладную часть программного обеспечения.

2. При изменении законов предметной области необходимо дорабатывать или изменять разработанное ранее.

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

Задача синхронизация взаимодействия нескольких прикладных программ с БД. Надо писать определенные функции, то есть практически вручную синхронизируется взаимодействие программ.

Преобразование типов данных. Зависит от того языка, на котором всё написано. Может возникать некорректное преобразование и прочее.

Итог:

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

Чтобы устранить недостатки, разработана концепция активного сервера.

Основные положения концепции активного сервера.

Концепция АС образует третье поколение серверов БД.

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

Концепция АС включает в себя 4 основных положения или момента:

1. Специальные процедуры БД

2. В отдельную часть выносится понятие «событие в БД»

3. Правила (триггеры), которые исполняются почти всегда по определенному событию.

4. Типы данных, которые задаются пользователем (определяются на этапе эксплуатации ИС).

14122011

Процедуры в составе активного сервера.

Название разное в разных источниках информации – хранимые, перемещаемые. Реализованы на диалекте SQL и являются частью сервера БД.

Включение этих процедур преследует несколько базовых целей:

1. С помощью данной технологии достигает новый независимый уровень централизации (упрощение контроля за прикладной частью со стороны администратора БД).

2. Каждая процедура может быть неоднократно использована различными пользователями. При этом (поскольку процедура входит в состав БД) скрипт SQL программы инициализируется, компилируется и прочее только один раз (в момент записи процедуры в программу).

3. Использование процедур данного типа значительно сокращает загруженность локальной сети (трафик). Так как обычно передаются сами SQL запросы, а в активного сервере передается только вызов процедуры.

4. Хранимые процедуры совместно с другими элементами активного сервера позволяют увеличить вероятность сохранения целостности БД.

Как правило, состав и синтаксис языка SQL, на котором реализованы процедуры, отличаются от стандартного языка SQL-запросов (язык описательный становится языком процедур).

Правила в составе БД

Механизм правил или триггеров позволяет тем или иным образом программировать обработку определенных ситуаций, который возникают в БД.

Правила или триггеры подключаются либо к отдельным таблицам БД, либо к отдельным элементам таблиц (это содержимая информация в отдельных столбцах БД).

На всю таблицу: в этом случае правила программируются на определение ситуации в случае изменения информации в таблицы (добавление новой строчки, удаление и так далее).

К отдельным элементам: с помощью правил определяется реакция на изменение значения определенного реквизита таблицы.

Примеры: стандартная ситуация – разработка БД для производственного предприятия. В реальном производстве может возникнуть ситуация: в БД храниться кол-во элементов на складе. Если реальное количество превышает минимального запаса – то всё нормально. А если стало меньше или нуль – при изменении значения срабатывает правило – предупреждение или самостоятельный заказ.

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

Правила разрабатываются и программируются на том же диалекте SQL, что и переносимые процедуры.

Исторически первые появились.

Понятие «событие» в БД

Механизм событий в БД позволяет прикладным программам и серверу БД уведомлять другие программы о наступлении некоторого события. Данный механизм позволяет синхронизировать работы БД и прикладных программ. Механизм событий предполагает использование двух элементов: во-первых, определение (описание) возможного события – заданно, как и в ПП, так и в процедуре сервера; во-вторых, каждое событие регистрируется для определенных прикладных программ.

При наступлении ситуации, заданной описанием события, сервер автоматически передаёт уведомление всем прикладным программам, в которых это событие зарегистрировано. Каждая прикладная программа реагирует на событие определенным образом, заданным при разработке программного средства.

Механизм событий совместно с правилами и переносимыми процедурами обеспечивают главное качество БД – это целостность информации.

Типы данных, определяемые пользователем.

Использует достаточно редко. На этапе эксплуатации БД пользователь может задать или описать тип данных, который требуется в повседневной работе.

Как правило, это возможно в тех случаях, когда пользователям предоставляются дополнительные средства (конфигурирование в 1С).