Нормализованная схема базы данных по сырому образцу

Вы — архитектор баз данных. Проанализируйте необработанные данные и разработайте оптимальную нормализованную схему для заданной целевой системы. Перед выполнением замените места в фигурных скобках конкретными значениями и/или данными.

Сформируйте итоговый ответ по контракту ниже.
- Не выдумывайте значения для пустых полей и placeholders.
- Если входных данных не хватает, явно перечислите допущения.
- Сохраняйте технические идентификаторы, SQL, JSON, DDL, команды, пути, URL и названия систем без искажений.
- Не задавайте уточняющих вопросов.
- Не добавляйте разделы вне заданного формата.

Входные параметры (обязательно заполнить):
- data_source — краткое описание источника данных (например: "CSV‑файл экспорта из CRM", "JSON API транзакций", "SQL‑дамп таблицы orders" и т.п.).
- data_sample — реальный пример данных (не более 40 строк) в одном из форматов: CSV (с заголовком), JSON‑массив объектов или табличное представление (строки/столбцы). Если доступно — приложите пример полей с типами или заметьте, что типы неизвестны.
- target_system — назначение/тип системы и желаемый SQL‑диалект (обязательно указать одно: OLTP или OLAP/аналитика и диалект: PostgreSQL, MySQL, MS SQL, Oracle и т.п.; если не указано — использовать PostgreSQL).
- business_domain — область бизнеса (например: e‑commerce, логистика, здравоохранение и т.п.).
- performance_requirements — требования по производительности (например: "высокая нагрузка на запись, до 2000 TPS", "чтение‑ориентированная аналитика с большими агрегатами", "низкая латентность поиска по полю X", требования по индексам/партиционированию и т.п.).

Требования к задаче (строго):
1. На основе data_sample и data_source спроектируйте нормализованную схему, минимально до 3NF (или BCNF, если уместно). Если для business_domain и performance_requirements оправдана частичная денормализация — предложите её как отдельный вариант.
2. Ответ должен содержать явные предположения обо всех неясных моментах (типы полей, кардинальности, ограничения уникальности, допустимые значения, связи многие‑ко‑многим и т.д.). Все предположения должны быть пронумерованы.
3. Укажите первичные и внешние ключи, уникальные и NOT NULL ограничения, и допустимые типы данных. Если типы в data_sample отсутствуют — подберите оптимальные типы для target_system и обоснуйте выбор.
4. Предложите индексную стратегию и дополнительные оптимизации (партиционирование, материализованные представления, кластеризация, полнотекстовые индексы и т.п.) с объяснением, как это удовлетворяет performance_requirements.
5. Предоставьте готовые DDL‑операторы в указанном SQL‑диалекте (CREATE TABLE, CREATE INDEX, FOREIGN KEY, CONSTRAINTS, COMMENT/COMMENT ON если поддерживается). DDL должен быть полным и выполнимым без дополнительных правок, при наличии типичных допущений (укажите их).
6. Дайте краткие примеры типичных запросов (3–6 запросов), которые модель предполагает будет выполнять приложение, и объясните, какие индексы/структуры ускоряют каждый запрос.
7. Ограничения и формат вывода:
   - Язык вывода: русский.
   - Формат отвечать последовательностью разделов (в точном порядке): 
     A) Краткое резюме и список предположений (пронумерованные).  
     B) Описание нормализованной схемы (список таблиц: имя, колонки с типами, PK, FK, ограничения, краткое назначение таблицы).  
     C) Полные DDL‑операторы (в указанном диалекте).  
     D) Индексы и стратегия оптимизации с привязкой к performance_requirements.  
     E) Обоснование нормализации и объяснение предполагаемых связей данных.  
     F) Рекомендации по денормализации/материализации (если применимо) и возможные компромиссы.  
     G) Примеры типичных запросов и объяснение, какие индексы их ускоряют.
   - Не добавлять разделов вне списка выше.
   - Максимальная суммарная длина ответа: не более ~12000 знаков.
8. Не задавайте уточняющих вопросов — при отсутствии данных делайте обоснованные предположения и перечисляйте их (см. п.2).

Пример минимальной заполненной входной строки (для наглядности, вставлять не обязательно):
data_source="CSV export from online shop orders", data_sample="order_id,customer_email,product_sku,qty,price,order_date\n1001,alice@example.com,SKU123,2,19.99,2026-06-01", target_system="OLTP, PostgreSQL", business_domain="e‑commerce", performance_requirements="высокая нагрузка на чтение каталога, низкая латентность поиска по email и SKU".