The name of Platoclast is not well known in academic circles. Geoffrey Platoclast, senior systems analyst of JCN (UK) Ltd, and one time Visiting Professor in Information Technology at the University of Stratford upon Avon, left no notes or other evidence of preparation of the lectures published here, except for the flip charts that he always brought and invariably left behind, and his introductory note to his students, below. The “slim briefing paper” (Lecture IV), or “Miscellaneous Revision Notes” (Lecture XXIX), although very effective indeed for a specific purpose, with which the reader will not be concerned, did not constitute a systematic or anywhere near complete account of the course.

Had it not been for the extended indisposition of Stratford’s usual Relational Database lecturer, these lectures would never have been given; and had it not been for the almost complete shorthand transcript of them taken by Ms Judith Genudomini BA, to whom the editor is much indebted, they would have been as ephemeral as any other spoken word. At the request of Professor Platoclast (below), editing of the text has been minimal. The editor has, however, taken the liberties of adding sub-headings within the lectures; and inserting a number of footnotes to indicate what seem to him to be Platoclast’s sources, to clarify some points that might otherwise be obscure, and to cross-refer from some passages to related lectures.

Though it was not at the time appreciated, Platoclast’s lecture course was thoroughly unsuitable for undergraduates. Nor, except ostensibly, was it directed at them. He was expounding his theories, probably, to his harshest critic: himself.

Apart from his openly confessed aim (to get his fees), along with the vanity that revelled in the title of “Professor” and the furtherance of a personal relationship, it is not easy when reading these lectures – any more than it was when listening to them – to determine exactly what Platoclast was hoping to achieve. But, on reflection, it was this: to correct a few very early mistakes in Relational Database Theory. In principle, this might have been done in a single, short text; perhaps no longer than EF Codd’s seminal paper [1]. But it is one thing to lay a foundation, or amend one newly laid; quite another to fix such deep problems when a huge structure has been built upon them.

Platoclast rejoiced at the University’s choice of the set text for the course, Date’s “splendid Introduction [2]”. He uses this (and other works by Date [3]) very much as a foil, to set off his own theory.

What Platoclast applauds in the Relational Theory are: normal records, a data language that is essentially the first order logic, and the data independence that comes from minimal structuring of the database; in a word, simplicity. What then are the mistakes that he tries to rectify? They are:

The constraint that collections of normal records (i.e. tables) can be queried, or manipulated, only if all the records in the collection have the same format (all the same columns); i.e. the constraint of Union Compatibility – embarrass­ingly, the very constraint that is used to justify the application of the term “Relational”.
 

The lack of a satisfactory interpretation of the theory, covering both records and the manipulations performed upon them, a problem severely exacerbated by the introduction of Nulls.
 

Following to some extent from the problem of interpretation, confusions in the notions of database integrity: domains and keys (he entirely rejects the notion of “primary key”).
 

Confusion between different levels of data, in particular the ambiguity of “base relation” between the notion of a “stored” record (a high-level physical concept) and that of a “kept”, or logically basic, record (a low-level logical concept).

What makes his exposition run long, apart from the need to fill thirty teaching hours, is that it is highly argumentative, mostly (though not exclusively) in the non-pejorative sense of that word. Platoclast’s approach is based on a number of principles drawn from Philosophical Logic (and unorthodox even there, especially in combi­nation). It is not necessary to discuss here whether these principles-the rejection of sets, infinities, and absolute identity-are correct in any metaphysical sense. The reader will judge for him- or herself whether they are methodologically correct. Do they result in a simple yet powerfully expressive theory (an “efficient” or “economical” theory [4])?

But Platoclast’s methodology comprises more than these principles. He wants to create a formal theory, but also to give a very clear interpretation of that theory: the formality, he feels, establishes what has been said; the interpretation, whether it is true. And yet he no more has the time for a full formalisation than he does for a complete data language design, so often he merely reaches a point where – secure in his interpretation – he judges that formalisation is possible. Whether that judgement is sound must be left to the reader, and to further research.

For the reader who wants a more extensive view of the lectures before plunging in, the main lines of Platoclast’s Argument are described below. But to understand the arguments and evidence he brings to bear on his major topics, especially that of tables with rows of different formats, it is necessary to follow the entire sweep of his lectures, for he returns to the same point time and again, but from different angles. The effect of this approach, when delivered three times a week for a term, was first to shock with the outrage of unorthodoxy, then to demand grudging acceptance that under certain circumstances the proposal might work, then to offer solutions to a number of important problems, and finally – by a strange twist – to appear so obvious that any alternative seemed perverse. Quite what its effect will be in cold print is difficult to tell; but the reader will discover.

In Lecture I Platoclast takes a rather traditional view of database records as forms containing fields. To get a definition of these ideas, he uses criteria of identity [5] (conditions under which one thing is the same form, or field, as another). He shows how fields and records (collections of fields) are essential in that they carry non-redundant information. Platoclast attempts to restrict this “essentiality [6]” to fields and records, eventually denying it to tables (relations). He shows that the normal records proposed by Codd are more constrained than is needed for a record simply to comprise its fields, the latter option allowing repeating fields, i.e. multiple fields of the same type within a record (but not repeating groups). He calls such records polynormal. In this first lecture, therefore, Platoclast has adumbrated several of his major themes:

Criteria of Identity, or relative identities [7] (eventually he will argue that absolute identity, “is the same as” without any mention of “the same what”, is a chimera).
 

Simplicity [8], or keeping to a minimum of essential constructs.
 

The essentiality of fields (atomic records) and records (comprising just their fields), and the inessentiality of relations or tables. This inessentiality appears first as a proposal of “non-rectangular” tables, or tables with rows of different formats, in contrast to relations, whose rows have a uniform format.
 

The option of polynormal records (records with repeating fields), which he plays with intermittently, but eventually seems to admit only transiently in accumulations (column functions). However, a brief discussion in the final lecture seems to indicate a late change of mind in this respect.

In Lecture II Platoclast introduces the First Order Predicate Logic, or Calculus (FOPC), and uses it as the foundation of a formal theory of data, the Theory of Two-Dimensional Data (TT-DD), “two-dimensional” because the “dimensions” of type (format) and value define and identify a field. He shows in this and subsequent lectures that many of the concepts used in Relational Theory can be formally captured using a small number of primitive (given, formally undefined) notions: overlapping [9] of records (sharing a common field), normality (first normal form), a similar concept that he calls value-normality, and the concept of a record being kept (logically basic, or – very roughly – stored).

Lecture III brings Platoclast to a subject that he wrestles with obsessively throughout much of the course: interpretation. He introduces the Classical interpretation, in which a record is construed as a proposition in the language of the FOPC. The record type (or format) constitutes a predicate, and its values constitute names to which the predicate is applied.

He also launches his sustained attack on set theory [10] and its concepts. The objective of this is to show that the use of set-language falls under one of the following classifications:

A mere façon de parler, a perhaps convenient way to say what could be said without set-language.
 

An inessential (redundant, useless) addition to what could be said otherwise.
 

To put it bluntly (he does): falsehood, complexity, confusion, and incomprehensibility.

Lecture IV falls into two parts. In the first Platoclast extends the TT-DD to a point where he can launch his first attack on the essentiality of tables. In the second he returns to the problem of interpretation, considering data manipulation operations: joins, restrictions, and projections (still within the Classical interpretation).

He regards this question as central to a sound theory of data:

Given the interpretations of data structures, specifically records, and given some operations on those records, what are the rules that determine the interpretations of the records resulting from those operations?

In Lecture V Platoclast expounds the constraints on predicates and names that the FOPC demands. He concludes that the Classical interpretation can be saved only by restricting it to what he calls self-interpretation: interpretation of records in terms of the values in those records, in contrast to interpretation in terms of “the wider world”. He expounds the problem of the Join Trap, and shows that it arises because the FOPC constraints have been breached, which implies that a different interpretation is needed.

Platoclast regards the traditional “Entity” interpretation (and accordingly the Entity/ Relationship theory) as hopelessly confused. So Lecture VI and Lecture VII are devoted to his main attack on that interpretation. In the former he exposes confusions in the idea of entity, and argues for relative against absolute identity. In the latter he shows how relative identities are used in naming and counting, and he delivers his attack on set theory, which, together with absolute identity, underpins the Entity interpretation.

Lecture VIII finds Platoclast in constructive mood. He proposes his new, Existential, interpretation of records, and of joins, restrictions, and projections. The major innovation is that values are construed not as proper names (as in the Classical interpretation) but as common names, which are intimately connected to a criterion of identity associated with the column in which they appear (their column criterion). Such a criterion, for a RELIGION column, might be “has the same faith as”, so that rows pertaining to two persons, and with a common RELIGION value, would be interpreted as pertaining to two persons having the same faith.

He briefly mentions, and shows how he would handle, a value in a column that failed to meet the column criterion (like “other”). This will turn out to be, in Platoclast’s definition, a null value. But before he gets to his solution of the problem of nulls, he devotes two more lectures to preparing his attack.

Lecture IX sees Platoclast in a final skirmish with the use of sets (as “types” or “kinds”) in interpretation. He then rejects the idea of tables as sets of records, treating a table as a redundant (inessential) way of connecting a “table name” (a record type name, such as “EMPLOYEE”), to each of its records. He shows how to make such a connection without introducing tables essentially.

There then emerge two levels of logical record. He calls them the form and concept level. Form level records are merely records; concept level records (which bear record type names) are the propositions (about “the wider world”) derivable from them. In effect, the record type name (roughly, table name) is the name of a view of some form level records whose record identifiers have been projected away.

The motivation behind this unusual move is quite complex. Firstly, Platoclast thinks that a number of problems in database theory can be solved only by identifying very precisely the “level” at which they arise. Secondly, he wants to handle together records of different format, but without admitting as essential the rather complex tables that contain these records. He believes that such tables are, under a fairly transparent disguise (null padding), what result from such operations as Outer Joins. Consequently he wants to deal with this sort of table in his own way before he overtly tackles nulls and their problems.

Lecture X begins with what seems a brief digression on definite (typed) and indefinite quantification (“For some person, x, ...” in contrast to “For some x, x is a person and ...”) This leads to the introduction of some quantifying operators (“]” and “[”) which are used to apply scalar (single value) restriction conditions (such as “=” or “<”) to possibly empty collections of values in a column, as would be found in polynormal records. A limited application of these operators is then discussed, pertaining to the case where a column might have zero or one but not multiple values (i.e. to a column of a table not present in a row of that table, as must occur if rows are not of uniform format).

Platoclast turns to the problem of nulls in Lecture XI. Firstly, he addresses the sort of “null” that arises from the use of tables of non-uniform format. He shows how joins, projections, and restrictions of records with these absent values can be handled, employing the “]” and “[” operators for the restriction conditions. Secondly, he discusses the sort of null value that arises, he claims, only at the concept level, and which he defines as an improper value, a value in a column that does not meet the column criterion. Again, the mechanism for handling such values in restriction conditions has already been developed.

The main part of this discussion is a demonstration of how other approaches to nulls are ill-defined, confused, wrong, or unpromising (or have some combination of those defects). The principal point of the argument, which is continued into Lecture XII, is that his definition is not only lucid and practically applicable but also pertains precisely to those values that give the problems that nulls give (essentially, problems with joins). Other theories, he shows, involve concepts orthogonal to his, which means that some of their nulls do not give rise to the characteristic problems, and some of their non-nulls do.

Platoclast now shows that the rule of Entity Integrity is a mistake and a confusion, that the rule of Referential Integrity is trivially true (so does not need to be applied), and that the concept of domain is ambiguous. The ambiguity of “domain” explains why some theorists (especially Codd) deny that nulls are values, and therefore propose “marks” and extra truth values.

To handle multiple kinds of null values within a column, Platoclast proposes the use of an associated modality column, in which can be recorded a comment on the original column value, whether null or not. I.e. his notion of “modality” is orthogonal to that of nullity.

The first part of Lecture XIII revisits data manipulations, and shows how all so far discussed can be interpreted in terms of conjunction (ANDing) when the new existential interpretation is used. Then the various kinds of data manipulation language (DML) are discussed: the Domain and Tuple Calculus and the Algebra. SQL is introduced as an example of a Tuple Calculus. Platoclast obviously likes two features of SQL: its use of Cartesian product with explicit statement of join conditions (rather than natural join with its implicit equalities), and what he sees as an ideal scheme for defining queries, by stating, in this order: the tables to be queried; extensions and restrictions; and projection.

At the end of this lecture Platoclast raises, and in Lecture XIV he tackles, the problems of the union operator. He shows how union is sometimes needed to build tables with records of different formats. The point of attack he chooses is the demand of relational theorists for Outer Joins, which amounts to an admission that tables with non-uniform rows are needed; but he demonstrates a number of problems with outer joins.

The first step in the solution to the problein of outer joins, which avoids nulls and gains formal tractability, is the proposal of Conjoins (a Left Conjoin, for instance, being the union of one table with the natural join of that table and another). But conjoins, like outer joins, can suffer the problem of information loss. This is solved by an “outer” analogue of Cartesian product, termed Combination (the combination of two tables being the union of both of them with their Cartesian product).

In Lecture XV Platoclast shows that his new combination operation, “the great conjunction operation”, can be taken as primitive and used to define other sorts of join and also Union. (He remarks of union that it is “quite clearly a conjunction”). To define a Relational Union (a compatible union) he resorts to extension, using “OR”, somewhat unconventionally, as an extension operator.

He then turns to another sort of extension, involving accumulation functions (in SQL termed “column” functions: COUNT, MAX, SUM, and so on). To accommodate these he introduces, with apparent reluctance, a Collection operator to gather together values to be accumulated. It is from this point that a number of important arguments start:

The need for at least transient polynormality is established (and with this he is content; he settles for normal records alone in the database).
 

The FOPC operation of existential quantification is to be excluded from the DML proper; likewise negation (and the Difference operation). This leaves a DML founded on a mere part of the FOPC, using only conjunction.
 

The distinction between “Open” and “Closed” interpretations of databases (in the closed interpretation, roughly, whatever is not asserted is denied) is to be dismissed.
 

The new collection operation will turn out to be schematically definable on combination, in the sense that each use of it can be so defined, but there is no general definition. Such schematic definition is later to be exploited to solve the Bill-of-Materials problem.

Platoclast apparently turns aside from his argument in Lecture XVI, and discusses encapsulation of data types. (He is, amongst other things, preparing his attack on negation and the Difference operation.) He envisages each value in a record represented by a token, which, when a function is requested on it, is passed by the DML to a token handler, and onward to function handlers. This severely limits, and therefore simplifies, the DML itself (which is what he has been searching for all along).

A number of topics, previously postponed, are now tackled: how to handle absent and null values in expressions, how to specify accumulations outside the DML proper (as encapsulated functions), and eventually, in Lecture XVII, how to process modalities (encapsulated with their associated values).

He starts that lecture by discussing the handling of values comprising a numeric part and a unit of measure, and introduces some new relative identities on column values. He shows that handling modalities is a similar problem, with a similar solution.

Then he turns once again to the collection operation and shows how any use of it can be interpreted in terms of natural join (and therefore of combination). And finally he turns to the question of negation, and shows how Difference can be defined using collection and an accumulation function.

Lecture XVIII is a recapitulation of the main points of the previous five lectures, with additional clarifications. It stresses the efficiency of the DML being proposed, and reviews the other facilities needed for a complete query system: presentation and report handlers, the field (token) handler, and the encapsulated functions. Towards the end, Platoclast gives his solution to the open/closed interpretation problem, which is to allow the user to introduce the closed database assumption where required.

In Lecture XIX he discusses data independence, in particular structure independence. He shows how both minimally structured data in the database and quite complexly structured data at program interfaces are needed. He complains that relational databases fail to provide the structured views needed by programs, and shows how his proposals (especially of non-uniform tables) allow both minimal database structure and – at least – hierarchical views for programs. The only mechanisms needed are the DML and sequencing.

He claims, in addition, that his approach could be exploited in a program generator with a fixed cycle like that of RPG, so avoiding the error-prone coding of complex program structures. As a parting shot he shows how dropping the constraint of uniform format would allow program outputs to be written back to the database for further examination and analysis, using the DML.

In Lecture XX the discussion of data and program structure is continued, and a batch program likened to a Tuple Calculus query. Platoclast shows how certain accumu­lations need a new operation, called Headline, which unions to a table the projection of some of its fields (those fields that-in a batch program-would control a level break). A special case of headlining involves the projection of no fields (analogous to batch program initialisation or termination). If this empty-headlining is done on all tables, combination and Cartesian product become the same operation.

The SQL “GROUP BY” clause is investigated, and turns out to be closely related to headlining. More deficiencies of uniform tables are demonstrated. Once more an attempt is made to approach the “ideal” query scheme, now involving automatic headlining (of each projection of each row) and incorporation of conditions in accumulation expressions (as is done in the QUEL data language).

This lecture finishes with, firstly, the brief introduction of a combined Headline and Extend operation (to avoid loss of data when an extension removes rows); and secondly, a scathing attack on the infelicities of relations (in contrast to non-uniform tables).

Lecture XXI sees Platoclast tackling the general question of Views, considering them both as schematic (typical rather than specific) queries, and as tables containing the data needed for such queries. He recommends his “ideal query scheme” as an approach to defining views. And he briefly touches on the problems of updating through views, and how record identifiers (at the form level) might be exploited to that end.

He then starts to question the popular method of relational database design based on higher normal forms (2nd and above), i.e. on projection and natural join. He argues that this method can be justified as applicable only at the physical level, and he distinguishes yet another level of records: the store (highest physical) level.

In Lecture XXII Platoclast tackles a number of database design problems. Firstly, he proposes the use of cryptic data types (“surrogates”), which enables him to separate as he argues is necessary) the questions of identification in its two senses: showing sameness and picking out. Then he shows how a densely ordered cryptic data type can solve the problem of inherently ordered data.

Secondly, he turns to a specific problem of recording non-overlapping time periods, and characteristically rejects any DML extension as a solution. Instead, he solves the problem by exploiting the differentiation he has made between “base” records: physi­cally stored (store level) records and logically basic, or kept (form or concept level) records.

Thirdly, he attacks the notorious Bill of Materials problem. He begins by giving two examples of the weakness of the FOPC: the impossibility of expressing “exactly as many” and the problem of the ancestral (defining “ancestor” in terms of “parent”), both of which he explains as an inability to formalise “and so on”. He gives a solution to the Bill of Materials problem, essentially the problem of the ancestral, once again based on the distinction between stored and kept records.

At the end of this lecture he raises, without answering, a further problem of ambiguity in the notion of “logically basic record”. Is such a record a postulate of the theory represented by the database? or a record formed from a primitive predicate? or is it both of these?

He offers two other solutions for the Bill of Materials problem in Lecture XXIII, the first using a rather complex definition formalised in the TT-DD, and the second exploiting schematic queries. Some schematic queries, while not complete queries, can be completed mechanically: the simplest example is a “SELECT *”, where the DBMS finds the appropriate columns to substitute for the “*”. By putting a similar, but greater, burden on the DBMS, Platoclast shows how queries using the previously introduced “collection” operator can be mechanically instantiated, and then demon­strates a similar approach for Bill of Material queries.

These solutions, based merely on the conjunctive part of the FOPC, yet going beyond the Relational Algebra or Calculus in power of expression, justify his claim that his theory is more efficient than Relational Theory. But he then shows that it is precisely this restriction to merely a part of the FOPC that allows the identification of postulates with propositions formed from primitive predicates, so that any kept record is logically basic in both senses. And this provides a firm theoretical foundation for the solution of the problems of updating through views.

Keys and Functional Determination are addressed in Lecture XXIV, which starts with a dismissal of the concept of Primary Key as both confused and intended to subserve too many conflicting ends. Platoclast gives a definition of “identifies” (or “keys”) that covers all functional determination (or minimal functional deter­mination), including even “accidental” or “coincidental” keys (e.g. persons’ names that just happen to be unique).

He argues that it is this sense of “key” that is needed for optimisation, and even for physical record design, not the sense of “candidate key”, where a candidate key is a collection of fields asserted to functionally determine other fields. He shows that, in that sense, “candidate key” cannot be formalised (in the FOPC or set theory).

The question of logical design using functional determination is then revisited, and it is shown how this approach, under the Classical Interpretation, gives rise to the Join Trap; and, under the Existential Interpretation, fails to convey some intended interpretations. The solution is to abandon the approach for logical design, while keeping it for physical design. Platoclast claims that almost all sources of functional determination – business rules, governmental laws and regulations, even our views of “reality” – are undependable and, even when correct now, likely to change. So they ought not to be used in logical design.

Lecture XXV and Lecture XXVI look at Integrity and Design, beginning with an investigation of Referential Integrity and deletion rules, and leading on to the definition of Existence Dependency and Simple Dependency. One record type, R, is existence dependent on another, Q, when for each rl, r2: rl is the same R as r2 only if rl and r2 are each associated with one and the same Q. Simple dependency demands merely that each R is associated with a Q.

Platoclast briefly touches on the non-normal records obtained when a record is combined with the records that are existence dependent on it, arguing that such complex objects should be kept as a number of normal records (usually of different formats). He also considers the specification of integrity constraints on views.

He investigates the connections between dependency and functional determination, particularly what he would regard as “safe” functional determination, founded on logic. These rather sketchy and tentative investigations bring him back to something rather close to Entity/Relationship Theory (to his annoyance).

A four-level data design is proposed, essentially comprising Business Data Analysis (Data Mapping), Conceptual Database Design, Forms Design, and (top level) Physical Database Design. The complexities of this approach are discussed, with particular reference to part/whole relationships.

Platoclast returns to the question of Functional Determination, and discusses the problem of informing the user when the result of a query is largely determined by business rules, or even by logical truths. He concludes that to solve this problem would need a modal logic that is not currently available. However, he proposes to “leave a little space” for the added complexity by using merely a part of the FOPC as his DML (a decision already taken for quite other purposes). He finishes this work on design by briefly discussing a umber of miscellaneous problems.

In Lecture XXVII Platoclast discusses first normal form. In view of his restricting essential structure to normal records alone, the importance of normality to his theory will be appreciated. He shows that whatever constraints are placed on allowable data structures (and therefore on complexity), there is always a temptation go beyond them. And he proposes going no further than is necessary, i.e. to normal records.

He discusses a number of ways in which one might attempt to escape the constraint of normality, and argues against each of them. He discusses the proposal of non-normal (or nested) relations, and rejects it; though he shows how tables of non-uniform format can be formatted to look as if they were nested relations.

For unavoidable reasons, Lecture XXVIII could not be given. Platoclast substituted an “Informal Symposium”: a question and answer session with a few of his students.

Lecture XXIX comprises a summary of the proposals made during the course, and an evaluation of them using a checklist in one of Date’s published papers. In Lecture XXX Platoclast lists what he regards as the main challenges to Relational Theory (which he believes it cannot meet); discusses the open problems of his own theory and proposes some research; and finally produces an interesting argument for accepting polynormal records.

The editor has included a number of brief expositions that arose from questions put after some of the lectures or on other occasions, not always easy to identify: Platoclast was perfectly capable of delivering an impromptu lecture under almost any circumstances. Apart from the topics already mentioned, these pertain to adjustments to the theory needed for Planning (“What If”) Databases, Object Orientation, and Duplicate Rows.

Douglas J Druckeberger III, BSc

(The autograph record, whose textual content is given below, is written on a postcard, marked merely “ Rome”, and in the possession of the editor’s solicitors.)

Got them all down in Pitman’s [11], did she? OK if you can find anyone fool enough to publish them. I did them for the money (on that topic, 80/20 seems a fairer split). Don’t water them down to pacify the relational and set-theoretical bigots. Print them like how I said them. No-one will read them anyway.

G.P.

COURSE: ITRDB, Relational Database

To do this optional course, you will need to read the set text, by Mr CJ Date, and come to the thrice-weekly lectures by me, Professor G Platoclast; both. I’m not going over what Mr Date says, except in the sense of walking over it with big boots.

And take notes, because all mine are scrawled on punch cards, and I’m not handing them out. (Punch cards are like gold dust nowadays.) Optionally, you can do homework assignments, if I remember to set them. There’s an exam at the end, but I’m sure you’ll manage that all right.