Archives of the TeradataForum

Message Posted: Thu, 02 Feb 2006 @ 16:15:21 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

<-- Anonymously Posted: Thursday, February 02, 2006 11:09 -->

You have been given plenty of tech advice. Here's a different perspective.

Having designed databases for environments in ORACLE, SYBASE, INGRES, DB2, and now TERADATA I am quite glad to see that denormalization is one physical design technique I have never had to reach for in Teradata because if its amazing speed. Denormalization is an exercise in risk management where you trade off speed for the robustness of the database to grow and be resilient to change. In my last database design for a medical billing environment I used denormalization (repeating groups) to the chagrin of a colleague of mine (a purist) but I had no choice if the business were to process 300M medical charges every night in a DB2 box. Denormalization was carefully evaluated and the risk deemed very low that we would gain a new instance of a repeating group because the whole industry would have to change (an unlikely scenario, but would not put that past Medicare)

My approach for DW design is to develop a data model in 3NF where data mining operations are performed and to create additional Dimensional Models to handle BI operations. ETL populates the 3NF, and then the 3NF populates the Dimensional Model. Thanks to Join Indexes a lot of that work is automatic. Thanks to this approach we are able to run two very large systems using the smallest Teradata footprint possible and we are adding a new application in less than a month. We achieved the goal 3 very large applications in 14 months, from unpacking boxes to unveiling the newest application and the staff does not exceed 10 people.

You have been advised to avoid data modeling and a data administration programme to manage the Datawarehouse environment. That's contrary to what the consulting firm that advised my current employer when they were considering a DW investment. They were advised to bypass their current DBA staff and instead find a Data Administrator to perform the duties of Data Architect and DBA. They are very glad they followed that advice. A Data Administrator can perform the duties of a Teradata DBA (a quite simple duty given Teradata's advanced environment) but also understands the business functions and the data. A DA is able to develop the data models that become the blueprint for the actual database and serve as the genesis for all the development that follows.

The business is so impressed with the benefits of Data Administration and Data Modeling that they are quickly moving to implement that practice across the enterprise. The ETL and BI tool developers are amazed at how easy it is to get their job done and can't imagine going back to their old groups of undocumented databases, processes, and murky business rules. I have been tasked with making that happen.

Closing points:

The Datawarehouse is an Investment, not an expense. A well designed DW backed with a data model can be the Enterprise Model for future application development and software purchases.

Speed is achieved through smart database design. Smart database designs begin with a Data Model (and its physical transformation into a database schema).

Smart database designs require you find the Best Modeler and Data Architect you can find.

Would you build a home, a factory, or a Skyscraper without an Architectural rendering and without engineering blueprints? Because that's what Data Models are. How can you ask the question as to how the database design will meet the business needs you know will happen in the next 2 years or 5 years or 10 years if you don't have a blueprint for it? How can you handle impact analysis from change if you don't know what the business looks like?

Don't worry about ETL or the "tech" aspects of Teradata. Those will follow after the Data Model and Physical Database design is complete.

There's plenty of advice in this forum and elsewhere as to how to do that.

Anonym

	<Prev	Next>		<<First	<Prev	Next>	Last>>