Что такое связь?

 В этой статье рассматривается понятие "связь", весьма употребительное в СУБД Access. Следует отметить, что слово "связь" употребляется в Access в самых разных смыслах. Мы же говорим о связи как об элементе схемы БД (связь — это то, что изображается "веревками" между атрибутами¹ отношений).

Обращает на себя внимание тот факт, что понятие связи, являющееся одним из центральных в Access, по сути дела, нигде не определяется. Вот что написано в учебнике Ю.Шафрина: "Объект, атрибут и связь — фундаментальные понятия ИС" ( [9], стр. 531). Если объекту и атрибуту в дальнейшем в этом учебнике даются определения (хотя, на наш взгляд, и не очень ловко), то определения связи там вообще нет. Как же
так? Ведь это — одно из фундаментальных (по мнению автора) понятий, а их всего-то три!

В учебнике под редакцией проф. Н.Макаровой раздел, посвященный базам данных, начинается обещанием научить школьника "связывать разные таблицы данных" ( [7], стр. 201). Правда, авторы тут же навсегда забывают о своем обещании. Что такое связь, так и остается неразрешенной загадкой.

В учебнике С.Симоновича и др., который представляется нам наиболее приемлемым, связи таблиц уделяется большое внимание. В частности, там говорится: "Базы данных, имеющие связанные таблицы, называются также реляционными базами данных" ( [8], стр. 98). Стало быть, по мнению авторов, связь — непременный (и даже определяющий!) признак реляционности. Однако хотя в учебнике подробно расписано, как устанавливается связь, но что такое связь, там не объясняется. Конечно, это относится не только к связям и не только к школьным
учебникам. К сожалению, это вообще стиль "пользовательской" литературы. Там обычно объясняется, как с данным понятием работать (т.е. какие кнопки в каком порядке нажимать), но что это понятие означает, либо вообще не говорится, либо поясняется крайне невнятно.

В частности, Help Access так определяет связь: "Отношение (связь), установленное между общими полями (столбцами) двух таблиц. Существуют отношения "один к одному", "многие ко многим" и "один ко многим". Можно ли отсюда понять, что такое связь?
Маловероятно. В справочнике [2] связь определяется так: "Соединение, данных двух таблиц, с помощью общего поля (или нескольких полей) — идентификатора записи" (стр. 393). Это определение поясняется следующим образом: "Когда между таблицами устанавливается связь, величины одной таблицы ставятся в соответствие величинам из другой таблицы. Чтобы создать связь, в одной или обеих таблицах должно быть поле, принимающее уникальные значения во всех записях. В родительской таблице, поле обычно индексировано (как правило, оно является ключевым полем), и в соответствие ему ставится поле дочерней таблицы (оно называется внешним ключом)" (стр. 88).

В литературе по модели "Сущность-Связь" можно найти определения такого рода: "Связь — это графически изображаемая ассоциация, устанавливаемая между двумя разными сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ею же самой (рекурсивная связь). В любой связи выделяются два конца (в соответствии с существующей парой связываемых сущностей), на каждом из которых указывается имя конца связи, степень конца связи (сколько экземпляров данной сущности связывается), обязательность связи (т.е. любой ли экземпляр данной сущности должен участвовать в данной связи)" ([4], стр. 121). На наш взгляд, такие определения мало что дают в понимании межтабличной связи в Access.

Между тем связь — это не такое уж хитрое понятие, оно вполне доступно среднему школьнику. Правда, чтобы объяснить его, в школьный курс информатики (а возможно, и математики) нужно ввести ряд новых идей. Впрочем, идеи эти давно стучатся в дверь. И нужны они, конечно, не только для объяснения понятия связи. Повторяем, что связь — это только пример.

Итак, что же это за идеи?

Для чего нужна СУБД

Начнем с одного простого, но важного вопроса: для чего нужны базы данных? Как это ни странно, но при всем внимании, уделяемом базам данных в "пользовательских курсах, этот вопрос остается как бы в тени. Между тем ответ на него ясен и прост: основная функция БД — выдавать ответы на поступающие запросы².
Если СУБД не умеет отвечать на запросы, то все ее остальные функции бессмысленны. (Отметим в скобках, что в некоторых пользовательских курсах поня­тие запроса вообще не рассматривается (см., например, [7] ). Как можно изучать СУБД, не зная, что такое запрос, — загадка.)

Как же вычисляется ответ на запрос в современных СУБД? Согласно реляционной парадигме, на которой основано подавляющее большинство систем, все данные представляются в виде отношений³ Формально отношение определяется как множество кортежей⁴. Отношение принято изображать в виде таблицы, в которой кортежи — ее строки. Отношения встречаются школьнику буквально на каждом шагу. И осознание того факта, что это обыкновенные таблицы, интересно с точки зрения развития общей культуры и мировоззрения школьника. (Мы советуем учителю не пожалеть время на то, чтобы ученики описали в виде таблиц отношения из самых разных сфер окружающего мира.)

Итак, данные представляются в виде отношений. Это относится и к исходным данным, которые хранятся в машине, и к данным, выдаваемым в ответ на запрос. Теперь мы можем уточнить наше понимание основной функции БД: выдача ответа на запрос происходит путем переработки исходных отношений в результирующие от­ношения. В качестве примера рассмотрим базу данных Школа. Пусть в ней хранятся две исходные таблицы:

  Распределение нагрузки

Конечно, если наша субд сможет выдавать только эти две таблицы, то цена ей невелика. Весь смысл в том, чтобы она умела отвечать на самые разнообразные запросы, например, на такой: "Кто кого чему учит?". Ответом на него будет такая таблица:

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

Запросы и операции над отношениями

Как же происходит эта переработка? К сожалению, в Access это окружено неким мистическим орео­лом. Пользователю предлагается некий таинственный ритуал, позволяющий машине "отгадать" его потребность. Суть же дела (сознательно или нет) затуманивается. Между тем она очень проста. Имеется небольшой набор операций над отношениями. И смысл этих таинственных и не очень понятных пользователю манипуляций сводится к тому, чтобы объяснить машине, какие именно операции и в каком порядке следует выполнить над исходными данными, чтобы получить ответ.

Конечно, учителю потребуются некоторое время и усилия, чтобы объяснить школьнику, что операции можно производить не только над числами, но и над отношениями. Но ведь это окупится не только тем, что школьник станет лучше понимать суть работы субд, но и тем, что он существенно расширит свой кругозор! Мы считаем, что это второй момент в обсуждаемом разделе курса информатики, имеющий большое общекультурное значение (первый момент — это анализ понятия отношения).

Итак, какие же операции над отношениями при­меняются при вычислении ответа на запрос? Прежде всего это фильтрация (т.е. выделение кортежей, обладающих заданными свойствами) и операции реляционной алгебры: проекция (т.е. удаление ненужных столбцов), объединение (т.е. добавление к одному отношению всех кортежей из другого отношения), теоретико-множественная разность (т.е. удаление из одного отношения всех кортежей, содержащихся в другом отношении) и, наконец, соединение отношений. (Заметим, что при "локализации" Access была допущена досадная ошибка. В результате операции соединения (join) и объединения (union) стали называться одним словом — "объединение". Это ведет к большой путанице.) 

В следующих статьях мы подробнее поговорим обо всех этих операциях. Но сейчас нас интересует только одна из них — соединение отношений. Смысл этой операции поясним на примере. Пусть у нас имеются два отношения:

Телефоны

 Звонки

 Соединив их, мы получаем третье:

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

Звонки-1

Заметим, что таблицы Телефоны и Звонки_1 можно соединять по условию Номер = Кто либо по условию Номер = Кому. Понятно, что результат в обоих случаях будет разным.

Итак, в общем случае при операции соединения нужно указывать пары соединяемых атрибутов. Отметим, что обычно требуют, чтобы атрибуты, по которым происходит соединение, имели одинаковые типы, или домены⁵ (т.е. запрещается, например, соединять по условию Дата == Адрес), но это непринципиально.

Можно указывать несколько пар соединяемых ат­рибутов, но мы для простоты ограничимся случаем, когда соединение происходит по одной паре. Тогда можно считать, что в каждой из соединяемых таблиц выделено по одному атрибуту и соединение происхо­дит по равенству значений этих атрибутов. Итак, что­бы задать операцию соединения, мы должны указать два отношения, в каждом из которых выделено по атрибуту.

Связь как полуфабрикат соединения

Вернемся к примеру с телефонами. Заметим, что хотя телефонную станцию постоянно интересует соединение таблиц Телефоны и Звонки (ведь именно она служит основанием для выставления счетов на оплату разговоров), но хранить-то это соединение невыгодно. Во-первых, исходные таблицы Телефоны и Звонки занимают гораздо меньше памяти. (Школьникам было бы полезно сравнить объем памяти, необходимой для хранения результата соединения, и объем исходных таблиц, если на фамилии, названия городов и адреса отводится, скажем, по 20 байт, а каждый абонент имеет в среднем по 1000 разговоров.) Во-вторых, при раздельном хранении гораздо легче вносить изменения (скажем, если владелец телефона сменил фамилию).

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

Выше мы для простоты рассмотрели только один тип соединения — внутреннее. Однако есть еще два типа соединения: левое внешнее и правое внешнее. Мы не будем давать их формальное определение, а ог­раничимся примерами. Рассмотрим таблицы:

Телефоны

Звонки

 Их внутренним соединением по условию Номер = Кто будет таблица

левым внешним соединением — таблица

а правым внешним соединением — таблица

Не вдаваясь в детали, отметим, что в первом случае соединились все кортежи исходных таблиц, у которых совпадают значения атрибутов Номер и Кто, во втором случае к ним добавились еще и оставшиеся корте­жи первой таблицы, а в третьем — оставшиеся кортежи второй таблицы⁶.

Итак, имеется три типа соединения. Поэтому, задавая связь, мы должны указать не только соединяемые отношения, не только пару атрибутов, по которым происходит соединение, но еще и тип соединения.

Связи и ограничения целостности

Это еще не все. Как мы уже говорили, таблица Access — это не совсем то, что мы обычно понимаем под словом "таблица". Кроме строк, столбцов и прочей "видимой части", в таблице запрятана еще кое-какая информация. Это некие законы, правила или аксиомы, называемые в теории БД ограничениями целостности.

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

К сожалению, в Access ограничения целостности разбросаны в разных местах и называются по-разному. Тем не менее мы будем говорить о них собирательно. Более того, мы будем употреблять термин "ограничения целостности" в более широком смысле, чем фирма Microsoft. В Help Access целостность данных определяется так: "Правила, обеспечивающие поддержание установленных межтабличных связей при вводе или удалении записей. Если наложены условия целостности данных, Microsoft Access не позволяет добавлять в связанную таблицу записи, для которых нет соответствующих записей в главной таблице, или же изменять записи в главной таблице таким образом, что после этого в связанной таблице появятся записи, не имеющие соответствующих главных записей, а также удалять записи в главной таблице, для которых имеются подчиненные записи в связанной таблице".

Отметим, кстати, что, на наш взгляд, учитель, объясняющий работу продукта фирмы Microsoft, вовсе не обязан исповедовать идеологию фирмы Microsoft. Более того, мы считаем, что было бы весьма полезно указать на недостатки изучаемых программных продуктов. Ведь его цель не столько обучить пользоваться конкретной системой, сколько познакомить учеников с общими принципами работы подобных систем. В частности, учитель вправе и покритиковать терминологию фирмы Microsoft. Существенным недостатком пользовательских учебников является некритическое отношение к "фирменной" терминологии. Если хранить абсолютную "верность фирме", то приходится жертвовать смыслом. Например, нельзя корректно объяснить реляционные операции, если обозначать union и join одним словом.

Однако мы отвлеклись. Где же в таблицах Access запрятаны ограничения целостности? Это прежде всего типы данных. Если вы определили атрибут как числовой, то вам не удастся придать ему значение "Вася". Далее, это ограничения, связанные с ключами и индексами. Например, если вы задали атрибут Муж в качестве ключа отношения Браки, то вам не удастся записать туда, что у гражданина Иванова две жены⁷.

Приведем примеры аксиом, задающих ограничения целостности.

• Аксиома 1. Если тип данных атрибута А таблицы Т объявлен как числовой, а размер поля определен как "длинное целое", то значениями атрибута А в любом кортеже таблицы Т могут быть только целые числа в диапазоне от —2 147 483 648 до 2 147 483 647.
• Аксиома 2. Если атрибут А таблицы Т объявлен как уникальный индекс или как ключ, то в таблице Т не может быть двух кортежей с одинаковыми значениями атрибута А.

Это только два примера. Существует еще много аксиом, задающих ограничения целостности. Заметим, кстати, что представление знаний о программной системе в виде такого рода аксиом представляется нам весьма перспективным. Конечно, к ним нужно добавить еще сведения о том, какие кнопки и в каком порядке следует нажимать, чтобы выполнить то или иное действие. Например, что нужно сделать, чтобы объявить атрибут ключом или уникальным индексом или чтобы задать тип атрибута.

Итак, мы убедились, что в таблицах Access запрятаны ограничения целостности. Запрятаны они и в связях. Только здесь они связаны с каскадным удалением и обновлением. Смысл этих понятий поясним на "телефонном" примере. Если вы хотите, чтобы при смене номера в таблице Телефоны соответствующая замена производилась и в таблице Звонки, то вам нужно задать режим каскадного обновления. Если вы хотите, чтобы при удалении строки из таблицы Телефоны из таблицы Звонки удалялись все записи о звонках с этого номера, то задайте режим каскадного удаления.

Теперь перейдем к параметрам ограничения целостности. Их три. Help определяет их так.

Обеспечение целостности данных

Задайте этот параметр для обеспечения целостности данных этой связи, только если соответствующее поле из базовой таблицы является первичным ключом или имеет уникальный индекс, связанные поля имеют один и тот же тип данных, а также если обе таблицы содер­жатся в одной и той же базе данных Microsoft Access.

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

Каскадное обновление связанных полей

Для автоматического обновления соответствующих значений в связанной таблице, как бы ни менялось значение ключевого поля в базовой таблице, установите флажки Обеспечение целостности данных и Кас­кадное обновление связанных полей.

Для предотвращения изменений значения первичного ключа в базовой таблице, если существуют связанные записи в связанной таблице, установите флажок Обеспечение целостности данных и снимите флажок Каскадное обновление связанных полей.

Каскадное удаление связанных записей

Для автоматического удаления связанных записей в связанной таблице при удалении записи в базовой таблице установите флажки Обеспечение целостности данных и Каскадное удаление связанных записей.

Для предотвращения удаления записей из базовой таблицы, если имеются связанные записи в связанной таблице, установите флажок Обеспечение целостнос­ти данных и снимите флажок Каскадное удаление связанных записей.

Нам эти определения кажутся не вполне удачными, и ниже мы несколько модернизируем их. Но сейчас нам важно, что при задании связи нужно указать еще и значения параметров целостности.

Формальное определение связи

В итоге получаем следующее определение.

Это формальное определение. А содержательно, как мы уже говорили, связь — это заготовка для соедине­ния двух таблиц.

Замечание для учителя с хорошей математической подготовкой.<"> Обычно, говоря о реляционных системах, имеют в виду алгебру отношений или таблиц. В же можно говорить об алгебре, содержащей объекты двух ти­пов: таблицы и связи. Впрочем, если заменить каждую связь на таблицу, получающуюся в результате выполнения соответствующего соединения, то наша "двухосновная" алгебра погрузится в обычную реляционную алгебру.

Теперь поговорим о параметрах целостности. Определения, имеющиеся в Help и в литературе по Access, представляются нам слишком расплывчатыми. Поэтому мы переформулируем их так:

Определение 1. Пусть включен флажок Обеспечение целостности данных. Если выделенный атрибут главной таблицы⁹ является ее ключом или уни­кальным индексом, а выделенный атрибут подчинен­ной таблицы таковым не является, то говорят, что связь имеет тип один ко многим. Если оба выделенных атрибута являются ключами или уникальными индек­сами соответствующих таблиц, то говорят, что связь имеет тип один к одному.

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

Пример. В нашей телефонной БД первые кортежи в обеих таблицах связаны, поскольку на выделенных атрибутах Номер и Кто оба принимают одно значение — 55-17-18.

Теперь термины, относящиеся к связи, принимают вполне строгий смысл. Благодаря этому можно не просто рассуждать на интуитивном уровне, но и доказывать теоремы!

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

Доказательство. От противного. Пусть некоторый кортеж К главной таблицы связан с двумя кортежами К1 и К2 подчиненной таблицы. Пусть А и В — выделенные атрибуты соответственно главной и подчиненной таблицы, С — значение кортежа К на атрибуте А. Согласно определению 2 кортеж К1 должен принимать на атрибуте В то же значение С. Точно так же и К2 должен принимать на атрибуте В то же значение С. Следовательно, кортежи К1 и К2 принимают на атрибуте В одинаковые значения. Согласно аксиоме 2 отсюда следует, что В не является ключом или уникальным индексом подчиненной таблицы. Остается применить определение 1.

Аналогично доказываются следующие два утверждения.

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

Теорема 3. Если связь имеет тип один ко многим, то каждый кортеж подчиненной таблицы связан в точности с одним кортежем главной таблицы.

Упражнение. Верно ли следующее утверждение: если связь имеет тип один ко многим, то каждый кортеж главной таблицы связан в точности с одним кортежем подчиненной таблицы?

Заключение

Полезно, на наш взгляд, обратить внимание учащихся на то, что теоремы, оказывается, можно доказывать не только про числа и фигуры, но и про совсем другие вещи. Например, про программные системы. И сообщить им, что есть специальная наука, этому посвященная. Называется она Computer Science. Как мы видим, изучение модных систем ничуть не мешает приоткрыть щелочку в эту науку. Нужно только отказаться от устаревших стереотипов. И хотя здесь рассмотрен только один весьма частный вопрос, мы убеждены, что, приложив некоторые усилия, можно изложить всю "пользовательскую" информатику на достаточно высоком уровне.

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

Литература

[1] Бешенков С., Теин А., Григорьев С. Информатика и информационные технологии. Екатеринбург, 1995.

[2] Винтер Pi Microsoft Access 97: справочник. СПб., 1998.

[3] Замятин А., Аивчак А. Элементы математической теории информационных систем. Екатеринбург, 1996.

[4] Кузнецов С. Основы современных баз данных. субд, 1995, № 4.

[5] Аивчак А. Основные понятия теории баз данных. НТИ, сер. 2, 1985, №2.

[6] Аивчак А. Неоднородные отношения: язык запросов и контекстные ограничения. НТИ, сер. 2, 1989, № 12.

[7] Макарова Н. и др. Информатика. 10—11-е классы. Под редакцией проф. Н.В. Макаровой. СПб., 1999.

[8] Симонович С., Евсеев Г., Алексеев А. Специальная информатика. Учебное пособие. М., 1998.

[9] Шафрин Ю. Информационные технологии. М., 1998.

¹Атрибут  — это заголовок столбца. Иногда его называют полем. Но, к сожалению, полем часто называют и значение атрибута (т.е. содержимое клетки таблицы), что ведет к путанице.

²Для простоты мы ограничиваемся только запросами на выборку.

³Заметим, что отношение является одним из фундаментальных понятий современной математики. В школьной информатике оно выходит на первый план (см., например, пособие [1] ). К сожалению, в стандартном курсе школьной математики это понятие отсутствует, Отношение тесно связано с понятием функции, лежащим в основе школьного курса математики. Получается, что два родственных понятия изучаются в разных курсах, но никакие мосты между ними не наводятся.

⁴Иногда кортеж называют записью. Мы понимаем кортеж как функцию, сопоставляющую атрибутам их значения. Атрибут — это заголовок столбца таблицы, изображающей отношение. Значение кортежа К на атрибуте А — это содержимое клетки таблицы, находящейся на пересечении строки К и столбца А. Подробнее о предлагаемом формализме см. в пособии [3] и статье [5].

⁵Домен - это множество возможных значений аргумента.

⁶Внимательный читатель может заметить, что полученные таблицы имеют пустые поля, что не согласуется со стандартным определением отношения. Строго говоря, здесь речь идет о необднородных отношениях (см. о них в статье [6]).

⁷ Есть и другие виды ограничений целостности, связанные с условиями, ограничивающими значения атрибутов, обязательными полями и т.п.

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

⁹ Напомним, что, устанавливая связь, вы соединяете "веревкой" две таблицы, перетаскивая мышь из одной таблицы в другую. Главная таблица — это та, откуда вы тянете "веревку". Эту таблицу также называют родительской. Вторая таблица, куда вы тянете "веревку", называется дочерней, или подчиненной. Help определяет главную таблицу так: таблица на стороне "один" при связи двух табмщ с отношением "один ко многим". В главной таблии,е должно существовать ключевое поле, а все записи в ней должны быть уникальными. На наш взгляд, это определение неудачно по следующим причинам. Во-первых, оно справедливо лишь для случая связи "один ко многим". Во-вторых, из него никак не следует, что главную таблицу назначает пользователь. То, что в Help фигурирует как определение, мы считаем следствием (см. теорему 3).