|
|
Tuesday, June 12, 2007
|
|
A lot of folks talk about the centrality of the data model. They correctly emphasize that the actual technology you use is less important as the quality of your data model. If your data model does not adequately address the business problem you have, then no amount of great technology can save you from troubles.
In a sense, a data model is like an acting script and technology like an actor. A great actor can bring a great script to life. A bad actor can do equally well at destroying it. But no kind of actor can turn a bad script into an academy award winner. It is the script - the screen play - the story - the data model that has the potential to make a happy ending. Enough on that analogy.
So if I want to create the world's best data model, which should I choose as the authoritative data model source? I've been in my share of discussions about which format is better, and it sometimes resembles operating system disputes in terms of intensity of opinion.
Suppose we have a UML class diagram, an Xml Schema, a C# class, a Java class, an XMI file, and a database file of a certain business object. Which of these would contain "THE" authoritative data model? What is the difference between them? Is one better than the others? Is one more Service Oriented that another?
Look at the objects listed below. (UML class diagram, Xml Schema, java class, c# class, XMI file, and database - some edited for simplicity). Which is the authoritative source?
As it turns out the data models are the same. And not only are they the same, but they were created from the same source!
The data modeler may say the UML is the definitive source. The data integration expert may say Xml goes on the wire, so the Schema is the definitive source. The programmer may say the code does the work, so it is the definitive source. And the DBA may say that in the end it all ends up in my database, so it is the definitive source.
The true authoritative source depends on audience, usability, and needs.
First, the audience (the customer) is always right and what they want to see will usually rise to the top of the food chain. So identifying the primary or secondary audience(s) is necessary when choosing an authoritative data format. If your audience is proficient in UML and you have lots of Rational licenses, then UML may be the best fit. If however, your audience doesn't know a thing about UML and just needs to get data from point A to point B, then perhaps Xml Schema is the best format. And so on.
Second, the usability of the model will separate the "good idea" formats from the most practical ones. This is a round about way of saying tools matter. The audiences need to have good tool support for the data formats you are aiming for. If the tools are ubiquitous and intuitive, then you have a good candidate for an authoritative data format source.
Third, and not intended to be last, the needs assessment is key. If your need to is primarily to communicate an idea or a design to a wide organization, then the visual nature of UML may be a good fit. If the primary need is to pass Xml on the wire that only techies will see and support, then Xml Schema may be the choice. If the data is internal (within the firewall), the systems are homogeneous, and simple objects need to be passed, then code is a good option. Look at what the needs of your data format are ultimately going to be and let this affect the data modeling technology used.
Beauty is in the eye of the beholder. Whichever one you are most comfortable working with is the best model of the lot. If you like UML, then go with it. If Xml Schema, then use it.
The key again is not to get overly concerned about which form the data model is in, but to create the best data model with that technology.
=====
=====
12:34:45 PM 
|
|
|
© Copyright 2007 Paul Kiel.
Last update: 9/22/2007; 4:26:57 PM.
|
|
| June 2007 |
| Sun |
Mon |
Tue |
Wed |
Thu |
Fri |
Sat |
| |
|
|
|
|
1 |
2 |
| 3 |
4 |
5 |
6 |
7 |
8 |
9 |
| 10 |
11 |
12 |
13 |
14 |
15 |
16 |
| 17 |
18 |
19 |
20 |
21 |
22 |
23 |
| 24 |
25 |
26 |
27 |
28 |
29 |
30 |
| May Jul |
|
|
