CoSc 2042 Chapter 1: Object‑Oriented Databases – Ethio Temari

📘 Chapter 1: Concepts for Object‑Oriented Databases

Course: Advanced Database Systems (CoSc 2042) | Year II, Semester II | Ethio Temari – free learning

✨ Salam, dear student! In this lesson we will explore Object‑Oriented concepts that form the heart of modern databases. We’ll go step by step, with lots of examples and practice like we’re in the same room. 🇪🇹

1.1 Overview of Object-Oriented Concepts

Before we jump into object‑oriented databases (OODB), we need to understand what an object really means. In simple words: an object is like a thing from real life – a student, a car, a bank account. It has data (attributes) and behaviours (methods) bundled together. Think of it as a small machine that knows stuff and can do stuff.

🎯 What is an object? (psychology + computing)

From the PDF: “Object is a kind of idiom or metaphor that addresses human psychology and the way humans perceive the real world.” That means we naturally think in objects. Your bicycle is an object: colour, speed (attributes) and you can pedal, brake (methods).

In an OODB, we store data together with methods. For example, a ‘Student’ object stores your name, ID, and also has a method calculateGPA() right inside the database. Amazing, right?

OODBS enables: complex data (CAD drawings), multimedia, and following objects through time (like tracking a bank account over years).

⚙️ Why OODBS? – real world examples

Ethiopian banks: they need to store customer accounts (objects) with methods like withdraw(), deposit(). In old relational databases, you keep data in tables and code in a separate program. In OODB everything is together.

📌 Simple example – object representation:

Student object (ID: S1001)
-------------------------------------
| name    = "Azeb Hailu"          |
| id      = "DB001/24"            |
| courses = {"DB", "Java"}        |
|                                  |
| methods:                         |
|   enroll(course)                |
|   getGPA()                      |
-------------------------------------

You see? The object contains both data and operations.

🔑 Object Identity (OID) – the unique fingerprint

Every object in an OODB is given a special ID — the Object Identifier (OID). It is like your national ID (Yenege memeseya) but for the database. It’s system-generated, invisible to you, and never changes even if the object’s data changes.

Properties of OID (from PDF):

Immutable: once created, the OID stays forever.
Unique per object: Even if the object is deleted, its OID is never reused. Never.

OID representation (conceptual)
----------------------------------------
| Object   |  OID (internal)  |  name  |
----------------------------------------
| student1 |  0x7F4B2A001     |  Ali   |
| student2 |  0x7F4B2A002     |  Sara  |
----------------------------------------
Even if you delete student1, OID 0x7F4B2A001 never goes to another object.

There are three ways to identify objects: by value (like primary key in relational), by name (user-given), or built‑in identity (used in OOP). OODBS uses built‑in identity (the OID).

🧠 Exam Tip – Mid & Final: They often ask: “List properties of OID” or “Differentiate OID from primary key.” Primary key can change (if we update a value), but OID never changes. Also OID is internal, primary key is visible.

📝 Practice: OID

Q1: Which of the following is TRUE about OID in OODB?
A) OID can be changed by the user
B) After an object is deleted, its OID may be reused
C) OID is immutable and system‑generated
D) OID is same as primary key

✅ Correct answer: C – OID is immutable, system‑generated and never reused. A and B are false; D is wrong because primary key is value‑based, OID is built‑in identity.

Q2 (Exit exam style): In an object‑oriented database, an object retains its identity even if some or all of the values of variables change. This is due to:
A) Inheritance
B) Object identifier (OID)
C) Encapsulation
D) Type constructor

✅ Correct: B – OID provides a unique immutable identity regardless of state changes.

🧱 Object Structure & Type Constructors

The PDF says: “The state of a complex object may be constructed from other objects using type constructors.” We can think of objects nested like Russian dolls. Every object is a triple (i, c, v) where i = OID, c = type constructor, v = state/value.

🛠️ Three basic constructors:

Atom – basic values: integer, string, boolean.
Tuple – record with named fields (like struct).
Set – collection of objects, no duplicates.

Also list, bag, array …

Constructor	Example (OID, constructor, value)
Atom	(oid101, atom, 25)
Tuple	(oid102, tuple, <name: “Azeb”, age: 22>)
Set	(oid103, set, { oid101, oid104 })

Example: A Department object could be a tuple containing a set of Student objects. This nesting is very powerful.

(oid200, tuple, 
   dept_name: "Computer Science",
   students: (oid201, set, { s1_oid, s2_oid, s3_oid })
)

📦 Encapsulation – hiding the engine

You know when you drive a car, you only use the steering wheel and pedals – you don’t touch the engine directly. That’s encapsulation! In OODB, we hide the internal structure of an object and only expose operations (methods). The user just sends a message, and the object’s method executes.

Signature = method name + parameters. Method = actual code. For example: withdraw(amount) is signature; the implementation (checking balance, updating) is the method.

📘 But for databases, complete encapsulation is too strict. So we divide attributes into visible (can be read directly by queries) and hidden (accessed only via methods).

👁️ Visible vs Hidden example – BankAccount object:

Visible attribute: accountNumber, ownerName
Hidden attribute:  pinCode, transactionLog
Method: validatePin(pin) – uses hidden attributes.

Q3: In OODB, the interface part of each operation is called _________.
A) Method
B) Signature
C) Constructor
D) Encapsulation

✅ Signature (B). Signature defines name & arguments; method is implementation.

🌳 Inheritance & Type Hierarchies

Inheritance is like family: children inherit properties from parents. A subclass (specialised type) gets all attributes and methods of its superclass (general type). Plus it can add its own or override. In OODB, this gives code reuse and a natural hierarchy.

Example from PDF: Animals → Mammals, Fish

        Animal (head, body, feed())
       /      \
   Mammal      Fish
   (four legs, sit())  (swim())

Mammal inherits head, body, feed from Animal, and adds four legs + sit().

Important: If class B is subclass of A, every instance of B is also instance of A. But not every A is a B. So a mammal is always an animal, but an animal might not be a mammal.

Specialization vs Generalization

From PDF: Specialization = defining subclasses from a superclass (top‑down). Generalization = combining subclasses into a superclass (bottom‑up).

Q4: In an OODB, if class Professor is a subclass of class Person, which is TRUE?
A) Person instances are always Professor
B) Professor inherits only methods, not attributes
C) Every Professor is also a Person instance
D) Professor cannot override inherited methods

✅ C. Professor is a subclass, so every Professor object is a Person. A is false (reverse). B false (inherits both). D false – overriding is allowed.

💾 Persistence & Methods

In OODB, objects can be made persistent – they live beyond the program. Methods are stored together. When you retrieve an object, you also get its behaviour. This is how we build active databases.

Constructor	Description	Example value (nested)	OODB usage
Atom	Basic atomic values	25, ‘Beza’, true	simple attributes
Tuple	Named fields, like record	<first:”Meron”, last:”Desta”>	structured object
Set	unordered collection, no duplicates	{ obj1, obj2, obj3 }	many-to-many
List	ordered, allows duplicates	[ x, y, z ]	ordered relationships
Array	indexed collection	array[1..5]	fast positional access

🎓 Mixed practice – exit exam level

Q5: Given the following ODL snippet, which concept is illustrated?
class Employee {...}; class Manager extends Employee {...};
A) Encapsulation
B) Polymorphism
C) Inheritance
D) Object identity

✅ Inheritance (C). ‘extends’ indicates inheritance hierarchy.

Q6: Which type constructor would you use to represent a student’s set of courses (no duplicates, unordered)?
A) List
B) Tuple
C) Set
D) Array

✅ C (Set). Set naturally avoids duplicates and order doesn’t matter.

👩🏫 Let’s test one more: In many OODB systems, we split attributes into visible and hidden. Why? Because database queries sometimes need direct access (e.g., SELECT name FROM …). But sensitive data stays hidden, accessible only through methods.

Q7: If an attribute is hidden, how can external users read it?
A) directly with SQL
B) via predefined operations (methods)
C) by using OID
D) they cannot ever access it

✅ B. Hidden attributes are accessible only through methods (encapsulation).

📌 Quick recap – what we covered today

Object = data + methods, reflects real world.
OID: unique, immutable, never reused.
Object structure: (i, c, v) with constructors (atom, tuple, set…).
Encapsulation: visible + hidden attributes; methods are the interface.
Inheritance: subclass inherits from superclass, supports reusability.

📝 Final words – exam tips

🔸 Differentiate OID from primary key (value‑based).
🔸 Know the three constructors and examples.
🔸 Remember that in OODB, encapsulation is often relaxed for query languages – some attributes are visible.
🔸 For inheritance: be able to draw a hierarchy and explain ‘is‑a’ relationships.

Here is a small type hierarchy from the PDF (animals):

       ┌──────────┐
       │ Animal   │
       │ head,body│
       │ feed()   │
       └────┬─────┘
            │
      ┌─────┴──────┬─────────┐
      │            │         │
┌─────▼─────┐  ┌──▼────┐
│ Mammal    │  │ Fish  │
│ fourLegs  │  │ swim()│
│ sit()     │  └───────┘
└───────────┘

🌟 Ethio Temari – learn freely, succeed together. Share with your friends! 🇪🇹

Advanced Database Systems – Chapter 1 notes. For personal study only.

Advanced Database Systems