Why the term: ”database” in object context is also evil

1 .  Impedance mismatch
In the early days of objects there was much talk about “impedance mismatch”. The phrase comes from physics. The intention here was to tell that objects and relation databases have a crucial difference in the point of views used and they can even at concept level been naturally integrated.
2 .The fundamental difference in the core of concepts
The idea of “data” doesn’t exist in the world of objects at all! What does this mean? Well “data” is organic an inseparable part of an object. Compare this with car. The body of a car is so essential part of a car that there is actually no sense to talk about “car without a body” – this just doesn’t make any sense at all. This partial analysis led finally to concepts like “data”warehouse and “data”mining . These revel the absurdness of such separation.
So the “data” is inseparable part of object. This means that a concept of object-database is actually a total misinterpretation. The right term would be closer to object community or society or tribe or similar. Why even object base (without the data) be misleading. Now any collection of unrelated arbitrary object is worthless waist -next to pollution. Objects make sense only in association with other objects! These are not drawbacks of our viewpoint but in the contrary these are the restriction that we want to impose on our model to make our lives easier in the future!

3. Association is a first class citizen

To give for this a bit more organized or formal presentation let’s start by creating the model (metamodel) of our OO-analysis domain. The object model of a class model is the following:

metaMalli

When our class diagram look like following:

oEsim1.1

and a corresponding object diagram can look for instance like this:

oEsim1.2

Now when I would like to get rid of my Renault and I will sell it to Bill then the association between me and that car is removed. The point here is that both ends of the association leaves exactly at the same time. The result looks like this:

What we really mean ie. try to say exactly is that there exists an object typed association: the ownership which is connected to two distinct different type of entity objects ( person & car). Now from this we can easily see that association is not two mutually independent collections of object as they in most cases are implemented but is one thing with two aspects. When you remove the association object both ends are removed simultaneously and it is logically impossible just to remove one end because such association has now meaning.

4.  Object societies shouldn’t have query-languages
Query languages are a side effect of this data aspect. Technically SQL query feature gives one an illusion of combining almost anything with everything. In reality this is of course not true. In contrary the structure of realty restrict heavily a meaningful use of such feature. Another sad thing is that those current relational database implementations don’t check structural validity of a query. This means that one can join tables though columns and the semantic (ie. meaning) validity is not checked at all.
The right way to do this would be to restrict the navigational possibility only to structurally established associations. In object network (not in database) the navigation though the network can only be done trough established association and this traversing should happen using the corresponding objects get-methods. In every object network an object is heavily dependent of its direct associative neighbors. The dependencies beyond this get rapidly weaker and weaker. In this way for each class there have fuzzy sets of dependencies to other classes. One fundamental principle of a domain class model is that all classes are connected. This means that for every class of each other class is reachable and thus has an associative weight is > 0. In other worlds the network in connected and when one picks up an object from any class one can (at least in best circumstances) reach and an object in every other class of the graph.
The point here is that strictly speaking every class knows only its directly associated classes. To navigate longer than one leg route through the network the navigator is responsible of knowing the route through the network. There is this way a strikingly exact analogy to a street network in a city. The streets don’t know all the routes through the city but the corners know what next corners can be reached from them through their “association” namely street parts connecting two corners.
The only thing to add here to complete the required “query language” is to allow a multi attribute filters for the enable easy filtering of collections. When class A has a association to collection of Bs then A should have getBs() which returns the whole collection. To be effective A should have a selectBs() method with optionally all free attribute types of B. For example when our Person has one to many association to cars so Person class should have as a standard feature a method selectCars() with optionally color and production year (and all other free attributes that car happens to have). So I could get a subset of the whole car collection with the following method call: selectCars(“blue”, 2003).

Advertisements