Shamil Salakhetdinov
shamil at users.mns.ru
Tue Mar 28 14:49:54 CST 2006
Hi All, I wanted to ask you how do you usually try to quickly understand existing real life applications data models? I mean the following: - imagine you've got a task to program some utility code for an application with rather tricky datamodel, working application and the question to change this tricky datamodel is out of your responsibility - you're not allowed even to discuss this question (I'm exaggerating about that latter - just wanted to outline that your task is to understand the existing datamodel whatever it's as quickly as possible, accept it and to deliver your solution in time and as good as possible in the given context because the customer is waiting for your working solution not your considerations about datamodel and how good it could have been if you have been allowed to change it....). - there is a good description of this datamodel and its business area but to program effectively you can use just a subset of this datamodel and its description, which you need to quickly filter out from all the existing (thick) stuff to make a simple submodel diagram of the tables used in your utilities and their relationships. And you do not want to spend time to understand all the rest of this datamodel because you're more interested to go watching the next series of Dexter and DeeDee or watch the 100th time your favorite action movie like I do sometimes watch "The White Sun of Desert" - a famous here Soviet action movie I first time watched in 1969 :)... The question is how to quickly understand such a data model and to get it well arranged to solve the urgent customer task? (You given the datamodel diagram but relationships are intersected in a tricky net) Did you ever try to solve such a task first of all on an abstract level? I mean did you ever try to "play" with existing datamodel relationships diagram (graphical diagram I mean) without knowing(/without even taking into account) the meanings(titles) of the tables and their relationships? With the main purpose of this playing being to finally get a relationships structure(graphical diagram) clearly showing you what are the key points of this datamodel, what a the "juncture points", what are the "bands and whistles"? I did try and I think it always work for tricky, sometimes not optimal but rather well normalized data model. I think this is called "building star schema abstract method". And it works in most of the cases. Try it. I did try to google for "start schema" concept definition and as far as I see it is usually linked with OLAP not OLTP data models as here (http://www.tdan.com/i021hy01.htm). I did read first about star schema data models abstraction in a short article in one of programming magazines somewhere in the summer 1995 and since then I use this concept and it always work well am I building datamodels from scratch or am I trying to understand/arrange existing ones... Just wanted to share how (sometimes boring task) of getting well understanding of an intersected net of an existing data model relationships can be converted in a joyful(?) game of shuffling these table's relationships to get at a clear view of the subject business area... Shamil