|SUMit Roster Software > Nut's Weekly > March 2001 > Half-brothers||Nederlands · Search...|
|Monday, 12 March 2001||January 2001 February 2001 Anonymous 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:
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. See the schema with dependencies in OO development.
The phase "Conceptual modelling" results into a logical model, input for
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..||Implements many-to-many relation almost always with a link table, that has just key columns.|
|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.||Implements one-to-many relations with an index on the foreign key column, but only if needed for a technical reson for performance optimisation.|
|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.|
The result set of one single SQL query can serve as source for values of several attributes of several instances of several classes.
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.
· April 2001
Home · Search...