72. Архитектура сетевого приложения, взаимодействующего с базой данных. Техника создания приложений и апплетов на языке Java, взаимодействующих с базами данных.
Исторически первой появилась модель распределенного представления данных, которая реализовывалась на универсальной ЭВМ с подключенными к ней неинтеллектуальными терминалами. Управление данными и взаимодействие с пользователем при этом объединялись в одной программе, на терминал передавалась только «картинка», сформированная на центральном компьютере.
Затем, с появлением персональных компьютеров (ПК) и локальных сетей, были реализованы модели доступа к удаленной базе данных. Некоторое время базовой для сетей ПК была архитектура файлового сервера. При этом один из компьютеров является файловым сервером, на клиентах выполняются приложения, в которых совмещены компонент представления и прикладной компонент (СУБД и прикладная программма). Протокол обмена при этом представляет набор низкоуровненых вызовов операций файловой системы. Такая архитектура, реализуемая, как правило, с помощью персональных СУБД, имеет очевидные недостатки — высокий сетевой трафик и отсутствие унифицированного доступа к ресурсам.
С появлением первых специализированных серверов баз данных появилась возможность другой реализации модели доступа к удаленной базе данных. В этом случае ядро СУБД функционирует на сервере, протокол обмена обеспечивается с помощью языка SQL. Такой подход по сравнению с файловым сервером ведет к уменьшению загрузки сети и унификации интерфейса «клиент-сервер». Однако, сетевой трафик остается достаточно высоким, кроме того, по прежнему невозможно удовлетворительное администрирование приложений, поскольку в одной программе совмещаются различные функции.
Позже была разработана концепция активного сервера, который использовал механизм хранимых процедур. Это позволило часть прикладного компонента перенести на сервер (модель распределенного приложения). Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, что и SQL-сервер. Преимущества такого подхода: возможно централизованное администрирование прикладных функций, значительно снижается сетевой трафик (т.к. передаются не SQL-запросы, а вызовы хранимых процедур). Недостаток — ограниченность средств разработки хранимых процедур по сравнению с языками общего назначения (C и Pascal).
На практике сейчас обычно используются смешанный подход:
- простейшие прикладные функции выполняются хранимыми процедурами на сервере
- более сложные реализуются на клиенте непосредственно в прикладной программе
Сейчас ряд поставщиков коммерческих СУБД объявило о планах реализации механизмов выполнения хранимых процедур с использованием языка Java. Это соответствует концепции «тонкого клиента», функцией которого остается только отображение данных (модель удаленного представления данных). В последнее время также наблюдается тенденция ко все большему использованию модели распределенного приложения. Характерной чертой таких приложений является логическое разделение приложения на две и более частей, каждая из которых может выполняться на отдельном компьютере. Выделенные части приложения взаимодействуют друг с другом, обмениваясь сообщениями в заранее согласованном формате. В этом случае двухзвенная архитектура клиент-сервер становится трехзвенной, а к некоторых случаях, она может включать и больше звеньев.
РАЗРАБОТКА СЕТЕВЫХ ПРИЛОЖЕНИЙ
Реляционные модели данных в настоящее время приобрели наибольшую популярность, и практически все современные СУБД ориентированы именно на такое представление данных.
Реляционную модель можно представить как особый метод рассмотрения данных, содержащий и собственно данные (в виде таблиц), и способы работы и манипуляции с ними (в виде связей). Реляционная модель предполагает три концептуальных элемента: структура, целостность и обработка данных, как, впрочем, и большинство не реляционных моделей. В этих элементах есть свои специальные понятия, которые для дальнейшего изложения необходимо кратно пояснить [38].
Таблица рассматривается как непосредственное «хранилище» данных. Традиционно в реляционных системах таблицу называют отношением. Строку таблицы называют кортежем, а столбец — атрибутом. При этом атрибуты имеют уникальные (в пределах отношения) имена. Количество картежей в таблице называют кардинальным числом, а количество атрибутов — степенью. Для отношения предусматривают уникальный идентификатор, т.е. один или несколько атрибутов, значения которых в одно и тоже время не бывают одинаковыми — идентификатор называют первичным ключом. Домен — это множество допустимых однородных значений для того или иного атрибута. Таким образом, домен можно рассмотреть как именованное множество данных, причем составные части этого множества являются логически неделимыми единицами (в качестве домена могут выступать, например, перечень фамилий сотрудников учреждения, однако не все фамилии могут присутствовать в таблице).
Отношение содержит две части: заголовок и собственно содержательную часть. Заголовок содержит конечное множество атрибутов, а содержательная часть (тело отношения) — множество пар имени атрибута и его значения. Например, на рис. 16.1 KOD, NAME и SUMM, содержащиеся в заголовке, являются атрибутами, а, скажем, пары SUMM — 25.50 или KOD — 5216 являются элементами тела отношения.
Рис. 1Б.1. Пояснение понятий реляционных БД
В реляционных БД, в отличие от других моделей, пользователь указывает, какие данные для него необходимы, а не то, как это делать. По этой причине процесс перемещения и навигации по БД в реляционных системах осуществляется автоматически, а эту задачу в таких СУБД выполняет так называемый оптимизатор. Его работа заключается, например, в том, чтобы наиболее эффективным способом произвести выборку данных из БД по запросу. Таким образом, оптимизатор, по крайней мере, должен суметь определить, из каких таблиц выбираются данные, как много информации в этих таблицах, каков физический порядок записей в таблицах, как они сгруппированы и т. д.
Кроме того, реляционная СУБД выполняет и функции каталога. В каталоге хранятся описания всех объектов, из которых состоит БД — таблиц, индексов, триггеров и т. п. Очевидно, что это жизненно необходимо для правильной работы всей системы — так, например, оптимизатор использует в своей работе информацию, хранящуюся в каталоге. Интересен тот факт, что каталог сам является набором таблиц, поэтому СУБД может манипулировать ими традиционными средствами, не прибегая к каким-то особым приемам и методами.
В реляционных моделях вопросу целостности данных отводится особое место. Ключ или потенциальный ключ — это минимальный набор атрибутов, по значением которых можно однозначно найти требуемый кортеж. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать кортеж по оставшимся атрибутам.
Каждое отношение обладает хотя бы одним возможным ключом. Один из них принимается за первичный ключ. При выборе первичного ключа следует отдавать предпочтение не составным ключам или ключам, составленным из минимального числа атрибутов. Нежелательно также использовать ключи с длинными текстовыми значениями (предпочтение отдается целочисленным атрибутам). Так, для идентификации работника можно использовать либо уникальный табельный номер или номер паспорт, либо набор из фамилий, имени, отчества и номера отдела.
Не допускается, чтобы первичный ключ отношения, т.е. любой атрибут, участвующий в первичном ключе, принимал неопределенное значение. В этом случае возникает противоречивая ситуация: появится не обладающий уникальностью элемент первичного ключа, поэтому при проектировании БД за этим необходимо следить особо тщательно.
Если отношение С связывают отношения А и Б, то оно должно включать внешние ключи, соответствующие первичным ключам отношений А и Б. Таким образом, при рассмотрении проблемы выбора способа связи отношений в БД возникает вопрос о том, каковы же должны быть внешние ключи. При этом для каждого внешнего ключа необходимо решить проблему, связанную с возможностью (или невозможностью) появления во внешних ключах неопределенных значений (NULL — значений — значений атрибута для отсутствующей информации). Другими словами, может ли существовать некоторый кортеж в отношении, для которого неизвестен кортеж в связанном с ним отношении.
С другой стороны, необходимо заранее обдумать вопрос о том, что произойдет при попытке удаления кортежей из отношения, на которое ссылается внешний ключ. При этом существуют следующие вероятные возможности:
- • операция каскадируется — т.е. удаление кортежей в отношении приводит к удалению соответствующих кортежей в связанном отношении. Например, удаление информации о фамилии, имени и т. п. сотрудников в одном отношении приводит к удалению информации о его заработной плате в другом.
- • операция ограничивается — т.е. удаляются лишь те кортежи, для которых связанной информации в другом отношении нет. Если таковая информация имеется, то удаление осуществить нельзя. Например, удаление информации о фамилии, имени и т. п. сотрудника возможна лишь в том случае, если информация о его заработной плате в связанном отношении отсутствует.
Наконец, нужно предусмотреть технологию того, что будет происходить при попытке обновления первичного ключа отношения, на которое ссылается некоторый внешний ключ. Здесь имеются те же возможности, как и при удалении:
- • операция каскадируется— т.е. при обновлении первичного ключа происходит обновление внешнего ключа в связанном отношении. Например, обновление первичного ключа в отношении, где хранится информация о сотруднике приводит к обновлению внешнего ключа в отношении с информацией о его заработной плате;
- • операция ограничивается— т.е. обновляются лишь те первичные ключи, для которых связанной информации в другом отношении нет. Если таковая информация имеется, то обновление сделать нельзя. Например, обновление первичного ключа в отношении, где хранится информация о сотруднике, возможно в том случае, если информация о его заработной плате в связанном отношении отсутствует.
Таким образом, для каждого внешнего ключа в БД должны предусматриваться не только атрибут или комбинация атрибутов, составляющих этот внешний ключ, и отношения, идентифицируемое этим ключом, но также и варианты «поведения» БД в рассмотренных выше случаях.
Формальной основой реляционной модели БД являются реляционная алгебра, основанная на теории множеств и рассматривающая специальные операторы над отношениями, и реляционное исчисление, базирующееся на математической логике.
Основных операторов в реляционной алгебре восемь:
- • выборка отношений;
- • проекция отношения;
- • объединения отношений;
- • пересечение отношений;
- • вычитание отношений;
- • произведение отношений;
- • соединение отношений;
- • деление отношений.
Надо отметить, что реляционная алгебра обладает большой мощностью — сложные запросы к БД могут быть выражены с помощью одного выражения. Именно по этой причине эти механизмы включены в реляционную модель данных. Конкретный язык манипулирования реляционными БД называется реляционно-полным, если любой запрос, выражаемый с помощью одного выражения реляционной алгебры или одной формулы реляционного исчисления, может быть выражен с помощью одного оператора этого языка.
Реляционная алгебра обладает важным свойством — она замкнута относительно понятия отношения. Это означает, что выражения реляционной алгебры выполняются над отношениями реляционных БД и результаты их вычисления также представляют собой отношения. Поэтому любое выражение может быть представлено как отношение, что позволяет использовать его в других выражениях реляционной алгебры.
Основная идея реляционной алгебры состоит в том, что средства манипулирования отношениями, рассматриваемыми как множества, основаны на традиционных множественных операциях, дополненных некоторыми специфичными операциями для БД [39].