Я слышу и вижу сплошное:
🔹 В вакансиях аналитиков нужны знания API!
🔹 В вакансиях аналитиков нужны знания по интеграциям и архитектуре систем!
🔹 Аналитики должны понимать принципы микросервисной архитектуры!
Согласна. Важно. Нужно.

Но при этом всем базы данных кажутся чем-то второстепенным. Однако понимание БД — это ключевой навык каждого системного аналитика. И даже если в вакансии этого требования нет, то это умение все равно должно быть. Почему? Давайте разберемся.

БД — это фундамент системы, который влияет на реализацию всех требований.

✨ Функциональные требования
Пример про Интернет-магазин. Когда вы выбираете товар, смотрите его описание, фото, отзывы других покупателей – все эти данные хранятся в БД.
БД – это как склад магазина. Если на «складе» нет нужной информации или она представлена, неверно, покупка не состоится.

✨ Нефункциональные требования
После добавления товара в корзину сайт долго грузится или вылетает. Возможно, проблема в том, как БД обрабатывает большой поток данных.
Таким образом, струтктура БД влияет на скорость, стабильность и масштабируемость функциональности Интернет-магазина.

🔗 Интеграции и REST
Мы все больше используем API для интеграции разных систем. Но без данных, API – просто мост в пустоту. То, что вы видите в посте выше про маппинг данных, яркий пример того, что API — проводник в данные системы.
API — программный интерфейс, который позволяет избегать прямых SQL-запросов к БД с целью усиления безопасности системы, и обращается к ее данным.
Сервис бронирования отелей. Когда вы ищете свободный номер на выбранные даты, ваш запрос через API направляется к БД. Именно БД «расскажет» информацию, какие номера доступны.

Продолжение 👇

База данных – это не просто место хранения информации. Это основа, на которой строится вся система. Глубокое понимание БД поможет нам создавать более точные требования к системам не упускать из вида особенности проектирования, делать системы масштабируемыми, надежными, быстрыми и эффективными.

Держите руку на пульсе и...! 🔍 Welcome to the new project!

В программе:
🌟 Определение и назначение БД.
🌟 Концептуальный, логический и физический уровень на практике. Работа с требованиями.
🌟 SQL-запросы.
🌟 Индексы, требования к обратной совместимости, связь с API и нефункциональными требованиями.

Я готова проектировать. Готовы принимать участие? ❤️

🌟Самая важная теория по БД для старта работы на проекте🌟
мини-гайд для аналитиков

Погрузимся в технические детали БД на примере системы для онлайн-зоомагазина PetCo.

1️⃣ База данных (БД):
Структурированный набор данных, хранящийся в электронном виде на сервере.
Основные типы: реляционные, NoSQL.
Пример: БД нашего зоомагазина PetCo содержит информацию о товарах, заказах, клиентах и поставщиках.

2️⃣ Сущности в БД:
Это объекты реального мира с определенным набором свойств.
Технически: таблицы с определенным набором атрибутов.
Пример: В зоомагазине у нас есть таблица Животные с атрибутами ID, Вид, Цена, Поставщик.

3️⃣ Реляционная БД:
БД, где данные организованы в виде таблиц со связями.
Сравнивайте со страницами в EXCEL-документе. Каждая страница - отдельная таблица в БД, которая иногда может ссылаться на соседнюю страницу.
От английского relations - связи, отношения.
Пример: В таблице Заказы есть колонка ID_животного, которая связывается с ID в таблице Животные, указывая, какое животное было куплено.

4️⃣ Этап проектирования БД:
Это момент определения структуры данных и связей в системе. Обычно выполняется после того, как завершена работа с описанием бизнес-процессов. Помогает в разработке функциональных требований.
Оценка разработки системы может быть основана на количестве сущностей в системе и количестве операций над ними.
Пример: Прежде чем добавить в систему раздел с товарами для животных, мы спроектируем новую таблицу Товары и определим, как она будет связана с другими таблицами, какая функциональность будет доступна для товаров разным ролям пользователей (CRUD-модель).

⬇️⬇️⬇️

5️⃣ Уровни проектирования БД:
✔️ Концептуальный: Определение сущностей БД и их отношений.
Пример: В PetCo нам нужны таблицы для животных, покупателей и заказов.
✔️ Логический: Определение таблиц, атрибутов и связей.
Пример: Решаем, какие данные будем хранить о каждом животном (возраст, порода, цена), какие таблицы будут созданы для описания каждой сущности.
✔️ Физический: Определение способа хранения данных и оптимизации. Определение требований к типам данных, обязательности, уникальности, значениям по умолчанию. На этом этапе мы точно знаем с чем работаем: SQLite, PostgreSQL, mongoDB и т.д.
Пример: Выбираем тип индексации для быстрого поиска животных по породе.
Или определяем, что ФИО пользователя это три отдельных поля типа данных varchar (для PostgreSQL) до 128 символов.

6️⃣ ER-диаграмма (Entity-Relationship):
Графическое представление сущностей БД и связей. Нотация моделирования баз данных.

7️⃣ SQL-запросы:
Специальный язык запросов для управления данными.
Пример:
SELECT Имя FROM Животные WHERE Вид = 'Кошка' AND Цена < 1000;
- запрос вернет имена всех кошек, которые стоят меньше 1000. Переводите ключевые слова с английского 😉

8️⃣ Система управления базами данных (СУБД):
Программный комплекс, позволяющий создавать, обрабатывать и управлять БД.
Пример: PostgreSQL, Oracle или MySQL – это СУБД, с помощью которых можно управлять данными в нашем зоомагазине.
Работать будем с PostgreSQL.

9️⃣ Отличие БД от СУБД:
БД – это непосредственно сами данные и их структура, в то время как СУБД – инструменты и методы для работы с этими данными.
Пример: Если сравнивать с книгой, то БД – это текст книги, а СУБД – это издательство и набор инструментов для публикации и распространения этой книги.


Для успешной работы на проекте Зоомагазина важно глубокое понимание базы данных: от подходов к формированию структуры до SQL-запросов. Это меняет понимание систем и подход к работе с требованиями, когда вы осознаете, что "под капотом", на сервере.

Наша цель на проекте PetCo освоить навык проектирования БД с нуля до SQL-запросов и добавить вам еще больше практического опыта в копилку 🙌

В процессе разработки выясняется, что в требованиях опять что-то не учли. Что может быть хуже? 😱

Может, коллеги! Когда через пол года вам же приходится возвращаться к задаче и вы понимаете, что требования к развитию системы по словам разработчиков нереализуемы.

Меня, как начинающего системного аналитика, это выводило из себя. Как так?! Элементарная же задача! А потом мне показывают БД. И тут я всё понимаю. Да, действительно, пришло время делать выбор: дорого переделывать или "костыли" подойдут.

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


Написала для вас статью:

📚Проектирование БД и почему важен SQL для системного аналитика: гайд по улучшению качества требований

🌟 Как в разработке систем возникают ситуации "костыли" или "переделываем", и почему обычно это связано с непродуманной структурой БД.
🌟 Как проектирование БД на ранних стадиях работы с проектом влияет на качество требований.
🌟 Дам пошаговый план проектирования БД.
🌟 SQL-запросы: почему нужно уметь читать.

В конце статьи рекомендации: что почитать и посмотреть 🔗

Сколько времени нужно учиться системному аналитику, чтобы хорошо зарабатывать и чувствовать себя уверенно в больших проектах? Согласитесь, вопрос звучит как испытание 🤔 И, честно говоря, нет универсального ответа на него.

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

В мире, где изменения происходят мгновенно, постоянное развитие не просто желание, но и необходимость. Сила духа и уверенность в себе дают нам энергию двигаться вперёд, преодолевать препятствия и достигать новых вершин в личной и профессиональной жизни.


👥 Личное развитие:
Все мы сталкиваемся с ситуациями, требующими проявления нашей уверенности, будь то высказывание своего мнения или принятие важного решения. Эти моменты становятся тестом для нашего духа.

🛠 Профессиональное развитие:
В каждой профессии важно сочетание Hard skills 🏋‍♀️ и Soft skills 👥. Для системного аналитика, например, важны навыки проектирования БД. Этот "твёрдый" навык помогает понимать требования к данным, структурировать их и задавать правильные вопросы заказчикам.

🌍 Информация и ее анализ:
В эпоху данных важность правильной структуризации и понимания информации, обработки данных становится критически важной.


Каждый новый навык или опыт, который вы приобретаете, делает вас сильнее и более конкурентоспособным. Не бойтесь новых вызовов и идите вперёд к новым вершинам! 🌟

Привет, коллеги!

Мы с вами продолжаем работать над проектом PetCo, с которым уже работали в рамках интеграций.

🐈🐕 PetCo - это веб-сайт и мобильные приложения для сети зоомагазинов, интегрированные с собственным Backend-приложением PetStore и платежной системой Raif Pay.

Моя первая задача - внимательно прочитать готовые требования или описания процессов и выделить из них сущности (ж) и свойства (к).
К анализу беру тексты требований из сообщения 🔗Про проект.

Читайте внимательно. Обращайте внимание на разметку текста.


-----
Цель проекта:
Создать интегрированное решение, объединяющее 🔓 веб-сайт, мобильные приложения и административную панель 🔶сети зоомагазинов PetCo с собственным Backend-приложением и платежной системой Raif Pay, с возможностью онлайн-оплаты для 🔹клиентов зоомагазина PetCo.


Основные требования:
🟢 Функциональность веб-сайта и мобильных приложений:
- Возможность просмотра ♦️ассортимента, выбора животных или товаров, и оформления 💠заказа.
- Синхронизация 🧺корзины и 💠истории заказов между сайтом и приложениями.

🟢 Административная панель (админка):
- Интерфейс для учета и управления ассортиментом животных, товаров.
- Отслеживание и обработка 💠заказов.
- 📃Аналитика продаж, популярности определенных животных, товаров и другие отчеты.

🟢 Интеграция с Backend-приложением:
- Синхронизация данных о товарах, ценах и наличии животных и товаров между всеми платформами для клиентов магазина и backend-приложением.
- Автоматизированный обмен данными о заказах и статусах заказов.
- Возможность управления ♦️каталогом (‼️) через административную панель.

🟢 Интеграция с платежной системой Raif Pay:
- Обеспечение безопасности 💵платежных данных клиентов.
- Проведение 💵 платежей за заказы в Интернет-зоомагазине.
- Автоматическое получение обновлений о статусах оплаты из платежной системы.

-----

Этот этап "вычитки требований". Вы уже видите первичные сущности и свойства, которые удалось определить из короткого описания проекта.


Структурированный результат и вопросы заказчику в продолжении 👇

Структурированный результат по сущностям и свойствам:

🔓 Роли и доступы
✔️ Тип приложения: веб-сайт, мобильные приложения и административную панель
✔️ Роль: админ, клиент, продавец, остальное уточнять у заказчика

🔶 Магазин
✔️ Адрес: т.к. сеть, то магазинов много, либо складов. Уточнить, есть ли склады.

🔹 Клиент

🧺 Корзина для заказа

♦️Ассортимент = каталог (‼️сделать единую терминологию)
✔️ Тип: животные, товары для животных.
✔️ Цена (в какой валюте? Если руб, то как храним: руб.коп или просто копейки?)
✔️ Наличие
✔️ Данные о товарах: уточнить у заказчика что подразумевает под "данные"

💠Заказ = история заказов
✔️ Статус: для отслеживания.
✔️ Дата и время: для истории.

📃 Отчет
✔️ Тип: продажи, популярность животных / товаров, другие (уточнять!)

💵 Платеж
✔️ Платежные данные клиента
✔️ Статус: из платежной системы RaifPay


----------


Исходя из этого структурированного представления данных я понимаю, что вопросов заказчику очень много.

🧠 С ходу по 1-2 вопроса минимум к каждой сущности:
Обратите внимание, что я, как системный аналитик работаю на двух фронтах. Максимально избегаю технических формулировок для заказчика.

Роли и доступы
❓Какие сотрудники должны иметь доступ к админке?
❓Правильно понимаю, что клиентов надо регистрировать в системе, чтобы они могли видеть историю покупок?

Магазин
❓Что кроме адреса необходимо хранить о магазине в системе?
❓Какие данные в вашей кассовой системе petStore есть о магазинах сети?

Клиент
❓Какие данные храним о клиенте?
❓Регистрируем с подтверждением по СМС или по почте?

Корзина для заказа
❓Есть ли ограничение на количество товаров или животных в одном заказе?

Ассортимент
❓Какие параметры надо отображать клиентам интернет-зоомагазина для каждого типа?
❓Есть ли типы ассортимента кроме животных и товаров? Возможно услуги?

Заказ = история заказов
❓Как номеруем заказы Интернет-зоомагазина и синхронизируем с вашим кассовой системой petStore?

Отчет
❓Очень много вопросов 😂

Платеж
❓ Какие данные о платежах из платежной системы нам важно хранить?
❓Будем ли поддерживать возврат (статус "возвращен") для заказов? Это нужно, чтобы также проанализировать данные о платежах к сохранению.


Коллеги, предлагаю и вам попрактиковаться в комментариях. Какие вопросы вы видете по этим требованиям и списку сущностей 👇

Есть три уровня моделей БД:
1. Концептуальный
2. Логический
3. Физический

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

Не все уровни обязательны. Каждый из них помогает в работе системному аналитику по-своему:
+ собрать полные требования,
+ найти неочевидные вопросы для заказчика,
+ спроектировать масштабируемую систему,
+ сократить расходы на инфраструктуру,
+ повысить скорость обработки запроов пользователей...

Разбирать на практике будем все уровни 🙌

Концептуальная модель БД 🎓 (1 из 3-х уровней проектирования БД)

Нужна, чтобы наглядно показать все сущности в будущей системе и связи мужду ними.

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

Практическое применение концептуальной модели базы данных может быть связано с созданием новой системы или полной переделкой существующей (например, когда от монолитной архитектуры переходят к сервисной или микросервисной).

Что будет в нашей концептуальной модели?

Список сущностей:
▫️Роли и доступы
▫️Магазин (не показала на схеме, так что маленькое задание для вас к логическому уровню остается)
▫️ Клиент
▫️ Корзина для заказа
▫️Ассортимент
▫️Заказ
▫️Отчет
▫️Платеж

Связи (на картинке пока без кратностей, будем ставить кратности сразу на логическом уровне):
🔵 Один клиент может сделать несколько заказов. Но один заказ принадлежит только одному клиенту.(связь "один-ко-многим")
🔵 Один администратор может сделать много отчетов. Но один отчет создается одним администратором. (связь "один-ко-многим")
🔵 В корзине по заказу может быть много товаров. Один товар может быть в нескольких разных корзинах по заказу, у разных пользователей. (связь "многие-ко-многим")

На концептуальном уровне мы пока говорим только про сущности, свойств пока нет. На этом уровне я думаю о том, какие данные глобально нужно хранить. Извлекаю сущности из требований и кладу в картинку.

Я очень лояльно отнеслась к концептуальному уровню. На прикрепленной к посту картинке даже не показала кратности связей ("один-ко-многим" и другие), хотя они должны быть. И пока подробно вам про них не рассказала.

Если быть честной, то я всегда пропускаю концептуальный уровень и сразу строю модель БД на логическом уровне. Но без понимания, как строить концептуальную модель, я бы не смогла это сделать.

Практическое применение концептуальной модели базы данных может быть связано с созданием новой системы или реорганизацией существующей 🚀

Если необходимо создать новую систему, то на этапе проектирования системные аналитики создают концептуальную модель базы данных, чтобы описать все объекты и связи между ними. Кроме того, на этапе анализа требований она может использоваться для определения функциональности системы и ее возможностей.

Если речь идет о доработке существующей системы, то концептуальная модель базы данных может использоваться для определения проблем, которые могут возникнуть при внесении изменений в систему. Например, если в системе существует связь между двумя объектами, то изменение одного объекта может повлиять на другой.


Системные аналитики должны понимать, как изменения в функциональности меняют БД и влияют на всю систему. Как их можно сделать их наиболее безболезненно и ничего не упустить из виду.

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

В прикрепленном видео разбор - как я построить на основе требований концептуальную модель БД.

P.S. А теперь представьте как много всего можно найти и проверить, когда читаешь ТЗ или описания бизнес-процессов 😍

У вас бывает такое, когда хочется всё и сразу? 😄

🏅 Прочитал книгу за пару ночей — всё понял и внедрил на практике.
🏅 Прошёл обучение — получил повышение.
🏅 Выложил резюме, а на утро увидел десятки откликов от работодателей.

Да, так тоже бывает, но не у всех и не всегда.

Раньше я очень переживала, что долго иду к своим целям.
Завышенные ожидания мешали мне видеть мои регулярные шаги.
Хотелось, чтобы если провожу вебинар, то чтобы сразу тысячи регистраций и сотни зрителей, начала читать книгу и за час освоила все 500 страниц 😅

Что я от этого получала? Одни разочарования. И демотивацию, потому что цель большая, а результат, хоть и есть, но он очень маленький.

Только с годами стало понятно, что каждый шаг, даже самый маленький, это успех и это путь к большой цели. Я стала оценивать каждый успех, каждый маленький прогресс. Делить большое на микро-цели. Слона нельзя проглотить целиком (очень жаль!!!).

А ещё поняла, что важно не только достигать, но и наслаждаться процессом достижения целей.
Книга, которую прочитала, урок, который я извлекла из своих ошибок, так или иначе, помогали мне или помогут в ближайшем будущем. Это мой опыт.

Иногда результаты приходят сразу, а иногда приходится ждать.
Главное — понимать, что и зачем делаешь.
ДЕЛАТЬ — ключевое к развитию👌

Когда читаешь новую книгу, важно воспринимать, что не обязательно знания пригодятся сейчас, возможно, они окажутся классной инвестицией в будущем.
Очередная прочитанная статья, обучение, разговор с коллегой или начальником может принести нам что-то новое и полезное, даже если мы не заметим этого в моменте.

Поэтому никогда не стоит отказываться от нового.
Продолжайте учиться, даже если результаты не приходят сразу🙌

Сегодня открываем предзапись на практическую программу
📚 Проектированию БД и основы SQL.

Более 40+ часов теории и 6 онлайн-встреч на которых работаем с проектом по проектированию БД (20+ сущностей, которые предстоит положить в модель, а затем часть из них самостоятельно создать в СУБД).

Результат:
🌟 ER-модели БД в draw.io.
🌟 Справочник команд ChatGPT.
🌟 Постановки задач в Jira
🌟 Проект в SQLite, понимание PostgreSQL.
🌟 Опыт работы с DBeaver для подключение к PostgreSQL, MySQL и не только.

До 22 сентября можно заполнить 🔗эту анкету, чтобы попасть на программу по специальным условиям 🌟

Я начала строить ER-диаграмму концептуального уровня базы данных. В видео рассказала, как найти необходимые элементы в прекрасном бесплатном инструменте draw.io. Сейчас хочу немного остановиться с проектированием.

Прежде чем идти дальше, давай поговорим подробнее о том, что такое ER-диаграмма. Словосочетание кажется сложным, о нём спрашивают на собеседованиях. Иногда аналитики путаются и дают неверный ответ. Причина проста: нотаций моделирования с аббревиатурами типа UML, BPMN, ER, C4 и других много 😕

Начинаем строить сильную ассоциацию с ER-диаграммой в вашем сознании, и очень прошу не путать её с диаграммой классов UML ‼️


Вопросы с собеседований на системного аналитика, касающиеся ER-диаграммы:

1. Основы ER-диаграмм
▫️Какую нотацию используют для моделирования баз данных?
▫️Что такое ER-диаграмма и для чего она используется?
▫️Какие основные компоненты ER-диаграммы вы можете выделить?
▫️Что такое сущность и атрибут в контексте ER-диаграммы?
▫️Какие инструменты используют для создания ER-диаграмм?

2. Типы связей
▫️Можете объяснить разницу между “один-к-одному”, “один-ко-многим” и “многие-ко-многим” отношениями?
▫️Приведите примеры каждого из этих типов отношений.
▫️Что такое связующая таблица и в каких случаях она используется?

3. Атрибуты и ключи
▫️Что такое первичный ключ и какова его роль в ER-диаграмме?
▫️Что такое внешний ключ и какова его роль?
▫️Какие атрибуты могут быть производными, и как их представить на ER-диаграмме?


Хотите с ходу отвечать и рассказывать с конкретными примерами? Последовательно читайте сообщения в канале 😉

Разберем всё по порядку. Я буду отвечать на вопросы и после передачи очередной порции теории давать сразу практику с нашим проектом:

1. Даю основы ER-диаграмм и рассказываю про то, что уже получили в рамках создания концептуальной модели.

2. Рассказываю про все типы связей на ER-диаграмме с примерами.
2.1. Рассказываю про команды ChatGPT для анализа требований и выделения сущностей и свойств.
2.2. Строю логическую модель БД: доопределяю сущности, добавляю все свойства, указываю кратности связей.

3. Разбираемся с атрибутами и ключами.
3.1. Исследуем логическую модель на необходимость дополнения сущностей.
3.2. Дополняем логическую модель первичными и внешними ключами.

4. Рассказываю про СУБД, типы данных и переход к физической модели.


P.S. А еще есть продвинутые вопросы с собеседований:
▫️Что такое нормализация данных и какова ее роль в проектировании баз данных?
▫️Могут ли две сущности иметь несколько отношений между собой? Приведите пример.
▫️Как вы бы моделировали иерархические или рекурсивные отношения в ER-диаграмме?
пример.
▫️Предположим, что при проектировании системы возник конфликт между необходимостью нормализации и производительностью. Как бы вы решали такой вопрос? ( 😄 совсем не смешно для аналитиков, кто не в курсе терминов “нормализация” и какие примеры проблем с производительностью могут быть).
▫️В чем различие между ER-диаграммой и UML диаграммой классов?
▫️Какие элементы можно встретить на ER-диаграмме, которых не будет на UML диаграмме классов, и наоборот?

📌 Что такое ER-диаграмма?

Всему есть свое место и время. Если бы вы хотели построить дом, первым делом вам потребовались бы чертежи, правда? Также и в мире IT: прежде чем "строить" систему, нам нужна карта или чертеж, который бы показал, как все устроено.

📌ER-диаграмма (Entity-Relationship Diagram) — это графическое представление структуры базы данных.

Она отображает основные элементы (дублирую из предыдущих сообщений про концептуальную модель и анализ требований):


1. Сущности, представленные в базе данных.

▫️Клиент
▫️Корзина для заказа
▫️Ассортимент
▫️Заказ
▫️Отчет


2. Их атрибуты.

▫️Заказ = история заказов
✔️ Статус: для отслеживания.
✔️ Дата и время: для истории.

▫️ Отчет
✔️ Тип: продажи, популярность животных / товаров, другие (уточнять!)

▫️ Платеж
✔️ Платежные данные клиента
✔️ Статус: из платежной системы RaifPay


3. А также связи (отношения) между этими сущностями с указанием кратностей связей.

🔵 Один клиент может сделать несколько заказов. Но один заказ принадлежит только одному клиенту. (связь кратности "один-ко-многим")
🔵 Один администратор может сделать много отчетов. Но один отчет создается одним администратором. (связь кратности "один-ко-многим")


Это главные составляющие, которые важно знать и помнить системным аналитикам. Материал считается базой в проектировании БД.

Как быть на одной волне с разработчиками и понимать их страшные диалоги, если ты системный аналитик? 🧠💡 Изучать технические детали проектирования систем, смотреть “под капот” (детали реализации) ваших “автомобилей” (проектов). Базы данных - один из первых шагов погружения в технические детали.

Что дает понимание технических деталей проекта:

✨ Единый язык
Почти во всех IT-проектах (кроме простых сайтов) есть БД. Представьте, вы обсуждаете с друзьями последний фильм, который все посмотрели, - вам легче находить общие темы.
Точно так же, понимая основы баз данных, вы можете на одном языке общаться с разработчиками - вы тоже на БД посмотрели 😎

✨ Оценка реализуемости требований
Понимание БД позволяет аналитикам оценить, насколько реалистичны и выполнимы требования технически.
Как выбрать лучший ингредиент для вашего рецепта, если вы знаете, как они сочетаются? С БД так же.

✨ Понимание взаимосвязей данных и улучшение требований
Зная, как данные связаны между собой, вы можете лучше понимать их структуру. Это как когда ты пытаешься найти фото на своем телефоне, и вспоминаешь, с кем ты был на ней, и где это было. А потом смотришь в информации. Работаем с данными и связями. Когда знаешь как, куда и на что смотреть - все сразу легче и понятнее))

✨ Повышение производительности
Понимание того, как хранятся и обрабатываются данные, может помочь ускорить многие процессы, связанные с чтением и записью данных, улучшить производительность и уменьшить нагрузку на систему.
Это как когда вы знаете, как закрыть все фоновые приложения на своем телефоне, чтобы сохранить заряд батареи.


Развивайтесь. Больше читайте и разбирайте практику. Улучшайте понимание что “под капотом” систем, коммуникации с разработчиками, понимание обсуждений коллег на митингах. Повышайте качество ваших требований и делайте работу интереснее! 🔍🤝🙌

📝 Для чего нужна ER-диаграмма?

ER-диаграмма помогает разработчикам и аналитикам понять структуру данных и спроектировать БД. Это модель, на которой тестируют сценарии работы системы до начала разработки. Это, по сути, карта нашего "дома".

Представьте, что вы хотите рассказать другу о том, как устроен ваш новый проект. Вместо того чтобы рассказывать длинную историю, вы просто показываете ему этот чертеж (ER-диаграмма) и все становится ясно, он сам может прочитать эту историю быстрее и задать вопросы при необходимости (посмотрите видео, где я эту рассказываю историю проекта по ER-диаграмме в конце). Особенно это важно для разработчиков, архитекторов и других технических участников команды, чтобы они знали, какие данные и как будут храниться в системе.

В проекте для Зоомагазина PetCo, это картинка, где показано, что "Клиент" может сделать "Заказ", а "Заказ" создается на основании "Корзины". Попробуйте сами почитать картинку к посту - это наша ER-модель на концептуальном уровне 🙂 Получается продумать историю?)

📌 Entity-Relationship в переводе с английского Сущности-Отношения.
И сейчас я предлагаю просто выучить перевод этих двух слов. И каждый раз, когда вам будут задавать этот теоретический вопрос, то идите по цепочке:

Entity.
Relationship.
Entity - это сущность.
Relationship - это про отношения (в социальных сетях типа ВК, если они у вас были на английском, чтобы его учить, то наверняка видели в графе “Отношения/Семейное положение” это слово, так было у меня).
Получается, это про сущности и отношения… а! А отношения - связи между ними.

Эврика! ER-диаграмма показывает все сущности (таблицы базы данных, их поля / атрибуты) и как они связаны друг с другом.

Это моя последовательность мыслей, когда я устраивалась на первую работу системным аналитиком и мой будущий руководитель спросил меня определение “Что такое ER-диаграмма?”. Самое страшное для меня было, что нарисовать я могла, а объяснить с ходу теорию - нет. Но он дал подсказку с английским и ровно по этой цепочке мыслей всё получилось 😄 Оффер на стажера был получен.

‼️Начинаем строить сильную ассоциацию с ER-диаграммой в вашем сознании:
это английский и что-то про отношения relationships в vk 😄
Entity - это сущность.
Relationship - это про отношения.
Устрою вам тестирование!

P.S. Еще раз: очень прошу не путать её с диаграммой классов UML.

Теперь готовы отвечать на вопросы собеседований:
▫️Какую нотацию используют для моделирования баз данных?
▫️Что такое ER-диаграмма и для чего она используется?
▫️Какие основные компоненты ER-диаграммы вы можете выделить?

Да? ❤️Есть еще вопросы - в комментарии 🙂

Сущность и атрибут в контексте ER-диаграммы

Сущность (Entity):
В контексте ER-диаграммы сущности представляют собой ключевые объекты или понятия, которые мы хотим описать и с которыми работать в рамках системы. Мы их извлекаем при вычитке требований.
Примеры:
🔵В библиотеке, сущностью может быть Книга.
🔵В рамках IT-инфраструктуры компании, сущностью может быть Сервер с конкретным номером.
🔵В нашем проекте PetCo, одной из сущностей является Заказ — комплексное представление о том, что клиент хочет приобрести.


Атрибут (Attribute):
Атрибуты описывают характеристики или свойства сущности. Это подробности, которые помогают нам лучше понять и описать каждую сущность.
Примеры:
🔵Книга: Название, Автор и Год издания.
🔵Сервер: IP-адрес, Тип оборудования и Местоположение.
🔵Заказ в PetCo: Номер заказа, Дата заказа, Статус заказа и Список товаров.

Есть ли отличия между сущностью и атрибутом в ER-диаграмме и без ER-диаграммы?
Нет.


Фиксируем ключевые определения:

Сущность — любой реальный или воображаемый (абстрактный) объект этого мира (стол, стул, мяч и т.д.).

Таблица — это физическая структура в базе данных, которая хранит данные конкретной сущности. Каждая запись в таблице представляет экземпляр сущности.
Одна сущность чаще всего представлена одной таблицей. Однако в сложных системах одна сущность может быть разделена между несколькими таблицами (например, из-за нормализации базы данных).

Свойство (атрибут) — характеристика сущности, описывающая конкретный объект (цвет, материал, размер).
Поле БД — это место в таблице БД, где хранится конкретное значение атрибута для конкретной записи.

Объект — сущность с конкретным набором атрибутов (зеленая железная большая машина; красный резиновый маленький мяч, желтое шелковое размера S платье) 🙌

Типы связей - моя любимая тема! Поэтому рассказываю, показываю лайфхаки, и мы переходим к логической модели БД 🙂

Названия типов связей основываются на их кратностях. Помните, я вам рассказывала о том, что в одном заказе может быть много товаров? Это я фактически определяла количественную зависимость у сущностей с двух сторон - кратность связи.

Есть три основных типа связей и остальные, в зависимости от системы и ситуации. Не усложняйте при проектировании. Как правило трех основных достаточно. Крайне редко можно встретить связь “один-к-двум”, но она есть в реальных проектах и часто без неё никуда.

🔶 Один-к-одному (1:1)
Каждому экземпляру сущности A соответствует не более одного экземпляра сущности B и наоборот.
Пример: Представьте, что в проекте PetCo каждый магазин имеет только одного администратора, и каждый администратор руководит только одним магазином. Здесь между магазином и администратором устанавливается связь 1:1.

🔶 Один-ко-многим (1:N) = Многие-к-одному (N:1) - разницы нет, только порядок чтения.
Один экземпляр сущности A может иметь отношение ко многим экземплярам сущности B, но каждый экземпляр сущности B связан с не более чем одним экземпляром сущности A.
Пример: Один клиент может сделать множество заказов в зоомагазине PetCo, но каждый заказ принадлежит только одному клиенту.

🔶 Многие-ко-многим (M:N)
Один экземпляр сущности A может иметь отношение ко многим экземплярам сущности B, и наоборот, один экземпляр сущности B может иметь отношение ко многим экземплярам сущности A.
Пример: В корзине по заказу может быть множество товаров из ассортимента, при этом один и тот же товар может быть включен в различные корзины разных клиентов.

На ER-диаграмме эти связи отображаются линиями между сущностями. Есть разные варианты обозначений. На картинке вы видите примеры связей ER и из UML (мне обозначения UML ближе - они понятнее).