[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Data design methods? (was Re: APIs, messaging)
[Michael Champion] > > > I have an even more basic question: by what criteria does one choose between > different DATA designs? OO methodologies provide criteria for choosing between > different designs, but as we've brought out here, a good OO design *hides* data > structures. Are there widely accepted criteria for defining "good" data models > independently of the algorithms used to process them? > > The only thing that comes to mind that would be relevant to XML is > Entity-Relationship Modelling. Any thoughts? > Several. Remember that in the (relational, at least) world, we have logical and physical (and maybe conceptual too) data models. The logical data model lets you describe clearly the essential structure of the data, and the physical data model lets you screw around with it to get performance or other desirable runtime properties. This separation is practically essential to good database design, especially for a complicated database. What plays an analogous role in xml data model approaches? In xml data modeling, people tend to dive right in with instances and physical schemas. Maybe this isn't the best approach. For databases, we have the good old CRUD analysis (Create, Replace, Update, Delete). For each entity, indeed each data item, you want to have such an analysis. It could be considered a design metric. For databases, we have the relational integrity rules for each foreign key relationship between entities (that is, "ON DELETE CASCADE", etc.). For relational databases, we have various degrees of normalization and we know that the logical data model should be in at least 3rd normal form. That's another metric. Normal forms are about making different data items and structures orthogonal to each other and about reducing redundancy. It would be interesting and valuable to look at xml data structures to find out how to achieve comparable goals. Another design consideration - there could be a design pattern for this one - is whether to make an entity dependent or independent. Independent entities are more suited to model as objects, but you can't always make them independent. The "intertwinkle" table (to use Mike Gorman's lovely term) that you use for a many-to-many relationship is an example. All these things (and more, including coherence) go into making a good ER data model. They are all independent of the processing algorithms. Cheers, Tom P
|
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
|