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

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

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

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

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

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

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

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

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

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

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

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

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

Выбор СУБД

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

🕹 MySQL

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

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


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

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


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

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


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

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

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

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

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


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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

📖 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 (статус, оплачен или нет)

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

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

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

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

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

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

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

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

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

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

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

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

☂️ Вторая нормальная форма (2NF) ☂️

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

- BookTitle – название книги (ключ)
- DepartmentName – название отдела, где хранитс книга (история, художественная, компьютерная) (ключ)
- LocationShelf – номер стеллажа.

Атрибут LocationShelf зависит только от подразделения (DepartmentName), а от названия книги не зависит. Значит, нарушена 2NF, тк имеется частичная зависимость, а должна быть зависимость от обоих ключей.
Вопрос решается разделением одной таблицы на две:

📓Books
- BookId
- Title
- DepartmentId

🏢 Departments
- DepartmentId
- Name
- LocationShelf


☂️ Третья нормальная форма (3NF) ☂️
Исключение транзитивной зависимости атрибутов.

3NF требует отсутствия транзитивных зависимостей среди неключевых атрибутов. То есть, любой неключевой атрибут не должен зависеть от другого неключевого атрибута, кроме первичного ключа.
Всвязи с тем, что наши данные построены корректно с точки зрения 3 формы, возьмем пример:
Предположим, что информация о книге реализована так:
- ISBN – идентификатор книги
- Title – название книги
- Author – автор книги
- Reader - читатель

❓Проблемы данной структуры:

🔸 Ошибочная зависимость. Поле Reader зависит не только от уникального идентификатора книги (ISBN), но также косвенно от имени автора и названия книги. Это нарушение правил Третьей Нормальной Формы (3NF), так как возникают потенциальные аномалии модификации данных.

🔸 Избыточность данных. Повторяется одно и то же название книги и автор всякий раз, когда новый читатель берет книгу.

Для решения мы отделяем книг и читателей и создаем соединяющую таблицу «Выдача книг», как мы и сделали изначально.

На этом мы завершаем приведение к нормальным формам и переходим к физическому проектированию

🎲 Что делать на физическом проектировании? 🎲
В отличие от логического и концептуального уровней, физический уровень проектирования многоступенчатый и содержит несколько этапов внутри себя. Сначала мы перечислим основные из них, а затем будем смотреть, что из этого применимо к нашей «бибилиотечной» задаче

Шаги перехода к физическому проектированию:

✏️ Выбор СУБД: Определяемся с типом базы данных, которую будете использовать (MySQL, PostgreSQL, MongoDB и др.).

✏️ Определение структуры таблиц
- Какие поля будут присутствовать в каждой таблице?
- Каковы типы данных полей (строки, целые числа, даты)?

✏️ Настройка первичных ключей
- Каждое отношение должно иметь уникальный идентификатор (первичный ключ).

✏️ Создание внешних ключей
Нужно реализовать внешние ключи, обеспечивающие целостность данных. Внешний ключ ссылается на первичный ключ другой таблицы. Например, в таблице author_book внешний ключ ссылается на id автора (author_id) и id книги (book_id).

✏️ Индексация
Разобраться, есть ли необходимость в индексации и Определить индексированные поля , особенно те, по которым будут проводиться частые выборки. Индексы ускоряют выполнение SQL-запросов, связанных с поиском записей по значению ключа.

✏️ Обеспечение целостности данных:
Разобраться в необходимости использования триггеров и хранимых процедур для поддержания бизнес-правил и проверки данных на входе. Например, запрет на выдачу книги, если пользователь имеет штрафы.

✏️ Ограничения уровня БД
Добавить необходимые ограничения на уровне схемы (ограничения NOT NULL, UNIQUE, CHECK-контракты и другие правила, определяющие допустимые значения).

✏️ Оптимизация производительности
Решить, какие методы оптимизаций потребуются: разделение таблиц, горизонтальное масштабирование, репликация, шардинг и тд, в зависимости от предполагаемых нагрузок.

✏️ Шифрование чувствительной информации:
Если база данных содержит персональные данные читателей или иную конфиденциальную информацию, важно предусмотреть механизмы шифрования (либо на уровне самой базы данных, либо на уровне приложения).

📍Чекл-лист ключевых решений на этапе физического проектирования:

🟢 Создание физических схем данных (таблиц, индексов, представлений);
🟢 Настройка правил целостности и каскадных действий (ON DELETE CASCADE, ON UPDATE CASCADE);
🟢 Организация резервного копирования и восстановления данных;
🟢 Установка политик паролей и механизмов аутентификации пользователей;
🟢 Планирование инфраструктуры (расположение сервера, сетевые настройки, безопасность доступа);
🟢 Конфигурация базы данных для повышения производительности (параметры буферного кеша, временные зоны, настройка памяти).