O/R Mapper

[Frans Bouma [C# MVP]]

Having never found a use for things like NIAM (I had to look it up to
see what it was), I can't see what you mean. I start my modelling by
defining classes that contain, not only data, but also functionality
as OO design is not just about data in isolation.

Then, if instances of that class require persisting, I then go on to
decide which attributes (data) require persisting and then map those
attributes to fields of tables in the teh OPF. Many classes in my
systems do not actually need persisting at all as they are "worker"
classes, used to manipulate other objects.

Ok, I think we then use a different approach towards creating
software. Which is perfectly fine of course, though it requires that
the proper tooling/methods are used which fit with the approach chosen.
I'm perhaps pretty old-school in this regard (Yourdon, Halpin etc.)

We find that, using our approach, employing a DBA would be serious
overkill as all the tables are created automatically, adjusted
automatically and the only SQL involved is simple Select, Update,
Insert and Delete statements

Heh well, as you might have read some of my anti-stored procedure
articles, you might have guessed I'm not that fond of the average
DBA-"stored procedures are the way to go" approach, though I think they
have their place, though more on the admin side, where tuning of RDBMS
parameters is required (e.g.: parameters outside the application scope,
like index bucket fill rate etc. )

Having to add foreign key fields and referential integrity
constraints into a database where they do not exist in the object
model is corrupting the original model. Relational theory was
invented to accomodate the need to store data in a relational
database. If you were able to use a well designed OODB, then you
would no longer need relational databases. Why should I have to store
the invoice lines separately from the invoice if they are an integral
part of that invoice ? Only because a relational database requires me
to do it that way.

If everything would have been as small as the sole entity, it would
indeed be the right approach. Though when I want a list of all
customer's company names and the order dates of their last orders, I
effectively create a new entity ('relation' in Codd's terms) which is a
first-class citizen of the relational model, but a bit of an ugly
stephchild in an OODB.

Also, OODBs are around for a long time now, but never gained any
ground while OO languages are around even longer, so something must
make them not really applicable to realworld scenario's.

Though I agree, if (not when) an application is fully suited with an
OODB, you don't need an o/r mapper.

I don't cut corners in class design, I use the OPF to translate the
object model into a relational one. However, due to the minimal
requirements of implementing an object storage mechanism, the
majority of what you call a "solid" relational model simply never
gets done; it is the job of the business classes themselves to
maintain inter-object integrity.

I think we disagree on that based on where we both come from and how
we look at the problem.

It looks like we must agree to differ. You seem to think that
everything has to be solved using relational modelling, whereas I
only use RDBs as a temporary store for objects.

I don't think 'everything' has to be solved with relational modeling,
I'm just practical. Just try it for a small simple customer-order etc.
app: go to http://www.orm.net (successor of NIAM), and read the basic
rules, it's very simple. You can model the reality without talking
about databases, classes or other things which map 1:1 to a technical
construct (table/class whatever). I think that's a great advantage, but
I agree with you, that we think differently and as long as we both
agree that the other approach is also doable but just 'different' it's
fine by me. I know a lot of people use E/R modelling and are very
succesful, but also know that a lot of people use DDD and are very
succesful.

Certainly, we use an attribute (property/field) as the smallest
granularity.

We have been known to create database views that manage inherited
classes, so that the base/derived classes are stored in "partial"
tables linked on the instance ID. but we tend to keep most classes to
full class per table, even if that means the same columns in multiple
tables. This is an optimisation that pays off in retrieval times at
the expense of being able to easily retrieve heterogeneous lists of
all instances of a hierarchy.

though wouldn't you agree that if said database is for example also to
be used in another application not using your o/r mapper, the database
would look 'un-normalized' or 'not properly normalized' and which would
be a bit of a problem?

We have never neede NIAM/ORM, we usually start with UML class
diagrams and use case diagrams. When we have a tested, working object
model, then we look at persistence. Don't forget, in theory we could
just keep all the objects in memory as in something like Prevayler,
only writing the whole object graph to disk when the application
quits.

sure, though querying and reporting would be a big pain

We really are approaching applicaiton design from two different
directions; you from the relational driven background where the world
can be ruled by RDBs , I from the OO background where RDBs are
mere (and inefficient) slaves to the object world

hehe I can live with that conclusion

Cheers

Frans

--

 

[Frans Bouma [C# MVP]]

Also, assuming that introducing an OR framework completely hides the
database access/product/etc. is naive at best. You still need to know
what is going on under the hood. For instance, you probably want to
know what kind of SQL statement is being sent to the server.

Isn't that contradicting with your statement below that it apparently
isn't important which relational model is created by the mapper? After
all, mapping classes to tables suggests that tables follow classes
which means that what you're doing with the classes would drive the
structure of the tables, as the tables are just storage for what you've
written in code.

two strings from the database. As the team didn't have a lot of
experience with the OR tool the just did what they thought was the
straight forward approach. In the end the SQL statement was a join
over a dozen tables and extremely slow. In the particular case the
issue was solved with a fairly simple stored procedure wrapped by a
simple method call.

As a side note: beware of people who think that mapping tables to
classes is identical to mapping a good object-oriented design to
tables, and that you end up with the same set of tables in both cases.
It usually raises a red flag if someone does not know the difference
between a class diagram and an ERD.

again, claiming things without proving why isn't helping the
discussion.

Let me help you, as I'm getting pretty tired of claims from people
without any proof. If you have something to say about which is bad or
good, explain why or don't claim things.

Let's say we define the following entities in the scope of our
application (among other entities):

Employee
Manager (subtype of employee)
BoardMember (subtype of manager)
CompanyCar
FamilyCar (subtype of CompanyCar)
SportsCar (subtype of CompanyCar).

We also identity the rule that only a boardmember can have a company
car.

If you use niam/orm you'd define a supertype employee, then a subtype
manager, then a subtype of that of boardmember. you also would define a
supertype companycar and 2 subtypes of that called familycar and
sportscar. You also would create a m:1 relation between boardmember and
companycar, as that would realize the rule that only boardmembers can
have a company car.

You can do the exact same thing in UML.

No tables have been created yet. Ok. Creating tables from this
abstract model creates an interesting question: you can model
hierarchies in 2 ways: every subtype in a separate table with a 1:1
relation over the PK, or you can flatten the hierarchy and store
everything in a single table with a discriminator column (there are
other ways, which are actually combinations).

As there is a relation between boardmember and company car which is
thus non-existend for manager and employee, it's better to opt for the
1-table per entity modelling. However for the
companycar-familycar/sportscar hierarchy, it doesn't matter, so we
flatten that hierarchy.

The tables we end up with are:
- employee
- manager (fk on pk to pk of employee)
- boardmember (fk on pk to manager, fk to companycar)
- companycar (with discriminatorcolumn cartype)

so 4 tables instead of 6.

Now, lets say the system architect uses niam/orm or other abstract
modelling technique and created those 4 tables. We then use the
table->class approach and what do we get?

4 entities.

So we mis 2. Now, from an OO's perspective, this is lacking, and I
fully agree (in LLBLGen Pro, you can re-create the complete hierarchy
as I explained earlier on, easily, recreating the complete abstract
model as it was intended, so at first it finds the 4 entities, and the
hierarchy of employee-manager-boardmember, and you create teh subtypes
familycar and sportscar).

Though what's the real deal? Isn't it so that all this is rather
semantic? If I have just 4 types, and just a companycar, is that
preventing me from writing software that works? No not at all, because
people are writing software with that paradigm for over 3 decades now.
It's just that it isn't that EASY to work with, because you can make
mistakes (if you don't interpret manually the cartype value, you might
treat a companycar row as a nice sportscar while it's a lame familycar!)

Though never forget: the data in the rows in the db are just data, and
get their semantic value in the sense of inheritance and what TYPE they
represent, by the context they're read. This means: beyond the type
offered by the relational model, as 'companycar' is the type offered by
the relational model but the types we're looking at are based on
semantical interpretation of a value in a column, not by the structure
of the type offered by the relational model.

Is the approach of using a proper relational model as the basis of
your application that weird though? No, as I just described, the
abstract elements which are used as building blocks are effectively the
same, be it an entity in a niam model or a class in an UML model. The
UML model combines behavior with teh data structure, the niam model
doesn't but that's a difference not really important for the structure
of the model.

Now, did I end up with different tables than a person who would have
started with UML? No. Employee, manager and boardmember are all mapped
to their own table. companycar, familycar and sportscar are all mapped
to the same table.

perhaps the cause of all this is the difference between datamodel and
relational model, I'm not sure. I hope people now realize what the
differences are between using an entity model vs using a pure table
model and can make their decision which one to choose.

For the record: I always talked about entities and the relational
model of entities, not about pure tables, as I've described above, you
can have multiple entities with just 1 table.

Bottom line my suggestions would be:
- Depending on your project size run a little experiment with
different approaches, determine selection criteria, and finally
decide on the make-or-buy decision.
- If you roll your own mapping, you should be extremely confident that
you can do better that those who implemented the available frameworks,
or you should have an excellent justification.

As a person who now works for 3 years full time on one of the
marketleaders, I can assure you: writing your own is simply too time
consuming: even if you just implement the very basic mapping code, its
still a lot of work, and also unnecessary, simply because there are
enough different o/r mappers out there which are solid and mature and
all have their own POV on the matter so it should be easy to find that
o/r mapper which fits the way you want to work with data.

I tried to write a little article on that some time ago:
http://weblogs.asp.net/fbouma/archive/2004/10/09/240225.aspx

Personally, I don't think anyone is helped with 'this is good' and
'this is bad' kind of babbling, simply because there isn't a silver
bullit. People who are perfectly comfortable with sql, table focussed
database access etc. have a hard time with DDD and o/r mappers but feel
at home with stored procs and datatables. We all can try to lecture
them that they're doing stupid things and use bad practises
(exxagerated) but at the end of the day, if they have succeeded in
writing a working succesful application, we're not justified to lecture
them, because they did manage to write a proper application.

FB

--