🎯 Цель

Освоить проектирование реляционной базы данных и написание DDL-запросов (CREATE TABLE, ключи, ограничения).

📖 Контекст

Вам поручено создать базу данных для автоматизации учёта студентов 2-го курса факультета Информационных технологий. В БД должны храниться данные о:

• факультетах и специальностях,
• учебных группах,
• студентах,
• дисциплинах текущего семестра,
• результатах сдачи зачётов и экзаменов.

Требуется реализовать нормализованную структуру (3НФ), избегая дублирования данных , .

🧩 Схема БД (описание связей)

🔹 Связи:

• Одна специальность → одна группа (или несколько), одна группа → один факультет.
• Один студент → одна группа.
• Один студент может сдавать несколько предметов; один предмет — у многих студентов → связь многие-ко-многим через grade , .

💡 Подсказки

• Используйте SERIAL или INT AUTO_INCREMENT для автоинкремента (зависит от СУБД).
• Внешние ключи связывайте строго по логике «один-ко-многим» , .
• Для хранения «зачтено»/«не зачтено» и чисел в одном поле можно использовать VARCHAR или отдельный столбец is_pass (BOOLEAN).

📖 Контекст
Вам поручено разработать базу данных для электронного каталога научно-технической библиотеки университета. В системе должны храниться сведения о:

• читателях (студентах и преподавателях),
• книгах и учебных пособиях,
• издательствах,
• выдачах и возвратах,
• резервировании литературы.

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

🧩 Схема БД (описание связей)

🔹 Связи:

• Одно издательство → много книг, одна книга → одно издательство.
• Один читатель → много выдач/резервирований.
• Одна книга → много выдач (по разным экземплярам и во времени) — связь многие-ко-многим реализована через loan и reservation.

✍️ Задание

1. Напишите DDL-скрипт: создайте все 5 таблиц с корректными:

   • первичными (PRIMARY KEY) и внешними ключами (FOREIGN KEY),
   • типами данных (VARCHAR, DATE, INT, BOOLEAN и др.),
   • ограничениями (NOT NULL, CHECK, DEFAULT).
     

     Например: CHECK (role IN ('студент', 'преподаватель')), DEFAULT CURRENT_DATE для enroll_date.

2. Вставьте по 2–3 тестовые записи в каждую таблицу (DML: INSERT).

3. (Дополнительно) Напишите один из запросов:

   • Вывести всех студентов, у которых просрочены книги (return_date IS NULL AND due_date < CURRENT_DATE).
   • Для каждой книги — сколько раз её брали (включая текущие выдачи).
   • Создать представление:
     Читатель | Книга | Выдана | Срок | Статус (вовремя/просрочка).

💡 Подсказки

• Используйте SERIAL (PostgreSQL) или AUTO_INCREMENT (MySQL) для автоинкрементных PK.
• Для дат — тип DATE; для due_date можно использовать issue_date + INTERVAL '14 days'.
• Чтобы избежать конфликта «одна книга — один экземпляр», можно ввести таблицу copy (экземпляр книги), но в рамках задания допустимо использовать available_copies как упрощение.
• Внешние ключи должны обеспечивать каскадное удаление или блокировку при попытке нарушить целостность.

📖 Контекст

Вам поручено разработать базу данных для электронной регистратуры университетской поликлиники. В системе должны храниться сведения о:

• пациентах (студентах и сотрудниках),
• врачах и их специализациях,
• приёмах (записях на приём),
• диагнозах и выданных рецептах,
• кабинетах и расписании приёмов.

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

🧩 Схема БД (описание сущностей и связей)

🔹 Связи:

• Один пациент → много записей.
• Один врач → одна специализация (многие к одному), может работать в одном кабинете.
• Один врач → много записей и одно расписание.
• Расписание — слабая сущность, зависящая от врача.

✍️ Задание

1. DDL: Напишите скрипт создания всех 5 таблиц с:
   
   • корректными PRIMARY KEY и FOREIGN KEY,
   • типами данных (VARCHAR, TIMESTAMP, TIME, INT, ENUM/CHECK),
   • ограничениями (NOT NULL, CHECK, DEFAULT).
    
    
2. DML: Вставьте по 2–3 тестовые записи в каждую таблицу (INSERT).
3. (Дополнительно) Напишите один из запросов:
   
   • Вывести пациентов, у которых есть неотменённые записи на сегодня.
   • Для каждого врача — сколько приёмов он провёл за последнюю неделю.
   • Создать представление: Пациент | Врач | Специализация | Дата приёма | Статус

💡 Подсказки

• Используйте SERIAL (PostgreSQL) или AUTO_INCREMENT (MySQL) для PK.
• Для временных меток — TIMESTAMP; для времени начала/окончания — TIME.
• Чтобы избежать неконсистентности, внешние ключи должны включать ON DELETE RESTRICT или ON UPDATE CASCADE.
• Специализация может быть вынесена в отдельную таблицу для гибкости — как сделано выше.

📖 Контекст

Вам поручено спроектировать реляционную базу данных для частной стоматологической клиники «Улыбка+». Система должна поддерживать:

• учёт пациентов и их анамнеза,
• расписание работы врачей (стоматологов),
• запись на приёмы, включая тип процедуры,
• ведение истории лечения (проведённые манипуляции, использованные материалы),
• учёт кабинетов и оборудования,
• выставление счётов и оплат.

🧩 Схема БД (сущности и связи)

🔹 Связи:

• Один пациент → много записей (appointment).
• Один врач → много записей; у одного врача может быть одна или несколько специализаций (можно расширить до связи многие-ко-многим, если нужно).
• Одна запись (appointment) → одна или несколько записей в treatment_log (один приём — несколько манипуляций).
• Каждая запись привязана к одному кабинету.
• Каждая запись (appointment) → не более одного счёта (invoice), но счёт создаётся только после завершения приёма.

✍️ Задание

DDL

Напишите SQL-скрипт для создания всех таблиц:

• Используйте SERIAL / INT AUTO_INCREMENT для PK.
• Укажите NOT NULL, CHECK (например, tooth_num BETWEEN 11 AND 48), DEFAULT.
• Настройте внешние ключи с ON DELETE RESTRICT / ON UPDATE CASCADE.
• Для перечислений (status, payment_method) используйте ENUM (MySQL) или CHECK(... IN (...)) (PostgreSQL).

DML

Выполните:

• По 2–3 INSERT в каждую таблицу (реалистичные данные: ФИО, даты, цены).
• Дополнительно: напишите один из запросов:
  
  1. Вывести список пациентов, у которых есть незавершённые приёмы (статус ≠ ‘выполнен’) в ближайшие 3 дня.
  2. Для каждого врача — суммарную выручку за последний месяц (по оплаченным счетам).
  3. Создать представление:
     patient_name | dentist_name | procedure_name | app_date | paid_status

💡 Подсказки

• Подумайте: нужно ли вынести specialty в отдельную таблицу? Почему?
• Как обеспечить, что счёт (invoice) создаётся только для завершённого приёма? (Подсказка: триггеры или прикладная логика?)
• Как избежать дублирования цены процедуры в treatment_log, если base_price может со временем меняться?

📖 Контекст (обновлённый)

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

• Учёт пациентов, включая цифровые 3D-модели (ссылки на файлы в облаке).
• Учёт врачей с возможностью нескольких специализаций.
• Запись на приёмы с привязкой к процедуре, кабинету и возможностью повторного визита (например, для установки коронки).
• Детальную историю лечения с поддержкой множественных зубов на одну манипуляцию (через отдельную связь).
• Учёт кабинетов, оборудования и их калибровок/сервиса.
• Выставление счетов до и после приёма (предоплата, постоплата, частичная оплата).
• Систему лояльности: 1 рубль = 1 балл → скидка 1% за 100 баллов.

🧩 Схема БД (уточнённая)

🔹 Связи (обновлённые):

• Один пациент → много записей → много процедур → много зубов.
• Один счёт (invoice) → привязан к одному приёму, но у одного приёма может быть несколько счетов (частичная оплата).
• Только счёт с is_final = TRUE и paid_amount = total_amount считается полностью оплаченным.
• Баллы начисляются при оплате (invoice.paid_amount > 0), с возможностью списания при следующем визите.

✍️ Задание

DDL

Напишите SQL-скрипт (PostgreSQL-совместимый), включающий:

✅ Все таблицы выше
✅ Первичные и внешние ключи (ON DELETE RESTRICT, ON UPDATE CASCADE, где уместно)
✅ NOT NULL, DEFAULT, CHECK-ограничения (особенно для tooth_code, email, paid_amount ≤ total_amount)
✅ ENUM не использовать — вместо этого справочники или CHECK (col IN (...))
✅ Отдельное ограничение: CHECK (paid_amount >= 0 AND paid_amount <= total_amount) в invoice

⚠️ Подумайте: как обеспечить, что loyalty_points обновляется только при подтверждённой оплате? (Подсказка: триггер AFTER UPDATE ON invoice)

DML

1. Вставьте по 2–3 реалистичных строки в каждую таблицу.
   Примеры реалистичных данных:
   
   • ФИО: Иванова Анна Сергеевна, Дроздов Артём Олегович
   • Процедуры: 'Цифровой оттиск челюсти (iTero)', 'Установка циркониевой коронки', 'Художественная реставрация 1 зуба'
   • 3d_scan_url: '["https://dentart.cloud/scans/p123_upper.stl", "https://dentart.cloud/scans/p123_lower.jpg"]'
   • tooth_code: '24' (постоянный), '75' (молочный)
   • parent_app_id: укажите, если приём — повторный
    
2. • Вывести: procedure_name, категория, кол-во выполнений, суммарная выручка, ср. чек
   • Только оплаченные (is_final = TRUE) и paid_amount = total_amountВыберите ОДИН из трёх запросов ниже и напишите его:
     
      

     a) Пациенты с неполностью оплаченными услугами за последние 30 дней:

     • Вывести: patient_name, app_datetime, procedure_name, total_amount, paid_amount, остаток
     • Только приёмы со статусом 'выполнен' и paid_amount < total_amount
     • Отсортировать по остатку (по убыванию)
      

     b) Топ-3 самых прибыльных процедур за квартал (по сумме paid_amount):

📖 Контекст (обновлённый)

Вам поручено спроектировать реляционную базу данных для частного автомобильного сервисного центра премиум-класса «Авто-Элит», специализирующегося на:

• Диагностике с помощью цифровых сканеров (например, ISTA, TechTool, Tesla Diagnostics)
• Ремонте ДВС, гибридов и электромобилей
• Обслуживании под ключ (включая мойку, химчистку, детейлинг)
• Учёте запчастей (новые/OEM/восстановленные/аналоги)
• Гарантийных и постгарантийных работах
• Лояльности: 1 рубль = 1 балл → 100 баллов = 500 ₽ скидки на следующее ТО

Система должна поддерживать:

• Учёт клиентов и их автомобилей (VIN, госномер, марка/модель, год)
• Учёт мастеров с возможностью нескольких специализаций (двигатель, электрика, подвеска, кузов)
• Запись на ТО/ремонт с привязкой к автомобилю, мастеру, боксу и возможностью повторного визита (например: диагностика → заказ запчастей → ремонт)
• Детальную историю работ с поддержкой нескольких запчастей на одну операцию (через отдельную связь)
• Учёт боксов и оборудования (подъёмники, сканеры, зарядные станции), их калибровок и ТО
• Выставление смет до и после работ (предоплата, постоплата, частичная оплата)
• Систему лояльности: 1 ₽ = 1 балл → каждые 100 баллов = фиксированная скидка 500 ₽ (не %, а абсолютная сумма)

🧩 Схема БД (уточнённая)

✍️ Задание

✅ DDL

Напишите PostgreSQL-совместимый SQL-скрипт, включающий:

• Все таблицы выше
• Первичные и внешние ключи (ON DELETE RESTRICT, ON UPDATE CASCADE, где уместно)
• NOT NULL, DEFAULT, CHECK-ограничения:
  
  • vin: длина 17, только буквы/цифры, исключая I/O/Q
  • email: базовая проверка через LIKE '%@%.%'
  • paid_amount ≤ total_amount
  • tooth_code → заменяется на part_code: допустимы цифры, буквы, символы '-', '_', '.'
• Не использовать ENUM — только справочники или CHECK (status IN (...))

💡 Подсказка по триггеру: написать TRIGGER AFTER UPDATE ON invoice → если NEW.paid_amount > OLD.paid_amount AND NEW.is_final = TRUE, начислить баллы (points_earned = NEW.paid_amount), и, возможно, списать (points_used) при создании счёта (это можно учесть в логике приложения или через второй триггер/функцию).

✅ DML

Вставьте по 2–3 реалистичных строки в каждую таблицу.

Примеры реалистичных данных:

• ФИО клиентов: Смирнова Екатерина Дмитриевна, Петров Илья Андреевич
• Машины:
  
  • VIN: WDD1770421J123456, brand: Mercedes-Benz, model: E300, year: 2022, license_plate: А123ВС77, is_ev: false
  • VIN: 5YJ3E1EA9MF123789, brand: Tesla, model: Model Y, year: 2023, license_plate: Т999ОК777, is_ev: true
   
• diag_report_url: '["https://autocloud.ru/diag/WDD177_20241201.json", "https://autocloud.ru/diag/WDD177_dtc.pdf"]'
• work_type:
  
  • 'Полная диагностика ходовой (3D-развал/схождение)'
  • 'Замена охлаждающей жидкости инвертора (Tesla)'
  • 'Компьютерная полировка кузова (3 этапа)'
   
• parent_order_id: укажите, если заказ — продолжение (например, диагностика → замена амортизаторов)

🎓 Контекст (обновлённый)

Вам поручено спроектировать реляционную базу данных для частного образовательного центра премиум-класса «Новый Горизонт», специализирующегося на:

• Подготовке к международным экзаменам: IELTS, TOEFL, Cambridge (FCE/CAE/CPE), SAT, GMAT, GRE
• Индивидуальных и мини-групповых занятиях (до 4 человек)
• Онлайн- и офлайн-форматах с поддержкой записи и повторного просмотра уроков
• Адаптивной программе обучения: диагностика → индивидуальный план → модули → промежуточные тесты → пробные экзамены
• Учёте преподавателей с сертификатами (Cambridge CELTA/DELTA, ETS-certified, GMAT Club verified)
• Системе прогресса: баллы за домашние задания, посещаемость, результаты тестов, личный рейтинг
• Программе лояльности: 1 ₽ = 1 балл → 500 баллов = 1 бесплатный пробный экзамен (IELTS/SAT/GMAT)
• Интеграции с внешними платформами: Zoom (логи уроков), Moodle (материалы), Cambridge English Write & Improve (оценка эссе)

Система должна поддерживать:

• Учёт учеников: возраст, уровень языка (CEFR), целевой экзамен, дедлайн, текущий статус (активный/приостановлен/выпущен)
• Учёт преподавателей с несколькими сертификатами и специализациями (лексика, письмо, speaking, math, critical reasoning)
• Планирование занятий: привязка к ученику/группе, преподавателю, аудитории или онлайн-ссылке
• Детальную историю обучения: модуль → тема → занятие → материалы → домашнее задание → проверка
• Учёт учебных материалов: PDF, видео, интерактивные задания, ссылки на внешние ресурсы
• Генерацию отчётов: прогресс по навыкам (Listening/Speaking/Reading/Writing), динамика баллов, прогноз экзаменационного результата
• Систему напоминаний: дедлайны, пробные экзамены, оплата абонемента

🧩 Схема БД (уточнённая)

✍️ Задание

✅ DDL

Напишите PostgreSQL-совместимый SQL-скрипт, включающий:

• Все таблицы выше
• Первичные и внешние ключи (ON DELETE RESTRICT / CASCADE, где логично)
• Ограничения:
  
  • email: LIKE '%@%.%'
  • cefr_level: CHECK (cefr_level IN ('A1', 'A2', 'B1', 'B2', 'C1', 'C2'))
  • target_exam: CHECK (target_exam IN ('IELTS', 'TOEFL', 'FCE', 'CAE', 'CPE', 'SAT', 'GMAT', 'GRE'))
  • scaled_score в diagnostic_test:
    
    • Для IELTS: BETWEEN 0 AND 9
    • Для GMAT: BETWEEN 200 AND 800
    • Для SAT: BETWEEN 400 AND 1600
      → реализовать через CHECK с CASE или разнести в разные столбцы/таблицы (по желанию — укажите подход)
  • location в session: начинается с 'офлайн:' или равен 'онлайн'
• Используйте JSONB для materials_json, skills_json — добавьте CHECK (jsonb_typeof(...)=’array’) или jsonb_typeof(...)=’object’
• Запрещено использовать ENUM
• Добавьте комментарии: COMMENT ON COLUMN student.cefr_level IS 'Уровень по общеевропейской шкале';

💡 Подсказка по триггеру:
Создайте FUNCTION update_student_cefr() → триггер AFTER INSERT OR UPDATE ON diagnostic_test, который:

• Анализирует skills_json и scaled_score
• Обновляет student.cefr_level (например: IELTS ≥7.5 → C1, ≥8.5 → C2)
• Фиксирует изменение в служебной таблице cefr_log(student_id, old_level, new_level, reason)

 

✅ DML

Вставьте по 2–3 реалистичных строки в каждую таблицу.

Примеры данных:

• Ученики:
  Морозов Артём, 17 лет, CEFR: B2, цель: IELTS 7.5 к 2026-06-15
  Кузнецова Полина, 24 года, CEFR: C1, цель: GMAT 700 к 2025-12-01
• Преподаватели:
  Елена Соколова — CELTA, DELTA, специализация: IELTS Writing & Speaking
  Дмитрий Петров — ETS-Certified, GMAT Club Verified, SAT Math
• Курс и модуль:
  course: 'GMAT Full Prep (6 недель)', target_exam: 'GMAT'
module: 'Quant: Word Problems & Data Sufficiency', order_num: 3
• Сессия:
  scheduled_at: '2025-12-05 18:00', location: 'офлайн: ауд. 205', zoom_link: NULL, status: 'проведено'
• Диагностика:
  type: 'IELTS Mock Test #1', date_taken: '2025-11-20', raw_score: NULL, scaled_score: 6.5, skills_json: {"listening":7.0, "reading":6.5, "writing":6.0, "speaking":6.5}
• Домашка:
  homework_text: 'Написать эссе по теме: Some people believe that unpaid community service should be compulsory in high school. To what extent do you agree?', score: 82, is_late: false

🌠 Контекст (обновлённый)

Вы — главный архитектор базы данных в AstroLogix, частной космической логистической компании, которая:

• Запускает малые и средние грузовые миссии на Луну (LRO, южный полюс) и Марс (Jezero Crater, Hellas Planitia);
• Клиенты:
  
  • Научные лаборатории (NASA, ESA, CNSA, частные — например, Helios Labs);
  • Коммерческие поселения (LunaBase Alpha, MarsHab-2);
  • Туристические корпорации (Orion Excursions — «лунные выходные» для сверхбогатых);
• Использует собственные многоразовые транспортные модули:
  
  • Hermes-1 (лёгкий, до 500 кг, Луна);
  • Odyssey-M (средний, до 2.5 т, Марс, с аэродинамическим торможением);
  • Valkyrie-C (тяжёлый, 8 т, возвращаемый модуль с термозащитой);
• Все миссии — автономные или с минимальным дистанционным контролем (6–22 мин задержка связи);
• Поддерживается инвентаризация грузов с учётом массы, энергопотребления, радиационной устойчивости, герметичности;
• Обязательно:
  
  • Сертификация грузов по COSPAR Planetary Protection Policy (Класс IV-C для Марса!);
  • Ограничение массы по этапам: старт → ТО → орбита → посадка;
  • Криогенные системы: жидкий водород/кислород, поддержание до −253 °C;
  • Резервирование жизненно важных систем (N+2 redundancy);
• Есть система баллов «Orbital Credit»:
  
  • Партнёры получают кредиты за публикации, open-source ПО, совместные миссии → обменивают на скидки или приоритет запуска;
• Интеграции:
  
  • NASA Horizons API (траектории),
  • SpaceTrack.org (данные по орбитальному мусору),
  • ESA’s Moonlight (лунная навигация GNSS),
  • Mars Relay Network (марсианские ретрансляторы: MRO, TGO, Tianwen-1).

🧩 Схема БД (AstroLogix Core Schema)

✍️ Задание

✅ DDL (PostgreSQL)

Напишите SQL-скрипт, включающий:

• Все таблицы выше (можно опустить supply_chain и craft_component, если хочется упростить);
• Первичные и внешние ключи с обоснованным ON DELETE (RESTRICT для миссий, CASCADE для логов и расписаний);
• Ограничения:
  
  • email — валидный формат;
  • target_body, pp_class, prop_type, type (в mission, spacecraft, trajectory) — через CHECK;
  • mass_kg, power_w, volume_m3 > 0;
  • hazard_zones_json — jsonb_typeof = 'array', и каждый элемент — объект с zone, t_start, t_end (используйте jsonb_path_exists);
  • delta_v_km_s BETWEEN 0 AND 25;
  • severity в anomaly_log: BETWEEN 1 AND 5;
• Комментарии ко всем колонкам (на русском или английском — по желанию);
• ✨ Триггер:
  Создайте FUNCTION check_mass_budget() → BEFORE INSERT OR UPDATE ON payload, который:
  
  • Считает общую массу всех payload в миссии;
  • Сравнивает с max_payload_kg соответствующего spacecraft (через mission_craft);
  • Если превышение — RAISE EXCEPTION 'Payload mass exceeds spacecraft capacity!';
  • Дополнительно: логировать попытки в mass_violation_log(mission_id, attempted_mass, allowed_mass, timestamp).

✅ DML

Вставьте реалистичные данные (2–3 строки на таблицу), например:

• Миссия: «Luna-Resupply-7», запуск: 2026-Q1, цель: LunaBase Alpha, груз — кислородные картриджи + модуль 3D-печати реголита;
• КА: Hermes-1 «Arachne», reuse_count = 4, с компонентами: «RadiationShield-Mk3», «NavStar-S2 GNSS receiver»;
• Груз: «Regolith Sintering Printer v2.1», pp_class = 'III', mass_kg = 320, temp_max = 85;
• Аномалия: severity = 3, system = 'thermal', description = 'Coolant loop pressure drop in lander leg #2';
• Организация: Helios Labs (research_lab, USA), получила 1500 Orbital Credits за open-source ПО «TrajSim-Core».

Сделать БД по ER-диаграмме:

(Прямая ссылка)

Сделать ER диаграмму по шаблону:

Делать тут

Потом по этой ER диаграмме написать код БД.

🌠 Контекст (обновлённый)

Вы — главный архитектор базы данных в Stellar Dynamics, частной компании по орбитальному сервису и удалению космического мусора, которая:

• Специализация: обслуживание, дозаправка, ремонт и утилизация спутников на всех орбитах (LEO, MEO, GEO, HEO);

• Клиенты:

  • Спутниковые операторы (Starlink, OneWeb, Iridium);

  • Государственные агентства (Роскосмос, ISRO, JAXA);

  • Коммерческие компании (Planet Labs, Maxar);

  • Страховые компании (Lloyd’s of London — оценка рисков);

• Использует собственные сервисные аппараты:

  • Orbital-Tug Mk.I (легкий, до 500 кг полезной нагрузки, LEO/MEO);

  • GeoServant (средний, до 2 т, GEO/HEO, с манипуляторами);

  • DebrisCollector (тяжелый, 5 т, сбор мусора с сетями и гарпунами);

• Все операции — автономные с поддержкой AI-планировщика (задержка связи до 5 секунд для LEO);

• Ведётся реестр объектов с учётом массы, баллистического коэффициента, класса опасности, орбитальных параметров;

• Обязательно:

  • Сертификация по ISO 24113 (орбитальное пространство);

  • Расчёт вероятности столкновения (Pc) по алгоритму CARA/ODQN;

  • Система раннего предупреждения о сближениях (<1 км);

  • Резервирование систем управления (N+3 redundancy);

• Есть система рейтинга «Orbital Stewardship Points»:

  • Операторы получают баллы за своевременное уведомление о манёврах, передачу телеметрии, утилизацию аппаратов → скидки на услуги;

• Интеграции:

  • Space-Track.org API (TLE, CDM);

  • ESA’s DRAMA/MASTER (модель мусора);

  • NASA’s CARA (оценка рисков);

  • Satellite Catalog (SATCAT);

  • AGI’s STK (расчёты);

🧩 Схема БД (Stellar Dynamics Core Schema)

✍️ Задание

✅ DDL (PostgreSQL)

Напишите SQL-скрипт, включающий:

1. Все таблицы выше (можно опустить component_inventory и craft_component, если хотите упростить);

2. Первичные и внешние ключи с обоснованным ON DELETE:

   • RESTRICT для mission_target и mission_servicer;

   • CASCADE для anomaly_report и fuel_log;

3. Ограничения:

   • contact_email — валидный формат (REGEXP);

   • mission_type, orbit_type, object_type, propulsion_type — через CHECK;

   • mass_kg, max_fuel_kg, cross_section_m2 > 0;

   • attitude_quaternion_json — jsonb_typeof = 'object', должен содержать поля q0, q1, q2, q3 с значениями от -1 до 1;

   • probability в collision_risk: BETWEEN 0 AND 1;

   • severity в anomaly_report: BETWEEN 1 AND 5;

   • miss_distance_m > 0;

4. Комментарии ко всем колонкам (на русском или английском — по желанию);

5. ✨ Триггер:
   Создайте FUNCTION check_fuel_capacity() → BEFORE INSERT OR UPDATE ON fuel_log, который:

   • Проверяет, не превышает ли amount_kg доступную ёмкость баков (max_fuel_kg) сервисного аппарата;

   • Если remaining_kg после заправки превышает max_fuel_kg → RAISE EXCEPTION 'Fuel capacity exceeded!';

   • Дополнительно: логировать попытки в fuel_violation_log(craft_id, attempted_amount, max_capacity, timestamp).

✅ DML

Вставьте реалистичные данные (2–3 строки на таблицу), например:

1. Миссия: «Starlink-3015 Refuel», mission_type=’refueling’, orbit_type=’LEO’, priority=’high’;

2. Сервисный аппарат: GeoServant «Athena», model=’GeoServant’, max_fuel_kg=1200, propulsion_type=’electric’;

3. Целевой объект: NORAD 25544 (Starlink-3015), object_type=’active_satellite’, mass_kg=260;

4. Риск столкновения: probability=0.003, miss_distance_m=850, risk_level=’medium’;

5. Заправка: fuel_type=’xenon’, amount_kg=45, purpose=’rendezvous maneuvers’;

6. Аномалия: severity=2, subsystem=’thermal’, description=’Radiator surface temperature 5°C above nominal’;

7. Организация: SpaceX (commercial, USA), получила 5000 Stewardship Points за своевременное уведомление о манёвре.