Всем привет!
Прошу не судить строго, сейчас только разбираюсь в теме:)
Застропорился на том, - как правильно организовать структуру данных на этапе трансформации.
На данный момент у меня 2 схемы в БД - stage и сам dwh. Проблема в следующем:
1. На входе есть большая плоская таблица с регистрацией автомобилей, с полями - "почтовый индекс", "номерной знак", "место регистрации";
2. В данной таблице присутствуют пропуски по этим 3-м полям и я решил сделать составной ключ, который проверяет, есть ли поле "почтовый индекс", если нет - "номерной знак" и далее "место регистрации" и на его основнии я заполняю регион, где зарегистрирован автомобиль;
3. Вопрос в том, где хранить эти 3 таблицы с фиксированными данными, на основании которых производится "склейка". На stage этапе, не по книжке, так как данные там надо удалять:) А в dwh в dimensions они мне по сути не нужны, и тоже вроде как не правильно...
4.Также вопрос в том, что было бы неплохо также туда вносить отсуствующие значения из сырых данных, чтобы их потом дополнять.
Заранее спасибо за помощь!

Вобщем решил создать еще одну схему service_dir, где буду хранить справочники с фиксированными данными, таккже перекину туда функции и ХП для очистки данных.

StarikNavy,
Спасибо!
Постараюсь более складно объяснить, я вложил фото схемы dwh, как я сделал изначально.
Я создала в dwh следующие таблицы:
1. dim_koatuu - содержит в себе данные по полную информацию по териториальному делению (область, район, населенный пункт и т.п.), она в дальнейшем будет выступать как dimension, для опредения региона;
2. dim_plates_region - содержит привязки, "тип номерного знака - регион - ссылка на код КОАТУУ", она нужна только для заполнения составного ключа;
3. dim_tsc_dep - содержит привязки "сервисный центр МВС - адрес - ссылка на код КОАТУУ", в принципе она тоже нужна только для заполнения составного ключа.
4. Залил в них дефолтные данные;
5. В фактовой таблице, я создал поле "koatuu_composite_key", которое заполняется при заливке данных из stage таблицы, в порядке наличия данных в полях dim_koatuu, dim_plates_region, dim_tsc_dep.
Все как-бы работает, но чувствую, что не по феншую:)

Критик,
Спасибо, НСИ вроде как раз то, что я искал!

Критик,
Ещё раз спасибо за помощь и критику.
Я писал, что это был первый вариант, как я сделал. Я все сразу запихал в dimensions, сейчас переделаю.
По пункатам:
1. В Country хранится абривиатура ua, us и т.п.
2. Поля null я сделал, чтобы из входной таблицы добавлять новые отсуствующие данные и потом их обрабатывать;
3. Сджойнить соответственно потом можно будет, после того как заполню отсуствующие данные.
Почитал про НСИ и хотел задать вопрос, так все-таки эти таблицы лучше хранить в отдельной схеме или вообще в отдельной бд и как их наполнять, если мои ответы 2 и 3 неверные?
Спасибо!

Гулин Федор,
Спасибо!
Вчера друг DWHшник, просветил как можно реализовать. Выкинуть пару столбцов и оставить все в dwh "снежинка", для начала, чтобы не путиться и запустить. А потом когда Кимпбала дочитаю уже разгрести. Сейчас занимаюсь:)
Я делаю на Python и Postgres, чтобы потом перенести на Airflow.
Это мне нужно и для учебы и для текущей работы, поэтому и парюсь именно с этими данными...
Из примеров в интернете, мне очень понравился: https://github.com/gtoonstra/etl-with-airflow . Но он там на "чистых" данных работает, а у меня тут 50% мусора.