Системный Аналитик (@sys_sa) के नवीनतम पोस्ट टेलीग्राम पर

Системный Аналитик टेलीग्राम पोस्ट

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

Реклама и сотрудничество @radale

https://gosuslugi.ru/snet/67b0613c6411ff785396754a
16,296 सदस्य
85 तस्वीरें
4 वीडियो
अंतिम अपडेट 11.03.2025 07:48

Системный Аналитик द्वारा टेलीग्राम पर साझा की गई नवीनतम सामग्री

Системный Аналитик

11 Feb, 08:04

8,289

SOLID

SOLID — набор принципов проектирования объектно-ориентированных систем.
Помогает создавать гибкую, поддерживаемую и масштабируемую архитектуру.
Нужны для улучшения структуры и качества кода.


SOLID и ООП: в чём разница? 

🔷ООП —  методология или стиль программирования ( с основными свойствами: инкапсуляция, наследование и полиморфизм)
🔴SOLID — набор рекомендаций, как правильно использовать принципы ООП, чтобы создать код, который будет легче поддерживать и расширять
ООП даёт инструменты, а SOLID помогает применять их эффективно.


Принципы SOLID

❤️ — Single Responsibility Principle (Принцип единственной ответственности) 
Каждый класс должен решать одну задачу
делай модули меньше
🟢Пример: класс "Order" отвечает только за управление заказом, а уведомления отправляются другим классом

♥️Связь с ООП: связан с инкапсуляцией — каждый объект скрывает детали своей реализации и выполняет только одну функцию

❤️— Open/Closed Principle (Принцип открытости/закрытости) 
Класс должен быть открыт для расширений, но закрыт для изменений
делай модули расширяемыми

🟢чтобы добавить новый тип отчёта, создаём новый класс, не изменяя существующий код

♥️использует наследование - создание новых классов на основе существующих;
и полиморфизм - способность объектов разных типов использовать общий интерфейс для выполнения различных действий

❤️— Liskov Substitution Principle (Принцип подстановки Барбары Лисков) 
Подклассы должны заменять родительские классы без ошибок
наследуйся правильно
🟢 если класс "Bird" имеет метод "fly", класс "Penguin" не должен его наследовать, так как пингвины не летают

♥️связан с принципом наследования. Подклассы должны правильно реализовывать поведение родительских классов, не нарушать полиморфизм

❤️ — Interface Segregation Principle (Принцип разделения интерфейса) 
Узкие специализированные интерфейсы лучше, чем один общий
дроби интерфейсы
🟢вместо общего интерфейса "Animal" создаём отдельные интерфейсы "Flyable", "Swimmable", "Runnable"

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

❤️ — Dependency Inversion Principle (Принцип инверсии зависимостей) 
Модули должны зависеть от абстракций, а не от конкретных реализаций
используй интерфейсы
🟢класс "UserService" зависит от интерфейса "Database", а не от конкретной реализации БД

♥️использовании абстракций (отделения концепции от её реализации);
и полиморфизма для уменьшения зависимости между модулями


Нарушение SOLID приводит к антипаттернам, таким как "God Object" (класс с множеством задач) или "Spaghetti Code" (запутанный код)


Зачем аналитику SOLID? 

➡️ поможет оценить архитектуру на этапе проектирования
🟢например, при добавлении новых способов оплаты система не должна требовать переписывания основного кода (принцип ❤️)

➡️ для составления требований к разработке и задач рефакторинга
🟢 если каждая функция изолирована, то изменения не затронут другие модули (принцип ❤️)

➡️ для согласования архитектурны с разработкой
🟢 корректное использование интерфейсов предотвратит сложную интеграцию с новыми системами в будущем (принцип ❤️)


📎 Материалы
1. Принципы SOLID в программировании — что это такое
2. SOLID
3. Простое объяснение принципов SOLID
4. SOLID принципы: что это такое и зачем они нужны?
5. SOLID — это несложно. С примерами на Python
6. SOLID == ООП?

📚Книги
1. Чистая архитектура — Роберт Мартин
2. Объектно-ориентированный анализ и проектирование с примерами приложений - Грэди Буч
3. Объектно-ориентированное мышление - Мэтт Вайсфельд
4. Приемы объектно-ориентированного проектирования. Паттерны проектирования. Хелм Ричард, Влиссидес Джон

#проектирование



🧑‍🎓 Больше полезного в базе знаний по системному анализу
Системный Аналитик

10 Feb, 13:33

3,473

⚡️ Внимание, аналитики и будущие специалисты!

Мы рады предоставить вам возможность стать частью мира системного анализа, а также улучшить свои навыки вместе с МАИ и Т1! 🚀

Мы подготовили для вас Квиз, который поможет найти ответы на вопросы:
Подходит ли вам профессия системного аналитика?
Какие навыки нужно развивать, чтобы добиться успеха?
Как быстро вы сможете достичь успеха в этой сфере?

⚡️ После прохождения Квиза вы получите:
- Персональную оценку ваших возможностей в роли системного аналитика.
- Полезные советы по развитию ключевых навыков.
- Скидку 50% на трехмесячный курс "Системный аналитик" от МАИ и Т1.

Начните путь к успешной карьере с первого шага – пройдите Квиз и оставьте заявку на курс "Системный аналитик" со скидкой 50%! 🚀

👉🏻 ПРОЙТИ КВИЗ 👈🏻

Реклама
Системный Аналитик

08 Feb, 10:06

8,619

✍️ Server-Sent Events (SSE)

Server-Sent Events (SSE) —  технология, при которой сервер отправляет клиенту обновления по мере их появления.
Клиенту не нужно отправлять повторяющиеся запросы
Соединение одностороннее: от сервера к клиенту

◾️Для поддержания соединения открытым, сервер может отправлять пустые события с определенной периодичностью, чтобы не закрылось соединение браузером из-за таймаута.

◾️Относится к асинхронным методам, т.к. позволяет получать данные от сервера, как только они становятся доступны, без задержек и постоянных перезапросов.


Как работает


😈клиент делает HTTP-запрос на сервер и  остается подключенным к серверу
😈сервер открывает однонаправленный поток данных, отправляет обновления на клиент в формате текстовых событий
😈онлайн клиент получает данные по мере их поступления с сервера


Где применяется

Когда сервер должен регулярно обновлять информацию на веб-странице.
Например:
🔘в системах мониторинга (получение обновлений о состоянии системы)
🔘чатах (получение новых сообщений)
🔘торговых приложениях (обновления котировок)
🔘лентах новостей и социальных сетях
🔘push-уведомления из веб-приложения


Пример работы SSE для мониторинга системы

💙 Сервер отслеживает метрики системы (загрузка CPU, ошибки, статус сервера)
💙 Клиент подключается через SSE и получает обновления об изменении состояния системы в реальном времени
💙 Как только сервер получает новые данные, он отправляет их клиенту


Плюсы и минусы

интегрируется через стандартные HTTP-запросы
только сервер инициирует обновления,не нужно постоянно отправлять запросы от клиента на сервер (polling). Это снижает нагрузку
автоматически восстанавливает соединение при его потере

однонаправленность — только от сервера к клиенту
работает только через HTTP, менее гибко по сравнению с WebSocket
может не поддерживаться старыми браузерами (работает только с UTF-8)
нет возможности передать свои заголовки в запрос


📎 Материалы

1. Асинхронный веб: WebSocket, Server-Sent Events, Long Polling и Short Polling
2. Подписки на GraphQL: Почему мы используем SSE/Fetch вместо Websockets
3. Вам посылка, или Как мы доставляем сообщения с сервера на клиент в реальном времени
4. Server-Sent Events: пример использования
5. Потоковое обновление с событиями, отправленными сервером
6. Server Sent Events
7. WebSockets vs SSE: особенности и сценарии использования

📚Книги
1. Сергей Константинов. API
2. Джей Гивакс. Паттерны проектирования API
3. Арно Лоре. Проектирование веб-API


#api #интеграции



🧑‍🎓 Больше полезного в базе знаний по системному анализу
Системный Аналитик

07 Feb, 09:38

4,286

30 собеседований за 1 месяц 🔝

Именно столько технических интервью прошел автор канала «Пасека аналитика» и сейчас делится информацией об этом: статистика, подготовка и советы.

Интересные посты:⚠️

🕗Границы работы SA 1/2
🕗Границы работы SA 2/2
💵Зарплаты SA в 2024
👋Рабочие встречи 1/2
👋Рабочие встречи 2/2

Подписывайтесь! ✔️
https://t.me/apiaryanalyst
Системный Аналитик

05 Feb, 08:04

8,524

📂 Стратегии работы с кэшем

Ранее описывали процесс кэширования
Рассмотрим подходы к работе с кэшем


Стратегии чтения данных

Кэширование на стороне (Cache Aside) 

🟡приложение запрашивает данные из кэша
🟡если данные отсутствуют в кэше, приложение запрашивает их из БД
🟡после получения, приложение записывает их в кэш для следующих запросов

Обновление кэша: обновляется только после запроса данных из БД

просто реализовать, контроль за кэшированием на уровне приложения
если данные изменяются в базе, кэш может стать устаревшим

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


Сквозное чтение (Read Through) 

🟡приложение запрашивает данные только из кэша
🟡если данных нет, кэш сам обращается к БД, извлекает данные и возвращает их приложению, одновременно сохраняя их в кэше

Обновление кэша: автоматически при отсутствии данных в нём, во время запроса из БД

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

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


Стратегии записи данных

Сквозная запись (Write Around) 

🟡приложение записывает данные напрямую в БД
🟡данные в кэше при этом не обновляются
🟡последующие чтения могут вызвать обновление кэша через механизм Cache Aside

Обновление кэша: приложение запрашивает данные из БД. Получает и записывает их в кэш

подходит для данных с редкими операциями чтения
кэш может быть неактуальным, при первом запросе данные не кэшируютя сразу

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


Сквозная запись (Write Through

🟡приложение записывает данные сначала в кэш
🟡кэш автоматически обновляет данные также в БД, синхронизируя их

Обновление кэша: кэш и БД всегда синхронизированы, так как данные записываются одновременно в в БД и в кэш

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

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


Обратная запись (Write Back) 

🟡приложение записывает данные в кэш
🟡кэш откладывает обновление БД, выполняет его асинхронно через определенные интервалы времени / по необходимости

Обновление кэша: данные в кэше актуальные, но БД обновляется позже, асинхронно

быстрая запись данных, поскольку операция записи в БД откладывается
риск потери данных в случае сбоя кэша до того, как БД будет обновлена

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


Хранение кэша

Кэш в архитектуре приложения обычно хранится в памяти, либо на выделенных серверах для кэширования. Их располагают ближе к приложению для быстрой обработки запросов.
Например,
🟡внутри приложения — локальный кэш
🟡на внешнем сервере / группе серверов — распределённый кэш


📎 Материалы
1. [По полочкам] Кэширование
2. SE: Проектирование эффективной системы кэширования
3. Стратегия кеширования в приложении
4. Все о кэшировании: стратегии, проблемы и оптимизация
5. Все о кэшировании и кэшах
6. Основные принципы кэширования веб-приложений
7. Проектирование эффективной системы кэширования для высоконагруженной системы
8. Cache-aside паттерн
9. Введение в кэширование со сквозным чтением с помощью NCache
10. Продуманные запросы: стратегии кэширования в век PWA

#проектирование #архитектура



🧑‍🎓 Больше полезного в базе знаний по системному анализу
Системный Аналитик

31 Jan, 08:05

10,506

▶️ ER-диаграмма (Entity-Relationship Diagram)

ER-диаграмма (Entity-Relationship Diagram, ERD) — диаграмма "сущность-связь",  которая применяется для:
🔘проектирования БД, описания процессов и бизнес-логики
🔘моделирования структуры данных и их связей в системах или приложениях
🔘документирования требований

Состоит из элементов

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


Типы связей между сущностями

🟡Один-к-одному (1:1): каждая запись в одной сущности соответствует одной записи в другой
🟡Один-ко-многим (1:M): одна запись в сущности соответствует нескольким записям в другой
🟡Многие-ко-многим (M:M): каждая запись в одной сущности связана с несколькими записями в другой, и наоборот


Пример ERD для интернет-магазина

*️⃣Сущности: пользователь, заказ, товар

*️⃣Атрибуты:
— пользователь: ID, имя, email
— заказ: ID заказа, дата, сумма
— товар: ID товара, название, цена

*️⃣Связи:
— пользователь делает заказ (один пользователь может сделать много заказов — связь "один ко многим")
заказ содержит товары (один заказ может включать много товаров — связь "многие ко многим")


Уровни ER-диаграмм

ER-диаграммы делятся на 3 уровня в зависимости от уровня детализации

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

🟡Логический: уточняет атрибуты сущностей и типы связей.
Детализирует модель, но не привязан к конкретной СУБД
используется на этапе уточнения требований и согласования структуры данных

🟡Физический: описывает, как данные будут реализованы в БД, с учётом таблиц, индексов, первичных и внешних ключей.
используется на этапе реализации и разработки БД


Нотации ERD

ER-диаграмма —  визуальная модель или схема,
а нотации — методы, с помощью которых она строится

🟡Нотация IDEF1X: фундаментальная, используется для физического уровня, ориентирована на стандарты реляционных БД. Редко используется на практике
сущности: прямоугольники с именем сущности
связи: линии с символами "лапками" для связи один-ко-многим, "палка" для связи один-к-одному
атрибуты: внутри прямоугольников сущностей

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

🟡Нотация Мартина («воронья лапка»): компактнее нотации Чена, используют для логического уровня, когда нужно описать все атрибуты сущностей

сущности: прямоугольники с атрибутами внутри
связи: линии с "лапками вороны" для связи один-ко-многим и палочкой для связи один-к-одному
атрибуты: внутри сущностей, первичные ключи выделены отдельной строкой


Отличия от других инструментов


🔵UML-диаграммы классов

Нужны для моделирования объектов и их поведения в объектно-ориентированном программировании, а не для реляционных БД
UML отражают методы (функции) классов
ERD показывают только структуру данных и их взаимосвязи

🔵BPMN

Моделируют бизнес-процессы и последовательность действий, а не данные
BPMN отображает шаги процесса и участников
ERD — только структуру данных и их отношения внутри системы


📎 Материалы

1. Сущности и связи: как и для чего системные аналитики создают ER‑диаграммы
2. Что такое ER-диаграмма и как ее создать?
3. Проектирование ER-диаграммы
4. Что выбрать для проектирования БД: сравнение UML-диаграммы классов и ER-диаграммы
5. Модель диаграммы Entity Relations (ER) с примером СУБД
6. Пример построения ER-модели и SQL-запросов к ней
7. Учимся проектированию Entity Relationship-диаграмм
8. Как создать ER-диаграмму
9. Методика построения ER-диаграммы для базы данных
10. Диаграммы «сущность – связь» (ERD). Типы отношений. Построение схемы базы данных на основе ERD диаграмм

#проектирование



🧑‍🎓 Больше полезного в базе знаний по системному анализу
Системный Аналитик

27 Jan, 15:13

10,427

🔵 Интеграция через общую базу данных

Рассмотрим еще один способ интеграции, менее популярый: интеграция через общую БД
Этот подход имеет свои преимущества, но не всегда является лучшим выбором из-за сложностей с согласованностью данных и производительностью

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

Принцип работы

🤤 все подключено к одной БД, ее используют для обмена информацией
🤤 системы читают и пишут данные напрямую через SQL-запросы или с помощью API, коннекторов

Особенности

💙системы должны согласовать структуру данных (схему БД), чтобы все понимали формат и правила работы с данными
💙одновременный доступ разными системами может приводить к блокировкам
Чтобы избежать используются механизмы синхронизации транзакций
💙изменения сразу видны другим системам


Способы интеграции

😮‍💨 Коннекторы (Database Connectivity, DBC)

Например, ODBC/JDBC-драйверы.
🟧JDBC — интерфейс для подключения Java-приложений к БД, позволяет выполнять SQL-запросы
🟧ODBC — универсальный интерфейс для подключения приложений на разных языках к БД, также использует SQL-запросы

Работают как посредники между приложением и БД.
Принимают запросы от приложения, преобразуют их в SQL-команды для БД, выполняют запросы и возвращают результат

😮‍💨 API

Приложения взаимодействуют с БД через REST или SOAP API
Отправляют HTTP-запросы, которые преобразуются в SQL-запросы внутри базы

😮‍💨 Прямое подключение

🤤 через SQL-запросы
Прямое подключение через SQL-запросы: приложение отправляет SQL-команды напрямую в базу данных по сети (например, через TCP/IP), без использования посредников.

🤤 через сетевые драйверы
Используются драйверы для установления связи с БД по сети (например, TCP/IP), затем приложение отправляет SQL-запросы напрямую

В обоих случаях идет работа с БД напрямую.
Но сетевые драйверы (например, для PostgreSQL или MySQL) обеспечивают управление сетевым соединением

🤤 через представления

Создаются виртуальные таблицы (представления), которые объединяют данные из нескольких таблиц.
🟧приложения не изменяют основные таблицы
🟧они выполняют SQL-запросы к представлениям, как к обычным таблицам
🟧выдаются права на чтение нужных представлений


Когда использовать общую БД

💙интеграция внутренних систем (например, системы из одной корпоративной платформы: ERP, CRM и т.д.)
💙для объединения данных из разных источников
💙надо сразу видеть изменения в системе
💙для минимизации повторного хранения данных
💙для интеграции Legacy-систем или самописных систем


Пример работы

В компании несколько систем: интернет-магазин, система управления складом и бухгалтерия

интернет-магазин: клиенты оформляют заказы, данные сразу записываются в общую Д
система управления складом: получает информацию о заказах из той же БД и обновляет количество товара на складе
бухгалтерия: автоматически подтягивает данные о продажах из общей БД для учёта финансов

Все системы работают с одной БД, не нужно синхронизировать данных между ними, данные актуальны во всех системах


Недостатки

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


📎 Материалы

1. Основы интеграции информационных систем
2. Архитектура приложений и интеграций: гайд по основным понятиям простыми словами
3. Современные стандарты информационного взаимодействия систем
4. Простой пример JDBC для начинающих
5. Две альтернативы JDBC
6. PostgreSQL и JDBC выжимаем все соки
7. Доктор, у меня легаси: лечим устаревшие ИТ-системы
8. Legacy-системы
9. Общая информация о ODBC и Connector/ODBC
10. Почему интеграционная бд это отстой

#интеграции



🧑‍🎓 Больше полезного в базе знаний по системному анализу
Системный Аналитик

27 Jan, 08:03

3,542

Бесплатный вебинар по прокачке LinkedIn!

Твой LinkedIn выглядит как резюме динозавра? 🦖
А ты хочешь быть на шаг впереди?

Тогда приходи на вебинар: «Как привлечь внимание работодателя в 2025 году»
30 января в 20:00 по Москве/ 18:00 по Берлину


Что будет на вебинаре:
⚡️ Разберёмся с Job matching и январскими обновлениями LinkedIn.
⚡️ Перепишем About и Headline так, чтобы они цепляли внимание рекрутеров.
⚡️ Узнаем, как проверять жизненно важные метрики для офферов.
⚡️ Поймём, как видят твой профиль рекрутеры и почему тебя зовут (или не зовут) на интервью.

Спикер — Александр Лепёшкин из Берлина, ex-директор проектных офисов Ozon и Lamoda, эксперт по трудоустройству в Европе и MENA (150+ успешных кейсов).

9️⃣0️⃣ минут полезной информации о настройке профиля совершенно бесплатно. Карьерные коучи берут за это большие деньги 💰

🔗 Регистрируйся в боте по ссылке

А если хочешь больше инсайдов о жизни и работе в Европе и MENA?
👉Подпишись на канал LinkedIn & Career|Alex Lepeshkin
Системный Аналитик

24 Jan, 16:44

3,904

🔵🗣Вырасти до хардового Middle+ аналитика в 2025 году.
Как? Добавьте к своим скилам навыки в проектировании архитектуры и интеграций веб-сервисов!

Рассмотрите — авторский курс про архитектуру и интеграции
с практикой.
—————
По результатам курса вы:
▫️научитесь выбирать стиль интеграции под вашу задачу;
▫️сможете проектировать с нуля и описывать интеграции в современных стилях (API: REST, SOAP, gRPC и др. + брокеры сообщений);
▫️поймете, как правильно собирать требования и моделировать в UML;
▫️подготовитесь к собеседованию, решив более 100 тестов;
▫️разработаете свой API на Python;
—————
🟢Вы получите большую базу фундаментальных знаний, доступ к урокам и обновлениям остается навсегда 💡

• Всю программу и отзывы смотрите в боте курса.
• Бонусный модуль про проектирование баз данных — нормализация, транзакции, основы DWH, индексы.
• Результат после прохождения курса: 15 рабочих проектов в портфолио.
• Доступ к чату учеников (общение, обмен опытом, помощь внутри сообщества)

🔹🔹 С чего начать?🔹🔹
С открытых бесплатных уроков по архитектуре и интеграциям в чат-боте курса. Переходите.
👇
@studyit_help_bot

Скидка на курс от канала —
1 000₽ по промокоду
SYSSA5 до 31 января
Системный Аналитик

21 Jan, 10:08

12,291

🔵 Нормальные формы баз данных

Напомним, нормализация — организация данных в таблицах БД так, чтобы:
🟠устранить избыточность данных (уменьшаеся объем хранения, ниже риск рассинхронизации и проще управление)
🟠улучшить целостность данных (поддерживается правильные связи, меньше ошибок)
🟠уменьшить их дублирование (оптимизация структуры, лучше производительность)


Процесс нормализации

Таблицы делятся на мелкие, связанные по смыслу, а между ними создаются связи.
Происходит шаг за шагом. В результате БД приводится к нормальным формам (NF)


Нормальные формы (NF) – требование к структуре таблиц реляционных БД
🟣чем выше NF, тем меньше лишних и зависимых данных -> БД работает быстрее и точнее , но усложняется её структура
🟣БД считается нормализованной после достижения третьей нормальной формы.
NF выше третьей нужны для устранения более сложных зависимостей
🟣чтобы таблица была в нужной NF, она сначала должна соответствовать всем предыдущим формам.


😈Первая нормальная форма (1NF)
Требования:
каждое поле должно содержать атомарные значения (неделимые на части).
отсутствие повторяющихся групп данных

Пример:
➡️ до: таблица с полем "телефоны", где у одного человека несколько телефонов в одной ячейке.
⬅️ после: каждый телефон записан в отдельной строке

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

➡️ до: в таблице заказов хранятся поля "имя клиента", "адрес клиента" и "ID заказа". Эти данные повторяются для каждого заказа клиента, что приводит к избыточности.
⬅️ после: эти данные выносятся в отдельную таблицу "клиенты", чтобы убрать дублирование в каждом заказе одного клиента

😈нормальная форма (3NF)
все столбцы зависят только от первичного ключа
(т.е. устранение транзитивных зависимостей: когда второй атрибут зависит от первого, а третий - от второго)

➡️ до: в таблице товаров есть поле "город" и "почтовый индекс".
"почтовый индекс" зависит от "города", а не от товара.
⬅️ после: данные разделяются: "город" и "почтовый индекс" в отдельную таблицу адресов, а "товар" — в другую

🔣Нормальная форма Бойса-Кода (BCNF) — более строгая версия 3NF, решает некоторые её недостатки
каждый атрибут, от которого зависят другие поля в таблице, однозначно идентифицировал запись (был кандидатным ключом)

😈нормальная форма (4NF)
удаляются многозначные зависимости (несколько значений зависят от одного атрибута)

➡️ до: в таблице "студенты" есть поля "курсы" и "хобби". Один студент может учиться на нескольких курсах и иметь несколько хобби, что приведёт к дублированию данных.
⬅️ после: зависимости разделяют на отдельные таблицы: одна для курсов, другая для хобби, чтобы избежать повторений

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

➡️ в системе договоров один договор может включать несколько услуг от разных компаний.

😈нормальная форма (6NF)
редко используется, дальнейший шаг нормализации для поддержки временных данных и их зависимостей

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


📎 Материалы
1. Нормализация отношений. Шесть нормальных форм
2. Как привести данные в форму: что такое нормализация и зачем она нужна
3. Нормализация и нормальные формы (описание 1-6 NF)
4. Нормализация СУБД: пример базы данных 1NF, 2NF, 3NF
5. Первая НФ (1NF) базы данных
6. Вторая НФ (2NF) базы данных
7. Нормальные формы: третья и Бойса-Кодда
8. Четвертая НФ (4NF) базы данных
9. Пятая НФ (5NF)
10. Шестая НФ (6NF) базы данных

📚Книги
1. Технологии проектирования баз данных -- Дмитрий Осипов (Глава 6-7)
2. Основы технологий баз данных — Новиков Б. А. / Б. А. Новиков, Е. А. Горшкова, Н. Г. Графеева; под ред. Е. В. Рогова
3. Основы баз данных — Кузнецов (Лекции 7-9)

#бд



🧑‍🎓 Больше полезного в базе знаний по системному анализу