Databases Reference
In-Depth Information
Dimensional data modeling
We will first take a moment to review a little bit of theory, and even some history.
If you are already familiar with dimensional modeling, feel free to skip to
The
associative data model
section. Otherwise, read on to see how the data models used in
transaction processing systems came to be, why these data models are hard to query,
and how an alternative modeling technique solves these problems.
This section is largely based on Ralph Kimball's article,
A Dimensional Modeling Manifesto
. The full version can be
found at
http://www.kimballgroup.com/1997/08/02/
a-dimensional-modeling-manifesto/
.
Back in the day
When computers first appeared on the scene, the methods for storing, retrieving,
and modifying data were still in their infancy. For example, when storing a customer
order, it was likely that all of the data from the paper order form was directly copied
into a single record or file.
While it was convenient to have the data digitally available, people quickly realized
that storing and manipulating the data was not. As each record was stored on its
own, it was hard to keep the data consistent. Imagine customer addresses and
product information being repeated on every order, and you will agree that updating
and keeping the data consistent is a painful exercise.
To counter these issues, and save expensive storage space, developers started to
apply their own optimizations, often splitting data out into separate tables. While
this approach was a step in the right direction, it also came with a downside. The
algorithms for linking and working with these tables needed to be embedded within
the applications, adding significant complexity.
Relational databases and ER modeling
Fortunately,
Relational Database Management System (RDBMS)
came to the
rescue by the early 1980's and solved part of the problem. These were systems
dedicated entirely to storing, retrieving, and modifying data.
