August 8, 2005
Welcome to the DBMS2 blog
This is the first blog I’ve ever administered, and it was launched in a hurry so that I could follow up on my column introducing the DBMS2 concept. In other words, it’s very much under construction.
Please forgive the exposed girders, loose wires, missing amenities, and dust.
If you need to reach me directly, try curtmonash at monash.com. Please put “DBMS2” in the note title so that I can pick it out from among all the spam.
If you just want to check out who I am, my Computerworld landing page is as good a place to start as any right now.
Categories: About this blog
Subscribe to our complete feed!
Comments
2 Responses to “Welcome to the DBMS2 blog”
Leave a Reply
I read your article in the August 8, 2005 edition of ComputerWorld, “Time for a New View Of Data Management.” I think you have some good points, but I doubt we will be able to reach a place where our most complex schemas are master/detail for transactions–only a few-tables-deep. (Time will tell, of course.) For one, the real world–analog–is a very complex place. The way people think and do business and work has many nuances and alternate tracks; and people want their information systems to allow them to think and function like humans. Complex schemas, to a limited degree, can enable people to be people. I don’t know XML deeply, so I await to see what we can do along those lines; perhaps we will find significant ways to deal with schema complexity that make it simpler for us. Whatever the case, we can’t squish real-world data sets into over-simplified data structures; we are humans who think in differing, creative, complex ways–so our data systems must allow for that.
You stated “Centralized, pre-DBMS2 master data management will never succeed.” I have been working on a Reference Service for a Service-Oriented Architecture, and have found that by using Universal Data Models (by Len Silverston) along with the principles laid out by Malcolm Chisholm in “Managing Reference Data in Enterprise Databases,” it is possible to reduce schema complexity. My Reference Service database (for a SOA-based Reference Service to provide master data management services) is currently at 100 tables; I project that it will top at 400 tables to have a very extensible, very adaptable master reference data system. This is not thousands of tables like many ERP systems have. Granted 400 tables is a lot; but life is complex. I challenge you to build a system as you envision, and tell us how to get there, with the minimum of schema complexity. My theory is that we have gone to too much complexity, and we should back off from that wherever possible; but we won’t be able to get rid of more than half of it.
I have found that by carefully crafting the divisions between “best-of-breed” software packages; integrating only what we must integrate; and being as simple as possible (no grandiose integrate-everything schemes), can allow a medium-sized paper mill to create an integrated, affordable information system. Of course, it will take 5 to 10 years of consistent, evolving work founded upon good software architecture. By dividing schema complexity amongst various systems that cover a sizable business function (supported by vendors), and maintaining internal systems to integrate master data and some transaction data, we have a system that can be maintained by a single talented database administrator/data architect employee. This to me is the cheap and dirty and good “database management services.”
(Jonathon Storm, database administrator and data architect)
Thanks for your comment, Jonathon. It is indeed possible that I was too excited and extreme in the area of schema complexity.
Basically, you’re very much in line with my thinking — which, come to think of it, inspires a new post.