Работа с базами данных в режимах «файл-сервер» и «клиент-сервер».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

Структура:

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

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

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

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

Целостность данных:

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

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

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

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

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

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

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

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

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

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

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

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

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

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