Content deleted Content added
RProgrammer (talk | contribs) Re-wrote Characteristics section to use better English, provide more clarity in explanations, have a more logical ordering, and be more respectful of dynamic and diverse systems. |
RProgrammer (talk | contribs) m heheh, 'should have previewed it; I guess I'm still green on wiki-markup |
||
Line 92:
* '''Complex Objects''': Complex objects are built by using the basic data objects like integers, strings, reals, and booleans. There are various complex data objects such as array, list, indices, tuples, etc. We can define methods to manipulate these new complex types.
* '''Extensibility''': Any database system has its own predefined set of data types which we can use to build new types (see Complex Objects), but a purely extensible system is designed such that there are no logical differences between built-in (or 'primitive') data types and 'custom' data types, though there may be strong differences in the way the two are implemented.
* '''Types and Classes''': '''Type''' refers to the particular set of Objects in the system, which has two parts, the interface and the implementation. Generally, interfaces are visible to the user and the implementations are hidden. A '''Class''' is a template for creating objects of a particular type, having their own implementations. The new objects can be created by performing the [[
* '''Inheritance''': Inheritance is often considered one of the most important features of the object database, as it clearly defines the hierarchical relationships between different types of objects at different levels and provides code reusability. It helps in separating the specifications and implementations of the system at a high level, as well as in sharing the overall intended structure of the data in a team setting.
* '''Overriding and overloading''': The intentional use of the same name for multiple implementations of an object's method or operation to represent the same data in different ways, for conciseness when multiple similar operations are involved, and/or to alter the implementation of an inherited method to make it more suitable for the narrower definition of the object's data.
Line 99:
* '''Transactions and Concurrency''': Modifications should be grouped into logical 'transactions' both for concurrency and rollback. Concurrency: multiple simultaneous accesses to the database which don't conflict with each other should be able to actually execute simultaneously (to some degree). Rollback: if, during the transaction, the application decides to cancel the transaction, the system should be able to logically 'undo' any modifications already made during it. Another provision commonly granted by transactions is atomicity--the insurance that if not all of the modifications in the transaction are completed, none of them will be (by effectively rolling back the partial transaction).
* '''Recovery''': In the case of a catastrophic software or hardware failure, barring excessive data corruption, the system must later recover itself into a well-defined state, though usually at the expense of some of the data currently in-use at the time. <ref>K.R. Dittrich, ``Object-Oriented Database System : The Notions and the issues'', in : Dittrich, K.R. and Dayal, U. (eds): Proceedings of the 1986 International Workshop on Object-Oriented Database Systems, IEEE Computer Science Press</ref><ref>K. R. Dittrich, ``Preface'', In : Dittrich, K.R. (ed): Advances in Object-Oriented Database Systems, Lecture Notes in Computer Science, Vol, 334, Springer-Verlag, 1988</ref><ref>W. Kim, ``A foundation for object-oriented databases'', MCC Technical Report, 1988</ref>
=== Ancillary ===
| |||