В задачах обработки информации, основанных на системах баз данных, существуют два варианта расположения данных: локальный и удаленный. Соответственно, существуют «локальные», или «персональные», БД, а также промышленные, или серверные, БД.
К локальным БД относятся Paradox, dBase, Access, FoxPro и др. БД Access занимает особое положение, потому что входит в состав распространенного пакета Microsoft Office. Локальные данные, как правило, располагаются на жестком диске компьютера, на котором работает пользователь, и находятся в монопольном ведении этого пользователя. Пользователь при этом работает автономно, не завися от других пользователей и никоим образом не влияя на их работу.
К серверным БД относятся Oracle, Sybase, SQL Server и др. Удаленные данные располагаются вне компьютера пользователя – на файловом сервере сети или на специально выделенном для этих целей компьютере.
Всего можно выделить три архитектуры серверных БД:
1. Архитектура «файл-сервер»;
2. Архитектура «клиент-сервер»;
3. Многозвенная архитектура.
При работе с локальными БД режим однопользовательский.
В стандартной файл-серверной архитектуре данные, располагаясь на файл-сервере, являются, по сути, пассивным источником. На компьютере пользователя запускается копия приложения. При этом, поскольку обработка данных осуществляется на компьютере пользователя, по сети передается вся необходимая для этой обработки информация, хотя интересующий пользователя объем данных может быть намного меньше пересылаемого. Например, если пользователя интересуют все работники какого-либо предприятия, участвующие в конкретном проекте, его приложение получит сначала информацию обо всех работниках и обо всех проектах из базы данных и только после этого произведет требуемую выборку.
Кроме того, вся ответственность за получение, обработку, а также за поддержание целостности БД лежит на пользователе. Данные, с которыми работает пользователь, время от времени обновляются из реальной БД, расположенной на файл-сервере. При этом изменения, которые вносит один пользователь, могут быть на протяжении какого-то времени неизвестны другим пользователям. Поэтому возникает проблема блокировки одновременного доступа к данным разных пользователей [12].
Исторически на персональных компьютерах использовался именно этот подход – как более простой в освоении. Однако большой объем передаваемых по сети данных быстро «забивает» сеть уже при небольшом числе пользователей, существенно ограничивая возможности роста. Этот основной и самый существенный недостаток заставил искать способы уменьшения нагрузки на сеть.
В архитектуре клиент-сервер для обработки данных выделяется специальное ядро – так называемый сервер баз данных, который принимает на себя функции обработки запросов пользователей, именуемых теперь клиентами. Сервер баз данных представляет собой программу, выполняющуюся, как правило, на мощном компьютере. Приложения-клиенты посылают с рабочих станций запросы на выборку (вставку, обновление, удаление) данных. При этом сервер выполняет всю «грязную» работу по отбору данных, отправляя клиенту только требуемую «выжимку». Если приведенный выше пример перестроить с учетом клиент-серверной архитектуры, то приложение-клиент получит с сервера в качестве результата список только тех работников, которые участвуют в заданном проекте.
Такой подход обеспечивает решение трех важных задач:
1. Уменьшение нагрузки на сеть;
2. Уменьшение требований к компьютерам-клиентам;
3. Повышение надежности и сохранение логической целостности базы данных.
Действительно, теперь сервер БД (в случае реляционных баз данных называемый SQL-сервером) возвращает клиентскому приложению только «выжимку» того, что он просмотрел в базе, а она («выжимка») в общем случае действительно составляет малую часть от общего объема. Поэтому в сети не наблюдается резкого увеличения нагрузки при увеличении числа клиентов. Клиентские же приложения могут выполняться на менее мощных (по сравнению с сервером) компьютерах благодаря тому, что им практически не требуется выполнять никакой дополнительной обработки полученных от сервера результатов запроса (хотя, конечно, это не запрещено). Побочным эффектом уменьшения нагрузки на сеть является повышение скорости выполнения приложений клиентов. Кроме того, система легче масштабируется – легче и дешевле заменить один сервер на более мощный, чем десятки рабочих станций.
Но наиболее важным результатом перехода в архитектуру «клиент-сервер» является гарантированное сохранение логической целостности базы данных, т. е. система становится более устойчивой и более защищенной. Достигается это благодаря возможности переложения заботы о сохранении целостности базы на сервер. Для этого «хорошие» серверы обладают большим набором встроенных механизмов, защищающих систему от неверных действий клиентов. Среди этих механизмов можно назвать такие, как ограничения целостности, декларативная ссылочная целостность, триггеры, виртуальные таблицы (представления), авторизация пользователей и др.
Лекция 4
Основные понятия реляционных баз данных
При работе с таблицами часто используют два представления: собственно таблицу и структуру таблицы. Пример приведен на рис. 5.
Таблица «Студенты»
Номер
Фамилия
Имя
Рост
Вес
Структура таблицы «Студенты»
Поле
Тип поля
Номер
Счетчик
Фамилия
Текстовый
Имя
Текстовый
Рост
Числовой
Вес
Числовой
Рис. 5. Пример описания таблицы и ее структуры
Таблица может иметь первичный ключ, под которым понимается поле или набор полей, однозначно идентифицирующих запись.
В таблице не должно быть записей с одним и тем же значением первичного ключа.
Например, если рассматривается таблица «Студенты», то в качестве первичного ключа нельзя использовать фамилию, имя или дату рождения, поскольку эта информация не уникальна.
В общем случае в качестве первичного ключа выгоднее использовать семантически незначащее (не несущее смысловой нагрузки) поле (счетчик), с помощью которого каждая запись получает уникальный номер.
Первичный ключ является разновидностью более общего понятия потенциального ключа, т. е. ключа, который может быть выбран в качестве первичного.
Между двумя и более таблицами БД могут существовать отношения подчиненности. Это означает, что для каждой записи главной таблицы (родительской, или мастер-таблицы (англ.: master)) может существовать одна или несколько записей в подчиненной (или детальной (англ.: detail)) таблицы.
Связывание таблиц выполняется для устранения избыточности информации.
Существуют три разновидности связей между таблицами:
1. Связь «один-ко-многим» (или «многие-к-одному»);
