При проектировании БД решаются 2 проблемы: 
1. Как отобразить объекты модели данных - **логическое проектирование**
2. Как обеспечить эффективность выполнения запросов к БД, т. е. как имея ввиду особенности конкретной СУБД, расположить данные во внешней памяти, создание каких дополнительных структур потребовать - **физическое проектирование**
  
Таким образом, суть проектирования в том, что выбираются отношения, из каких будет состоять БД, и определяется, какие атрибуты должны быть у этих отношений
## Нормализация
Проектирование реляционных БД производится методом последовательных приближений к удовлетворительному набору схем отношений. Исходная точка является представлением предметной области в виде одного или нескольких отношений.  
**Процесс проектирования** - это процесс нормализации схем отношений, причем каждая следующая **нормальная форма (НФ/NF)** обладает свойствами лучшими, чем предыдущая.  
Каждой НФ соответствует некоторый определенный набор ограничений.  
Существуют такие нормальные формы:
- Первая НФ (1НФ/1NF)
- Вторая НФ (2НФ/2NF)
- Третья НФ (3НФ/3NF)
- НФ Бойса-Кодда (BCNF)
- Четвертая НФ (4НФ/4NF)
- Пятая НФ (5НФ/5NF)
  
Основные свойства НФ:
- Каждая следующая НФ в некотором смысле лучше предыдущей
- При переходе к следующей НФ свойства предыдущих НФ сохраняются
  
**Нормализация** - это декомпозиция отношения, находящегося в предыдущей НФ в два или более отношений, удовлетворяющих требованиям следующей НФ.  
Нормализацию часто завершают на 3НФ.  
При использовании ненормализованных таблиц возможны проблемы: избыточность данных, аномалии обновления, удаления, ввода.  
#### Пример нормализации
**Исходные данные**  
Предметная область: отдел кадров учреждения  
Сущность: сотрудники  

| ФИО | Дата рождения | Адрес | Телефон | Должность | Разряд | Зарплата | Дата приема | Дата увольнения |
| --- | ------------- | ----- | ------- | --------- | ------ | -------- | ----------- | --------------- |
|     |               |       |         |           |        |          |             |                 |
  
**1НФ** - значения атрибутов отношения должны быть атомарны (неделимы).  
Сущность: сотрудники  

| Фамилия | Имя | Отчество | Дата рождения | Улица | Дом | Квартира | Сотовый телефон | Рабочий телефон | Должность | Разряд | Зарплата | Дата приема | Дата увольнения |
| ------- | --- | -------- | ------------- | ----- | --- | -------- | --------------- | --------------- | --------- | ------ | -------- | ----------- | --------------- |
|         |     |          |               |       |     |          |                 |                 |           |        |          |             |                 |
  
**2НФ** - отношение находится во 2НФ в том и только в том случае, когда отношение находится в 1НФ и каждый неключевой атрибут полностью зависит от первичного ключа.  
**Алгоритм трансформации:**
1. Определить, на какие части можно разбить первичный ключ так, чтобы некоторые из неключевых полей зависели от одной из этих частей.
2. Создать новую таблицу для каждой такой части ключа и группы зависящих от нее полей и переместить их в эти таблицы. Часть бывшего первичного ключа при этом станет первичным ключом новой таблицы.
3. Удалить из исходной таблицы поля, перемещенные в другую таблицу, кроме тех, которые станут внешними ключами.
  
Выделим в отдельную таблицу сведения о сотруднике, как о физическом лице.  
Сущность: физические лица  

| Код физического лица | Фамилия | Имя | Отчество | Дата рождения | Улица | Дом | Квартира | Сотовый телефон | Рабочий телефон |
| -------------------- | ------- | --- | -------- | ------------- | ----- | --- | -------- | --------------- | --------------- |
|                      |         |     |          |               |       |     |          |                 |                 |
  
Сущность: сотрудники  

| Код сотрудника | Код физического лица | Должность | Разряд | Зарплата | Дата приема | Дата увольнения |
| -------------- | -------------------- | --------- | ------ | -------- | ----------- | --------------- |
|                |                      |           |        |          |             |                 |
  
**3НФ** - отношение находится в 3НФ в том и только в том случае, когда отношение находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.  
Выявляется и обнаруживается, есть функциональная зависимость между атрибутами код сотрудника и зарплата, она транзитивная. Предлагается сущность сотрудники разбить на сущности сотрудники и должности.  
Сущность: сотрудники  

| Код сотрудника | Код должности | Код физического лица | Дата приема | Дата увольнения |
| -------------- | ------------- | -------------------- | ----------- | --------------- |
|                |               |                      |             |                 |
  
Сущность: должности  

| Код должности | Должность | Разряд | Зарплата |
| ------------- | --------- | ------ | -------- |
|               |           |        |          |
  
Сущность: физические лица  

| Код физического лица | Фамилия | Имя | Отчество | Дата рождения | Улица | Дом | Квартира | Сотовый телефон | Рабочий телефон |
| -------------------- | ------- | --- | -------- | ------------- | ----- | --- | -------- | --------------- | --------------- |
|                      |         |     |          |               |       |     |          |                 |                 |
## Семантическое моделирование данных
Реляционных БД достаточно для моделирования большинства предметных областей. Но при реальном проектировании обнаруживается их ограниченность, у модели нет достаточных средств для отражения смысла данных. Трудно моделировать предметную область на основе плоской таблицы.  
**Проектирование** - это выделение сущностей и связей между ними. Модель не предполагает аппарата для разделения сущностей и связей. В развитии реляционной модели появилась семантическая модель данных **Entity Relationship (ER)**. Эта модель рисуется в виде **ER-диаграмм**. Моделирование базируется на графических диаграммах. Сущность: связь-атрибут.  
**Сущность** - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. Диаграмма - прямоугольник, внутри которого имя сущности (при этом имя сущности - это имя типа, а не некоторого конкретного экземпляра).  
![Сущности](../Pictures/07_01.%20Сущности.png)  
**Связь** - графически изображаемая ассоциация, устанавливаемая между 2 разными сущностями (она бинарна). На концах указывается имя конца связи (сколько экземпляров данной сущности связывается), обязанность связи (т. е. любой экземпляр сущности должен участвовать в связи).  
![Связи между сущностями](../Pictures/07_02.%20Связи%20между%20сущностями.png)  
Каждый билет предназначен только **для** 1 пассажира. Каждый пассажир может **иметь** 1 или более билетов.  
**Атрибут** - любая деталь (характеристика), которая служит для идентификации, классификации, численной характеристики, выражения состояния, уточнения сущности.  
**Уникальный идентификатор (id)** - такой атрибут или их комбинация, однозначно отличающая любой экземпляр сущности от других экземпляров этой сущности.  
![Атрибуты сущности](../Pictures/07_03.%20Атрибуты%20сущности.png)  
## История реляционных БД
Первая экспериментальная реляционная СУБД - **System R**. Придумана фирмой IBM в 1975-1979 гг.