Вторая нормальная форма (далее – 2НФ) выставляет такие требования, как и первая нормальная форма (далее – 1НФ) и добавляет ещё одно:
- В базе данных (далее – БД) колонки таблиц не должно быть частичной зависимости от первичного ключа (primary key).Предположим, что в таблице developers-specialties мы хотим разместить developer_id, developer_name, developer_salary, specialty_id, specialty_name.
Данная таблица будет выглядеть следующим образом:
CREATE TABLE developers(
DEVELOPER_id INT NOT NULL,
DEVELOPER_NAME VARCHAR (20) NOT NULL,
DEVELOPER_SALARY INT NOT NULL,
SPECIALTY_ID INT NOT NULL,
SPECIALTY_NAME,
PRIMARY KEY (DEVELOPER_ID, SPECIALTY_ID)
);
Данная таблица находится в 1НФ, так как она выолняет все её правила. В этой таблице первичный ключ состоит из developer_id и specialty_id. Оба эти значения уникальны, так как разработчик не может иметь две одинаковые специальности.
Тем не менее, таблица не во 2НФ, потому что у нас есть зависимость колонки от первичного ключа. developer_name зависит от specialty_id и у нас нет реальной ссылки между именем разработчика и его специальностью (мы не можем определить данные разработчика по полю developer_name).Такая же ситуация со specialty_id и developer_id, потому что нет ссылки между developer_id и specialty_id.
Для того, чтобы привести данную БД ко 2НФ, мы должны разделить данную таблицу на три:
- developers
CREATE TABLE developers( DEVELOPER_ID INT NOT NULL, DEVELOPER_NAME VARCHAR (100) NOT NULL, DEVELOPER_SALARY INT NOT NULL, PRIMARY KEY (DEVELOPER_ID) );
- specialties
CREATE TABLE specialties(
SPECIALTY_ID INT NOT NULL,
SPECIALTY_NAME VARCHAR (20) NOT NULL,
PRIMARY KEY (SPECIALTY_ID)
);
- developers_specialties
CREATE TABLE developers_specialties(
DEVELOPER_ID INT NOT NULL,
SPECIALTY_ID INT NOT NULL,
PRIMARY KEY (CUST_ID, ORDER_ID)
);
После этого наша БД будет приведена ко 2НФ.
На этом мы заканчиваем изучение 2НФ БД.