Домашнее задание - Практическое занятие №1: ключи, объекты и проект БД, таблицы

Выполняйте только если преподаватель назначил это задание. Срок сдачи сообщит преподаватель.

Дисциплина: ОП.08 Основы проектирования баз данных
Специальность: 09.02.07 Информационные системы и программирование

1. Назначение и методический регламент

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

Цель задания: Закрепить практические навыки проектирования реляционной схемы таблицы, выбора оптимальных физических типов данных, спецификации первичных и альтернативных ключей, а также формализации бизнес-правил через декларативные ограничения целостности CHECK.

2. Содержание резервного задания

Часть А. Проектирование схемы таблицы учетной системы

Спроектируйте физическую структуру реляционной таблицы tovarnye_nakladnye (Товарные накладные оптового склада) в нотации SQL DDL (синтаксис PostgreSQL/ANSI SQL). Таблица должна содержать следующие реквизиты:

  1. Суррогатный первичный идентификатор (BIGINT IDENTITY).
  2. Номер накладной (строка фиксированного формата, уникальная в масштабах системы).
  3. Внешний ключ на таблицу поставщиков postavshchiki(id_postavshchika) с правилом защиты от удаления (RESTRICT).
  4. Дата и время составления накладной (по умолчанию текущий момент).
  5. Планируемая дата поставки товара.
  6. Фактическая дата приемки товара на склад (может быть не заполнена до момента приемки).
  7. Сумма накладной без НДС (денежный тип данных с фиксированной точностью до копеек).
  8. Сумма НДС (20% от суммы без НДС).
  9. Итоговая сумма с НДС.
  10. Статус накладной: 'черновик', 'согласована', 'в_пути', 'принята', 'аннулирована'.
Часть Б. Проверка корректности и формулирование ограничений CHECK

Разработайте и запишите в коде создания таблицы 4 строгих ограничения целостности CHECK:

  • Ограничение 1 (Темпоральная последовательность дат): Планируемая дата поставки не может предшествовать дате составления накладной. Фактическая дата приемки (если она заполнена) также обязана быть больше или равна дате составления накладной.
  • Ограничение 2 (Корректность финансовых сумм): Сумма без НДС строго неотрицательна. Итоговая сумма с НДС обязана быть больше либо равна сумме без НДС.
  • Ограничение 3 (Статусная модель): Поле статуса накладной может принимать только значения из утвержденного закрытого перечня жизненного цикла документа.
  • Ограничение 4 (Логическая непротиворечивость приемки): Если статус накладной установлен в 'принята', то фактическая дата приемки не может быть пустой (IS NOT NULL).

3. Пример оформления эталонного решения

Ниже приведен образец корректного оформления аналогичной проектной задачи для таблицы договоров аренды:

Эталонный образец: Таблица dogovory_arendy
CREATE TABLE dogovory_arendy (
    id_dogovora BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    nomer_dogovora VARCHAR(30) NOT NULL UNIQUE,
    id_arendatora INT NOT NULL REFERENCES arendatory(id_arendatora)
        ON UPDATE CASCADE ON DELETE RESTRICT,
    data_zaklyucheniya DATE NOT NULL DEFAULT CURRENT_DATE,
    data_nachala DATE NOT NULL,
    data_okonchaniya DATE NOT NULL,
    stoimost_mesyac NUMERIC(10,2) NOT NULL CHECK (stoimost_mesyac > 0),
    status VARCHAR(20) NOT NULL DEFAULT 'активен'
        CHECK (status IN ('черновик', 'активен', 'расторгнут', 'завершен')),
    sozdano_v TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT chk_period CHECK (data_okonchaniya > data_nachala),
    CONSTRAINT chk_start CHECK (data_nachala >= data_zaklyucheniya)
);

4. Требования к оформлению и критерии оценивания