Локальные и серверные базы данных.
Линия развития баз данных в применении к персональным компьютерам была направлена от локальных баз данных, работающих в однопользовательском режиме, к серверным базам данных коллективного доступа.
Локальная база данных строится по принципу: один компьютер – одна БД – один пользователь в каждый конкретный момент времени (рис. 7). Но такая связка хороша только для хранения персональной (личной) информации, тогда как информация в большинстве случаев является общей для множества пользователей и требует коллективного доступа. Для реализации такого доступа БД переместили с рабочего места на сервер (файл-сервер) локальной сети (рис. 8), а на рабочих местах пользователей остались только приложения, которые могли обращаться к общей базе данных.
Рис. 7. Локальная база данных
Рис. 8. Файл-серверная база данных
Таким образом был обеспечен коллективный доступ к БД. Но, к сожалению, подобная реализация доступа имеет ряд существенных недостатков. Прежде всего, это большая сложность обеспечения одновременного доступа к одним и тем же элементам БД с разных рабочих мест. В системе нет арбитра, который бы регулировал порядок (очередность) доступа к БД. Этот порядок приходится реализовывать путем синхронизации работы приложений, что крайне сложно и не всегда возможно.
Файл-сервер в такой архитектуре никаких управляющих функций не выполняет, он только лишь хранит файлы БД, но никак не регулирует обращение к ее элементам. Если у пользователя есть права доступа к файлам БД, он может делать с ними все, что угодно. Естественно, что исполнение требований по соблюдению целостности хранимой информации всецело возлагается на приложения.
|
|
|
Наконец, отсутствие «интеллекта» у файл-сервера порождает проблему «тупой телефонистки» (для ответа на запрос о любом конкретном телефонном номере она начинает зачитывать телефонный справочник с буквы «А»), то есть вместо того, чтобы выбрать и передать пользователю только нужную ему информацию, файл-сервер передает всю имеющуюся информацию, оставляя решение задачи выбора за приложением. Как следствие, сильно и неоправданно растет нагрузка на локальную сеть.
Решение перечисленных проблем было найдено в клиент-серверной архитектуре (рис. 9). В такой архитектуре на сервере размещается не только собственно БД, но и СУБД, которая становится монопольным хозяином базы данных. СУБД принимает от приложений запросы на выполнение действий в БД, определяет порядок их выполнения, регулирует доступ к отдельным элементам базы данных, обеспечивает целостность хранимой информации. При этом по сети передается не «сырая», необработанная информация, а только результаты выполнения запросов.
|
|
|
Рис. 9. Клиент-серверная база данных
Кроме того, приложения в клиент-серверных базах данных разделяются на две части: клиентскую и серверную. Серверная часть приложений, как правило, сосредотачивает в себе всю вычислительную нагрузку и выполняется в рамках сервера БД. Для этих целей большинство SQL-серверов БД поддерживает специальные процедурные расширения языка SQL, предназначенные для реализации процедур обработки информации. В клиентской же части приложений обычно стараются оставить только элементы, обеспечивающие интерфейс пользователя, что уменьшает аппаратные требования к рабочим местам.
Такое разделение обеспечивает также простое масштабирование системы: увеличение сложности обработки информации или необходимость повышения ее производительности требует только наращивания мощности сервера, а рабочие места остаются без изменений. Упрощается сопровождение БД, поскольку изменения по большей части вносятся на серверной стороне и не затрагивают множество рабочих мест. Кроме того, для различных приложений, работающих с одной и той же БД, серверные части могут существенно пересекаться, что упрощает их разработку и решение проблем обеспечения целостности хранимой информации.
|
|
|
Дальнейшее развитие этой линии в истории БД также приводит к трехзвенной архитектуре (рис. 10), когда серверные части приложений выносятся на отдельный компьютер, называемый сервером приложений. При этом обеспечивается большая гибкость при конфигурировании и масштабировании системы.
Рис. 10. Трехзвенная архитектура баз данных
Мы рассмотрели три направления в истории развития баз данных. Их разделение достаточно условно и все они тесно переплетаются и влияют друг на друга. Так, например, выделение СУБД и переход к клиент-серверной модели обусловлены необходимостью реализации корректного многопользовательского доступа, а движение к трехзвенной архитектуре обусловлено как дифференциацией функций в базах данных, так и изменением способов доступа к ним.
Кроме того, переход от одних форм к другим не означает, что предыдущие формы полностью исчезли из употребления. На самом деле происходит смещение акцентов, и каждая форма занимает свою нишу в достаточно большом многообразии БД. Например, концептуально БД начинались с иерархической и сетевой моделей, а затем абсолютное лидерство перешло к реляционной модели данных.
Дата добавления: 2018-05-31; просмотров: 1276; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!