SQL Server Magazine welcomes reader feedback about the magazine. Please include your full name, email address, and daytime phone number with your letter. We edit all letters and replies for style, length, and clarity.
The Race Is On
Thanks for the justification of SQL Server 7.0 (Michael Otey, "The Oracle Challenge," April). I've been testing OLAP Services for some time now and always get a kick out of how speedy my query can perform when I use aggregation. I am beginning to build a true data warehouse infrastructure using Data Transformation Services (DTS) and OLAP Services. Oracle will say anything to gain a competitive advantage over SQL Server 7.0, but we're up for a marathon.
—Alovett J. King, MCSE
OLAP in Real Life
Bob Pfeiff's "OLAP: Resistance Is Futile" (April) is interesting but disappointing. I wonder if the author really can explain the differences between MOLAP, ROLAP, and HOLAP, instead of essentially repeating what is in OLAP Services. Can he explain:
- What is the initial data like? Is it simply a relational database or has that database been modified to contain a new set of fact and dimension tables?
- After defining storage and processing the cube, what happens to the data? What new files are created and where are they stored? Are new files created in the relational database? What do these files individually contain?
- Can the author take an example, work through it, and identify each new file as it is created, along with its contents?
Thank you for your ideas. Future articles will cover the questions you raise.
Michelle Poolet mentions in "Why You Need Data Normalization" (Premiere issue) that you can use normalization for transactional databases and data warehouses and then mentions later that data warehouses are usually denormalized for query optimization. Data warehousing does not use normalization. It uses a different modeling technique called dimensional modeling. Because it follows different models, it isn't quite right to say it is denormalized. It was never normalized.
Poolet also refers to tables as being like spreadsheets. Rows and columns have much different properties than spreadsheets. The Visual Basic (VB) Grid programming has always been challenged by this difference.
I don't mean to nitpick. Not much exists (at least not enough) on normalization. You've made an excellent effort to get the discussion out. Good job.
Thanks for your feedback! I prefer to work from a conceptual model, an entity relationship diagram (ERD), rather than try to normalize from the ground up. That's not always feasible, I know.
Regarding your comment about denormalized data warehouses—it depends on your perspective. When I first encountered dimensional modeling, I began to recognize the tremendous similarities between the gerund (or associative table) of the transactional (ERD) model and the fact table of the dimensional model. Then I noticed a 1:1 correspondence between the base entities of the ERD and the dimension tables of the dimensional model. So if the entities that compose the dimensional model are mostly sourced from one or more properly normalized transactional models, even if they incorporate non-database (or non-normalized) data into the dimensional design, I believe that it is fair to think of the dimensional model as a denormalized version of the transactional data.