Перейти к основному содержимому

Основы проектирования БД

Методы проектирования БД​

1. Нисходящее проектирование (Top-Down)​

  • Проектирование начинается "сверху" — с анализа общих бизнес-требований и создания абстрактной концептуальной модели, затем детализируется до логической и физической модели.
  • → Когда использовать: Для новых, хорошо определенных проектов. Этот подход рассмотрим подробнее в статье ниже.

2. Восходящее (Bottom-Up)​

  • Проектирование начинается "снизу" — с анализа отдельных отчетов, форм, документов и их атрибутов. Атрибуты группируются в структуры (отношения), которые затем объединяются в общую схему БД.
  • → при интеграции унаследованных систем, проектировании ХД (Data Warehouse) или когда есть документы и отчеты.

3. Внутреннее (Inside-Out)э​

Частный случай восходящего подхода

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

4. Смешанный подход​

  • Комбинация нисходящего и восходящего методов. Верхний уровень архитектуры создается нисходящим методом, а затем отдельные модули детализируются восходящим.
  • → во многих проектах средней и высокой сложности.

Какой метод выбрать?

  • Новый проект с ясными целями? → Нисходящий.
  • Интеграция или анализ существующих данных? → Восходящий.
  • Нужен быстрый прототип? → Внутренний.
  • Большой, сложный проект? → Смешанный.

Проектирование БД​

Нисходящий подход

Процесс проектирования можно разделить на три шага::

  1. Концептуальное проектирование — анализ и описание бизнес-сущностей без привязки к технологиям.
  2. Логическое проектирование — преобразование бизнес-модели в структуру таблиц, ключей и связей.
  3. Физическое проектирование — реализация модели в конкретной СУБД с учетом особенностей хранения, типов данных, индексов и оптимизации.

Между этими этапами используется ER-диаграмма — инструмент визуализации.

1. Концептуальная модель​

Задача: понять и описать какие данные нужны системе и как они связаны между собой. Не решается, в какой СУБД будет храниться информация и как будут называться таблицы.

Основные шаги​

  • Определить сущности: ключевые объекты, информацию о которых будет храниться (например, «Пользователь», «Заказ», «Товар»).
  • Описать связи между сущностями, т.е как сущности взаимодействуют друг с другом (например, «Пользователь оформляет Заказ»).
  • Выделить атрибуты сущностей. Это характеристики, которые описывают каждую сущность (например, «ФИО» у пользователя, «Цена» у товара).
  • Зафиксировать правила предметной области (например, заказ всегда связан хотя бы с одним товаром).

ER-диаграмма​

Чтобы визуализировать концептуальную модель, используют ER-диаграмму (Entity–Relationship Diagram). Это графическое представление сущностей и связей.

ERD может быть простой (несколько сущностей и связей) или детализированной (с атрибутами и ограничениями). Главное — диаграмма должна помочь быстро увидеть, какие объекты важны и как они соотносятся друг с другом.

Подробнее про ER диаграмму

2. Логическая​

Создание реляционной схемы. ER-модель преобразуется в формальную схему, готовую для реализации в реляционной СУБД (распространенный тип БД).

Основные шаги​

  1. Создать таблицы по сущностям. Например, сущность «Пользователь» превращается в таблицу users.

  2. Определить атрибуты как столбцы таблиц. У «Пользователя» будут поля: id, name, email.

  3. Задать ключи.

    • Первичный ключ (id) для уникальной идентификации строки.
    • Внешние ключи для связи между таблицами.

  4. Нормализовать таблицы.

    • Убрать повторы и избыточные данные.
    • Проверить соответствие нормальным формам (1НФ, 2НФ, 3НФ).
    • Например, если в таблицу «Заказ» включить название товара, это приведет к дублированию. Решение: выделить отдельную таблицу «Товар» и связать через «Заказ–Товар».

  5. Определить индексы.

    • Для часто используемых ключей.
    • Для ускорения поиска по колонкам.

Пример​

  • Таблица users: id, name, email
  • Таблица orders: id, user_id, date
  • Таблица products: id, name, price
  • Таблица order_products: order_id, product_id (связь «многие-ко-многим»)

Связь концептуальной и логической модели​

Концептуальная модель отвечает на вопрос «что хранить», логическая — «как хранить».

  • Сущность → Таблица
  • Атрибут → Поле таблицы
  • Связь → Внешний ключ или отдельная таблица для связи «многие-ко-многим»

Пример:

  • Сущность «Заказ» превратилась в таблицу orders.
  • Связь «Заказ–Товар» реализована через промежуточную таблицу order_products.

3. Физическая​

Модель адаптируется под конкретную СУБД:

  • Выбираются типы данных (VARCHAR, INTEGER, DATE).
  • Настраиваются индексы, триггеры, процедуры.
  • Проектируется стратегия хранения больших данных (шардинг, партиционирование).
  • Учитываются ограничения конкретной СУБД (PostgreSQL, MySQL, Oracle и т. д.).

Краткий пример трех моделей​

Предметная область: интернет-магазин.

  1. Концептуальное

    • Сущности: Пользователь, Заказ, Товар
    • Связи: Пользователь оформляет Заказ, Заказ содержит Товар
    • Атрибуты: у Пользователя — Имя, Email; у Заказа — Дата; у Товара — Название, Цена

  2. Логическое

    • Таблицы: users, orders, products, order_products
    • Ключи: id в каждой таблице, user_id в orders, order_id и product_id в order_products
    • Нормализация: товары вынесены в отдельную таблицу, связь заказ–товар через промежуточную таблицу

  3. Физическое

    • В СУБД PostgreSQL создаются таблицы
    • Типы данных: id — SERIAL, name — VARCHAR(100), price — NUMERIC(10,2), date — DATE
    • Индексы: по email в users, по user_id в orders

DFD в проектировании БД​

DFD (Data Flow Diagram, диаграмма потоков данных) используется для описания как информация проходит через систему:

  • откуда приходят данные
  • какие процессы их обрабатывают
  • какие внешние участники взаимодействуют с системой
  • в какие хранилища данные попадают

→ ER-диаграммы описывают структуру данных.
→ а DFD - движение информации и процессах обработки.
DFD логически предшествует построению концептуальной и логической моделей БД DFD — не инструмент проектирования БД напрямую, логически предшествует построению концептуальной и логической моделей БД.

Помогает в проектировании БД выявить:

  • сущности и хранилища: в DFD есть «Data Store» — хранилища данных. Это кандидаты на таблицы / сущности в БД.
  • атрибуты: потоки показывают, какие поля передаются между процессами.
  • связи: если один процесс одновременно использует данные из двух хранилищ, вероятная связь между таблицами.

Пример​

В интернет-магазине процесс «Оформить заказ» получает данные от внешнего участника Пользователь.
Данные уходят в хранилище Заказы и Товары в заказе. Процесс Управление каталогом работает с хранилищем Товары.

→ в БД нужны сущности: Пользователь, Заказ, Товар, и таблица-связка Заказ–Товар.

Материалы​

  1. Как работают базы данных в IT: разбор на примерах
  2. Базы данных для системного аналитика. Краткий обзор на практике
  3. Основы правил проектирования базы данных
  4. Основы проектирования баз данных
  5. Проектирование реляционных баз данных: основные принципы
  6. Основы проектирования баз данных (Методичка с понятной теорией)
  7. Советы по изучению проектирования баз данных/схем
  8. Пример проектирования базы данных MySQL
  9. DFD (Data Flow Diagram) Диаграммы — зачем они нужны и какие бывают
  10. Использование DFD: как описать движение данных в бизнес-процессах
  11. Использование DFD: как описать движение данных в бизнес-процессах (расширенная версия)
  12. DFD: примеры и правила построения диаграмм потоков данных
  13. Диаграмма потоков данных (DFD) для чайников: что это такое, как сделать и какой бывает
  14. Анализ методов проектирования БД
  15. Методология проектирования баз данных для современного ПО

Видео​

  1. Проектирование БД архитектуры на практике / eFreelancingTeachers
  2. Проектирование баз данных в highload проектах // Демо-занятие курса «Highload Architect»
  3. Мастер-класс по проектированию БД // «PostgreSQL для администраторов баз данных и разработчиков»
  4. Проектирование баз данных за 40 минут. Практика
  5. Цикл "Штурмуем базы данных" (6 встреч)
  6. Анна Вичугова . Практическое использование DFD: как описать движение данных в бизнес-процессах?

Бесплатные курсы​

  1. Хекслет: основы реляционных баз данных
  2. «Основы технологий баз данных» — университетский курс на примере PostgreSQL

Книги​

  1. Основы баз данных (учебное пособие) - Кузнецов С. Д.
  2. Путеводитель по базам данных - Владимир Комаров
  3. Базы данных. Инжиниринг надежности - Кэмпбелл Лейн, Мейджорс Черити
  4. Проектирование и реализация систем управления базами данных - Эдвард Сьоре
  5. Основы технологий баз данных: учебное пособие - Новиков Б. А. и др.