Re: Lucid statement of the MV vs RM position?

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 21 Apr 2006 13:18:35 GMT
Message-ID: <LY42g.63641$VV4.1190225_at_ursa-nb00s0.nbnet.nb.ca>


Jay Dee wrote:

> Christopher Browne wrote:
> 

>> In the last exciting episode, ralphbecket_at_gmail.com wrote:
>>
>>> Pickie wrote:
>>>
>>>> There doesn't seem to be a formal model anywhere. Integrity
>>>> constraints are not enforced at the database level.
>>>
>>>
>>> Yikes.
>>>
>>>
>>>> http://www.pickwiki.com/cgi-bin/wiki.pl?PhilosophyOfPick gives
>>>> my views of the philosophy behind Pick.
>>>
>>>
>>> I've just read your article. Two misconceptions of the RM seem
>>> to crop up again and again in comparisons between MV and the RM:
>>>
>>> (1) the RM is *not* based on the idea of storing data in tables.
>>> Under the RM, a relation is a set of rows with the same
>>> signature, and a row is a partial function from column names to
>>> values. The signature of a row is the domain of the function
>>> (i.e., a set of column names). It is purely accidental that
>>> relations of this kind can be conveniently portrayed on the page
>>> as two- dimensional tables. The emphasis on the RM should be
>>> that a relation is a *set* of rows, a row is a *set* of (column
>>> name, value) pairs, and sets are unordered, duplicate-free
>>> collections.
>>>
>>> (2) The RM says *nothing* about *how* a database should be
>>> implemented. It would be a mistake to think that because
>>> relations are often called "tables" and are often portrayed as
>>> 2D arrays, that is how they are stored in memory or on disc.
>>> Any implementation taking that route would have shocking
>>> performance. The point of the RM is to separate the model (how
>>> one thinks of the data) from the representation (how it is
>>> stored). A good RDBMS implementation should make good decisions
>>> concerning representation (perhaps under the guidance of the
>>> DBA), but that is purely an optimization issue. Conflating
>>> representation and model is akin to hand optimizing a program
>>> before you'r sure it's correct: it will surely lead to a world
>>> of pain.
>>
>>
>>
>> If you look at the ACM TODS (Transactions on Database Systems), a
>> goodly number of the papers present views of relational systems in a
>> fashion that looks *way* more like Prolog than anything else.
>>
>> It tends to be pretty easy to represent relational facts as well as
>> queries as sets of Prolog clauses.
> 
> 
> True,
> 

>> There is a conspicuous disconnect from Darwen/Date, there, in that
>> they trumpet loudly about strong data typing, whilst Prolog tends to
>> be nearly type-free. Mind you, I'm conflating representation and
>> model there, a bit...
> 
> 
> true,
> 

>>
>>>> There is a mindset about the Relational Model that is disturbing.
>>>> The point of view that says that there is no TRULY Relational DBMS
>>>> because of incompetance or wickedness on the part of the SQL DBMS
>>>> providers is just outright wrong.
>>>
>>>
>>> My gut feeling is that it's partly to do with poor early choices
>>> having become the standard and partly to do with the fact that not
>>> many people finish a CS degree with any understanding of theory or
>>> how the careful application of theory can save huge amounts of time
>>> and effort. Given things such as the lack of any decent type theory
>>> or the addition of terrible ideas like NULLs into SQL, I'm inclined
>>> to think the latter is more significant than the former.
>>
>>
>>
>> I'd tend to agree with that.
>>
>> One issue I'd take is with the notion of the *forcible* importance of
>> type theory. That's certainly the sort of thing that falls out of a
>> focus on type-oriented systems like ML, which extend the importance of
>> explicity typing as is typical in the spectrum of computer languages
>> like FORTRAN, PL/I, *descendents* of the typeless BCPL like C, C++,
>> and Java, and Pascal descendents like Ada.
>>
>> In contrast, there are also a lively set of languages that eschew
>> strong typing, like, well, in the ancient past, BCPL, Tcl, and Perl.
>> And lively sets of languages that have strong typing, but which mostly
>> eschew type annotations, like Scheme, Common Lisp. I'm not certain
>> how to classify Smalltalk...
> 
> 
> true,
> 

>> At any rate, there's enough diversity there that I don't think I can
>> go along with type theory being entirely essential...
> 
> 
> and true -- depending on your system's intended purpose.
> 
> [Here comes the rub.]
> 
> The "knowledge" DBMSs, which store facts and functional
> dependencies explicitly and independently, behave very
> differently than most "relational" DBMSs.  I don't want to
> spend too much time on this point, but let me simply say
> that a KDBMS can be expected to expunge everything which is
> inconsistent with the most recently presented knowledge.
> Most DBMSs that posters to this group are familiar with
> would expect the system to reject such inconsistent data -
> usually because some constraint is violated.- rather than
> view it as better knowledge.

So, one careless mistake can wipe out the entire database?!? Yikes!!! Received on Fri Apr 21 2006 - 15:18:35 CEST

Original text of this message