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

From: Anthony W. Youngman <wol_at_thewolery.demon.co.uk>
Date: Sat, 10 Jul 2004 01:21:21 +0100
Message-ID: <lBjHdSQBaz7AFwXX_at_thewolery.demon.co.uk>

In message <40dd4ca1$0$93324$e4fe514c_at_news.xs4all.nl>, mAsterdam <mAsterdam_at_vrijdag.org> writes
>Sorry to be vague, but I can't (maybe just yet) get it concise:
>MV.FILE obviously comes with more 'togetherness' and 'containment'
>of the associated data than SQL.TABLE.
>Also, MV.FIELD may contain more than SQL.COLUMN.
>
>It may be a good exercise to think of MV.FILE as closer
>to SQL.SCHEMA than to SQL.TABLE (and MV.FIELD to SQL.TABLE).

Think of a MV FILE as a bit like a SQL view. And then (like you can join cells in a Word table, think that where relational has a 1:many link, and SQL presents the user with multiple instances of the same data on the 1: side, MV can vertically join all those cells such that there is only one instance of the data.

eg

LIST CARS VIN COLOUR CAR.... VIN COLOUR
RLP587E ABC123 BLUE
OKO681M XYZ987 BLUE

                GREEN
                BLACK

C174CKL MNO456 GREEN Note that each car is ONE row in the file, COLOUR is a list stored in a single cell. So just as it would be LOGICALLY contained in a relational database, with a cascading delete to ensure integrity, so it is PHYSICALLY contained in an MV database. And because it's *physically* contained, when I declare SHIPPING-ADDRESS and BILLING-ADDRESS as part of my file definition, it's not a foreign key, but an ordinary (multi-value) attribute.
>
>The crucial difference may be in the adherence to the information
>principle. (In some other post you talk about having order
>without specifying it, I think it is similar).
>
><quote>
>[Information principle] (RM) Date/Codd:
>Chris Date in "EDGAR F. CODD 08/23/1923 – 04/18/2003 A TRIBUTE":
> The entire information content of a relational database
> is represented in one and only one way: namely, as
> attribute values within tuples within relations.
></quote>
>
>Adherence to it comes with costs and benefits.
>You seem to be convinced that the benefits of non-adherence to it
>easily outweigh the costs (i.e. the benefits of adherence).

Because that principle is, basically, Codd's way of enforcing Normal Form. What Codd *wanted* was normal form. Only by imposing first normal form could he ensure he got it.

MV *should* be normal form (hence my cursing in that currency example - that wasn't normal form), but if the database has been properly designed, then MV has all the (meta)data it needs to automatically convert MV-form to First Normal Form. So we get all the benefits of adherence (because we can get FNF by applying a mechanical transform) AND we get all the benefits of non-adherence too :-)

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
The society which scorns excellence in plumbing because plumbing is a humble
activity, and tolerates shoddiness in philosophy because it is an exalted
activity, will have neither good plumbing nor good philosophy. Neither its
pipes nor its theories will hold water. John W Gardner

Received on Sat Jul 10 2004 - 02:21:21 CEST