стым и легко стандартизуемым алгоритмам. Первым этапом при решении таких задач является проектирование базы данных. Под базой данных понимают совокупность взаимосвязанных файлов. Напомним, что файлом называется поименованная совокупность данных, предназначенная для хранения на внешних носителях. Отсюда следует, что для проектирования базы данных необходимо разработать структуру файлов и их взаимосвязей.

Delphi поддерживает реляционную модель данных, поэтому необходимо разработать файлы согласно этой модели. Другими словами, структура файлов в Delphi должна соответствовать реляционной модели данных. По теории реляционной модели данных и по вопросам их проектирования имеется обширная литература. Здесь ставим задачу поскромнее: изложить основные принципы проектирования. В основе реляционной модели данных лежит обычная таблица, в этом смысле реляционная модель похожа на записи в Pascal’е. Структура таблицы традиционная: заголовок (заголовок не может быть “многоуровневым”) и данные, например:

Табельный номер	Фамилия	Имя	Отчество	Год рождения

Всей таблице соответствует файл, одной строке в таблице – запись (в файле), запись состоит из полей. Проектирование структуры таблицы включает в себя следующее:

• определение имени (идентификатора) таблицы;

• определение перечня столбцов – полей;

• для каждого поля:

• внутреннее имя;

• тип данных;

• диапазон допустимых значений (по возможности);

• выбор ключа (первичного индекса);

• выбор вторичного(ых) индекса(ов).

Рассмотрим это подробнее. Внутреннее имя столбца – это идентификатор, в том же самом смысле, как в языках программирования.

Тип данных: смысл такой же, как и в языках программирования, но в задачах обработки данных обычно используется расширенный состав типов данных. Например, часто имеется тип данных “дата”.

Диапазон допустимых значений – это множество возможных значений в данном столбце. Часто при решении реальных задач этот диапазон удается определить и он используется в ходе работы с базой данных для проверки правильности ввода данных в таблицу. Конечно, определить диапазон допустимых значений для поля “Фамилия” невозможно, но для поля “Год рождения” вполне возможно. Например, для студентов год рождения в подавляющем большинстве находится в пределах [(текущий год) –25 . . . (текущий год)–16]. Разумеется, из того, что значение попало в допустимый диапазон еще не следует, что оно введено правильно.

Ключ – это поле (или поля), которое (ые) однозначно определяет значения всех других полей. Например, среди малого количества людей ключом может служить фамилия: она однозначно определяет конкретного человека и таким образом все его личные данные. Среди большого количества людей фамилия уже может не обеспечивать однозначности. В приведенной выше таблице имеется поле “табельный номер”. Можно в пределах одной организации определить такой порядок определения табельных номеров, чтобы они никогда не совпадали. Например, в вузе номер зачетной книжки состоит из года приема студента и его порядкового номера среди принятых в этом году. При проектировании базы данных для каждой таблицы должен быть определен ключ. Если среди данных нет поля, обеспечивающего однозначность, то ключ необходимо конструировать самому (пример с номерами зачетных книжек) или иметь составной ключ из нескольких полей.

Вторичный индекс (иногда говорят вторичный ключ) призван облегчить выполнение операций доступа к данным, а также выполнение некоторых служебных операций. Необходимость часто иметь вторичный индекс видна из следующих рассуждений. Данные в файле можно упорядочить по ключу и при поиске тогда нет необходимости проводить полный перебор: используя упорядоченность, можем получать прямой доступ к данным. При необходимости поиска по всем остальным полям придется выполнять полный перебор для нахождения записей с требуемыми значениями. Простой пример: список людей. Если он не упорядочен по алфавиту, то для определения, имеется ли в списке Петров П.П. придется просматривать весь список. Допустим, что список упорядочен по алфавиту, но возник вопрос: “Имеется ли в списке человек, которого зовут Аполлинарий?” Очевидно, что для получения ответа на этот вопрос придется просматривать весь список до конца или по меньшей мере до нахождения искомого имени. Реализация вторичного индекса выполняется самим Delphi, но в принципе он представляет собой таблицу следующей структуры:

Вторичный индекс	Ключ

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

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

Результаты проделанной работы по проектированию файлов целесообразно оформлять в виде следующей таблицы:

Имя файла: KADRY

№	Содержание поля	Имя поля	Тип данных, длина	Диапазон значений	Индексы
11	Табельный номер	TAB#	Короткое целое – 2	0001 – 9999	Ключ
22	Фамилия	FAM	Символ – 18
33	Имя	IMJA	Символ – 10
44	Дата рождения	DATA_R	Дата	1.1.1973 – 31.12.82
35	Специальность	SPEC	Короткое целое – 2		Вторичный индекс

5.2. Связывание файлов. Проектирование базы данных

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

Таблица 1. Специальности

№	Номер специальности	Название специальности
1	0102	Прикладная математика
2	0711	Динамика и прочность машин
3	2201	ЭВМ и сети

Таблица 2. Студенты

№	Номер зачетной книжки	Фамилия И.О.	Специальность
A	960125	Иванов П.Р.	0102
B	963210	Куперянов А.Л.	0102
C	966543	Федулов Р.Д.	2201

Примечание:подчеркивание означает, что это поле – ключ, при табличном представлении так обычно выделяют его.

Поставим перед собой задачу подготовить таблицу, где содержатся фамилии студентов и названия их специальностей. Согласно определению эти таблицы могут быть соединены только по полям “Номер специальности” в табл. 1 и “Специальность” в табл. 2. Соединению подлежат записи (строки), в которых в названных полях имеются равные значения. В нашем случае: (1-A), (1-B), (3-C). Запись 2 из табл. 1 не участвует в соединении, потому что в табл. 2 нет записи со значением 0711 в этом поле. В результате получим табл. 3.

Таблица 3. Студенты и специальности

Фамилия И.О.	Название специальности
Иванов П.Р.	Прикладная математика
Куперянов А.Л.	Прикладная математика
Федулов Р.Д.	ЭВМ и сети

В принципе можно было бы иметь только один файл со следующими полями:

• номер зачетной книжки;

• фамилия И.О.;

• номер специальности;

• название специальности.

Возникает вопрос: каким образом распределить данные между создаваемыми файлами – таблицами? Что лучше: много “маленьких” или немного “больших” таблиц, где разумный компромисс? Этот вопрос детально обсуждается в теории реляционных баз данных в разделе “Нормализация”. Обсуждение нормализации выходит за рамки данного учебного пособия, отметим лишь основное. Таблица считается нормализованной, если ключ непосредственно (не транзитивно) определяет все остальные поля. Очевидно, что если перечисленные выше четыре поля включить в одну таблицу, то это требование не выполняется: в таблице имеется транзитивная зависимость:

номер зачетной книжки



номер специальности



название специальности

Табл. 1 и 2 удовлетворяют требованиям нормализации. Недостатки ненормализованных таблиц:

• избыточность информации: название специальности присутствует много раз;

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

Преимущества ненормализованных таблиц: легче реализовать – нет необходимости обеспечить выполнение соединения.

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

• в обеих таблицах должно быть по меньшей мере одно общее поле;

• эти поля в обеих таблицах должны иметь одинаковые типы данных и длину (названия могут быть разными);

• по этим полям обе таблицы должны иметь вторичный индекс (за исключением случая, когда участвующее в соединении поле является ключом);

• иногда необходимо определить ведущую и ведомую таблицы.

Рассмотрим подробнее последние понятия. Между двумя таблицами могут быть отношения:

• 1:1 (один к одному): одной записи в первой таблице всегда соответствует одна и только одна запись во второй таблице;

• 1:М (М:1) (один ко многим, многие к одному): одной записи в первой таблице (эта таблица называется ведущей) может соответствовать несколько записей во второй (ведомой) таблице, но каждой записи во второй таблице соответствует только одна в первой;

• M:N (многие к многим) одна запись в первой таблице связана со многими записями во второй и наоборот.

Приведенные табл. 1 и 2 относятся ко второму случаю: каждый студент учится по одной специальности, но по каждой специальности учатся много студентов. Поэтому табл. 1 ведущая, табл. 2 ведомая. Графически это обозначают следующим образом:

Специальности  Студенты

Аналогично отношение 1:1 обозначается через , а M:N через . Случай M:N надо рассмотреть отдельно, по умолчанию Delphi (и многие другие СУБД) не разрешают им пользоваться.

Подведем итоги. Для проектирования базы данных необходимо:

• составить перечень данных, хранение которых необходимо обеспечить;

• распределить их по файлам;

• продумать связи между файлами, для каждой связи выполнить приведенные выше требования для соединения;

• разработать структуру каждого файла.

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

Имя табл. 1 (имя поля)  Имя табл. 2 (имя поля).

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