> For the complete documentation index, see [llms.txt](https://rema.gitbook.io/it-business-system-analyst/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rema.gitbook.io/it-business-system-analyst/systems_analyst/rabota-s-dannymi-work-with-data/model-dannykh.md).

# Модель данных

| Грейд     | Роль               |
| --------- | ------------------ |
| 🔵 Middle | 🅰️ System Analyst |

> Модель данных — это формализованное описание того, какие данные существуют в системе, как они связаны между собой и по каким правилам живут. Для системного аналитика это один из ключевых артефактов проектирования.

## Что такое модель данных

Модель данных определяет структуру информации в системе: какие сущности (объекты) существуют, какие у них атрибуты (свойства) и какие связи (отношения) между ними. Это не просто схема базы данных — это язык, на котором аналитик описывает предметную область в терминах, понятных и бизнесу, и разработчикам.

## Три уровня моделирования

Проектирование модели данных проходит через три уровня абстракции. Каждый уровень отвечает на свой вопрос:

### Концептуальная модель (Conceptual)

**Вопрос:** «Какие сущности есть в предметной области и как они связаны?»

Это высокоуровневая схема, понятная бизнесу. Она не привязана к конкретной СУБД и не содержит технических деталей. Обычно рисуется на этапе сбора требований.

**Пример:** в системе интернет-магазина концептуальная модель может содержать сущности «Клиент», «Заказ», «Товар», «Оплата» и связи между ними: клиент оформляет заказ, заказ содержит товары, к заказу привязана оплата.

### Логическая модель (Logical)

**Вопрос:** «Какие атрибуты у сущностей и какие типы связей?»

Здесь появляются атрибуты, типы данных (без привязки к конкретной СУБД), первичные и внешние ключи, кардинальность связей (1:1, 1:N, M:N). Это основной артефакт аналитика при проектировании.

**Пример:** сущность «Заказ» имеет атрибуты: order\_id (PK), customer\_id (FK), created\_at (datetime), status (enum: new, paid, shipped, delivered), total\_amount (decimal). Связь с «Клиент» — many-to-one.

### Физическая модель (Physical)

**Вопрос:** «Как данные хранятся в конкретной СУБД?»

Включает имена таблиц, типы данных конкретной СУБД (VARCHAR(255), BIGINT), индексы, партиционирование, constraints. Обычно создаётся совместно с разработчиком или DBA.

## Что делает аналитик с моделью данных

| Задача                    | Что конкретно делать                                                                               |
| ------------------------- | -------------------------------------------------------------------------------------------------- |
| Анализ предметной области | Выделить сущности из бизнес-процессов и требований                                                 |
| Проектирование            | Нарисовать ER-диаграмму, определить атрибуты и связи                                               |
| Согласование              | Провести ревью модели с бизнесом (понятны ли сущности?) и с разработкой (реализуемо ли?)           |
| Документирование          | Описать каждую сущность и атрибут в Data Dictionary                                                |
| Валидация                 | Проверить модель на типовых сценариях: «а что будет, если клиент сделает два заказа одновременно?» |

## Нормализация: зачем и когда

Нормализация — это процесс устранения избыточности данных. Существует несколько нормальных форм (1NF, 2NF, 3NF, BCNF), и аналитику важно понимать первые три.

**Практическое правило:** нормализуйте до 3NF при проектировании OLTP-систем (транзакционные системы). Денормализуйте осознанно для OLAP-систем (аналитические хранилища), где скорость чтения важнее компактности.

**Пример проблемы без нормализации:** если адрес клиента хранится прямо в таблице заказов, то при 100 заказах одного клиента адрес дублируется 100 раз. При смене адреса придётся обновить все 100 записей.

## Инструменты для моделирования

| Инструмент              | Для чего                                        |
| ----------------------- | ----------------------------------------------- |
| draw\.io / diagrams.net | Быстрые схемы, бесплатный                       |
| Miro / FigJam           | Совместная работа над концептуальной моделью    |
| dbdiagram.io            | Логические модели из кода (DSL), бесплатный     |
| DataGrip / DBeaver      | Визуализация существующей БД, реверс-инжиниринг |
| Enterprise Architect    | Полноценное моделирование для крупных проектов  |
| PlantUML                | Модели как код, удобно для версионирования      |

## Типичные ошибки аналитика

1. **Моделирование «от таблиц», а не от предметной области** — начинайте с бизнес-сущностей, а не с полей БД.
2. **Пропуск связей M:N** — связь «многие ко многим» всегда требует промежуточной таблицы (например, order\_items между заказом и товаром).
3. **Отсутствие Data Dictionary** — модель без описания атрибутов теряет ценность через месяц.
4. **Игнорирование истории изменений** — подумайте: нужно ли хранить историю статусов заказа или только текущий статус?

## 📚 Ресурсы для изучения

**🗺️ Роадмапы**

* [SQL Roadmap — roadmap.sh](https://roadmap.sh/sql) — покрывает основы реляционного моделирования

**📖 Официальная документация**

* [ERD нотации — Vertabelo Academy](https://www.vertabelo.com/blog/crow-s-foot-notation/) — подробный гайд по Crow's Foot нотации
* [dbdiagram.io](https://dbdiagram.io/) — онлайн-инструмент с DSL для моделирования

**📝 Статьи и руководства**

* [Database Normalization Basics — Microsoft Learn](https://learn.microsoft.com/en-us/office/troubleshoot/access/database-normalization-description) — доступное объяснение нормальных форм
* [Data Modeling — IBM](https://www.ibm.com/topics/data-modeling) — обзор от IBM

**📚 Книги**

* *The Data Model Resource Book* — Len Silverston (готовые паттерны моделей для типовых доменов)
* *Database Design for Mere Mortals* — Michael Hernandez (пошаговое руководство)

**🎥 Видео**

* [Data Modeling for Beginners — freeCodeCamp](https://www.youtube.com/watch?v=QpdhBUYk7Kk) — вводный курс
* [Entity Relationship Diagram Tutorial — Lucidchart](https://www.youtube.com/watch?v=QpdhBUYk7Kk) — практический гайд по ER-диаграммам


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://rema.gitbook.io/it-business-system-analyst/systems_analyst/rabota-s-dannymi-work-with-data/model-dannykh.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.