Из рисунка выше видно, что Audi A4 принадлежит сотруднику с идентификатором 1, то есть Иванову Ивану. Два автомобиля BMW X3 и Ford Mondeo у сотрудника Петрова Надежда Анатольевна. Fiat Panda принадлежит Афанасию Константиновичу и т.д. Сотрудник Первый Николай Николаевич не имеет ни одного автомобиля, так как в таблице «Автомобили сотрудников» нет ни одной записи (ни одной строки), где бы в столбце ID_PERS было значение 4.

Разработчики создали в таблице «Автомобили сотрудников» столбец ID_PERS и сознательно настроили так, чтобы он был внешним ключом, то есть значения в нем могли бы быть только такими, которые есть в таблице «Сотрудники» в столбце ID. Теперь СУБД будет сама контролировать, запись с каким значением для графы ID_PERS добавляется в таблицу «Автомобили сотрудников». Чтобы нельзя было добавить строчку в таблицу, указав идентификатор владельца такого, которого нет. Это и есть главное назначение внешнего ключа.

В таблице «Автомобили сотрудников» значение графы ID_PERS ссылается на идентификатор конкретного сотрудника. По этому идентификатору всегда можно получить все сведения о сотруднике: Фамилию Имя Отчество, в каком отделе он работает, на какой должности и т.д. В базе данных еще есть много таблиц, и почти каждая из них имеет столбец, который ссылается на другую таблицу. Например, в таблице Сотрудников, помимо прочих, может быть еще и столбец, указывающий на идентификатор филиала, в котором работает сотрудник. По идентификатору филиала в таблице Филиалов можно найти конкретную строчку с названием филиала и другой сопутствующей информацией: адресом, телефоном и т.д.

В примере, который мы разобрали выше с Сотрудниками и Автомобилями сотрудников, у каждого сотрудника может быть несколько автомобилей. Может быть! А может и не одного. Но если база данных построена так, что согласно связи, одной строчке в одной таблице потенциально может относиться несколько строчек другой таблицы, то такая связь называется один–ко–многим. Еще бывают связи один–к–одному и многие–ко–многим. Немного подробнее поговорим об этом попозже.

Итак, раз в базе данных почти все таблицы как–то относятся к другим таблицам – «Автомобили сотрудников» к «Сотрудникам», «Филиалы» к «Сотрудникам» и т.д. – такую базу данных называют реляционной (от англ. relations – отношения).

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

Вопрос на собеседовании „Какие команды DML Вы знаете?“ не поставит нас в тупик, а удивит: насколько простое в этой компании собеседование!

Все команды языка SQL разделяются на 4 группы:

DML (Data Manipulation Language) – язык манипуляции данными. Набор из четырех основных команд, для работы непосредственно с информацией, хранящейся в таблицах. С помощью этих команд можно: выбирать из таблицы (чтение), вставлять новые строчки с информацией в таблицу (например, добавлять новые товары в таблицу товаров, добавлять нового сотрудника в таблицу сотрудников), редактировать что–то в строчках данных и удалять строки из таблицы. Помимо этих четырех команд работы с данными, есть еще одна команда – MERGE. Это операция также добавляет строчки в таблицу, но, если записи с такими же ключевыми значениями уже в целевой таблице есть, то MERGE их обновит;

DDL (Data Definition Language) – язык определения данных. Перед тем как строчки с данными добавлять в таблицу, надо сначала создать саму таблицу в базе данных. Вот для этого и нужны команды DDL: создание таблиц и других объектов базы данных, их редактирование и удаление;