Is AdventureworksDW's FactInternetSales an accumulating snapshot table?

Question

I always wonder if the FactInternetSale table of the AdventureworksDW is a accumulating snapshot table. It has a ShipDateKey in it.

According to the AdventureWorks OLTP documentation, it says that the ShipDate of the SalesOrderHeader is the date that "the order was shipped to customer". I interpret this line as, when the order is shipped, the ship date will be updated.

That also means the rows in the DW FactInternetSale will also need to be updated as well. The ship date marks the an important milestone of an order and this is clearly the behavior of an accumulating snapshot fact table.

So should this table be considered an accumulating snapshot fact table? If so then is there any problem that there is no real transaction fact table?

In the Kimball's data warehouse toolkit book, in this kind of problem, he separates the Order transaction fact table and the Shipping Fact table very strictly, with the Order Transaction Fact table only contains only the information which is recorded when the order is made, and will not be updated. The dates in the Order Transaction Fact table are always expected date, not the real date. The shipping fact table contains the true ship date of an item. After that there is an accumulating snapshot fact table that contains all the important milestones of an order. Not only the ship date, but also other important milestones... By having dates of important milestones, we of course can know the current status of the order.

In my personal opinion, I consider that the Order Fact Table that does not contain the current status of it is totally useless. What is the point of knowing the total amount of orders but cannot know how much is from fulfilled (shipped) ones and how much is from unfulfilled ones? In my experience, users (data analysts) will always just use the accumulating snapshot table to do their job all the time, as the search predicate of "current status" is never absent in their query.

In my real world, I usually design this Order (information) fact table as a accumulating snapshot straightforwardly, skipping the transaction fact table (like what Kimball does, strictly separates things), as I feel that is very time-consuming and have no use. The transaction fact tables are usually just the actions done on the order (for example: shipping).

How do you think about this?

Answer 1

No, it's not an accumulating snapshot fact table

Answer 2

No, it's not an accumulation fact table.
Explanation:
Accumulating fact table has plenty of field dates, such as: Data Requested, Expected Ship Date, Actual Ship Date, etc. Initially, these fields could be NULL and after a while to be updated. The table in FactInternetSales has only one field date, and it doesn't seem to be updatable in the workflow.

More information: https://www.holistics.io/blog/the-three-types-of-fact-tables/

A fact table is expected to have dates. The additional information of many dates and lag information is what makes it Accumulating.