 | |
Re: foreign key constraint versus referential integrity constraint
comp.databases.theory comp.databases.theory
 |
| | Thread Tools | Display Modes |
#51
 
| |||
| |||
|
Re: foreign key constraint versus referential integrity constraint -
10-26-2009
, 11:28 PM
|
But surely you understand that's what type casts are for. Right? |
#52
| |||
| |||
|
|
But surely you understand that's what type casts are for. Right? |
philip
#53
| |||
| |||
|
|
Marshall wrote: On Oct 25, 4:15 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote: Marshall wrote: On Oct 24, 12:13 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote: Domains, however, define what is or is not joinable because natural join applies the equality comparison to attributes with like names, and domains define equality comparisons. That may be the most practical perspective, but from a theoretical perspective, I find myself lately thinking that every value of every domain is theoretically able to be compared for equality with every value of every domain. If we are considering comparing an integer and a string, we can say with confidence ahead of time that the comparison will return that they are unequal. For the comparison, that's fine. But what is the type of the resulting attribute? We are discussing natural join. Suppose we have 2 relations: state: { * * *(id in char(2),name in string) | * * * * * *('AK','Alaska'), ('NY', 'New York) ... } inventory_bin: { * * *(id in integer, contents in string) | * * * * * *( 1, 'Soup' ), ( 2, 'Nuts' ) ... } When we evaluate state join inventory_bin, we know the body is empty, but what is the type of the id attribute? state join inventory_bin: { * * *(id in ??,name in string,contents in string) | } Well. If the system is untyped, the question doesn't even come up. (Not that I would ever use such a system, but I mention it for completeness.) In a typed system, the type is whatever the intersection of int and string is. Union not intersection. It has to be a type compatible with both integer and string. |
with a string. Is it?
The other points you made seem to be variations on the
same question.
Quote:
|
On the weekends I often hang out with my oldest daughter at the local Starbucks; I sip coffee and she people-watches. I sit and she prefers to stand. If we go in the afternoon that means I'm in the shade and she's not. Today we went at twelve thirty, and she got sunburned. Ouch! |
I haven't had any alcohol in a week or more. Maybe
a drink is in order? Plus, I think there is a cupcake in
a cupboard somewhere downstairs. I must away!
Marshall
#54
| |||
| |||
|
|
On Oct 25, 10:52 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote: Marshall wrote: On Oct 25, 4:15 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote: Marshall wrote: On Oct 24, 12:13 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote: Domains, however, define what is or is not joinable because natural join applies the equality comparison to attributes with like names, and domains define equality comparisons. That may be the most practical perspective, but from a theoretical perspective, I find myself lately thinking that every value of every domain is theoretically able to be compared for equality with every value of every domain. If we are considering comparing an integer and a string, we can say with confidence ahead of time that the comparison will return that they are unequal. For the comparison, that's fine. But what is the type of the resulting attribute? We are discussing natural join. Suppose we have 2 relations: state: { (id in char(2),name in string) | ('AK','Alaska'), ('NY', 'New York) ... } inventory_bin: { (id in integer, contents in string) | ( 1, 'Soup' ), ( 2, 'Nuts' ) ... } When we evaluate state join inventory_bin, we know the body is empty, but what is the type of the id attribute? state join inventory_bin: { (id in ??,name in string,contents in string) | } Well. If the system is untyped, the question doesn't even come up. (Not that I would ever use such a system, but I mention it for completeness.) In a typed system, the type is whatever the intersection of int and string is. Union not intersection. It has to be a type compatible with both integer and string. I don't see how that would work. An integer isn't type compatible with a string. Is it? |
compatible with TOP or the universal supertype. String doesn't have to
be compatible with integer either. It only has to be compatible with TOP
or the universal supertype.
Quote:
|
The other points you made seem to be variations on the same question. |
easy to get wrong. The type of the joined attribute has to be TOP which
has the union of all values and an empty set of operations (or actually
a single "equals" comparison operation) not an empty set of values and
the union of all operations.
Quote:
|
On the weekends I often hang out with my oldest daughter at the local Starbucks; I sip coffee and she people-watches. I sit and she prefers to stand. If we go in the afternoon that means I'm in the shade and she's not. Today we went at twelve thirty, and she got sunburned. Ouch! Fortunately, I'm not hot any more. Now I'm thinking that I haven't had any alcohol in a week or more. Maybe a drink is in order? Plus, I think there is a cupcake in a cupboard somewhere downstairs. I must away! Marshall |
skunk smell out of the vestibule before it pollutes the house any more
than it already has, when I would much rather just go to bed.
#55
| |||
| |||
|
|
Cimode wrote: On 25 oct, 04:56, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote: paul c wrote: Bob Badour wrote: ... You asked about semantic joinability. Semantically, the join works if like-named attributes have an equality comparison defined and not if they don't. ... In RT, how could they not define equality? What reason would one have to define an equality comparison to compare employee ids with department ids or with names? Or charge with current or potential? Or age with price? Hi paul, A valid set of questions (pun intended). *My conclusion were that Codd was focused onto defining a side of the relational model that would be part of information system as opposed as being a part of mathematics since relational domain analysis is more loosely coupled with set theory than relational general model. While relational domain analysis is not mandatory in the context of the general relational model, it is mandatory in the context of implementation of RM. * *It even makes header based definitions somehow moot...IMHO... Regards... Cimode, I tend to look at it the same way, at least the part about the information system motive, not sure about headers. *If I recall it wasn't until his second paper that he introduced the pair of attribute and domain name, he was adjusting his theory to meet practice. A reasonnable assumption. Since I went back to domain analysis for |
implementation, that conclusion quickly imposed itself on me. Domain
analysis is for instance more relevant than relational general theory
for physically representing set disjointedness ...
#56
| |||
| |||
|
|
Marshall wrote: In a typed system, the type is whatever the intersection of int and string is. Union not intersection. It has to be a type compatible with both integer and string. I don't see how that would work. An integer isn't type compatible with a string. Is it? It doesn't have to be compatible with a string. It only has to be compatible with TOP or the universal supertype. String doesn't have to be compatible with integer either. It only has to be compatible with TOP or the universal supertype. |
I'll just regurgitate the argument I thought of before I went to
bed:
Consider relations A and B each with a single, common attribute.
Natural join and inner union will behave much like intersection
and union in this case. If the result type of the join isn't an
intersection type, then we lose the property:
A = A join (A union B)
because the type of the attribute of the expression is different
than the type of the attribute of A.
More generally, the values in the result of a join are the
intersection
of the values in the operands; why wouldn't the result type be the
intersection type?
Also, what about the analogous situation with inner union? Would
the type of the common attributes be a union type or an intersection
type? The values are the union of the values of the operands,
so I would propose that it has to be a union type.
Quote:
|
Fortunately, I'm not hot any more. Now I'm thinking that I haven't had any alcohol in a week or more. Maybe a drink is in order? Plus, I think there is a cupcake in a cupboard somewhere downstairs. I must away! Having bathed each of my 3 dogs several times, I now have to wash the skunk smell out of the vestibule before it pollutes the house any more than it already has, when I would much rather just go to bed. |
I skipped the drink but I found the cupcake. It was getting a
bit on the dry side but still quite tasty! Now it's time for me
to make my son some pancakes and send him off to school.
Marshall
#57
| |||
| |||
|
|
More generally, the values in the result of a join are the intersection of the values in the operands; why wouldn't the result type be the intersection type? |
weaker kind only considers set operations and typing in general. In
this frame of mind, and as Bob already pointed out, you will have to
find the common supertype of string and integer before you even have
the comparison operator available. The lowest common supertype in this
case is TOP, which as it happens *only* has a single equality
comparison operator. The type of the join column is then the supertype
where we finally find the means of comparison, i.e. TOP.
But you can also go deeper and consider the semantics of the equality
operator. Then you actually know that the result set is always the
intersection of the incoming ones, that because of that we can unify
the two sides of the resulting comparison to get "the join column" of
one homogeneous type, and furthermore that, in the case of types whose
least common supertype is TOP, the intersection type will also be
uninhabited. What happens is that now we're actually propagating types
through different kinds of operators, and the equality comparison
operator is just one of them, with its particular properties. A
minimum nontrivial counterexample in this vein would probably be a
join using a less-than comparison between integers and floats.
Quote:
|
Consider relations A and B each with a single, common attribute. Natural join and inner union will behave much like intersection and union in this case. If the result type of the join isn't an intersection type, then we lose the property: A = A join (A union B) because the type of the attribute of the expression is different than the type of the attribute of A. |
words for the values considered as inhabitants of TOP. That's
essentially because type logics tend to be intuitionistic, or even
modal, not classical.
--
Sampo
#58
| |||
| |||
|
|
Consider relations A and B each with a single, common attribute. Natural join and inner union will behave much like intersection and union in this case. If the result type of the join isn't an intersection type, then we lose the property: A = A join (A union B) because the type of the attribute of the expression is different than the type of the attribute of A. ... |
that property is important because without it you don't have a
relational lattice or is it important because without it some practical
use is lost?
(I may be far out in left field as far as mathematicians and type
theorists are concerned, but my simple interpretation of the Information
Principle is that the type of A{c} JOIN B{c} is {c}, whether it is a
union or intersection doesn't need to be asked.)
#59
| ||||
| ||||
|
|
On Oct 26, 10:29 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote: Marshall wrote: In a typed system, the type is whatever the intersection of int and string is. Union not intersection. It has to be a type compatible with both integer and string. I don't see how that would work. An integer isn't type compatible with a string. Is it? It doesn't have to be compatible with a string. It only has to be compatible with TOP or the universal supertype. String doesn't have to be compatible with integer either. It only has to be compatible with TOP or the universal supertype. OK, I didn't get much sleep last night so I'm not very sharp, but I'll just regurgitate the argument I thought of before I went to bed: Consider relations A and B each with a single, common attribute. Natural join and inner union will behave much like intersection and union in this case. If the result type of the join isn't an intersection type, then we lose the property: A = A join (A union B) because the type of the attribute of the expression is different than the type of the attribute of A. |
Because you will join A with a supertype of A, the MST will be the same
as the type of A. This is different from the case joining an integer
with a string because the MST is the universal supertype.
Quote:
|
More generally, the values in the result of a join are the intersection of the values in the operands; why wouldn't the result type be the intersection type? |
types that are both supertypes of some set of subtypes, the resulting
type will be the union type of those subtypes or the most specific
supertype of those subtypes. In the case where there are no common
subtypes, the resulting type will be the union type of the types
themselves or the most specific supertype of them, and the body will be
empty.
Quote:
|
Also, what about the analogous situation with inner union? Would the type of the common attributes be a union type or an intersection type? The values are the union of the values of the operands, so I would propose that it has to be a union type. |
specific supertype, which might be a union type. If you union circles
with hyperbola, the type will be conic sections. If you union circles
with ellipses, the type will be ellipses.
Quote:
|
Fortunately, I'm not hot any more. Now I'm thinking that I haven't had any alcohol in a week or more. Maybe a drink is in order? Plus, I think there is a cupcake in a cupboard somewhere downstairs. I must away! Having bathed each of my 3 dogs several times, I now have to wash the skunk smell out of the vestibule before it pollutes the house any more than it already has, when I would much rather just go to bed. Ouch! That sucks about the skunk. I skipped the drink but I found the cupcake. It was getting a bit on the dry side but still quite tasty! Now it's time for me to make my son some pancakes and send him off to school. |
off him before bathing him. I have to mix up another batch of peroxide
and baking soda just for it. I should have just left it on him.
#60
| |||
| |||
|
|
I didn't skip anything, but I missed Ollie's radio collar, which I took off him before bathing him. I have to mix up another batch of peroxide and baking soda just for it. I should have just left it on him.- Hide quoted text - - Show quoted text - |
meaningful advice (since, like mine, your dogs will undoubtedly play
this game again)
Next time, try Dawn dishwashing liquid. In the past, I've tried a
specialty shampoo, and the baking soda/peroxide recipe, but Dawn alone
seems to do the trick the best. I'm fortunate in that I have 3 Germain
Shorthaired Pointers, so their fur tends not to hold on to the scent
as much as a longer-haired dog. Plus, they have improved on the art of
the quick kill, which greatly reduces the emissions from the
unfortunate animal.
Now to get back to thinking about types, supertypes, domains and
such
TroyK
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.