Arthur Fuller
artful at rogers.com
Sat Apr 1 23:13:50 CST 2006
I typically inhale the existing app into an Erwin model, but admittedly that gives me insight into the database hierarchy. The current project upon which I am working comprises 8 databases located on 8 servers, and in terms of number of tables it all adds up to about 400. There are numerous relationships, sprocs, udfs, scheduled jobs and so on, and the total DB footprint is about a terabyte, first year, expected to triple each year. In this situation, Erwin is my saviour. Other similar tools would do, but Erwin is their tool of choice so I am quickly becoming expert in its use. "A picture is worth a thousand words" applies here, IMO. Maybe not for everyone in the world, but certainly for me -- I can view a few pictures and get a grasp of the existing situation much more quickly than I can by reading table descriptions and trying to figure it out. There are Erwin, PowerDesigner and DeZign to do this. Not to use one of these is IMO nuts. Arthur -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil Salakhetdinov Sent: March 28, 2006 3:50 PM To: !DBA-MAIN Subject: [AccessD] Does anybody work on this level of abstraction with reallife apps data models? 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 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com