tion framework with long and nested transactions. Most of the applications evolve and they do no acquire a stable state until a long time after their initial implementation. For this reason it should be possible to do the following: the old data should not be overridden by new ones but should be kept and coexist as older versions of the same object and not as independent objects; and in case of schema changes, the data that correspond to previous schemas should not be thrown away but should evolve following the schema evolution.There is a set of features, finally, for which the designers can choose among different implementations that are not equivalent, but they have certain advantages and disadvantages. There are plenty of programming models (C++, Lisp, Smalltalk, etc.), but none of them should be considered better than the others. The designers choose the programming model of their system according to the kind of applications that the system is going to serve. The choice of the programming style is open as well. The one that better suits the applications should be chosen. The representation system is the set of the types or classes provided by the system as well as the set of constructors that can be applied on these classes. As long as the system provides support for extensibility and composite objects, there is no restriction of which member the representation should contain. There are systems that support the highest degree of uniformity, which means that everything in the system including classes, methods, messages, etc. is treated as an object. Uniformity has consequences at the level of the implementation of the system and at the level of the application programming and the user interface as well. Although uniformity is a nice feature and simplifies the implementation of the system, it can sometimes confuse the users since in reality there is no absolute uniformity.The design of the relational database system and the mechanisms...
