object oriented DBMS?

Question

1. define what is object oriented DBMS
2. differentiate between RDBMS and OODBMS
3. list next generation database systems
4. list advantages of object oriented DBMS

Answer 1

NEXT GENERATION DATABASE SYSTEMS

Computer sciences has gone through several generation of database management starting with indexed files and later, network and hierarchical data base management systems (DBMS).More recently, relational DBMS revolutionised the industry by providing powerful data management capabilities based on few simple concepts. Now, we are on the verge of another generation of database system called Object oriented DBMS based on object oriented programming paradigm. This new kind of DBMS, unlike previous DBMS models, manages more complex kind of database management system (KDBMS), which is used to support the management of the shared knowledge. It supports a large number of complex rules for automatic data inferencing (retrieval) and maintenance of data integrity.

The goal of these new DBMS is to support a much wider range of data intensive applications in engineering, graphic representation, scientific and medical. These new DBMS can also support new generations of traditional business applications.


NEW DATABASE APPLICATIONS

Some applications that require the manipulation of large amounts of data can benefit from using a DBMS. However, the nature of the data in these applications does not fit well into the relational framework.

1. Design databases: Engineering design databases are useful in computer-aided design/ manufacturing/ software engineering (CAD/CAM/CASE) systems. In such systems, complex objects can be recursively partitioned into smaller objects. Furthermore, an object can have different representations at different levels of abstraction (equivalent objects). Moreover, a record of an object's evolution (object versions) should be maintained. Traditional database technology does not support the notions of complex objects, equivalent objects, or object versions.

2. Multimedia databases: In modern office information or other multi-media system, data include text and numbers but also images, graphics and digital audio and video. Such multimedia data are typically stored as sequences of bytes with variable lengths, and segments of data are linked together for easy reference. The variable length data structure cannot fit well into the relational framework, which mainly deals with fixed-format records. Furthermore, applications may require access to multimedia data on the basis of the structure of a graphical item or by following logical links. Conventional query languages were not designed for such applications.

3. Knowledge bases: Artificial intelligence and expert systems represent information as facts and rules that can be collectively viewed as a knowledge base. In typical Artificial Intelligence applications, knowledge representation requires data structures with rich semantics that go beyond the simple structure of the relational model. Artificial decomposition and mapping would be necessary if a relational DBMS were used. Furthermore, operations in a knowledge base are more complex than those in a traditional database. When a rule is added, the system must check for contradiction and redundancy. Such operations cannot be represented directly by relational operations, and the complexity of checking increases rapidly as the size of the knowledge base grows.

In general, these applications require the representation of complex data elements as well as complex relationships among them. Users in these environments have found relational technology inadequate in terms of flexibility, modeling power, and efficiency.


OBJECT ORIENTED DATABASE MANAGEMENT

Object-oriented technologies in use today include object-oriented programming languages (e.g., C++ and small talk), object-oriented database systems, object-oriented user interfaces (e.g., Macintosh and Microsoft Windows systems) and so on. An object-oriented technology is a technology that makes available to the users facilities that are based on object-oriented concepts. To define object-oriented concepts, we must first understand what an object is.

Object

The term object means a combination of data and program that represents some real-world entity. For example, consider an employee named Amit; Amit is 25 years old, and his salary is $25000. Then Amit may be represented in a computer program as an object. The data part of this object would be (name: Amit, age: 25, salary: $25000). The program part of the object may be a collection of programs (hire, retrieve the data, change age, change salary, fire). The data part consists of data of any type. For the Amit object, string is used for the name, integer for age, and monetary for salary; but in general, even any user-defined type, such as Employee, may be used. In the Amit object, the name, age, and salary are called attributes of the object.


Encapsulation

Often, an object is said to encapsulate data and program. This means that the users cannot see the inside the object but can use the object by calling the program part of the object. This is not much different from procedure calls in conventional programming; the users call a procedure by supplying values for input parameters and receive results in output parameters.


Inheritance and Class

The term object- oriented roughly means a combination of object encapsulation and inheritance .The term inheritance is sometimes called reuse. Inheritance means roughly that extending an existing object may create a new object. Now let us understand the term inheritance more precisely. An object has a data part and a program part. All objects that have the same attributes for the data part and same program part are collectively called a class (or type). The classes are arranged such that some class may inherit the attributes and program part from some other classes.

Amit, Ankit and Anup are each an Employee object. The data part of each of these objects consists of the attributes Name, Age, and salary. Each of these Employee objects has the same program part (hire, retrieve the data, change age, change salary, fire). Each program in the program part is called a method. The term class refers to the collection of all objects that have the same attributes and methods. In our example, the Amit, Ankit and Anup objects belong to the class Employee since they all have the same attributes and methods. This class may be used as the type of an attribute of any object. At this time, there is only one class in the system namely, the class Employee; and three objects that belong to the class namely Amit, Ankit and Anup objects.


Inheritance Hierarchy or Class Hierarchy

Now suppose that a user wishes to create two sales employees, Jai and Prakash. But sales employees have an additional attribute namely, commission. The sales employees cannot belong to the class Employee. However, the user can create a new class, Sales Employee, such that all attributes and methods associated with the class Employee may be reused and the attribute commission may be added to Sales Employee. The user does this by declaring the class Sales Employee to be a subclass of the class Employee. The user can now proceed to create the two sales employees as objects belonging to the class Sales Employee. The users can create new classes as subclasses of existing classes. In general, a class may inherit from one or more existing classes and the inheritance structure of classes becomes a directed acyclic graph (DAG); but for simplicity, the inheritance structure is called an inheritance hierarchy or class hierarchy

The power of object-oriented concepts is delivered when encapsulation and inheritance work together.

Since inheritance makes it possible for different classes to share the share the same set of attributes and methods, the same program can be run against objects that belong to different classes. This is the basis of the object-oriented user interface that desk publishing systems and windows management systems provide today. The same set of programs (e.g., open, close, drop, create, move etc.) applies to different types of data (image, text file, audio, directory, etc.).

If the users define many classes, and each class has many attributes and methods, the benefit of sharing not only the attributes but also the programs can be dramatic. The attributes and programs need not be defined and written from scratch. Adding attributes and methods of existing classes, thereby reducing the opportunity to introduce new errors to existing classes, can create new classes.


PROMISES OF OBJECT ORIENTED SYSTEMS
Object-oriented systems make these promises:


Reduced maintenance
The primary goal of object-oriented development is the assurance that the system will enjoy a longer life while having far smaller maintenance costs. Because most of the processes within the system are encapsulated, the behaviours may be reused and incorporated into new behaviours.


Real-world modelling
Object-oriented systems tend to model the real world in a more complete fashion than do traditional methods. Objects are organised into classes of objects, and, objects are associated with behaviours. The model is based on objects rather than on data and processing.


Improved reliability
Object-oriented systems promise to be far more reliable than traditional systems, primarily because new behaviours can be built from existing objects.


High code reusability
When a new object is created, it will automatically inherit the data attributes and characteristics of the class from which it was spawned. The new object will also inherit the data and behaviours from all super classes in which it participates.


PROMISES AND ADVANTAGES OF OODBMS
An object-oriented programming language (OOPL) provides facilities to create classes for organising objects, to create objects, to structure an inheritance hierarchy to organise classes so that subclasses may inherit attributes and methods from super classes, and to call methods to access specific objects. Similarly, an object-oriented database system (OODB) should provide facilities to create classes for organising objects, to create objects, to structure an inheritance hierarchy to organise classes so that subclasses may inherit attributes and methods from superclasses, and to call methods to access specific objects. Beyond these , an OODB, because it is a database system, must provide standard database facilities found in today's relational database system (RDBs), including nonprocedural query facility for retrieving objects, automatic query optimisation and processing, dynamic schema changes (changing the class definitions and inheritance structure) , automatic management of access methods (e.g., B+- tree index, extensible hashing , sorting, etc.) to improve query processing performance, automatic tansaction management, concurrency control, recovery from system crashes, and security and authorisation. Programming languages, including OOPLs, are designed with one user and a relatively small database in mind. Database systems are designed with many users and very large databases in mind; hence performance, security and authorisation, concurrency control, and dynamic schema changes become important issues. Further, transaction systems are used to maintain critical data accurately; hence, transaction management, concurrency control, and recovery are important facilities.

In so far as a database system is system software, whose functions are called from application programs written in some host programming languages, we may distinguish two different approaches to designing an OODB. One is to store and manage objects created by programs written in an OOPL. Some of the current OODBs are designed to store and manage objects generated in C++ or Smalltalk programs. Of course, an RDB can be used to store and manage such objects. However RDBMSs do not understand objects --- in particular, methods, and inheritance. Therefore, what may be called an object manager or object- oriented layer software needs to be written to manage methods and inheritance and to translate objects to tuples (rows) of a relation (table). But the object manager and RDB combined are in effort to an OODB (with poor performance, of course).

Another approach is to make object - oriented facilities available to users of non- OOPLs. The users may create classes, objects, inheritance hierarchy, and so on, and the database system will store and manage those objects and classes. This approach in effect turns non- OOPLs (e.g., C, FORTRAN, COBOL, etc.) into object - oriented languages. In fact, C++ has turned C into an OOPL, and CLOS has added object - oriented programming facilities to Common LISP. An OODB designed using this approach can of course be used to store and manage objects created by programs written in an OOPL. Although a translation layer would need to be written to map the OOPL objects to objects of the database system, the layer should be much less complicated than the object manager layer than an RDB would require.

In view of the fact that C++, despite its growing popularity, is not the only programming language that database application programmers are using or will ever use, and there is a significant gulf between a programming language and a database system that will deliver the power of object - oriented concepts to database application programmers. Regardless of the approach, OODBs, if done right, can bring about a quantum jump in the productivity of database application programmers and even in the performance of the application programs.

One source of the technological quantum jump is the reuse of a database design and program that object - oriented concepts make possible for the first time in the evolving history of database technologies. Object - oriented concepts are fundamentally designed to reduce the difficulty of developing and evolving complex software systems or designs. Encapsulation and inheritance allow attributes ( i.e., database design) and programs to be reused as the basis for building complex database and programs. This is precisely the goal that has driven the data management technology from file systems to relational database systems during the past of designing and evolving very large and complex databases.

Advantages of Object--- Oriented Databases

Systems developed with object-- oriented languages have many benefits, as previously discussed. Yet, as also described, these systems have particular attributes that can be complemented with object-- oriented databases. These attributes include lack of persistence, inability to share objects among multiple users, limited version control, and lack of access to other data, for example, data in other databases.

In systems designed with object-- oriented languages, objects are created during the running of a program and are destroyed when the program ends. Providing a database that can store the objects between runs of a program offers both increased flexibility and increased security. The ability to store the objects also allows the objects to be shared in a distributed environment. An object- oriented database can allow only the actively used objects to be loaded into memory and thus minimizes or preempts the need for virtual memory paging. This is especially useful in large-scale systems. Persistent objects also allow objects to be stored for each version. This version control is useful not only for testing applications, but also for many object- oriented design applications where version control is a functional requirement of the application itself. Access to other data sources can also be facilitated with object- oriented databases, especially those built as hybrid relational systems, which can access relational tables as well as other object types.

Object- oriented databases also offer many of the benefits that were formerly found only in expert systems. With an object- oriented database, the relationships between objects and the constraints in objects are maintained by the database management system, that is, the object themselves. The rules associated with the expert system are essentially replaced by the object schema and the methods. As many expert systems currently do not have adequate database support, object-oriented databases afford the possibility of offering expert system functionality with much better performance.

Object-oriented databases offer benefits over current hierarchical and relational database models. They enable support of complex applications not supported well by the other models. They enable programmability and performance, improve navigational access, and simplify concurrency control. They lower the risks associated with referential integrity, and they provide a better user metaphor than the relational model.

Object-oriented databases by definition allow the inclusion of more of the code (i.e. the object's methods) in the database itself. This incremental knowledge about the application has a number of potential benefits of the database system itself, including the ability to optimize query processing and to control the concurrent execution of transactions.

Performance, always a significant issue in system implementation, may be significantly improved by using an object-oriented model instead of a relational model. The greatest improvement can be expected in applications with high data complexity and large numbers of inter-relationships. Clustering, or locating the related objects in close proximity, can be accomplished through the class hierarchy or by other interrelations. Caching, or the retention of certain objects in memory or storage, can be optimised by anticipating that the user or application may retrieve a particular instance of the class. When there is high data complexity, clustering and caching techniques in object databases gain tremendous performance benefits that relational databases, because of their fundamental architecture, will never be able to approach.

Object-oriented databases can store not only complex application components but also larger structures. Although relational systems can support a large number of tuples (i.e., rows in a table), individual types are limited in size. Object-oriented databases with large objects do not suffer performance degradation because the objects do not need to be broken apart and reassembled by applications, regardless of the complexity of the properties of the application objects.

Since objects contain direct references to other objects, complex data set can be efficiently assembled using these direct references. The ability to search by direct references significantly improves navigational access. In contrast, complex data sets in relational databases must be assembled by the application program using the slow process of joining tables.

For the programmer, one of the challenges in building a database is the data manipulation language (DML) of the database. DMLs for relational databases usually differ from the programming language used to construct the rest of the application. This contrast is due to differences in the programming paradigms and mismatches of type systems. The programmer must learn two languages, two tool sets, and two paradigms because neither alone has the functionality to build an entire application. Certain types of programming tools, such as application generators and fourth-generation languages (4GLs) have emerged to produce code for the entire application, thereby bridging the mismatch between the programming language and the DML, but most of these tools compromise the application programming process.

With object-oriented databases much of this problem is eliminated. The DML can be extended so that more of the application can be written in the DML. Or an object-oriented application language, of example C++ can be extended to be the DML. More or the application can be built into the database itself. Movement across the programming interface between the database the application then occurs in a single paradigm with a common set of tools. Class libraries can also assist the programmer in speeding the creation of databases. Class libraries encourage reuse of existing code and help minimise the cost of later modifications. Programming is easier because the data structures model the problem more closely. Having the data and procedures encapsulated in a single object makes it less likely that a change to one object will affect the integrity of other objects in the database. Concurrency control is also simplified with an object-oriented database. In a relational database, the application needs to look each record in each table explicitly because related data re-represented across a number of tables. Integrity, a key requirement for databases, can be better supported with an object-oriented database, because the application can lock all the relevant data in one operation. Referential integrity is better supported in an object-oriented database because the pointers are maintained and updated by the database itself. Finally, object-oriented databases offer a better user metaphor than relational databases. The tuple or table, although enabling a well-defined implementation strategy, is not an intuitive modeling framework, especially outside the domain of numbers. Objects offer a more natural and encompassing modeling metaphor.


DEFICIENCIES OF RDBMS

The data type facilities are the keys to eliminating three of the important deficiencies of RDBMSs. These are summarised below, we will discuss these points in greater detail later.

RDBs force the users to represent hierarchical data (or complex nested data or compound data) such as bill of materials in terms of tuples in multiple relations. This is awkward to start with. Further, to retrieve data thus spread out in multiple relations.

RDBs must resort to joins, a general expensive operation. The data type of an attribute of an attribute of an object in OOPLs may be a primitive type or an arbitrary user-defined type (class). The fact that an object may have an attribute whose value may be another object naturally leads to nested object representation, which in turn allow hierarchical data to be naturally (i.e., hierarchically) represented.

RDBs offer a set of primitive built-in data types for use as domains of columns of relation, but they do not offer any means of adding user-defined data types. The built-in data types are basically all numbers and short symbols. RDBs are not designed to allow new data types to be added and therefore often require major surgery to the system architechture and code to add any new data type. Adding a new data type to a database system means allowing its use as the data type of an attribute--- that is, storage of data of that type, querying, and updating of such data. Object encapsulation in OOPLs does not impose any restriction on the types of data that the data may be primitive types or user-defined types. Further, new data types may be created as new classes, possibly even as subclasses of existing classes, inheriting their attributes and methods.

Object encapsulation is the basis for the storage and management of programs as well as data in the database. RDBMSs now support stored procedures -- that is, they allow programs to be written in some procedural language and stored in the database for later loading and execution. However, the stored procedures in RDBs are not encapsulated with the data ---- that is, they are not associated with any linear relation or any tuple of a relation. Further, since RDBs do not have the inheritance mechanism, the stored procedures cannot automatically be reused.


DIFFERENCE BETWEEN RDBMS AND OODBMS

RDBMSs were never designed to allow for the nested structure. These types of applications are extensively found in CAD/CAE, aerospace, etc. OODBM can easily support these applications. Moreover, it is much easier and natural to navigate through these complex structures in form of objects that model the real world in OODBMS rather than table, tuples and records in RDBMS.

It is hard to confuse a relational database with an object-oriented database. The normalised relational model is based on a fairly elegant mathematical theory. Relational databases derive a virtual structure at run time based on values from sets of data stored in tables. Database construct views of the data by selecting data from multiple tables and loading it into a single table (OODBs traverse the data from object to object).

Relational databases have a limited number of simple, built-in data types, such as integer and string, and a limited number of built-in operations that can handle these data types. You can create complex data types in a relational database, but you must do it on a linear basis, such as combining fields into records. And the operations on these new complex types are restricted, again, to these defined for the basic types (as opposed to arbitrary data types or sub-classing with inheritance as found in OODBs).

The object model supports browsing of object class libraries, which allows the reuse, rather than the reinvention, of commonly used data elements. Objects in an OODB survive multiple sessions; they are persistent. If you delete an object stored in a relational database, other objects may be left with references to the deleted one and may now be incorrect. The integrity of the data thus becomes suspect and creates inconsistent versions.

In the relational database, complex objects must be broken up and stored in separate tables. This can only be done in a sequential procedure with the next retrieval replying on the outcome of the previous. The relational database does not understand a global request and thus cannot optimise multiple requests. OODBs can issue a single message (request) that contains multiple transactions.

The relational model, however, suffers at least one major disadvantage. It is difficult to express the semantics of complex objects with only a table model for data storage. Although relational databases are adequate for accounting or other typical transaction- processing applications where the data types are simple and few in number, the relational model offers limited help when data types become numerous and complex.

Object-oriented databases are favoured for applications where the relationships among elements in the database carry the key information. Relational databases are favoured when the values of the database elements carry the key information. That is, object- oriented models capture the structure of the data; relational models organise the data itself. If a record can be understood in isolation, then the relational database is probably suitable. If a record makes sense only in the context of other records, then an object-oriented database is more appropriate.

Engineering and technical applications were the first applications to require databases that handle complex data types and capture the structure of the data. Applications such as mechanical and electrical computer-aided design (MCAD and ECAD) have always used nontraditional forms of data, representing such phenomena as three-dimensional images and VLSI circuit designs. Currently these application programs store their data in application-specific file structures. The data - intensiveness of these applications is not only in the large amount of data that need to be programmed into the database, but also in the complexity of the data itself. In these design-based applications, relationships among elements in the database carry key information for the user. Functional requirements for complex cross references, structural dependences, and version management all require a richer representation than what is provided by hierarchical or relational databases.

OBJECT-ORIENTED DATABASE STRATEGIES

There are at least six approaches for incorporating object orientation capabilities in databases:

1. Novel database data model/ data language approach: The most aggressive approach develop entirely new database management system with object orientation capabilities. Most of the research project in object-oriented databases has pursued this approach. In the industry introduces novel DML (Data manipulation Language) and DDL (Data Definition Language) constructs for a data model based on semantic and functional data models.

2. Extending an existing database language with object-orientation capabilities: A number of programming languages have been extended with object-oriented constructs. C++ flavors (an extension of LISP), and Object Pascal are examples of this approach in programming languages. It is conceivable to follow a similar strategy with database languages. Since SQL is a standard and the most popular database language, the most reasonable solution is to extend this language with object-oriented constructs, reflecting the object orientation capabilities of the underlying database management system. This approach being pursued by most vendors of relational systems, as they evolve the next generation products. There have been many such attempts incorporating inheritance, function composition for nested entities, and even some support of encapsulation in an SQL framework.

3. Extending an existing object-oriented programming language with database capabilities: is to introduce database capabilities to an existing object-oriented language, object identity - will already be supported by the object-oriented language. The extensions will incorporate database features (quering, transaction support, persistence, and so on).

4. Embedding object-oriented database language constructs in a host (conventional) language: Database languages can be embedded in host programming languages. For example, SQL statements can be embedded in PL/I, C , FORTRAN and Ada. The types of SQL (that is relations and rows in relations) are quite different from the type systems if these host languages. Some object-oriented databases have taken a similar approach with a host language and an object-oriented database language.


SEO India | Cheap SEO Services India | SEO Company India | SEO
Search engine marketing - search engine optimization services - Internet Marketing services - website promotion - web promotion - marketing on the internet ...
http://www.imagewebsolutions.com/search-engine-optimization.html

Internet Marketing | Search Engine Marketing | Website Promotion
Professional search engine optimization - internet marketing company - search engine marketing - online marketing services - outsource website development ...
http://www.imagewebsolutions.com/internet-marketing-services.html


Pramod Kumar
SEO Expert India
http://www.imagewebsolutions.com/web-design-services.html

Answer 2

In an object oriented database, information is represented in the form of objects as used in Object-Oriented Programming. When database capabilities are combined with object programming language capabilities, the result is an object database management system (ODBMS). An ODBMS makes database objects appear as programming language objects in one or more object programming languages. An ODBMS extends the programming language with transparently persistent data, concurrency control, data recovery, associative queries, and other capabilities.

Some object-oriented databases are designed to work well with object-oriented programming languages such as Java, C#, Visual Basic .NET, C++ and Smalltalk. Others have their own programming languages. ODBMSs use exactly the same model as object-oriented programming languages.

Object databases are generally recommended when there is a business need for high performance processing on complex data.

Answer 3

In RDBMS there is just tables and keys, and each field is simple and contains only one type of data ex: name, lastName, ID, ...etc

In OODBMS the field is not as simple as RDBMS
for example if we take the field EMPLOEE
EMPLOEE contains many sub fiels

EMPLOEE
{NAME,
LNAME,
Password,
DOB,
Address}

you can see that each field is an object and each record is an instance of this object

Answer 4

Advantages and disadvantages

Benchmarks between ODBMSs and relational DBMSs have shown that ODBMS can be clearly superior for certain kinds of tasks. The main reason for this is that many operations are performed using navigational rather than declarative interfaces, and navigational access to data is usually implemented very efficiently by following pointers.[3]

Critics of Navigational Database-based technologies, like ODBMS, suggest that pointer-based techniques are optimized for very specific "search routes" or viewpoints. However, for general-purpose queries on the same information, pointer-based techniques will tend to be slower and more difficult to formulate than relational. Thus, navigational appears to simplify specific known uses at the expense of general, unforeseen, and varied future uses. (However, it may be possible to apply generic reorderings and optimisations of pointer routes in some cases).

Other things that work against ODBMS seem to be the lack of interoperability with a great number of tools/features that are taken for granted in the SQL world including but not limited to industry standard connectivity, reporting tools, OLAP tools and backup and recovery standards. Additionally, object databases lack a formal mathematical foundation, unlike the relational model, and this in turn leads to weaknesses in their query support. However, this objection is offset by the fact that some ODBMSs fully support SQL in addition to navigational access, e.g. Objectivity/SQL++ and Matisse. Effective use may require compromises to keep both paradigms in sync.

In fact there is an intrinsic tension between the notion of encapsulation, which hides data and makes it available only through a published set of interface methods, and the assumption underlying much database technology, which is that data should be accessible to queries based on data content rather than predefined access paths. Database-centric thinking tends to view the world through a declarative and attribute-driven viewpoint, while OOP tends to view the world through a behavioral viewpoint. This is one of the many impedance mismatch issues surrounding OOP and databases.

Although some commentators have written off object database technology as a failure, the essential arguments in its favor remain valid, and attempts to integrate database functionality more closely into object programming languages continue in both the research and the industrial communities.

Standards

The Object Data Management Group (ODMG) was a consortium of object database and object-relational mapping vendors, members of the academic community, and interested parties. Its goal was to create a set of specifications that would allow for portable applications that store objects in database management systems. It published several versions of its specification. The last release was ODMG 3.0. By 2001, most of the major object database and object-relational mapping vendors claimed conformance to the ODMG Java Language Binding. Compliance to the other components of the specification was mixed.[4] In 2001, the ODMG Java Language Binding was submitted to the Java Community Process as a basis for the Java Data Objects specification. The ODMG member companies then decided to concentrate their efforts on the Java Data Objects specification. As a result, the ODMG disbanded in 2001.

Many object database ideas were also absorbed into SQL:1999 and have been implemented in varying degrees in object-relational database products.

In 2005 Cook, Rai, and Rosenberger proposed to drop all standardization efforts to introduce additional object-oriented query APIs but rather use the OO programming language itself, i.e., Java and .NET, to express queries. As a result, Native Queries emerged. Similarly, Microsoft announced Language Integrated Query (LINQ) and DLINQ, an implementation of LINQ, in September 2005, to provide close, language-integrated database query capabilities with its programming languages C# and VB.NET 9.

In February 2006, the Object Management Group (OMG) announced that they had been granted the right to develop new specifications based on the ODMG 3.0 specification and the formation of the Object Database Technology Working Group (ODBT WG). The ODBT WG plans to create a set of standards that incorporates advances in object database technology (e.g., replication), data management (e.g., spatial indexing), and data formats (e.g., XML) and to include new features into these standards that support domains where object databases are being adopted (e.g., real-time systems).

Answer 5

I think it depends

Answer 6

http://en.wikipedia.org/wiki/Object-oriented_DBMS
the above link answers you

Answer 7

In computing, a database can be defined as a structured collection of records or data that is stored in a computer so that a program can consult it to answer queries. The records retrieved in answer to queries become information that can be used to make decisions. The computer program used to manage and query a database is known as a database management system (DBMS). The properties and design of database systems are included in the study of information science.

The term "database" originated within the computing discipline. Although its meaning has been broadened by popular use, even to include non-electronic databases, this article is about computer databases. Database-like records have been in existence since well before the Industrial Revolution in the form of ledgers, sales receipts and other business-related collections of data.

The central concept of a database is that of a collection of records, or pieces of Information. Typically, for a given database, there is a structural description of the type of facts held in that database: this description is known as a schema. The schema describes the objects that are represented in the database, and the relationships among them. There are a number of different ways of organizing a schema, that is, of modeling the database structure: these are known as database models (or data models). The model in most common use today is the relational model, which in layman's terms represents all information in the form of multiple related tables each consisting of rows and columns (the true definition uses mathematical terminology). This model represents relationships by the use of values common to more than one table. Other models such as the hierarchical model and the network model use a more explicit representation of relationships.

The term database refers to the collection of related records, and the software should be referred to as the database management system or DBMS. When the context is unambiguous, however, many database administrators and programmers use the term database to cover both meanings.

Many professionals consider a collection of data to constitute a database only if it has certain properties: for example, if the data is managed to ensure its integrity and quality, if it allows shared access by a community of users, if it has a schema, or if it supports a query language. However, there is no definition of these properties that is universally agreed upon.

Database management systems are usually categorized according to the data model that they support: relational, object-relational, network, and so on. The data model will tend to determine the query languages that are available to access the database. A great deal of the internal engineering of a DBMS, however, is independent of the data model, and is concerned with managing factors such as performance, concurrency, integrity, and recovery from hardware failures. In these areas there are large differences between products.


Database models

Various techniques are used to model data structure.

Most database systems are built around one particular data model, although it is increasingly common for products to offer support for more than one model. For any one logical model various physical implementations may be possible, and most products will offer the user some level of control in tuning the physical implementation, since the choices that are made have a significant effect on performance. An example is the relational model: all serious implementations of the relational model allow the creation of indexes which provide fast access to rows in a table if the values of certain columns are known.

Flat model

This may not strictly qualify as a data model, as defined above. The flat (or table) model consists of a single, two-dimensional array of data elements, where all members of a given column are assumed to be similar values, and all members of a row are assumed to be related to one another.

Hierarchical model

In a hierarchical model, data is organized into a tree-like structure, implying a single upward link in each record to describe the nesting, and a sort field to keep the records in a particular order in each same-level list.

Relational model

Three key terms are used extensively in relational database models: relations, attributes, and domains. A relation is a table with columns and rows. The named columns of the relation are called attributes, and the domain is the set of values the attributes are allowed to take.

The basic data structure of the relational model is the table, where information about a particular entity (say, an employee) is represented in columns and rows (also called tuples). Thus, the "relation" in "relational database" refers to the various tables in the database; a relation is a set of tuples. The columns enumerate the various attributes of the entity (the employee's name, address or phone number, for example), and a row is an actual instance of the entity (a specific employee) that is represented by the relation. As a result, each tuple of the employee table represents various attributes of a single employee.

All relations (and, thus, tables) in a relational database have to adhere to some basic rules to qualify as relations. First, the ordering of columns is immaterial in a table. Second, there can't be identical tuples or rows in a table. And third, each tuple will contain a single value for each of its attributes.

A relational database contains multiple tables, each similar to the one in the "flat" database model. One of the strengths of the relational model is that, in principle, any value occurring in two different records (belonging to the same table or to different tables), implies a relationship among those two records. Yet, in order to enforce explicit integrity constraints, relationships between records in tables can also be defined explicitly, by identifying or non-identifying parent-child relationships characterized by assigning cardinality (1:1, (0)1:M, M:M). Tables can also have a designated single attribute or a set of attributes that can act as a "key", which can be used to uniquely identify each tuple in the table.

A key that can be used to uniquely identify a row in a table is called a primary key. Keys are commonly used to join or combine data from two or more tables. For example, an Employee table may contain a column named Location which contains a value that matches the key of a Location table. Keys are also critical in the creation of indices, which facilitate fast retrieval of data from large tables. Any column can be a key, or multiple columns can be grouped together into a compound key. It is not necessary to define all the keys in advance; a column can be used as a key even if it was not originally intended to be one.


Relational operations

Users (or programs) request data from a relational database by sending it a query that is written in a special language, usually a dialect of SQL. Although SQL was originally intended for end-users, it is much more common for SQL queries to be embedded into software that provides an easier user interface. Many web sites, such as Wikipedia, perform SQL queries when generating pages.

In response to a query, the database returns a result set, which is just a list of rows containing the answers. The simplest query is just to return all the rows from a table, but more often, the rows are filtered in some way to return just the answer wanted. Often, data from multiple tables are combined into one, by doing a join. There are a number of relational operations in addition to join.

Normal Forms
Relations are classified based upon the types of anomalies to which they're vulnerable. A database that's in the first normal form is vulnerable to all types of anomalies, while a database that's in the domain/key normal form has no modification anomalies. Normal forms are hierarchical in nature. That is, the lowest level is the first normal form, and the database cannot meet the requirements for higher level normal forms without first having met all the requirements of the lesser normal forms

Object database models

In recent years, the object-oriented paradigm has been applied to database technology, creating a new programming model known as object databases. These databases attempt to bring the database world and the application programming world closer together, in particular by ensuring that the database uses the same type system as the application program. This aims to avoid the overhead (sometimes referred to as the impedance mismatch) of converting information between its representation in the database (for example as rows in tables) and its representation in the application program (typically as objects). At the same time, object databases attempt to introduce the key ideas of object programming, such as encapsulation and polymorphism, into the world of databases.

A variety of these ways have been tried for storing objects in a database. Some products have approached the problem from the application programming end, by making the objects manipulated by the program persistent. This also typically requires the addition of some kind of query language, since conventional programming languages do not have the ability to find objects based on their information content. Others have attacked the problem from the database end, by defining an object-oriented data model for the database, and defining a database programming language that allows full programming capabilities as well as traditional query facilities.

Post-relational database models

Several products have been identified as post-relational because the data model incorporates relations but is not constrained by the Information Principle, requiring that all information is represented by data values in relations. Products using a post-relational data model typically employ a model that actually pre-dates the relational model. These might be identified as a directed graph with trees on the nodes.