каждая база данных обычно предназначена для отдельной прикладной программы При разработке нового приложения создается, как правило, и новая база данных.

Таблицы Джо OFFICES

PRODUCTS

ORDERS

База данных OP (для обработки заказов)

Таблицы Мэри

ACCOUNTS

JOURNAL

База данных ACCTG (для бухгалтерского учета)

Таблицы Джорджа

TIMECARDS

WAGES

-

База данных PAYROLL (для начисления зарплаты)

Рис 13.10. Многобазовая архи-еь

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

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

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

СР.JOE.OFFICES

относится к таблице offices, принадлежащей пользователю joe в базе данных с именем ор (используется для обработки заказов), а следующий запрос объединяет эту таблицу с таблицей salesreps в базе данных по начислению зарплаты:

SELECT OP.JOE.OFFICES.CITY, PAYROLL.GEORGE.SALESREPS.NAME FROM OP.JOE.OFFICES, PAYROLL.GEORGE.SALESREPS WHERE OP.JOE.OFFICES.MGR = PAYROLL.GEORGE.SALESREPS.EMPL NOM

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

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

CONNECT OP

В Sybase и SQL Server необходима иная инсфукция:

USE DATABASE OP

Каталожная архитектура

На рис. 13.11 изображена каталожная архитектура, в соответствии с которой база данных организуется как древовидная структура каталогов. Такого рода схема применялась в ранних СУБД для мини-компьютеров (Rdb/VMS и Informbc). Подобно многобазовой архитектуре, для каждой прикладной профаммы обычно создается собственная база данных. Как видно из рисунка, каждая база данных имеет имя, причем две различные базы данных в разных каталогах могут иметь одно и то же имя.

Каталог верхнего уровня j

( Каталог PRODUCTION J

( Каталог DEVELOPMENT)

Каталог test

f База данных PAYROLL

База данных ОР

База данных acctg

Рис 13. ? 1. Кезталожная архитектура

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

Каталожная архитекту1:)а еще больше усложняет доступ к базе данных, поскольку для этого необходимо указать не только имя базы данных, но и ее местоположение в иерархии каталогов. Для доступа к базе данных Rdb/VMS применяется инструкция declare database диалекта VAX SQL. Например, ниже приведена инсфукция declare database для подключения к базе данных с именем ор, которая находится в каталоге с именем sys$root: [development.test] :

DECLARE DATABASE

FILENAME SYS$ROOT:[DEVELOPMENT.TEST]OP

Если база данных находится в текущем каталоге пользователя (что бывает достаточно часто), то инсфукция упрощается;

DECLARE DATABASE

FILENAME OP