Re: Why does 1:3 relationsihp require another table?
From: Anith Sen (anith_at_bizdatasolutions.com)
Date: 05/16/04
- Next message: Tibor Karaszi: "Re: DateTime value behaviour"
- Previous message: AlexS: "Re: Modeling Question: Multiple Relationships"
- In reply to: Steve Kass: "Re: Why does 1:3 relationsihp require another table?"
- Next in thread: Steve Kass: "Re: Why does 1:3 relationsihp require another table?"
- Reply: Steve Kass: "Re: Why does 1:3 relationsihp require another table?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 16 May 2004 00:12:07 -0500
>> ..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.
>> 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.
-- Anith
- Next message: Tibor Karaszi: "Re: DateTime value behaviour"
- Previous message: AlexS: "Re: Modeling Question: Multiple Relationships"
- In reply to: Steve Kass: "Re: Why does 1:3 relationsihp require another table?"
- Next in thread: Steve Kass: "Re: Why does 1:3 relationsihp require another table?"
- Reply: Steve Kass: "Re: Why does 1:3 relationsihp require another table?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|