Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Shpory_po_BD.doc
Скачиваний:
4
Добавлен:
22.09.2019
Размер:
1.37 Mб
Скачать

25.Требования к современным субд. Активный сервер

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

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

  1. Данные должны быть взаимно непротиворечивыми;

  2. Постоянный контроль за состоянием базы данных, отслеживание всех изменений и адекватная реакция на них (например, в АСУ производством контролировать температуру процесса, при превышении отключить / включить прибор / станок / установку).

  3. Возникновение некоторой ситуации в базе данных должно оперативно влиять на ход выполнения прикладной программы (синхронизация задач).

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

  1. реализация правил перегружает прикладную программу, усложняет ее написание и понимание;

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

  3. правила не должны противоречить друг другу, особенно это важно, когда их реализует группа разработчиков. Фактически правила должен формулировать и контролировать один человек - администратор базы данных.

Таким образом, включение правил в прикладные программы представляет собой устаревшую технологию. Она приводит к большим накладным расходам при изменении правил и не обеспечивает централизованный контроль за их непротиворечивостью. Эта технология имеет в своей основе RDA-модель.

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

  1. программа опрашивает базу через интервалы времени, которые определяет программист, следовательно, если в базе происходят какие-либо изменения, то они выявляются не сразу, а через какое-то время, то есть не обеспечивается оперативность оповещения в прикладных программах, работающих в режиме реального времени;

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

Следующее требование - синхронизация работы нескольких программ, обращающихся к базе данных. Эта проблема решается либо стандартными средствами многозадачной операционной системы либо за счет механизма опроса, недостатки которого рассмотрены ранее.

Пути решения перечисленных проблем заключаются в том, что знания выносятся за рамки прикладных программ и оформляются как объекты базы данных. Функции применения знаний выполняются непосредственно на сервере. Такая архитектура получила название - активный сервер, опирается на следующие моменты:

  • процедуры базы данных;

  • триггеры;

  • события в базе данных.

Процедуры базы данных носят название хранимых (разделяемых), их использование преследует четыре цели.

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

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

  3. использование процедур позволяет существенно снизить трафик сети в системах с архитектурой "клиент-сервер", т. к. программа при вызове процедуры передает серверу лишь ее имя и параметры; в процедуре обычно помещают повторяющиеся фрагменты нескольких прикладных программ, если бы эти фрагменты остались частью программы, они загружали бы сеть посылкой полных SQL-запросов.

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

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]