I will start with an example.
Here are examples at each level to handle a user-customer relationship:
- Level 1 – RDB: A join table:
- Level 2 – OO: A few classes depending on use and need:
a user table with a customer objects list or a customer id’s list depending
a customer class
a user class
a ‘client’ data structure that contains both objects (references to them)
a user-customer relationship class
- Level 3 – IOP: Three endeme sets defining user-customer fields:
a UserIdentity set
a CustomerIdentity set
A relationship set
- Level 4 – KR: Two nodes and a relationship edge:
Native Organization Schemes
- Level 1 – RDB – relations
- Level 2 – OO – hierarchies
- Level 3 – IOP – matching/(or memberships?)
- Level 4 – KR – graphs
For matching, each piece of data is part of whatever it matches well. For membership, each piece of data is part of multiple things.
The First Three Organization Schemes Are Implemented Through Four Types of Tables:
- data tables – usually have a large number of rows focused on data
- lookup tables – usually have a smaller amounts of rows focused on data [OO]
- endeme tables – usually have a small number of rows focused on ‘type’ [IOP]
- join tables – plumbing used to connect data tables to tables in a n to n relationship [RDB]
Given the needs of various part of a project, work with one or more of these for different purposes.
Resulting in These Structures:
- hierarchy – oo is especially good with these [like lookup tables]
- join – uniquely relational [join tables]
- search – generally information oriented [endeme tables and endeme structures
- data – everyone works with data to some extent
- graphs – above the level of database tables?
Then adding two more types of tables:
- Endeme implementation tables – endemes
- Graph implementation tables – knowledge representation
These two new groups of tables implement endeme and knowledge representation structures (information structures) in a database. They generally set somewhat apart within the database in their own little engines.