Re: deductive databases

In article <p56dnTmpwdoJWxTfRVn-sQ_at_comcast.com>, VC wrote:
>
> "Simon Taylor" <stayl_at_cs.mu.oz.au> wrote in message
> news:428982b5$1_at_news.unimelb.edu.au...

>> Nesting is not significant; it's allowing data structures to express
>> choice that increases the expressive power.

Nested data where there is no choice between function symbols can always be flattened into 1NF.

>>Without that, database
>> developers have to resort to kludges like NULL or excessively complex
>> relational decompositions to deal with missing or optional data.

Taking the example from
<http://web.onetel.com/~hughdarwen/TheThirdManifesto/Missing-info-without-nulls.pdf>

The relational decomposition as described in that presentation is a poor solution because it makes queries more complex, the integrity constraints required can't be implemented in any available RDBMS, and probably couldn't be implemented efficiently anyway.

So, the missing or optional data needs to be embedded in the table somehow.

With NULLs:

--Table Person_Info ---------------------------------
Id	Name	Job_Info		Salary
-----------------------------------------------------
1234	"Anne"	"lawyer"		10000
1235	"Boris"	"banker"		NULL
1236	"Cindy"	NULL			70000
1237	"Dave"	NULL			NULL
-----------------------------------------------------

With special values:

--Table Person_Info ---------------------------------
Id	Name	Job_Info		Salary
-----------------------------------------------------
1234	"Anne"	"lawyer"		10000
1235	"Boris"	"banker"		-1
1236	"Cindy"	"unknown"		70000
1237	"Dave"	"unemployed"		0
-----------------------------------------------------

With function symbols / functors / algebraic data types:

---Table Person_Info --------------------------------
Id	Name	Job_Info		Salary
-----------------------------------------------------
1234	"Anne"	employed("lawyer")	salary(10000)
1235	"Boris"	employed("banker")	unknown
1236	"Cindy"	unknown			salary(70000)
1237	"Dave"	unemployed		unsalaried
-----------------------------------------------------

In short, the version using function symbols has much more of a "say what you mean" flavour to it, and is simpler and more robust for it. The downside is that it is more difficult for application languages like C and Java to work with.

Simon Taylor. Received on Tue May 17 2005 - 16:23:18 CEST