Actor: Database Modelers automate weakness and agony.
Proactor: Database Designers automate power and pleasure.
Reactor: DBAs automatically complain.
You may be wondering about the title of this post. I’ve decided to reject John Zachman, a non-businessman completely, and name my discovery to honor someone I respect much more highly, an archetypical businessman, Peter Drucker.
The first thing to do is abandon the term “hierarchy”. You are working with networks. You are also dealing with seven networks, not one. This means you are dealing with not seven by seven (49) but seven to the power of seven (over 800,000) nodes in the business space. This is called a seven dimensional hypercube. The main difference between the associative model and the relational model is that the associative (node-link) business area grows into the space while the relational (relation-inferred relationship) business area has to be completely defined. When you are talking about almost one million cells in the schema alone the traditional relational model with all of its NULL values for unused space in tables becomes quite cumbersome. The SQL is resource intensive in both models.
Another thing to abandon is your language. Lay English is often imprecise and inconsistent. I am creating a taxonomy as part of this work to provide a seven dimensional vocabulary. Every one of the terms was thoroughly examined for its definition.
Finally, abandon preconceptions. Look at the data and let it guide you.
There are key levels of abstraction: The schema which are entities and entity associations and instance and instance association. I highly recommend going to Simon William’s site lazysoft.com and reading some of his short white papers on the architecture.
Associations and Entities
A chart of associations is below:
Let’s look at these associations in the context of physics and business:
It is based on an associative (node and link) architecture not a relational (table and relationships) architecture.
Seven Nodes, Six Dimensions
After considerable struggle with the data it became clear to me that I was not dealing with a table in the normal sense. I could not reconcile a data cube with the seven dimensions I had discovered. Then it occurred to me that I was not dealing with a cube at all. I was dealing with a simpler solid, the octahedron. The octahedron has six dimensions (spokes) and seven vertexes.
This gives us a Hauy Construction (this figure is an eight degree):
Using my new taxonomy gives us the following views:
Front:
Side:
Top:
The age of the cube is over. Welcome to the age of the Octahedral Hauy Construction.
Formula
In this context we can deduct the following equation:
In the Business Interpretation E can represent Everything (Monopoly) and M can represent Market.
Generic Table
First, we create the generic table:
Generic Schema
We are now ready to create the schema:
We can also look at the role of long tails (exponential curves) and tipping points (singularities, pluralarities). Singularities occur when the taxonomy reaches it’s cost/benefit optimum and plurality when the data utilizes the entire business space. Benefit declines from that point.
What I am saying here is systems are not tabula rasas. Systems have a hardwired architecture and schematic that obeys simple physical laws that are in many ways understood as well as softwired structure that is unique to the system. We don’t have to create a unique architecture and unique schema for each system. Now they need only to be refined and applied across the spectrum of human endeavor. We need only learn how to classify the data.
