Мы работаем над хранилищем данных для банка и в значительной степени следуем стандартной модели Kimball промежуточных таблиц, звездной схемы и ETL, чтобы вытащить данные через этот процесс.
Kimball рассказывает об использовании промежуточной области для импорта, очистки, обработки и всего, пока вы не будете готовы помещать данные в схему звездочек. На практике это обычно означает загрузку данных из источников в набор таблиц с небольшой или никакой модификацией, за которыми следует выбор данных через промежуточные таблицы, пока он не будет готов перейти в схему звездочек. Это большая работа для одного объекта, здесь нет единой ответственности.
Предыдущие системы, над которыми я работал, сделали различие между различными наборами таблиц, в том числе:
Вы можете вставлять их в отдельные схемы, а затем применять разные политики для архивации/резервного копирования/безопасности и т.д. Один из других парней работал на складе, где есть StagingInput и StagingOutput, аналогичная история. Команда в целом обладает большим опытом, как хранилищем данных, так и другим.
Однако, несмотря на все это, просматривая Кимбалл и Интернет, в письменной форме ничего не говорится о предоставлении какой-либо структуры промежуточной базе данных. Можно было бы простить, полагая, что г-н Кимбалл хотел бы, чтобы мы все работали с постановкой этого большого глубокого темного неструктурированного пула данных.
Хотя, конечно, довольно очевидно, как это сделать, если мы хотим добавить еще какую-то структуру в промежуточную область, кажется странным, что в ней ничего не написано.
Итак, что делают все остальные? Является ли постановка этой большой неструктурированной беспорядком или у людей есть интересные проекты?
У меня возникла та же проблема. У нас большой HR DataWarehouse, и я извлекаю данные из систем по всему предприятию. У меня есть хорошая коллекция таблиц фактов и измерений, но область постановки - беспорядок. Я не знаю никаких стандартов для этого. Я бы пошел по тому же пути, что и вы, и придумал стандартный набор имен, чтобы все было в порядке. Ваше предложение довольно хорошо для именования. Я бы продолжал работать с этим.
Просто записка, есть книга под названием "The Data Warehouse ETL Toolkit" от Raph Kimball и Joe Caserta, поэтому г-н Кимбалл приложил к этому некоторое усилие.:)
В настоящий момент мы работаем над большим проектом DWH для страхования, его немного сложно, но каждая из исходных системных таблиц помещается в отдельную схему в базе данных STAGING, тогда у нас есть ETL, который перемещает/очищает/совместим (MDM ) данные из промежуточной базы данных в базу данных STAGINGCLEAN, а затем еще ETL, которая перемещает данные в DWH Kimball.
Разделение базы данных Staging и StagingClean очень полезно при диагностике проблем, в частности, по качеству данных, поскольку у нас есть грязные поэтапные данные, а также очищенная версия до того, как она преобразуется в собственно DWH.
В разделе "Стадии" могут быть подчиненные области. Вызывается staging1, staging2, например.
Staging1 может быть напрямую вытащен из источников данных без преобразования. И Staging1 сохраняет только самые последние данные.
Staging2 сохраняет данные, преобразованные и готовые к работе на складе. Staging2 хранит все исторические данные.
Взгляните на этот пост здесь. Он дает хороший обзор обязанностей промежуточной области в DW.
Какой великий вопрос.
В прошлом мы использовали суффикс _MIRR (для зеркала) для нетрансформированных данных, помещенных в базу данных, т.е. он отражает источник. Затем мы используем _STG для преобразованных данных из источника, затем _DW для звездной схемы.
Таблицы промежуточного уровня здесь будут находиться в 3NF. Я думаю, что это ключевой момент. Данные приземляются непереведенными и сохраняются отдельно от следующего шага, где мы полностью нормализуем данные, а затем сглаживаем все это в нашу звездную схему для отчетности.
Лично я не ищу проблем, в Кимбале или в другом месте.
Какую "структуру" вы ищете? Какая "структура" вам кажется необходимой? Какие проблемы вы видите из-за отсутствия "структуры" у вас сегодня?
Я могу оставить вас с впечатлением, что я не очень много думаю о Кимбале. Не так - я не читал Кимбалла. Я просто не думаю, что многое изменилось без каких-либо причин, кроме подгонки какого-то шаблона. Изменение для решения какой-то реальной проблемы было бы неплохо. Например, если вы обнаружите, что выполняете резервное копирование промежуточных таблиц, потому что отсутствие структуры заставляло обрабатывать таблицы промежуточной и складской таблиц одинаково, тогда это было бы причиной для изменения структуры. Но если это то, что вы имели в виду, тогда вы должны отредактировать свой вопрос, чтобы указать его.