Re: Data design methods? (was Re: APIs, messaging)

["Thomas B. Passin" <tpassin@home.com>]

[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