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.

Structured Thinking System: Methods

Give a man a fish and you feed him for a day.
Teach him how to fish and you feed him for a lifetime.

Lao Tzu

sts-entities.jpg

  1. CREATE refers to the Verity. Make a Moral Law.
  2. RELATE refers to the Unity. Make a favorable Command.
  3. REPORT refers to the Quality. Make a favorable Discipline.
  4. RECORD refers to the Quantity. Make favorable Training.
  5. AFFORD refers to the Safety. Make favorable Terrain.
  6. ENGAGE refers to the Relief. Make a favorable Climate.

Related Links:

STL: Structured Thinking Language R0.3

I had a bit of an epiphany today. What I realized is that by structuring Structured Thinking Language as I have, everything can evolve as lists. Each VERB is simply the addition of another list to the NOUN you are working with.

Six Verbs: CREATE, RELATE, REPORT, RECORD, AFFORD, ENGAGE

Six Nouns: MOTIVE, LOCALE, OBJECT, METHOD, PERSON, MOMENT

Four Adjectives: INDUCED, DEDUCED and IMPLICIT, EXPLICIT

CREATE INDUCED|DEDUCED IMPLICIT|EXPLICIT
     NOUN
        (   nounname_1,
            ...,
            nounname_n
        );       

RELATE INDUCED|DEDUCED IMPLICIT|EXPLICIT
     NOUN.nounname TO
                (    NOUN_1.nounname_1,
                     ...,
                     NOUN_n.nounname_n
                );         

REPORT INDUCED|DEDUCED IMPLICIT|EXPLICIT
    NOUN.nounname
                (    attributename_1,
                     ...,
                     attributename_n
                );       

RECORD INDUCED|DEDUCED IMPLICIT|EXPLICIT
    NOUN.nounname.attributename
                (    constraintname_1,
                     ...,
                     constraintname_n
                );         

AFFORD INDUCED|DEDUCED IMPLICIT|EXPLICIT
    NOUN.nounname
                (    SELECT
                     INSERT,
                     UPDATE,
                     DELETE
                )
                ON
                (   NOUN_1.nounname_1,
                    ...,
                    NOUN_n.nounname_n
                );         

ENGAGE INDUCED|DEDUCED IMPLICIT|EXPLICIT
SELECT|INSERT|UPDATE|DELETE

Obviously, it still needs work, but we can see where the Structured Thinking Language adds value to the design process. SQL does have it’s place in data manipulation. However, STL has a place in data definition. See the related posts for background information on this syntax.

Related Posts:

Structured Thinking Language R0.3

STL: Structured Thinking Language R0.2

The more original a discovery, the more obvious it seems afterwards.
Arthur Koestler

I find I hated the Six Hats being six adjectives in STL R0.1 so I am changing them back to verbs:

  1. CREATE refers to the creation of entities. Meaning. Capability.
  2. RELATE refers to the creation of relationships. Uniqueness. Portability.
  3. REPORT refers to the creation of attributes. Value. Reliability.
  4. RECORD refers to the creation of constraints. Business Plan. Profitability.
  5. AFFORD refers to the creation of affordances. Adoption. Usability.
  6. ENGAGE refers to the creation of manipulations. Evangelism. Availability.

The Six Coats remain the unchanged nouns:

  1. MOTIVE refers to the rules of the system.
  2. LOCALE refers to to the nodes of the system.
  3. OBJECT refers to the data of the system.
  4. METHOD refers to the functions of the system.
  5. PERSON refers to the people of the system.
  6. MOMENT refers to the events of the system.

Giving us the following:

stl_r02_1.jpg

INDUCE and DEDUCE will be changed to the adjectives INDUCED and DEDUCED.

Now that we have the verbs, adjectives and nouns of STL we can work on Release 0.2 of the syntax:

CREATE INDUCED|DEDUCED IMPLICIT|EXPLICIT
     NOUN.nounname;

RELATE INDUCED|DEDUCED IMPLICIT|EXPLICIT
     NOUN.nounname
                (   MOTIVE.motivename,
                    LOCALE.localename,
                    OBJECT.objectname,
                    METHOD.methodname,
                    PERSON.personname,
                    MOMENT.momentname
                ); 

REPORT INDUCED|DEDUCED IMPLICIT|EXPLICIT
    NOUN.nounname.attributename; 

RECORD INDUCED|DEDUCED IMPLICIT|EXPLICIT
    NOUN.nounname.attributename.constraintname; 

AFFORD INDUCED|DEDUCED IMPLICIT|EXPLICIT
    NOUN.nounname
 	(	SELECT,
 		INSERT,
 		UPDATE,
 		DELETE
 	); 

ENGAGE INDUCED|DEDUCED IMPLICIT|EXPLICIT
SELECT|INSERT|UPDATE|DELETE
    NOUN.nounname.attributename.value;

That’s it for now. Time to get some sleep.

Related Posts:

Structured Thinking Language R0.2

STL: Structured Thinking Language R0.1

The more original a discovery, the more obvious it seems afterwards.
Arthur Koestler

Since I posted STL: Structured Thinking Language and STL: Structured Thinking Language (remix), I have made quite a bit of progress in my thinking regarding the syntax of Structured Thinking Language.

The Six Hats are no longer verbs. There are only two verbs in STL, INDUCE and DEDUCE. INDUCE is a bottom up process of learning the structure of a system. DEDUCE is a top down process of teaching the structure of a system. INDUCE observes and orients. DEDUCE decides and acts. All STL statements begin with the INDUCE or DEDUCE verb to determine whether you are referring to an existing or a new system.

Each of the verbs can also be IMPLICIT or EXPLICIT according to the definitions found in Implicity and Explicity.

The Six Hats are now six adjectives:

  1. CONCEPTUAL refers to the creation of entities. Revise. Creativity. Meaning.
  2. CONTEXTUAL refers to the creation of relationships. Relate. Relativity. Uniqueness.
  3. LOGICAL refers to the creation of attributes. Report. Optimicity. Benefit.
  4. PHYSICAL refers to the creation of constraints. Record. Pessimicity. Cost.
  5. MECHANICAL refers to the creation of affordances. Intuit. Anthropicity. Usability.
  6. OPERATIONAL refers to the creation of manipulations. Engage. Synchronicity. Convenience.

The Six Coats remain the unchanged nouns:

  1. MOTIVE refers to the rules of the system.
  2. LOCALE refers to to the nodes of the system.
  3. OBJECT refers to the data of the system.
  4. METHOD refers to the functions of the system.
  5. PERSON refers to the people of the system.
  6. MOMENT refers to the events of the system.

Giving us the following:

stl_r01_3.jpg

Now that we have the verbs, adjectives and nouns of STL we can work on the syntax:

INDUCE|DEDUCE IMPLICIT|EXPLICIT
CONCEPTUAL NOUN.nounname;    

INDUCE|DEDUCE IMPLICIT|EXPLICIT
CONTEXTUAL NOUN.nounname
                (   MOTIVE.motivename,
                    LOCALE.localename,
                    OBJECT.objectname,
                    METHOD.methodname,
                    PERSON.personname,
                    MOMENT.momentname
                );    

INDUCE|DEDUCE IMPLICIT|EXPLICIT
LOGICAL     NOUN.nounname.attributename;    

INDUCE|DEDUCE IMPLICIT|EXPLICIT
PHYSICAL    NOUN.nounname.attributename.constraintname;    

INDUCE|DEDUCE IMPLICIT|EXPLICIT
MECHANICAL      NOUN.nounname
		(	select,
			insert,
			update,
			delete
		);    

INDUCE|DEDUCE IMPLICIT|EXPLICIT
OPERATIONAL    NOUN.nounname.attributename.value;

NOUN can be any one of the Six Coats nouns. Noun name can be any name unique for that specific noun. Cardinality of context is always one to many be the relationship associative, relative or recursive. A noun has multiple attributes each with a constraint, affordances and ultimately a value.  Note I do not call mechanical access “privileges”.  I prefer “affordances”.

Structured Thinking Language R0.1

Systema: Observe, Orient, Decide and Act

john_r_boyd_2.jpg

Colonel John R. Boyd of the United States Airforce was a top fighter pilot who in his later years refined his understanding of arial combat into a four step lifecycle:

  1. Observe
  2. Orient
  3. Decide
  4. Act

which came to be known as the OODA Loop. The objective was simple, increase the frequency of your effective strikes to a rate faster than your opponent to disorient him and achieve victory. The diagram to illustrate this, however is less than obvious:

oodaloop02.jpg

As an alternative I prefer the sine wave presentation:

ooda_loop_2.jpg

In this way we can have a better understanding of the OODA Loop over a period of time. Each time you cross the horizontal red axis you strike. One thing that must be noted is that the loop of the system in combat is different than the loop of the system in dialog. The combat loop of System A is closed. It does not wait for the target system to receive input or transmit output. In the following diagram System A is cycling much faster than System B and consequently striking more often:

ooda_loop_03.jpg

Another quality of the OODA Loop is there is the entire cycle does not need to be completed. The following patterns are possible:

ooda_loop_04.jpg

The shape of the cycle is irrelevant as long as you are able to complete the cycle more rapidly than your opponent. This is termed as being “inside the opponent’s loop”.

Another aspect is the ability to “push down” the amplitude of each cycle through proper training. You can act without orientation or decision being necessary if you have conditioned your system to provide the correct response to a given state.

And all of this fits in nicely with the Structured Thinking Lifecycle:

ooda_loop_01.jpg

The difference is that Boyd has:

  1. Factored Repeat, Refine, Record into Observe
  2. Factored Report, Relate, Revise into Orient
  3. Factored Revise, Relate, Report into Decide
  4. Factored Record, Refine, Repeat into Act

Thus, the OODA Loop and the Structured Thinking Lifecycle complement each other nicely. All you have to do is choose your medium.

Implicity and Explicity

Nothing can be so amusingly arrogant
as a young man who has just discovered an old idea
and thinks it is his own.
Sidney J. Harris

By now I think I have established the legitimacy of the Six Hats, Six Coats Framework and I am presenting it here in what I am going to consider its final form:

zachmanframeworkabstract03.jpg

Every notational technique is a combination of two or more of the Six Coats. What we are working toward ultimately is a language to interrelate all Six Hats and Six Coats at once.

In this post I want to think about the terms “implicit” and “explicit” and how they relate to the Six Hats, Six Coats Framework. For the purpose of this framework implicit is defined as unchanging and invisible; explicit is defined as changing and visible.

Every entity, relationship, attribute, constraint, definition and manipulation has an implicit and explicit name. As well, every motive, locale, object, method, person and event has an implicit and explicit name. An implicit name is unique and once assigned cannot be changed. An explicit name is unique, but it can be changed. The implicit name is not visible to the user. The explicit name is visible to the user.

An entity which contains its own primary key is an implicit entity. An entity which contains a key from another entity in its primary key is an explicit entity.

A relationship that connects one entity’s primary key as part of the attributes of another entity is an implicit relationship. A relationship that connects one entity’s primary key as part of another entity’s primary key is an explicit relationship.

If the primary key is never made visible to the user and cannot be changed it is an implicit primary key. If the primary key is visible and can be changed as long as it is unique it is an explicit primary key.

Attributes that are foreign keys are implicit attributes. Attributes that are non-key are explicit attributes.

Constraints are implicit when they are data listed in a foreign entity. Constraints are explicit when they are a datatype.

Definitions are implicit when they protect explicit child tables. Definitions are explicit when they cascade manipulations.

Implicit manipulations maintain an audit trail. Explicit manipulations do not maintain an audit trail.

So, what is the purpose of implicity and explicity? Primarily it is strength and flexibility. Implicit design results in rigid, but more integral systems. Explicit design results in flexible, but less complete systems. For example, in an office you have work to rule, which is implicit, and work to allow, which is explicit. Ultimately, in dealing with implicity and explicity it is best to strike a balance. No system is fully normalized or fully exceptionalized. It is necessary to allow for both normality and exceptions as no system is fully closed or fully open.

Implicity and Explicity