OOPL vs DBMS design principles

From: Bob Badour <bbadour_at_golden.net>
Date: 17 Oct 2001 19:26:29 -0700
Message-ID: <cd3b3cf.0110171826.4074c7c0_at_posting.google.com>

"S Perryman" <q_at_deja.com> wrote in message news:<9puh2f$kisk6$1_at_ID-75294.news.dfncis.de>...

>

> What [OO Pundits] haven't done is given us guidance on how to overcome such
> problems in an OOP context. Fortunately some of us through background
> and experience, have discovered how to resolve the problem with some
> very simple principles.

If the principles are very simple, one should be able to enumerate them (at the very minimum.)

You will find that database management folks frequently enumerate their principles. (Physical independence, logical independence, logical identity, consistency, atomicity, isolation, durability, self description, etc.)

I have frequenly seen OO folks enumerate patterns and idioms. Only on rare occasions do they describe OO principles. (LSP is one.)

I find it interesting that someone has enumerated the Smalltalk language design principles:
http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html

It is interesting to contemplate the similarities and differences of the design principles of a good database management language.

The relational model encourages the following principles:

"Personal Mastery", "Good Design", "Purpose of Language", "Objects",
"Storage Management", "Messages", "Uniform Metaphor", "Modularity",
"Classification", "Polymorphism", "Factoring", "Leverage", "Virtual

Machine", "Natural Selection".

Differences exist in the following principles: "Scope", "Objects", "Messages", "Reactive Principle", "Operating System".

Scope: The principles of "Logical Independence" and "Physical Independence" suggest different languages or sub-languages for internal models, external media and interaction.

Objects: The "Information Rule" provides a uniform means for referring to objects in the universe of the dbms. However, the relational model's logical addresses consist of three parts -- one of which can have arbitrary form.

Messages: The relational model requires encapsulation of all domains. However, the relational model does not require any artifice that an operation with multiple parameters is a message of any one of those parameters.

Reactive Principle: A dbms does not assume any particular user interface. The user has access to each object through the operations defined on that object.

Operating System: A dbms should manage databases and leave operation to operating systems. A dbms should allow users to use whatever operating system they prefer when interacting with the dbms.

Of particular importance to database management, the relational model directly supports "Personal Mastery" and "Good Design". The system catalog supports "Personal Mastery". The "Information Principle" provides "Good Design". Received on Thu Oct 18 2001 - 04:26:29 CEST