While Relational DB's are by far the most powerful of all organized methods for Data Storage, they are not necessarily the best for all situations. We look at two other systems which provide better DBMS's in some situations.

In many real-life situations, the best description of relationships between Entities is not n-ary relations, but through other semantics, such as hierarchical breakdowns, or sub-classes.

Typical examples:

In Product Classifications, each class of a product has some characteristics (attributes). Further, it has several subclasses, each of which inherits some attribute values from the parent, but has it's own values for others.

In BOM's, each product (class) is composed of a set of other sub-assemblies/parts (subclasses). Each subclass has its own attribute types. For example, a Computer is composed of
a keyboard (which has attribute: shape, no-of keys, etc.),
Monitor (which has attributes: screen-size, Resolution etc.),
Motherboard (which has attributes: CPU-type, CPU-speed, Cache-size etc.)
and so on..

In each of these examples, Relational tables cannot express the relationships in a natural way.

In some other applications, such as DB's for CAD/CAM applications, Geographic DB's etc., the size of data in each field can be massive.

In some applications, the transaction durations can also be very large.

For each of the above cases, OODB's provide a better means for Data modeling and Data management.

1. Each entity about which information is stored is treated as an Object; every object in the OODB has a unique identity (Object ID) assigned by the OO DBMS.

2. Objects are characterized by the information that describes them (Data) AND the way that the object interacts with other objects, or with itself (Methods). Since all such information is stored within the object, this concept is called encapsulation.

3. Subclasses inherit information and methods from their parent classes, thereby providing the standard mechanism for inheritance of OO programming.

Several companies have recently developed industrial strength OO DBMS's, but not many large scale users are known. Examples of systems/sources:

ObjectStore, from Object Design Inc.,

OpenOODB, from Texas Instruments Corp.,

O2, from O2 Technologies,

Ontos, from Ontologics,

etc.

Relational DBMS, like the ones we studied, focus on how to organize ALL information of an enterprise into a single, unified DB. Then, if different users require different subsets of the information, we can use security control mechanisms, or views, or combination of these two.

DDBS are different from this in a fundamental way: the data in a DDBS can exist in several different databases (possibly non-homogeneous). Each DBMS is connected to the other through a computer network.

A distributed computing system consists of a number of independent computers that are inter-connected by a network and cooperate in performing an assigned DB-related task. The data, and even the DB control and Functions are distributed.

The key in DDBS is INTEGRATION of the different DB's without INTEGRATING them.

Architecture of a DDBS

1. Improved performance (data is close to the end-user.)

2. Improved control (e.g. DB's for several franchises of a store, like 7-11).

1. Data may be replicated/repeated in several DB's: difficult to maintain consistency.

2. Executing commands over network cause security, and well as additional transaction processing problems (concurrency control is much more difficult, failed transactions are more common).