💡 Реляционная модель, это не просто таблицы. Это договор между людьми
Когда я только начал работать аналитиком, я думал, что база данных это просто место, где хранятся цифры. Потом я потратил два дня на отчёт, который оказался неверным, потому что не знал: поле 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
🌎 Мой ИТ-стартап
Когда я только начал работать аналитиком, я думал, что база данных это просто место, где хранятся цифры. Потом я потратил два дня на отчёт, который оказался неверным, потому что не знал: поле 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
🌎 Мой ИТ-стартап