Re: Primary and Foreign Keys

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

[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