9.2 Многоуровневый подход к реализации базы данных
Чтобы разобраться в системах баз данных, важно понимать различие между программами, которые общаются с пользователем базы данных, и программами, которые в действительности манипулируют базой данных.
9.2.1Система управления базой данных
Типичная система базы данных состоит из двух уровней — прикладного уровня и уровня управления базой данных (рис. 9.2). Приложения отвечают за общение с пользователем (обычно с человеком, но иногда и с другим компьютером). Таким образом, именно они определяют внешние характеристики системы. Приложение может общаться с пользователем посредством диалога, состоящего из вопросов и ответов, или по сценарию заполнения пропусков данных в специальных формах1. Оно может работать как в текстовом, так и в графическом (GUI) режиме.
Программное обеспечение не манипулирует данными напрямую. Фактическое управление базой данных осуществляется на другом прикладном уровне, называемом системой управления базой данных, СУБД (database management system — DBMS). После того как приложение определило, какое действие требуется пользователю, оно применяет СУБД как абстрактный инструмент для получения нужных результатов. Если запрос направлен на добавление или удаление данных, именно СУБД в действительности обновляет базу данных. Если запрос предназначен для получения информации, СУБД выполняет требуемый поиск.
Разделение уровней приложений и СУБД имеет несколько преимуществ. Одно из них заключается в возможности создания и использования абстрактных инструментов, которые, как мы снова и снова убеждаемся, являются основной концепцией упрощения в разработке приложений. Если такие детали, как управление индексами, решение проблем переполнения и обновление указателей, изолированы внутри СУБД, разработку программного обеспечения можно существенно упростить. Более того, возьмем случай распределенной (distributed database) базы данных (базы данных, которая размещается на нескольких машинах в сети). Если бы не существовало СУБД, процедуры для своевременного отслеживания изменения фактического расположения различных частей базы данных пришлось бы поместить в приложения. Однако эти процедуры можно внедрить в хорошо спроектированную СУБД, а приложения разрабатывать без учета того, распределена ли база данных по многим машинам или она хранится на одном компьютере.
9.2.2Распределенные базы данных
Как вы узнали, базы данных создавались для объединения и централизации информации. Однако с современной точки зрения базы данных рассматриваются как способ интеграции информации, которая может храниться на различных компьютерах в локальной сети или в Интернете. Например, международная корпорация может хранить и обслуживать записи о сотрудниках на соответствующих местных узлах, связывая эти записи по сети для создания распределенной базы данных — одной большой интегрированной базы, данные которой хранятся на различных машинах.
Распределенная база данных может содержать фрагментированные и/или реплицированные (дублированные) данные. Первый случай иллюстрируется предыдущим примером записей сотрудников, когда различных фрагменты базы данных записаны на разных машинах. Во втором случае дубликаты одного компонента базы данных хранятся в различных местах. Репликацию можно производить для сокращения времени, необходимого для получения информации. В обоих случаях возникает проблема, не свойственная более традиционным централизованным системам, а именно: как замаскировать распределенную природу базы данных, чтобы она работала как единая система, и как гарантировать идентичность реплицированных частей базы данных при каждом обновлении. В свою очередь, изучение распределенных баз данных — это популярная область исследований компьютерных технологий.
Второе преимущество отделения приложений от СУБД состоит в том, что такая организация позволяет управлять доступом к базе данных. Приняв, что любой доступ к базе данных будет производиться только через СУБД, мы определяем, что именно она будет реализовывать ограничения, обусловленные различными подсхемами. В частности, СУБД может использовать всю схему базы данных для своих внутренних нужд и одновременно ограничивать приложение так, чтобы каждый пользователь оставался в рамках определенной для него подсхемы.
Еще одна причина разделения пользовательского интерфейса и фактического управления данными на два различных программных уровня — это достижение независимости данных (data independence), то есть возможности изменить организацию базы данных, не меняя приложение. Например, отделу кадров понадобится добавить во все записи дополнительное поле, указывающее, будет ли сотрудник принимать участие в новой корпоративной программе по страхованию здоровья. Если бы приложение обменивалось данными непосредственно с базой данных, такое изменение формата данных потребовало бы модификации всех приложений, работающих с этой базой. В результате изменения, инициированные в отделе кадров, привели бы к изменению и в программе обработки платежных ведомостей, и в программе печати адресных наклеек для информационного бюллетеня компании.
Разделение приложений и СУБД устраняет необходимость перепрограммирования. Для реализации в базе данных изменений, необходимых одному пользователю, нужно модифицировать только общую схему и подсхемы пользователей, которых эти изменения касаются. Подсхемы всех остальных пользователей не меняются, поэтому приложения, работающие с неизмененными подсхемами, модифицировать не требуется.