💡 Реляционная модель, это не просто таблицы. Это договор между людьми Когда я только начал работать аналитиком, я думал, что база данных это просто место, где хранятся цифры. Потом я потратил два дня на отчёт, который оказался неверным, потому что не знал: поле status в таблице orders может быть NULL, если заказ ещё не обработан системой. Но документации по этому поводу не было и узнал я об этом потом только со слов коллег. С тех пор я понял - реляционная модель это не про данные. Это про доверие. ❗️ Таблицы — это интерфейс В IT мы привыкли к API: чёткие контракты, типы, документация. ➖Реляционная схема — API для данных. ➖Имена таблиц и колонок — часть договора. ➖Типы данных (DATE, BOOLEAN, NUMERIC(10,2)) — гарантии формата. ➖Ограничения (NOT NULL, FOREIGN KEY, CHECK) — правила игры. Например, если в колонке user_id есть NULL, значит, система допускает анонимные действия. Это бизнес-решение, зафиксированное в схеме (надеюсь). ❗️ Кто участвует в этом договоре? ➖ Разработчики — создают и меняют схему. ➖ Аналитики — читают данные, строят гипотезы, пишут требования. ➖ ML\BI-инженеры — строят витрины и дашборды, обучают модели. ➖ Менеджеры продукта — принимают решения на основе этих данных. Если договор нарушен (например, внезапно появляются дубли без первичного ключа), все теряют доверие к данным. ❗️ Что ломает договор? ➖ Колонки вроде data_json со "всем подряд" - нет контракта, только хаос. ➖ Отсутствие документации: "Что значит status = 5?" ➖ Изменение типа колонки без уведомления команд юзающих данные (например, INT стал TEXT). ➖ Использование общих таблиц вроде temp_analytics_2025 как совокупного источника истины. Это как менять API без версионирования - клиенты падают, но никто не знает почему. ❗️ Договор требует ответственности от всех сторон ➖ Разработчик не должен "временно" писать мусор в notes-поле вместо создания новой сущности. ➖ Аналитик не должен строить отчёт на основе недокументированного поля, даже если "оно работает" ➖ Команда должна иметь владельца данных - человека, который следит за целостностью контракта. ❗️ Как укреплять договор? ➖ Именуйте осознанно: order_created_at, а не date1. ➖ Используйте ограничения: если поле не может быть пустым - NOT NULL. ➖ Документируйте семантику: через комментарии в БД (COMMENT ON COLUMN ...) или Data Dictionary. Если вы бизнес/системный аналитик, подробно описывайте поля и логику, например в конфлюенс. ➖ Согласовывайте изменения: даже переименование колонки событие для всей команды. ➖ Уточняйте и уведомляйте: лучше лишний раз переспросить перед внесением изменений в данные и после уведомить заинтересованных, чем потом отвечать на кучу вопросов "а почему теперь так?" ❗️ Данные, это социальный артефакт Реляционная модель, не техническая деталь. Это язык согласия между людьми, которые хотят говорить об одном и том же, не путаясь. Хорошая схема это когда новый аналитик через неделю понимает бизнес, просто читая документацию по модели данных БД. Посмотрите на любую таблицу в вашей БД. Спросите себя: ➖ Мог бы новичок понять, что означают эти поля? ➖ Есть ли здесь секретные знания, которые живут только в головах коллег? Если да - вы знаете, с чего начать укреплять договор. И напоследок анекдот: Новичок приходит в команду и спрашивает: — Где почитать про модель данных БД? — Вся документация в голове у Артёма — отвечает тимлид. — А как с ним связаться? — А… он уволился полгода назад. 📱 Подписаться на канал 💻 Курс автора по SQL DDL 🌎 Мой ИТ-стартап