При файл серверной архитектуре сервер не участвует в обработке данных

Обновлено: 06.07.2024

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

Существуют две технологии (архитектуры) обработки удаленных данных:

файл-серверная архитектура

архитектура клиент-сервер

Обработка запроса одного пользователя: - Обращение к БД (запрос) - Перекачка данных с блокировкой доступа других пользователей - Обработка данных на компьютере пользователя Обработка запроса нескольких пользователей: - Одновременный запрос к тем же данным в БД - Ответ: "Данные заблокированы, подождите, или откройте в режиме только для чтения".

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

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

Недостатки ФАЙЛ-СЕРВЕРНОЙ системы:

Очень большая нагрузка на сеть, повышенные требования к пропускной способности. На практике это делает практически невозможной одновременную работу большого числа пользователей с большими объемами данных.

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

Блокировка данных при редактировании одним пользователем делает невозможной работу с этими данными других пользователей.

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

Обработка запроса одного пользователя: – Обращение к БД (SQL-запрос) – Передача ответа – результата обработки Обработка запроса нескольких пользователей: – Одновременный SQL-запрос к тем же данным в БД – Передача ответа – результата обработки.

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

Такой подход обеспечивает решение трех важных задач:

уменьшение нагрузки на сеть

уменьшение требований к компьютерам-клиентам

повышение надежности и сохранение логической целостности базы данных.

Понятие объектно-ориентированных баз данных (ООБД). Особенности проектирование ООБД. Основные характеристики и преимущества и недостатки ООСУБД.

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

Особенности проектирование ООБД.

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

Другой подход предоставляет доступ к объектно-ориентированным средствам пользователям традиционных языков. Этот подход, по сути, превращает такие языки, как С, FORTRAN, COBOL и т.д., в объектно-ориентированные языки. Спроектированные таким образом ООБД могут использоваться для хранения и управления объектами, созданными программами, написанными и на объектно-ориентированных языках. Хотя для отображения таких объектов в объекты базы данных также нужен программный слой, он намного проще, чем менеджер объектов, требуемый РБД.

Основные характеристики ООСУБД

Структура объектной модели описываются с помощью трех ключевых понятий:

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

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

полиморфизм - различные объекты могут по разному реагировать на одинаковые внешние события в зависимости от того, как реализованы их методы.

Для поддержания целостности объектно-ориентированный подход предлагает использовать следующие средства:

автоматическое поддержание отношений наследования

возможность объявить некоторые поля данных и методы объекта как "скрытые", не видимые для других объектов; такие поля и методы используются только методами самого объекта

создание процедур контроля целостности внутри объекта

Средства манипулирования данными:

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

Основные преимущества и недостатки ООСУБД

В объектно-ориентированных базах данных, в отличие от реляционных, хранятся не записи, а объекты. ОО-подход представляет более совершенные средства для отображения реального мира, чем реляционная модель:

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

имеется возможность определения новых типов данных и операций с ними.

В то же время, ОО-модели присущ и ряд недостатков:

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

вместо чисто декларативных ограничений целостности (типа явного объявления первичных и внешних ключей реляционных таблиц с помощью ключевых слов PRIMARY KEY и REFERENCES) или полудекларативных триггеров для обеспечения внутренней целостности приходится писать процедурный код.

Очевидно, что оба эти недостатка связаны с отсутствием развитых средств манипулирования данными. Эта задача решается двумя способами - расширение ОО-языков в сторону управления данными (стандарт ODMG), либо добавление объектных свойств в реляционные СУБД (SQL-3, а также так называемые объектно-реляционных СУБД).

Исторически первыми появились информационные системы с использованием файл-сервера. Файл-сервер только извлекает данные из файла (файлов) базы данных и передает их клиенту для дальнейшей обработки (рис. 1.1).

В процессе работы из базы данных клиенту передаются большие объемы информации. Значительный сетевой трафик иногда особенно сильно сказывается при одновременной работе даже уже нескольких клиентов, например вы скачиваете игры на Андроид Fruit Ninja или другие приложения. В файл-серверной архитектуре всегда передаются избыточные данные. Неважно, сколько записей из базы данных нужны клиенту — файлы базы данных передаются в самом общем случае целиком. Что касается MS Access, то нагрузку на сеть добавляют еще и объекты приложения, такие как формы, отчеты и т. д. Они вместе с данными хранятся в одном файле на компьютере-сервере.

Рис. 1.1. Структура информационной системы с файл-сервером

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

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

Рис. 1.2. Структура информационной системы с сервером базы данных

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

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

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

3.1. Централизованная архитектура

При использовании этой технологии база данных , СУБД и прикладная программа ( приложение ) располагаются на одном компьютере (мэйнфрейме или персональном компьютере) (рис.3.1.). Для такого способа организации не требуется поддержки сети и все сводится к автономной работе. Работа построена следующим образом:

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

Подобная архитектура использовалась в первых версиях СУБД DB2 , Oracle , Ingres [ [ 3.1 ] ].

Многопользовательская технология работы обеспечивалась либо режимом мультипрограммирования (одновременно могли работать процессор и внешние устройства – например, пока в прикладной программе одного пользователя шло считывание данных из внешней памяти, программа другого пользователя обрабатывалась процессором), либо режимом разделения времени (пользователям по очереди выделялись кванты времени на выполнение их программ). Такая технология была распространена в период "господства" больших ЭВМ (IBM-370, ЕС-1045, ЕС-1060). Основным недостатком этой модели является резкое снижение производительности при увеличении числа пользователей.

3.2. Технология с сетью и файловым сервером (архитектура "файл-сервер")

Увеличение сложности задач, появление персональных компьютеров и локальных вычислительных сетей явились предпосылками появления новой архитектуры файл-сервер . Эта архитектура баз данных с сетевым доступом предполагает назначение одного из компьютеров сети в качестве выделенного сервера, на котором будут храниться файлы базы данных [ [ 3.2 ] ]. В соответствии с запросами пользователей файлы с файл-сервера передаются на рабочие станции пользователей, где и осуществляется основная часть обработки данных. Центральный сервер выполняет в основном только роль хранилища файлов, не участвуя в обработке самих данных ( рис. 3.2.).

Работа построена следующим образом:

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

В рамках архитектуры " файл-сервер " были выполнены первые версии популярных так называемых настольных СУБД , таких, как dBase и Microsoft Access.

В литературе [ [ 3.2 ] ] указываются следующие основные недостатки данной архитектуры:

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

Рис. 9.1. Архитектура «файл-сервер»

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

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

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

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

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

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

Одними из первых СУБД были так называемые dBase-совместимые программные системы, разработанные разными фирмами: dBase III — PLUS (фирма Achton-Tate), Clipper (фирма Nantucket Inc.), FoxPro (фирма Fox Software), FoxBase+ (фирма Fox Software), Visual

FoxPro (фирма Microsoft). Одно время достаточно широко использовалась СУБД PARADOX (фирма Borland International). В последние годы очень широкое распространение получила система управления базами данных Microsoft Access, которая входит в целый ряд версий пакета Microsoft Office (фирма Microsoft).

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

Читайте также: