Content deleted Content added
m →Check constraints and foreign keys: {{code|}} |
m →If joins or unions are considered: not even weak representation: {{mono}}, {{code}} |
||
Line 343:
=== If joins or unions are considered: not even weak representation ===
Consider the following query over the same Codd table {{mono|Emp}} from the previous section:
<syntaxhighlight lang="sql">
Line 351:
</syntaxhighlight>
Whatever concrete value one would choose for the {{NULL}} age of Harriet, the above query will return the full column of names of any model of {{mono|Emp}}, but when the (lifted) query is run on {{mono|Emp}} itself, Harriet will always be missing, i.e. we have:
{| style="margin: 0 auto;" cellpadding="20"
|- valign="center"
| Query result on {{mono|Emp}}:
||
{| class="wikitable"
Line 365:
| Charles
|}
|| Query result on any model of {{mono|Emp}}:
||
{| class="wikitable"
Line 428:
|}
The intuition for what happens above is that the Codd tables representing the projections in the subqueries lose track of the fact that the Nulls in the columns F12.F2 and F23.F2 are actually copies of the originals in the table J. This observation suggests that a relatively simple improvement of Codd tables (which works correctly for this example) would be to use ''Skolem constants'' (meaning [[Skolem function]]s which are also [[constant function]]s), say ω<sub>12</sub> and ω<sub>22</sub> instead of a single NULL symbol. Such an approach, called v-tables or Naive tables, is computationally less expensive that the c-tables discussed above. However it is still not a complete solution for incomplete information in the sense that v-tables are only a weak representation for queries not using any negations in selection (and not using any set difference either). The first example considered in this section is using a negative selection clause, {{code|WHERE Age <> 22|sql}}, so it is also an example where v-tables queries would not report sure information.
==Check constraints and foreign keys==
| |||