IrreducibleComplexityEntityModel

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).