17 The First Great Blunder

According to Date and Darwen, the first great blunder is the relvar = class equation: treating a relation variable as the counterpart of an object class, and treating each tuple in its current value as an object instance. This mistake, they argue, leads directly to a host of conceptual and practical problems:

• hidden object identity
• pointer-based semantics
• update anomalies
• confusion between value and identity
• non-logical equality
• mixing logical and physical models
• OO-style thinking infecting the relational model

This is why they attack systems that treat tuples as mutable objects:

• OIDs
• object databases
• ORMs
• SQL’s row identifiers
• any model in which a tuple has hidden identity or reference semantics

The essence of the blunder is confusing the logical notion of a relation with the object-oriented notion of a class. In the relational model, tuples are values, not objects; they have no identity beyond their value. In OO, objects have identity independent of their state. Conflating these two worlds leads to the pathologies Date and Darwen warn against.

Does Predica commit the first great blunder?

At its most literal, the equation relvar = class is already a category error: a relvar is a variable, whereas a class is a type. Predica does not make that identification. Indeed, Predica has no independently declared relvars. It has types and attributes, while a database is a variable whose declared type is an entity type.

Predica allows entity (and relationship) types in semantic modelling to be genuine types in the type system. For example:

entity Supplier
{
    Integer id;
    String name;
    Integer status;
    String city;
    key {id};
}

In An Introduction to Database Systems, 8th edition, Chapter 14, C. J. Date says:

... the entity type concept as used in (e.g.) the E/R model is not at all the same thing as the type concept discussed in Chapter 5. To be more specific, such entity types will probably map to relvars in a relational design, so they certainly do not correspond to relational attribute types (domains).

Predica deliberately rejects that boundary. Supplier is simultaneously:

• a semantic-modelling entity type; and
• a genuine type in Predica’s type system.

As a genuine type in the type system, Supplier is expected to occur as an attribute type:

entity ShipmentsSystem
{
    Supplier supplier*;
    Part part*;
    Shipment shipment*;
}

This is not committing the first great blunder, i.e. the category error.

Let db be a database variable of type ShipmentsSystem:

// Database variable of type ShipmentsSystem
var db = openDatabase<ShipmentsSystem>("/path/to/database/on/file/system");

The attribute name supplier, when applied to db, gives the pseudovariable db.supplier. This pseudovariable is a location whose current value is the extension of the supplier predicate and can therefore correspond to a relvar:

// db.supplier is a pseudovariable recording extensions of type Supplier
assert( db.supplier isa Supplier );
print(db.supplier);

But Supplier is the type used in the declaration of that attribute; it is neither the attribute supplier nor the pseudovariable db.supplier. Predica therefore does not make the relvar = class identification.

Predica distinguishes between attributes, value types and entity types. The identifiers appearing in these examples can be partitioned into those three groups as follows:

• attributes: id, name, status, city, supplier, part, shipment. These are unary predicates. They have extensions, and in this respect correspond to relvars, understood as predicate names.
• value types: Integer, String.
• entity types: Supplier, Part, Shipment, ShipmentsSystem. These are kinds of domains. They have domain definitions, not predicate definitions.

Going back to C. J. Date’s quotation above, there remains a substantive difference from Date’s conception, and this highlights a distinction between Predica and the standard and expected application of the Relational Model.

Allowing semantic entity types to be genuine types is a major advantage of Predica. It lets a Predica schema directly perform the semantic modelling that a schema is supposed to perform. Supplier remains the type of supplier entities throughout the model, rather than being translated into a relvar whose tuples stand for suppliers.