[
Lists Home |
Date Index |
Thread Index
]
> > For me, it's not an issue of "how do I represent this data?",
> > but "how do I define this data so that it can be represented
> > several different ways?" (and efficiently).
>
> Boy, that's a $64,000 question...
Add a few orders of magnitude to that.
> What I wouldn't necessarily expect is normalizations
> that conforms
> to what experts in the current relational world might expect:
> I'm starting
> to believe that data normalization and metadata normalization
> are orthogonal
> to each other.
It's a good point. The mapping technology envisioned (albeit vaguely, I
admit) would have to have additional information not available in one or
the other represention. XML does not require normalization, but relational
databases do. There are different contraints on each model. Any mapping
would require enough additional information to, at best, provide adapt the
data to the target model during data transformation. Fer instance,
<report>
<customer>Fred A. Farkle</customer>
<address>111 Main St., Monroe, WA</address>
<customer>Sheila de Da</customer>
<address>131 Oak St., New Rochelle, NY</address>
</report>
There's no containment of address within customer, but it's pretty obviously
implied. Mapping information would have to contain enough hints to
determine that this colocality of customer and address elements is
implicitly a parent-child relation. It would also have to know that the
report contains a list of such parent-child pairs.
In the target relational database, address may be broken down into separate
columns. Parameterized regex patterns in the mapping file may provide
enough information to enable cross-model transforms, or maybe a method will
have to be called explicitly.
It may not be possible to come up with a normalized mapping of a given XML
document model. In such cases, potential integrity-violating operations on
an unnormalized data model might be disallowed or flagged though triggers.
I wish I had the answers, but I don't. All I can make is the observation is
that there are a whole lot of cross-model mapping technologies being
developed. That hints that there is potentially some leverage to be gained
by formalizing these mapping languages.
> Eg.; there are
> known relational
> patterns for normalizing a non-cyclical hierarchical
> structure.
Good. You may be starting farther down this train of thought than I am.
> An abstract model representation (aka UML and
> more likely it's
> predecessors) holds out hope of being able to generate multiple
> representations.
That would be my guess. The next challenge would be driving such
abstractions down enough levels so that mapping authors can work at an
appropriate conceptual level given the language, the data model, and the
representation.
And then I suppose next will be mapping to mapping transforms. Turtles upon
turtles...
|
