1. The Universal Database Design The Future of Data For Database Architects

2.  To handle objects effectively, you need to be able to relate any entity to any other entity, but this is difficult when they are separated into different entity tables. Primary Entity Key Relationship Type Secondary Entity Key (Fan23)Type Of(AcmeFan) (Fan23)Contains(Motor23) (Fan23)Connected To(Wire 14) Fan Table Motor Table Wire Table Primary / Secondary FansMotorsWires FansXXX MotorsXXX WiresXXX  This chart shows that to relate the entities of an N=3 number of tables to each other, there are N 2 =9 number of combinations – a measure of complexity.

3. EntityKeyNameManufLength Length Unit Size Size Unit X X Unit (AcmeFan)Acme FanAcme (Fan23)Fan23Acme13inSmall (Motor23)Motor23Nadir15kW30% (Wire14)Wire14Nadir10ft20mm 2 0.001 Ω  Commonly-used attributes and relationships are simpler to manage if the entities using them are put into the same entity table.  But putting different types of entities into the same table increases the amount of unused space.  Allowing different input formats and units of measurement also increases the amount of unused space.  To allow more than one value per cell requires either more columns or more secondary tables.

4.  Because database tables are custom- designed and crafted to match the applications they support, they are isolated from each other.  Integration leads to an N 2 number of point-to-point translations and increased developmental gridlock.  Because most changes are structural, it increases the cost of change, including the transition (or loss) of legacy data.

5.  The General Relation Table uses foreign keys from a General Entity Table holding the entity and relationship types. Primary Entity Key Relationship Type Key Secondary Entity Key (Fan23)(TypeOf)(AcmeFan) (Fan23)(Contains)(Motor23) (Fan23)(ConnectedTo)(Wire 14)  To handle object data and other types, we need to increase the flexibility of relationships, but without increasing the complexity.  As shown previously, complexity of a system is proportional to the number of different types of tables squared(N 2 ). To reduce the complexity, it is very effective to reduce the number of table types.  A solution starts with defining a General Relation Table to handle any standard relationship between two entities.

6. Entity KeyNameManufLength Length Unit Size Size Unit X X Unit (AcmeFan)Acme FanAcme (Fan23)Fan23Acme13inSmall (Motor23)Motor23Nadir15kW30% (Wire14)Wire14Nadir10ft20mm 2 0.001 Ω (TypeOf)Type Of (Contains)Contains (ConnectedTo)Connected To  A General Relation Table requires entities and relationship types to be from the same table, the General Entity Table.  Combining all entities in the same table lets any entity have any attribute, but generates more unused space as is.

7.  Using normalization, attribute columns can be replaced with relationships, eliminating the empty space, and allowing multiple values for each attribute. Primary Entity Key Relationship Type Key Secondary Entity Key (Fan23)(TypeOf)(AcmeFan) (Fan23)(Contains)(Motor23) (Fan23)(ConnectedTo)(Wire14) (AcmeFan)(Manuf)(Acme) (Fan23)(Manuf)(Acme) (Motor23)(Manuf)(Nadir) (Wire14)(Manuf)(Nadir) Entity KeyName (AcmeFan)Acme Fan (Fan23)Fan23 (Motor23)Motor23 (Wire14)Wire14 (TypeOf)Type Of (Contains)Contains (ConnectedTo)Connected To (Manuf)Manuf

8.  The old design pattern holds values whose meaning are dependent on the row and column positions in each table. This leads to separate, hard- coded, custom-built functions to handle each different table and column.  The new design pattern holds small, atomic pieces of Equal Format Data in a standard container, called an Equal Format Database. This leads to standard, reusable functions with powerful data management capabilities across all “columns”.

9.  To see the differences in normalization patterns, first examine the statistics of the entities and attributes used. Fans Motors Wires  The old design method uses the pattern of data to define separate tables that match the groupings, each with some of the possible attributes.  The new design method keeps everything in the same “table”, with a full selection of all possible attributes – past, present and future. Fan Table Motor Table Wire Table Old New

10.  Entity-Relationship (E-R) Triplets have some limitations. They can be difficult to use for some data. It would help to expand past triplets, but we need a larger pattern to guide us. Subject KeyVerb KeyObject Key (Fan23)(TypeOf)(AcmeFan) (Fan23)(Contains)(Motor23) (Fan23)(ConnectedTo)(Wire14) (AcmeFan)(Manuf)(Acme) (Fan23)(Manuf)(Acme) (Motor23)(Manuf)(Nadir) (Wire14)(Manuf)(Nadir)  The first step in improving triplets is to convert the entity-relationship triplets to Semantic Triplets. This only requires a name change to the columns, making each row into a Sentence. This concept lays the foundation of the next steps.

11. Sentence Key Syntax KeyPhrase Key (S1)(Subject)(Fan23) (S1)(Verb)(TypeOf) (S1)(Object)(AcmeFan) (S2)(Subject)(Fan23) (S2)(Verb)(Contains) (S2)(Object)(Motor23) (S3)(Subject)(Fan23) (S3)(Verb)(ConnectedTo) (S3)(Object)(Wire14) (S4)(Subject)(AcmeFan) (S4)(Verb)(Manuf) (S4)(Object)(Acme)  Another normalization step moves each phrase to its own row, allowing more phrases per sentence and more phrases per syntax position.  Now you can scan through “tables” and “columns” as easily as rows.  Controls can be added for special capabilities, such as nondestructive changes, point-in-time storage, with less locking problems.

12.  The old design pattern leads to an N 2 number of point-to-point translations, leading to developmental gridlock.  The new design pattern reduces the burden of point-to-point translations, providing a uniform container, a uniform pipeline, and simpler systems.

13.  Equal Format Database containers can be grouped together to take advantage of many scaling techniques, without altering the data atoms moved between them.  Built on standard database systems, Equal Format Databases are easily integrated with legacy data in various ways.