ДРУГ ПОЗНАЕТСЯ В БД - теория баз данных

GLAZъ (glazy@mail.ru) & Дронич

Спецвыпуск Xakep, номер #028, стр. 028-042-2

После того, как ты определил первичный ключ, надо определить внешний ключ. Его задают в таблице, на которую ссылается главная таблица. В подчиненной таблице, помимо первичного ключа, появится внешний (кстати, они могут совпадать). Пример смотри на рисунке.

Tip:

PK = Primary Key = Первичный ключ

FK = Foreign Key = Внешний ключ

Внимательно посмотри на рисунок. Это связь между таблицами "один-ко-многим", отображенная по древней методологии IDEF1X (ГОСТы, все дела :)). Содержимое этих таблиц ищи чуть ниже.

Суть дела: есть таблица АВТОРЫ, в которой хранятся основные данные на авторов Спеца. Для каждого из авторов мы заводим поля ИМЯ, НИК и АДРЕС. Первичный ключ - НИК, так как ники у наших авторов не повторяются. Для учета мыльников одного поля недостаточно - ведь у некоторых мыло не одно (в нашем случае у Хрымза). Да и вообще неплохо вести комментарии к мылу - вдруг оно какое особенное? Поэтому мы создаем новую таблицу E-MAIL с полями НИК, МЫЛО, КОММЕНТАРИИ, где первичным ключом будет МЫЛО (ибо оно тоже не повторяется). Внешний ключ этой таблицы - НИК, так как именно по нику проводится сопоставление записей этих таблиц.

Представь, что ты нашел в таблице Ильича и решил выяснить его мыло. По твоему запросу СУБД обратится к связанной таблице E-MAIL и будет просматривать поле НИК, пока не найдет там Ильича :). Тогда она и предоставит тебе его мыло. Если же ты захочешь выяснить мыло по косвенному признаку (например, мыло авторов из Власихи), то СУБД сначала найдет НИК автора, которому в поле АДРЕС соответствует "Власиха", а потом сделает то же самое, что и в первом случае.

Как видишь, грамотно спроектированная база спокойно позволяет иметь авторов-тезок и нормально справляться с кучей мыл.

Теперь поговорим о связях. Существуют три типа связей: один-к-одному, один-ко-многим, многие-ко-многим.

При связи один-к-одному каждой строке из главной таблицы соответствует одна или ни одной строки из зависимой. И в обратном порядке: каждая строка из зависимой таблицы связывается только с одной строкой из главной. Связанные один-к-одному таблицы можно вообще объединить в одну без ущерба здоровью :).

В связи один-ко-многим каждая строка главной таблицы указывает на несколько строк в зависимой. Наоборот будет, если каждая строка из зависимой таблицы будет связана только с одной из главной. Пример - таблицы наших авторов и их мыл.

Связь многие-ко-многим предполагает, что строка из главной таблицы будет указывать на несколько строк из зависимой, а одна строка из зависимой таблицы будет связана с несколькими строками из главной. Например, таблица о распределении доступа к чему-нибудь. Несколько человек могут использовать одну папку, и один человек может использовать несколько папок.

Теперь поговорим непосредственно о СУБДах, которые позволяют воплотить всю эту... хм, теорию на практике.

MySQL

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