Data Models |
Commentary |
Step 1 : A Customer
This Model dates from 2001 and shows how Inheritance helps us to model both Commercial and Personal Customers. However it doesn't show any details of other things that we are interested in, like Payment Methods. So we look for another Model which is a more suitable starting-point for a Customer who is going to make a Purchase. |
|
Step 2 : Customers and Addresses
This Model dates from 2006 and shows a general solution for Customers and Addresses. We will have to add more Customer-related items to the Customer Entity but it is fine for a starting-point. However it doesn't show any details of other things that we are interested in, like Payment Methods. So we look for another Model which is a more suitable starting-point for a Customer who is going to make a Purchase. |
|
Step 3 :A Customer makes a Payment
This Model dates from 2010 and was part of a Master Data Management (MDM) approach. It includes Payment Methods and the MDM approach is good for this current work so we decide to includ it in our Top-Level Model. So we choose this Customers and Payments Model and will adapt it to suit our requirements. barry |
|
Step 4 : Customer makes a Purchase
This Customers and Orders Model dates from 2010. It includes (Customer-related) Mailshots and (Promotion-related) Promotions. It is comprehensive so we decide to include it. barry |
|
Step 5 : A Customer makes a Journey by Train
This Model for Public Transport dates from 2009 |
|
Step 6 : The Customer makes a reservation for a FlightThis Model dates from 2008 When we look at the Trains and Flight Reservations Models, we realise that we can replace them both by the "Trains and Boats and Planes" Model. We prefer to have a smaller number of Models and have more powerful Models. |
|
Step 7 : Replace two Models by one for Trains and Boats and PlanesThis Model dates from 2013 When we look at the Trains and Flight Reservations Models, we realise that we can replace them both by the "Trains and Boats and Planes" Model. We prefer to have a smaller number of Models and have more powerful Models. |
|
Step 8 : Review progress On the left, we show the Data Model for Customers with Addresses and Payment Methods. | |
Step 9 : Adopt our Canonical Data Model At this point we decide to use our Canonical Data Model, because its Event-Oriented Approach is very economical and very powerful. | |
Step 10 : Conclusions
On the left, we will show the Top-Level Data Model with Customers.
In the next Model, we replace Customers with Parties. Logically, these are equivalent but the Parties approach is more general and professional. You can choose the one which is more appropriate to your situation. |
|
Step 11 : Conclusions
On the left, we show the Top-Level Data Model, and here are links to the Subject Area Models that we have derived :-
Reservations Subject Area (which we prefer to Customers Purchases) |
|
Step 12 : Design Pattern for a Generic Data Warehouse
Our Data Warehouse is a Generic Third-Normal Form design. |
|
Step 13 : Data Warehouse
Our Data Warehouse has a Third-Normal Form design and is the same As our final Top-Level Model with Customers. |
|
Step 14 : Design Pattern for a Generic Data Mart | |
Step 15 : Using the Design Pattern for our specific Data Mart
This shows Data Mart Phase 3 for our specific Requirements. |
|
Step 16 : Data Warehouse
Our Data Warehouse has a Third-Normal Form design and is the same As our final Top-Ledvel Model with Customers. |