- by dbdebunker, Data Doctor
- 1/28/2013 1:10:29 PM
All that data were generated for different purposes and, therefore, do not have a common structure to which common sound operations can be applied for analytical purposes. There is this common delusion that such data can be taken as is and, without any effort, can be mined for information.
Another aspect is a disregard for the cruacial importance the ratio of method and tool complexity to usefulness. The purpose of models is to simplify the reality of interest to the most essential and to structure it optimally for multiple analytical purposes. Complexity and lack of generality defeats their purpose. This is largely missed by both business and IT and the industry encourages the opposite.
Codd's genius was not only to apply theory to data management, but also that the theory provides an optimal ratio of simplicity to generality: the relational approach is the simplest way to deal with data that is general enough to handle a vast majority of informational needs. In my paper "Businss modeling for database design" I specify the criteria that an alternative approach must satisfy to be superior. Unless it does, we trade down. The trite statement "the right tool for the right job" more often than not reflects a lack of foundation knowledge.
- by kq4ym, Data Doctor
- 1/28/2013 9:02:07 AM
Good points, more than just a programmer/developer is needed to make sense and hopefully some company profits out of the data massage.
Lots of data, means lots of brainpower is needed to figure the best ways to use it, and the persistence to keep trying new ways of looking at what's going on. It's not the first result that will define the answers.
- by dbdebunker, Data Doctor
- 1/17/2013 12:02:13 PM
Of course, how businesses do that makes the difference between success or failure.
The large and complex databases require (1) a formal process (2) management support (3) modeler-user-manager-dba team (4) thorough knowledge of the business (5) data foundation knowledge (6) proper documentation and design tools.
I believe that except for cases of relatively simple databases used by only a few application/users, the current practice of assigning a programmer/developer to do everything from business modeling to database design to database administration to application development will usually end up with serious problems.
The notion that eschewing this saves money and time is an illusion due to scarcity of foundation knowledge: the opposite is true. The argument that modeling and design is difficult, takes a long time, is expensive and so on is certainly true, but there is no free lunch: if you want the benefits of a true db system, that's the price for it, and thinking that you can eschew it and still get the benefits is delusional. You can do it, but then you must do it consciously and aware of the benefits you give up. The ndustry caters to this delusion by promoting magic wands.
Simplicity and parsimony are critical. Given the complex nature of business reality and the above process, it is crucial that we don't pile complexity of methodology and tools on top of it. Everything should be as simple as possible, but not simpler. That's the issue that the relational model addresses and the failure to comprehend that is one of the core problems in IT.
- by BethSchultz, Blogger
- 1/16/2013 5:36:47 PM
Hi Fabian, I like the idea of laying out the definitions in this way. What's your advice on how to make sure people within a company are all working from the same dictionary, so to speak, as they work on their business modeling? Should they have a document with all of their terms spelled out, for example?