RE: Primary and Foreign Keys

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Yes, and explaining that in proposals is a bear.  So, of 
course, they get the table lists and field lists and some
documentation.  Two remarks overheard concerning XML 
Schema today (both from graybeard developers):

o  "XML Schemas don't do very much.  Why bother?"
o  "XML Schemas work out to be just another presentation 
    form of the relational schema document.  Why bother"

80/20 is like NearBeer: so near and so unsatisfying.

No, I see QBE and lists still as what we use with predefined 
queries, etc.  On the other hand, stylesheets add a different 
kind of tool to that.  Transforms for visualization, for 
example.   As to an ontology, S.G.M.L. (Sounds Good.  Maybe later.). 
For today, the xsd:documentation element is that.  It will be interesting 
to see just how much intelligence can be built into the 
schema and what it gets used for.

Another wrinkle:  going into the relational db and finding out 
that some fields and tables have the same name (noted as duplicate 
declarations in the XML Schema validation) and finding one that is 
different only the by the spelling of a single character but is 
now so deep in the code, getting rid of it would be expensive.  
For now, I will annotate and rename.  I realize I could push 
all the fields into attributes but I really don't want to.

So far, one benefit of the exercise is to clean up and find out 
just how denormal the existing relational design is.

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Thomas B. Passin [mailto:tpassin@home.com]
Sent: Sunday, July 22, 2001 1:58 PM
To: xml-dev
Subject: Re: Primary and Foreign Keys


[Bullard, Len]

> It is true, that the task is to enable a way
> for them to describe the access and to ensure
> that the data model doesn't get in the way of
> different people doing that different ways.
> That is why the reply to so many requests for
> ad hoc querying capabilities is to say "buy
> a copy of MS Access or Crystal Reports and
> learn to use it with ODBC".
>
I don't think it's really possible to allow general adhoc queries for just
anyone, because hardly anyone understands the data model (let alone the
implementation) enough enough to figure out how to ask for something
arbitrary, let alone get any performance out of the query.

What I've noticed is that when people ask for "adhoc" access, they really
mean 1) filter by a selectable combination of fields, 2) sort by some
combination of fields, or 3) ask for data using some kind of
query-by-example.

Sticking with relational databases for now, the normal good-practice
approach is to create views and predefined queries for other people to use
when hitting the database.  I don't see that principle changing just because
we're interested in using xml somewhere in the process, do you?

> Yes, when collecting data, it can stay in
> the relational database and be collected
> as XML.   So rather than modeling foreign
> keys, what may be needed are the kinds of
> co-occurrence relationships one can model
> as Schematron assertions where values have
> to be checked and that is indeed a big part
> of the problem I have to solve.
>

Are we getting into the data dictionary here?

Another interesting question is whether you have to provide a vocabulary or
ontology so that these other agencies' software can discover what you mean
by "driver", "SSN", or whatever, or whether the meaning of the terms can be
taken for granted.  The first alternative is getting to be Semantic-Web-ish,
and sure would take a lot more doing.

Cheers,

Tom P


------------------------------------------------------------------
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 unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: xml-dev-request@lists.xml.org