Рассматривать их как «прошлые» и «будущие» данные немного вводит в заблуждение - потому что, как вы сказали, есть веские причины, по которым любой тип данных может потребоваться обновить после первоначальной загрузки в хранилище данных.
Вместо этого я предлагаю думать об этих данных как о «запланированном» и «фактическом» отпуске. Надеемся, что после этого станет яснее, что оба типа могут иметь отношение к загрузке и последующему обновлению в хранилище данных.
Это связано с тем, что отчетность и анализ могут потребоваться как для планового, так и для фактического отпуска (поэтому загрузка обоих типов в DW актуальна). Кроме того, ваш запланированный отпуск может измениться, и ваш фактический отпуск может потребоваться исправить в исходной системе после начальной загрузки (поэтому актуально обновление обоих типов в DW).
Если запланированный отпуск данные go в хранилище данных?
Это субъективно и полностью зависит от ваших вариантов использования.
В общих чертах, целью хранилища данных является эффективное хранение и запрашивать большие объемы данных. На практике это часто делается для целей бизнес-отчетности (например, на конец месяца, на конец года) и аналитики.
Таким образом, соответствие данных запланированных отпусков приведенным выше зависит от контекста вашей организации и пользователей, и понимание того, какая коммерческая ценность имеет (или нет) хранение этих данных в хранилище данных.
Как вы управляете обновлениями при изменении исходных данных?
Прочитайте это сообщение в блоге Джеймса Серры . Хотя он немного устарел (опубликовано в 2011 году), в целом концепции все еще актуальны, и он действительно хорошо объясняет некоторые ключевые концепции.
Из этой статьи есть два подхода к загрузке данных в хранилище данных:
- Полное извлечение: все данные полностью извлекаются из исходной системы. Поскольку это извлечение отражает все данные, доступные в настоящее время в исходной системе, нет необходимости отслеживать изменения в исходных данных с момента последнего успешного извлечения.
- Инкрементальное извлечение: будут извлечены только те данные, которые изменились с указанного c момента времени в истории. Этот момент времени может быть временем последнего извлечения или деловым событием, таким как последний день финансового периода. Чтобы идентифицировать это дельта-изменение, должна быть возможность идентифицировать всю измененную информацию, поскольку этот конкретный c момент времени.
Полное извлечение простое, но неэффективное для больших объемов данные.
Инкрементальное извлечение более эффективно, но для него требуется способ идентификации дельты - то есть записи в исходных данных, которые являются новыми, или были изменены или удалены с момента последней загрузки. В статье Джеймса изложены некоторые подходы к этому. Эта статья об отслеживании изменений на SQL Server также может быть полезна.