Re: Vocabularies and DBMSs

From: Dawn M. Wolthuis <>
Date: Mon, 14 Jun 2004 17:41:08 -0500
Message-ID: <cal9ia$jq9$>

"x" <> wrote in message
> **** Post for FREE via your newsreader at ****
> "Dawn M. Wolthuis" <> wrote in message
> news:ca9obu$91l$
> > "mAsterdam" <> wrote in message
> > news:40c7ac7c$0$559$
> > > Dawn M. Wolthuis wrote:
> > > > It is relational folks who become democratic about this and start
> > thinking
> > > > about understanding the nature of any particular noun outside of its
> use
> > in
> > > > "this" context. Define it based on its use and if a new use comes
> > > > redefine it if necessary, otherwise add qualifiers to it.
> > >
> > > The first department to get a database wins.
> > > The rest has to jiggle their stuff into the imposed hierarchy.
> >
> > Not at all! Dept #2 identifies their major entities, some of which
> > align with Dept #1, others of which might be able to see information
> > Dept #1 maintains. There actually is no issue whatsoever that crops up
> > here. There could be the usual types of changes that need to be made --
> > adding files, fields, functions, but it works just fine and again I'll
> have
> > to think of how to make that perfectly clear.
> Do you think that one departament is the 'owner' of the data its produces
> They are the only one that update "their" data ?
> Or that it is a single "view" of data for all application/users that
> maintain that data ?
> I'm sure you can provide a more clear description by not mixing levels and
> by mentioning the role of 'vocabulary' (so foreign to "relational

If you look at all of the terms defined in a database -- the metadata, you get a defined vocabulary. But it is typically redundant in that there might be an attribute named Gender in more than one relation. So, the relation is a namespace and defines its own vocabulary. Now, if that relation is a view of the data, then you can see that the data can be anywhere and the vocabulary is all in that relation. So, when I'm talking about the vocabulary for possible queries, it is analogous to a view that gives them just those elements that can be requested through this view. Because it isn't really a SQL view, nor does it operate like a SQL view, I didn't want to call it that. Nor did I want to call it a relation since it is non-1NF and need not be only a base relation. Sorry to have tossed in a not-so-frequently-used term. --dawn Received on Tue Jun 15 2004 - 00:41:08 CEST

Original text of this message