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

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

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

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

Поставим перед собой задачу подготовить таблицу, где содержатся фамилии студентов и названия их специальностей. Согласно определению эти таблицы могут быть соединены только по полям “Номер специальности” в табл. 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 (имя поля).

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

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