Re: Principle of Orthogonal Design
Date: Sat, 02 Feb 2008 13:50:33 +0100
Message-ID: <47a465c5$0$85780$e4fe514c_at_news.xs4all.nl>
Jan Hidders wrote:
> mAsterdam wrote:
>> Jan Hidders wrote: >>> mAsterdam wrote something very much like: >>>> Pragmatical redefinitions must be temporary and tracked. >>> Sure, we agree on that. >> <unsnip> >> >> Wether the relation between heading and tuples goes >> via names or ordering is relevant or not. >> >> If it is not I want it out of scope. >> >> </unsnip>
>
> I don't think that it is possible to get it out of scope. If you think
> it is, then by all means provide an equivalent and complete definition
> where it is. I'm also not sure what your problem exactly is.
My problem here is that I can't grasp all the consequences of making attributes and types indiscriminate. D&M draft: "...type-compatibility as we define it requires the two tables to have identical column names." The BOM, MOD, WIRES example you snipped without comment may illustrate why I have this problem. Please read until the end of this post before replying to this (it may not be necessary, and no, I did not mind the snip at all, I am just referring to the example).
> We have a definition that works for the named perspective,
> which is arguably the most appropriate for the relational
> model anyway, so can we now
> please, please, please, pretty please, move on with the discussion?
No, sorry, not in your main line (discussing the Hidders PoOD). You will need to tickle other peoples' curiosity. I am not good enough at this to discuss it in a (for me) less time-consuming way. What I will do is try to shed some light on my reservations (which I suspect you share) towards the foundations of D&M's PoOD.
Aside:
Shame on me that I don't have the Alice book.
Joachim Hereth also uses examples where there is no
I think 'named perspective' was just an unfamiliar
label to a familiar concept.
Googling for '"named pespective" database' gave me
"Relational Scaling and Databases" by Joachim Hereth,
http://wwwbib.mathematik.tu-darmstadt.de/Math-Net/Preprints/Listen/files/2208.pdf
. He talks about 'Conceptual Information Systems'.
He does pay some lipservice to updates and
normalization, but his intrests are in analyzing and
presenting; datawarehouses (fancy report generators using
technology and data from databases), not databases.
He quotes S. Abiteboul ea. in saying that "the differences
(between named and unnamed perspective, mA) are mainly
syntactical, while the expressivity is the same."
(Foundations of databases 1995).
The need to have something irrelevant in scope makes me suspicious.
>>>> DEFINITION: Two relations R and S are said to have dependency-induced >>>> overlap if there is a dependency that requires that sometimes some >>>> tuples(1) of R are also in S. >>>> (1) for some definition of tuples that allows restricted >>>> reshuffling of its values. To do. >>> The only way to achieve (1) so that it also takes all normal inclusion >>> dependencies into account is to define tuples as something equivalent >>> to bags of values. >> Nice, a third alternative way to state the same relation. >> How can this be relevant?
>
> It shows to what unacceptable consequences your demand is leading.
> It destroys the relational model as we know it.
My demand to get irrelevant stuff out of scope?
>>> Such an operation on its internal organs is going >>> to change the relational model beyond recognition. >> This is hardly surprising when part of the (database local) >> definition of relation is under discussion. More specifically: >> How do tuples conform to relation headers?
>
> Hm? What makes you think that this is under discussion? As far as I am
> concerned we are firmly sticking to the usual definitions.
>
>>> I'm going to >>> strongly insist that we stick to the classical definitions of the >>> named perspective and state in the definition that we are talking >>> about inclusion up to relabeling: >>> DEFINITION: Two relations R and S are said to have dependency-induced >>> overlap if there is a dependency that requires that sometimes some >>> tuples of R are also in S after renaming the attribute names. >> Two glossary todo items: [Trivial](new) and [Type]. >> The s/meaning overlap/dependency induced overlap/ >> did help to clarify. >> >> This time 'type' is the label on a jar containing something else.
>
> I don't think I used the word "type" in any of my definitions. I only
> mentioned it because you did. You want to redefine that also? Is there
> no end to this madness? ;-)
>
>> Which 'classical definitions of the named perspective' do you mean?
>
> As in the Alice book. Pretty much *the* authority in the area of
> database theory.
>
>> Do you have a suggestion for >> s/type/$some_name_dependent_notion_similar_to_but_not_the_same_as_type/ >> in PoOD related discussions ?
>
> Yes, don't. :-) IMNSHO that part of the POOD discussion clearly
> doesn't make sense and at best leads only to a crippled version of the
> relational model.
Ah... (<=== sigh of relief), now that is a lot stronger than my reservation.
> But if you insist and want a name for that kind of thing
I don't. I prefer to completely throw
"...type-compatibility as we define it
requires the two tables to have identical column names."
out - which is what you seem to be doing. Are you?
> thing then I can tell that suspect (but might be wrong because it's
> not really well defined) that the thing your are talking about is
> often called a "named type", and if you want to emphasize that you are
> talking about the other kind the term "anonymous type" is often used.
Received on Sat Feb 02 2008 - 13:50:33 CET