Re: Network Example: Sibling of Opposite Gender

On Jan 2, 3:25 pm, kvnkrkpt..._at_gmail.com wrote:
> Marshall wrote:
> > On Dec 30, 10:51 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
> > > Check out some of the articles at:
>
> > >http://www.thethirdmanifesto.com/
>
> > > In particular, try:http://www.dcs.warwick.ac.uk/~hugh/TTM/Missing-info-without-nulls.pdf
>
> > Well, as much as I respect Mr. Darwen, (Dr. Darwen?) I don't find
> > this paper particularly compelling. While it certainly addresses the
> > semantic issues well, it doesn't show us much about how we're
> > going to do queries, and it doesn't particularly justify what
> > appears to be added complexity in updates.
>
> > And as near as I can tell, his solution goes to a great deal of
> > trouble simply to emulated tagged unions in a relational
> > language without them. It would be ever so much simpler
> > just to say, let our relational language support tagged unions.
>
> > http://en.wikipedia.org/wiki/Tagged_union
> > With tagged unions, would the solution resemble this?
>
> CREATE TABLE PERS_INFO
> (ID INTEGER,
> NAME VARCHAR2(30),
> JOB {VARCHAR2(30), UNKNOWN_JOB, UNEMPLOYED},
> SALARY {INTEGER, UNKNOWN_SAL, UNPAID});
>
> If so, how might one use these tags?
>
> SELECT NAME FROM PERS_INFO
> WHERE JOB.TYPE = UNEMPLOYED
>
> SELECT SUM(SALARY)
> FROM PERS_INFO; -- generates compile time error
>
> SELECT SUM(SALARY)
> FROM PERS_INFO
> WHERE SALARY.TYPE = INTEGER; -- works correctly
>
> Or am I completely missing the boat here?

That's basically what I was thinking. You need a tad more than what you put, though. Consider how you wrote this type:

{INTEGER, UNKNOWN_SAL, UNPAID} The first entry is an existing type, the second two are new tags. They should all three have the tags, the first of which has an additional parameter. Roughly:

{SALARIED(INTEGER), UNKNOWN_SAL, UNPAID} You can construct (or select, I guess Darwen would say) values of this type like so:

SALARY(10000)
UNKNOWN_SAL
SALARY(20000)
UNPAID etc.

You also need a "match" or extended CASE construct to "pull apart" the branches of the union and extract any parameters, such as in the SALARIED case. So if you wanted, for example, to calculate the sum of all the salaries, counting unknown as -10 and unpaid as 0 (a wildly unrealistic example, but illustrative) you do something like

select sum(case SALARY
  WHEN SALARIED(x) THEN x
  WHEN UNKNOWN_SAL THEN -10
  WHEN UNPAID THEN 0 END CASE) from PERS_INFO;

Marshall Received on Wed Jan 03 2007 - 03:04:21 CET