Re: O/R Mapper

Joanna Carter [TeamB] wrote:

> "Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xxxxxxxxx> a écrit dans
> le message de news: xn0eh6swtha2ie001@xxxxxxxxxxxxxxxxxxxxx
>
> > Well, if you follow this analogy:
> > - create NIAM model from reality
> > - create E/R model from niam model
> > - create tables from E/R model
> >
> > - create entity types back from tables,
> >
> > you get back your e/r model. With the proper tooling you get back
> > the niam model from the reverse engineered e/r model.
>
> 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.)

> > In a lot of organisations, this is a proper way of designing the
> > database, often done by a person who's job it is to design the
> > schemas/maintain the schemas because that person is the specialist
> > for relational models. Although I'd love to say that programs can
> > do that job for that person, it's often a lot of 'interpretation'
> > of the reality to come to the proper result.
>
> 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. )

> > though neither would the other way around.
>
> 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.

> > yeah well, if you start with the classes and create teh relational
> > model from that, you of course cut corners to make it as easy as
> > possible for the classes to get persisted and let the o/r mapper
> > do its job, which will compromise what otherwise would have been a
> > solid relational model.
>
> 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's hard, but doable to reproduce an abstract model of entities
> > which aren't 1:1 copies of table definitions, and which are also
> > usable in hierarchies for example (supertype/subtype) which
> > already move away from the relational approach as inheritance
> > isn't modelable in a relational model without semantic
> > interpretation of the relational model and / or containing data.
>
> 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.

> > I do similar things: you can define a list based on fields in the
> > entities in the project (which support inheritance) which are
> > related, and you can also do that in code, dynamically. Using the
> > compile-time checked query language then to build the query with
> > aggregates, groupby etc. for reporting data.
> >
> > Not a lot of the o/r mappers out there offer that kind of
> > features, as most of them use the entity as their smallest block
> > to work with, while if they would use teh attribute (entity
> > field), dynamic lists and the like would be possible.
>
> 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?

> > I also think what is the core information provider for your design
> > is important. If you, as I stated above, use NIAM/ORM or similar
> > highly abstract modelling technique to design the reality with the
> > customer during the functional research phase, you have other
> > sources of information than when you start with a UML model. It's
> > not that the other way of doing things doesn't work or works less
> > good, it's just that a person should realize that by starting with
> > the DB requires a properly designed relational model, and starting
> > with classes requires a properly designed class model. If people
> > don;t realize that, no matter what technique they choose, it will
> > be cumbersome.
>
> 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

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
.

Relevant Pages

  • Re: How do I create an Excel database?
    ... It can be argued that the proper place for a database is database management ... It is important to design a spreadsheet not just type everything in. ... On the output side I can't comment as I don't know the purpose to which data ...
    (microsoft.public.excel.newusers)
  • Re: How do I create an Excel database?
    ... > It can be argued that the proper place for a database is database ... Each piece of information on the card is a field. ... > design I mean stop, have a cup of tea and think about what is wanted. ...
    (microsoft.public.excel.newusers)
  • Proper database design input needed
    ... I have a question about proper table design. ... the CustNum for a reference back to the customer and call it good. ... This would require me to change the database structure to add the ...
    (microsoft.public.access.tablesdbdesign)
  • Proper database design input needed
    ... I have a question about proper table design. ... the CustNum for a reference back to the customer and call it good. ... This would require me to change the database structure to add the ...
    (microsoft.public.access.tablesdbdesign)
  • C# programmer looking for a job
    ... Software Development including Desktop, Client/Server and Database ... Practical skills in object oriented design and design patterns ... XML, Oracle, CVS, VSS, Delphi, bug tracking. ... Developed in Delphi5; ...
    (misc.immigration.usa)