[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XML Database Decision Tree?
<<< I may be digressing, but an implication of an XML DBMS support for efficient storage/retrieval of well-formed XML is that you can get many benefits of using a DBMS without going through the agonies of data modelling, database design, and performance tuning that RDBMS-based applications traditionally suffer.>>> Hmm.....I see your point in terms of not needing to do data modeling in the traditional sense in order to put a production database in place. In a traditional (RDBMS) database implementation a team of logical data modelers would get together to review business rules, perform analysis, and iteration after iteration of conceptual/logical data models would be put forward until a mature enough model is handed to the physical database designers to denormalize most of what was done anyways. <cynical data architect remark...> I don't see however the "agonies" of data modeling going away, I just see its role moving to a different place in the process. With XML databases we lose the traditional rigid structure of an RDBMS and the need to create a logical model at the database level. One is misled and truly at a cross-roads in their understanding of your companies data needs if however, they feel that data modeling need not be done at all. XML provides the Schema which is very much analogous with a data model and it is disturbing to me how few developers have embraced the Schema or put 2 + 2 together and asked Data Architecture teams for assistance creating them. One of the biggest challenges I have encountered in my work as a Data Architect (I consider myself an XML Data Architect at this point) is taking the toys out of the hand of developers. This is very much like taking away a toy from a child who may have not yet learned the rules of the game. XML came along very rapidly and was the toy of choice for many developers. They implemented really "cool" applications that did simple messaging or integration functions/tasks, they created a few simple web applications that showed the promise of mastering XML and added new developers to the fold, but they did not understand that XML IS DATA! Yes, in the truest sense XML is data just as a traditional RDBMS is data. DATA = DATA. It's a simple equation but one that some developers just don't get. Now this isn't a new struggle. Data Architecture historically has had an uphill battle for acceptance, I won't get into the specifics of that struggle here. XML Data Architecture will certainly face many of the same battles but should be guided by the same Data Architecture principles. These vary slightly by organization but typically include things like standard definitions that facilitate consistency and data/data structure reuse, strong definition and capture of metadata (which XML EXCELLS AT!), high degree of data quality, one source for like data, etc.. The XML Schema is the mechanism to achieve these principles and thus the responsibility to develop these should be put in the hands of the Data Architects, not in the hands of the developers. The Data Architects of an organization need to embrace XML quickly so that these Schemas can be developed and implemented (with validation, but this is another post and another battle to be fought) and be managed in a way that supports consistency, common definitions, reuse, etc.. While it true that with XML data modeling is not at the database level we must consider that XML can be managed without a database. With this said you can clearly see that each XML document itself acts as a pseudo-database (remember RDBMS = DATA, XML = DATA), and that each document's Schema needs to be given the same care and attention one would put into crafting a table in an RDBMS. In terms of the XML database I think the term database might be bit misleading (I personally think repository fits better) but the fact that it is not a database in the traditional sense DOES NOT lend credence to the total absence of data modeling for your XML data. Brian Magick -----Original Message----- From: Dan Weinreb [mailto:dlw@e...] Sent: Saturday, October 27, 2001 3:31 PM To: Mike.Champion@S... Cc: xml-dev@l... Subject: Re: XML Database Decision Tree? Date: Sat, 27 Oct 2001 15:58:15 -0400 From: "Champion, Mike" <Mike.Champion@S...> I may be digressing, but an implication of an XML DBMS support for efficient storage/retrieval of well-formed XML is that you can get many benefits of using a DBMS without going through the agonies of data modelling, database design, and performance tuning that RDBMS-based applications traditionally suffer. I don't think it's so much that XML means you don't need those agonies. Whether you need them really depends on the role that your DBMS plays on your organization. Having a strongly-enforced strict and structured schema has benefit and costs, which depend on the use case. That is, depending on what you're trying to do, the costs might outweight the benefits or vice versa. In the classic "database of record" "standard corporate database" use case, you've got a large corpus of critical long-lived corporate data, and there are lots of different applications that might read and write it (plus ad hoc queriers). To make sure that none of those applications breaks another by writing something into the database that another one can't read, you have to set up ground rules that all the applications must follow. The classic RDBMS schema is part of that set of ground rules, and there are these DBA guys who act as judges (or perhaps "as bouncers") in order to prevent car crashes. I think the need for these ground rules is pretty much independent of what data model the DBMS is using. (That is, if somehow someone ended up with a native XML database playing such a role -- even though I keep saying that I don't think that'll happen and that's not what native XML databse systems are intended for! -- then you'd still want a schema for the same reason.) In other use cases, rigid conformity may provide less benefit, and the ability to manage semi-structured data may be more pressing. For example, to again repeat the comments that you (Mike) made at the NEJUG talk in Burlington, if a purchase order for $1M comes in, you don't want to automatically turn it away just because it doesn't conform perfectly 100% to your pre-defined schema! Semi-structured data arises in more and more situations these days, including the integration of data from multiple disparate sources. (Anyone interested might want to do Web searches for papers about semi-structure data.) I think this is one of the areas of opportunity for native XML databases. ----------------------------------------------------------------- The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.xml.org/ob/adm.pl>
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|