SUMit Roster Software > Nut's Weekly > March 2001 > Half-brothersNederlands · Search...

Half-brothers

 Monday, 12 March 2001 About Nut January 2001 February 2001
March 2001
Anonymous
Half-brothers
Ear Chicken April 2001 May 2001
It staff is a special lot. They live aside normal part of society, at the edge, but not in the gutter.

These special people can debate fiercely about abstract issues such as:

  1. Is the object model leading for the database model or vice versa?
    answer
  2. Should a Class in the object layer be 1 to 1 to a table in the database layer?
    answer
  3. Must an attribute of a Class have the same name as a column of a table?
    answer
I'm happy to stir up the fight with my personal answers.

1. The logical model

Is the object model leading for the database model or vice versa?

No. Neither is true.

The object model and the database model are two derivatives of one common source: the conceptual model. Logical Design See the schema with dependencies in OO development.

The phase "Conceptual modelling" results into a logical model, input for

  • OO modelling, which is input for making Classes and attributes.
  • physical database design, which is input for making tables and columns.
The OO model and the physical database model relate to each other as two half-brothers, children of a common parent.

2. Equivalents

Should a Class in the object layer be 1 to 1 to a table in the database layer?

No, absolutely not.

The OO model and physical database model might be family, but they are not full brothers and certainly not an identical twin. Each has his own unique properties.

Object Model Physical Database Model
Implements many-to-many relations with things like a Vector or Hashmap, if need be at both sides of the relation, but only if there is a functional requirement.. Many to Many Implements many-to-many relation almost always with a link table, that has just key columns.
Many to One Implements many-to-one relations with a reference to an other instance, but only if this is needed for a functional requirement. Implements many-to-one relations always with a foreign key on the many side, whatever the functional requirement might be.
Implements one-to-many relations with things like a Vector or Hashmap, but only if needed for a functional requirement. One to Many Implements one-to-many relations with an index on the foreign key column, but only if needed for a technical reson for performance optimisation.
One to One Implements one-to-one relations by combining entities to one class, or making a combination of super and subclasses. Implements one-to-one relations by linking several tables by a foreign key in the table with the lowest frequency of usage.
Every attribute gets a place in one specific class, with strong encapsulation. Even keys will not have redundancy. A column can get denormalised and occur in several tables. Key information will occur double any way, in several tables and indexes.
A method can be implemented in several classes, using polymorfism and inheritance. Some RDBMSses allow the programmer to put some coding in stored procedures. These stored procedures make the system tougher to debug. In addition triggers for stored procedures break down easily as they are not always active.
In an object model an instance will always be classified by one Class. A resultset from a database can contain information from several tables.
Conclusion: The result set of one single SQL query can serve as source for values of several attributes of several instances of several classes.

3. Mapping

Must an attribute of a Class have the same name as a column of a table?

No, please don't.

What makes a 3-tier architecture so neat is the one fact that the layers are independent of each other. The technical structure of the database can change, without impact on the object model.

So, for instance it is possible to combine two tables for performance reasons. This can even be done after implementation. It would be crazy when you're forced to change the object model as well.

Tips

  1. Please don't make one class per table, but one class for the entire database. This database class can nicely use an SQL join to combine columns from several tables.
  2. Keep the interface between database and object layer flexible. Use a result set as interface between DB and OO layer. Assign a fixed alias to every column in the SQL result set, which is the same in every query.
  3. Let the conceptual, logical model be leading for this alias, not the physical database or class structure. In this way, the interface between object and database layer stays nicely at a logical level, completely independent of the physical implementation.
Till next week,
Nut
February 2001 · Anonymous · Half-brothers · Ear · Chicken · April 2001
Home · Search...