Tag: Editorials

Editorials

Multiple Version Support in SQL

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 […]

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 […]

Editorials

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 […]

Editorials

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 […]

Editorials

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 […]

Editorials

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 […]

Editorials

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 […]

Editorials

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 […]

Editorials

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 […]