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

Пользователь (user)
- ID пользователя
- Email
- Контактные данные (адрес, номер телефона и т.д., если есть)
- История заказов

Товар (product)
- ID товара
- Наименование товара
- Объем (если применимо, например, 200 мл)
- Цена
- Количество на складе

Заказ (order)
- ID заказа
- ID пользователя (внешний ключ к таблице Пользователь)
- Дата и время создания заказа
- Общая сумма заказа
- Статус заказа (например, создан, оплачен, отменен и т.д.)
- Срок жизни заказа
- Комментарий

Заказанный товар (ordered_product)
- ID заказанного товара
- ID заказа (внешний ключ к таблице Заказ)
- ID товара (внешний ключ к таблице Товар)
- Количество заказанного товара
- Цена товара на момент заказа (если цена может меняться со временем)

Платеж (Payment)
- ID платежа в PetCo
- Ссылка на страницу платежа
- ID заказа (внешний ключ к таблице Заказ)
- Дата и время платежа
- Статус платежа (например, в обработке, успешный, отклоненный)
- Платежная система (пока только Raif Pay)
- Сообщение/код ответа от платежной системы
- Способ оплаты (СБП, карта)


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

К посту на всякий случай прикрепила картинку с напоминанием об уровнях представления модели БД. Я описала список таблиц на логическом уровне проектирования.

Первый шаг в сторону описания маппинга данных сделан 😉

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

Я желаю каждому из вас достичь поставленных целей, обрести новые навыки и уверенность в своих силах. Ваше доверие и готовность к развитию вдохновляют! ❤️

13 сентября нас ждет первый практический вебинар, все напоминания уже заготовлены в нашем чате 😉

Помните: вы пришли получать опыт, получать ответы на вопросы, собирать ошибки и разбираться, как не допустить их на своей работе. Будьте онлайн, будьте смелыми, и не бойтесь задавать даже самые простые, как вам кажется, вопросы. Это важно! Следуйте этим указаниям и тогда всё точно получится!

Собираем силы, отдыхаем в выходные и... до встречи оналайн!

Маппинг - сопоставление данных. Что и с чем сопоставлять? 🔑

Есть несколько компонентов системы PetCo, которые участвуют в сценарии оплаты заказа:
✔️ Мобильное приложение / веб-приложения,
✔️ Backend PetCo,
✔️ Backend PetStore (кассовый),
✔️ Raif Pay - платежная система.

Данные, которые надо сопоставлять (маппить) для постановок задач:
🟠 Мобильное приложение / веб-приложения:
на UI.
🟠 Backend PetCo:
в БД сервера,
и в интеграционном методе API, к которому обращаются мобильное или веб-приложение:
🟠 Backend PetStore (кассовый)
в API внешней системы PetStore, БД для нас закрыта.
🟠 Raif Pay - платежная система:
в API внешней системы Raif Pay, БД для нас закрыта.

Когда и в каких случаях рекомендуется описывать маппинг:
🟢 Для задачи на мобильное или веб-приложение:
Маппинг между API PetCo и UI.
🟢 Для задачи на интеграционный API PetCo c Raif Pay:
Маппинг между API PetCo, БД PetCo и API Raif Pay.
🟢 Для задачи на интеграционный API PetCo c PetStore (смена статуса заказа в PetStore на оплаченный:
Маппинг между API PetCo, БД PetCo и API PetStore.

Это три отдельные таблицы маппинга данных, для трех разных постановок задач в рамках интеграции систем. Теперь надо пример 👇

Проектирование интеграционного метода для получения статуса заказа через RaifPay 💻

🧩 Для получения статуса заказа после его создания подходит метод GET https://pay-test.raif.ru/api/payment/v1/orders/{orderId}, который возвращает полную информацию о заказе по идентификатору.

🧩 GET https://pay-test.raif.ru/api/payment/v1/orders/{orderId}
path Parameters:
+ orderId
header Parameters:
+ Authorization (Bearer secretKey)

Ответ (успешный):
{
"amount": 12500.5,
"comment": "Покупка кота",
"status": {
"value": "NEW",
"date": "2019-08-24T14:15:22+03:00"
},
"expirationDate": "2019-08-24T14:15:22+03:00"
}




Мобильному и веб-приложению не рекомендуется обращаться напрямую к API Raif Pay, т.к. запрос подписывается секретным ключом Bearer secretKey - общий для всех запросов ото всех пользователей в Raif Pay. Хранить его в мобильном приложении или получать с сервера для использования в запросах к RaifPay с клиента опасно. Есть риск его утери и использования в целях мошенничества.
С целью безопасности, интеграция систем PetCo и Raif Pay реализуется через бэкенд-приложение PetCo.



🟢 Для реализации этой интеграции необходимо разработать интеграционный API-метод в PetCo.

На вход методу предаются: id заказа в PetCo, авторизация пользователя PetCo (при наличии).
Результат вызова метода: сведения об актуальном статусе заказа в Raif Pay, получаемые в систему PetCo. Если статус в Raif Pay обновляется, то его необходимо синхронизировать с PetCo и перезаписать в БД PetCo. Вернуть пользователю API PetCo актуальный статус.

🟢 Дизайн метода REST API предлагается сделать так:
GET ..../order/{orderId}
path Parameters:
+ orderId
header:
+ Authorization (при наличии)

Ответ (успешный):
{
"id": "id в PetCo",
"number": 23245,
"externalId": "...",
"userId": "...",
"amount": 12500.5,
"comment": "Покупка кота",
"status": "NEW",
"date": "2019-08-24T14:15:22+03:00",
"expirationDate": "2019-08-24T14:15:22+03:00",
"products":
[ { "id": ...., "name": ... }, { "id": ...., "name": ... } ]
}

Пример описания маппинга данных для интеграционных методов 🤝 Таблицы внутри

Я слышу и вижу сплошное:
🔹 В вакансиях аналитиков нужны знания 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. А теперь представьте как много всего можно найти и проверить, когда читаешь ТЗ или описания бизнес-процессов 😍