Home -> Usenet -> comp.databases.theory -> Re: DB schema -> graph, good strategies

Re: DB schema -> graph, good strategies

From: Martin Christensen <knightsofspamalot-factotum_at_gvdnet.dk>
Date: Fri, 25 Oct 2002 23:43:57 +0200
Message-ID: <87y98mkxcy.fsf_at_gvdnet.dk> 






-----BEGIN PGP SIGNED MESSAGE-----



Hash: SHA1


>>>>> "Jan" == Jan Hidders <hidders_at_REMOVE.THIS.uia.ua.ac.be> writes:
Jan> Using the schema for ranking? Sounds fascination. Can you explain
Jan> how that works or give some references?





Grabbing the top of the stack of papers on my desk I can find example
systems such as DISCOVER, BANKS and DBXplorer, all, if I recall
correctly, using different approaches, though. Papers can be easily
found on CiteSeer.



DISCOVER is perhaps the best example, and definitely the one that I
know best of the mentioned systems. It initially finds all keywords
using a database-wide index that they call the Master Index. Then,
using a fairly simple schema graph in which they place separate nodes
for matches to the inputted keywords, they do breadth first searches
to find relationships between nodes (and by implication tuples). Their
algorithm basically spits out results in an ordered fashion, best
ranking result first.



>> The papers I've read are at best superficial on why they use the


>> strategy that they do for building schema graphs. If

>> primary/foreign key relationships map directly to edges, in which

>> direction should they go, if they're directed at all?

Jan> The direction matters of course, but whether you want that
Jan> information depends of course on what you want to do with the
Jan> graph, so, er, what *do* you want to do with the graph?





Imagine we have some ER model that represents our data as we prefer to
think of it. Anyone with basic knowledge of databases know that when
transfering this model to a relational database we need to do data
normalisation. I postulate that most of the time the users' perception
of the stored data will be much closer to the ER model than to the
actual database schema. However, since there are several levels or
normalisation and many equivalent ways of normalising the same ER
model, translating a schema into the original ER model is by no means
a straight-forward task. Nevertheless, I am convinced that to the
degree it can be done, it will be helpful. That is what I propose to
do with the graph.



Martin






iEYEARECAAYFAj25ux0ACgkQYu1fMmOQldUn6ACfXqdsooh6iWSfo/bmxI7MaDQf
b9IAoIPHk2B/frm0KkXCJMsQApepHquQ


=E+Zv


-----END PGP SIGNATURE-----

Received on Fri Oct 25 2002 - 23:43:57 CEST












Original text of this message