Библиографический список

1. Крёнке Д. Теория и практика построения баз данных. 8-е изд.– СПб.: Питер, 2003 – 800 с.

2. Дейт К.Дж. Введение в системы баз данных. 6-е изд. – К.;М.;СПб.: Вильямс, 2000 – 848 с.

3. Кириллов В.В. Основы проектирования реляционных баз данных (http://www.cs.ifmo.ru/- кафедра Вычислительной техники Санкт-Петербургского государственного института точной механики и оптики)

4. http://www.codenet.ru

Приложение

Пример оптимизации таблиц и расчета объемов хранимой информации

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

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

Первый вариант: табельная информация хранится в одной таблице

Табельный номер сотрудника	Год	Месяц	1	2	3	4	…	28	29	30	31
357	2003	1	0	0	8	0		8	8	8	8
357	2003	2	0	0	8	8		8	0	0	0
406	2003	1	0	0	8	0		8	8	8	8
406	2003	2	0	0	4	0		8	0	0	0

В выходные дни (показаны 1,2 и 4 января, 1 и 2 февраля) и в несуществующие дни месяца (с 29 по 31 февраля) всем сотрудникам в табель записывается 0. Когда сотрудник отработал неполный рабочий день или находился на больничном (для примера №406 ушел с полудня 3 февраля и не вышел на работу 4 февраля), ему в табель заносится фактическое количество часов.

CтолбцыТабельный номериГодхранятся в форматеINT(4 байта), остальные – в форматеTINYINT(1 байт). Одна строка таблицы занимает 42 + 32 = 40 байт. Объем, необходимый для хранения всех табелей работников за год составляет:

40 байт 12 месяцев1000 чел. = 480000 байт469 Кб.

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

Второй вариант: табельная информация хранится в одной таблице:

Табельный номер сотрудника	Год	Месяц	День	Часы
357	2003	1	3	8
357	2003	1	5	8
357	2003	1	…
357	2003	1	31	8
406	2003	1	3	8
406	2003	1	5	8
406	2003	1	…
406	2003	2	3	4

День- день месяца,Часы- количество отработанных часов в этот день. Дни, когда работник не работал (часы=0) в таблицу не заносятся.

CтолбцыТабельный номериГодхранятся в форматеINT(4 байта), остальные – в форматеTINYINT(1 байт). Одна строка таблицы занимает 42 + 3 = 11 байт. Объем, необходимый для хранения всех табелей работников за год составляет:

11 байт 250 рабочих дней1000 чел. = 2750000 байт2,68 Мб.

Вычисление количества отработанных часов выполняется суммированием поля Часыстрок, относящихся к одному сотруднику, примерно за 20–25 сложений. Поиск сотрудников, пропускавших рабочие дни требует анализа дат (специального алгоритма).

Третий вариантоснован на том, что у большинства сотрудников один и тот же рабочий режим: 8-часовой рабочий день, общие выходные, праздники, укороченные предпраздничные дни. Индивидуальны отгулы, отпуск, больничные и т.п. Информация, общая для большинства работающих, располагается в таблицахНорма_часовиНестандартные_дни.ТаблицаИсключенияхранит отличия от общепринятого графика работы.

Норма_часов

Код_1	Табельный номер сотрудника	Год	Месяц	Норма часов в день
1	357	2003	1	8
2	357	2003	2	8
3	406	2003	1	8
4	406	2003	2	8
5	198	2003	2	4

Нестандартные_дни

Год	Месяц	День месяца	Часов в день
2003	1	1	0
2003	1	2	0
2003	1	4	0
2003	2	1	0
2003	2	2	0
2003	2	23	0
2003	3	7	6

Исключения

Код_1	День месяца	Ч Столбец Код_1 является суррогатным ключом, заменяющим составной ключ (Табельный номер сотрудника; Год; Месяц) с целью экономии памяти. асов в день
4	3	4
4	4	0
2	23	8

Сотрудники № 357 и № 406 работают 8-часовой рабочий день, сотрудник № 198 работает на 0,5 ставки, его норма – 4 часа в день (см. таблицу Норма_часов). ТаблицаНестандартные_днихранит количество часов, общее для большинства сотрудников. Так, 1,2,4 января и 1,2,23 февраля – выходные дни (0 часов), а 7 марта – предпраздничный укороченный день (6 часов). В таблицеИсключениязаписываются все отличия работы сотрудников от "общепринятого" графика. Первая и вторая строки таблицыИсключенияотражают факт, что сотрудник №406 в феврале 3 числа отработал 4 часа, а 4 числа отсутствовал. Третья строка таблицыИсключенияпоказывает, что сотрудник №357 выходил 23 февраля на работу и отработал 8 часов.

Подсчитаем объемы памяти, необходимые для хранения табелей всех сотрудников за год. Допустим, столбцы Код_1,ГодиТабельный номер сотрудникаимеют типINT(4 байта), все остальные столбцы – типTINYINT(1 байт). Строка таблицыНорма_часов"весит" 4+4+4+1+1 = 14 байт. За год на одного сотрудника создается 12 строк; суммарный объем для всего предприятия за год: 14 байт12 строк1000 чел. = 168000 байт.

Таблица Нестандартные_днивключает примерно 120 строк, по 7 байт каждая, итого 840 байт.

В таблицу Исключенияпопадают отпускные (28 дней), отгулы, больничные и неурочный выход на работу, в среднем 40–45 строк на человека в год. Каждая строка занимает 6 байт. На всё предприятие требуется 6 байт40 строк1000 чел. = 240000 байт.

Общий объем: 168000+840+240000 = 408840 байт 400 Кб.

1 этот этап иначе называют "инфологическое моделирование", "моделирование данных", "объектное моделирование".

2 альтернативный перевод "объект-отношение". Его мы использовать не будем, поскольку термин "отношение" применяется также в реляционной модели, и там имеет совершенно иной смысл.

3 тип связи называется кардинальностью связи (cardinality).

4 при добавлении новой строки значение столбца автоматически увеличивается или уменьшается на константу, обычно на 1. За счет этого значения столбца никогда не повторяются.

5 в SQL Server текущую дату возвращает функция GetDate(), в MySQL – функция Now().

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

7 альтернативный перевод – нормальная форма область/ключ (НФОК)