Setting up a data warehouse connection and selecting tables

At the core of a data warehouse, there are facts and dimensions. They can be organized in star schemas, snowflake schemas; they can be more or less complex, and to some extent undocumented. This is not a book about dimensional modeling and discussing how a database layout works better than other is out of scope. Some common sense rules always apply: consistent column naming can be useful (user_id, iduser, user_code, key_user, yetanotheruserid, you name it…), constraints on tables help to pull the strings and find a way into unexplored databases. NOT NULL fields also come in handy.

I personally had my share of good and bad data. I always remember a development team manager who once asked me, "Why do you need primary keys, anyway?" I looked around and thought, "This must be a candid camera…"

If you are drowning in a very complex DB and want some relief, you can go to http://at5.us/Ch2U2 and read about the Directive 595, it may be a...