Связываем данные

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

В теории СУБД выделяется три вида связей: один-к-одному, один-ко-мно-гим и многие-ко-многим. Расскажу подробно о каждом виде.

1. Один-к-одному. Этот вид связи применяется в том случае, когда пер­вичный ключ одной таблицы ссылает­ся на ключ другой. Чтобы было понятнее, приведу пример: допустим, у нас имеется три таблицы хакерской БД. Первая – информация о хакере: дата рождения, пол (девушки тоже бывают взломщиками ;)) и ICQ. Вторая – хакер-ские течения (тип течения, его слож­ность и начальные капиталовложе­ния). Ну и третья – тип выхода в ин­тернет (технология, скорость доступа, оценка безопасности). Все эти табли­цы нельзя свести в одну, так как в ре­зультате отсутствия связи между дан­ными о доступе в интернет и о хакерс-ких течениях (и не только о них) мы получим путаницу. А при реализации связи в виде трех разных таблиц (с помощью первичного ключа - поряд­кового номера) обеспечивается и вы­сокая скорость обработки, и упорядо­ченность данных.

2. Один- ко- многим. Наиболее типичная связь. Реализуется при копировании первичного ключа одной таблицы в дру­гую. В этом случае во второй таблице этот ключик называется уже внешним. Непонятно? Тогда опять обращусь к примеру. Возьмем две таблицы – с ин­формацией о хакере (таблица "Хакеры") и об отношениях с характеристиками эксплойтов, которые он написал (табли­ца "Эксплойты"). По сути, они связаны механизмом один-ко-многим. Действи­тельно, каждый хакер может быть авто-

ром нескольких эксплойтов (так часто и бывает), но каждый эксплойт может быть написан одним и только одним ав­тором (даже при совместной работе в хак-группах определенным эксплойтом занимается один человек). Здесь в каче­стве внешнего ключа в таблице "Эксплойты" используется ник хакера, а в качестве первичного – название эксплойта. При этом внешний ключ "ник хакера" является первичным ключиком в таблице "Хакеры", а сюда введен наме­ренно для связи двух таблиц и организа­ции поиска нужной информации. Кстати, отношение "Эксплойты" совсем не обя­зательно будет состоять лишь из одного атрибута – можно добавить характерис­тики операционок, к которым применим эксплойт, количество целей, тип (локаль­ный или удаленный) и т.п.

3. Многие-ко-многим. Суть этого ти­па связи в том, что ключ в одной таб­лице связывается с ключом другой и наоборот. С этим типом в реляцион­ной модели дела обстоят очень плохо. Точнее, эту связь напрямую вообще никак не реализовать. Чтобы обойти этот недостаток, используется класси­ческое решение: добавляется проме­жуточное отношение, которое будет связано типом "один-ко-многим" как с первой, так и со второй таблицей. Опять наглядный пример. Имеем два отношения: информация о хакерах и данные о серверах, которые когда-то были взломаны. Если подумать, то мы владеем следующей структурой: од­ним злоумышленником могут быть хакнуты несколько серверов (так час­то и бывает в жизни), а на один сер-вак могут поселиться несколько хаке­ров (одновременно или последова­тельно), если админ вовремя не про-патчил баг. Чтобы реализовать по­добную схему в реляционной БД, мы добавим промежуточное отношение из двух полей: ник хакера и адрес сер­вера. Таким образом, эта вспомога­тельная таблица будет иметь связь "один-ко-многим" как с первым, так и со вторым отношением. Конечно, в этом случае повысится избыточность данных, поэтому эксперты рекоменду­ют избегать таких связей.

Вот, собственно, и вся информация о реляционной модели. Чтобы поды­тожить этот раздел, скажу, что многие СУБД построены именно на ее осно­ве. Я бы с удовольствием рассказал про булеву алгебру, на законах кото­рой основана реляционная модель, но, к сожалению, объемы этой статьи не позволят мне этого сделать.