Основы проектирования структуры базы данных: гайд

Основы проектирования структуры базы данных

От концепции до ER-диаграммы: пошаговое руководство для начинающих

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

Структура (или схема) БД — это «чертеж» на котором строится вся система хранения информации. <br><br>Подобно тому, как архитектор планирует комнаты перед постройкой дома, разработчик определяет таблицы, поля и связи перед написанием кода.<br><br><b>Ключевые цели:</b><br>• Целостность данных<br>• Отсутствие дубликатов<br>• Скорость доступа

Подходы: SQL vs NoSQL

Реляционные (SQL)

• Строгая структура (Таблицы)<br>• Четкие связи (Relations)<br>• Идеально для финансовых систем, CRM, ERP<br>• Примеры: PostgreSQL, MySQL

Документные (NoSQL)

• Гибкая схема (JSON/BSON)<br>• Данные могут меняться динамически<br>• Идеально для каталогов, контента, больших данных<br>• Примеры: MongoDB, CouchDB

ER-модель: Основные понятия

Сущность (Entity)

Объект реального мира, о котором мы храним данные. В SQL это становится Таблицей.<br><i>Пример: Студент, Книга, Заказ.</i>

Атрибут (Attribute)

Свойство или характеристика сущности. В SQL это Колонка таблицы.<br><i>Пример: Имя, Email, Год рождения.</i>

Типы связей (Relationships)

Один к Одному (1:1)

Одна запись в таблице A соответствует ровно одной записи в таблице B.<br><br><i>Пример: Гражданин — Паспорт.</i>

Один ко Многим (1:N)

Самая частая связь. Одна запись в A связана с несколькими в B.<br><br><i>Пример: Автор — Книги.</i>

Многие ко Многим (N:M)

Множество записей A связано с множеством записей B. Требует промежуточной таблицы.<br><br><i>Пример: Студенты — Курсы.</i>

Ключи: PK и FK

Primary Key (PK)

Уникальный идентификатор строки. Не может повторяться и быть пустым (NULL). Это «паспорт» записи.

Foreign Key (FK)

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

Ограничения (Constraints)

Constraints — это правила, которые БД принудительно проверяет при каждой записи данных, чтобы защитить информацию от ошибок.

<b>NOT NULL</b> — поле обязательно для заполнения.

<b>UNIQUE</b> — значения в колонке не должны повторяться (например, Email).

<b>CHECK</b> — проверка условия (например, возраст > 0).

<b>DEFAULT</b> — значение по умолчанию, если ничего не передано.

Нормализация данных

Плохо (Денормализовано)

Одна таблица «Заказы», в которой дублируется адрес клиента и название товара в каждой строке.<br><br>• Много повторов<br>• Сложно обновлять (надо менять во всех строках)

Хорошо (Нормализовано)

Разделение на таблицы: «Клиенты», «Товары», «Заказы».<br><br>• Данные хранятся один раз<br>• Ссылки через ID<br>• Легкая поддержка

Практический пример: Онлайн-библиотека

<b>Задача:</b> Создать структуру для учета выдачи книг.

<b>Сущности (Entities):</b><br>- <i>Книга (Book):</i> Название, ISBN, Автор.<br>- <i>Читатель (Reader):</i> ФИО, Номер билета.<br>- <i>Выдача (Loan):</i> Кто взял, какую книгу, дата возврата.

Визуализация схемы (ERD)

Таблица «Loans» связывает «Books» и «Readers» через их ID (Foreign Keys).

Реализация: Таблицы vs JSON

Structured (SQL)

| ID | Name | Age | |----|----------|-----| | 1 | Alice | 24 | | 2 | Bob | 30 |

Flexible (NoSQL)

{ "_id": "1", "name": "Alice", "age": 24, "skills": ["Art"] }

Популярные СУБД (Stack Overflow Survey 2024)

Данные опроса профессиональных разработчиков показывают доминирование реляционных баз (Postgres, MySQL), но NoSQL (MongoDB) также сохраняет значительную долю.

Главные выводы

✅ <b>Думайте наперед:</b> Планируйте структуру на бумаге до написания кода.

✅ <b>Нормализуйте:</b> Избегайте дублирования данных, где это возможно.

✅ <b>Следите за типами:</b> Правильный выбор типа данных (int, varchar, date) экономит место и ускоряет поиск.