HARAMAYA UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF COMPUTER SCIENCE

INDIVIDUAL ASSIGNMET FOR ADVANCED

DATABASE

Name-------------------------------------ID
Abdulhakim Michael--------------0466/16

Submitted to Mr. BAHER.H

Submission date march 31-2025

Chapter 1: Concepts for Object-Oriented Databases
1. Overview of Object-Oriented Concepts
Object-Oriented Databases (OODBs) are systems that store data as objects, drawing
inspiration from object-oriented programming (OOP) principles. In OOP,
programs are built around objects that encapsulate both data (attributes) and
behavior (methods), interacting through concepts like classes, inheritance,
polymorphism, and encapsulation. OODBs adapt these ideas to manage data,
offering a natural way to represent complex, interconnected information.

Key Features

• Objects as Data Units: Unlike relational databases, which use tables with
rows and columns, OODBs store data as objects that can contain attributes,
methods, and even other objects. This mirrors how objects are used in
languages like Java or C++.
• Complex Data Handling: OODBs excel at managing intricate data types
such as multimedia (images, videos) or hierarchical structures without the
need to flatten them into tables.
• Integration with Programming: By aligning with OOP, OODBs reduce the
impedance mismatch, the disconnect between a database’s data model (e.g.,
tables) and a programming language’s data model (e.g., objects). This
eliminates the need for extensive mapping layers.

Advantages
• Natural Relationships: Relationships between entities (e.g., a book and its
author) can be modeled directly, with objects referencing each other, rather
than relying on foreign keys and joins.
• Behavior Inclusion: Objects can include methods (e.g., a Book object with a
borrow() method), embedding logic within the data itself.

Example library system:

• A Book object might have attributes like title and publicationYear, a reference
to an Author object, and a method checkAvailability().
 • This contrasts with a relational database, where books and authors would be
separate tables linked by IDs, requiring joins to combine data.

2. Object Identity, Object Structure, and Type Constructors

This section delves into three foundational concepts that define how data is
represented and managed in OODBs.

❖ Object Identity

• Ensures uniqueness and relationship integrity via OIDs, enabling precise

tracking and referencing of objects.
• Every object in an OODB has a unique, persistent Object Identifier (OID),
which distinguishes it from all other objects, regardless of its attribute values.
• Purpose: OIDs ensure that objects remain uniquely identifiable even if their
data changes, and they enable direct referencing between objects.
• Comparison: Similar to primary keys in relational databases, but OIDs are
system-generated and independent of user-defined attributes.
• Example: In a library database, two copies of "The Great Gatsby" would have
different OIDs, allowing the system to track them as distinct objects despite
identical titles and authors. If an author’s name changes, all books referencing
that author’s OID automatically reflect the update.

❖ Object Structure

• Combines attributes and methods, supporting rich, nested data representations

and encapsulated behavior.
• Definition: An object’s structure comprises its attributes (data) and methods
(operations), defining both its state and behavior.
• Attributes: Can be simple (e.g., name as a string, age as an integer) or
complex (e.g., another object like address, or a collection like a list of
reviews).
• Methods: Operations tied to the object, such as getAge() or updateAddress(),
encapsulating behavior alongside data.
• Flexibility: This structure supports nested objects and complex data types
naturally, unlike the flat, tabular structure of relational databases.
• Example: A Person object might include:
o Attributes: name (string), age (integer), address (an Address object).
o Methods: calculateAge() or moveTo(newAddress).
 o A multimedia object like a Video could have a play() method.

❖ Type Constructors

• Facilitate the creation of complex types through classes and collections,

leveraging inheritance and composition for flexible modeling.
• Definition: Type constructors are mechanisms to define new data types,
primarily through classes, which serve as blueprints for creating objects.
• Classes: Specify an object’s attributes and methods, similar to OOP. They
support inheritance, allowing hierarchies (e.g., a Student class inheriting
from a Person class).
• Collection Types: Enable modeling relationships, such as:
➢ Lists: Ordered sequences (e.g., a list of Book objects in a Library).
➢ Sets: Unordered, unique collections (e.g., a set of Author objects for a
multi-author book).
• Purpose: Type constructors provide flexibility to define complex, reusable
structures tailored to the application’s needs.
• Example:
➢ A Book class might define:
▪ Attributes: title (string), author (an Author object), year (integer).
▪ Methods: borrow().
➢ A Library class could include a set of Book objects, with a method
addBook().

OODBs shine in scenarios requiring complex data relationships (e.g.,

multimedia systems, CAD software) and seamless integration with OOP
languages. However, they may lack the standardization and query
optimization of relational databases, making their suitability dependent on the
use case.

This overview provides a solid foundation for understanding how object-oriented

databases operate and why they differ from traditional relational systems.

3. Encapsulation of Operations, Methods, and Persistence

Encapsulation in Object-Oriented Databases
Encapsulation is a core principle in object-oriented systems, where data (attributes)
and the operations (methods) that manipulate that data are bundled together within
an object. In object-oriented databases, this means that each object not only stores
its own data but also the methods that define how that data can be accessed or
modified. This tight integration of data and behavior provides a natural and intuitive
way to model real-world entities.

• Operations and Methods: Methods are functions embedded within an object

that perform specific tasks or computations on its data. For example, in a
library database, a Book object might include attributes like title, author, and
ISBN, along with methods such as borrow() or return(). These methods
encapsulate the logic for updating the book’s availability, ensuring consistent
and controlled manipulation of the data.
• Contrast with Traditional Databases: In relational databases, data is stored
in tables, and operations are typically defined externally through queries (e.g.,
SQL) or application code. In OODBs, the methods are part of the *object
itself, reducing the separation between the database and the application logic.

Example:
A BankAccount object might have attributes like accountNumber and balance, and
methods like deposit(amount) or withdraw(amount). These methods enforce rules
(e.g., checking for sufficient funds before a withdrawal) directly within the database,
rather than relying on external code.

Persistence in Object-Oriented Databases

Persistence refers to the ability of objects to be stored in the database and retrieved
later, maintaining their state across different sessions or program executions. In
OODBs, persistence is a built-in feature that allows objects to seamlessly transition
between transient (in-memory) and persistent (stored) states.

• Object Identifiers (OIDs): Each object in an OODB is assigned a unique

Object Identifier (OID), a system-generated value that acts as a permanent
address for the object. OIDs ensure that objects can be located and referenced
consistently, even if their attributes change over time.
• State Preservation: When an object is saved, its entire state—including its
attributes and relationships with other objects—is preserved in the database.
This allows complex object structures (e.g., networks or hierarchies) to be
stored and retrieved intact.

Example:
In a university database, a Student object might reference a Course object via its
OID. When the Student object is persisted, this reference is maintained, ensuring the
relationship remains intact without requiring explicit joins or foreign keys, as in
relational databases.

Note: Unlike relational databases, where persistence involves mapping data to tables
and operations are external, OODBs store both data and methods together, providing
a more unified approach to data management.

4. Type Hierarchies and Inheritance

Type Hierarchies in Object-Oriented Databases

Type hierarchies allow data types (or classes) in an OODB to be organized into a
structured hierarchy, where types can inherit properties and behaviors from other
types. This mirrors the class hierarchies in object-oriented programming, enabling a
more modular and reusable database design.

• Supertypes and Subtypes: A supertype (parent type) defines attributes and

methods common to a group of related types. Subtypes (child types) inherit
these properties and can extend them by adding their own specific attributes
or methods.
• Benefits: Inheritance promotes code reuse by defining shared characteristics
once in the supertype, and it enhances modularity, making the database
schema easier to maintain and extend.

Example:
In a university database, a supertype Person might include attributes like name and
address, and a method like updateAddress(). Subtypes Student and Professor inherit
these properties, adding their own attributes such as studentID for Student or
department for Professor.

Inheritance Mechanisms

Inheritance allows subtypes to reuse and potentially modify the attributes and
methods of their supertypes.

a. Single Inheritance: A subtype inherits from one supertype. For instance,

Student inherits from Person.
b. Multiple Inheritance: Some OODBs support a subtype inheriting from
multiple supertypes (e.g., a TeachingAssistant inheriting from both Student
and Professor). This can introduce complexity, such as method name
 conflicts, which the database must resolve (e.g., through a predefined
resolution order).

Example:
A TeachingAssistant might inherit enrollCourse() from Student and assignGrade()
from Professor. If both supertypes define a method like getRole(), the OODB must
specify which version is used or allow the subtype to override it.

❖ Advantages of Type Hierarchies and Inheritance

a. Intuitive Schema: Hierarchies reflect real-world relationships (e.g., all
students are persons), making the database design more natural.
b. Polymorphic Queries: Queries on a supertype can apply to all its subtypes.
For example, a query for all Person objects with a specific name would return
both Student and Professor instances.
c. Extensibility: New subtypes can be added without altering existing
supertypes, simplifying schema evolution.

✓ Key Difference
• Relational databases lack native inheritance support, requiring work
arounds like separate tables per subtype or a single table with type flags.
• OODBs provide built-in inheritance, making hierarchical relationships
more efficient and elegant.

Encapsulation of Operations, Methods, and Persistence: By bundling data

and methods within objects, OODBs enable a cohesive approach to data
management. Persistence, supported by OIDs, ensures that objects and their
relationships are preserved over time, offering a seamless integration of
transient and stored states.
Type Hierarchies and Inheritance: These mechanisms organize data into
reusable, hierarchical structures, enhancing modularity and supporting
complex relationships through inheritance.

Together, these concepts make object-oriented databases particularly suited

for applications requiring rich data models and complex interactions,
providing a robust foundation for representing and managing real-world
entities effectively.