62.Системы совместного использования файлов. Обработка запросов в них. Недостатки систем.

Архитектура с совместным использованием файлов была разработана до клиент/серверной архитектуры и во многих отношениях является достаточно упрощенной.

Почти во всех системах с совместным использованием файлов применяются локальные сети. Для этой архитектуры характерен коллективный доступ к общей БД на сервере, который является файловым сервером. Файловый сервер содержит файлы, необходимые для работы приложений и самой СУБД. Он обеспечивает функционирование той части сетевой версии СУБД, которая осуществляет управление данными в БД. Однако пользовательские приложения и сама сетевая СУБД размещены и функционируют на отдельных рабочих станциях и обращаются к файловому серверу по мере необходимости. Рассмотрим организацию архитектуры файл/сервер с использованием настольной СУБД. Сетевые версии настольных СУБД отличаются от локальных версий тем, что они обладают некоторыми специальными механизмами, позволяющими многим пользователям совместно обращаться к общим ресурсам данных из централизованной базы данных. СУБД на каждой рабочей станции посылает запросы файловому серверу по всем необходимым ей данным, которые хранятся на диске файлового сервера. Все данные из БД пересылаются на компьютер пользователя, независимо от того, сколько реально их нужно для выполнения запроса. В результате на компьютере пользователя создается локальная копия БД (время от времени обновляемая из реальной БД на сервере). Затем СУБД пользователя выполняет запрос. Недостатки архитектуры файл/сервер: 1. При совместном использовании файлов по локальной сети передаются большие объемы данных. При такой архитектуре трафик в локальной сети достаточно большой. 2. С увеличением объема хранимых данных и числа пользователей снижается производительность настольных СУБД. Из-за этих проблем системы с совместным использованием файлов редко используются для обработки больших объемов данных. 3. Вся тяжесть выполнения запроса к БД и управления целостностью БД ложится на СУБД пользователя. 4. На каждой рабочей станции должна находиться сама сетевая версия настольной СУБД, что требует наличия больших объемов оперативной памяти на компьютере пользователя. 5. Доступ к одним и тем же файлам могут осуществлять сразу несколько пользователей, что усложняет управление целостностью, восстановлением БД на сервере.

63.Настольные субд, их достоинства и недостатки.

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

Известно более десятка настольных СУБД. Наиболее популярными, исходя из числа проданных копий признаются DBASE, Visual DBASE, Paradox, Microsoft FoxPro, Visual FoxPro, Access. Более подробное описание упомянутых СУБД приведено в [1].

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

65.Функции клиентского приложения и сервера баз данных при обработке запросов. Преимущества клиент/серверной обработки. Функции клиентского приложения: · ввод-вывод данных (презентационная логика) – это часть кода клиентского приложения, которая определяет, что пользователь видит на экране, когда работает с приложением; · бизнес-логика – это часть кода клиентского приложения, которая определяет алгоритм решения конкретных задач приложения; · обработка данных внутри приложения (логика базы данных) – это часть кода клиентского приложения, которая связывает данные сервера с приложением. Для этой связи используется процедурный язык запросов SQL, с помощью которого осуществляется выборка и модификация данных в серверных СУБД. Сервер БД осуществляет комплекс действий по управлению данными: · выполнение пользовательских запросов на выбор и модификацию данных и метаданных, получаемых от клиентских приложений, функционирующих на ПК локальной сети; · хранение и резервное копирование данных; · поддержка ссылочной целостности данных согласно определенным в БД правилам; · обеспечение авторизованного доступа к данным на основе проверки прав и привилегий пользователя; · протоколирование операций и ведение журнала транзакций. Преимущества: -При клиент/серверной обработке уменьшается сетевой трафик. -Груз файловых операций ложится в основном на сервер, который мощнее компьютеров-клиентов и поэтому способен быстрее обслуживать запросы. -Поскольку серверы способны хранить большое количество данных, то на компьютерах-клиентах освобождается значительный объем дискового пространства для других приложений. -Повышается уровень непротиворечивости данных и существенно повышается степень безопасности БД. -Имеется возможность хранения бизнес-правил (например, правил ссылочной целостности или ограничений на значения данных) на сервере.

66.Общие сведения о хранимых процедурах и триггерах. В современной модели клиент/сервер бизнес-логика разделена между клиентом и сервером. На сервере бизнес-логика реализована в виде хранимых процедур.

Хранимая процедура – это специальная процедура, которая выполняется сервером баз данных. Хранимые процедуры пишутся на процедурном языке, который зависит от конкретной СУБД. Для написания хранимых процедур для MS SQL Server используется расширенный стандарт языка SQL – Transact-SQL. Хранимая процедура здесь – это последовательность операторов Transact-SQL, хранящихся в БД. Хранимые процедуры предварительно откомпилированы, поэтому их эффективность выше, чем обычных запросов. Они выполняются непосредственно на сервере. Существует два вида хранимых процедур: системные и пользовательские. Системные хранимые процедуры предназначены для получения информации из системных таблиц и выполнения различных служебных операций и особенно полезны при администрировании базы данных. Пользовательские хранимые процедуры создаются непосредственно разработчиками или администраторами базы данных. Полезность хранимых процедур определяется в первую очередь высокой (по сравнению с обычными Transact-SQL запросами) скоростью их выполнения. Однако наибольший эффект достигается при выполнении многократно повторяющихся операций. Пользовательские хранимые процедуры применяются при решении практически любых задач. Пользователь может получить право выполнения хранимой процедуры, даже если он не имеет права доступа к объектам, к которым обращается программа. Хранимая процедура вызывается явно, т.е. при непосредственном обращении к процедуре из клиентского приложения, работающего с базой данных. Хранимые процедуры используются для извлечения или изменения данных в любое время. Хранимые процедуры могут принимать аргументы при запуске и возвращать значения в виде результирующих наборов данных. Логика БД реализуется с помощью триггеров. Триггер – это специальный тип хранимой процедуры, которая автоматически выполняется при каждой попытке изменить данные. Триггер всегда связан с конкретной таблицей и выполняется тогда, когда при редактировании этой таблицы наступает событие, с которым он связан (например, вставка, удаление или обновление записи). Каждая таблица может иметь произвольное количество триггеров любых типов. После операций вставки, обновления, удаления может быть запущен триггер, который в результате приведет к вычислению бизнес-правил или к выполнению определенных действий. При удалении таблицы, имеющей триггеры, все они также удаляются. Триггеры обеспечивают целостность данных, предотвращая их несанкционированное или неправильное изменение. Триггеры не принимают параметров и не возвращают значений. Они выполняются неявно, то есть триггер запускается только при попытке изменения данных. Триггеры могут иметь несколько уровней вложенности (например, в СУБД MS SQL Server триггеры имеют до 32 уровней вложенности), то есть выполнение одного триггера инициирует выполнение другого триггера. Триггер является частью транзакции, следовательно, если триггер не выполнятся, то отменяется вся транзакция. И наоборот, если какая-то часть транзакции не выполнилась, то и триггер будет отменен.