Конспект

Модели данных: основы

Ключевые тезисы

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

Данные и их определение

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

Характеристики данных:

• Формализованность и структурированность: Это не произвольный набор, а информация, приведённая к определённой форме.
• Контекст предметной области: Смысл и ценность данных определяются бизнес-процессами, в которых они используются.
• Фиксация состояния: Данные фиксируют состояние объектов (сущностей) и факты их взаимодействия.
• Критерий для системы: Данными считается то, что система должна хранить, обрабатывать, преобразовывать или передавать для достижения бизнес-целей.

Сущность (Entity)

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

Ключевые характеристики сущности:

• Представляет собой класс объектов (шаблон), а не конкретный экземпляр.
• Обладает уникальной идентификацией (каждый экземпляр можно однозначно определить, например, по ID).
• Имеет самостоятельное существование в предметной области (существует независимо от других сущностей).
• Описывается через атрибуты — набор свойств, характеризующих сущность.

Критерии выявления сущности:

1. Объект имеет уникальный идентификатор.
2. О нём система хранит информацию.
3. Он участвует в бизнес-процессах.
4. У него есть множество экземпляров.
5. Он обладает набором характерных свойств.

Примеры сущностей: Клиент, Платёж, Книга, Заказ, Автор.

Атрибуты (Attributes)

Атрибут — это характеристика, свойство или качество сущности, которое содержит элементарную единицу информации о ней.

Характеристики атрибута:

• Элементарная единица: Содержит минимальную неделимую в контексте системы информацию.
• Принадлежность: Каждый атрибут описывает конкретную сущность.
• Тип данных: Имеет определённый формат хранения (например, int, string, UID).

Классификация атрибутов:

• По структуре: Простые (атомарные, например, возраст) и составные (состоящие из компонентов, например, адрес).
• По обязательности: Обязательные (всегда должны быть заполнены) и необязательные.
• По происхождению: Базовые (хранятся напрямую, например, дата рождения) и производные (вычисляются на основе других, например, возраст).
• По уникальности: Ключевые (уникально идентифицируют экземпляр, например, user ID) и неключевые (описывают, но не идентифицируют, например, имя).

Правила качественного атрибута: должен быть однозначным, атомарным, однородным, не избыточным и релевантным бизнес-процессам.

Связи (Relationships)

Связь — это логическое отношение между двумя и более сущностями, определяющее бизнес-правила их взаимодействия.

Типы связей по мощности:

1. Один к одному (1:1): Одному экземпляру сущности A соответствует не более одного экземпляра сущности B.
   • Пример: Сотрудник — Паспорт (у сотрудника только один паспорт).
2. Один ко многим (1:M): Одному экземпляру сущности A соответствует ноль, один или несколько экземпляров сущности B.
   • Пример: Покупатель — Товарный чек (у покупателя может быть много чеков).
3. Многие ко многим (M:M): Одному экземпляру сущности A соответствует несколько экземпляров сущности B и наоборот.
   • Пример: Студент — Библиотека (студент может быть записан в нескольких библиотеках, в библиотеке много читателей).

Типы связей по семантике:

• Идентифицирующая: Дочерняя сущность не может существовать без родительской (например, Позиция заказа не существует без Заказа).
• Неидентифицирующая: Дочерняя сущность может существовать независимо (например, Клиент может существовать без привязки к Городу).
• Рекурсивная: Сущность связана сама с собой (например, связь "Сотрудник — Менеджер", где менеджер также является сотрудником).

ER-диаграммы (ERD)

ER-диаграмма — графическое представление сущностей, их атрибутов и связей между ними в модели данных.

Виды ER-моделей:

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

Нотации ERD:

• Нотация Чена: Классическая, с символами (прямоугольник — сущность, овал — атрибут, ромб — связь). Используется для концептуальных моделей.
• Нотация Мартина: Более компактная. Все атрибуты перечислены внутри прямоугольника сущности. Используется для логических и физических моделей.

Правила составления ERD:

• Наименование сущности — в единственном числе.
• Наименования атрибутов уникальны в пределах модели.
• Определены первичные и внешние ключи.
• Направление чтения — слева направо.

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

Нормализация — процесс организации данных в базе для уменьшения избыточности и устранения аномалий при операциях вставки, обновления и удаления.

Нормальные формы (НФ):

1. Первая НФ: Все атрибуты атомарны (неделимы). Решает проблему многозначных и составных полей.
   • Пример: Вместо атрибута "Модель: X5, X6" создаются отдельные записи для каждой модели.
2. Вторая НФ: Должна выполняться 1НФ. Каждый неключевой атрибут зависит от всего первичного ключа. Решает проблему частичных зависимостей.
   • Пример: Если скидка зависит только от производителя, а не от модели, её нужно вынести в отдельную таблицу.
3. Третья НФ: Должна выполняться 2НФ. Неключевые атрибуты не зависят друг от друга (нет транзитивных зависимостей).
   • Пример: Если телефон магазина зависит от названия магазина, а не от модели товара, данные о магазине выносятся в отдельную таблицу.

Алгоритм нормализации:

1. Собрать все атрибуты в одну большую таблицу.
2. Применить 1НФ: разделить составные и многозначные поля.
3. Применить 2НФ: выявить и вынести атрибуты, зависящие от части ключа.
4. Применить 3НФ: выявить и вынести транзитивные зависимости.
5. Проверить логичность и обязательность связей, оптимизировать модель.

Последовательность построения модели данных

1. Выделить сущности из пользовательских историй и требований.
2. Определить атрибуты для каждой сущности.
3. Определить связи между сущностями на основе бизнес-правил.
4. Построить ER-диаграмму, отобразив сущности и связи.
5. Проверить нормализацию (до 3НФ).
6. Сверить модель с пользовательскими историями на полноту.