[dba-SQLServer] AdventureWorks --> AdventureWorksDW

Does anyone have an URL or other info source on how the transition was made
from AW to AWDW? What underlies the decisions made, etc. I can play with
both but the deductions and the amalgamations and the aggregates baffle me.

Mostly unrelated question: given a bunch of data about stock prices at
moments in time, and quantities bought and sold, how might I build a cube
out of all this? At first blush, I would guess that trader, stock and date
are obvious dimensions. I want things out of this like moving averages and
position and so on, but I am totally unsure how to go about creating the
cube based on these dimensions. I'm reading Analysis Services Step by Step
but it is so literal (step by step) that I don't feel that I'm learning
anything about the larger picture.

My current app ignores cube technology completely and instead rolls up
everything since the beginning of time. My thought is that the past is the
past, and can be rolled up, and then we look at the past plus the present
(e.g. say the threshhold is beginning of last month, all the past data is in
the cube and all the current data is in the OLTP db; this requires an
amalgamation of the past with the present; I think this would be way faster
than our current "since the beginning of time" approach, but I am unsure how
to implement it.)

One small example is let's call it PersonOfInterest. That means a trader
whose details are normalized into a dozen tables. In the AS version, should
I denormalize all this detail and create a bunch of largely redundant rows
so that lookups are no longer required? On the other side of it, a stock
resides within a sub-industry which lives in an industry which lives in a
sector. Should all this be denormalized in the OLAP db? The aforementioned
"Step by Step" book touches not at all on this subject.

Currently my thought is that denormalization is the way to go: that I start
with the normalized Person data and create a view or something that grabs
all the data about said Person from let's say 12 tables and presents it as a
single table with all the FKs resolved already. This single table will then
be joined in the OLTP db to various items, but will avoid all the ancillary
lookups. Apply the same logic to Products, which have a ProductType and a
ManufacturerID and so on... so in the transition I denormalize all this and
end up with a dimProducts table. These tables will obviously be much larger
than the original source, but they will reduce the number of joins from 20
to say 3. Then we sum everything (bicycle sales by brand by customer by
salesperson by region etc.) and write a db which is considerably larger than
the OLTP version, but which has all the answers we want by visiting only one
or perhaps a few rows rather than doing all the legwork required in the OLTP
version of the db.

Do I have the picture right, or at least vaguely right?

Advice, URLs and other sources eagerly invited.

TIA,
Arthur