我正在为我们公司开发一个 BI 系统，从头开始，目前，我正在设计一个数据仓库。我对此完全陌生，所以有很多我不太了解的东西，所以我需要听到更多关于这方面的见解。
我的问题是：
1) 在我们的源系统中，有名为“Booking”和“BookingAccess”的表。预订表保存预订的数据，例如入住时间和退房时间、预订日期、预订编号、预订总额。
而在 BookingAccess 中，它保存与预订相关的外键，例如 bookerID、customerID、processID、hotelID、paymentproviderID 和该预订的当前状态。Booking 和 BookingAccess 具有 1:1 的关系。
我们的源系统是关于检查这些预订的有效性，这些预订不是我们的。我们从其他来源收到这些预订信息，为他们外包上述流程。总金额只是我们需要验证的预订信息，它们不是我们业务的一部分。BookingAccess 表中保留的预订的当前状态是我们系统中该预订的当前状态，可以是“处理中”或“已完成”。
根据我从 Ralph Kimball 那里读到的内容，在这种情况下，“Booking”是维度表，而 BookingAccess 应该是事实。我觉得 BookingAccess 有点像[累积快照表]，我应该在其中跟踪预订“处理”和预订“完成”的时间。
我做对了吗？
2）在“Booking”表中，还有一个外键叫做“ImportID”。此键链接到名为“导入”的表。此“导入”表保存已导入我们系统的文件的历史记录（这些文件包含将写入“预订”表的预订），包括文件名、导入日期、导入的总预订......
从我的角度来看，这显然是一个事实表。
但问题是，“导入”表和“预订”表具有一对多的关系（“导入”表中的 1 个 ImportID 可以有 1、2 个或更多记录，它们在“预订”表中具有相同的 ImportID ）。这与事实表的想法相悖，事实表坚持事实和维度之间的关系必须是多对一的，事实总是在多方面。
那么我应该使用什么方法来解决这种情况呢？我正在考虑使用桥接表来解决这个问题。但我不知道这是否是一个好习惯，因为“导入”表中有很多记录，所以我必须创建一个大的桥表来涵盖所有这些。
3）我应该将包含关系和信息混合的表（来自源系统）与仅包含关系的事实表和仅包含信息的维度表分开吗？（例如，源系统中名为“客户”的表。该表包含客户名称、客户地址和客户类型 ID、客户父 ID 等内容。）
我问这个是因为我觉得如果我使用 BI 工具来分析事物（例如，分析 customertypeid = 1 的客户数量），如果没有涉及事实表，我觉得这有些奇怪。
或者我应该把它当作一个单纯的维度表并使用雪花模式？但这会导致我们的数据仓库中混合使用星型模式和雪花模式。这是正常的吗？我已经阅读了一些官方资料（很可能是 Oracle），指出应该尽量避免使用和混合雪花模式。但微软等一些消息人士称，这是非常正常的。甚至Advanture Work Data Warehouse 示例数据库也使用这种方法。
或者我应该对“客户”表中的每个关系进行反规范化吗？但我认为这不是一个好方法，因为它会使 Customer 包含很多列，并且很难跟踪“DIM_Customer”表中每一行的历史记录。例如，如果“客户”表的任何关系发生任何变化，则需要更新整个“DIM_Customer”表。
关于数据仓库，我还有很多问题。我几乎独自一人使用它，没有任何帮助或顾问。如果我犯了任何不便或错误，请原谅我。