Re: Why does 1:3 relationsihp require another table?
From: Steve Kass (skass_at_drew.edu)
Date: 05/16/04
- Next message: Tibor Karaszi: "Re: date conversion?"
- Previous message: Tibor Karaszi: "Re: DateTime value behaviour"
- In reply to: Anith Sen: "Re: Why does 1:3 relationsihp require another table?"
- Next in thread: Anith Sen: "Re: Why does 1:3 relationsihp require another table?"
- Reply: Anith Sen: "Re: Why does 1:3 relationsihp require another table?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 16 May 2004 02:41:40 -0400
Anith Sen wrote:
>>>..one can build a theory like relational algebra basedon tuples that can
>>>
>>>
>contain that symbol in place of any domain value <<
>
>Perhaps one can, provided the symbol can handle all kinds of missing
>information without violating any existing 3VL tautologies. And it is
>practically difficult if not impossible and that is why NULLs or any such
>markers in place of values cannot be valid in a real-world proposition and
>thus violates 1NF.
>
>
No one has given a definition of 1NF yet in this thread that can be used
to determine if a model for a real-world scenario is 1NF. The
definition of 1NF I'm most familiar with is "every relation is 1NF",
which is fine if you only require that the relation model the relation
and assume there is no real world model. I offered something like "if A
and B are two rows that represent the same real-world information,"
then A and B must be equal when compared column-wise by =, where = is
whatever symmetric, transitive, binary operator is defined as equality
on the domain = is being used in (= is also defined when one of its
operators is NULL, and we could be using 2VL or 3VL, as long as we're
clear).
What's your definition of 1NF, and why is it incompatible with domains
that have an extra symbol called NULL? In fact, since no one has
defined NULL, either, what property are you assuming of the symbol NULL
that makes it always violate 1NF when it's allowed? If NULL is just a
symbol, like XYZ or 234, it wouldn't necessarily violate 1NF any more
than the integer 137 would if it were allowed into tuples of a relation
with integer domains, so I think it's fair to ask. Does any symbol X
for which X = X evaluates to UNKNOWN imply that 1NF is violated, for
example?
>
>
>>>Correct, but is it fair to say the development of SQL was guided by a
>>>
>>>
>desire to make NULL a good representation of a real-world unknown more than
>it was guided by a desire to make NULL a good representation of NoValueHere?
><<
>
>I doubt it. If representation of unknown value is the idea behind the
>implementation of NULLs in SQL, then SQL avoids far too many kinds of
>missing information which is quite common in the real world. Given an
>attribute a, there are many interpretations for the statement "a is null":
>1. Inapplicable value (Codd's I-mark)
>2. Non-existent value
>3. Unknown value (Codd's A-mark, which is claimed to be in SQL)
>4. Undefined value
>5. Not supplied value (variations: not yet, since then etc.)
>6. Invalid value
>7. Empty set (hint: outer joins)
>8. and several more...
>
>
>By assuming support for just one kind of missing information (Unknown value
>in our case), support for NULLs in SQL or any such markers, may have to
>ignore all other kinds of missing information handling. Given no NULLs, the
>system can live with the traditional 2VL and with an additional single kind
>of "null" (to handle the meaning Unknown) it requires 3VL and so on. In
>other words, to deal with the 7 kinds of "nulls" above one would need a
>logic of 9 values (9VL). In general, given N kinds of "nulls", one would
>need (N+2)valued logic, which is quite impossible with the existing naivete
>approach in SQL.
>
>
I'm not sure whether you're disagreeing with me or not. I'm saying that
SQL tries to use 3VL and choices were made so that NULL #3 is modeled
best, but that one could choose any single NULL (I chose #5, I think),
and within 3VL define appropriate = operators so that relations with
NULLs could be 1NF. But I'll admit that I don't know what definition of
1NF we're using, so I'm mostly just blabbering until we settle that.
SK
- Next message: Tibor Karaszi: "Re: date conversion?"
- Previous message: Tibor Karaszi: "Re: DateTime value behaviour"
- In reply to: Anith Sen: "Re: Why does 1:3 relationsihp require another table?"
- Next in thread: Anith Sen: "Re: Why does 1:3 relationsihp require another table?"
- Reply: Anith Sen: "Re: Why does 1:3 relationsihp require another table?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
