Each Level Has its Own Native Structure

I will start with an example.

Here are examples at each level to handle a user-customer relationship:

  1. Level 1 – RDB: A join table:
    ——————
    user customers
  2. 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
  3. Level 3 – IOP: Three endeme sets defining user-customer fields:
    —————————————————–
    a UserIdentity set
    a CustomerIdentity set
    A relationship set
  4. Level 4 – KR: Two nodes and a relationship edge:
    ————————————–
    customer node
    user node
    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

Gellish?

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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s