рефераты конспекты курсовые дипломные лекции шпоры

Реферат Курсовая Конспект

Традиционные подходы

Традиционные подходы - раздел Информатика, Технология и модели "клиент-сервер" До Недавнего Времени Функции Управления Знаниями Оставались За Границами Возм...

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

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

Рассмотрим, например, базу данных Склад, хранящую информацию о наличии деталей на заводском складе. Прикладная программа Складской Учетобеспечивает учет имеющихся и вновь поступающих деталей. В ее функции входит просмотр содержимого базы данных, добавление информации о новых деталях, замена снятых с производства деталей на новые и т.д. В программе реализованы некоторые правила, например "В любой момент времени количество деталей типа "втулка" не должно быть меньше 1000" (ситуация со втулками на производстве всегда напряженная). Нетрудно понять, что оно должно применяться только в том случае, когда количество втулок уменьшается. Значит, нужно проверить: а не уменьшилось ли оно настолько, что стало меньше 1000. Если это произошло, то нужно срочно направить на завод-изготовитель письмо с просьбой отгрузить нужное количество втулок, если, конечно, такое письмо не было направлено до этого.

А чтобы это правило применялось, программа должна периодически, через определенные интервалы времени опрашивать значение в столбце Количество таблицы Деталь для всех строк, которые удовлетворяют условию Деталь. Название ="Втулка". Если это значение становится меньше 1000, программа должна послать письмо на завод-изготовитель.

Фрагмент программы указан в Примере 1.

...

SELECT Количество, Номер_поставщика

FROM Деталь

WHERE Название = "Втулка";

IF (Количество < 1000)

THEN

BEGIN

SELECT Адрес_поставщика

FROM Поставщик

WHERE Номер = Номер_поставщика;

Послать письмо(Адрес_поставщика, 1000-Количество);

END

ELSE Ничего не делать

...

{ ...

ВЫБРАТЬ Количество, Номер_поставщика

ИЗ Деталь

ГДЕ Название = "Втулка";

ЕСЛИ (Количество < 1000) ТО

НАЧАТЬ

ВЫБРАТЬ Адрес_поставщика

ИЗ Поставщик

ГДЕ Номер = Номер_поставщика;

Послать письмо(Адрес_поставщика, 1000-Количество);

ЗАКОНЧИТЬ

ИНАЧЕ Ничего не делать

... }

Пример 1.

В чем недостатки такого подхода?

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

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

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

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

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

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

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

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

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

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

Общепринятый способ преодоления ограничения на типы данных в СУБД - приведение данных новых типов к стандартным. Как правило, данные новых типов рассматриваются как целые или вещественные числа, или как строки символов.

Рассмотрим пример. В ряде стран, в том числе и в США, для измерения длины наряду с привычными мерами метрической системоы используются также футы и дюймы. Правила выполнения арифметических операций в этой системе отличны от десятичной. Так, три фута одиннадцать дюймов плюс один дюйм равно четырем футам ( 3"11" + 1" = 4"). Стандартный набор типов данных не позволяет определить данные в этой системе и оперировать с ними. Они должны быть преобразованы в вещественные числа с плавающей точкой, то есть представлены соответственно, как 3.91666 (три фута одиннадцать дюймов) и 0.08333 (один дюйм). Выполнив операцию сложения (3.91666+0.08333=3.99999), мы убедимся, что такое представление приводит к потере точности (ведь результат должен быть равен четырем!).

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

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

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

Другое важнейшее требование к современным СУБД - возможность хранения неструктурированных объектов большого объема (Binary Large OBjects - BLOB). Отвечая на это требование, разработчики СУБД предусматривают такую возможность. Однако сервер лишь хранит такие объекты, не обладая возможностями их обработки. Например, работая с графическим объектами, сервер не делает различий между изображением автомобиля BMW и структурой ДНК. Сервер вынужден передавать их для интерпретации прикладной программе, которая сможет разобраться, кто есть кто.

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

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

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

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

2.3.3. Современные решения

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

Такая архитектура суть воплощение концепции активного сервера. Она опирается на четыре "столпа":

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

правила (триггеры)

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

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

Процедуры базы данных

В различных СУБД они носят название хранимых (stored), присоединенных, разделяемых и т.д. Ниже будем пользоваться терминологией, принятой в СУБД Ingres.

Использование процедур базы данных преследует четыре цели.

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

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

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

Рисунок 11.
Увеличение производительности системы за счет использования процедур базы данных.
а. процедуры не используются;
б. выделение фрагмента прикладных программ в виде процедуры БД.

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

В современных СУБД процедура хранится непосредственно в базе данных и контролируется ее администратором. Она имеет параметры и возвращает значение. Процедура базы данных создается оператором CREATE PROCEDURE (СОЗДАТЬ ПРОЦЕДУРУ) и содержит определения переменных, операторы SQL ( например, SELECT, INSERT), операторы проверки условий (IF/THEN/ELSE) операторы цикла (FOR, WHILE), а также некоторые другие.

Например, необходимо разработать процедуру, которая переводила бы рядового сотрудника в резерв на выдвижение на руководящую должность. Процедура Назначение перемещает строки из таблицы Сотрудник, содержащей сведения о сотрудниках, в таблицу Резерв для всех сотрудников с указанным номером. Номер сотрудника представляет собой целое число (тип integer), который не может иметь пустое значение, является параметром процедуры и передается ей при вызове из прикладной программы оператором EXECUTE PROCRDURE (ВЫПОЛНИТЬ ПРОЦЕДУРУ). (Пример 2.)

CREATE PROCEDURE Назначение (Номер_сотрудника integer not nul) AS

BEGIN

INSERT INTO Резерв

SELECT *

FROM Сотрудник

WHERE Номер = Номер_сотрудника;

DELETE

FROM Сотрудник

WHERE Номер = Номер_сотрудника;

END

{ СОЗДАТЬ ПРОЦЕДУРУ Назначение (Номер_сотрудника целый не пустой) КАК

НАЧАТЬ

ВКЛЮЧИТЬ В Резерв

ВЫБРАТЬ ВСЕ

ИЗ Сотрудник

ГДЕ Номер = Номер_сотрудника;

УДАЛИТЬ ИЗ Сотрудник

ГДЕ Номер = Номер_сотрудника;

ЗАКОНЧИТЬ }

– Конец работы –

Эта тема принадлежит разделу:

Технология и модели "клиент-сервер"

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

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ: Традиционные подходы

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Все темы данного раздела:

Технология и модели "клиент-сервер".
"Клиент-сервер" - это модель взаимодействия компьютеров в сети. Как правило, компьютеры не являются равноправными. Каждый из них имеет свое, отличное от других, назначение, играет свою ро

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

Активный сервер
Действительно профессиональные СУБД обладают мощным активным сервером базы данных. Это не просто технические новшество. Идея активного сервера коренным образом изменяет представлен

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

Хотите получать на электронную почту самые свежие новости?
Education Insider Sample
Подпишитесь на Нашу рассылку
Наша политика приватности обеспечивает 100% безопасность и анонимность Ваших E-Mail
Реклама
Соответствующий теме материал
  • Похожее
  • Популярное
  • Облако тегов
  • Здесь
  • Временно
  • Пусто
Теги