Irreducible Complexity Entity Model

I am not sure that the name Irreducible Complexity Entity Model actually fits what I am about to describe, but it was the best name I could think of:

Lets think of an EntityModel (DatabaseModel??, RelationalModel?) that has at least one instance of each kind of entity relationship, so that it becomes representative of pretty much anything that can happen at any database:

• A OneToOne relationship
• A OneToMany? relationship

So we would have:

• TableA One To One TableB
• TableB One To Many TableC

But then, lets remember that there are recursive relationships so the list now is:

• A OneToOne relationship to the same table
• A OneToOne relationship to another table
• A OneToMany? relationship to the same table
• A OneToMany? relationship to another table

So now we have:

• TableA OneToOne TableA
• TableA OneToOne TableB
• TableB OneToMany? TableB
• TableB OneToMany? TableC

But then we realize that is not representative of all cases, because there is another kind of relationship, one that is “complex” (formed by 2 of the “simple” ones described before: Many To Many) so:

• A OneToOne relationship to the same table
• A OneToOne relationship to another table
• A OneToMany? relationship to the same table
• A OneToMany? relationship to another table
• A ManyToMany? relationship to the same table
• A ManyToMany? relationship to another table

And now we have:

• TableA OneToOne TableA
• TableA OneToOne TableB
• TableB OneToMany? TableB
• TableB OneToMany? TableC
• TableC ManyToMany? to TableC (using TableCC as intermediate)
• TableC ManyToMany? to TableD (using TableCD as intermediate)

---

Now, with at this point one would think that we have a representative case for each “conceptual” kind of entity relationship. Right? After all ObjectRelationalMappers? offer a way to map relationships for their ObjectOriented counterparts, and the only kinds of relationships that are supported by them when going from the database to the object model are: OneToOne, OneToMany? and ManyToMany?.

Well, it turns out that if we leave the relational world enter object orientation, then "Inheritance" enters the game, so I guess this IrreducibleComplexityEntityModel has to include "InheritsFrom?" as a relationship type (note that InheritsFrom? is the only kind of relationship that can not be used in "reflective" way):

• A OneToOne relationship to the same class
• A OneToOne relationship to another class
• A OneToMany? relationship to the same class
• A OneToMany? relationship to another class
• A ManyToMany? relationship to the same class
• A ManyToMany? relationship to another class
• A InheritsFrom? relationship to another class

And so we get:

• Composition
  • ClassA OneToOne ClassA
  • ClassA OneToOne ClassB
  • ClassB OneToMany? ClassB
  • ClassB OneToMany? ClassC
  • ClassC ManyToMany? to ClassC
  • ClassC ManyToMany? to ClassD
• Inheritance
  • ClassD InheritsFrom? ClassE

But, then we realize there is another case, what if the relation is not to a concrete but to an abstract class?

• Composition
  • A OneToOne relationship to the same class
  • A OneToOne relationship to another class
  • A OneToMany? relationship to the same class
  • A OneToMany? relationship to another class
  • A ManyToMany? relationship to the same class
  • A ManyToMany? relationship to another class
• Inheritance
  • A InheritsFrom? relationship to another ConcreteClass?
  • A InheritsFrom? relationship to an AbstractClass

And then (finally?) we realize that this "Concrete/Abstract" separation also applies to the Composition relationships:

• Composition
  • A OneToOne relationship to the same abstract class
  • A OneToOne relationship to the same concrete class
  • A OneToOne relationship to another abstract class
  • A OneToOne relationship to another concrete class

  • A OneToMany? relationship to the same abstract class
  • A OneToMany? relationship to the same concrete class

  • A OneToMany? relationship to another abstract class
  • A OneToMany? relationship to another concrete class

  • A ManyToMany? relationship to the same abstract class
  • A ManyToMany? relationship to the same concrete class

  • A ManyToMany? relationship to another abstract class
  • A ManyToMany? relationship to another concrete class

• Inheritance
  • A InheritsFrom? relationship to another ConcreteClass?
  • A InheritsFrom? relationship to an AbstractClass

---

Mmmm, now I realize that if its hard to find a Relational FunctionallyCompleteCrudGenerator it is event harder to find an ObjectOriented FunctionallyCompleteCrudGenerator, the IrreducibleComplexityEntityModel gets really complex and it is easy to oversee a particular combination of the kinds of relationships (Event now I wonder if I am missing a particular combination/ relationship kind).