"Frans Bouma [C# MVP]" <
[email protected]> a écrit dans le
message de news: (e-mail address removed)...
| 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.
| 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
| 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.
| 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.
| 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.
| Though how a production database is migrated is often depending on the
| amount of data in the tables, not the structure of the tables itself,
| and because a production database with a lot of data is hard to backup
| / restore easily, migrating these databases can be a task which is
| often done by hand, tested in labs first etc.
If I were to migrate from one database manufacturer to another, I would
simply use one type of connection to read in the objects and then write them
out using a different type of connection. Both connections are written to
accomodate any peculiarities of the particular DB to which they are talking.
| 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.
| 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.
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
Joanna
