При работе в архитектуре "файл/сервер" база данных и приложение для ее обработки расположены на файловом сервере сети. Многопользовательская работа с одной и той же базе данных возможна в том случае, когда каждый пользователь с рабочей станции запускает приложение, расположенное на файловом сервере.
На рабочей станции запускается копия этого приложения, и по каждому запросу к базе данных таблицы полностью передаются по сети на рабочую станцию, независимо от того, сколько реально нужно данных для выполнения запроса. После этого выполняется запрос
Каждый пользователь имеет на рабочей станции локальную копию данных, время от времени обновляемых из реальной базы данных, расположенной на сетевом сервере. При этом изменения, которые каждый пользователь вносит в базу данных, могут быть до определенного момента неизвестны другим пользователям, что делает сложным систематическое обновления данных на рабочей станции из реальной базы данных. Важнейшей задачей является также блокирование записей, которые изменяются одним из пользователей, чтобы в это время другой пользователь не внес изменений в те же данные.
В архитектуре "файл/сервер" вся тяжесть выполнения запросов к базе данных и управления целостностью базы данных ложится на приложение пользователя. База данных на сервере в этом случае является пассивным источником данных. Секретность и конфиденциальность информации обеспечить также трудно.
В качестве приложений рабочих станций, как правило, используются вышеописанные настольные СУБД, такие как Dbase, Paradox, Microsoft Access 2000, FoxPro и другие.
В настольных СУБД база данных является более логическим, чем физическим понятием. Под базой данных здесь понимается набор отдельных таблиц, существующих в едином каталоге на жестком диске.
Недостаточно развитый аппарат транзакций для настольных СУБД служит потенциальным источником ошибок как с точки зрения одновременного внесения изменений в одну и ту же запись, так и с точки зрения отката (отмены) транзакций.
Поскольку настольные СУБД не содержат специальных сервисов, управляющих данными, а используются для этой цели файловые сервисы операционной системы, то сервисы доступа к данным находятся в том же адресном пространстве компьютера, что и сервисы отображения данных. Это может приводить к разрушению таблиц, поэтому существуют специальные программы утилиты для "ремонта" испорченных файлов настольных СУБД.
К недостаткам архитектуры "файл/сервер" следует также отнести необходимость передачи по сети целиком всех таблиц, что, учитывая вышеописанные принципы передачи данных по сети, может привести к «заторам» трафика сети. Например, если в результате запроса необходимо получить всего 2 записи из таблицы объемом 10000 записей, то все 10000 записей будут скопированы с файл/сервера на рабочую станцию.
Недостатки настольных СУБД обычно проявляются не сразу, а лишь в процессе длительной эксплуатации. Когда объем хранимых данных и число пользователей становятся достаточно велики, то это приводит к снижению производительности приложений, использующих такие СУБД.
Недостатки архитектуры "файл-сервер" решаются при переводе приложений в архитектуру "клиент-сервер", которая знаменует собой следующий этап в развитии СУБД.
Дата добавления: 2015-09-04; просмотров: 93 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Вопрос. Характеристики серверов баз данных. | | | Вопрос. Клиент-серверные системы и модели доступа к данным. |