Инструкции DDL

CREATE/DROP/ALTER PACKAGE

CREATE/DRCP/ALTER PROCEDURE CREATE/DROP/ALTER PROFILE

CREATE/DROP/ALTER ROLE

CREATE/DROP/ALTER/ROLLBACK SEGMENT

CREATE SCHEMA

CREATE/DROP/ALTER SNAPSHOT

CREATE/DROP SYNONYM CREATE/DROP/ALTER TABLESPACE CREATE/DROP/ALTER TRIGGER CREATE/DROP TYPE CREATE/DROP TYPE BODY CREATE/DROP/ALTER USER

В Sybase Adaptive Server.

CREATE/DROP/ALTER DATABASE CREATE/DROP DEFAULT CREATE EXISTING TABLE

CREATE/DROP PROCEDURE CREATE/DROP/ALTER ROLE CREATE/DROP RULE CREATE SCHEMA CREATE/DROP TRIGGER В стандарте ANSI/ISO: CREATE/DROP ASSERTION CREATE/DROP CHARACTER SET CREATE/DROP COLLATION CREATE/DROP/ALTER DOMAIN CREATE/DROP SCHEMA CREATE/DROP TRANSLATION

Управляемый объект

группа процедур PL/SQL, доступных для коллективного использования

пользовательская хранимая процедура

набор ограничений на использование ресурсов базы данных

роль пользователя в базе данных

область дисковой памяти, используемая для восстановления базы данных при отмене транзакции

схема базы данных

таблица результатов запроса, доступная только для чтения ( снимок )

псевдоним таблицы или представления

табличная область

триггер

пользовательский абстрактньт тип данных методы абстрактного типа данных идентификатор пользователя Oracle

база данных

значение столбца по умолчанию

локальная копия таблицы, к которой осуществляется удаленный доступ

хранимая процедура

роль пользователя в базе данных

правило соблюдения целостности столбца

схема базы данных

триггер

утверждение

расщиренный набор символов порядок сортировки набора символов домен

схема базы данных

правило конвертирования наборов символов

Структура базы данных

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

База данных

Таблицы Джо Таблицы Мэри , , FRIENDS

PETS

ORDERS

Таблицы Сэма

PRODUCTS

PEOPLE

PETS

Рис. 13.8. Организация базы данных согласно стандарту SOU

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

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

Однобазовая архитектура

На рис. 13.9 представлена однобазовая архитектура, при которой СУБД поддерживает единую системную базу данных. Такой подход применялся в СУБД для

мэйнфреймов и мини-компьютеров (в соответствующих версиях DB2 и Oracle) Данные по бухгалтерскому учету, зарплате и заказам хранятся в таблицах внутри одной базы данных. Главные таблицы каждой программы собраны вместе и принадлежат одному пользователю, который, вероятно, является ответственным за эту профамму на данном компьютере.

Единая системная база данных

Таблицы Джо

offices

products

orders

Таблицы Мэри

accounts

journal

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

timecards

wages

Рис. 13.9. Однобаэавая архитектура

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

Недостатком такой архитектуры является то, что со временем, по мере добавления новых прикладных профамм, база данных приобретает офомные размеры. В DB2 и Oracle не редкость базы данных, имеющие несколько сотен таблиц. Проблемы, связанные с управлением базой данных таких размеров, очевидны: резервное копирование, восстановление данных, анализ производительности и т.д. требуют, как правило, постоянного внимания администратора базы данных.

При однобазовой архитектуре доступ к базе данных осуществляется очень просто, так как база данных одна и не фебуется делать какой-либо выбор. Например, подключение к базе данных Oracle осуществляется посредством инструкции connect из профаммного SQL, и пользователи говорят о подключении к Oracle , а не к какой-нибудь конкретной базе данных.

Фактически Oracle и DB2 часто управляют двумя отдельными базами данных: одна служит для промышленной эксплуатации, а другая - для целей отладки. Однако все производственные данные собраны в одной базе данных.

Многобазовая архитектура

На рис. 13.10 представлена многобазовая архгггектура, при использовании которой каждой базе данных присваивается уникальное имя. Такая архитектура применяется в Sybase Adaptive Sen-er, Microsoft SQL Server, Ingres и других СУБД. Как видно из рисунка.