2.  Object oriented databases are also called Object
Database Management Systems (ODBMS). Object
databases store objects rather than data such as
integers, strings or real numbers. Objects are
used in object oriented languages such as
Smalltalk, C++, Java, and others.

3. Objects basically consist of the following:
Attributes
• are data which defines the characteristics
of an object. This data may be simple such
as integers, strings, and real numbers or it
may be a reference to a complex object.

4. Methods
• define the behavior of an object and are
what was formally called procedures or
functions.

5.  Relational databases store data in tables
that are two dimensional. The tables have
rows and columns. Relational database
tables are "normalized" so data is not
repeated more often than necessary.

6.  All table columns depend on a primary
key (a unique value in the column) to
identify the column. Once the specific
column is identified, data from one or
more rows associated with that column
may be obtained or changed.

7.  With traditional databases, data
manipulated by the application is
transient and data in the database is
persisted (Stored on a permanent storage
device). In object databases, the
application can manipulate both transient
and persisted data.

8.  Object databases should be used when
there is complex data and/or complex
data relationships. This includes a many
to many object relationship

9.  . Object databases should not be used
when there would be few join tables and
there are large volumes of simple
transactional data.

10. Object databases work well with:
• CAS Applications (CASE-computer aided
software engineering, CAD-computer aided
design, CAM-computer aided manufacture)
• Multimedia Applications
• Object projects that change over time.
• Commerce

11. • Objects don't require assembly and
disassembly saving coding time and
execution time to assemble or disassemble
objects.
• Reduced paging
• Easier navigation

12. • Better concurrency control - A hierarchy
of objects may be locked.
• Data model is based on the real world.
• Works well for distributed architectures.
• Less code required when applications are
object oriented.

13. • Lower efficiency when data is simple and
relationships are simple.
• Relational tables are simpler.
• Late binding may slow access speed.
• More user tools exist for RDBMS.
• Standards for RDBMS are more stable.
• Support for RDBMS is more certain and
change is less likely to be required.

14.  The term client server database may sound
confusing to a non-techie in the field of the
internet. The client server database is
simply used every day on the Internet. They
include programs and the user of those
programs. A client server database can be
broken down to its terms. A client is usually
one who is “being served” or one who is
being helped.

15.  So in essence, “clients” refer to the users
and the “server,” is the one offering the
technical application. This creates a client/
server relationship. And the client server
database is the network, or the
applications that are currently being used.

16.  Client server databases allow us to collect
and use data from the Internet.
 So the client server database system is
very relevant as more people access the
Internet for everyday usage, and everyday
email checking.

17.  Technically, the client is the user of the
software program, whether it is a game,
email or chat. Anytime you open up an
Internet browser, you are a client. And the
database is a place to access those
applications. Any time a set of data is held
in a computer and can be accessed by the
client, and then this would be part of the
client server database system.

18.  It provides an essential reference for
anyone interested in the effective
management of semi-structured data. Since
many new and advanced web applications
consume a huge amount of such data, there
is a growing need to properly design
efficient databases.

19.  This volume responds to that need by
describing a semantically rich data model
for semi-structured data, called Object-
Relationship-Attribute model for Semi-
structured data (ORA-SS).

20.  Focusing on this new model, the book
discusses problems and presents
solutions for a number of topics,
including schema extraction, the design of
non-redundant storage organizations for
semi-structured data, and physical semi-
structured database design, among
others.

21. Semi-structured Database Design
 presents researchers and professionals
with the most complete and up-to-date
research in this fast-growing field.

22. The semi-structured model
 is a database model. In this model,
there is no separation between the
data and the schema, and the
amount of structure used depends
on the purpose.

23. The advantages of this model are the
following:
• It can represent the information of some
data sources that cannot be constrained
by schema.
• It provides a flexible format for data
exchange between different types of
databases.

24. • It can be helpful to view
structured data as semi-
structured (for browsing
purposes).
• The schema can easily be
changed.
• The data transfer format may be
portable.

25. Associative Model of Data
• is a new data-base architecture conceived
as an alternative to the Rational Model
Data, the software industry's standard
arch-itecture for database management
systems.

26.  The Associative Model embodies a
radically different approach, but is
equally powerful and expressive.
 When the Relational Model was
introduced in 1970, a large application
might have been 50 tables and 200
programs.

27.  Today's enterprise applications often
comprise tens of thousands of tables and
corres-pondingly vast numbers of
programs.
 The scale of modern applic-ations has
now outstripped their developers' ability
to readily comprehend them.

28. Associative Model of Data
 is an alternative data
model for database systems. Other data
models, such as the relational model and
the object data model, are record-based

29.  These models involve encompassing attributes
about a thing, such as a car, in a record structure.
Such attributes might be registration, colour,
make, model, etc. In the associative model,
everything which has “discrete independent
existence” is modeled as an entity, and
relationships between them are modeled as
associations.

30.  The granularity at which data is
represented is similar to schemes
presented by Chen (Entity-relationship
model); Bracchi, Paolini and Pelagatti
(Binary Relations); and Senko (The Entity
Set Model).

31.  Entity–attribute–value model (EAV) is
a data model to describe entities where
the number of attributes (properties,
parameters) that can be used to describe
them is potentially vast, but the number
that will actually apply to a given entity is
relatively modest.

32.  In mathematics, this model is known as
a sparse matrix. EAV is also known
as object–attribute–value
model, vertical database
model and open schema.

33. Structure of an EAV table
 This data representation is analogous to
space-efficient methods of storing
a sparse matrix, where only non-empty
values are stored.

34.  In an EAV data model, each attribute-
value pair is a fact describing an entity,
and a row in an EAV table stores a single
fact. EAV tables are often described as
"long and skinny": "long" refers to the
number of rows, "skinny" to the few
columns.

35. Data is recorded as three columns:
• The entity: the item being described.
• The attribute or parameter: a foreign key
into a table of attribute definitions.
• The value of the attribute.

36.  The table has one row for each Entity-
Attribute-Value triple.

37.  EAV is known under several alternative
names: object-property-value by the O-O
folks, frame-slot-value by the AI
folks. When implemented in databases,
an EAV table is called a "generic" table, or
an "open schema" table.

38.  Resource Description Format (RDF), the
basis for "Semantic Web" content, uses
the same approach: RDF content consists
of "Subject-Predicate-Object" triples.

39. Benefits:
 Flexibility
There are no arbitrary limits on the
number of attributes per entity. The number
of parameters can grow as the database
evolves, without schema redesign.
(Important in the EPRS)

40.  Space-efficient storage for highly sparse
data: One need not reserve space for
attributes whose values are null.

41.  A simple physical data format with
partially self-describing data. Maps
naturally to interchange formats like XML
(the attribute name is replaced with start-
attribute and end-attribute tags.)

42.  For databases holding data describing
rapidly evolving scientific domains,
insulation against consequences of
change and potential domain
independence.