Что такое база данных?

Что такое база данных?

Определение для Business Analyst

Хотя это базовый вопрос, я объясню его так, как я объясняю коллегам и stakeholders. База данных — это организованное хранилище информации, которое позволяет быстро искать, добавлять, изменять и удалять данные.

Простое объяснение

Аналогия: Если Excel файл — это один список, то база данных — это несколько связанных списков с быстрым поиском и правилами.

Excel:
Один лист с 10,000 строк товаров
Поиск: Ctrl+F (медленно)
Лимит: ~1 млн строк
Опасность: легко перепутать данные

База данных:
Несколько таблиц (товары, категории, цены)
Поиск: индексы (быстро, даже на 1 млн строк)
Лимит: миллиарды строк
Безопасность: ограничения и проверки

Как я работаю с базами данных как BA

1. Понимание структуры (Data Model)

Я не пишу SQL, но я должен понимать:

• Какие таблицы есть (Users, Orders, Products)
• Какие связи между ними (1-to-many, many-to-many)
• Какие данные в каждой таблице

Пример:

Users таблица:
- id (уникальный номер)
- name (имя)
- email (почта)
- created_at (когда зарегистрировался)

Orders таблица:
- id
- user_id (ссылка на Users)
- product_id (ссылка на Products)
- quantity (количество)
- price (цена)
- created_at

2. Требования к данным

Когда я пишу User Story, я определяю:

• Какие данные нужно сохранять
• Какие данные нужно искать
• Как долго хранить
• Какие правила проверки (validation)

Пример:

US-050: Customer profile

Данные, которые нужно сохранять:
- Full name (обязательно, макс 100 символов)
- Email (обязательно, уникальная, валидный формат)
- Phone (опционально, макс 15 символов)
- Address (опционально, макс 500 символов)
- Birth date (опционально, должен быть 18+)

Какие правила:
- Email не может быть изменен после регистрации
- Телефон может быть не более одного на пользователя
- Адрес может быть несколько (доставка vs платеж)

3. Запросы к данным

Когда я создаю требования, я думаю:

• Что нужно найти (фильтры)
• Как быстро это должно работать
• Сколько данных вернуть

Пример:

US-051: Search customers

"Как админ, я хочу найти клиента по email,
чтобы получить его заказы и контакты"

Для этого нужна база данных, где:
- Можно быстро найти по email (индекс нужен)
- Можно получить все заказы этого клиента
- Результат вернуть за < 1 сек (даже 1 млн пользователей)

Типы баз данных, которые я встречаю

1. Relational (SQL) — самая популярная

Примеры: PostgreSQL, MySQL, SQL Server

Характеристики:

• Таблицы с связями
• ACID гарантии (data consistency)
• Хорошо для business data

2. NoSQL (Document) — для большого объема

Примеры: MongoDB, Firebase

Характеристики:

• Документы (как JSON)
• Гибкая структура
• Масштабируется горизонтально
• Для logs, events, analytics

3. TimeSeries — для исторических данных

Примеры: InfluxDB, Prometheus

Характеристики:

• Отслеживание изменений во времени
• Для метрик и аналитики
• Компрессия данных

4. Graph — для связей

Примеры: Neo4j

Характеристики:

• Узлы и связи между ними
• Для социальных сетей, рекомендаций
• Быстрые запросы на взаимодействия

Как я описываю data requirements

В User Story я указываю:

US-100: Store customer preferences

Данные для сохранения:
- customer_id (ссылка на Customer)
- theme (dark/light) - строка
- language (en/ru/fr) - строка
- notifications_enabled (да/нет) - boolean
- updated_at (дата обновления) - datetime

Данные для поиска:
- Найти все customer_id where theme='dark' (для статистики)
- Быстро получить preferences для одного customer (< 100ms)

Данные для удаления:
- Удалять preferences при удалении customer (каскадное удаление)

Правила:
- theme может быть только 'dark' или 'light'
- language из предопределенного списка
- updated_at устанавливается автоматически

Примеры задач, которые я ставлю перед разработчиком

Task 1: Создать таблицу

Перед разработкой фичи "создать заказ"
Разработчику нужна таблица Orders:
- id (primary key)
- user_id (foreign key to Users)
- status (enum: pending, paid, shipped, delivered, cancelled)
- total_price (decimal)
- created_at (timestamp)
- updated_at (timestamp)
- notes (text, optional)

Индексы нужны для:
- Быстрого поиска по user_id
- Быстрого поиска по status

Task 2: Создать запрос

Для отчета "Продажи за месяц"
Нужно получить из БД:
- Сумму по month
- Групировку по product_category
- Только status='paid'

Текущие требования:
- Результат < 1 сек (даже на 10 млн заказов)
- Обновляется каждый час

Task 3: Обновить правила

Когда требования изменились:
"Теперь можно удалить заказ только в течение 24 часов"

В БД это значит:
- Добавить constraint на DELETE
- Или добавить флаг is_deleted с timestamp
- Синхронизировать с приложением

Как я проверяю database design

Когда tech lead показывает мне ERD (диаграмму БД), я проверяю:

1. Данные полные?

• Все ли данные из User Story сохраняются?
• Есть ли все поля, которые нам нужны?

2. Оптимально ли спроектирована?

• Нет ли дублирования данных (DRY принцип)
• Есть ли нужные индексы
• Нет ли слишком много JOIN операций

3. Безопасна ли?

• Какие ограничения на удаление (cascade, restrict)
• Есть ли audit trail (кто, когда изменил)
• Есть ли шифрование для чувствительных данных

4. Производительна ли?

• Сможет ли справиться с ростом (миллионы заказов?)
• Какой размер таблиц в peak load
• Нужна ли архивизация старых данных

Типичные вопросы, которые я задаю разработчику

1. "Как долго мы храним старые заказы?"
   (помогает определить архивизацию)

2. "Какой объем данных будет в этой таблице?"
   (помогает выбрать индексы)

3. "Как быстро нужно искать по этому полю?"
   (помогает понять нужен ли индекс)

4. "Что делать если пользователь удалится?"
   (помогает определить referential integrity)

5. "Есть ли compliance требования по хранению данных?"
   (GDPR, PCI-DSS требуют deletion)

Связь между требованиями и БД

Примеры как User Story влияет на БД:

US-001: Customer can filter by price
→ Нужно создать индекс на price column (иначе медленный поиск)

US-002: Customer can delete account
→ Нужно продумать удаление cascade (заказы, preferences, etc)

US-003: Admin views sales reports
→ Может быть, нужно создать materialized view (для speed)

US-004: System sends email about promotions
→ Нужно хранить email subscription preferences

Мой процесс работы с БД

Шаг 1: Требования (User Story)

Что пользователь хочет делать?
Какие данные нужны?

Шаг 2: Design (с tech lead)

Как это спроектировать в БД?
Какие таблицы нужны?
Какие индексы?

Шаг 3: Implementation

Разработчик создает миграцию (SQL script)
Тестируем на staging

Шаг 4: Validation

Проверяю, что все требования выполнены
Проверяю performance

Типичные ошибки

❌ Я забыл указать, какие данные нужно сохранять

• Разработчик создает БД, потом выясняется, что чего-то не хватает

❌ Я не подумал про performance

• "Нужно найти все заказы за месяц"
• На миллионе заказов это займет 10 минут
• Нужны индексы или кеширование

❌ Я не подумал про удаление

• Когда пользователь удаляет аккаунт, что удаляется?
• Заказы? Отзывы? Комментарии?

✅ Я думаю о БД при написании требований

• Какие данные нужны
• Как долго хранить
• Как быстро искать
• Что удаляется

Итог для BA

Я должен знать: ✅ Что такое таблицы и связи ✅ Как данные организованы ✅ Как быстро искать данные ✅ Какие ограничения и правила ✅ Что происходит при удалении

Я НЕ должен: ❌ Писать SQL (это работа разработчика) ❌ Оптимизировать запросы ❌ Управлять миграциями

Но я должен: ✅ Знать, как мой requirements влияют на БД ✅ Общаться с tech lead о data design ✅ Проверять, что все требования покрыты данными ✅ Думать про масштабируемость и performance