Распределенные базы данных

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

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

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

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

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

Модели баз данных

В процессе обсуждения структур данных мы узнали, что для перевода запросов (таких как push и pop) в терминах абстрактной структуры (стека) в соответствующие действия в фактической системе хранения можно применять заранее разработанные процедуры. Также и в СУБД есть процедуры, которые преобразуют команды в терминах абстрактного представления базы данных в действия, выполняемые в фактической системе хранения данных. Абстрактное представление называется моделью базы данных (database model). Таким образом, используя специальные процедуры СУБД, можно писать приложение так, как если бы информация в базе данных хранилась согласно концептуальной модели, а не так, как она организована в системе хранения на самом деле.

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

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

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

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


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: