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

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:40c7ac7c$0$559$e4fe514c_at_news.xs4all.nl...
> Dawn M. Wolthuis wrote:
>
> > [I'm sure I've missed a bunch since my ISP first had nntp down and then
> > seemed to reinitialize the database (is that the right term?) but I'll
read
> > a bit before a long weekend away from news again.]
>
> A shared databank of messages - check the glossary ...
> yep it's a database!
> Probably a hierarchical one (MV maybe? - nah just protocol),
> definitely not designed with the relational model in mind,
> though. I have no way of viewing it as tables -
> because the crosspost I made about "database - prolog
> and relational" to two newsgroups forces me to check both
> groups for replies.
>
> It works quite well, though :-)

I'm sure it would work much better if implemented in Oracle, but, ah well ... ;-)

> > ... people tend to choose solutions that work. If
> > there were overwhelmingly good evidence that you get a better bang for
the
> > buck by using relational theory, that would be a different story. I'd
> > strongly suggest we nudge relational databases toward pragmatism ;-)
>
> Roman numerals still exist. They work quite well in some contexts.
> Besides, there is tradition.
> Do you know what the QWERTY keyboard was designed for?

I was told once it was to keep the mechanical hammers attached to the keys from hitting each other, so they needed to put keys you would likely hit one after the other so they were not close together.

> > ... an invoice is just one of these
> > things, but the data from the invoice is also available through other
data
> > portals (for lack of a better word -- don't make me use the word
"view"!)
> > such as warehouses and parts. I can see that one difference is that the
> > same data from my perspective is available as an invoice and as
> > parts-invoiced. These are different entities with the same or similar
data
> > accessed. Each portal can see everything you can "get to" from there
(via
> > declared links as one might have in a join statement).
>
> Yep. The guys (mostly) who check the deliveries simply
> can't afford having just the invoice as their unit of work.
> They need to do it item by item - yep it's there/no it's not.
>
> > again, I think you are confusing something here -- perhaps physical and
> > logical (although I think I've ascertained that would not be like you)
but
> > perhaps it is your notion that data can only be accessed through one
place -
> > it's base relation. Remove that obstacle -- free yourself. Yes, we
still
> > divide it all up, but into wholes, not pieces.
>
> So - let's pay the whole invoice or not *if* one minor item is not
> there? I guess it's a way of doing business - but I would prefer
> to not have the database implementation decision
> determine this business style.

I'm still not saying this both accurately and clearly. I'll think about it some more. There is no problem paying one line item from an invoice and I'm not sure why you think there would be. Again, this is a logical way of looking at the data, but if you looked at a physical implementation, such as a paper invoice form, does it seem difficult to you to check off one line item from that form? Would it be easier conceptually or in any way for this to come on multiple sheets of paper so you could retrieve the one piece of paper related to this line item and check it off that way?

> > 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 up,
> > 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 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.

> > Have you found that when you map from xml to relational, you don't need
to
> > add anything to the information in your source, but when you go the
other
> > direction, you need to add data (such as ordering)?
>
> If the order is *that* important, you can model it, but indeed
> most relational modellers have a blind spot there.
> However, getting rid of the possible contradictions is much more
difficult.

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. 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 ...

Later. --dawn Received on Thu Jun 10 2004 - 15:40:08 CEST