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

Dawn M. Wolthuis wrote:

> mAsterdam wrote:

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

IOW: It was designed to *slow* the typing *down*. Alternative keyboards have been designed, built, and tested to significantly ( > 2x) increase the speed of typing. E.g. velotype (http://www.velotype.com/index.html) is used in specialised applications, but it never really caught on. People tend to like and kling on to what is there and works.

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

Phew ;-) So a portal is similar to a view. What is the difference?

[snip]

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

No, I would prefer to have one listing - wether on paper or on my handheld pen-computer. So - I need to be able to treat the whole invoice as one thing, and I need to be able to treat the invoice as being composed of items. So the model of the invoice should be designed to cater for both needs. Though earlier posts suggested that the chopping up is somehow a typical relational, bad 1NF thing to do I suspect that is rather easy to to, both in MV or in a RDBMS.

Now, I also want one listing for the measurements of stock turnaround, in order to aim for just-in-time logistics and optimally sized orders. In an RDBMS I would create another view on the same schema. Would, in MV, another portal be the way to approach this?

>>The first department to get a database wins.
>>The rest has to jiggle their stuff into the imposed hierarchy.

Another poster already asked an ownership question, so I won't go into that here. "see information that Dept #1 maintains." gives me an uneasy feeling, though.

> As Wol has said, you can take any PICK database and view it as relational,
> but you can't go the other way around.

And you will have seen that I asked him a question about that.

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

In two ways. The straight-jacket feeling this gives comes from oversimplification in the relational design. :-) But it is a realistic example, I think. Received on Thu Jun 10 2004 - 22:16:27 CEST