Мастерская IT-решений

☂️ Первая нормальная форма (1NF)

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

📀 Первая нормальная форма (1NF): Уничтожение повторяющихся групп.

Первая нормальная форма (1NF) означает приведение каждой сущности в такую форму, где каждое значение атрибута является простым (атомарным), а повторяющиеся группы отсутствуют. В нашей модели есть пара полей, которая подразумевает несколько экземпляров атрибута для одной строки (связь многие ко многим).

⏳ Проблема: Поле authors может содержать больше одного значения (авторов). Это нарушает правило 1-й НФ, поскольку должно быть одно значение на одну строку.

⌛️Решение: Разбиваем этот атрибут на отдельную таблицу (BookAuthors), где одна строка соответствует одному автору конкретной книги, а из таблицы книг убираем любое упоминание об авторах.

1. Books (Книги)
- title (название)
- isbn (ISBN-код)
- publicationyear (год издания)
- pagescount (количество страниц)
- availabilitystatus (статус доступности)
- location (местоположение/полка)

2. BookAuthors (Авторы книг)
- author (автор книги)
- book (книга)

3. BookGenres
– genre (жанр книги)
– book (книга)

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

Не забывайте правильно оценивать таски!)

♻️ Концептуальная модель данных ♻️

🤜 Проанализируем тип структуры

Какие аспекты нужно учесть:
▪️наличие большого количества стандартных сущностей (книги, клиенты, штрафы);
▪️необходимость обработки отношений между этими сущностями (книга связана с выдачей клиенту, выдача связана с записью о возврате);
▪️важность гарантии целостности данных при проведении различных операций.

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


🤜 Определяем атрибуты

Для нашей несложной задачи выделим следующие таблицы и поля:

📖 Books (Книги)
- title (название)
- isbn (ISBN-код)
- authors (авторы книги) – может быть > 1
- publicationyear (год издания)
- pagescount (количество страниц)
- availabilitystatus (статус доступности)
- location (местоположение/полка)
- genre (жанр). Может быть > 1)

🧑‍🎓 Authors (Авторы)
- fullname (ФИО автора)
- biography (биография)

🧞‍♂️ Genres (Жанры)
- name (жанр)

🏛 Departments (Отделы)
- name (название отдела)

🙍 Users (Читатели)
- firstname (имя)
- lastname (фамилия)
- readerticketnumber (номер читательского билета)
- phonenumber (телефон)
- email (электронная почта)
- address (адрес проживания)

🎫 Loans (Выдачи книг)
- book (Выданная книга)
- user (Пользователь, который ее взял)
- issuedate (дата выдачи)
- returndate (предполагаемая дата возврата)
- actualreturndate (фактическая дата возврата)
– loantype (тип выдачи - читальный зал или на дом)

💸 Fines (Штрафы)
- loan (Запись о выдаче)
- amount (сумма штрафа)
- reason (причина начисления штрафа)
- status (статус, оплачен или нет)

Далее займемся приведением данных к нормальным формам.

♻️ Концептуальная модель данных ♻️

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

➿ Книга и️ Автор
Один автор может написать много книг
Одна книга также может иметь нескольких авторов.
связь «многие ко многим»


➿ Книга и️ Жанр
Книга может относиться сразу к нескольким жанрам
связь «многие ко многим»

➿ Книга и️ Отдел
Книги располагаются в определенных отделах библиотеки: один отдел хранит много книг, но каждая книга находится лишь в одном отделе.
связь «один ко многим»

➿ Книга и Запись о выдаче
Каждая запись о выдаче связана с конкретной книгой: одна книга может многократно выдаваться разным пользователям, но конкретная запись относится именно к одной книге.
связь «один ко многим»

➿ Пользователь и️ Запись о выдаче
Пользователи берут разные книги в разное время: каждый пользователь может брать много книг, но отдельная запись принадлежит одному пользователю.
связь «один ко многим».

➿ Запись о выдаче и Штрафы
Если пользователь просрочил возвращение книги, появляется задолженность: одна запись о выдаче может привести к начислению одного или нескольких штрафов, но штраф всегда привязывается к конкретной записи о выдаче.
связь «один ко многим»

Следующий этап — выбор подходящей структуры хранения данных.

Котики, кто на ЛАФ? 😘

Показываю, что получилось у меня.
📘 Книга
— название книги, автор, ISBN, издательство, жанр, количество страниц, дата публикации, местоположение (полка), статус доступности (занята/свободна).

🧑‍💼 Пользователь
— ФИО читателя, номер читательского билета, контактные данные (телефон, email), адрес проживания, история взятий книг, долги (штрафы).

🧙 Автор
— имя автора, биографические сведения, список произведений.

👩‍❤️‍👨 Жанр
— литературный жанр (детектив, роман, фантастика и др.).

🏢 Отдел
— секция библиотеки (художественная литература, учебники, справочная литература и т.п.)

💸 Штрафы
— виды штрафов, размер штрафа, сроки просрочки возврата.

📑 Запись о выдаче
— книга, выданная пользователю, срок выдачи, предполагаемый срок возврата, фактический возврат, штраф (если применимо).

Следующим этапом будет определение связей между этими сущностями.

Сбор сущностей

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

📒 Особенности и условия:
1. За просрочку возврата полагается штраф
2. Книгу можно взять домой или в читальный зал библиотеки. Статусы книги должны различаться.
3. Система предназначена не только для просмотра статуса книги, но и места ее хранения на полке

Как говорили ранее, начинаем со сбора сущностей. Напишите в комментариях, какие сущности вы бы предложили. Вечером покажу свой вариант :)

Теперь, когда мы выбрали СУБД, можно приступать к модели данных. Эта часть является одним из моих любимых процессов при проектировании системы. Но очень редко я следую правилам. Сначала я думала, что я нетерпелива, чтобы проходить последовательно по всем процессам. А потом я поняла, что эти знания вложены в меня настолько глубоко, что я «из коробки» проектирую модель нормализованной и со всеми ключами.
Но давайте разложим по полочкам весь процесс. Будет долго, но эффективно. Такой очевидный этап как сбор требований мы пропустим и перейдем сразу к данным.

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


🏮 Определение отношений между сущностями
Далее устанавливаются связи между выявленными сущностями. Например, один клиент может иметь много заказов, а один заказ может содержать несколько товаров. Связи бывают трёх типов:
- Один-к-одному (1:1)
- Один-ко-многим (1:N)
- Многие-ко-многим (N:M)

🏮 Создание концептуальной модели данных
Концептуальная модель отражает высокоуровневую структуру данных без привязки к конкретной СУБД. Обычно используется нотация ERD (Entity Relationship Diagram). Здесь отражаются сущности, их атрибуты и взаимосвязи.

🏮 Нормализация данных
Нормализация является важным этапом, целью которого является устранение избыточности данных и повышение целостности базы данных. Она заключается в последовательном приведении схемы базы данных к определённым формальным нормам (нормальные формы):

- Первая нормальная форма (1NF): Уничтожение повторяющихся групп.
- Вторая нормальная форма (2NF): Устранение частичной зависимости атрибутов от первичного ключа.
- Третья нормальная форма (3NF): Исключение транзитивной зависимости атрибутов.
- Четвёртая нормальная форма (4NF): Разделение многозначных зависимостей.
- Пятая нормальная форма (5NF): Минимизация аномалий обновления путём разбиения сложных зависимостей.

Этот процесс позволяет минимизировать дублирование данных и повысить производительность запросов.


🏮 Физическое проектирование
На данном этапе разрабатывается физическая структура базы данных, учитывающая особенности выбранной СУБД. Определяются типы полей, индексы, ограничения целостности, триггеры и другие элементы физической структуры.

Примеры решений физического уровня:
- Выбор оптимального типа поля (INT, VARCHAR, DATE и др.)
- Создание уникальных ключей и индексов для ускорения выборок.


🗝 Таким образом мы последовательно приходим к итоговому решению.
Дальше разберем подробно основные шаги.

У кого совпало? 😆

Выбор СУБД

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

🕹 MySQL

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

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


🕹 PostgreSQL
Особенности
- Более мощная альтернатива MySQL с поддержкой сложных SQL-запросов и расширенных функций.
- Гибкая поддержка транзакций ACID, оптимизированная работа с большими объемами данных.
- Возможность создавать расширения, хранимые процедуры и триггеры.

Рекомендуемые задачи
- Средние и крупные проекты с большим объемом данных и сложными структурами.
- Приложения, которым важна высокая производительность и надежность.
- Географические приложения благодаря встроенной поддержке пространственных данных (расширение PostGIS).


🕹 MongoDB
Особенности
- NoSQL база данных с документоориентированной моделью хранения данных.
- Высокая гибкость схемы базы данных — возможность хранить разнородные данные без жесткой структуры.
- Отличается высокой производительностью при работе с большими массивами документов.

Рекомендуемые задачи
- Масштабируемые веб-сервисы и мобильные приложения с частым изменением структуры данных.
- Работа с полуструктурированными или слабо формализованными данными (логирование действий пользователей, социальные сети).
- Анализ больших объемов неструктурированных данных (Big Data).


🕹 ClickHouse
Особенности
- Колоночная СУБД, разработанная специально для аналитики и обработки огромных объемов данных в режиме реального времени.
- Обладает уникальной скоростью обработки аналитических запросов (OLAP), отлично масштабируется горизонтально.
- Идеальна для сбора и анализа метрик, логирования событий и построения дашбордов.

Рекомендуемые задачи
- Аналитика поведения пользователей, обработка журналов событий.
- Реалтайм-аналитические запросы и построение отчетов по данным большого объема.
- Логирование активности приложений и серверов (системы мониторинга, BI-платформы).

Кажется, мне пора открывать свое hr-агентство... а пока попробуем здесь :)

📣 ищу аналитика уровня middle и выше на интересный банковский проект . нужен хороший технический бекграунд (sql, очереди и всякое такое)
есть желающие?

Кто едет на ЛАФ? признавайтесь)))

☀️ Системные аналитики ПСБ Марина Липатова и Дарья Борисова выступят на Летнем Аналитическом Фестивале.

🌷 Марина расскажет, как обеспечить взаимопонимание между участниками создания информационной системы, и разберет артефакты разработки ПО. В ее докладе представлены взаимодополняющие взгляды на уровнях бизнеса, фронт- и бэк-разработки, дизайна, тестирования, системного анализа. А еще реальные практики, которые можно адаптировать под свой проект.

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

ЛАФ — одна из старейших ежегодных конференций в России и СНГ по направлению системного анализа, бизнес-анализа, работы с требованиями и управлению продуктами. 

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

Когда, где:
7–8 июня, Кострома

✏️ Подробности на сайте.

Идеальным вариантом будет комбинация двух типов баз данных:

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

🏥 NoSQL база данных
используется для хранения разнородных данных — изображений (рентгеновских снимков, МРТ, КТ), биоэлектрических сигналов (ЭКГ), лабораторных данных и нестандартных показателей. Эта база будет отвечать за расширение набора данных и экспериментальные нововведения.

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

Неловко получилось...
🤣

Знаю, что хотите задачку :) Держите!
🏥
Предположим, вы работаете в крупной медицинской компании, занимающейся обработкой результатов медицинских исследований пациентов. Ваша задача — разработать новую платформу для ведения электронных медицинских карт пациентов. Пользовательская база огромна — десятки миллионов человек. Основная цель системы заключается в следующем:

- Собирать подробную историю болезни пациента, включающую разнообразные медицинские данные: анализы крови, рентгеновские снимки, УЗИ, МРТ, ЭКГ и многие другие.
- Предоставлять врачам быстрый доступ ко всей истории болезней пациента
- Проводить регулярный анализ данных пациентов для выявления закономерностей заболеваний и рисков осложнений.
- Вести учёт лечения и назначаемых препаратов пациентам.
- Планировать профилактические мероприятия и диспансеризацию.

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

📝Ответ расскажу вечером

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

Реляционные или нет?

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

🟠 Реляционные

🔸Особенности

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

🔸 Преимущества

Строгая структура данных гарантирует ясность и предсказуемость.
Высокий уровень безопасности и устойчивости данных.

🔸Недостатки

Трудности с масштабированием для больших объемов данных.
Могут быть неэффективны для постоянно меняющейся структуры данных.
Сложность адаптации к изменениям структуры данных (необходимость миграции данных).

🔸Примеры ситуаций, когда предпочтительна реляционная база данных

Банковские системы: необходимость высокого уровня безопасности и согласованности данных.
Финансовая отчётность: требование точного соблюдения стандартов отчетности и соответствия стандартам регулирования.
CRM-системы: точные данные о клиентах и история взаимодействии необходимы для анализа и маркетинга.

🟠 NoSQL базы данных

🔸Особенности

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

🔸Преимущества

Гарантированная масштабируемость для больших объемов данных.
Легко адаптируются к изменению структуры данных.
Повышенная производительность для операций чтения и записи.
Лучшее соответствие современным задачам обработки больших данных и распределённых систем.

🔸Недостатки

Сложность выполнения сложных запросов и соединений.
Потенциальные риски нарушения целостности данных.

🔸Примеры ситуаций, когда предпочтительны NoSQL базы данных

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

❓Рассмотрим кейсы, в которых нужно выбрать тип бд.

🅰️ Онлайн-магазин книг

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

🅱️ Социальная сеть

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

Итог

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