Databases: Hyperbolic Schema Example


In a talk, Margaret Wertheim proudly relates how a craft predominantly practiced by women solved the physical representation of Hyperbolic Geometry.  Click on the image to view a video of the talk.

This got me to thinking about the representation of Hyperbolic Schemas and Hyperbolic Data.

An example of a Hyperbolic Schema is as follows:

Take the name “John”.  “John” can be seen as an word element or as a composite of “J”, “o”, “h”, “n”.

The left side of the brain sees the element, the right brain sees the composite. This applies level after level.  Phrase element and composite of words.  Sentence element and composite of phrases.  Paragraph element and composite of sentences and so on.  The associative database can support both representations.  This give you very powerful editing capabilities at many levels of granularity as well as powerful searches and applications.

Our product does this using the Sentences Associational Database from Lazy Software.  A relational database cannot do this effectively or efficiently.


COA: Change Oriented Architecture


The problem of this decade is the information technology platform. We have to switch to scale-free networks and abandon tabular lattice networks. It isn’t SOA that we need, it’s Change Oriented Architecture (COA).

I highly recommend rejecting Larry Ellison’s Oracle Relational Database and Sun’s MySQL and adopting Simon Williams’ Sentences Associational Database at which provides a schema and interface you can completely change on the fly.  No data loss, no null values, no normalization.  The lazy developer is the efficient developer.

When the Board of Directors says “Change!” the CIO can say “Immediately!”

And have you ever heard of “Hyperbolic Data”?  Sentences can do it easily and dynamically.  Click on the image to learn more:


Danger or Pluralarity?

Thinking about pluralities I was motivated to dig out and dust off my copy of Nicholas G. Carr’s book, Does IT Matter?: Information Technology and the Corrosion of Competitive Advantage. In this piece of pulp Nicholas droned on about the commoditization of hardware and software and the end of the IT industry.

What Nicholas was witnessing in 2003 was the plurality of one generation of hardware and software. Everybody had an office suite and enterprise software suite.  And rightly, they were no longer providing a competitive advantage. What Nicholas was experiencing was a complete lack of imagination with regard to the opportunities the pluralarity presented: the next generation of innovation leading to the next singularity.

In hind sight it was funny how Nicholas shook everybody up, but I didn’t find myself looking for a new career, I found myself looking for innovation and in many respects we found it in Open Source and Web 2.0 Social Software.

I have also found that Relational Database technology is reaching plurality and its limitations are becoming more pronounced as application developers test its limits. It simply does not have the flexibility we need. I’ve seen the future in the Associative Model of Data and have found it fits the Zachman Framework better than current technologies. The need is growing and this architecture fits it.

What Nicholas and all of us should have still been reading was this book:

Peter is still the authority when it comes to experience based instruction.

SQL: Old Soldiers Never Die

Structured Query Language (SQL) has been a phenomenally useful language for the relational database era. But I see that era coming to a close.

One of the primary flaws is SQL allows for database Alters, Drops, Updates and Deletes. When diskspace was expensive this made perfect sense, but with the unlimited disk resources we have today a greater principle holds true: NO SCHEMA OR DATA SHOULD BE ALTERED, DROPPED, UPDATED OR DELETED.

A second flaw is the lack of interactive modification of the schema in real time. Changes still blow most applications all to hell.

A third flaw is supertype/subtype hierarchies. Such things should not be hard coded into a design.

That being the case SQL has four unnecessary statements just waiting to be abused. We need a better language. In fact, we need a better database architecture.

A new language would provide no means for updates or deletes. I created the first Releases of this language I called “Structured Thinking Language” (STL).

STL has the following commands:

  1. CREATE – affordance concept (creates entities)
  2. DIRECT – affordance context (relates entities)
  3. POSIT – affordance method (entity output)
  4. OBJECT – affordance pragma (entity input)
  5. NEGATE – affordance cosmos (entity security)
  6. INTUIT – affordance chronos (entity manipulation)

As you can see there are no means to delete data.

Each entity (noun) has only one “attribute” in the relational ERD sense and each entity value is unique.

Each relationship between entities is called an direction with a subject, verb and object.

What we are actually dealing with is a database that has data states. Data being no longer affected by Alters and Deletes are instead affected by change of state without physical alteration or deletion.

After looking at STL recently I realized I had created a command language for an existing database architecture: The Associative Model of Data by Simon Williams.

The Book on the Model and a free copy of the Enterprise Edition software is available here.

An old release of STL can be found here.

Say, “Hello World”, with the Associative Model

In the beginning was the priest. Writing materials were produced in limited quantities. Education was monopolized. Scription was a laborious task and difficult to correct with the materials used. Text made filing easy.  Thus you had the Flat database model.

Then came the scribe. Writing materials increased in availability. Education became institutionalized. Scription and transcription were performed by trained personnel who recorded the dictate of untrained personnel in an academic tongue.  Libraries made indexing easy.  Entire scriptoriums were dedicated to the process of document production. Thus you had the Hierarchical database model.

Then came the writer. Writing materials were mass produced. Education became publicized. Individuals wrote their own documents in their own tongue. The printing press guaranteed mass distribution.  Formatted printing made tabulation easy.  Thus you had the Relational database model.

Then came the layperson. Publishing became universally available via the internet.  Education became personalized.  Networks made linking easy.   Thus you had the Associative Model of Data conceived by Simon Williams.


Simon has developed an Associational Database Management System (ADBMS) called Sentences. It foregoes the use of tables and inferred relationships for the use of single attribute entities and explicit relationships. The schema is intrinsic to the database making the business rules immediately available to anyone who accesses it. Finally, it is internet ready with the capability to be distributed across servers. It is a simple, elegant concept well executed, however there are still some hurdles.

The main hurdle is acceptance. Simon has met strong resistance from relational model advocates. He currently has a website offering the Sentences Enterprise Edition for free to anyone who wants it without technical support, but I do not think that is the answer. I believe that the potential of the Associative Model of Data is not fully realized in the Sentences proprietary implementation. If Sentences is to become the industry standard database for the internet, Simon Williams will have to open up Sentences to global collaboration as an open source project. Only then will the Associative Model reach the tipping point that puts it ahead of the relational model as the database architecture of choice for the lay internet user.

Simon needs Java Programmers for development and support and Mathematicians to develop Associational Calculus.


Lazysoft – Home site of Sentences

I highly recommend going to and downloading the Sentences Personal and Enterprise Edition to get a feel for this new architecture.  Downloading and intalling the latest Java runtime environment and Sentences can be done in roughly ten minutes.  A populated sample database is ready for exploration.

Surrogate Key Best Practice

Surrogate keys (unintelligent keys) are an excellent way to preserve the referential integrity of your database and avoid the need for cascading updates of natural keys if they are changed. However, simply using surrogate key is not always enough.

One of the most common best practices for databases designed with surrogate keys is: Any independent table with a surrogate primary key should have a corresponding natural key with uniqueness enforced. When uniqueness is not enforced duplicate rows are possible and your referential integrity is lost.

For example, consider the table below:


In the student table the primary key is a surrogate key, but uniqueness is enforced stringently by protecting the full name of the student and his birthdate as a unique composite natural key.

Another context for protecting surrogate key referential integrity is by protecting the uniqueness of foreign key combinations where uniqueness would be enforced if the table were dependent. For example consider the tables below:


Note how the enrollment table has a surrogate primary key, however uniqueness is protected by the unique natural key index on the two foreign keys.

If you use surrogate keys and natural keys together when you design your database, you will avoid the pitfalls of duplicate rows in your data.