12 internautes sur 12 ont trouvé ce commentaire utile
- Publié sur Amazon.com
The book's complete title is "Data warehouse toolkit: the complete guide to dimensional modeling". What is dimensional modeling? Chapter 1, "Dimensional modeling primer", will surely explain. Page 1 - nothing, page 2 - nothing... page 8 - nothing, page 9 - "By default, normalized databases are excluded from the presentation area, which should be strictly dimensionally structured". What is "dimensionally structured" though? Have I missed the definition? Leafing back... no, Kimball is just using a concept before he defined it, moving on... Page 10: "Dimensional modeling is a new name for an old technique for making databases simple and understandable". Great, what is it then? Page 11 - "Dimensional modeling is quite different from third-normal-form (3NF) modeling". Yees? Page 12 - nothing, page 13 - "If the presentation area is based on a relational database, then these dimensionally modeled tables are referred to as star schemas". Finally! Now, this sort-of-definition would not help someone who did not know about star schema, but thankfully I do, and anyway, this is the closest thing to a definition that you get - although things start to get clearer on page 16, where fact tables and dimension tables are introduced. The essence of dimensional modeling, it seems, is "Star is good; snowflake is bad".
A couple of pages later, on page 18, I see this passage. "The fact table itself generally has its own primary key made up of a subset of the foreign keys. This key is often called a composite or concatenated key. Every fact table in a dimensional model has a composite key, and conversely, every table that has a composite key is a fact table. Another way to say this is that in a dimensional model, every table that expresses a many-to-many relationship must be a fact table". I am confused, for three reasons. A fact table's primary key is "generally" made up of a subset of foreign keys? This is not the case with Kimball's own first fact table on page 36 - "POS Transaction Number" definitely should be part of a primary key (he does not define one, so I assume), but it does not foreign-key into anything. Oh, and Sentence 3 means it's "always", not "generally", if we follow the "conversely" path. Is the "another way to say this" part true? ... And overall, isn't this all just a confused way to say that fact tables have foreign keys and dimension tables don't? "Stars, no snowflakes". (What's wrong with snowflakes, apart from the increased design complexity? Among the reasons listed on page 60 - views are never mentioned - the technical and the scariest one is "snowflaking defeats the use of bitmap indexes").
The two examples above are representative of the book's style, and I am quite sure that it could use a lot more editing. I wish that somebody did a better job, but don't know a reasonable substitute. (Yes, I have seen Inmon's book - not a fan). Nonetheless, it's an impressive, concrete book that will give you a lot of practical ideas, and, when it suggests something that looks suboptimal or incomplete or self-contradictory, will make you think about schema design. Not a sufficient reference on the subject, but a very necessary one.
PS. I recommend "Kimball Group Reader" as the alternative to this book: I believe that it covers the material here, and offers a lot of additional information.