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

From: Eric Kaun <ekaun_at_yahoo.com>
Date: Wed, 09 Jun 2004 19:41:10 GMT
Message-ID: <qJJxc.385$Pt.272_at_newssvr19.news.prodigy.com>


"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:9EJ4q$GofOxAFw1i_at_thewolery.demon.co.uk...
> >1. files
>
> This represents a "physical" object. A house. A car. A company. A
> building. An invoice.

What about relationships between any of those things - e.g. cars and houses owned by companies, and the invoices for their purchases? At what point does something move from being a file to an attribute or vice versa?

> >2. attributes
>
> This describes the object. A house has an address. A car has a colour,
> and an owner. A company may have several buildings (so here we have a
> "foreign key"). A building has an address. An invoice may have several
> addresses, and several lines.

So if an invoice has a Parts attribute, it then needs additional attributes corresponding to each "attribute" of its use of those parts? At what point does the relationship between the two acquire enough "meaning" or enough attributes of its own to warrant being in its own file? Imagine line items on an invoice became very complex, with shipment information and payment information... is there a point at which you say "Enough!" and stop adding those things as sub-attributes to the Parts attribute of the Invoice?

> >3. sub-attributes
>
> A building has an address - which may have multiple lines (actually,
> this is a bad example, but it's a common mistake). An invoice has
> multiple lines, each of which contains several different types of data.

Yes, but how far do you go? Certainly at some point some of those attributes refer to other things properly categorized as Files. Do you find yourself yanking out attributes or sub-attributes, and moving the lot to Files? At least to me, normalization offers a much clearer view on how do make those data design decisions. Maybe I'm being alarmist, but when I've had to make changes in a SQL data model it's been due to actual changes in the requirements (external predicates), not just acquiring one attribute too many. Granted that I don't know Pick, so haven't walked a mile in your shoes... these criteria just seem very dicey.

> >4. sub-sub-attributes
>
> Simply nest sub-attributes one level deeper. :-)

Ah, hierarchical induction. I'll just have one File in my app. :-)

> Basically, to describe it in relational terms, if you link table A to
> table B, such that deleting a record in A causes a cascading delete of
> one or more records in B, then I'd make each column of B a column of A,
> and each row of B into a sub-attribute row of A.

You're describing parent-child relationships. Surely you run into multi-parent and many-to-many scenarios?

> And then you use common sense to say "I use these fields all the time,
> and these fields only rarely" so you split A into two physical FILEs,
> and make all the colums of A-rarely into virtual columns of
> A-all-the-time, and vice versa. So for retrievals the user notices
> nothing (apart from the speed-up), although it does cost a bit extra
> logic when updating.

A logical cost is a big cost. Every updating app needs to know that, right?

So you're definitely describing some physical redesign which sits below the logical view available to users. I think in relational terms, that's what the DBMS vendors should offer, since they can more accurately (and easily) split relations based on usage, and have that happen dynamically. But you do seem to be describing a user- or application-level view of the data, which is layered atop something that is, or leans toward, or could be "more relational." At least that's the way it seems...

  • erk
Received on Wed Jun 09 2004 - 21:41:10 CEST

Original text of this message