Внешние ключи представляют собой разновидность ограничений для таблицы. Зачем вообще что-то ограничивать? Ответ на этот вопрос следует искать в таком понятии как нормализация базы данных. Чаще всего некоторый набор законченных данных размещают не в одной таблице, а в нескольких. Соответственно, эти таблицы должны быть каким-то образом взаимосвязаны между собой и, таким образом, мы получаем гарантии того, что значение(я) столбца одной таблицы имеется в другой(их) таблице(ах). В следствие этого, в столбцы зависимых таблиц мы не сможем поместить недопустимые значения.
Как это выглядит на практике.
Представьте, что мы создаем БД, в которой будем хранить информацию о книгах. По умолчанию, каждая книга представлена названием книги (Name) и именем автора (AuthorName). Для этого мы можем создать одну таблицу, в которой и создадим столбцы ID, Name, AuthorName:

Однако такой подход не совсем оптимален. В данной таблице могут быть записи с одинаковыми значениями полей AuthorName. Вполне возможна ситуация, когда в БД имеются записи о книгах, написанных одним автором. Так что теперь, более логично информацию об авторах вынести в отдельную таблицу. В итоге мы создаем две таблицы, Books и Authors:


Теперь возникает новая задача. В таблицу Books мы можем заносить книги, значение поля AuthorID которой равно значению поля ID в таблице Authors. Иначе, если не существует автора, то как может существовать книга им написанная?! Соответственно для каждой книги в таблице Books должен существовать автор в таблице Authors. При чем для многих книг может быть один автор.
Таким образом, внешние ключи гарантируют, что никто не сможет добавить в базу новую книгу, если её автор не существует в данной базе.
Перед установкой внешних ключей следует для начала определить для зависимых таблиц уникальные индексы – первичный ключ. Установление уникального индекса для некоторого поля таблицы мы обеспечиваем уникальность значений записей в данном поле. Простым языком это можно понять на примере присвоения идентификационного кода каждому гражданину страны. Нет два одинаковых значения идентификационного кода. В той базе данных, в которой хранится информация обо всех гражданах, в поле IdentifCode установлен уникальный индекс, назначающий данному полю первичный ключ.
Назначим нашим таблицям первичные ключи. Для єтого в дизайнере каждой из таблиц выделите поле ID и правой кнопкой мыши вызовите контекстное меню, в котором выберите команду «Задать первичный ключ»:

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


После этого сохраните наши таблицы.
Теперь создадим сами связи между таблицами. Напомню, что главной таблицей является Authors, подчиненной – Books.
Поэтому переключитесь в дизайнере на таблицу Books. В пустом месте щелкните правой кнопкой мыши для вызова контекстного меню таблицы. Выберите команду «Отношения»:

В открывшемся окне нажмите кнопку «Добавить»:

Далее, раскройте элемент «Спецификация таблиц и столбцов».
В открывшемся окне выберите в качестве таблицы первичного ключа таблицу Authors и её поле ID. Для таблицы внешнего ключа оставьте таблицу Books с выбранным полем AuthorID.

Нажмите кнопку «ОК» для завершения операции.
Таким образом мы получили зависимое поле Books.AuthorID от поля Authors.ID. Теперь, попытавшись вставить в поле Books.AuthorID значение, которого еще нет в Authors.ID, мы не сможем этого сделать.
Как видите, установка внешних ключем позволяет контролировать согласованность даннях на уровне самой базы даннях.