我正在读一本关于数据仓库的书。它告诉，如果我有一个日期时间数据，我应该将其存储为单独的列：年、月、日期和原始日期时间（以毫为单位）。它是用于聚合目的的（另请参见更新部分）-用于按日期、月份等进行聚合。但是，如果我需要不同时区的聚合，该怎么办？是的，可以在UI上显示UTC+时区，但如果业务部门希望在"转换"的日期段上看到聚合，而不希望看到该日期在00:00+07开始，该怎么办？
注意
可以计算每个时区的每个时间聚合（年、月、日），但这需要太多的计算（据我所知）
也许还有更好的方法？还是每个时区的每一次计算都是一个通用的解决方案？
更新
关于聚合。我所说的聚合是指有一个进程按计划运行（它首先对所有数据运行，然后只对新的聚合按计划运行）。因此，在这个过程中，当它"看到"新数据时，它会计算所有列的聚合。例如，假设数据是客户订单，它有成本、用户id和日期。因此，处理带有1个剪切订单的抓取行，并将这些信息"添加"到几个OLAP多维数据集单元格中：日、月和年。假设客户在22.06.2015上用$1下订单。此订单数据（通常为成本）"添加"在以下OLAP单元格中：22天、06月和2015。我不是合格的OLAP设计师，单元格可能不同（例如，它可以添加到22.06而不是22），但其想法是将数据放入单独的单元格中，用于查询优化目的，例如，从一个立方体单元格22.06.2015中选择成本总和要快得多，而不是在22.06.2015上运行所有订单的计算。但在这种情况下，设计日从UTC开始，如果我需要从不同的时区开始呢？通过这种方法，数据聚合增加了24倍（
将日期存储在UTC中并在UI上显示偏移量是一种常见的做法，但在OLAP设计中，当我需要预先计算时，这种做法并不常见。
但首先，在级别上定义"仓库谷物"，这将使其他聚合/计算更容易进行和维护。
在我看来，您应该在数据仓库和ETL级别上"处理和映射"这种业务需求。是的，将每个日期级别放在单独的列中，您将能够使聚合"简单明了"。不要担心添加另一个级别，如"24小时聚合"。OLAP就是为这种方法构建的。
如果您想避免额外的聚合，请创建专用的数据集市。事实表将是一个累积快照，而不是事务事实。Next创建了Dim"UTC"来处理您的需求。您将把聚合工作从OLAP级别转移到ETL级别。
希望得到帮助。