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

In message <aq%vc.5718$er.906_at_newssvr32.news.prodigy.com>, Eric Kaun <ekaun_at_yahoo.com> writes
>> Sorry, not refusal, but even I get sick of my broken record on 1NF --
>> that's why things are chopped up unnecessarily, in order to put them into
>> 1NF. So, in the example I gave, there is no reason, in my opinion, not to
>> have a single line of the invoice be stored in a tuple, allowing the lists
>> to be elements of the tuple, just as the single-valued attributes are.
>
>What are your criteria for chopping into the following:

For me, it's simple.

>1. files

This represents a "physical" object. A house. A car. A company. A building. An invoice.

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

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

>4. sub-sub-attributes

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

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.

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.

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999