Роль базы данных в организации
Вступление
База данных в учебнике часто выглядит как набор таблиц и упражнений на 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 | Правила «чьи данные, кто может, сколько хранить» — см. 111. |
Центральная БД организации - единый источник данных
Одно место правды
Без СУБД каждое приложение копирует «свой» 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 (111) задаёт явные правила: кто утверждает ALTER в пятницу вечером.
Жизненный цикл информационной системы и базы данных
Жизненный цикл ПО (планирование → анализ → проектирование → реализация → тестирование → внедрение → эксплуатация → вывод из эксплуатации) накладывается на жизненный цикл модели данных.
Концептуальный уровень
Что: сущности и связи предметной области без PostgreSQL/MongoDB. Инструмент — ER / IDEF1X.
Кто: аналитик, архитектор, бизнес.
Артефакт: ER-диаграмма, глоссарий.
В энциклопедии: Entity Relationship, раздел «Уровни моделирования» в design/116.
Логический уровень
Что: таблицы, ключи, нормальные формы, ограничения — ещё можно перенести в другую СУБД.
Артефакт: логическая схема, DDL-черновик.
В энциклопедии: Реляционная модель, Нормализация.
Физический уровень
Что: индексы, партиции, типы, размещение на диске, параметры сервера.
Артефакт: миграции, runbook DBA.
В энциклопедии: 3.md, 4.md, 881.
Эксплуатация и эволюция
Схема не замораживается: новые поля, справочники, отчётные витрины. Стратегии:
- миграции (Flyway, Liquibase, Alembic) — версионируемый DDL;
- Expand–Contract — сначала добавить столбец, потом переключить приложение, потом убрать старое;
- денормализация под отчёты — осознанно, см. 104.
Чек-лист перед 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. Обычно включает:
- Выбор платформы — 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».
См. также
См. также
Другие статьи этого же раздела в боковом меню (как на странице «О разделе»). База данных и СУБД, схемы данных, реляционная и нереляционная модели — вводная глава с разбором терминов relation и relationship. ERD (Entity-Relationship Diagram) — это визуальное представление структуры базы данных. Диаграмма сущность-связь показывает сущности, их атрибуты и отношения между ними. Data governance - роли, правила и процессы, чтобы данные были учтены, защищены и использовались согласованно в организации. Совокупность программных и лингвистических средств, обеспечивающих управление созданием и использованием баз данных. База данных - это ящик с данными, который лежит в архиве - хранилище. СУБД как программный комплекс - хранение, извлечение и изменение данных с гарантиями целостности и безопасности в реляционной модели. Критерии «настоящей» реляционной СУБД по Эдгару Кодду — что означает каждое правило и насколько современный SQL им соответствует. Параллельные транзакции — блокировки, MVCC, упорядочение по меткам времени и оптимистичный контроль; когда какой подход выбирать. WAL, контрольные точки, redo и undo — как СУБД переживает обрыв питания и чем это отличается от резервного копирования администратора. Краткие итоги раздела «Основы баз данных». Чек-лист раздела Основы баз данных — вопросы для самопроверки в энциклопедии Вселенная IT.Знакомство с базами данных
Entity Relationship
Управление данными - Data Governance
Системы управления базами данных (СУБД)
Внутреннее устройство баз данных
Теоретические основы реляционных данных
Двенадцать правил Кодда
Конкурентный доступ к данным
Восстановление после сбоя
Итоги
Чек-лист самопроверки