Pastein: # ПРАКТИЧЕСКАЯ РАБОТА №1 ## Тема: «Построение схемы базы данных» ### Вариант 22

Загрузка данных
# ПРАКТИЧЕСКАЯ РАБОТА №1
## Тема: «Построение схемы базы данных»
### Вариант 22 — Кулинария

**Выполнил:** Dilan  
**Преподаватель:** А.А. Кравченко

---

## Задание 1. Описание предметной области

**Кулинария** — предприятие общественного питания, специализирующееся на приготовлении и реализации кулинарных изделий (полуфабрикатов, готовых блюд, кондитерских изделий, салатов и т.д.).

**Основные бизнес-процессы предприятия:**

1. **Закупочная деятельность** — приобретение продуктов и сырья у поставщиков по договорным ценам.
2. **Складской учёт** — приёмка, хранение и списание продуктов с контролем сроков годности и условий хранения.
3. **Производство** — изготовление кулинарных изделий по утверждённым технологическим картам (рецептурам) с учётом норм закладки сырья.
4. **Кадровый учёт** — учёт сотрудников (поваров, кондитеров, технологов), их должностей и квалификации.
5. **Продажи** — реализация готовой продукции через торговые точки (витрины, отделы) с оформлением заказов.
6. **Классификация продукции** — ведение справочника категорий изделий (салаты, горячие блюда, выпечка, кондитерские изделия и т.д.).

**Цель создания БД:** автоматизация учёта производства, складских операций, продаж и кадрового состава для повышения эффективности управления предприятием.

---

## Задание 2. Ключевые объекты системы

| № | Объект (сущность) | Описание | Примеры |
|---|-------------------|----------|---------|
| 1 | **Поставщик** | Организация или ИП, поставляющее продукты | ООО «Молочный мир», ИП Иванов |
| 2 | **Продукт (Ингредиент)** | Сырьё, используемое для приготовления блюд | Мука, яйца, сахар, мясо |
| 3 | **Склад** | Помещение для хранения продуктов | Основной склад, холодильник |
| 4 | **Рецептура** | Технологическая карта приготовления изделия | Рецептура торта «Наполеон» |
| 5 | **Кулинарное изделие** | Готовый продукт, производимый предприятием | Торт, салат, пирожок |
| 6 | **Категория изделия** | Группа, к которой относится изделие | Салаты, выпечка, кондитерские |
| 7 | **Сотрудник** | Работник предприятия (повар, кондитер) | Петров И.И., Сидорова А.А. |
| 8 | **Должность** | Квалификационная позиция сотрудника | Повар 4 разряда, кондитер |
| 9 | **Клиент** | Покупатель продукции | Физическое или юридическое лицо |
| 10 | **Заказ** | Факт продажи продукции клиенту | Заказ №123 от 15.03.2024 |

---

## Задание 3. Инфологическое проектирование

### 3а. Концептуальная ER-диаграмма

```mermaid
erDiagram
    ПОСТАВЩИК ||--o{ ПРОДУКТ : "поставляет"
    ПРОДУКТ }o--o{ СКЛАД : "хранится на"
    ПРОДУКТ }o--o{ РЕЦЕПТУРА : "входит в состав"
    РЕЦЕПТУРА ||--o| КУЛИНАРНОЕ_ИЗДЕЛИЕ : "описывает"
    КУЛИНАРНОЕ_ИЗДЕЛИЕ }o--|| КАТЕГОРИЯ_ИЗДЕЛИЯ : "относится к"
    СОТРУДНИК }o--|| ДОЛЖНОСТЬ : "занимает должность"
    СОТРУДНИК }o--o{ КУЛИНАРНОЕ_ИЗДЕЛИЕ : "готовит"
    КУЛИНАРНОЕ_ИЗДЕЛИЕ }o--o{ ЗАКАЗ : "включается в"
    КЛИЕНТ ||--o{ ЗАКАЗ : "оформляет"

    ПОСТАВЩИК {
        string наименование
        string ИНН
        string адрес
    }

    ПРОДУКТ {
        string наименование
        string единица_измерения
    }

    СКЛАД {
        string наименование
        string адрес
    }

    РЕЦЕПТУРА {
        string название
        string технология
    }

    КУЛИНАРНОЕ_ИЗДЕЛИЕ {
        string наименование
        float цена
    }

    КАТЕГОРИЯ_ИЗДЕЛИЯ {
        string название_категории
    }

    СОТРУДНИК {
        string ФИО
        string телефон
    }

    ДОЛЖНОСТЬ {
        string название_должности
        int разряд
    }

    КЛИЕНТ {
        string ФИО
        string телефон
    }

    ЗАКАЗ {
        date дата_заказа
        float сумма
    }
```

**Комментарий к диаграмме:**

Диаграмма отражает основные сущности предметной области и связи между ними:

- **Поставщик — Продукт (1:M):** один поставщик может поставлять множество различных продуктов, но каждая партия продукта поступает от конкретного поставщика.
- **Продукт — Склад (M:N):** один и тот же продукт может храниться на разных складах (например, в холодильнике и в сухом складе), а на одном складе хранится множество продуктов.
- **Продукт — Рецептура (M:N):** один продукт может входить в состав множества рецептур, а каждая рецептура содержит множество продуктов.
- **Рецептура — Кулинарное изделие (1:1):** каждая рецептура описывает одно конкретное изделие.
- **Кулинарное изделие — Категория (M:1):** множество изделий относится к одной категории.
- **Сотрудник — Должность (M:1):** несколько сотрудников могут занимать одну должность.
- **Сотрудник — Кулинарное изделие (M:N):** сотрудник может готовить разные изделия, а одно изделие могут готовить разные сотрудники.
- **Кулинарное изделие — Заказ (M:N):** в одном заказе может быть несколько изделий, одно изделие может входить в разные заказы.
- **Клиент — Заказ (1:M):** один клиент может оформить несколько заказов.

---

### 3б. Уточнённая ER-диаграмма (с атрибутами и связующими таблицами)

```mermaid
erDiagram
    ПОСТАВЩИК {
        int id_поставщика PK
        string наименование
        string ИНН
        string адрес
        string телефон
        string контактное_лицо
    }

    ПРОДУКТ {
        int id_продукта PK
        string наименование
        string единица_измерения
        string категория_продукта
    }

    СКЛАД {
        int id_склада PK
        string наименование
        string адрес
        float температура_хранения
    }

    РЕЦЕПТУРА {
        int id_рецептуры PK
        string название
        string технология_приготовления
        int время_приготовления_мин
        int выход_грамм
        int id_изделия FK
    }

    КУЛИНАРНОЕ_ИЗДЕЛИЕ {
        int id_изделия PK
        string наименование
        float цена
        int вес_грамм
        int срок_годности_час
        int id_категории FK
    }

    КАТЕГОРИЯ_ИЗДЕЛИЯ {
        int id_категории PK
        string название_категории
        string описание
    }

    ДОЛЖНОСТЬ {
        int id_должности PK
        string название_должности
        int разряд
        float оклад
    }

    СОТРУДНИК {
        int id_сотрудника PK
        string ФИО
        string телефон
        date дата_приёма
        int id_должности FK
    }

    КЛИЕНТ {
        int id_клиента PK
        string ФИО
        string телефон
        string адрес
    }

    ЗАКАЗ {
        int id_заказа PK
        date дата_заказа
        float сумма
        int id_клиента FK
    }

    ПОСТАВКА {
        int id_поставки PK
        int id_поставщика FK
        int id_продукта FK
        date дата_поставки
        int количество
        float цена_закупки
    }

    ХРАНЕНИЕ {
        int id_хранения PK
        int id_продукта FK
        int id_склада FK
        int количество
        date дата_поступления
    }

    СОСТАВ_РЕЦЕПТУРЫ {
        int id_состава PK
        int id_рецептуры FK
        int id_продукта FK
        float количество
        string единица_измерения
    }

    ПРИГОТОВЛЕНИЕ {
        int id_приготовления PK
        int id_сотрудника FK
        int id_изделия FK
        date дата
        int количество
    }

    СОСТАВ_ЗАКАЗА {
        int id_позиции PK
        int id_заказа FK
        int id_изделия FK
        int количество
        float цена
    }

    ПОСТАВЩИК ||--o{ ПОСТАВКА : "осуществляет"
    ПРОДУКТ ||--o{ ПОСТАВКА : "поставляется в рамках"
    ПРОДУКТ ||--o{ ХРАНЕНИЕ : "хранится в"
    СКЛАД ||--o{ ХРАНЕНИЕ : "принимает на хранение"
    РЕЦЕПТУРА ||--o{ СОСТАВ_РЕЦЕПТУРЫ : "содержит"
    ПРОДУКТ ||--o{ СОСТАВ_РЕЦЕПТУРЫ : "включается в"
    РЕЦЕПТУРА }o--|| КУЛИНАРНОЕ_ИЗДЕЛИЕ : "описывает"
    КАТЕГОРИЯ_ИЗДЕЛИЯ ||--o{ КУЛИНАРНОЕ_ИЗДЕЛИЕ : "включает"
    ДОЛЖНОСТЬ ||--o{ СОТРУДНИК : "занимается"
    СОТРУДНИК ||--o{ ПРИГОТОВЛЕНИЕ : "выполняет"
    КУЛИНАРНОЕ_ИЗДЕЛИЕ ||--o{ ПРИГОТОВЛЕНИЕ : "производится"
    КЛИЕНТ ||--o{ ЗАКАЗ : "оформляет"
    ЗАКАЗ ||--o{ СОСТАВ_ЗАКАЗА : "содержит"
    КУЛИНАРНОЕ_ИЗДЕЛИЕ ||--o{ СОСТАВ_ЗАКАЗА : "включается"
```

**Комментарий к уточнённой диаграмме:**

В уточнённой диаграмме связи типа M:N реализованы через **связующие (ассоциативные) таблицы**:

1. **ПОСТАВКА** — связывает Поставщика и Продукт, содержит атрибуты самой поставки (дата, количество, цена закупки).
2. **ХРАНЕНИЕ** — связывает Продукт и Склад, содержит информацию о количестве и дате поступления.
3. **СОСТАВ_РЕЦЕПТУРЫ** — связывает Рецептуру и Продукт, содержит норму закладки ингредиента.
4. **ПРИГОТОВЛЕНИЕ** — связывает Сотрудника и Изделие, фиксирует факт приготовления.
5. **СОСТАВ_ЗАКАЗА** — связывает Заказ и Изделие, содержит количество и цену в заказе.

Все внешние ключи (FK) явно указаны в атрибутах таблиц.

---

## Задание 4. Логическое проектирование

Реляционная схема базы данных «Кулинария»:

```
ПОСТАВЩИК(id_поставщика PK, наименование, ИНН, адрес, телефон, контактное_лицо)

ПРОДУКТ(id_продукта PK, наименование, единица_измерения, категория_продукта)

СКЛАД(id_склада PK, наименование, адрес, температура_хранения)

КАТЕГОРИЯ_ИЗДЕЛИЯ(id_категории PK, название_категории, описание)

ДОЛЖНОСТЬ(id_должности PK, название_должности, разряд, оклад)

КЛИЕНТ(id_клиента PK, ФИО, телефон, адрес)

КУЛИНАРНОЕ_ИЗДЕЛИЕ(id_изделия PK, наименование, цена, вес_грамм, срок_годности_час, id_категории FK → КАТЕГОРИЯ_ИЗДЕЛИЯ)

РЕЦЕПТУРА(id_рецептуры PK, название, технология_приготовления, время_приготовления_мин, выход_грамм, id_изделия FK → КУЛИНАРНОЕ_ИЗДЕЛИЕ)

СОТРУДНИК(id_сотрудника PK, ФИО, телефон, дата_приёма, id_должности FK → ДОЛЖНОСТЬ)

ЗАКАЗ(id_заказа PK, дата_заказа, сумма, id_клиента FK → КЛИЕНТ)

ПОСТАВКА(id_поставки PK, id_поставщика FK → ПОСТАВЩИК, id_продукта FK → ПРОДУКТ, дата_поставки, количество, цена_закупки)

ХРАНЕНИЕ(id_хранения PK, id_продукта FK → ПРОДУКТ, id_склада FK → СКЛАД, количество, дата_поступления)

СОСТАВ_РЕЦЕПТУРЫ(id_состава PK, id_рецептуры FK → РЕЦЕПТУРА, id_продукта FK → ПРОДУКТ, количество, единица_измерения)

ПРИГОТОВЛЕНИЕ(id_приготовления PK, id_сотрудника FK → СОТРУДНИК, id_изделия FK → КУЛИНАРНОЕ_ИЗДЕЛИЕ, дата, количество)

СОСТАВ_ЗАКАЗА(id_позиции PK, id_заказа FK → ЗАКАЗ, id_изделия FK → КУЛИНАРНОЕ_ИЗДЕЛИЕ, количество, цена)
```

**Диаграмма реляционной схемы:**

```mermaid
graph TD
    subgraph Справочные таблицы
        A[ПОСТАВЩИК<br/>id_поставщика PK<br/>наименование<br/>ИНН<br/>адрес<br/>телефон]
        B[ПРОДУКТ<br/>id_продукта PK<br/>наименование<br/>единица_измерения]
        C[СКЛАД<br/>id_склада PK<br/>наименование<br/>адрес]
        D[КАТЕГОРИЯ_ИЗДЕЛИЯ<br/>id_категории PK<br/>название_категории]
        E[ДОЛЖНОСТЬ<br/>id_должности PK<br/>название_должности<br/>разряд<br/>оклад]
        F[КЛИЕНТ<br/>id_клиента PK<br/>ФИО<br/>телефон]
    end

    subgraph Основные таблицы
        G[КУЛИНАРНОЕ_ИЗДЕЛИЕ<br/>id_изделия PK<br/>наименование<br/>цена<br/>вес<br/>id_категории FK]
        H[РЕЦЕПТУРА<br/>id_рецептуры PK<br/>название<br/>технология<br/>id_изделия FK]
        I[СОТРУДНИК<br/>id_сотрудника PK<br/>ФИО<br/>телефон<br/>id_должности FK]
        J[ЗАКАЗ<br/>id_заказа PK<br/>дата_заказа<br/>сумма<br/>id_клиента FK]
    end

    subgraph Связующие таблицы
        K[ПОСТАВКА<br/>id_поставки PK<br/>id_поставщика FK<br/>id_продукта FK<br/>количество]
        L[ХРАНЕНИЕ<br/>id_хранения PK<br/>id_продукта FK<br/>id_склада FK<br/>количество]
        M[СОСТАВ_РЕЦЕПТУРЫ<br/>id_состава PK<br/>id_рецептуры FK<br/>id_продукта FK<br/>количество]
        N[ПРИГОТОВЛЕНИЕ<br/>id_приготовления PK<br/>id_сотрудника FK<br/>id_изделия FK<br/>количество]
        O[СОСТАВ_ЗАКАЗА<br/>id_позиции PK<br/>id_заказа FK<br/>id_изделия FK<br/>количество]
    end

    A --> K
    B --> K
    B --> L
    C --> L
    D --> G
    G --> H
    G --> N
    E --> I
    I --> N
    F --> J
    J --> O
    G --> O
    H --> M
    B --> M

    style A fill:#e1f5fe
    style B fill:#e1f5fe
    style C fill:#e1f5fe
    style D fill:#e1f5fe
    style E fill:#e1f5fe
    style F fill:#e1f5fe
    style G fill:#fff3e0
    style H fill:#fff3e0
    style I fill:#fff3e0
    style J fill:#fff3e0
    style K fill:#f3e5f5
    style L fill:#f3e5f5
    style M fill:#f3e5f5
    style N fill:#f3e5f5
    style O fill:#f3e5f5
```

---

## Задание 5. Нормализация (до 3 нормальной формы)

### Исходная универсальная таблица (ненормализованная форма)

Рассмотрим объединённую таблицу, содержащую все данные о заказах:

> **ЗАКАЗ_ПОЛНЫЙ**(id_заказа, дата_заказа, ФИО_клиента, телефон_клиента, адрес_клиента, наименование_изделия, цена_изделия, вес_изделия, название_категории, описание_категории, количество, цена_в_заказе, сумма)

### Приведение к 1НФ

**Требование 1НФ:** все атрибуты должны быть атомарными (неделимыми), в таблице не должно быть повторяющихся групп.

В нашей таблице все поля содержат простые значения (числа, строки, даты), повторяющихся групп нет.

✅ **Таблица соответствует 1НФ.**

---

### Приведение к 2НФ

**Требование 2НФ:** таблица должна быть в 1НФ, и каждый неключевой атрибут должен полностью зависеть от первичного ключа (не должно быть частичных зависимостей).

Если рассматривать составной первичный ключ `(id_заказа, id_изделия)`, то:
- `дата_заказа`, `сумма` зависят только от `id_заказа` (частичная зависимость) 
- `наименование_изделия`, `цена_изделия`, `вес_изделия` зависят только от `id_изделия` (частичная зависимость) ❌
- `название_категории`, `описание_категории` зависят от `id_категории`, который зависит от `id_изделия` (транзитивная зависимость) 
- `ФИО_клиента`, `телефон_клиента`, `адрес_клиента` зависят от `id_клиента`, который зависит от `id_заказа` (транзитивная зависимость) ❌

**Декомпозиция для устранения частичных зависимостей:**

1. **ЗАКАЗ**(id_заказа PK, дата_заказа, сумма, id_клиента FK)
2. **КЛИЕНТ**(id_клиента PK, ФИО, телефон, адрес)
3. **СОСТАВ_ЗАКАЗА**(id_позиции PK, id_заказа FK, id_изделия FK, количество, цена_в_заказе)
4. **КУЛИНАРНОЕ_ИЗДЕЛИЕ**(id_изделия PK, наименование, цена, вес, срок_годности, id_категории FK)
5. **КАТЕГОРИЯ_ИЗДЕЛИЯ**(id_категории PK, название_категории, описание)

✅ **Таблицы соответствуют 2НФ.**

---

### Приведение к 3НФ

**Требование 3НФ:** таблица должна быть в 2НФ, и каждый неключевой атрибут должен нетранзитивно зависеть от первичного ключа (не должно быть транзитивных зависимостей).

Рассмотрим таблицу **СОТРУДНИК**:
> СОТРУДНИК(id_сотрудника, ФИО, телефон, дата_приёма, название_должности, разряд, оклад)

Здесь `название_должности`, `разряд`, `оклад` зависят от `id_должности`, который, в свою очередь, зависит от `id_сотрудника`. Это транзитивная зависимость. ❌

**Декомпозиция:**
- **СОТРУДНИК**(id_сотрудника PK, ФИО, телефон, дата_приёма, id_должности FK)
- **ДОЛЖНОСТЬ**(id_должности PK, название_должности, разряд, оклад)

Аналогично проверяем остальные таблицы — транзитивных зависимостей не обнаружено.

✅ **Все таблицы соответствуют 3НФ.**

---

### Диаграмма процесса нормализации

```mermaid
graph TD
    A["0НФ: Универсальная таблица ЗАКАЗ_ПОЛНЫЙ<br/>id_заказа, дата, ФИО_клиента, телефон_клиента,<br/>адрес_клиента, наименование_изделия,<br/>цена_изделия, категория_изделия, количество, сумма"] -->|"Устранение повторяющихся групп<br/>все атрибуты атомарны"| B["1НФ ✅<br/>Все поля содержат неделимые значения"]

    B -->|"Устранение частичных зависимостей<br/>наименование, цена, категория зависят<br/>только от id_изделия, а не от составного ключа"| C["2НФ ✅<br/>Декомпозиция на таблицы:<br/>- ЗАКАЗ<br/>- КЛИЕНТ<br/>- СОСТАВ_ЗАКАЗА<br/>- КУЛИНАРНОЕ_ИЗДЕЛИЕ<br/>- КАТЕГОРИЯ_ИЗДЕЛИЯ"]

    C -->|"Устранение транзитивных зависимостей<br/>название_должности, разряд, оклад зависят<br/>от id_должности, а не напрямую от id_сотрудника"| D["3НФ ✅<br/>Финальная схема из 15 таблиц<br/>Все таблицы в 3НФ"]

    style A fill:#ffcccc,stroke:#333,stroke-width:2px
    style B fill:#ffffcc,stroke:#333,stroke-width:2px
    style C fill:#ccffcc,stroke:#333,stroke-width:2px
    style D fill:#99ff99,stroke:#333,stroke-width:2px
```

---

### Итоговые таблицы в 3НФ

| № | Таблица | Первичный ключ (PK) | Внешние ключи (FK) | Статус 3НФ |
|---|---------|---------------------|---------------------|------------|
| 1 | ПОСТАВЩИК | id_поставщика | — | ✅ |
| 2 | ПРОДУКТ | id_продукта | — | ✅ |
| 3 | СКЛАД | id_склада | — | ✅ |
| 4 | КАТЕГОРИЯ_ИЗДЕЛИЯ | id_категории | — | ✅ |
| 5 | ДОЛЖНОСТЬ | id_должности | — | ✅ |
| 6 | КЛИЕНТ | id_клиента | — | ✅ |
| 7 | КУЛИНАРНОЕ_ИЗДЕЛИЕ | id_изделия | id_категории | ✅ |
| 8 | РЕЦЕПТУРА | id_рецептуры | id_изделия | ✅ |
| 9 | СОТРУДНИК | id_сотрудника | id_должности | ✅ |
| 10 | ЗАКАЗ | id_заказа | id_клиента | ✅ |
| 11 | ПОСТАВКА | id_поставки | id_поставщика, id_продукта | ✅ |
| 12 | ХРАНЕНИЕ | id_хранения | id_продукта, id_склада | ✅ |
| 13 | СОСТАВ_РЕЦЕПТУРЫ | id_состава | id_рецептуры, id_продукта | ✅ |
| 14 | ПРИГОТОВЛЕНИЕ | id_приготовления | id_сотрудника, id_изделия | ✅ |
| 15 | СОСТАВ_ЗАКАЗА | id_позиции | id_заказа, id_изделия | ✅ |

---

### Диаграмма функциональных зависимостей

```mermaid
graph TD
    subgraph "Функциональные зависимости (корректные)"
        A["id_заказа → дата_заказа, сумма, id_клиента"]
        B["id_клиента → ФИО, телефон, адрес"]
        C["id_изделия → наименование, цена, вес, срок_годности, id_категории"]
        D["id_категории → название_категории, описание"]
        E["id_сотрудника → ФИО, телефон, дата_приёма, id_должности"]
        F["id_должности → название_должности, разряд, оклад"]
    end

    subgraph "Транзитивные зависимости (устранены при нормализации)"
        G["id_заказа → id_клиента → ФИО_клиента, телефон_клиента ❌"]
        H["id_сотрудника → id_должности → название_должности, оклад ❌"]
        I["id_изделия → id_категории → название_категории ❌"]
    end

    style G fill:#ffcccc,stroke:#333,stroke-width:2px
    style H fill:#ffcccc,stroke:#333,stroke-width:2px
    style I fill:#ffcccc,stroke:#333,stroke-width:2px
```

---

## Задание 6. Ключевые ограничения

### 6.1. Ограничения целостности данных

| № | Ограничение | Тип | Таблица | Описание |
|---|-------------|-----|---------|----------|
| 1 | **Первичный ключ (PK)** | PK | Все таблицы | Каждая таблица имеет уникальный идентификатор (id_*). Значение PK уникально и не может быть NULL. |
| 2 | **Внешний ключ: СОТРУДНИК.id_должности** | FK | СОТРУДНИК | Ссылается на ДОЛЖНОСТЬ(id_должности). Сотрудник не может иметь несуществующую должность. |
| 3 | **Внешний ключ: КУЛИНАРНОЕ_ИЗДЕЛИЕ.id_категории** | FK | КУЛИНАРНОЕ_ИЗДЕЛИЕ | Ссылается на КАТЕГОРИЯ_ИЗДЕЛИЯ(id_категории). Изделие должно относиться к существующей категории. |
| 4 | **Внешний ключ: ЗАКАЗ.id_клиента** | FK | ЗАКАЗ | Ссылается на КЛИЕНТ(id_клиента). Заказ должен быть оформлен существующим клиентом. |
| 5 | **Внешний ключ: РЕЦЕПТУРА.id_изделия** | FK | РЕЦЕПТУРА | Ссылается на КУЛИНАРНОЕ_ИЗДЕЛИЕ(id_изделия). Рецептура описывает существующее изделие. |
| 6 | **Внешний ключ: ПОСТАВКА.id_поставщика** | FK | ПОСТАВКА | Ссылается на ПОСТАВЩИК(id_поставщика). Поставка осуществляется существующим поставщиком. |
| 7 | **Внешний ключ: ПОСТАВКА.id_продукта** | FK | ПОСТАВКА | Ссылается на ПРОДУКТ(id_продукта). Поставляемый продукт должен существовать в справочнике. |
| 8 | **Внешний ключ: ХРАНЕНИЕ.id_продукта** | FK | ХРАНЕНИЕ | Ссылается на ПРОДУКТ(id_продукта). На складе хранится существующий продукт. |
| 9 | **Внешний ключ: ХРАНЕНИЕ.id_склада** | FK | ХРАНЕНИЕ | Ссылается на СКЛАД(id_склада). Продукт хранится на существующем складе. |
| 10 | **Внешний ключ: СОСТАВ_РЕЦЕПТУРЫ.id_рецептуры** | FK | СОСТАВ_РЕЦЕПТУРЫ | Ссылается на РЕЦЕПТУРА(id_рецептуры). Состав относится к существующей рецептуре. |
| 11 | **Внешний ключ: СОСТАВ_РЕЦЕПТУРЫ.id_продукта** | FK | СОСТАВ_РЕЦЕПТУРЫ | Ссылается на ПРОДУКТ(id_продукта). В рецептуре используется существующий продукт. |
| 12 | **Внешний ключ: СОСТАВ_ЗАКАЗА.id_заказа** | FK | СОСТАВ_ЗАКАЗА | Ссылается на ЗАКАЗ(id_заказа). Позиция принадлежит существующему заказу. |
| 13 | **Внешний ключ: СОСТАВ_ЗАКАЗА.id_изделия** | FK | СОСТАВ_ЗАКАЗА | Ссылается на КУЛИНАРНОЕ_ИЗДЕЛИЕ(id_изделия). В заказе указывается существующее изделие. |

### 6.2. Проверочные ограничения (CHECK)

| № | Ограничение | Таблица | Атрибут | Условие | Описание |
|---|-------------|---------|---------|---------|----------|
| 14 | **Положительное количество** | ПОСТАВКА, ХРАНЕНИЕ, СОСТАВ_РЕЦЕПТУРЫ, ПРИГОТОВЛЕНИЕ, СОСТАВ_ЗАКАЗА | количество | количество > 0 | Количество не может быть отрицательным или нулевым |
| 15 | **Неотрицательная цена** | КУЛИНАРНОЕ_ИЗДЕЛИЕ, ПОСТАВКА, СОСТАВ_ЗАКАЗА | цена, цена_закупки | цена >= 0 | Цена не может быть отрицательной |
| 16 | **Положительный вес** | КУЛИНАРНОЕ_ИЗДЕЛИЕ, РЕЦЕПТУРА | вес_грамм, выход_грамм | вес > 0 | Вес изделия должен быть положительным |
| 17 | **Положительный срок годности** | КУЛИНАРНОЕ_ИЗДЕЛИЕ | срок_годности_час | срок_годности > 0 | Срок годности должен быть положительным |
| 18 | **Положительное время приготовления** | РЕЦЕПТУРА | время_приготовления_мин | время > 0 | Время приготовления должно быть положительным |

### 6.3. Ограничения уникальности (UNIQUE)

| № | Ограничение | Таблица | Атрибут | Описание |
|---|-------------|---------|---------|----------|
| 19 | **Уникальность ИНН** | ПОСТАВЩИК | ИНН | ИНН поставщика должен быть уникальным |
| 20 | **Уникальность названия категории** | КАТЕГОРИЯ_ИЗДЕЛИЯ | название_категории | Названия категорий не должны повторяться |
| 21 | **Уникальность названия должности** | ДОЛЖНОСТЬ | название_должности | Названия должностей не должны повторяться |

### 6.4. Ограничения на пустые значения (NOT NULL)

| № | Ограничение | Таблица | Атрибут | Описание |
|---|-------------|---------|---------|----------|
| 22 | **Обязательные поля** | Все таблицы | PK, наименование, ФИО | Первичные ключи и основные наименования не могут быть пустыми |
| 23 | **Обязательная цена** | КУЛИНАРНОЕ_ИЗДЕЛИЕ, СОСТАВ_ЗАКАЗА | цена | Цена изделия и цена в заказе обязательны |
| 24 | **Обязательная дата** | ЗАКАЗ, ПОСТАВКА, ХРАНЕНИЕ, ПРИГОТОВЛЕНИЕ | дата_* | Даты операций обязательны |

### 6.5. Каскадные операции (ON DELETE / ON UPDATE)

| № | Ограничение | Таблица | Связанная таблица | Действие | Описание |
|---|-------------|---------|-------------------|----------|----------|
| 25 | **Каскадное удаление заказа** | ЗАКАЗ | СОСТАВ_ЗАКАЗА | ON DELETE CASCADE | При удалении заказа автоматически удаляются его позиции |
| 26 | **Каскадное удаление клиента** | КЛИЕНТ | ЗАКАЗ | ON DELETE CASCADE | При удалении клиента удаляются его заказы |
| 27 | **Запрет удаления категории** | КАТЕГОРИЯ_ИЗДЕЛИЯ | КУЛИНАРНОЕ_ИЗДЕЛИЕ | ON DELETE RESTRICT | Нельзя удалить категорию, если в ней есть изделия |
| 28 | **Запрет удаления должности** | ДОЛЖНОСТЬ | СОТРУДНИК | ON DELETE RESTRICT | Нельзя удалить должность, если есть сотрудники с этой должностью |
| 29 | **Каскадное обновление PK** | Все таблицы | Все FK | ON UPDATE CASCADE | При изменении PK автоматически обновляются все FK |

---

## Заключение

В ходе выполнения практической работы была спроектирована база данных для предметной области **«Кулинария»**. 

**Выполненные задачи:**

1. ✅ Описана предметная область и основные бизнес-процессы предприятия.
2. ✅ Выделено 10 ключевых объектов системы.
3. ✅ Проведено инфологическое проектирование:
   - Составлена концептуальная ER-диаграмма с 10 сущностями и 9 связями.
   - Составлена уточнённая ER-диаграмма с атрибутами и 5 связующими таблицами для реализации связей M:N.
4. ✅ Проведено логическое проектирование: разработана реляционная схема из 15 таблиц.
5. ✅ Проведена нормализация до 3НФ: устранены частичные и транзитивные зависимости, что исключает аномалии обновления, удаления и вставки.
6. ✅ Описаны ключевые ограничения: 29 ограничений целостности данных, включая PK, FK, CHECK, UNIQUE, NOT NULL и каскадные операции.

**Результат:** спроектированная база данных обеспечивает эффективное хранение и обработку информации о производстве, складском учёте, продажах и кадрах предприятия «Кулинария», соответствует требованиям нормализации и обеспечивает целостность данных.

---

**Список использованной литературы:**

1. Годин В.В. Базы данных: проектирование. Учебник для СПО. М: изд-во Юрайт, 2020 г.
Больше возможностей при регистрации:
