Re: In an RDBMS, what does "Data" mean?

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:ca9obu$91l$1_at_news.netins.net...
> "mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
> news:40c7ac7c$0$559$e4fe514c_at_news.xs4all.nl...
> > 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 might
> align with Dept #1, others of which might be able to see information that
> 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.

I understand what you're saying - but as the number of departments (or even job roles within a department) demands different views of the data, I believe that whatever vocabularies you layer on top, your "base" data design tends toward normalized relations.

> As Wol has said, you can take any PICK database and view it as relational,
> but you can't go the other way around. If you could, then this discussion
> would be moot -- we could just toggle between different perspectives on
the
> data.

He did say that, and I've been thinking about it, and am not sure it's accurate. The order of values in a list attribute in a Pick file seems primarily to correlate with other attributes that relate to the same "nested" entity - e.g. a line item. Those can easily be spit out in correlated lists by foreign key traversal. Other ordering would have to be imposed, and maybe that's where the discrepancy is. Relational requires that if order is important, you make it an attribute. I've never found such to be a problem - in most cases, orderings are pseudo-IDs.

> Now, it is possible to design a relational database that can do that,
> but you have to design for it. I would not be surprised if you had a
> relational data modeler and a pick data modeler both address the same
> problem space, if the PICK modeler would actually encode more information
> than the relational one. One example that pops to mind is with
> classifiers -- the relational modeler who identifies that 90% of the time
a
> single entity fits into a single classification and if they don't then the
> user can pick one without anyone dying, will likely then proceed to make
> that a rule by putting a classification code as an attribute on that
entity,
> rather than splitting it out into a separate table for the few times when
> the entity could be classifed in two ways. The PICK modeler doesn't blink
> and identifies that this classification code is multivalued -- if you need
> to put two classification codes on this entity, you do so. Overly
> simplified example, but ...

That's a good example, though... I'll have to give that some thought. The question is whether any power is gained by using another relation, since it's slightly more work; I'm assuming that the classification codes themselves are stored in another relation/file, and thus you want some referential integrity so nonexistent codes don't get entered...

• Eric