Terminology

In 1967 George Mealy lamented that we had no common terminology for discussing data. Fortunately, the Computer History Museum provides a copy of his paper, Another look at data, here. Quoting from Mealy:

...we speak of some set of things, attributes of those things and values of attributes. Attributes are the same as relations, being a correspondence between the things and the values (which may also be things)...

...The notion of attribute should be distinguished from that of property. To say that something has a given property is to say that some attribute of that something has a certain value. Thus, when I say that a house is red, I mean that the value of its color attribute is red, not that I intend to identify the house with the universal concept of redness. Properties may be combined using the usual logical connectives to form new properties, unlike values. Thus, the tall, red house has a property not shared by the long, red house, except by accident. Its color attribute has the value red and its height attribute has the value tall.

Bill Anderson of the University of Texas has summarized and diagrammed Mealy's theories here. In the absence of anything more cogent I find Mealy's proposed terminology eminently useable and have used it since his paper appeared. Unfortunately, few people writing about databases use as well-defined a set of terms. His appeal for the need for Representation Independence goes completely unheeded by both database software and language developers. I urge all readers of this blog to download and read Another Look at Data.

Value-based and object-based properties

Properties having the same attribute should take their values from a very specific domain. There are two types of properties: those whose value-domain is simply a set of values represented by a specific data-type found in the computing environment – strings, integers, floating-point numbers, etc.; and those whose value-domain is the identifiers of a specific set of objects in the computing environment. I'll refer to these as value-based and object-based properties, respectively.

Every attribute must specify whether its properties are value-based or object-based and exactly which domain they take their 'values' from. For example, an attribute of a car might be its wheelbase and the corresponding value-based property might be (wheelbase, 162 inches). That same car might have an object-based property whose attribute is owned-by and the corresponding property might be (owned-by, person #3564) where person #3564 is an object in the database. The object-based property implies the existence of a reciprocal property in the set of people – with an attribute owns-car. Only one of the two properties, owned-by and owns-car, requires explicit representation in the database; the other can be derived easily from the index of the one that is stored.

Associative database access

Feldman and Rovner designed and implemented An ALGOL-based Associative Language (1968). They called it LEAP. They wanted to have an associative memory that would make it possible to -

...access data through a partial specification of its contents,...

Their associations all consisted of triples (and were implemented using a hash coding technique):

attribute of object is value

In essence this is very similar to what Mealy described:

object has property (attribute, value)

Wither databases?

In my paper Sets as a Model for Database Representation: Much Ado about Something, which I was invited to present at ACM Pacific 1975, I employed essentially the same structure. I proposed that two representations of a database be kept; one that stored every object that had a particular property (attribute, value —› object), and the other which stored every property for each object (object —› attribute, value). The utility of this representation isn't immediately evident: firstly, there are two complete representations of the database, each of which may simply be recreated from the other; secondly, each representation serves a different purpose, the mappings from properties to objects facilitate access to the contents of the database, and the mappings from objects to properties allow all of the properties of an object to be rapidly retrieved.

NoSQL databases try to achieve something similar but do not have - Atomicity, Consistency, Isolation, and Durability – they don't pass the ACID test! (In 1984 my company, symphysis incorporated, implemented an object-oriented, multi-processor-based, distributed database management system, for a Minneapolis-based company. It worked exceedingly well. Unfortunately the client decided to move to a different hardware platform. They decided to use the database management system provided by their new hardware supplier, rather than have us implement our system for the new hardware.)