I’ve proposed an entirely new database architecture which subscribers might find interesting. It’s called the associative model of data. You can find out more at www.lazysoft.com, where there's a PDF of my book.
Instead of using a separate, unique table for every different type of data, the associative model uses a single, generic physical data structure to contain all types of data. The metadata that defines the logical structure of the data and the rules that govern it is stored alongside the data in the database.
This sets the scene for a new style of programming, whereby the data structures and rules are no longer hard-coded into the programs, but are obtained by the programs from the database itself. Thus, for the first time, such programs are truly reusable, and no longer need to be amended when the data structures change. This dramatically reduces the cost of application development and maintenance.
From a data modelling perspective, the associative model is a closer fit to the structure of information in the real world. It removes the need for normalisation - by which the true structure of information is modified to fit into a set of relations - and for keys.
In 1970, Ted Codd introduced the relational model with the words “Future users of large data banks must be protected from having to know how the data is organized in the machine”. The aim of the relational model was to free programmers from having to know the physical structure of data. The aim of the associative model is to free them in addition from having to know its logical structure.
The associative model was new when MUMPS was introduced. The associative model had pretty much come and gone as a database technology by the end of the 1970s.
The associative model still exists in concept, and the same kind of thinking is actively used in the Windoze registry. I just haven't seen it used for a database outside of research projects in a couple of hospitals for a long time.
OK Pat, I’m always keen to learn – would you please point me towards references to the associative model of data which pre-date my book?
I’d like to do some research and hopefully argue a case that any similarities which you perceive between the associative model that I’ve described and MUMPS or the Windows registry do not automatically rule it out of sensible discussion.
There was a flurry of interest in the Associative Database Model in the late 1970s. There was some discussion of it in books at the time, and lots of activity in ACM publications. Check out Yao, Ozkarahan, and others.
I know that there were papers that predated them, as well as a chapter in the original Sahani book, but I don't know if that chapter survived to the present edition.
At one time, Jeff Ullman did a very funny, rather scathing analysis of the aftermath of an attempt to build a "real world" application using an associative database. Unfortunately, I can't find any reference to that online, but it is probably worth looking for when I get some free time because it is hysterical!
There is nothing wrong with the Associative Model. It does some really great things. The problem is that todays hardware just can't make it practical... Either you can't afford enough hardware, or you can't get an answer while you are still young enough to care (or maybe even remember the question)! There will probably come a time when it will be a great thing, and that may be in my lifetime, but I'm not willing to bet on that yet!
Originally posted by andrewst
I have seen your Associative Model discussed before, and have visited your website in the past. There have always been unanswered questions in my mind that maybe you could address here:
1) Does your model have an equivalent to a foreign key constraint, e.g. that if an Employee is assigned to a Department then the Department code used must be a valid Department?
2) Does it have the equivalent of a constraint like "Employee's hire date must be at least 16 years after Employee's date of birth".
There were probably other questions I can't think of right now, but those are the big ones.
1) Yes. Briefly, associations are created as instances of association types, such as ‘Employee, assigned to, Department’. The DBMS ensures that only existing instances of the type ‘Department’ are eligible as targets for new and changed instances of that association type.
(You’ve chosen an interesting feature. One can argue that the relational model’s referential integrity mechanism, which you describe, is a fragile way to ensure the integrity of data. If you’re interested there’s a brief discussion under “Relationships and Identity” on page 234 of my book at www.lazysoft.com/docs/other_docs/AMD.pdf.)
2) Yes, in one of several ways:
A. Declaratively, via a subset constraint: The association type might be defined as ‘Employee, hired on, Hire date’ where the type ‘Hire date’ is a subset of the type ‘Date’, whose members are determined by a query which uses the target of ‘Employee, birth date, Date’ as a parameter.
B. Procedurally, via a trigger that invokes a stored procedure to validate all new and changed instances of the ‘Employee, hired on, Date’ association type.
C. Ideally, via a business rule: The type ‘Employee’ might have a state domain of ‘Age’ whose states might be ‘Too young’, ‘Employable age’ and ‘Too old’. Like subsets, states are defined by reference to queries which may use attributes as parameters. The state rule for your constraint might be: