Какие знаешь принципы построения логической модели данных?

Принципы построения логической модели данных

Логическая модель данных (Logical Data Model, LDM) — промежуточное представление между концептуальной моделью и физической реализацией БД. Она детализирует структуру данных, но остается независимой от конкретной СУБД.

Основные принципы

Нормализация (Normalization)

• Первая нормальная форма (1NF): атомарность атрибутов, отсутствие повторяющихся групп
• Вторая нормальная форма (2NF): каждый неключевой атрибут зависит от всего первичного ключа
• Третья нормальная форма (3NF): отсутствие транзитивных зависимостей
• Нормальная форма Бойса-Коди (BCNF): каждый детерминант является потенциальным ключом
• Цель: минимизировать аномалии при вставке, обновлении и удалении

Сущности и таблицы (Entities to Tables)

• Каждая концептуальная сущность становится таблицей
• Атрибуты сущности становятся столбцами таблицы
• Первичный ключ определяется явно
• Внешние ключи добавляются для связей

Первичные ключи (Primary Keys)

• Каждая таблица должна иметь уникальный первичный ключ
• Может быть простым (один столбец) или составным (несколько)
• Не может содержать NULL
• Рекомендуется использовать суррогатные ключи (ID, UUID)
• Пример: employee_id в таблице Employees

Внешние ключи (Foreign Keys)

• Связывают таблицы через первичные ключи
• Обеспечивают ссылочную целостность
• Пример: customer_id в таблице Orders ссылается на Orders.customer_id
• Создаются для каждой связи 1:N

Преобразование связей (Relationship Mapping)

• Связи 1:1: добавить внешний ключ в любую таблицу
• Связи 1:N: добавить внешний ключ в таблицу "многие"
• Связи M:N: создать промежуточную таблицу (junction table)
  • Пример: StudentCourse (student_id, course_id) для связи Student M:N Course

Детали структуры

Типы данных (Data Types)

• NUMERIC: INTEGER, BIGINT, DECIMAL, FLOAT
• STRING: VARCHAR, CHAR, TEXT
• DATETIME: DATE, TIME, TIMESTAMP
• BOOLEAN: BOOLEAN, BIT
• Правильный выбор влияет на производительность и хранение

Домены (Domains)

• Определение допустимых значений для атрибутов
• Диапазоны: age 0-150
• Форматы: email должен содержать @
• Ограничения: CHECK constraints

Обязательность атрибутов (Nullability)

• NOT NULL для обязательных атрибутов
• Для опциональных атрибутов NULL допускается
• Все ключи должны быть NOT NULL
• Каждый выбор влияет на целостность данных

Уникальные ограничения (Unique Constraints)

• UNIQUE для атрибутов, которые должны быть уникальными
• Примеры: email, username, SSN
• Может быть несколько UNIQUE в одной таблице
• Отличается от PRIMARY KEY: может быть NULL

Продвинутые принципы

Денормализация (Denormalization)

• Иногда нарушают нормализацию для производительности
• Добавление хеширования или агрегированных данных
• Примеры: сохранить total_amount в Order вместо расчета из Items
• Требует специального обоснования и синхронизации

Наследование (Inheritance)

• Моделирование иерархии типов
• Стратегия Single Table: все классы в одной таблице + тип-дискриминатор
• Стратегия Joined Tables: отдельные таблицы для каждого класса
• Стратегия Table Per Class: независимые таблицы без связи

Слабые сущности (Weak Entities)

• Сущности, зависящие от других для идентификации
• Пример: OrderItem зависит от Order
• Первичный ключ включает внешний ключ родительской сущности
• OrderItem.PK = (order_id, line_number)

Процесс преобразования

Шаг 1: Преобразование сущностей

Customer (концептуальная) → customers (таблица логическая)

Шаг 2: Определение первичных ключей

• Простой: customer_id
• Или составной: (first_name, last_name, date_of_birth)

Шаг 3: Преобразование связей

• 1:N: Customer 1 -> M Order
  • Добавить customer_id в таблицу orders
• M:N: Student M <-> M Course
  • Создать enrollments(student_id, course_id)

Шаг 4: Добавление атрибутов

• Определить все столбцы
• Задать типы данных
• Определить ограничения

Шаг 5: Нормализация

• Проверить каждую таблицу
• Убедиться соответствие 3NF
• Устранить аномалии

Практический пример: E-commerce

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

• Сущности: Customer, Product, Category, Order
• Связи: Customer 1->M Order, Category 1->M Product

Логическая модель

Таблица customers:

• customer_id (PK, UUID)
• email (UNIQUE, VARCHAR)
• first_name (VARCHAR)
• last_name (VARCHAR)
• created_date (TIMESTAMP)

Таблица products:

• product_id (PK, UUID)
• name (VARCHAR, NOT NULL)
• price (DECIMAL, CHECK > 0)
• category_id (FK → categories.category_id)

Таблица orders:

• order_id (PK, UUID)
• customer_id (FK → customers.customer_id, NOT NULL)
• order_date (TIMESTAMP)
• total_amount (DECIMAL)

Таблица order_items:

• order_item_id (PK, UUID)
• order_id (FK → orders.order_id)
• product_id (FK → products.product_id)
• quantity (INTEGER, CHECK > 0)
• unit_price (DECIMAL)

Выбор между вариантами

UUID vs INTEGER для PK

• UUID: глобально уникален, 16 байт, медленнее для индексов
• INTEGER: 4 байта, быстрее, нужен генератор (AUTO_INCREMENT, sequence)
• Выбор: UUID для микросервисов, INTEGER для монолита

NULL vs значение по умолчанию

• Для optional: можно NULL
• Для required: NOT NULL + DEFAULT
• Пример: status VARCHAR NOT NULL DEFAULT 'pending'

Инструменты и стандарты

Инструменты

• Lucidchart, ERDPlus: рисование логических диаграмм
• SQL Power Architect: генерация SQL DDL
• DataGrip: встроенная поддержка

Стандарты

• ANSI SQL для совместимости
• Naming conventions: snake_case для таблиц и столбцов

Заключение

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