Роль базы данных в организации
Вступление
База данных в учебнике часто выглядит как набор таблиц и упражнений на JOIN. В компании — это инфраструктурный актив — через неё проходят заказы, зарплаты, медицинские карты, логи, отчёты для регулятора. От качества схемы и дисциплины эксплуатации зависят скорость сайта и доверие к цифрам в решениях руководства.
Эта глава связывает технические темы раздела Основы баз данных с организационным контекстом:
- зачем компании одна управляемая СУБД вместо десятка Excel-файлов;
- как схема данных растёт вместе с продуктом (от идеи до эксплуатации);
- кто принимает решения про поля, бэкапы и доступ;
- где чаще ломается процесс, даже при исправном PostgreSQL.
Что вы унесёте после чтения: сможете объяснить коллеге разницу между аналитиком и DBA, назвать артефакты этапа "логическая модель", понять, зачем бизнесу цифры RPO/RTO, и увидеть типичные человеческие ошибки (DELETE без WHERE в prod).
Подробное проектирование схем — в Проектировании баз данных. Корпоративные правила владения данными — в Data Governance.
Термины, которые встретятся в главе
| Термин | Простыми словами |
|---|---|
| СУБД | Программа-сервер (PostgreSQL, MySQL…), которая хранит данные, принимает SQL, гарантирует транзакции. |
| Схема | Описание таблиц, столбцов, ключей и ограничений — "чертёж" данных. |
| Миграция | Версионируемое изменение схемы (ALTER TABLE, новые индексы) — как коммит в git, но для БД. |
| DDL | Команды определения структуры: CREATE, ALTER, DROP. |
| ETL | Extract–Transform–Load: выгрузить из старой системы, преобразовать, загрузить в новую. |
| SLA | Договорённость об уровне сервиса: uptime, время восстановления. |
| Governance | Правила "чьи данные, кто может, сколько хранить" — см. Управление данными - Data Governance. |
Центральная БД организации - единый источник данных
Одно место правды
Без СУБД каждое приложение копирует "свой" Excel, JSON или файл. Возникают расхождения — в CRM одна выручка, в бухгалтерии — другая, в отчёте директора — третья.
Пример из жизни. Отдел продаж ведёт клиентов в CRM. Склад списывает остатки в отдельной таблице Excel. Бухгалтерия считает выручку в 1С. Вопрос "сколько мы продали вчера?" превращается в три совещания. Центральная БД (или согласованный data warehouse) задаёт ответ один раз — таблица orders с первичным ключом, суммой, датой, статусом; отчёты читают её (или витрину, построенную из неё).
Реляционная БД даёт общий контракт:
- сущности — таблицы
customers,orders; - ключи —
id, внешние связиorder.customer_id → customers.id; - ограничения — "сумма заказа ≥ 0", "статус только из справочника";
- транзакции — списание со склада и создание заказа либо оба успешны, либо оба откатываются.
Одновременный доступ без "каши в файлах"
См. Знакомство с базами данных — транзакции, блокировки, MVCC — Конкурентный доступ. Файловое хранение этого не гарантирует — Эволюция хранения.
Безопасность и аудит
Кто что читал и менял — через учётные записи, роли, журналы. В администрировании разобраны сеть, привилегии и аудит.
Долговечность
Данные переживают перезапуск приложения и сервера — при правильных WAL и бэкапах: Восстановление после сбоя, резервное копирование.
Роли вокруг данных (кто за что)
| Роль | Фокус | Типичные задачи |
|---|---|---|
| Владелец данных (Data Owner) | Бизнес-смысл, допустимость использования | "Можно ли хранить это поле?", срок хранения, GDPR/ФЗ‑152 |
| Аналитик / бизнес-аналитик | Требования, ER на уровне предметной области | Сущности, связи, отчёты — ER |
| Разработчик | Приложение + схема в коде (миграции) | SQL, ORM, API |
| Архитектор | Выбор СУБД, границы сервисов, нагрузка | SQL vs NoSQL, шардирование, design/116 |
| DBA / инженер данных | Эксплуатация сервера БД | Установка, бэкапы, мониторинг, 3-08 |
| Специалист по безопасности | Доступ, шифрование, реагирование | Совместно с DBA |
Разбор ролей на одном примере — поле orders.status:
| Роль | Вопрос, который задаёт | Типичное решение |
|---|---|---|
| Владелец данных | "Можно ли статус cancelled через год после доставки?" | Бизнес-правило + политика хранения |
| Аналитик | "Какие статусы бывают и как связаны с оплатой?" | ER, глоссарий в Confluence |
| Разработчик | "Как хранить в БД: enum, справочник order_statuses?" | Миграция, FK на справочник |
| DBA | "Нужен ли индекс по (status, created_at) для отчётов?" | CREATE INDEX, мониторинг |
| Безопасность | "Кто видит статусы с персональными данными?" | Роль readonly_analyst без PII |
Владелец данных отвечает за смысл ("что такое активный клиент"). DBA — за доступность сервера (диск, бэкап, патч). Это разные люди с разными KPI; путать их — частая организационная ошибка.
В маленькой команде один человек совмещает три шляпы — конфликты интересов остаются: разработчик хочет быструю фичу, DBA — стабильную ночь без аварий. Governance (Управление данными - Data Governance) задаёт явные правила: кто утверждает ALTER в пятницу вечером.
Жизненный цикл информационной системы и базы данных
Жизненный цикл ПО (планирование → анализ → проектирование → реализация → тестирование → внедрение → эксплуатация → вывод из эксплуатации) накладывается на жизненный цикл модели данных.
Концептуальный уровень
Что: сущности и связи предметной области без PostgreSQL/MongoDB. Инструмент — ER / IDEF1X.
Кто: аналитик, архитектор, бизнес.
Артефакт: ER-диаграмма, глоссарий.
В энциклопедии: Entity Relationship, раздел "Уровни моделирования" в design/116.
Логический уровень
Что: таблицы, ключи, нормальные формы, ограничения — ещё можно перенести в другую СУБД.
Артефакт: логическая схема, DDL-черновик.
В энциклопедии: Реляционная модель, Нормализация.
Физический уровень
Что: индексы, партиции, типы, размещение на диске, параметры сервера.
Артефакт: миграции, runbook DBA.
В энциклопедии: Внутреннее устройство баз данных, Теоретические основы реляционных данных, Оптимизация SQL-запросов.
Выбор программного обеспечения СУБД
Решение принимают до написания сотен миграций: смена PostgreSQL на Oracle "по ходу" обходится дороже, чем недельный анализ на старте. Один продукт редко закрывает все задачи — часто реляционная БД учёта сочетается с Redis и поисковым движком (четыре типа БД).
| Критерий | Вопросы к команде и бизнесу | На что смотреть |
|---|---|---|
| Модель данных | Строгая схема, транзакции, отчёты с JOIN? | Реляционная SQL; иначе — NoSQL |
| Нагрузка | Чтение, запись, смешанная OLTP/аналитика? | Индексы, реплики чтения, DWH отдельно |
| Объём и рост | Гигабайты сегодня, терабайты через год? | Партиции, шардинг, managed scale |
| Доступность | Допустимый простой, RPO/RTO? | HA, репликация, multi-AZ — RPO и RTO |
| Лицензия и бюджет | CapEx лицензий Oracle или OpEx облака? | PostgreSQL/MIT, GPL MySQL, платные Enterprise |
| Команда | Есть DBA, только разработчики? | Документация, сообщество, managed-сервис |
| Регуляторика | Данные в РФ/ЕС, шифрование, аудит? | Регион облака, TDE, журналы доступа |
| Интеграции | .NET, Java, 1С, BI? | Драйверы, T-SQL/PL/pgSQL, коннекторы |
| Вендор и выход | Что при уходе с платформы? | Экспорт (pg_dump, BACPAC), открытые форматы |
Технические детали установки, лицензий по ядрам и настройки "железа" — в управлении РСУБД (раздел "Выбор платформы"). Инструменты DBA — там же.
Эксплуатация и эволюция
Схема не замораживается — новые поля, справочники, отчётные витрины. Стратегии:
- миграции (Flyway, Liquibase, Alembic) — версионируемый DDL;
- Expand–Contract — сначала добавить столбец, потом переключить приложение, потом убрать старое;
- денормализация под отчёты — осознанно, см. Нормализация данных.
Чек-лист перед CREATE TABLE — в design/116.
Артефакты по этапам (что должно появиться на выходе)
| Этап ИС / данных | Артефакт | Кто владелец | Проверка качества |
|---|---|---|---|
| Анализ требований | Глоссарий терминов, бизнес-правила | Аналитик + владелец данных | Нет синонимов "клиент/покупатель/user" |
| Концептуальная модель | ER-диаграмма, кардинальности | Аналитик | Каждая сущность — существительное |
| Логическая модель | Таблицы, PK/FK, 3НФ-обоснование | Архитектор / ведущий разработчик | Нет транзитивных дублей |
| Физическая модель | DDL-миграции, индексы, партиции | Разработчик + DBA review | План EXPLAIN на горячие запросы |
| Внедрение | Runbook: бэкап, restore drill, мониторинг | DBA | Успешный тест восстановления |
| Эксплуатация | Регламент изменения схемы (change window) | DBA + релиз-менеджер | Миграция откатывается |
Без артефакта этап "формально есть", а риски (два разных справочника статусов, "временная" таблица на годы) остаются.
Пример сквозного потока — интернет-магазин
- Бизнес: "Нужен учёт заказов и остатков на складе".
- Концепт: сущности Покупатель, Заказ, Строка заказа, Товар, Склад.
- Логика:
customers,orders,order_items,products,inventoryс FK иCHECK (quantity > 0). - Физика: индекс на
orders(customer_id, created_at), партиционирование архива заказов по году. - Приложение: API + миграции Flyway; списание склада в транзакции — см. Конкурентный доступ.
- Эксплуатация: nightly snapshot, PITR 7 дней, алерт на
replication lagиdisk 85%.
Так связь модели на курсе и эксплуатации в проде становится видимой, а не только набором отдельных статей.
RACI — кто за что отвечает
| Действие | Владелец данных | Аналитик | Разработчик | DBA | Безопасность |
|---|---|---|---|---|---|
| Утвердить смысл поля "статус заказа" | A | R | C | I | I |
| Спроектировать ER | I | A/R | C | C | I |
| Написать миграцию DDL | I | C | A/R | C | I |
| Выбрать размер инстанса / HA | I | I | C | A/R | C |
| Открыть порт БД в интернет | I | I | I | C | A |
A — accountable (отвечает за результат), R — responsible (делает руками), C/I — consult / inform.
Внедрение базы данных в организации
Внедрение — не только apt install postgresql. Обычно включает:
apt install postgresql
- Выбор платформы — on-prem, VM, Kubernetes, managed cloud — Администрирование в облаке.
- Окружения — dev / test / staging / prod с изоляцией и разными секретами.
- Миграция данных — из legacy (Excel, старая СУБД, 1С) — ETL, сверка, параллельный период.
- Обучение — разработчики не пишут
DELETEбезWHEREв prod; аналитики знают, где "официальная" витрина. - Регламенты — бэкап, восстановление (учебные drill), окно обслуживания, эскалация при инциденте.
Критерий успеха: бизнес доверяет цифрам и знает, кого звать при потере данных.
Миграция с legacy — типовые стратегии
| Стратегия | Суть | Когда подходит |
|---|---|---|
| Big bang | В выходные переключили всё на новую БД | Малый объём, короткое окно простоя |
| Параллельный период | Старая и новая система пишутся; сверка отчётами | Нельзя долго "заморозить" бизнес |
| Постепенный срез | По доменам: сначала справочники, потом заказы | Крупный монолит, микросервисы по очереди |
| Read replica / CDC | Поток изменений в новое хранилище (Debezium и т.д.) | Минимизировать ручной ETL |
На этапе миграции особенно важны сверка (суммы, количества строк, контрольные hash) и откатный план — не только "как накатить вперёд".
RPO и RTO — язык для разговора с бизнесом
Два английских термина, которые переводят "технику бэкапов" на язык денег и риска:
| Термин | Расшифровка | Вопрос бизнеса | Пример ответа |
|---|---|---|---|
| RPO | Recovery Point Objective | Сколько последних данных можно потерять? | "Не больше 15 минут заказов" → частый snapshot + архив WAL |
| RTO | Recovery Time Objective | Сколько простоя допустимо? | "Магазин снова принимает заказы за 2 часа" → отработанный runbook, standby |
Сценарий для новичка. В 14:00 упал дата-центр. Последний успешный бэкап — 13:50. RPO = 10 минут формально нарушен (потеряли 10 минут заказов). Команда поднимает standby к 15:30 — RTO = 1,5 часа. Бизнес заранее согласовал: потеря 10 минут заказов — терпимо, простой больше 4 часов — катастрофа. Отсюда выбор — multi-AZ, PITR, drill раз в квартал.
Цепочка в энциклопедии: восстановление после сбоя (как СУБД переживает падение процесса) → бэкапы (как вернуть удалённую таблицу) → облако (кто крутит snapshot в RDS).
Expand–Contract — смена схемы без "ломаем всех сразу"
Когда меняется структура, а старые сервисы ещё работают, используют Expand–Contract (расширить → сжать):
- Expand: добавить новый столбец
first_name, не трогая старыйfull_name. - Переключение: новые сервисы пишут в оба поля или только в новые; старые читают
VIEWсfull_name(см. правило 9 в главе про Кодда). - Contract: удалить
full_name, когда последний клиент обновлён.
Так снижают риск "вышли в prod с ALTER DROP COLUMN — упали пять микросервисов".
Человеческий фактор в среде БД
Техника редко падает "сама" — чаще цепочка решений людей.
| Риск | Пример | Профилактика |
|---|---|---|
| Ошибка в prod | UPDATE users SET role='admin' без WHERE | Отдельные роли, запрет DDL в prod из IDE, review миграций |
| Обход СУБД | Правка файлов данных на диске | Правило 12 Кодда, только штатные утилиты |
| "Временная" денормализация | Дубли без синхронизации | Документировать, триггеры/ETL, срок жизни |
| Секреты в репозитории | postgres://user:pass@prod в .env в git | Vault, CI-секреты |
| Нет проверки бэкапа | Бэкап есть, восстановление никогда не пробовали | Ежеквартальный drill — 3-08/1 |
| Конфликт команд | DBA не в курсе релиза с тяжёлой миграцией | Change management, окно, откат |
В управлении РСУБД прямо перечислены угрозы вроде человеческой ошибки и DROP DATABASE — это типовой инцидент.
Связь с критериями "хорошей" реляционной СУБД
Когда организация требует от поставщика "реляционную СУБД", имеется в виду не только SQL, но и независимость, каталог, целостность — см. Двенадцать правил Кодда. Это аргументы для архитектурных комитетов и тендеров, не только для экзамена.
Контрольные вопросы
- Чем владелец данных отличается от DBA?
- На каком уровне моделирования появляется ER-диаграмма — концептуальном, логическом или физическом?
- Почему внедрение БД не заканчивается установкой сервера?
- Приведите два примера человеческого фактора, которые не исправляет индекс.
- Чем концептуальная модель отличается от логической на выходных артефактах?
- Что такое RPO и RTO — и кто их должен согласовать с бизнесом?
- Назовите одну стратегию миграции с legacy без "big bang".
См. также
- Управление РСУБД — выбор платформы и инструменты
- Data Governance
- Проектирование баз данных
- СУБД
- Администрирование в облаке