 | |
Re: foreign key constraint versus referential integrity constraint
comp.databases.theory comp.databases.theory
 |
| | Thread Tools | Display Modes |
#31
 
| |||
| |||
|
Re: foreign key constraint versus referential integrity constraint -
10-25-2009
, 05:15 PM
|
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. |
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) |
}
Quote:
|
I also am suspicious of the idea of allowing a domain designer to define equality. From a theoretical standpoint, the system ought to know enough to figure it out, and from a practical standpoint, I've seen enough class designers screw it up with subtle and annoying consequences. Damn them! |
possrep.
Quote:
|
Marshall (Still hot; still grumpy.) |
But to be fair, there was a nice gusty wind to take the edge off the
heat.
#32
| |||
| |||
|
|
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) | } ... |
illogical if the model (just another word for 'interpretation') let the
heading be (id in char(2), id in integer, name ... etc.) even if that's
contrary to TTM, not to mention sql convention. Surely the problem has
less to do the technical heading than with preferring a language to
reference only by name?
#33
| |||
| |||
|
|
Bob Badour 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) | } ... Not that I'm advocating it but I imagine there would be nothing illogical if the model (just another word for 'interpretation') let the heading be (id in char(2), id in integer, name ... etc.) even if that's contrary to TTM, not to mention sql convention. |
id mean if you pretend it means two mutually exclusive things?
#34
| |||
| |||
|
|
paul c wrote: .... Not that I'm advocating it but I imagine there would be nothing illogical if the model (just another word for 'interpretation') let the heading be (id in char(2), id in integer, name ... etc.) even if that's contrary to TTM, not to mention sql convention. It would be very illogical. Names are very important things. What does id mean if you pretend it means two mutually exclusive things? |
attribute. Personally, another alternative wouldn't bother me, eg.
excluding both both attributes from the heading union.
#35
| |||
| |||
|
|
Bob Badour wrote: paul c wrote: ... Not that I'm advocating it but I imagine there would be nothing illogical if the model (just another word for 'interpretation') let the heading be (id in char(2), id in integer, name ... etc.) even if that's contrary to TTM, not to mention sql convention. It would be very illogical. Names are very important things. What does id mean if you pretend it means two mutually exclusive things? Obviously you wouldn't, you would have to name the type as well as the attribute. Personally, another alternative wouldn't bother me, eg. excluding both both attributes from the heading union. |
comparison? That makes no sense to me whatsoever.
#36
| |||
| |||
|
|
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) | } |
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. Since we know, as mentioned, that
there are no values that are both ints and strings, we
certainly know that whatever the type is, it will be
uninhabited. (That is, it has no values.) So either "the
intersection of int and string" or else simply the empty
type, aka "bottom" or "void" or what have you.
Now that I've said all that, I agree that there are
good arguments for saying (how did you put it?)
you get an error or a warning or something like that
instead.
Quote:
|
I also am suspicious of the idea of allowing a domain designer to define equality. From a theoretical standpoint, the system ought to know enough to figure it out, and from a practical standpoint, I've seen enough class designers screw it up with subtle and annoying consequences. Damn them! I suppose in TTM, equality is implicit based on type and any arbitrary possrep. |
Quote:
|
Marshall (Still hot; still grumpy.) Yeah, it was hot here today to. It got all the way up into the 50's F. But to be fair, there was a nice gusty wind to take the edge off the heat. |
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.
Marshall
#37
| ||||
| ||||
|
|
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. |
and string.
Quote:
|
Since we know, as mentioned, that there are no values that are both ints and strings, we certainly know that whatever the type is, it will be uninhabited. |
relation body is empty not because the type is empty but because no
integer values in the type happen to equal any string values in the type.
Quote:
|
(That is, it has no values.) So either "the intersection of int and string" or else simply the empty type, aka "bottom" or "void" or what have you. |
Quote:
|
Now that I've said all that, I agree that there are good arguments for saying (how did you put it?) you get an error or a warning or something like that instead. I also am suspicious of the idea of allowing a domain designer to define equality. From a theoretical standpoint, the system ought to know enough to figure it out, and from a practical standpoint, I've seen enough class designers screw it up with subtle and annoying consequences. Damn them! I suppose in TTM, equality is implicit based on type and any arbitrary possrep. It makes sense to me. Marshall (Still hot; still grumpy.) Yeah, it was hot here today to. It got all the way up into the 50's F. But to be fair, there was a nice gusty wind to take the edge off the heat. 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. |
#38
| |||
| |||
|
|
com... (AT) hotmail (DOT) com wrote: On Oct 24, 8:56 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote: 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? shoot your age and you are worth your weight in gold. My age in what measure? Years? Integral or rational? If integral, cardinal or ordinal? According to what calendar? |
comparisons that I'd say have reasons. Otherwise I agree with you.
Certainly the corresponding expressions depend on
the variable and function predicates.
philip
#39
| |||
| |||
|
|
On Oct 24, 10:53 am, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote: Anyhow, the question here is not one of our imagination but rather simply this: if it makes sense for the RM to support constraints on relational /values/ (taken on by variables) why does it not make sense to support constraints on relational /expressions/? That is a question of general principle not specific design. This question, it seems to me, is clear and to the point. And I would answer it by saying that we shouldn't really even make the distinction! (At least not formally.) |
(p /\ q) -> r is not the same as (p -> r) /\ (q -> r)
but (p \/ q) -> r is the same as (p -> r) \/ (q -> r)
A view consisting of a natural join, for example, represents a set of
conjunctions. Each row of the join represents a conjunction of
propositions, one for each operand. A constraint defined on a join would be
of the form (p /\ q) -> r. That is definitely not the same as constraints
defined on one or more tables, which would take the form (p \/ q) -> r.
Quote:
|
There are quite a lot of constraint taxonomies out there, and I haven't ever really been able to derive any particular value of any of them. Most generally, ever constraint is a constraint on the entire database; if the constraint mentions only a single variable, then we might say it is a "table constraint" or "relvar constraint" or some such, but that's only a degenerate case of a database constraint. So let us say there is only one type of constraint, the database constraint, and be done with it. Now that I've said that, let me take it back a bit. Transition constraints don't seem to be quite like anything else. Transition constraints are therefore annoying. :-) It's Sunday and I'm hot, so I'm posting with reckless abandon. Read my sentences at your own risk. Marshall |
#40
| |||
| |||
|
|
A sometimes disappearing attribute that is the very basis for comparison? That makes no sense to me whatsoever. |
incomparable such as these attributes disappear but they can be ignored
with enough willpower. From the day it was built, my father's Ford
FANCON (no, I didn't make the spelling error) had many loopholes but
during the times it was operational he preferred to drive rather than
walk.
Some systems will cop out with an error but without being able to inform
exactly what the error really is. That's because loopholes create their
own logic.
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.