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.

-PatP

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.

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.

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!

-PatP

i was at U of T when those guys were doing their research

i think it was covered in one of my Comp Sci courses, cannot be sure without checking my notes, and i don't have my notes any more

heck, i remember thinking at the time that the relational model didn't have a chance commercially, compared to the hierarchical and network models

so i'm not ruling out the associative model

but i'm not holding my breath, either

I took the time to read the white paper and I can't see a data model anywhere.

Isn't this just a EAV schema?

i saw lotsa models -- see attached for one such

sorry, what's EAV?

Come on Rudy, that is not a data model!

That is a business model.

A data model is "A general theory of data which defines structural, integrityand manipulation features."

EAV - Entity Attribute Value.......

I am sure you have come across it....

In a table you would have three columns...Entity, Attribute, Value

Data would be something like..
Shoe, Colour, Red
Shoe, Size, 5

are you familiar with business rule models? i haven't seen one for years, but i remember a guy called Ron Ross who was a great proponent

and everything on that diagram i attached is data!

(i'm playing devil's advocate)

but no, i had never heard of EAV

No, I don't think I am familiar with them or maybe not the name.

I suppose the term data model has multiple meanings... The formerly one (that I quoted) and the informal one being a database schema/diagram or business model or logical model.

I am both surprised and jealous that you haven't heard of EVA.

EAV, not EVA -- you're typing too fast!!

(i have heard of Eva! )

anyhow, here's an example of what i mean about the association being "data"

project has employees
project is managed by an employee

if the "flavour" of the association didn't matter, there would be only one relationship

but even the relational model recognizes that there are two relationships between these entities

where do you store the "data" about which relationship is which? in different columns -- manifested, in actual tables, via separate and differently-named keys

I can see what you are saying...

There is no "data" which describes the relationship, only the implemetation of constraints and dependencies gives meaning to the schema.

The example you gave could be represented like this in a RDBMS.

Project (ProjectID, Manager)
Employee(EmployeeID)
ProjectEmployees(ProjectID, EmployeeID)

Even without the RI or the background business rules, I think it is pretty easy to infer those rules..

But that does give rise to the argument that "data" is required to describe the relationship only when the design is poor....

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:

‘Employee.Age.[NOT] Employable age’ PROHIBITED ALWAYS

(There’s a discussion of business rules in Chapter 11 of the book, link above.)

hmmm, the pdf i've got has only 160 pages

where'd i get that from? can i ditch it?