I’ve proposed a 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. There a PDF of my book at www.lazysoft.com/docs/other_docs/AMD.pdf.

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.

When I wrote my book, I decided to set the associative model in the context of relational model's perceived shortcomings because of the latter’s ubiquity and universal acceptance, just as the merits of alternatives to the internal combustion engine have to be argued in terms of its shortcomings.

However, as a consequence of my decision, attempts to discuss the associative model often end up as defences of the relational model, which is what has already happened in the previous topic that I opened.

This new topic is intended for people who are interested in the associative model for its own sake. Please don’t use it to discuss why you think the relational model is superior to the associative model.

You can use the previous “Associative Model of Data” topic for that purpose. I’ll do my best to keep up with both. Apologies to people who have posted non-relational issues in the previous topic.

The fact that the relational model has stood the test of time so well is a testament to its strength and mathematical rigour: however, that doesn’t mean it’s disrespectful to discuss its shortcomings and possible alternatives.

I'm very much with you on that.

Can you give me some idea of how you see that things have changed since the fiasco's (circa 1980) for the Associative Model? I think that the fundamental problems remain unsolved, especially the ones that have to do with the fundamental mis-match between row oriented programming languages (like VB, VC, etc) and the underlying structure (or lack thereof) in an associative model.

If you look at the paper from Purdue or the one from Toronto from the 1970s that I cited previously, they both showed a lot of enthusiasm. After the attempt to re-implement ERIC using an associative store failed so badly, I can't remember seeing much if anything published on the associative model. Why the huge disconnect in only three years time? Why hasn't anyone seriously attempted to revive the associative model since then?

-PatP

So the rules of this thread are that we are allowed to talk about shortcomings of the relational model, but not the advantages?

You spelled "normalization" incorrectly in your book. Perhaps there are alternate spellings - I just typed your spelling into MS Word and it didn't like it.

Perhaps it is in the book, but how would you enforce "referential integrity" in the associative model?

Thanks.

There are 2 threads going with similar titles. The other one (without the "fresh start" suffix) is debating the pros and cons of the relational model.

"Normalisation" is the correct UK English spelling

Ok, Thanks!!!!

I think two reasons. Firstly, market opportunity. Ever since Cullinet became the first software company to be listed on the NYSE, database management has been big business. This has meant that research funding – corporate, academic and VC - has been concentrated in two places: the incumbent and whatever the market decides is the likeliest challenger. In the early 80s, Cullinet’s IDMS was the incumbent and relational was the challenger. Cullinet was out-marketed by Oracle, and its failure set the seal on the relational model’s commercial dominance. In the 90s, relational was the incumbent and OODB was the challenger, driven by the market’s often irrational enthusiasm for all things object-oriented. OODB failed, but Y2K and dotcom meant that the market didn't care. So today there is no challenger on the horizon, and hence, perhaps, the opportunity.

Secondly, granular architectures such as the associative model are undeniably less efficient in pure performance terms than record or row-based architectures such as relational, network and hierarchical. (Although the margin is not as great as might be supposed – see my analysis on page 219.) I suspect that 25 years ago there really wasn't enough hardware power to drive a granular database to acceptable levels of performance. But now I believe that has changed, though I accept that you disagree.

Fundamental problems remain unsolved because of the lack of research focus and funding that I describe above. However, at least we made a start by developing an ADBMS with a level of concurrency which has been successfully implemented on a commercial basis.

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.

Associations are bi-directional. If we choose any item in the database, we can immediately see both its outward and its inward associations. So the DBMS can easily prevent any item that is the target of one or more associations from being deleted. Eg. the existence of an association 'Mary Stewart, assigned to, R&D' would inhibit the deletion of Department 'R&D'.

I think any connection between Simon's Associative Model and any previous model of that name is coincidental - i.e. Simon is proposing a new model that he has named the Associative Model, rather than revisiting an old model that happened to have the same name. Is that correct, Simon?

Before anyone else points it out, I already know that the part of my book on concurrency is entirely inadequate: it needs a full discussion of associative locking mechanisms. I've worked through many of the issues but they've yet to be formalised or incorporated.

(I'm neither an academic nor an author, and I'd like to find a co-author to help take the book forwards: is anyone who's suitably qualified interested?)

Yes, that's correct. I had searched (inadequately, it appears) for earlier references but had found none (except to associative memory, which is a different area entirely). The book acknowledges its debt and cites references to binary relational, triple store, entity relationship and other prior work wherever I could find it.

I'm going to try to locate the references that Pat mentions, but meanwhile I answered his question presuming that the earlier work had elements in common with mine. For now, he will be a better judge of that than me.

I haven't made the time to really investigate Simon's book in any detail. I'd like to do that, but I'm currently "under the gun" for a development project where we marginally overcommited (based on available staff), then lost almost 25% of our staff!!! Although I can spare a few minutes now and then to answer questions, I really can't devote the hours needed to pursue major personal project between now and the first of August.

It would appear that Simon has actually moved a step past what I call the Associative Model, moving toward the Predicate Model. If that is the case, it is an amazing feat of scholarship!

There have been at least two efforts to get a comercially viable, predicate based database to market in the last two years. Both have failed due to performance failures, although the effort that ended last year in California made it a lot closer than the one that ended in 2002 in Ireland did. As Rudy may remember, this Predicate model is something that I've been quite excited about for a long time, so I was very disappointed with the failures.

I'll be very interested to see where this discussion goes, but at the moment I can't really contribute much "new" material to it.

-PatP

Hello,

How is that implemented? In other words, if you create a database with rules, how do I as a human read the rules you enforced?

Thanks in advance,

I'm not 100% sure what you're asking - hopefully I'm answering the right question.

You make the rule as a designer when you assert in the schema that things of type Employee have an 'assigned to' attribute whose target must be a thing of type Department. At the same time you get to specify the cardinality rules for the association type: whether it's optional or mandatory, singular or multiple, and whether one Department may be the target of more than one, or only one, such association.

Apart from the cardinality aspects, it's no different to saying in a relational schema that an Employee table has a foreign key whose values must be drawn from the primary keys of a table called Department.

I think that he's looking for the declarative syntax. How can he see what declarations have been made, in other words what constraints apply to given attributes.

-PatP