I didn’t get much feedback on the value of writing software so that multiple versions can co-exist. Either it isn’t worth the extra effort or cost to write code in this fashion, or there really isn’t a need. Personally, I have found that there are rare instances where you simply end one version and begin a completely new version of […]
Tag: Editorials
Open/Closed and Multiple Versions
Every year or so I come back around to the SOLID principles of software development. They are easiest to implement in object oriented languages, but the principles still apply. If the SOLID acronym is new to you, take a trip to Wikipedia for an explanation. Today I want to talk about the O in solid, which stands for Open/Closed. Open […]
Another Sequence Example
Here’s a little demonstration of the power of a sequence (or sometimes called Tally) table in SQL. The sequence table allows you to perform set logic for things that would normally require looping or procedural code. Today I was working on a query that produced a set of possible values, and then used an outer join to present all implemented […]
Big Data Storage
The final data warehouse design pattern I want to review in this series is Big Data. Unlike all of the other data warehousing structures we have reviewed so far, big data does not have to conform to a table like structure with relationships. In fact, it often has jagged arrays containing other arrays in the form of objects. Instead of […]
Comparing Data Warehouse Designs
Today let’s compare the traditional data warehousing database schemas. Normalized data is not often used today for data warehousing. The key reason is that, while the normalization of the tables results in less redundancy, and higher quality of data, it comes with a cost, because data needs to be joined from multiple tables to produce the results needed for reporting […]
The Snowflake Warehouse Design
As we have been looking at data warehouse structures we reviewed data marts, and star schemas. Today we’re going to enhance the star schema, converting it into a more complicated form known as a snowflake schema. A snowflake schema begins as a star schema. As dimensions are added to fact tables, a lot of redundant data begins to emerge in […]
http://www.diffen.com/difference/Snowflake_Schema_vs_Star_Schema
Star Schema Warehouse Design
Today we continue the review of different data warehousing structures. We began yesterday with Data Marts. As a quick review, a data mart is simply a table that is self contained. It is rarely joined to any other data. Everything needed to provide results for your query is often contained in a single data mart table. Sometimes there are a […]
Data Mart Overview
The first data warehouse I worked on was built completely on data marts. Data marts are an anti-pattern, ignoring data normalization principles, creating a single table with repeating data in multiple rows, or having repeating columns. These tables are not normalized to the basics of even first normal form. The de-normalization is not randomly achieved. Often, query results for producing […]
Reporting Database Designs
Keith provides some really thought provoking comments about Data Marts, prompting me to respond with my take on the whole topic of reporting databases. Keith writes: I saw the heading on this article and before I read the article, I got stuck… What is a data mart anyway? I’m not talking about the surface definition. I’m talking about in our […]