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

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

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

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

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

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

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

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

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

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

Имя файла: KADRY

Комментарии запрещены.