RELATIONAL ALGEBRAS, LOGIC, AND FUNCTIONALPROGRAMMING

Patrick A.V. Hall

Cirrus Computers Ltd.,29/30 High Street, Fareham, PO16 7AD, England.

ABSTRACT non-procedural or semi-procedural languages [e.g.

GRAD 83, MCCR 801. The facilities are often
Relational algebras as developed by Codd and his loosely founded on the relational theories of Codd
followers are extended by noting an equivalence [CODD 721 but add various additional facilities in
with functional languages. This leads to higher ad hoc manner.
order relatione, recursive definition8 of
relations, and the use of higher order relations In this paper I start with relational databases,
as recursive data structures. This equivalence on and interpret the relational algebra functionally,
the one hand enables the technology of databases to extend thie to embrace all the power and
to be used within the context of applicative theoretical neatness of functional languages. In
languages, and on the other hand removes the adhoc doing this my intentions are twofold.
mechanisms used for higher order operations in to provide a theoretical basi8 for the 4th
relational databases. This leads from 4th to 5th generation data processing languages, to
generation data management, exploiting the enable them to move into the 5th generation.
mathematical foundations of functional languages to integrate functional, logic, and
and logic programming, and the technology of relations1 languages so that they can share
relational database. technology.

This exploration is by no meens complete, for a

1.0 INTRODUCTION critical aspect, the time dimension and updates,
has not been addressed. However this paper must
Logic programming and functional programming have be viewed as a necessary pre-requisite for that
recently become very fashionable through interest later study.
in "5th generationI computing. Logic and
functional programming have, of course, been In section 2, the historical background to this
around a long time. So has the application of study is described, and relationships to other
computers to commerce, and the use of databases work explained.
for that application. Logic prcgmnming has seen
the challenge and responded to it [GN 781. In section 3, the relational algebra is developed
Functional programming appears not to have, except as an applicative language. This correspondence
in the use of functional ideas in some query with applicative languages adds capabilities to
languages IBF 79, SHIP.811. the algebra, with recursive definitions, higher
order relations, and recursive data Structures,
Yet it is databases that form the foundation of a presented in Section 4 and 5. An example is given
very large bulk of computing applications, from in Section 6.
COFIOL systems to those usillg the moat
sophisticated data management software. In this
area we are seeing the emergence of a large number 2.0 BACKGROUND
of commercial systems, often styled "4th
Generation", based on data dictlonaries and During the development of the research relational
providing various facilities t-ugh database system PRTV [TODD 761 at IBM Peterlee,
Perm~smonto copy wlthout fee all or part of tbls matenal IS granted the relational algebra was used as the data
provaicd that the copies arc not made or dlstnbutcd for drrcct manipulation language. In its original form [coDD
commercud advantage, the ACM copyngbt notice and the tltk of the 701, relations had been defined as subsets of
pubhcatron and I@ data appear, and no& IS @ven that copymg IS by Cartesian products on a number of domains. In
pcrmlsslon of the Assoclauon for Computmg Machmery To copy order to achieve a position independent notation
otbenvlsc, or to rcpubbsb, rcqturcs a fee and/or spccdic pcrmlsslon for relations, the 'columns were distinguished by
the domain name, or where several domains were the
0 1984 ACM 0-89791-128-8/84/006/0326 $00 75 sane, by a 'role name'. However there were some
technical problems with the name inheritance in
the 1join' operations of the relatlonal algebra.
The key relational operation is the 'equi-join',
where two relations are combined in a Cartesian

326
product constrained by equality of values between into PROLOGI [e.g. CM 811. Indeed one could
matching domains of the two relationa. The conjecture a paper titled, "Lists considered
notation in the relatlonal algebra used for the harmful". For storage of information for
PRTV was a Cartesian product associated with a commercial data processing lists are particularly
'selection' which indicated the columns to be inadequate. Relations as sets have no single
equated, for example ordering, and lists imposes one. Relations may be
Rl * R2 A=B complexly interconnected at the user level this
interconnection may be considered associative, but
A and B are role names, where A is a column of Rl, internally they need explicit connections not
and B a column of R2. The result is a relation of permitted in lists. The structure present in the
n + m columns (n = number of columns of Rl and m = problem must be capable of direct expression,
number of columns of R2. Two of these columns are extra structure to aid processing must be capable
identical - columns A and B, and clearly one of addition, extraneous structure which interferes
should be removed, but which one? In the PRTV with both must not be imposed. Thus a major
this was specified using a project operation, but motivation of this paper is to move away from
we felt there must be better ways of solving the lists while still remaining an applicative
role inheritance problem. language.
At the same time Stephen Todd was investigating A recent stimulating paper by Bob Kowalski [KOWA
how to ~~escape~~from the relational algebra into 831 notes the equivalence between predicates
PL/I, and one method he came up with replaced a (relations) and functions, and explores logic
relation by a PL/l procedure call. An equivalence PWgramning capabilities to match functional
between relations and procedures became evident, Programming. Here I go beyond that paper to
and we sought ways of reformulating the relational produce a full relational applicative language.
algebra so that the fact that a PL/I procedure was Perhaps this may in turn enrich logic programming.
invoked would be transparent.
Uniting relations with functional languages leads
The result was a l'generalised** relational algebra us to higher order relations, relations not in
(see example below) in which Codd 1st normal form. There has been a recent
matching role names in a Cartesian Waturall' move in this direction, as relational databases
join caused an equijoin on these columns. have been applied to engineering applications [eg.
the number of operations was reduced to LP 83, AR 841, and this paper completes this cycle
four. of development with an algebra of relations
This was published at a conference in 1975 [HHT appropriate to general hierarchical relations.
751 together with an analysis of the restrictions
cawed by the directional properties of
procedures. The paper was presented in a highly 3.0 A RELATIONAL APPLICATIVE LANGUAGE
analytical manner, and is not easy to read.
The basic languaf3e consists of relations,
An example of the generalised algebra is expressions involving these relations, and
Rl(X,Y,A,C)*R2(P,A,Q,X,F) definitional equations. Examples are shown in
which causes an equi-join on columns A and X in figures, to be motivated in the discussion below.
the two relations, yeilding a result
The basic syntax is.
relation-definition .= typed-relation 'w'
The resemblance of this to the predicate logic expression
formula typed-relation = relation-name relation-type
Pl(x,y,a,c) & W(p,a,l,x,f) relation-type = "(I' variable 'I 'I type I","
was initially coincidental, but it was soon variable I1 @Itype) ")'I
pointed out to us by Bob Kowalski. The expression I expression operator expression
correspondence has, of course, now been explored Imodadic-op expression
in depth [e.g. GM 781. Irelational-constant
Iuntyped-relation
At this time (1975) applicative languages were 111(11expression @*)"
beginning their regeneration led by, among others, operator = It*11 1 11+11
John Bachus [BACH781. It struck me then that monadic-op = II-11
there was a correspondence between the generalised relational-constant = relation-type 11[11tuple
join and functional application, but other things (",*' tuple} ")"
intervened. Then, recently, the appearance of two tuple = "(I1 value [*',I' value} ")"
books [HKND 80, DHT 821 has renewed my interest untyped-relation = relation-name '*(" variable
and the result is this paper. (ll,@* variable) ")I1

Applicative languages as they have developed today Notation. terminals have been included in quotes,
[as exemplified by the collection DHT 821 are braces v(** and 11)'1are metasymbols and have been
still very much moulded in the LISP tradition. included in quotation marks where they are
The critical limitation that this imposes is their required as terminal symbols.
dependence upon lists. For some applications
lists are an appropriate structure, but all too A relation is interpreted as a subset of the
frequently they are inappropriate, both as a means Cartesian product of the types. A type is a set.
of expressing the problem, and as a representation initially this is not particularly significant but
to aseist computation. Lists have evsn intruded later we will need to invoke a complete

327
type-lattice to make our 1-e general.
Position in the parameters list is significant, as precisely for this composition operation that the
in programming languages. The variables are used original generalised algebra was developed [HHT
for binding. A relation may be represented either 751.
extensionally, as an explicit set of "tuples" or
intensionally by some rule such as a relational
expression. The type of a relation is the list of
its parameters and their type, where the variables FIGURE 2
are not significant but position is. Relation Example of Relational Composition as Intersection
constants can be written as sets of tuples
conforming to the relation type immediately
preceding it. Alternative interpretations of MORK-RKADINGS(Pressure.real, Angle real)
relations are, as Predicates in Logic, and 5 (Pressure*real,angle real)
proceduut calls in programming languages. ((0.9,10),(1.3,10),(3.6,15),(4.2.25),(8.7,45)

The operations are define

CHECKED-RKADINGS(p.real, a real)
l relational composition = MORE-READINGS(p,a) l READINGS(p,a)
+ relational alternation
CmCKED-RKADINGS is ((1.3,10),(8.7,45))
relational complement

Alternation is normal set union for relations of

the same type, inhomogeneous combinations are not
permitted (though *w could be allowed).
FIGDRE3
Complement is relative to the base type of the Example of Relation Composition as Selection
relation, the usual set complement. Composition
is the key operation, and requires explanation. define
GOOD_RANOE(Pressure.real, Angle real)
=angle<50 and Pressure>l.O
GOOD-READINGS(Preal, A real)
FIGURE 1 = RiTADINGS(P,A)*GOOD_RANOE(P,A)
&ample of Relational Composition as an Equijoin
GOOD-READINGSis t(l.3, 10),(4.2, 20),(8.7,45))
READINGS SINE
(Pressure, Angle ) (Angle, Value)
.real *real real real
[( 1.3, 10 ), r( 0, 0.0000 1, FIGURE 4
I 4.2, 45
20 1, ( 20,
10, 0.1736
0.3420 ),
Relational Composition as Functional Application
( 1:::: 70 11 ( 30, 0.5000 1,
( 40, 0.6428 1, FUNCTIONS
( 50, 0.7660 ),
Sine R -> R
( 60, 0.8660 ),
Square-root R+ -> R
( 70, 0.9397 1, f R->R
( 80, 0.9848 ),
( 90, l.ooo 11 = square-root (sine (angle))
f bwle)
define
ANALYSIS(Pressure real, Angle real, Value real) RELATIONS
= RIIADINGS (Pressure, Angle) l SINE (Angle, Value) Functions are 'convertsd' to relations by placing
an explicit results parameter last.
ANALYSIS is ((1.3 , 10 , 0.1736 ),
(4.2 , 20 s 0.3420 1, SINE (angle real,value real)
(11.1 ) 70 , 0.9397 )) SQUARE-ROOT(Number:real, root real)

F(Angle*real,Value real, Result:real)

In relational databases, composition covers the = SINE(Angle,value) l SQUARE-ROOT(value,result)
normal equijoin, where the columns to be equated
are indicated by coinciding variables in the
columns. Figure 1 shows an example. However, The interpretation of the operations in logic
composition also covers set intersection, as shown programming are straightforward
in Figure 2, and selection as in Figure 3. From
these examples it should be clear that the
*AND
?ables10 could be %irtuall', and rather than being
defined extensionally, could be defined + OR
intentionally by a program. The sine relation of
figure 1 could, indeed should, have been a library - NOT
Program* and we used an implicit definition in
Figure 3 to emphasise the use of composition as The interpretation in conventional (functional)
selection. We will use arithmetic and logical programming languages is not so straightforward.
expressions informally in later examples. It was The '+I allows functional composition, I+' allows

328
alternatives to be combined as in ,,case,, and
"if . ..then...else., constructs. All three together positional significance of these in principle,
allow logic conditions. Figures 4 and 5 show all variables on the right-hand sids should
examples, expressed both in the functional appear. However, if some are omitted, this means
programming notation of Henderson [HKND 801 and in that they are projected out. Thus in Figures 4
the relational notation. and 5 the intermediate "value,, can be omitted, to
make the relational expression identical in
However, our composition operator is far more semantics to the functional Programming
powerful than traditional functional composition, expression.
for it allows functions to be used "backwards,,.
(Kowalski [KOWA~S] calls this ,,invertibility,,) As observed by Codd [CODD 721, projection involves
existential quantification, thereby giving the
relational algebra the power of the first order
predicate logic.
FIGURE 5 - Conditional Applicative Expressions
One could reasonably also allow extra columns on
the left hand side, interpretting these as
FUNCTIONS Cartesian products extending the relation defined
Sine R -> R by the right hand side of the definition.
Square-root R+->R

g(angle)= (if x> 0 then square-root(x) 4.0 HIGHER ORDERRELATIONS

else square-root (-x)
where x=sine(angle) ) We now consider relations where the columns
themselves may contain relations. Now in
RELATIONS relational databases this has been depracated ever
SINE (angle real, value real) since the first of codd,s papers [CODD 701.
SQUARE_RooT(Number real, root real) However the seeds of it have recurred in the need
to produce totals and subtotals, for which special
G(angle real, value real, result real) measures outside the framework of the theory have
= ((NON_P1RG(value)*SQUARE_ROOT(Value,result) had to be taken. An early attempt to handle this,
+ NEG(value)+NEGATE(value,x)*SQUARE~ROOT(x,result) based on the PRTV experience, was made by
)*SINB(angle,value) Hitchcock [HITC 761.
or
= ((value~O)*SQUARE~ROOT(value,result) Figure 7 shows an example, the cardinality
+ (value<O)*(x=-value)*SQUARE-ROOT (x,result) function which counts the members of a set. The
)*SINE(angle,value) tabulation only considers a few examples, and the
full relation must of course be represented
intensionally. At the moment we will assume some
built-in function outside our programming
An example of the use of SINE to compute arc-sine
language, but in the next section will see how to
is shown in Figure 6. Now tabular functions are
clearly able to be used bidirectionally, but if define this function recursively.
represented intensionally by programs would
typically be only useable in a limited direction,
This observation then leads to a further level of
,,effectiveness,, of FIGURE 7
theory around the
which was very thoroughly Example of Higher-order relation, Cardinality
representations
characterised in the 1975 paper [HHT 751. This
theory would be Vital for any functional
programming interpretation of the relational given
applicative language. CARDINALITY (set (...), size integer)
size integer)
=I~~(a),(b),(~~~(d~:~~~,(f),(g),(~)), 8)
(((0,0,01),(0,0,1,0)~, a:
FIGURE 6 - Using a table of SINES as Arcsine (((1,0.3),(2,56.2),(3,1.7),(4,13.8)}, 41,
(((FRED), (JOE)~ 2).
. . . 1
SINE - as in Figure 1
given table of DATA values define
SIZE~OF~SET(size integer)
DATA(setting real,measure real)=(...) t...)
= CARDINALITY(set,size)
define
ANALYSIS(setting,real,measure real,angle real) *(set ( . ..))~(~(0.0,0,~),(l0~~,
= DATA(setting,measure)*SINE(angle,measure) (I(FoRTRAN),(~~S~L),(ALDOL),(PASCAL),(LISP)~))

SIZE_oF_SET 1s t(2),(5))
One further operation is necessary. This IS the
,,projection,, of relational algebras. Rather than
To make this and other definitions of higher order
have a special operator for this, we will make it relations acceptable,
a property of the definitional equality ,,='. The we will have to consider
further the specification of "type,, in relations.
relation being defined and placed on the left-hand Up to this point we have assumed a base set of
side of ,,=,, lists its columns, thus determing the types like "real,,, ,,integer,,, ,,string,,, but now
*

329
must extend this to include relations themselves. digress from our main argument. The operation of
We have already defined the type of a relation as Figure 9 is the ,,GROUPBY,, operation of SQL [ABM
the list of the types of its columns, but that is 76) necessary for sub-totalling. Figure 9 shows
too restrictive for higher order relations like this use.
TOTAL shown in Figure 8 which must sum the values
of one column but does not care about the other
columns, if any. We will use a ,,...,, notation to
indicate optional columns, treating this FIGURE 9
informally while recognising that this should be Conversion from first-order to second-order
properly defined, perhaps as a lattice of types.
Figure 7 and 8 have used the notation we intend to
employ. The syntax is given
fullrelationtype = relationtype PURCHASE~DETAILS(supplier~string,item integer,
I ( variable type number integer,price.real)
11,..*;11-*~"
I "(...)" define
PURCHASES(supplier string,item integer,cost.real)
We will also allow columns to contain individual = PURCHASE~DBTAILS(supplier,item,number,price)
tuples, and denote their type in the same way as l (cost = number l price)
relations, but preceding the type description by a
prime PURCHASES-BY-SUPPLIER
tupletype 5: ,,,,, fullrelationtype (supplier string,order (item.integer,cost real))
= PURCHASES(supplier,item,cost)
The syntax for type is then
type = simpletype PURCHASES-SUMMARY (supplier string,total~cost~real)
I fullrelationtype = PURCHASES_BY_SUPPLIER(supplier,orders(item,cost))
I tupletype l TOTAL(orders.(...,cost,...),total-cost)
simpletype .*= identifier

We will pick out the components of a tuple using This simple operation for converting between
the usual dot notation orders of functions provides a very powerful file
typecomponent = tuplevariable ,,.,, conversion language, and could provide a
columnvariable theoretical basis for languages like EXPRESS [SHTG
771.
Higher order relations provide the ability to
FIGURE 8 - The Higher-order relation, TOTAL modify ,,programs,, in the sense that by suitable
relational expressions the transformations defined
by a relation can be changed. Note that this is
given different from the kind of changes featured by
TOTAL (relation (...,NUMBER real,.,.),total real) LISP which changes program text. Of course here
we could represent text by suitable relationships
define and do the sort of manipulations practiced in
ORDER~SUMMARY(supplier string,total-cost real) LISP, to write compilers and similar. However,
= TOTAL(orders (...,Cost,...),total-cost) that has not been my motivation, and my notation
*(supplier string,orders (item integer,cost real) has not been aimed at that.
((BLOGG_BROS,[(1,57.21),(32,1.06),(127,42.43))))

~RDER_SURWARY
IS ((BL~Gc-BROS, 100.70)) 5.0 RECURSIVEDEFINITIONS
Recursive definition of relations, inspired by the
Examples involving tuples as components only methods of functional programming, follows very
appear in section 4, Figures 11 and 12. readily. Figure 10 shows that overworked example,
the factorial function.
We can write relations as column values within
relation constants, as has been done in Figures 7
and 8. However we will need general mechanisms
for converting given relations into ,,equivalent,, FIGURE 10
higher order relations, and vice versa. Recursive Relational Definition of Factorial
For this we will extend the relational-definition
operation, so that the columns of a relation and fact(n) = if n==Othen 1 else n*fact(n-1)
its subrelation can be regrouped as shown in
Figure 9. The intermediate ,,PURCHASE,,relation is FACT(n integer,r integer)
not necessary, but has been included for clarity. = (n=G)*(x=l)
We will only use this operation in the form shown + (n>O)+(n*x=r)*(y+l=n)*FACT(y,x)
there, where a first order relation is converted
to a second relation with only one column of Note y+l=n is used to compute y=n-1.
relations. However a general operation could be
defined, though it will not be done here, since it
requires a very careful definition that would

330
Recursive definitions will be most useful in the the singleton relations and the elements contained
definitions of higher order relations, but before in them. The NON-SINGLETONrelation is defined as
we can do that, we need to be able to recurse on the relative complement of SINGLETON with the
the relations themselves, in the same way that elements projected out.
LISP and its derivatlves recurse on list
structures. We could choose to treat relations as
sequences and follow the practices of LISP, but
relations are sets and no ordering may be natural. FIGURE 12
The Split Function and another definition of TOTAL
What we need is some method of breaking a relation
into parts, and then these parts into parts and so
on recursively until atomic parts are encountered. given
We will see two alternative methods of approaching SPLIT(set (...),subsetl (...),subset2 (...))
this. SINGLETON(set (...),element I(...))

A first method is the "choice" function of set define

theory. Given a set, it chooses an element and TOTAL(relatlon (...,number real....),sum real)
returns thus together with the reeldue (the set = SINGLETON (relation,element)*(element.number=6um)
less the chosen element). We also need a way of + NON SINGLETON(relation)+SPLIT(relation,subl,sub2)
stopping the recursion, and a function for testing "TO~AL(subl,suml)*TOTAL(sub2,sumi!)
for the null set is assumed. This is the l (suml+ sum2rsum)
counterpart of the car, cdr and null functions of + EMPTY(relation)*(sum=O)
LISP. A device like this has been used by
Hitchcock [HITC 74). where
NON-SINGLETON(re1 (...))= - SINGLETON(rel,elem)
Figure 11 gives an example. The choice function
applies to relations of arbitrary type. TOTAL is
defined recursively to sum the values on the We must be careful to distinguish recursive
column %umber" in the given relation. If the definitions, from equalities which define
relation is empty the sum is zero, otherwise for a properties of the relation. For example, a
non-empty relation an element is chosen and the relation could be defined as symmetric by the
"number" column of that element IS added to the equation
sum of the residue. R(a X,b X) = R(b X,a X) This is a higher order
relation, and fits into our theory, though the
treatment of such cases is outside the scope of
this paper.
FIGURE 11
The Choice Function and the definition of TOTAL
6.0 A SIMPLE gXAWPLE
given In this section a very simple example is chosen to
CHOICE(set ( . ..).element '(...),residue (...)) illustrate the language developed in this paper.
EMPTY(set (...)) The problem domain chosen is sclentiflc data
analysis commercial problems have been avoided
define because they typically involve update, and the
TOTAL(relation (...,number real,...),sum real) handling of time and update is outside the scope
= EMPTY(relatlon)*(sum = 0) of the study so far.
+(-RMPTY(relation))*CHOICE(relation,elem,res)
l TOTAL(res,sum~res)+(elem.number+sum~res=sum) A survey is being made pigs being sold at the
local meat market. It is required to find out the
Note we have used the notation VVelem.number" to average weight of carcases, and the average price
indicate the binding between the result of the per kilogram. These figures should be broken down
CHOICE relation and the addition relation by producer and by purchaser.
~~(elem.numbBF+sum~res=sum)".
An entity-relatlonshlp systems analysis [HOT 76,
CHEN 761 shows three entities
The second method is a "split" function which - PRODUCER
devides the set into two arbitrary disjoint sets - CARCASE
whxh are non-empty if that is possible. To stop - PURCHASERand one relationshlb
the recursion a method of testing for a singleton - SALES
is necessary. This approach 1s similar to as shown in Figure 13. In these the columns "id"
Williams' tree function-composer [WILL 82). are the surrogates of [HOT 76).
An example IS shown in Figure 12, where a second We want to produce the reports
definition of TOTAL is given. For empty relations - PRODUCER_RXPORT
the result IS zero (the long stop for empty - PURCHASE-REPORT
arguments to TOTAL). For singletons the sum is with columns
the value of the NURSER column. For other (name string, average-weight kilograms,
relations the result 1s the sum of the TOTALS for weight variance kilograms, total-weight kilograms,
the two subsets selected by the SPLIT relation. averag;-price sterling-per-kilogram)
Note that the SINGLETON relation has columns of

331
 relations required, and their use, are shown in
FIGURE 13 - Sales analysis of Pig Market Figure 13.

Note that further facllltles would be required to

Entities are control the format of the reports arranging
presentation sequence, layout, etc. Note also
PRODUCER(producer id,name string) that efficiency has been assumed to be left to the
CARCASE(carcase id,weight kilograms,grade grade) implementation, so that, for example, the use of
PURCHASBR(purchaser id,name:string) the functions TOTAL, TOTAL-SQUAREDand COUNTcould
be optimised to require only one traversal of the
Relationships are data.
SALES(producer id,carcase.id,purchaser id,
price*sterling,date date) 7.0 CONCLUSIONS
Utilities relations required are What I have done is develop a rapprochement
between Relational Algebras, Logic Programming,
TOTAL(relation (...,number real,...),total real) and Functional Programming.
= KMPTY(relation)*(sum=O)
+ (-EMPTY(relation))+CHOICE(relation,elem,residue) Kach of these has its own implementation
l TOTAL(residue,sum-residue) technology. Hopefully through this rapprochement
l (elem.number+sun~residue=total) these technologies will become integrated to lead
to really effective implementations of
TOTAL-SQUARED non-procedural languages manipulating large
(relation ( . . ..number.real....),total-sq*real) volumes of data.
= RMPTY(relation)*(total-sq=O)
+ (-EMPTY (relation))*CHOICE(relation,elem,residue) The correspondence between relational databases
*TOTAL-SQUARBD(residue,tsq-res) and logic has been known for a long time and led
*(elem.number+*2 + teeres = total-sq) to fruitful results [e.g. GM 80). The
correspondence of these two with functional
COUNT(relation (...).count integer) programming languages is the interesting one. The
= EMPTY (relation)*(count=O) seeds have been there in the database literature
+ (-EMPTY(relat~on))*CHOICg(relation,el,res) for some time particularly in the work of Buneman
l COUNT(~~~,C~~~)*(CI'W + 1 = count) [BF 79, BFN 821 and Shipman [SHIP 811, though
neither of the approaches allow general higher
order operations. The development of the
Definitions of Reports are correspondence with functional programming has
enriched relational algebras, and in particular
PRODUCER~RKPORT(producer_namestring, moved away from a lot of the constraints imposed
average-weight.kilograms, by first normal form.
weigh-variance kilograms,
total-weight kilograms, For logic programming the correspondence with a
average~ice.sterling~er-kilogram) higher-order relatlonal algebra may suggest a way
of moving logic programming into higher order
= PRODUCER_GROUP(producer_name,prods (weight,price)) logics, as desired by Kowalski [KOWA831.
l TOTAL(prods.(...,weight,...),total-weight)
l TOTAL(prods.(...,price,...),totalgrice) A recent paper by MacLennan [MACL 831 takes a
l TOTAL-SQUARED(~~~~~(...,weight,...),tot-wt-sqd) relational view of functional programming. His
*COUNT (prods (...),num) motivation is very different from mine, wishing to
l (average_pricentotalJrice/total~weight) advance functional programming through the less
*(average-weightitotal-weight/num) restrictive facilities offered by binary
l square_root(var_Bq,weight_variance) relations. The final facilities are,
'(var-sq = tot-wt-sqd - aver-e-weight**2)/(num-1) nevertheless, appealingly similar and his paper
makes an excellent complement to my discussions.
where
PRODUCERGROUP(producer name.string, What I have not entended to do is to develop yet
prods (weight kilograms,price sterling)) another database system. The notations developed
= PRODUCER(prod,producer-name)* here are very compact and potentially difficult to
l SALES(prod,carc,purch,price,date) use. At best they could serve as an abstract
*CARCASE(carc,weight,grade) syntax, with the concrete syntax containmng many
more operations to enable ease of use and,
PURCHASERREPORT(purchaser_nanre string,...) therefore, accurracy of use.
as f% PRODUCgF-REPORT
While elaboration of a concrete syntax on the
relational model may appear attractive with its
To produce these we need to gather together all tabular view of data, I believe the way forward
the sales of a particular producer or purchaser, will be through functional programmingusinga
and count these and sum these over carcase weight, functional view of data. This needs development.
price, and weight-squared, and from these compute Perhaps a dual view withln a single system could
the statistics required. The higher-order emerge.

332
One particular advantage of the relational view Prentice-Hall 1980.
was its neutrality on "dlrectlon@@. Relations can HHT 75 Hall P.A.V., Hitchcock P.J., and T&d
be used in any direction, functions engender a S.J.P. "An Algebra of Relations for
very strong direction from domaln to range which Machine Computationw. Second ACM
can help the user, but, perhaps, ln the end Symposium on Principles of Programming
conatraln him. In implementation, too, tbe Languages, Palo Alto, California, Jan.
neutrality of relations can be an advantage. 1975. Pages 225-232.
HITC 74 Hltchcock P. %ukiamental Operations on
The next step in this line of development of Relations" IBM UK Scientific Centre,
databases must be the incorporation of update and Report UKSC-0051 May 1974.
time. The usual approach of before and after HITC 76 Hltchcock P. "User Extensions to the
states inherent in most formal approaches to Peterlee Relational Test Vehicle", 2nd
computing [e.g. JONE 801 1s not judged adequate, VLDB Conference, Brussels 1976.
and something more along the life history approach HOT 76 Hall P.A.V., Cwlett J. and Todd S.J.P.
of Michael Jackson [JACK 831 is expected to be the "Relations and Entitiesw in Modelling in
fruitful approach. DataBase Management Systems, Editor GM.
NiJssen, IFIP/North Holland, 1976. Pages
201-220.
8.0 REFERENCES JACK 83 Jackson M.A. "System Developmentw
Prentice Hall 1983.
AB 84 Abitebout S. and Bldolt N., "Non Flrst JONE 80 Jones C.B. "Software Development. A
Normal Form Relations to Represent Rigorous Approach". Prentice Hall 1980.
Hierarchically Organised Data", Third ACM KOWA74 Kowalskl R.A. "Predicate logic as a
SIGACT-SIGMOD Symposium on Principles of wogr-iw language" in Information
Database Systems, April 1984. Processing 74, North Holland 1974. Pages
ABCE 76 Astrahan M.M., Blasgen M.W., Chamberlin 569-574.
D.D., Eswaren K.P., Gray J.N , Griffitha KOWA83 Kowalskl R.A. "Logic Programming" Invited
P.P., King W.F., Lorie R.A., McJones P.R., Paper for IFIP 83, to appear.
Mehl J.W., Putzolu G.R., Traiger I.L., LP 83 Lorie R., and Plouffe W. *'Complex Objects
Wade B.W., and Watson V. 'System R and Their Use in Design Transactions", in
Relational Approach to Database Engineering Applications, Database Week,
Management" ACM Transactions on Database ACM SIGMODAnnual Meeting, May 1983.
Systems, Vol. 1, no. 2, June 1976 page MACL 83 MacLeMan B.J. l'Overview of Relational
97-137. Programming" SIGPLAN Notices, Vol. 18 No.
BACK 78 Backus J.W. "Can programming be liberated 3 March 1983. Pages 36-45.
from the von Neumannstyle? A functzonal HCCR 80 McCracken D.D. ‘*A Guide to NOMAD for
style and its algebra of programs." CACM, Applications Development" Addison-Wesley
August 1978. 1980.
BF 79 Buneman O.P., Frankel R.E. "FQL - A SHIP 81 Shipman P.W. "The Functional Data Model
functional query language *I, In Proc. ACM and the Data Language DAPLFX" ACM
Sigmod, Int. Conf. Management of Data, Transactions on Database Systems, Vol. 6,
Boston May 30th - June 1, 1979, ACM, New No. 1, March 1981. Pages 140-173.
York 1979. Pages 52-57. SHTG 77 Shu N.C., House1 B.C., Taylor R.W., Ghosh
BFN 82 Buneman P., Frankel R.E., Nlkhil R. "An S.P., and Lum V.Y. "EXPRESS aData
Implementation Technique for Database Extraction, Processing, and REStructuring
Query Languages" ACM Trans. on Database Systems'* ACM Trans. on Database Systems,
Systems, Vol. 7 No 2 June 1982 pages Vo1.2, No.2 June 1977 Pages 136-171.
164-186. TODD 76 Todd S.J.P. "Peterlee Relation Test
CHEN 76 Chen P.P-S "The Entity-relationship model Vehicle a system overview" IBM Systems
Towards a unified view of data", ACM Trans Journal, Vol. 15, No.3 August 1976.
Database Systems. Vol. 1, No 1, March WILL 83 Williams J.H. "Note on the FP style of
1976, page 9-36. Functional Programmingw page 73-102 in DHT
CM 81 Clocksin W.F. and Melllsh C.S. 82.
**Programming in Prolog" Springer 1981.
CODD70 Codd E.F. "A Relational Model of Data for
Large Shared Data Banks" CACMVol. 13,
No.6, June 1970. Pages 377-387.
CODD72 Codd E.F. "Relational Completeness of
Data Base sublanguages*' In Data Base
Systems (Ed. R. Rustin) Prentice Hall,
1972. Pages 65-98.
DHT 82 Darlington J., Henderson P., Turner D.A.,
"Functional Programming and its
Application6 II Cambridge University Press,
1982.
GN 78 Gallaire H. and Minker J. "Logic and
Databases" Plenum Press 1978.
GRAD83 Gradwell D.J.L. llICL's Data Dictionary
System" In Database 83 Conference BCS
HEND 80 Henderson P. %lnctiona1 Programming,
Application and Implementation"

333