The document discusses complex object-oriented databases, highlighting their evolution from simple data management to knowledge management and the need for object data management in various applications. It details various approaches to object data management, including extended relational database systems and object-relational mapping, along with the necessary features such as unique identifiers and long transactions. Additionally, it describes object-oriented abstractions, attributes, and the structure of binary and n-ary relationships.

1. Advance Database Management Systems : 9
Complex Objects
Prof Neeraj Bhargava
Vaibhav Khanna
Department of Computer Science
School of Engineering and Systems Sciences
Maharshi Dayanand Saraswati University Ajmer

2. 2
Complex Object-oriented databases
• Based on an object data model:
– Structured (hierarchical) objects
– Class hierarchies
– Attached functions and procedures
(‘encapsulation’)
• Comes close to object-oriented (OO)
programming.
• Used in special application areas.

3. 3
Evolution of database systems
1) Data management:
– Simple data structures and operations
2) Object management
– Complex data structures and operations
3) Knowledge management
– Complex rule bases and inference systems
– More ’intelligence’

4. 4
New database applications
(needing object management)
• Computer-aided design (CAD) and
manufacturing (CAM)
• Computer-aided software engineering (CASE)
• Office automation
• Computer-aided publishing (CAP)
• Graphics
• Scientific and medical applications
• Geographic information systems (GIS)
• etc.

5. 5
Object Data Management Needs
• Composite (complex) objects
• Unique and stable object identifiers
• Efficient references and integrity
• Object type hierarchy
• Associated procedures
• Object encapsulation
(hiding implementation details)
• Ordered sets (e.g. lists)

6. 6
Object Data Management Needs
(cont.)
• Long fields (text, image, audio, video)
• Efficient remote access (check-out / check-in)
• Long transactions (implying long locks)
• Single-user performance
• Versioning
• Support for schema changes
• Programming language interface (C++, Java)

7. 7
Approaches to object data
management
(1) Extended relational database systems
• Easy migration from existing systems, taking
advantage of their benefits
(relational data model and query language)
• Extensions:
– Procedures
– Object identity
– Type hierarchy
– Long fields

8. 8
Approaches to object data
management
(2) OO database programming languages
• Extension of e.g. C++, Java, or Smalltalk, to
provide persistence, concurrency control, etc.
• Programming and query language execute in
the same environment, share the same type
system and workspace.
• No big distinction between (persistent) db
objects and (transient) program objects.

9. 9
Approaches to object data
management
(3) Object-relational mapping
• An auxiliary package for performing the
mapping from the object model to a relational
schema (and back).
• Solves the so called impedance mismatch
between the models.
• May suffer from performance problems
• Example systems:
– Entity Framework (Microsoft)
– Hibernate (open source)

10. 10
Object-oriented abstractions
• Structural abstractions:
– Classification/instantiation
– Aggregation
– Generalization/specialization
– Association
• Behavioral abstraction:
– Encapsulated procedures

11. 11
Object identifiers
• Motivation: Shortcomings of value-based primary
keys in the relational model.
• System-generated, short, stable.
• No logical meaning, not shown to users.
• Used as references (‘handles’) between objects
• Implementation alternatives:
– Object address as id (efficient; stability problems)
– Location-independent surrogate (less efficient, stable)

12. 12
Attributes (properties, features)
= instance variables in OO languages
(a) Simple attributes:
– Literal values (numbers, characters)
– Not considered ‘objects’
(b) Complex attributes:
– References to represent relationships
– Collections of simple/reference/collection attributes
– Derived attributes, defined by procedures

13. 13
Binary relationships
• Reference attribute points to one-valued side
• Reference set attribute points to many-
valued side (pointer array / list)
• References appear as pairs, called inverse
attributes; they must be maintained intact.
Note the redundancy!
• Physical implementation alternatives:
Collocation, links, indexing

14. 14
N-ary relationships
• A separate relationship object type must be
created.
• Also binary M:M relationships having a
relationship attribute require a separate
object type.
• Creates an extra step in the ‘navigation’
through relationships.

15. Assignment
• What are the Object Data Management Needs
in ORDBMS
• Explain the Evolution of DBMS to New database