We were starting the eDWH in the early 2000 by impleting the FS-LDM as a physical model (more or less, slightly adapted to our needs).
This is working fine, but there are also, let's say from business side, remarks on the implemented PDM, especially on the 'complexity' (you need to join a lot of tables...)
The FS-LDM itself was growing and changing all over the time by every new release. But also the insights on how to implement a PDM was changing the last years.
My question: is there a good reference book | 'orange book' | article that describes in detail how nowadays a LDM is tranformed into a PDM on Teradata? Topics about denormalization, info over building blocks (datamarts), etc.?
Thanks for the suggestions.
With all current Industry Data Models we provide what we refer to as the Physical Design Concepts Reference Manual. While not exactly a "How To" manual, it does walk through the decision making processes involved in moving from a Third Normal Form LDM to an implemented PDM, identifying the risk-reward factors involved in the various decision points. If AXA has a subscription to the FSDM (formerly FS-LDM) then they would have access to this document.
There are process documents that I have seen utilized in presentations for logical to physical modeling engagements but I am unsure of their availability outside of the company. You may want to speak with someone on your Teradata support team about whether or not there are documents that you may access directly.
I should also mention that we have just added some instructor led courses to the Teradata Education Network that have several modules built around the transition from logical to physical model. Course number is 55545.
Are the iLDM models intended to be physically architected as updateable or as insert only?
For example, would you update ACCOUNTS or EVENTS or always expire and add new rows?
Either - depends on the bsuiness requirements. Generally the business requires the history of an account so it would be likely that Account is defined to save the expired rows. Events however often is not updated or only a tiny portion of the events are editted or fixed after the fact and it is often not important to keep the changes that happen to an event row. iLDM is designed for either and the physical should implement the business requirements - simply leave out the effective dates if the history is not to be kept.
P.S. When history is to be kept with its effective dates, it is a great opportunity to implement Teradata Temporal capabilities.