Re: Principle of Orthogonal Design
- From: mAsterdam <mAsterdam@xxxxxxxxxxx>
- Date: Mon, 28 Jan 2008 02:12:17 +0100
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>
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?
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?
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.
Which 'classical definitions of the named perspective' do you mean?
Do you have a suggestion for
s/type/$some_name_dependent_notion_similar_to_but_not_the_same_as_type/
in PoOD related discussions ?
.
- Follow-Ups:
- Re: Principle of Orthogonal Design
- From: Jan Hidders
- Re: Principle of Orthogonal Design
- References:
- Principle of Orthogonal Design
- From: JOG
- Re: Principle of Orthogonal Design
- From: JOG
- Re: Principle of Orthogonal Design
- From: Brian Selzer
- Re: Principle of Orthogonal Design
- From: David Cressey
- Re: Principle of Orthogonal Design
- From: JOG
- Re: Principle of Orthogonal Design
- From: Jan Hidders
- Re: Principle of Orthogonal Design
- From: mAsterdam
- Re: Principle of Orthogonal Design
- From: Jan Hidders
- Re: Principle of Orthogonal Design
- From: mAsterdam
- Re: Principle of Orthogonal Design
- From: Jan Hidders
- Re: Principle of Orthogonal Design
- From: mAsterdam
- Re: Principle of Orthogonal Design
- From: Jan Hidders
- Re: Principle of Orthogonal Design
- From: mAsterdam
- Re: Principle of Orthogonal Design
- From: Jan Hidders
- Re: Principle of Orthogonal Design
- From: mAsterdam
- Re: Principle of Orthogonal Design
- From: Jan Hidders
- Principle of Orthogonal Design
- Prev by Date: Re: what are keys and surrogates?
- Next by Date: Re: what are keys and surrogates?
- Previous by thread: Re: Principle of Orthogonal Design
- Next by thread: Re: Principle of Orthogonal Design
- Index(es):
Relevant Pages
|