Describing a Database

The reason that databases are incorrectly designed has a lot to do with the Data Description Languages (DDLs). Data description in COBOL, SQL, and XML all omit some crucial elements.

A database description names and identifies collections of similar things and what it is that you want to know about them. Ontologically, for a thing to exist in a database, something about that thing must be explicitly stored; that is, at least one property of that thing must be stored in the database. It could be as simple as an arbitrarily assigned identifier. For example, each person in a collection of people might be assigned a unique identifying number. In Mealy's terms, an example would be: 'this person (object) has an identifier (attribute) with a (value) of 3097.' Databases consist of primary objects, the sets of objects that are the reason for the database's existence; temporal objects, the sets of data about the primary objects that change over time; the data domains, the sets of values (or the sets of other objects) that specific attributes of the primary and temporal objects are defined over; and views, the user-oriented objects that make the database accessible to the end users.

Taking the attribute date of birth (DOB) as an example, there are many questions that must be asked:

Must every person have a DOB?
May one person have more than one DOB?
May two people have the same DOB?
What is the largest number of DsOB a single person may have?

More generally, three simpler questions may be used to determine these characteristics:

What is the minimum number of properties with this attribute that a single object may have?
What is the maximum number of properties with this attribute that a single object may have?
Must the properties with this attribute be unique for every single object in the set?

Simply stating that the minimum number of properties with a specific attribute is 1 tells us that every person must have at least one property with that attribute. On the other hand if the minimum number of properties with a specific attribute is 0, then we know that properties with that attribute are not required. Similarly, the maximum number of properties with an attribute is needed. Clearly, the maximum number of properties must be at least as large as the minimum number of properties.

If the maximum number of properties is greater then the minimum number of properties then some ordering discipline needs to be specified.

Simply stating that properties with a specific attribute are unique, means that no two people may have the same value for a property with that attribute.

Lastly, the domain of the values needs to be declared. A domain may simply be a list of values, or it may be one or more sets of objects.

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.)