Wednesday, February 18, 2009

Irreducible (Minimal?) Complexity: EntityModel (RelationalModel? DatabaseModel?)

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

Lets think of an Entity Model (Database Model?, Relational Model?) 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 One To One relationship
  • A One To Many relationship

So we would have:

  • TableA One To One TableB
    TableB One To Many TableC

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

  • A One To One relationship to the same table
  • A One To One relationship to another table
  • A One To Many relationship to the same table
  • A One To Many relationship to another table

So now we have:

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

But then we realize that there is si not representative of any case, 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 One To One relationship to the same table
  • A One To One relationship to another table
  • A One To Many relationship to the same table
  • A One To Many relationship to another table
  • A Many To Many relationship to the same table
  • A Many To Many relationship to another table

So we have:

  • TableA One To One TableA
  • TableA One To One TableB
  • TableB One To Many TableB
  • TableB One To Many TableC
  • TableC Many To Many to TableC (using TableCC as intermediate)
  • TableC Many To Many to TableD (using TableCD as intermediate)

Now, with this one would think we have a representative case for each “conceptual” kind of entity relationship. Am I right? (For example Object Relational Mappers? offer a way to map relationships for their Object Oriented counterparts, and the only kinds of relationships that are supported by them (when going from the database to the object model) are: One To One, One To Many? and Many To Many?. (If going from the Object Model to the database, then "Inheritance" enters the game, so I guess the Irreducible Complexity Entity Model would have to include "Inherits From?" as a relationship type (note that Inherits From? is the only kind of relationship that can not be used in "reflective" way):

* A One To One relationship to the same class
* A One To One relationship to another class
* A One To Many? relationship to the same class
* A One To Many? relationship to another class
* A Many To Many? relationship to the same class
* A Many To Many? relationship to another class
* A Inherits From? relationship to another class

And so we get:

* Class A One To One Class A
* Class A One To One Class B
* Class B One To Many Class B
* Class B One To Many Class C
* Class C Many To Many to Class C
* Class C Many To Many to Class D
* Class D Inherits From Class E

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

  • Composition
    • A One To One relationship to the same class
    • A One To One relationship to another class
    • A One To Many relationship to the same class
    • A One To Many relationship to another class
    • A Many To Many relationship to the same class
    • A Many To Many relationship to another class
  • Inheritance
    • A Inherits From relationship to another Concrete Class?
    • A Inherits From relationship to an Abstract Class

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

  • Composition
    • A One To One relationship to the same abstract class
    • A One To One relationship to the same concrete class
    • A One To One relationship to another abstract class
    • A One To One relationship to another concrete class
    • A One To Many relationship to the same abstract class
    • A One To Many relationship to the same concrete class
    • A One To Many relationship to another abstract class
    • A One To Many relationship to another concrete class
    • A Many To Many relationship to the same abstract class
    • A Many To Many relationship to the same concrete class
    • A Many To Many relationship to another abstract class
    • A Many To Many relationship to another concrete class
  • Inheritance
    • A Inherits From relationship to another Concrete Class?
    • A Inherits From relationship to an Abstract Class

I wonder if I am missing a particular combination/ relationship kind… (or if there is a simpler way to express this…)

No comments:

Requirements Analysis: Negative Space

A while ago, I was part of a team working on a crucial project. We were confident, relying heavily on our detailed plans and clear-cut requi...