1. Организация файлов базы данных в db2®

Физическая организация реляционной базы данных в DB2® UDB

Универсальная база данных видит окружение в виде иерархии объектов (Рис. 7.40).

Высший уровень иерархии – рабочие станции (или серверы), на которых установлена система.

Рис. 7.40. Иерархия объектов

В ходе процесса инсталляции программные файлы для фонового процесса, известные как менеджер БД DB2®, физически копируются в определенное место на сервере – создается экземпляр менеджера БД DB2®. Экземпляры отвечают за управление системными ресурсами и базами данных, которые подпадают под их контроль.

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

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

В реляционной базе данных данные представлены в виде собрания таблиц. Таблицы хранятся во внешней памяти, и структуры хранения имеют свою организацию.

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

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

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

База данных содержит один или несколько разделов, в которых создаются табличные пространства, а сами таблицы создаются уже в табличных пространствах. Табличные пространства используются в целях контроля над тем, где физически хранятся данные.

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

Таблицы – предназначены для хранения данных, логически упорядоченных по строкам и столбцам. Таблица содержит определенное число столбцов и произвольное число строк. Все данные базы данных и таблиц собраны в табличных пространствах. Данные в таблице логически связаны, а между таблицами могут быть заданы отношения.

Для организации доступа к данным используются индексы. Индекс – это набор ключей, каждый из которых указывает на строки в таблице. Индекс позволяет эффективнее получать доступ к строкам в таблице, создавая прямой путь к данным через указатели. Оптимизатор SQL автоматически выбирает наиболее эффективный путь доступа к данным в таблицах. При определении наиболее быстрого доступа к данным он принимает во внимание индексы.

Табличные пространства

База данных разбивается на части, которые называются табличными пространствами. Табличное пространство – это пространство, предназначенное для хранения объектов базы данных (таблиц, индексов, LOB и LONG данных). При создании таблицы можно решить, что определенные объекты (например, данные индексов и больших объектов) будут храниться отдельно от остальных табличных данных (Рис. 7.41). Табличное пространство может быть размещено на одном или нескольких физических устройствах хранения.

Рис. 7.41. Использование табличных пространств

Определения и атрибуты табличных пространств хранятся в системном каталоге баз данных.

В системе различают обычные табличные пространства и большие табличные пространства. Каждое табличное пространство имеет имя.

Таблицы, содержащие пользовательские данные, находятся в обычных табличных пространствах. Пользовательское табличное пространство по умолчанию называется USERSPACE1.

Таблицы системного каталога находятся в обычном табличном пространстве. Табличное пространство системного каталога по умолчанию называется SYSCATSPACE.

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

Индексы хранятся в обычных табличных пространствах или больших табличных пространствах.

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

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

По умолчанию табличные данные хранятся на страницах по 4 Кбайта. Каждая страница (независимо от ее размера) содержит 68 дополнительных байтов для менеджера баз данных. Для хранения пользовательских данных (или строк) останется 4028 байт, хотя никакая строка на странице размером 4 Кбайта не может превышать 4005 байт в длину. Строка не может занимать несколько страниц. При использовании страниц размером 4 Кбайта допустимо не более 500 столбцов.

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

С помощью предложения SQL ALTER TABLE APPEND ON можно указать, что данные должны всегда добавляться в конец таблицы. В этом случае информация о свободном месте на страницах данных не сохраняется.

Страницы табличных данных не содержат данных для колонок типов LONG и LOB. Если в таблице какие-либо колонки объявлены как LONG или LOB, в строках на странице табличных данных в соответствующих позициях содержится дескриптор для этих колонок, а сами значения размещаются в отдельных табличных объектах, структура которых отличается от других типов данных.

База данных создается с помощью команды CREATE DATABASE, имеющей большое количество параметров, позволяющих задать все необходимые характеристики базы данных. В простейшем случае команда имеет вид:

CREATE DATABASE имя_базы_данных

Данная команда позволяет создать базу данных с указанным именем, характеристики которой устанавливаются в соответствии с правилами по умолчанию. В частности, при этом создаются табличные пространства с именами SYSCATSPACE для системных каталогов, USERSPACE1 для пользовательских таблиц и индексов, TEMPSPACE1 для временных таблиц, создаваемых системой. При необходимости, администратор системы может создавать дополнительные табличные пространства с помощью предложения CREATE TABLESPASE. Описание предложения можно найти в SQL Reference [11].

Логическая организация реляционной базы данных в DB2® UDB

На логическом уровне все объекты базы данных (таблицы, представления, триггеры, функции и другие) размещаются в схемах. Схема представляет собой коллекцию именованных объектов и сама также является объектом базы данных.

Схема может быть создана явно, с помощью предложения CREATE SCHEMA, имеющего следующий синтаксис:

CREATE SCHEMA идентификатор_схемы [ SQL-предложения_схемы ]

Идентификатор_схемы может быть задан одним из трех способов:

• имя_схемы; в этом случае владельцем схемы становится текущий пользователь;

• AUTORIZATION авторизационное_имя; в этом случае владельцем схемы становится указанный в данной конструкции пользователь, и имя схемы совпадает с именем владельца схемы;

• имя_схемы AUTORIZATION авторизационное_имя; в этом случае задаются явно и имя схемы, и владелец схемы.

SQL-предложения схемы включают предложения CREATE, COMMENT, GRANT.

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

Имя схемы – уникально и не может начинаться символами SYS. Владельцем схемы становится текущий пользователь, создающий схему, или пользователь, указанный в конструкции AUTORIZATION.

Имя любого другого объекта базы данных состоит из двух частей – имени схемы и имени самого объекта, разделенных символом «точка»:

имя_схемы.имя_объекта

Соответственно, в любом предложении SQL, в котором используется тот или иной объект базы данны, имя объекта может быть представлено полностью, например:

SELECT *

FROM UDBA.EMPL

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

При создании объектов базы данных (например, таблиц) имя объекта также может быть указано вместе с именем схемы, например:

CREATE TABLE MYSCHEMA.TAB(

…

)

В этом случае если указанная в предложении схема не существует, она будет создана; создаваемый объект базы данных (таблица в данном примере) будет размещен в указанной схеме.

Если же в предложениях CREATE имя схемы не указывается, создаваемые объекты размещаются в текущей схеме, имя которой можно получить с помощью специального регистра CURRENT SCHEMA.

Существуют ограничения на схемы, в которых можно размещать создаваемые объекты. Так, при создании таких объектов базы данных, как таблицы, представления и индексы, нельзя (явно или неявно) указывать схемы с именами SYSIBM, SYSCAT, SYSFUN, SYSSTAT. При создании типов данных, определенных пользователем, функций, последовательностей и триггеров имя схемы не может начинаться символами SYS.

Приложение. База данных поставок

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

CREATE TABLE SALOR(

SId CHAR(3) NOT NULL PRIMARY KEY,

SName VARCHAR(20) NOT NULL UNIQUE,

Status int,

SCity VARCHAR(20) NOT NULL,

Mngr VARCHAR(50) NOT NULL

);

CREATE TABLE CATEGORY(

CId CHAR(3) NOT NULL PRIMARY KEY,

CName VARCHAR(50) NOT NULL UNIQUE,

Descr VARCHAR(200)

);

CREATE TABLE ARTICLE(

ACode CHAR(3) NOT NULL PRIMARY KEY,

AName VARCHAR(50) NOT NULL UNIQUE,

Price DECIMAL(10,2) NOT NULL CHECK(Price > 0),

ACity VARCHAR(100) NOT NULL,

PrName VARCHAR(50) NOT NULL,

CId CHAR(3) NOT NULL REFERENCES CATEGORY

);

CREATE TABLE WAREHOUSE(

WId CHAR(3) NOT NULL PRIMARY KEY,

WName VARCHAR(50) NOT NULL UNIQUE,

WCity VARCHAR(100) NOT NULL,

Mngr VARCHAR(50) NOT NULL

);

CREATE TABLE INVOICE(

SId CHAR(3) NOT NULL REFERENCES SALOR,

ACode CHAR(3) NOT NULL REFERENCES ARTICLE,

WId char(3) NOT NULL REFERENCES WAREHOUSE,

Qty INT NOT NULL CHECK(qTY > 0),

PRIMARY KEY(SId, ACode, WId)

);

INSERT INTO SALOR VALUES

('S1', 'Перевозки', 20, 'Москва', 'Сергеев Никита Петрович'),

('S2', 'Айсберг', 10, 'Санкт Петербург', 'Фомин Илья Владимирович'),

('S3', 'Посредник', 30, 'Вологда', 'Ильин Алексей Олегович'),

('S4', 'Пост-С', 20, 'Липецк', 'Кузьмин Андрей Петрович'),

('S5', 'Прима', 30, 'Орел', 'Карпов Алексей Иванович');

INSERT INTO CATEGORY (CId, CName) VALUES

('C1', 'Холодильники'),

('C2', 'Микроволновые печи'),

('H1','Электробытовые товары'),

('C3','Телевизоры'),

('C4','DVD');

INSERT INTO ARTICLE VALUES

('A1', 'Стинол-101', 25240.00, 'Липецк', 'ОАО ЭлБытМаш', 'C01'),

('A2', 'ЗИЛ-240', 27500.00, 'Москва', 'АМО ЗИЛ', 'C01'),

('A3', 'LG-No frost', 15670.00, 'Тула', 'LG', 'C01'),

('A4', 'Inverter', 5500.00, 'Тамбов', 'Panasonic', 'C02'),

('A5', 'KL5470', 6300.00, 'Орел', 'Samsung', 'C02'),

('A6', 'KS3500', 4389.00, 'орел', 'Samsung', 'C02'),

('A7', 'Миксер Мк05', 2210.00, 'Тула', 'ОАО МХМ', 'H01'),

('A8', 'Кофеварка КС12', 2500.00, 'Москва', 'ОАО МКМ', 'H01'),

('A9', 'Кофемолка МКМ', 1500.00, 'Москва', 'ОАО МКМ', 'H01'),

('A10', 'Bravia KDL', 45000.00, 'Москва', 'Sony', 'C03'),

('A11', 'RS-51', 46800.00, 'Санкт Петербург', 'Samsung', 'C03'),

('A12', 'Bravia KSU', 65000.00, 'Москва', 'Sony', 'C03'),

('A13', 'DVD-R12', 3329.00, 'Санкт Петербург', 'Samsung', 'C04'),

('A14', 'DVD-RW', 5300.00, 'Москва', 'Sony', 'C04'),

('A15', 'DVD-R4', 2350.00, 'Тамбов', 'Panasonic', 'C04');

INSERT INTO WAREHOUSE VALUES

('W1', 'Склады', 'Москва', 'Иванов Иван Иванович'),

('W2', 'База 12', 'Орел', 'Петров Иван Петрович'),

('W3', 'База 131', 'Курск', 'Иванов Федор Иванович'),

('W4', 'Склад на Пресне', 'Москва', 'Ильин Петр Ильич'),

('W5', 'Склад 33', 'Орел', 'Кузнецов Сергей Петрович'),

('W6', 'Склад 05', 'Москва', 'Кузнецов Сергей Петрович');

INSERT INTO INVOICE VALUES

('S1', 'A1', 'W1', 100),

('S1', 'A2', 'W1', 150),

('S1', 'A1', 'W5', 50),

('S2', 'A1', 'W1', 100),

('S2', 'A2', 'W3', 200),

('S2', 'A3', 'W3', 220),

('S2', 'A4', 'W1', 180),

('S2', 'A5', 'W4', 300),

('S3', 'A3', 'W2', 230),

('S3', 'A1', 'W1', 130),

('S3', 'A1', 'W5', 160),

('S3', 'A2', 'W1', 210),

('S3', 'A2', 'W4', 120),

('S4', 'A4', 'W1', 500),

('S4', 'A2', 'W2', 330),

('S4', 'A3', 'W3', 270),

('S4', 'A5', 'W3', 120),

('S4', 'A1', 'W5', 150),

('S1', 'A1', 'W3', 200),

('S1', 'A4', 'W1', 220),

('S2', 'A6', 'W1', 140),

('S2', 'A7', 'W3', 280),

('S2', 'A8', 'W3', 310),

('S2', 'A9', 'W1', 160),

('S2', 'A10', 'W4', 110),

('S2', 'A11', 'W1', 350),

('S2', 'A12', 'W3', 250),

('S2', 'A13', 'W3', 320),

('S2', 'A14', 'W1', 210),

('S2', 'A15', 'W4', 450);

Список литературы

1. Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация, сопровождение. Теория и практика. : Пер. с англ. – М.: Издательский дом «Вильямс», 2000.

2. Дейт К.Дж. Введение в системы баз данных. : Пер. с англ. – М.: Наука, 1996.

3. Ульман Дж. Основы систем баз данных. : Пер. с англ. – М.: Финансы и статистика, 1983.

4. Спецификации на стандарт IDEF. http://www.idef.com

5. Мартин Дж. Организация баз данных в вычислительных системах. : Пер. с англ. – М: Мир, 1998.

6. Чен П. Модель сущность-связь – шаг к единому представлению данных. //СУБД №3, 1995. стр. 137 – 158

7. Кодд Е.Ф. Реляционная модель данных для больших совместно используемых банков данных. //СУБД №1, 1995. стр. 145 – 160

8. Тиори Т., Фрай Дж. Проектирование структур баз данных. Т. 2. : Пер. с англ. – М.: Мир, 1985.

9. Мейер Д. Теория реляционных баз данных. : Пер. с англ. – М.: Мир, 1987.

10. IBM® DB2 Universal DatabaseTM. SQL Reference Volume 1.

11. IBM® DB2 Universal DatabaseTM. SQL Reference Volume 2.

12. IBM® DB2 Universal DatabaseTM. Application Development Guide: Programming Server Applications.

13. Кнут Д. Искусство программирования для ЭВМ, т 3. Сортировка и поиск. : Пер. с англ. – М.:

189