Расчет физического пространства для таблиц.

1. Тип колонок

2. Длина самих таблиц (количество строк)

3. Дефрагментация диска

4. Объем свободного пространства на диске

Эти 4 момента необходимо учитывать при оценке физического пространства для таблиц.

Estimate size — оценивает, какое пространство объект БД будет занимать на диске в предположении того, что объект будет разрастаться. Оценкой объекта являются два значения:

• Минимальный размер (размер табличного пространства)

• Максимально возможный размер.

Размер, необходимый для таблиц БД определяется следующими объектами:

1. Таблица системного каталога

2. Пользовательские таблицы

3. Данные типа long

4. Данные типа LOB

5. Размер индексов.

1. Таблицы системного каталога.

Таблицы увеличиваются при добавлении объектов в БД и привилегий. При создании БД изначально все ее таблицы занимают 3.5 Мб. Объем необходимого для размещения таблиц системного каталога зависти от типа табличного пространства и размера extent’a этого табличного пространства, который будет содержать таблицы системного каталога. Для DMS с размером extent=32 пространство под таблицы системного каталога занимает 27? Мб.

2. По умолчанию используется page size = 4 Кб. Каждая страница включает 76 байт, которые использует менеджер БД, остается 4020 байт, которые можно использовать под строку данных. От этого возникает ряд проблем:

• 4 Кбайтная страница не может сохранить больше, чем 4005 байт, т.е. 15 байт все равно остаются незадействованными.

• Максимальное количество столбцов не может превышать 500, т.е. не может быть больше 500 колонок.

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

ROUND DOWN (4020 / (average rowsize +10)) = records per page

(number of records / records per page)*1.1 = number of pages

average rowsize — средний размер строки.

number of pages — размер extent, который нам нужен при планировании табличного пространства.

3. Оценка данных типа long.

Данные типа long хранятся и структурируются отдельно от других данных.

В DB2 существует два типа для long-данных:

• Long VARCHAR

• Long VARGRAPHIC

Для них используется отдельная 4 Кбайтная страница.

4. Данные типа LOB.

Для того, чтобы оценить LOB-данные, необходимо рассмотреть 2 объекта:

1. LOB data object

Данные хранятся в 4 Кб пространстве, которое разбивается не сегменты по1 Кб.

2. LOB allocation object. (Хранятся на 4 Кб странице).

Под этими объектами рассматривается не используемое пространство.

5. Пространство для индексов

Для каждого индекса используется место, которое можно разместить как в табличном пространстве, так и в отдельном табличном пространстве. Для оценки используется формула:

(average index keysize +8)* number of rows *3.2

average index keysize — количество байт под каждую колонку, включая индекс.

+8 и *3.2 используются для округления.

Временное табличное пространство, используемое для создания индекса, рассчитывается по такой же формуле, только вместо *3.2 будет *2.

Объекты системы

Параметры:

1. Параметры конфигурации

2. Бизнес-правила

3. NOT NULL ограничения

4. Уникальные ограничения

5. Ограничения первичного и вторичного ключа

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

1. Существует два типа конфигурационных файлов:

• Для менеджера БД

• Конфигурационный файл БД.

Параметры содержат значение ресурсов системы на уровне Instance.

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

2. Бизнес-правила.

Обеспечивают соответствие БД некоторым обязательным требованиям (ограничениям):

1. NOT NULL ограничения. Предполагается, что в каждой ячейке таблицы содержится информация, т.е. не пустые ячейки.

2. Unique (т.е. должен быть столбец, значения которого уникальны, т.е. является первичным ключом).

3. Primary key (первичный ключ).

4. Foreign key (первичный ключ для другой таблицы).

5. Check (проверка корректности ввода).

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

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

DEPARTMENT

DEPTNO Primary key	DEPTNAME	MGRNO
A00	Comp.Serv.	10
B01	Planning	20
C01	Inform. Center	10
D11	Manuf. Syst.	60

EMPNO Primary key	First Name	Last Name	WORKDEPT Foreign key
10	Christine	Haas	A00
20	Sally	Kwan	B01
30	Sean	O’Connel	D11
40	Heather	Nichols	D11
60	Irving	Stern	D11
10	Christine	Haas	C01

EMPLOYEE

Лекция №6 (14.03.02)