О чём этот курс и кому он нужен
Любая система, работающая с данными — интернет-магазин, банковское приложение, аналитический отчёт — внутри себя хранит данные в каком-то виде: таблицах, документах, узлах графа. Решение «что и как хранить» и есть моделирование данных (data modeling). Это решение принимается один раз в начале, а его последствия — хорошие или плохие — компания несёт годами.
Этот курс — про то, как принимать такие решения осознанно. Не «методом тыка» и не копированием чужих схем, а понимая, ПОЧЕМУ одна модель работает, а другая порождает баги, медленные запросы и бесконечные правки.
Что такое модель данных простыми словами
Модель данных — это формальное описание того, какие сущности существуют в предметной области, какие у них свойства и как они связаны между собой. Возьмём интернет-магазин. В нём есть клиенты, заказы, товары. Клиент делает заказы. В заказе есть товары. У товара есть цена. Всё это надо где-то записать так, чтобы:
- данные не противоречили друг другу (один товар — одна цена, а не три разных в трёх местах);
- запросы выполнялись быстро (показать историю заказов клиента за секунды, а не за минуты);
- систему можно было развивать (добавить скидки, не переписав половину базы).
Модель — это чертёж. Как и в строительстве, ошибка в чертеже стоит дёшево, пока чертёж на бумаге, и очень дорого, когда здание уже построено.
Обратите внимание на средний блок. Многие начинающие пропускают его и сразу прыгают из «реальности» в «таблицы». Это и есть главная ошибка: без чертежа здание строится наугад.
Цена плохой модели
Чтобы понять, зачем тратить время на моделирование, посмотрим, что происходит, когда им пренебрегают. Представим, что разработчик решил хранить заказы интернет-магазина в одной плоской таблице:
orders
+---------+--------------+---------------------+-------------------------+----------+
| order_id| customer_name| customer_email | items | total |
+---------+--------------+---------------------+-------------------------+----------+
| 1 | Иван Петров | [email protected] | Мышь, Клавиатура | 3500 |
| 2 | Иван Петров | [email protected] | Монитор | 18000 |
| 3 | Иван Петров | [email protected] | Коврик | 500 |
+---------+--------------+---------------------+-------------------------+----------+Здесь спрятаны три классические проблемы, которые в моделировании называют аномалиями:
- Аномалия обновления. Email Ивана записан в трёх строках. Иван сменил почту — надо обновить все три. Обновили две, забыли третью (строка 3 — уже опечатка
mailru.ru). Теперь у одного человека два разных email, и система не знает, какой настоящий. - Аномалия вставки. Хотим завести нового клиента, который ещё ничего не заказал. Но строка в этой таблице — это заказ. Нет заказа — некуда записать клиента. Клиент не может существовать без заказа, хотя в реальности легко может.
- Аномалия удаления. Иван отменил заказ 3. Удаляем строку — и вместе с заказом теряем сам факт существования товара «Коврик», если он больше нигде не встречался.
Плюс колонка items со списком через запятую: невозможно посчитать, сколько всего продано мышек, без разбора строки. Невозможно узнать цену отдельного товара. Невозможно поставить ограничение «количество товара не может быть отрицательным».
Эти проблемы не «всплывут когда-нибудь потом». Они есть в схеме с первого дня. Просто пока данных мало, их не замечают — а когда замечают, в базе уже миллионы строк, и переделка превращается в многомесячный проект с риском потерять данные.
Правильно смоделированная версия разносит данные по трём связанным таблицам — клиенты, заказы, позиции заказа — и каждый факт хранится ровно один раз. Email Ивана — в одной строке таблицы customers. Меняется один раз. Клиент заводится независимо от заказов. Этому посвящён весь блок про нормализацию в курсе.
Данные как актив
Раньше данные считали побочным продуктом работы приложения — «логи, которые занимают место». Сегодня данные — это актив, такой же, как оборудование или деньги на счёте. На данных строят отчёты для руководства, обучают модели машинного обучения, принимают решения о ценах и ассортименте.
Но у актива «данные» есть особенность: его ценность зависит от структуры. Терабайт данных в хаотичной схеме почти бесполезен — из него тяжело что-либо достать достоверно. Тот же терабайт в продуманной модели — это источник ответов на вопросы бизнеса.
Именно поэтому моделирование данных — не узкая техническая задача «нарисовать таблички», а навык, который напрямую влияет на то, может ли компания доверять своим данным.
Кому нужен этот курс
Курс рассчитан на тех, кто только входит в работу с данными (уровень junior). Он будет полезен:
- Будущим data engineer и analytics engineer — для них моделирование это профессиональный фундамент. Они каждый день проектируют схемы хранилищ, и без этого навыка дальше двигаться нельзя.
- Backend-разработчикам — они проектируют базы для приложений. Хорошая схема приложения экономит месяцы будущих правок.
- Аналитикам и BI-специалистам — чтобы понимать, почему данные лежат именно так, и писать корректные запросы.
- Тем, кто переходит в данные из другой сферы — это один из первых навыков, который стоит освоить.
Что нужно знать заранее: базовый SQL (SELECT, WHERE, JOIN на уровне «видел и примерно понимаю»). Если SQL совсем незнаком — это не блокер, но первые уроки будут идти медленнее. Глубокого знания конкретной СУБД не требуется: модель данных — понятие, которое существует над любой конкретной базой.
Моделирование — навык, а не врождённый талант
Может сложиться впечатление, что хорошо проектировать данные — это что-то вроде художественного дара: либо дано, либо нет. Это не так. Моделирование данных — это ремесло, набор воспроизводимых приёмов и правил, которым можно научиться так же, как учат играть на инструменте или программировать.
За десятилетия практики накоплены чёткие техники: как находить сущности в требованиях, как нормализовать схему пошагово, как проектировать аналитические звёзды. Эти техники не «интуиция гения» — это проверенные процедуры. Опытный проектировщик отличается от новичка не врождённым талантом, а тем, что освоил эти процедуры и применял их много раз.
Что действительно нужно — это практика. Нельзя научиться моделировать, только читая про моделирование, как нельзя научиться плавать по учебнику. Поэтому курс построен вокруг практических заданий: вы будете проектировать схемы сами, ошибаться, исправлять и постепенно набирать ту самую «насмотренность», которая со стороны выглядит как талант, а на деле является накопленным опытом.
Если первые модели даются тяжело и кажутся неуклюжими — это нормально и правильно. Так выглядит начало освоения любого навыка. Важно не качество первой схемы, а то, что вы её сделали, увидели слабые места и поняли, как лучше. Через десяток спроектированных схем процесс станет естественным.
Почему «до железа»
Многие курсы по моделированию останавливаются на уровне «вот правила, делай так». Этот курс идёт глубже. Когда мы говорим, что surrogate key (искусственный ключ) ускоряет соединение таблиц, мы не просто декларируем это — мы разберём, почему: фиксированная ширина в байтах, больше строк на странице, меньше работы процессору на сравнение. Когда мы говорим, что нормализация устраняет аномалии, мы покажем аномалию как конкретный сбой, который СУБД не может предотвратить при плохой схеме.
Цель такого подхода — чтобы вы принимали решения, понимая механику, а не заучивая рецепты. Рецепт работает, пока ситуация стандартная. Понимание механики работает всегда.
Если какой-то раздел кажется слишком глубоким — это нормально. Сначала уловите основную идею (она всегда вынесена явно), а детали «до железа» вернутся в следующих модулях и постепенно станут понятны. Глубина здесь — не для запугивания, а для того, чтобы знание было настоящим.
Попробуй сам
Возьмите любое знакомое приложение — маркетплейс, мессенджер, сервис доставки еды — и на листе бумаги выпишите 4-6 главных сущностей, данные о которых оно хранит. Для сервиса доставки это может быть: клиент, ресторан, блюдо, заказ, курьер. Затем стрелками соедините те, что связаны между собой («клиент делает заказ», «заказ содержит блюда»). Не пытайтесь нарисовать таблицы или колонки — пока только сущности и связи. Это и есть начало conceptual-модели, с которой мы детально работаем в модуле 2. Сохраните листок: к концу курса вы посмотрите на него другими глазами.
Как создавался курс
Курс создан при участии Claude (Anthropic) как соавтора: ИИ помогал писать материалы, структурировать темы, генерировать примеры кода и диаграммы. Каждая глава проходила ручную сверку с первоисточниками — спецификациями, документацией, исходным кодом рассматриваемых систем — но гарантировать 100% точность невозможно.
Если вы заметили неточность, опечатку или хотите предложить улучшение — напишите в Telegram-группу курса. Это самый ценный вклад в курс, который вы можете сделать.
Углублённое изучение с Claude
Курс рассчитан на самостоятельное изучение, но любая теория быстрее ложится, если задавать вопросы. Рекомендую держать рядом браузерное расширение Claude (claude.com/download) — оно работает с контентом открытой страницы: выделяете кусок урока и спрашиваете напрямую.
Сценарии, которые особенно хорошо работают для углублённого погружения:
- «Объясни проще» / «дай ещё один пример» — когда формулировка из урока не дошла с первого раза.
- «Покажи, как это устроено на уровне кода / железа» — когда хочется спуститься на слой ниже того, что даёт урок.
- «Как это связано с [другая тема курса]» — когда нужно увязать концепцию с тем, что было раньше.
- «У меня в проекте стек X — как применить?» — когда хочется примерить материал на свой реальный кейс.
Это не замена курсу, а способ ускорить интеграцию материала в вашу картину мира. Если что-то из ответов Claude расходится с уроком — присылайте в Telegram-группу, курс будет уточнён.
Нашли ошибку?
Если заметили неточность, опечатку или хотите предложить улучшение:
Telegram-канал
Подписывайтесь, чтобы узнавать об обновлениях и новых курсах: