EXPLAIN | Магомед Мурадалиев

Слои обработки данных от сырых к аналитическим Прежде чем данные достигнут конечных пользователей, они проходят несколько уровней обработки. Такой многослойный подход значительно повышает стабильность ETL-процессов, позволяя настраивать требования к нормализации данных, прорабатывать подготовку и обновление информации, распределять задачи между уровнями обработки, выявлять ошибки в процессах Полный цикл обработки включает следующие слои: БД → RAW → ODS → DDS → DM→ BI Давай детально разберём каждый этап. 1. Слой RAW/STG — "сырые" данные Это первоначальный уровень хранения, куда попадают данные непосредственно из систем-источников. Его ключевые особенности: - Сохраняет данные в практически неизменном виде, максимально близком к источнику - Служит резервной копией для возможных повторных ETL-процессов - Единственное допустимое преобразование — изменение типов данных для совместимости систем (например, при переходе с Oracle на Postgres) Иногда сам слой стейджинга разделяют на слои. Первый Инкрементальный стейджинг, содержит только последние изменения, например, данные за текущий день или или другой установленный период. Второй Исторический стейджинг (corporate memory) накапливает все данные из источника, полученные за время работы хранилища. Также в стейджинге могут выделяться вспомогательные слои для хранения данных, прошедших или не прошедших контроль качества. Ещё там хранятся вспомогательные объекты, которые нужны для поддержания процессов загрузки и обработки данных: таблицы соответствия натуральных ключей суррогатным, таблицы кодировок.  2. Слой ODS (Operational Data Store) — операционные данные В данном слое данные очищаются от технической информации (метаданные, служебные поля), сохранение детализации близкой к исходной системе, а также приводятся к единой модели данных, унифицированы, очищены и связаны.  После ODS-слоя данные уже пригодны для работы аналитиков, но ещё не интегрированы между разными источниками. 3. Слой DDS (Detail Data Store) — детал

Представь, ты обнаруживаешь баг в данных и потратил полдня на его поиски. Ты ныряешь в витрины, потом в промежуточные слои, но ошибка, словно призрак её нигде нет. В отчаянии ты пишешь ДЕ, а он в ответ: «проблема где-то тут… но это не точно» 💨 Знакомая история? Чтобы такого не случалось, я написал статью про порядок загрузки данных. Да, это не частая история, у меня так было лишь однажды, но я потратил на "раскрутку" бага аж день 😢 ах, да, вот статья: Порядок загрузки объектов почему это важно #DE

Написал про инкрементальную загрузку. Штука частая в работе, поэтому понимание её принципов — must-have для любого ДЕ. Пост про инкрементальную загрузку <- кликай 😕 #DE

Немного про Git Когда начинал разбираться с Git, я сохранял в закладки всё подряд. Со временем выделились те, к которым я возвращался снова и снова, а часть осталась "на всякий случай". Делюсь этим списком — вдруг что пригодится. 📌Ресурсы, которыми я активно пользовался: 1. Learn Git Branching — интерактивный тренажёр, где можно руками пощупать команды и сразу увидеть, что они делают. Это сильно ускоряет понимание. 2. Visualizing Git — классная визуализация: наглядно видно, как команды влияют на структуру коммитов. 3. Плейлист на YouTube — моё «быстрое справочное». Видео по 5–10 минут. Схема простая: словил затык, включил видео, попробовал то что на видео показывают — и сразу выполнил, profit. 📌 То, что осталось в закладках (редко использовал, но может быть полезно) - Hello World — минималистичный проект, хороший для старта. - Основы работы с Git — небольшой gist с базовыми командами. - Курс Git для начинающих — хороший вводный курс, если нужно с нуля. - Как работает Git (GitHub) — материал для тех, кто хочет глубже копнуть под капот. #Helpful

Про SQL-ключи deep dive часть 1 Интернет полон догматичных правил про ключи в реляционных базах. Кажется, что это почти священные войны: использовать естественные (natural) или искусственные (artificial) ключи? Автоинкременты или UUID? Что такое ключи, на самом деле? Пока забудем про первичные ключи — нам нужна общая идея. Ключ — это столбец или набор столбцов, которые в совокупности не повторяются в строках таблицы. Кроме того, эти столбцы должны быть неприводимо уникальны, то есть ни один поднабор столбцов не должен обладать тем же свойством уникальности. Например, представим таблицу для учёта сыгранных карт: CREATE TABLE cards_seen ( suit text, face text ); Если мы ведём учёт одной колоды (никакие карты не дублируются), то сочетание (suit, face) будет уникальным. Мы не хотим хранить одну и ту же масть и один и тот же номинал дважды — это избыточно. Если карта есть в таблице — мы её видели, если нет — не видели. И стоит поручить базе данных обеспечивать это ограничение, добавив: CREATE TABLE cards_seen ( suit text, face text, UNIQUE (suit, face) ); Ни suit, ни face по отдельности не уникальны. Можно увидеть несколько карт одной масти, или с одинаковым номиналом. Раз комбинация (suit, face) уникальна, а отдельные столбцы не уникальны, мы говорим, что сочетание неразложимо, и (suit, face) — это ключ. Если расширить пример и учитывать несколько колод, можно добавить поле, фиксирующее, сколько раз карту встречали: CREATE TABLE cards_seen ( suit text, face text, seen int ); Хотя тройка (suit, face, seen) формально уникальна, это не ключ, потому что подмножество (suit, face) должно быть уникально само по себе — две строки с одинаковой мастью и номиналом, но разным seen, означали бы противоречивые данные. Поэтому (suit, face) остаётся ключом, иных ключей тут нет. Ограничения уникальности В PostgreSQL предпочтительный способ задать ограничение уникальности — объявить его явно (UNIQUE), как показано выше. Использование индексов для обеспечения уник

Поиск естественных ключей Про SQL-ключи часть 2, прошлая часть тут Ключи, о которых мы говорили выше, — это естественные ключи: они являются свойствами моделируемых объектов и имеют самостоятельный смысл, даже если никто специально не создавал их для целей идентификации. Первое правило при поиске естественного ключа — не усложнять. Как советует пользователь StackExchange sqlvogel: Некоторые люди испытывают сложности с выбором «естественных» атрибутов ключа, потому что они придумывают ситуации, где данное поле может быть не уникальным в некоторой популяции. Это упускает суть. Суть ключа — ввести бизнес-правило, согласно которому атрибуты должны и будут быть уникальными для популяции данных в конкретной таблице в конкретный момент времени. Таблица всегда представляет данные в некотором, надеюсь, хорошо понятном контексте («бизнес-домен» или «domain of discourse»). Важно именно намерение/требование обеспечить уникальность в данном домене. Правило «на пальцах»: добавляй ограничение ключа, когда столбец уникален для текущих значений и, вероятно, останется таким в разумных сценариях. Всегда можно снять ограничение, если понадобится. Например, в базе членов небольшого любительского клуба можно объявить уникальность по паре столбцов first_name, last_name. На таком масштабе дубликаты скорее случайны, и при необходимости ограничение можно убрать. Пока реального конфликта нет — такое ограничение имеет смысл. По мере роста базы и расширения предметной области найти естественные ключи становится труднее. Хранимые данные — это упрощённая модель внешней реальности и не всегда содержат отличительные признаки, которые в реальном мире выделяют объекты (например их местоположение во времени). Без какого-то кодового обозначения чем отличаются две банки колы или коробки хлопьев — только их место в пространстве или мелкие отличия упаковки? Именно поэтому стандарты вводят отличительные маркировки: автомобили получают VIN, книги — ISBN, товары — UPC. Можно возразить, что эти номера

Суррогатные ключи Прошлые части: один, два, три Как уже говорилось, важный тип искусственных ключей — суррогатные ключи. Они не предназначены для краткости и удобства обмена, а служат внутренним идентификатором строки. Их используют в SQL и при соединениях, но обычно не ссылаются на них напрямую из приложения. Если знаком с системными столбцами PostgreSQL, можно думать о суррогатах как о некой внутренней детали реализации (аналог ctid), только никогда не меняющейся. Значение суррогата выбирается один раз для строки и затем не изменяется. Суррогаты — отличные цели для внешних ключей; внешние ключи к суррогатам стоит помечать ON UPDATE RESTRICT, чтобы помогать поддерживать их неизменность. С другой стороны, внешние ключи к публично разделяемым ключам следует помечать как ON UPDATE CASCADE, что даёт максимальную гибкость при изменении значений таких ключей. (Каскадное обновление выполняется с тем же уровнем изоляции, что и окружающая транзакция, так что о проблемах конкурентности беспокоиться не нужно — СУБД справится, если выбрать строгий уровень изоляции.) Не «натурализуй» суррогаты. Как только ты показываешь значение суррогатного ключа пользователю или, того хуже, позволяешь ему работать с ним (например через поиск), ты фактически придаёшь этому ключу бизнес-значение. Тогда этот «внутренний» ключ в чьих-то глазах становится естественным. Лучше заставить внешние системы пользоваться другими искусственными ключами, специально созданными для обмена, чтобы можно было менять внешне видимые ключи по мере требований, а для внутреннего JOIN-а и референциальной целостности использовать суррогаты. Автоинкрементный bigint Наиболее распространённый выбор для суррогата — автоинкрементный bigserial (aka IDENTITY). (Кстати, PostgreSQL 10 теперь поддерживает конструкцию IDENTITY, как это делает Oracle.) Однако автор считает, что автоинкрементный int обычно — не лучший выбор для суррогатов. Это не самая популярная точка зрения, поэтому поясню. Недостатки serial-ключей: - На

Проектирование модели Когда ты начинаешь проектировать новую модель данных, кажется, что самое сложное придумать сами таблицы. На самом деле сложность в другом: выбрать подход. Не просто «что построить», а каким путём к этому прийти. Ты уже собрал требования к модели. У тебя есть цель понять, как она должна работать после изменений. Теперь нужен маршрут. И здесь помогают методологии и приёмы. Например, нормализация полезна, когда модель разрослась, дублирует данные и тормозит аналитику. А если данные меняются со временем, в дело входит SCD подход, который сохраняет историю. Всё это твой набор инструментов, но чтобы выбрать правильный, нужно задать один вопрос: какую задачу ты решаешь? Если тебе нужно ускорить аналитику, скорее всего, ты пойдёшь в сторону OLAP. Если важна чистая транзакционная обработка это уже OLTP. Здесь нет универсального ответа. Есть потребность, есть ограничения, есть твоё понимание, куда вести модель. И здесь встаёт классика жанра подходы «звезда» и «снежинка». Это два способа собрать схему с фактами и измерениями. Оба работают с идеей: есть центральные события (факты) и есть описательные сущности (измерения). Но их устройство разное. Писал о подходах тут. Оба подхода можно превращать друг в друга. Есть звезда? Можешь нормализовать измерения и собрать снежинку. Есть снежинка? Упрощай и получай звезду. Они не конкурируют они дополняют друг друга. Когда у тебя уже есть исходная модель, ты разбираешь её на две части: что представляет собой схема сейчас и какой она должна стать в итоге. Например: Условия: — модель похожа на звезду; — данные денормализованы. Цели: — получить те же аналитические результаты, что и раньше; — убрать избыточность; — дать возможность расширять модель: добавлять акции, промопредложения, новые измерения; — сократить разницу во времени выполнения запросов до одного порядка; — гарантировать, что каждая сущность хранит свои атрибуты в рамках одной таблицы. Остальное шум. Всё, что не относится ни к тек

Нашёл недавно интересную статью Thinking Like a Data Engineer и вот главные мысли: 1. Делай ставку на базовые знания: моделирование данных, SQL и распределённые системы. Освоив фундамент, ты начинаешь воспринимать любой новый инструмент как обычную надстройку, а не как магию. 2. Смотри на бизнес как на систему. Таблицы это отражение реального мира: полки, товары, пользователи, события. Покупка событие, а данные модель этого мира. 3. Система, это не просто набор таблиц. Она скорее похожа на живой организм или город: постоянно меняется, развивается, перестраивается. Стоит привыкнуть к этому, ведь проект, это не путь к «идеальной архитектуре», а непрерывное улучшение через гипотезы, тестирование и адаптацию. Поэтому нормально, если пайплайн или модель данных приходится переписывать. 4. Сомнения нормальная часть пути. "А достоин ли я работать в компании N?", "Достаточно ли я хорош?", "Мне просто повезло?" Есть простое правило: если ты уже работаешь в компании N ты достойный кандидат. Без ритуалов и мотивационных речей. Просто факт. Уверенность — это не знание всего, а понимание, что ты можешь расти и учиться дальше. #DE

Нормализуем таблицу Нормальные формы, вопрос, который часто встречается на технических собеседованиях на позиции СА/ДА/ДЕ. В прошлый раз я писал о нормализации: что такое 1НФ, 2НФ и 3НФ и как нормализация работает на простых примерах. Теперь разберём пример немного сложнее. Ссылка на небольшую статью с картинками #DE

Виды моделей данных ч.1 В этом и в следующих постах хочу рассказать про моделирование данных, какими бывают модели данных и чем они различаются. Помните этот пост про то, что всё нужно моделировать, если ты трушный инженер? Так вот решил продолжить писать цикл постов про моделирование. Модель — это упрощённое (схематичное) представление реальности, сохраняющее ключевые свойства первоначального объекта и передающее информацию для дальнейшего анализа. Данные — это представление информации в формализованном виде, пригодном для передачи, интерпретации и обработки. В качестве примера в постах буду использовать кофейню, так как очень люблю этот напиток. Не путать с тем кофе, который в офисе 😉 Прежде дата инженер или системный аналитик начинают проект с изучения предметной области. Это значит понять, какие сущности, процессы и правила существуют в бизнесе заказчика. Предметная область — это знания о конкретной части реального или виртуального мира. ДЕ/СА специалист может изучать предметную область всей системы или только её часть. Всё зависит от задачи бизнеса. Например, для кофейни предметной областью может быть, как вся система, складской учёт ингредиентов, программа лояльности, бронирование столиков и аналитика продаж, так и отдельная часть, функционал онлайн-заказов через мобильное приложение. Предметную область системы или её части описывают через процессы (что происходит) и данные (с чем работают). Процесс «оформить заказ» использует данные: «список напитков», «цены», «данные клиента». Если верхнеуровнево посмотреть, то получается: Описание предметной области = процессы + информация Процесс — это последовательный поток работы или действий. Информация — это знания об объектах, таких как факты, события, предметы или идеи, включая понятия, которые в зависимости от контекста имеют определённое значение. Чтобы упростить представление о предметной области, СА/ДЕ описывают процессы и информацию в виде процессов и моделей данных. Что такое модель данных? Моде

Зачем моделировать данные? ч.2 Любое приложение работает с данными, предположим такую ситуацию: утро, на улице пасмурно, ты не хочешь никуда выходить, но хочешь вкусный раф или капучино с сиропом. Для этого в приложении какого-то сервиса доставки выбираешь напиток, указываешь объём, тип молока, добавляешь сироп, выбираешь свой адрес и нажимаешь «Оплатить». На основе этих данных приложение ищет товар, считает стоимость, добавляет позицию в корзину, которая привязана к сессии клиента и отправляет заказ бариста. Ну и как программа обрабатывает столько данных и не путается? Как вариант: информация организована по чётким правилам, её легко хранить, искать и обновлять. Когда мы начинаем разрабатывать приложение, первая задача — понять, с какими данными оно будет работать и как они устроены. Решает эту задачу моделирование данных. Моделирование данных также позволяет: - Улучшить взаимодействие системного аналитика и дата инженера. Хотя иногда это может быть один человек и взаимодействие не требуется ⌨️ - Уменьшить количество ошибок при разработке ПО и при проектировании баз данных. - Определить, какую информацию будет хранить и обрабатывать создаваемое приложение, чтобы использовать её при проектировании базы данных. - Привести к единому виду документацию компании. Моделируя данные, мы определяем чёткие термины для понятий предметной области. Например, используем слово «клиент», а не «покупатель» или «потребитель». Определившись с терминами, мы можем ориентироваться на них при составлении документов. Так мы избежим ситуации, при которой в спецификации используется «клиент», в руководстве пользователя «покупатель», а в программе и методике испытания системы «потребитель». Виды моделей данных В зависимости от вида модели данных, понятия называют сущностями, классами или объектами. Сущность - это представление понятия предметной области, фокусирующееся на его характеристиках. Если представить «Заказ» как сущность, то мы описываем его свойства: номер, дата, сумма, стат

Уровни абстракции ER-моделей ч.4 Когда только начинаем проект, предметная область словно тёмный лес. Поэтому логично идти от общего к частному: сначала сформировать общую картину, а потом углубляться в детали. Этот процесс разбивают на три этапа. Каждому этапу соответствует свой уровень модели. ER-модели создают в три этапа. Сначала аналитик составляет модель на концептуальном уровне, затем уточняет её на логическом уровне и, наконец, доводит до физического уровня. Каждый следующий уровень добавляет деталей. У каждого уровня своя цель, своя аудитория и своя степень детализации. Концептуальный уровень. Основная цель концептуального уровня сформировать представление о том, как бизнес воспринимает информацию, с которой работает: какие сущности он выделяет, что они из себя представляют, какие названия он им даёт, как эти сущности связаны между собой. Другими словами, цель этого уровня понять суть предметной области, выделить основные сущности и связи. СА/ДЕ составляет ER-модель концептуального уровня вместе с заинтересованными лицами, которые разбираются в предметной области: заказчиками, пользователями, экспертами (специалистами, у которых есть специфические знания, опыт и квалификация), владельцами продукта и бизнес-аналитиками. Концептуальная ER-модель не зависит от конкретной системы управления базами данных (СУБД). Её можно применять для создания словаря, описывающего бизнес-информацию и связи внутри этой информации. Концептуальная ER-модель, это представление самого высокого уровня абстракции. Она содержит наименьшее количество деталей и отражает общий объём модели, то есть количество сущностей и связей в ней. Рассмотрим на примере. Допустим, ты хочешь научиться готовить идеальный раф. Этот кофе придумали в Москве, кстати, и у него есть строгий рецепт: эспрессо, ванильный сахар и сливки вместо обычного молока. Всё это взбивается паром до нежной, бархатистой пены. Предметная область в этом примере приготовление рафа. Понятия, которые мы включим в концептуа

Какие навыки чаще всего требуют от Data Engineers в 2026 Нашёл небольшую статью о том, какие навыки сейчас требуют от Data Engineers. Коротко разберу основные тезисы и добавлю комментарии про рынок РФ. База, без которой ты не дата-инженер. SQL и Python остаются фундаментом профессии. У нас такая же ситуация. SQL основной инструмент аналитики и дата-инженерии, Python используют для ETL, обработки данных. Большинство вакансий требуют опыт работы с облаками (AWS, GCP, Azure). В ЕС и США, да. В РФ чаще используют on-premise решения или локальные облака. Поэтому важнее понимание архитектуры инфраструктуры, а не конкретного провайдера. Почти везде встречаются data warehouses: Snowflake, BigQuery, Redshift. В РФ чаще используются альтернативы: ClickHouse, Greenplum, PostgreSQL-based DWH, иногда Vertica. Snowflake и BigQuery встречаются редко из-за ограничений. Инструменты оркестрации вроде Airflow стали стандартом. В РФ это тоже фактически стандарт. Airflow самый распространённый orchestration-инструмент для пайплайнов. Растёт спрос на streaming-стек: Kafka, Spark, Flink. Kafka активно используется и в РФ, особенно в крупных компаниях. Spark тоже довольно распространён. Flink встречается реже. Всё чаще ждут понимания data modeling и архитектуры данных. Это один из главных трендов и в РФ. Инженеров, которые умеют проектировать хранилища и модели данных, ценят заметно выше, чем тех, кто только пишет пайплайны. Основная мысль статьи: компании ищут не просто инженеров пайплайнов, а людей, которые понимают как проектировать data systems. По сути речь про T-shape специалиста: глубокая экспертиза в data engineering + понимание архитектуры данных и инфраструктуры. Таких инженеров менеджеры любят больше всего. 🤓 Ссылка на источник: кликай сюда #DE

Уровни абстракции ER-моделей ч.5 Логическая модель данных - это описание важных для бизнеса понятий, их атрибутов и связей между ними. На этом уровне СА/ДЕ уточняет ER-модель концептуального уровня обогащает сущности атрибутами (характеристиками). Выделив характеристики, можно обнаружить, что количество сущностей в ER-модели нужно изменить. Целевая аудитория логического уровня включает заинтересованных лиц они помогают с уточнением атрибутов сущности. Аудитория логического уровня также включает архитекторов баз данных и бизнес-аналитиков, которые могут помочь с разработкой ER-модели или предложить, как её доработать. Цель, уточнить концептуальную модель: добавить характеристики (атрибуты) каждой сущности и определить первичные ключи. Логическая модель тоже не зависит от конкретной СУБД. Но она уже содержит больше деталей, чем концептуальная. Вернёмся к нашему примеру с рафом. Рассмотрим понятие эспрессо. Для идеального рафа важны свежие зёрна средней обжарки. Значит, атрибутами сущности эспрессо могут быть: дата обжарки, сорт зерна, степень помола. Набор атрибутов и их качественный состав отличают одно понятие от другого. Качественный состав, это то, как именно мы описываем характеристику. Например, степень помола можно измерять в микронах, а можно словами грубый/средний/мелкий. Каждый атрибут должен быть задействован хотя бы в одном бизнес-процессе, например, при списании ингредиентов со склада. Если рассматривать понятие сливки, мы заметим, что их атрибуты отличаются: важны жирность и срок годности, а не сорт и помол. Значит, это разные сущности. А вот сущности сливки и ванильный сахар уже ближе: у обоих есть срок годности, производитель и вес упаковки. В этом случае мы можем обобщить понятия: и то и другое ингредиент. После выделения характеристик количество сущностей меняется: сливки и сахар превращаются в одну сущность ингредиент. Мы уже знаем, что для приготовления одного рафа требуется несколько ингредиентов. Предположим, что каждый ингредиент можн

Как я готовлюсь к 1-to-1 В дата инженерии есть ловушка: кажется, что если ты построил безупречный отказоустойчивый пайплайн, то он сам за себя все расскажет. Но корпоративная реальность, это не только код, это еще и управление ожиданиями. Я долго пытался приучить себя фиксировать каждый чих, но когда ты осваиваешь JQL и начинаешь жонглировать тикетами в Jira, то ты всё реже записываешь свои достижения, ведь всё жеж написано в тикете. 😂 Несмотря на это, молчание всё же плохая стратегия. Если ты сам не подсветишь свои результаты, велика вероятность, что для системы ты останешься «просто еще одним инженером». Повышение или высокая оценка не случаются сами по себе, это результат прозрачного диалога. Для меня 1-to-1 это не отчет о проделанной работе, а синхронизация. Мы сверяем взаимные ожидания, не превратилась ли наша совместная импровизация в какофонию. Неделю назад я прошёл такую встречу. Итого всё хорошо и повышенная оценка имеется. Моя подготовка ко встречи - Я иду по задачам квартала, но ищу не сухие факты, а контекст: комментарии, сложные обсуждения, моменты, где пришлось выйти за рамки ТЗ. Ценность всегда лежит там, где ты сделал чуть больше, чем просил скрипт. - Иду к заказчикам и прямо спрашиваю: "Та витрина, что мы выкатили, она принесла ценность для бизнеса или просто красиво висит в продакшене / дашборде". - Собираю фидбек от коллег. Как они оценивают коммуникацию за квартал и чего ждут от взаимодействия в будущем. - Готовлю ответы на вопросы: "Что нравится / не нравится?", "Что хотел бы улучшить?", "Как сам оцениваешь квартал?" - Готовлю список вопросов исходя из квартала и контексты. Я не жду, что мне навяжут задачи и поэтому задаю примерно такие вопросы: - "Какие ожидания на будущий квартал?" - "Какие задачи точно НЕ надо делать, даже если кажутся важными, на чем сфокусироваться?" - "Есть ли что-то, что я делаю, но это не даёт ценности и можно убрать?" - "Что, по твоему мнению, я мог бы улучшить: как инженер?" Встреч

Уровни абстракции ER-моделей ч.6 Физическая ER-модель - это описание того, как логическая ER-модель будет реализована с помощью определённой технологии. Если концептуальный и логический уровни летали в облаках бизнеса и абстракций, то здесь мы приземляемся на суровую техническую почву. Физическая модель всегда привязана к конкретной СУБД. Например, мы составляем разные физические модели для PostgreSQL, Oracle, MS SQL и других систем, так как у них отличаются синтаксис и поддерживаемые типы данных. То есть одной логической ER-модели могут соответствовать несколько совершенно разных физических. Основная аудитория этого уровня, это DE, архитекторы баз данных и разработчики. Цель превратить логические схемы в готовые скрипты для создания реальной базы данных. Для построения физической ER-модели сущности из прошлых этапов должны превратиться в таблицы. Для каждой таблицы нужно определить имя на английском языке без пробелов, чаще всего в snake_case. Атрибуты сущностей становятся полями (столбцами) этих таблиц. Для каждого поля нужно чётко определить: - Имя на английском языке. - Тип данных и размерность, например, целое число, строка на 255 символов, дата. - Допустимость пустых значений NULL или NOT NULL. - Значение по умолчанию, если требуется. - Правила валидации значений (ограничения, чтобы в базу не попал мусор). Связи между таблицами теперь отражаются не просто линиями на схеме, а через внешние ключи (Foreign Key). Вернёмся к нашему идеальному рафу. В логической модели мы выделили сущности «раф» (родительская) и «ингредиент» (дочерняя). В физической модели сущности «раф» будет соответствовать таблица raf_drink (или просто drink). В ней мы будем хранить строки, соответствующие каждому приготовленному напитку. Полями таблицы raf_drink могут быть: - id (уникальный номер напитка, первичный ключ, тип данных целое число INT). - created_at (время приготовления, тип данных дата и время TIMESTAMP). - volume_ml (объём в миллилитрах, тип данных целое число INT)

Расскажи про изменяемые и не изменяемые типы данных Это один из самых частых вопросов на скринингах в любую компанию. Интуитивно эту концепцию понимают почти все, но на лайвкодинге или глубоких деталях многие сыпятся. Начнем с главного правила: в Python переменные это просто ярлыки (ссылки), которые указывают на объекты в памяти. Смотрим в терминал. Создаём переменную и проверяем её ID: >>> x = 3.14 >>> print(id(x)) 4340150704 Теперь прибавим единицу к той же переменной и снова проверим адрес: >>> x += 1.0 >>> print(id(x)) 4342897808 Видите? Изменился не сам объект, изменилась ссылка. Сначала переменная x (которая в Python является лишь ярлыком или указателем) указывала на объект 3.14 в памяти. Строка x += 1.0 заставила этот ярлык указывать на совершенно другой, заново созданный объект 4.14. Старый объект 3.14 остался в памяти без изменений. Похожая история со строками. При изменении символа в строке вызывается ошибка: >>> word = 'Лето' >>> word[0] = 'П' Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'str' object does not support item assignment Каждый объект в Python при создании получает три неизменные характеристики: тип, значение и ID (адрес в памяти). В нашем примере str это тип, 'Лето' - это значение, а id(word) адрес. Глобально все типы данных делятся на два лагеря: Неизменяемые. После создания состояние объекта нельзя изменить. Любая попытка изменить его (например, конкатенация строк или математическая операция) не меняет объект «на месте», а заставляет Python создать совершенно новый объект по новому адресу в памяти и перенаправить на него ссылку. Изменяемые. Обладает внутренним состоянием, которое можно модифицировать «на месте» (in-place). При этом адрес объекта в памяти id() остаётся прежним Сами типы данных: - Immutable (неизменяемые): int, float, bool, str, tuple, frozenset. - Mutable (изменяемые): list, dict, set, bytearray. Демонстрация на списках (list) >>> nums = [1, 2, 3] >>> other_nums = nums З