Перевод ER-модели в реляционную модель: Путеводитель для начинающих

Здравствуйте, будущие маги баз данных! Сегодня мы отправляемся в увлекательное путешествие из мира моделей сущность-связь (ER) в страну реляционных моделей. Не волнуйтесь, если вы чувствуете себя немного потерянными — мы будем двигаться шаг за шагом, и к концу вы сможете преобразовывать ER-диаграммы в реляционные схемы, как профессионал!

Почему нужно преобразовывать ER в реляционное?

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

Теперь, давайте рукавами и начнём!

Маппинг сущности

Что такое сущность?

Сущность — это как "вещь" в нашем мире баз данных. Это может быть человек, место или объект — что-то, о чём мы хотим хранить информацию.

Как маппить сущность

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

Давайте рассмотрим пример:

Студент
ID (PK)
Имя
Возраст
Специальность
```

Здесь мы маппим сущность 'Студент' в таблицу 'Студент'. 'ID'是我们的主键 (PK), который уникально идентифицирует каждого студента.

Несколько слов о primary keys

Представьте primary key как уникальную идентификационную карту студента. Так же, как ни два студента не должны иметь одну и ту же идентификационную карту, ни две строки в нашей таблице не должны иметь одинаковый primary key.

Маппинг отношений

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

Отношение один-ко-многим

Это как учитель и его студенты. Один учитель может иметь много студентов, но каждый студент имеет только одного учителя (в этом контексте).

| Учитель | | Студент | |--------------| |--------------| | УчительID(PK)| | УченикID(PK) | | Имя | | Имя | | Предмет | | УчительID(FK)|

Смотрите на 'УчительID' в таблице Студент? Это наш foreign key (FK). Он ссылается на УчительID в таблице Учитель, создавая отношение.

### Отношение много-ко-многим

Думайте о студентах и курсах. Студент может посещать много курсов, и курс может иметь много студентов. Для этого нам нужна промежуточная таблица:


| Студент      |   | Зачисление   |   | Курс        |
|--------------|   |--------------|   |--------------|
| УченикID(PK) |   | УченикID(FK) |   | КурсID(PK)  |
| Имя          |   | КурсID(FK)   |   | Название курса |
|              |   | Оценка       |   |              |

Таблица Зачисление соединяет Студентов и Кurse, позволяя многие-ко-многим отношениям.

Маппинг слабых наборов сущностей

Слабая сущность — это как sidekick — она не может существовать без своего супергероя (сильной сущности). В терминах базы данных, у неё нет своего primary key.

Давайте представим, что у нас есть 'Комната' как слабая сущность 'Здания':

| Здание | | Комната | |--------------| |--------------| | ЗданийID(PK) | | НомерКомнаты | | Название | | Вместиемость | | | | ЗданийID(FK) |

Primary key для Комнаты будет комбинацией ЗданийID и НомерКомнаты.

## Маппинг иерархических сущностей

Иерархические сущности — это как семейные деревья в нашем мире баз данных. У нас есть несколько вариантов для их маппинга:

### 1. Подход с одной таблицей

Мы.put всё в одну таблицу:


| Person       |
|--------------|
| PersonID(PK) |
| Name         |
| Type         |
| EmployeeID   |
| StudentID    |

Этот подход работает, но может привести к множеству нулевых значений.

2. Подход с таблицей для каждого типа

Мы создаем таблицу для базового типа и отдельные таблицы для каждого подтипа:

| Person | | Employee | | Student | |--------------| |--------------| |--------------| | PersonID(PK) | | PersonID(FK) | | PersonID(FK) | | Name | | EmployeeID | | StudentID | | | | Department | | Major |

Этот подход более гибкий, но требует объединений для запросов.

### 3. Подход с таблицей для каждого конкретного типа

Мы создаем отдельные таблицы для каждого типа, повторяя общие атрибуты:


| Employee     |   | Student      |
|--------------|   |--------------|
| PersonID(PK) |   | PersonID(PK) |
| Name         |   | Name         |
| EmployeeID   |   | StudentID    |
| Department   |   | Major        |

Этот подход avoids null значения, но может привести к избыточности данных.

Заключение

И вот оно, folks! Мы совершили путешествие из концептуального мира ER-моделей в concrete realm реляционных баз данных. Помните, что практика makes perfect. Попробуйте создать свои собственные ER-диаграммы и преобразовывать их в реляционные модели. Before вы know it, вы будете speak the language of databases fluently!

Keep learning, keep growing, и, что самое главное, получайте удовольствие от работы с базами данных. Until next time, happy coding!

Credits: Image by storyset