79:T47e,The relational model revolutionized database management by providing a clean, mathematical foundation for data storage and retrieval. Tables, rows, and columns—combined with SQL—became the dominant paradigm for decades. But as software engineering evolved, a fundamental tension emerged: **the impedance mismatch** between how programmers think about data and how databases store it. Programmers working in object-oriented languages like Java, C++, or Python naturally think in terms of **objects**—self-contained entities that bundle data (attributes) with behavior (methods). A `Customer` isn't just a row of values; it's an entity that can `placeOrder()`, `updateAddress()`, or `calculateLoyaltyPoints()`. The relational model, with its flat tables and value-based relationships, struggles to represent this richness directly. The **Object-Oriented Database Model (OODM)** emerged to address this mismatch. Rather than forcing programmers to translate between their mental model and the database's storage model, OODM stores objects directly—preserving their identity, structure, and behavior exactly as they exist in application memory.7a:T433,Object Identity (OID) is perhaps the most fundamental departure from relational thinking. In the relational model, entities are identified by their key values—a customer is identified by `customer_id = 12345`. If you need to reference that customer from another table, you copy this value as a foreign key. This approach has consequences: - **Key values can change** — What happens when a company restructures and renumbers all customer IDs? - **Keys are domain-dependent** — Different applications choose different keys for the same real-world entity - **References are indirect** — Following a foreign key requires a lookup operation Object Identity eliminates these issues by introducing a **system-managed, immutable identifier** that: 1. Is assigned automatically when the object is created 2. Never changes throughout the object's lifetime 3. Remains unique across the entire database (often globally unique) 4. Is completely independent of the object's attribute values 5. Does not require any lookup—it directly addresses the object in memory or storage7b:T4b0,// Class definition in Object Definition Language (ODL) style class Employee { // Attributes define state structure attribute string employeeId; attribute string firstName; attribute string lastName; attribute Date hireDate; attribute float salary; // Complex attribute: embedded object attribute Address homeAddress; // Collection attribute: set of project references relationship Set assignedProjects inverse Project::teamMembers; // Reference to another object relationship Department department inverse Department::employees; // Derived attribute: computed from other data attribute int yearsOfService = (currentDate - hireDate).years; // Methods define behavior void promote(float raisePercent) { this.salary = this.salary * (1 + raisePercent/100); } void assignToProject(Project p) { this.assignedProjects.add(p); p.teamMembers.add(this); } float calculateBonus() { return this.salary * 0.10 * this.yearsOfService; } // Constraints constraint salary > 0; constraint hireDate <= currentDate; }7c:T54b,// Bidirectional relationship with inverse specification class Department { attribute string name; attribute string building; // One-to-many: department has many employees relationship Set employees inverse Employee::department; // One-to-one: department has one manager relationship Employee manager inverse Employee::managedDepartment; } class Employee { attribute string name; attribute float salary; // Many-to-one: employee belongs to one department relationship Department department inverse Department::employees; // One-to-one inverse (optional - not all employees manage) relationship Department managedDepartment inverse Department::manager; // Many-to-many: employee works on many projects relationship Set projects inverse Project::team; } class Project { attribute string title; attribute Date deadline; // Many-to-many inverse relationship Set team inverse Employee::projects; } // Usage: Navigation is direct Employee emp = getEmployeeByName("Alice"); Department dept = emp.department; // Direct traversal, no join Set projects = emp.projects; // Direct access to collection String building = emp.department.building; // Chained navigation7d:T4bc,-- Relational Schema for Library CREATE TABLE Author ( author_id INT PRIMARY KEY, name VARCHAR(100), birth_date DATE, nationality VARCHAR(50) ); CREATE TABLE Book ( book_id INT PRIMARY KEY, title VARCHAR(200), isbn VARCHAR(13), publication_year INT, page_count INT ); -- Junction table for M:N relationship CREATE TABLE Book_Author ( book_id INT REFERENCES Book(book_id), author_id INT REFERENCES Author(author_id), author_order INT, -- For co-author ordering PRIMARY KEY (book_id, author_id) ); CREATE TABLE Member ( member_id INT PRIMARY KEY, name VARCHAR(100), email VARCHAR(100), join_date DATE ); CREATE TABLE Borrowing ( borrowing_id INT PRIMARY KEY, book_id INT REFERENCES Book(book_id), member_id INT REFERENCES Member(member_id), borrow_date DATE, due_date DATE, return_date DATE ); -- Query: Find all books by an author with borrowing count SELECT b.title, COUNT(br.borrowing_id) as borrow_count FROM Book b JOIN Book_Author ba ON b.book_id = ba.book_id JOIN Author a ON ba.author_id = a.author_id LEFT JOIN Borrowing br ON b.book_id = br.book_id WHERE a.name = 'James Clear' GROUP BY b.book_id, b.title;7e:T697,// Object-Oriented Schema for Library class Author { attribute string name; attribute Date birthDate; attribute string nationality; relationship Set books inverse Book::authors; int getBookCount() { return this.books.size(); } } class Book { attribute string title; attribute string isbn; attribute int publicationYear; attribute int pageCount; relationship List authors // Ordered list inverse Author::books; relationship Set borrowings inverse Borrowing::book; int getBorrowCount() { return this.borrowings.size(); } boolean isAvailable() { return this.borrowings .filter(b -> b.returnDate == null) .isEmpty(); } } class Member { attribute string name; attribute string email; attribute Date joinDate; relationship Set borrowings inverse Borrowing::member; Set getCurrentBooks() { return this.borrowings .filter(b -> b.returnDate == null) .map(b -> b.book); } } class Borrowing { attribute Date borrowDate; attribute Date dueDate; attribute Date returnDate; relationship Book book inverse Book::borrowings; relationship Member member inverse Member::borrowings; boolean isOverdue() { return returnDate == null && currentDate > dueDate; } } // Query: Find all books by an author with borrowing count Author author = findAuthorByName("James Clear"); for (Book book : author.books) { print(book.title + ": " + book.getBorrowCount()); }71:{"json":{"id":"seed_fee4d7fbcb6e48ab366c8bd010790c75","slug":"object-oriented-model","category":"Database Management Systems","topic":"Object-Oriented Model","title":"Object-Oriented Database Model","description":"Master the object-oriented approach to database design. Learn how objects, classes, inheritance, and encapsulation create powerful, flexible data models that bridge the gap between programming languages and persistent storage.","difficulty":"INTERMEDIATE","estimatedMinutes":60,"pages":[{"id":"seed_0bc4dc95c862018cb3ace42df96f0148","title":"Objects and Classes","order":0,"content":[{"id":"opening-context","title":"Rethinking Data Representation","content":[{"data":{"content":"$79"},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand how objects and classes serve as the foundational building blocks of object-oriented databases. You'll grasp object identity versus value equality, the anatomy of database objects, class hierarchies, and why these concepts represent a paradigm shift from relational thinking.","variant":"info"},"type":"callout"}]},{"id":"object-paradigm","title":"The Object Paradigm","content":[{"data":{"content":"An **object** in the database context is a direct analog of an object in object-oriented programming. It is a self-contained unit that encapsulates:\n\n1. **State** — The current values of the object's attributes (data)\n2. **Behavior** — The methods or operations that can be performed on the object\n3. **Identity** — A unique, immutable identifier that distinguishes this object from all others\n\nThis triad—state, behavior, identity—forms the conceptual foundation of object-oriented databases. Each element addresses limitations in the relational model."},"type":"text"},{"data":{"items":["**State (Attributes)** — Unlike relational tuples that are flat and atomic, object state can be arbitrarily complex. An `Employee` object might contain a nested `Address` object, a collection of `Project` references, and computed properties like `yearsOfService`. This complexity is stored directly, not decomposed into normalized tables.","**Behavior (Methods)** — Objects carry their own operations. A `BankAccount` object knows how to `withdraw()`, `deposit()`, and `calculateInterest()`. This co-location of data and behavior eliminates the artificial separation between database storage and application logic.","**Identity (OID)** — Every object possesses a unique Object Identifier (OID) assigned by the database system. This identity is independent of attribute values—two `Person` objects with identical names and addresses remain distinct objects because they have different OIDs."],"title":{"icon":"Target","text":"The Three Pillars of Objects","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"Lightbulb","title":"Identity vs. Equality","content":"This distinction is crucial. In relational databases, two rows are 'the same' if their primary key values match—a **value-based identity**. In object databases, identity is **existence-based**: an object is itself because it exists, not because of what values it holds. This mirrors how we think about real-world entities—you remain you even if you change your name, address, or every measurable attribute.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"object-identity","title":"Object Identity (OID)","content":[{"data":{"content":"$7a"},"type":"text"},{"data":{"rows":[["What identifies an entity","Primary key value(s)","System-assigned OID"],["Can identity change?","Yes (key update)","Never"],["How are references stored?","Copy of key value (FK)","Direct OID reference"],["Reference resolution","Lookup via index","Direct pointer traversal"],["Two entities with same values","Cannot exist (key constraint)","Fully allowed (different OIDs)"],["Cross-database identity","Application-managed","System-guaranteed unique"]],"caption":"Identity Models Compared","headers":["Aspect","Value-Based (Relational)","Object-Based (OODM)"]},"type":"table"},{"data":{"content":"**Implementation of OIDs:**\n\nDifferent OODBMS implementations use different strategies for OID generation:\n\n- **Physical OIDs** — Based on storage location (segment, page, offset). Extremely fast for access but problematic if objects move.\n- **Logical OIDs** — UUID or sequence-based identifiers mapped to physical locations via an indirection table. Allows object relocation without changing identity.\n- **Hybrid approaches** — Combine benefits by using logical OIDs with cached physical hints.\n\nMost modern systems prefer logical OIDs for their flexibility, accepting the minor indirection cost for the ability to reorganize storage without affecting application code."},"type":"text"},{"data":{"fileName":"OID Concepts Illustrated","languages":[{"code":"// In a relational database:\ncustomer_table:\n | customer_id (PK) | name | email |\n |------------------|-----------|-------------------|\n | 1001 | Alice | alice@example.com |\n | 1002 | Bob | bob@example.com |\n\norder_table:\n | order_id | customer_id (FK) | total |\n |----------|------------------|--------|\n | 5001 | 1001 | 250.00 |\n\n// To find Alice's orders: SELECT * FROM order_table WHERE customer_id = 1001\n// This requires an index lookup on customer_id\n\n// In an object-oriented database:\nCustomer object (OID: 0x7F3A2B1C):\n - name: \"Alice\"\n - email: \"alice@example.com\"\n - orders: [direct reference to 0x8D4E5F2A, ...]\n\nOrder object (OID: 0x8D4E5F2A):\n - total: 250.00\n - customer: [direct reference to 0x7F3A2B1C]\n\n// Navigation is instant pointer traversal:\n// alice.orders → immediate access, no lookup\n// order.customer → immediate access, no lookup","label":"Pseudocode","value":"pseudo","language":"pseudo"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"Zap","title":"Performance Implications","content":"Direct OID references enable O(1) navigation between related objects—no indexes, no joins, no hash lookups. For applications that traverse complex object graphs (CAD systems, scientific simulations, AI knowledge bases), this direct navigation can provide orders-of-magnitude performance improvements over relational approaches.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"object-state","title":"Object State and Complex Values","content":[{"data":{"content":"The relational model enforces **First Normal Form (1NF)**: all attribute values must be atomic (indivisible). This constraint, while mathematically elegant, forces artificial decomposition of naturally complex data.\n\nConsider modeling an employee's work history:\n\n**Relational approach:**\n- Create a separate `work_history` table\n- Link via foreign key `employee_id`\n- Normalize further if work history entries have sub-structure\n- Query using JOINs across multiple tables\n\n**Object approach:**\n- Store work history as a **collection attribute** directly in the Employee object\n- Each history entry is itself an object with rich structure\n- Access is direct: `employee.workHistory`\n\nObject-oriented databases support **complex state** through several mechanisms:"},"type":"text"},{"data":{"items":["**Nested Objects** — An object can contain other objects as attribute values. A `Company` object might have a `headquarters` attribute that is itself an `Address` object containing street, city, country, and postal code.","**Collection Attributes** — Sets, lists, bags, arrays, and maps can be stored directly as attribute values. An `Author` object might have `books: Set` containing references to all their published works.","**Multivalued Attributes** — Unlike relational systems where multivalued attributes require separate tables, OODM stores them naturally. A `Person` can have `phoneNumbers: List` directly.","**Derived Attributes** — Computed values defined by methods. An `Employee` object might have a `yearsOfService` attribute computed from `hireDate` and current date, stored or calculated on access.","**Reference Attributes** — Direct pointers to other objects. Unlike foreign keys, these are traversable without lookup. An `Order` has `customer: Customer` that directly references the Customer object."],"title":{"icon":"Sparkles","text":"Complex Value Support in OODM","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"rows":[["Employee with multiple skills","employee table + skill table + employee_skill junction table","Employee.skills: Set"],["Order with line items","order table + order_item table + FK relationships","Order.items: List"],["Person with nested address","person table + address table + FK or denormalized columns","Person.address: Address (embedded object)"],["Document with version history","document table + version table + complex queries","Document.versions: List"],["Graph of related entities","Multiple junction tables + recursive queries","Entity.relatedTo: Set"]],"caption":"Data Complexity: Relational vs Object-Oriented","headers":["Scenario","Relational Representation","Object Representation"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"The Denormalization Trade-off","content":"Complex state in objects resembles denormalization in relational databases—both avoid joins by storing related data together. The key difference: OODM provides principled ways to share objects (via OID references) rather than copying data. This preserves update consistency while enabling direct access.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"classes-templates","title":"Classes as Templates","content":[{"data":{"content":"Just as in object-oriented programming, a **class** in OODM serves as a template or blueprint that defines:\n\n1. **Attributes** — The structure of state that instances will hold\n2. **Methods** — The operations that can be performed on instances\n3. **Constraints** — Rules that all instances must satisfy\n4. **Relationships** — How instances connect to objects of other classes\n\nEvery object in the database is an **instance** of exactly one class. The class defines what the object *can be*; the instance represents what a specific object *actually is*.\n\n**Class as Schema:**\n\nIn relational databases, the schema (table definitions) is separate from the data (rows). In OODM, classes serve a similar schema role—they define structure—but with crucial differences:\n\n- Classes can have behavior (methods), not just structure\n- Classes form inheritance hierarchies (covered in the next page)\n- Class definitions are themselves objects (metaobjects) that can be queried and manipulated"},"type":"text"},{"data":{"fileName":"Class Definition Example","languages":[{"code":"$7b","label":"ODL/Java Style","value":"java","language":"java"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**Class Extent:**\n\nThe **extent** of a class is the set of all current instances of that class in the database. This is analogous to a relational table containing all rows, but with important differences:\n\n- Extent automatically includes instances of subclasses (polymorphic)\n- Extent can be navigated directly without scanning storage\n- Extent membership is managed by the system, not explicit insertion\n\nWhen you create a new object, it automatically becomes part of its class's extent. When you delete an object, it's automatically removed. This automatic extent management simplifies application code."},"type":"text"},{"data":{"icon":"Lightbulb","title":"Classes Are First-Class Objects","content":"In pure OODBMS implementations, class definitions are themselves objects stored in the database. This enables powerful metaprogramming: you can query the schema ('show me all classes with a salary attribute'), dynamically create new classes, or implement schema evolution as data operations rather than DDL commands.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"object-lifecycle","title":"Object Lifecycle","content":[{"data":{"content":"Understanding the lifecycle of database objects is essential for working with OODBMS. Unlike transient programming objects that exist only in memory, database objects have **persistence**—they survive program termination and system restarts.\n\nThe object lifecycle encompasses:"},"type":"text"},{"data":{"type":"ordered","items":["**Creation** — A new object is instantiated from a class. The system assigns a unique OID. The object is added to its class extent. Initial attribute values may be set via constructor or defaults.","**Persistence** — The object is made persistent (stored in the database). In some systems, this is explicit (call `makePersistent()`). In others, reachability-based persistence means objects become persistent when referenced by other persistent objects.","**Access** — Persistent objects are loaded into memory when accessed. The OODBMS manages this transparently—application code works with objects without explicit load/save operations.","**Modification** — Changes to object state are tracked by the system. Depending on the concurrency model, modifications may be buffered, logged, or immediately written.","**Commit/Rollback** — Transaction boundaries determine when modifications become permanent. Commit makes changes durable; rollback reverts to the previous consistent state.","**Deletion** — Objects can be explicitly deleted or garbage-collected when no longer reachable. Deletion removes the object from its class extent and invalidates its OID."],"title":"Object Lifecycle Phases","variant":"accent"},"type":"list"},{"data":{"left":[{"data":{"items":["Objects become persistent when referenced by persistent objects","Mirrors programming language semantics","No explicit persistence calls needed","Natural transitive closure of persistence","Garbage collection can reclaim unreachable objects"],"title":{"icon":"CheckCircle","text":"Persistence by Reachability","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Objects must be explicitly marked persistent","Clearer control over what gets stored","Requires discipline in application code","Risk of orphaned transient objects","More predictable storage behavior"],"title":{"icon":"AlertCircle","text":"Explicit Persistence","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"icon":"Zap","title":"Transparent Persistence","content":"The ideal OODBMS provides **transparent persistence**: application code operates on objects without awareness of whether they're in memory or on disk. The system automatically loads objects on access (swizzling) and writes modifications on commit. This transparency dramatically simplifies application development compared to explicit data access layers.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"object-relationships","title":"Object Relationships","content":[{"data":{"content":"Relationships between objects in OODM are fundamentally different from relational foreign keys. While relational systems represent relationships as *value matches* between columns, object databases represent relationships as *direct references* between objects.\n\n**Types of Object Relationships:**"},"type":"text"},{"data":{"rows":[["**Association**","General connection between objects. Can be unidirectional or bidirectional.","Employee *works-in* Department"],["**Aggregation**","Weak 'has-a' relationship. Component can exist independently.","Department *has* Employees"],["**Composition**","Strong 'contains' relationship. Component cannot exist without container.","Order *contains* OrderItems"],["**Dependency**","One object uses another without ownership.","ReportGenerator *uses* DataSource"]],"caption":"Object Relationship Types","headers":["Relationship Type","Description","Example"]},"type":"table"},{"data":{"content":"**Relationship Cardinality:**\n\nLike relational models, object relationships have cardinality constraints:\n\n- **One-to-One (1:1)** — Each object relates to at most one other object. Example: Employee *has* one EmployeeBadge.\n- **One-to-Many (1:N)** — One object relates to multiple objects. Example: Department *has* many Employees.\n- **Many-to-Many (M:N)** — Multiple objects on both sides. Example: Students *enroll-in* Courses.\n\nUnlike relational systems that require junction tables for M:N relationships, OODM handles them naturally through collection-valued attributes on both sides."},"type":"text"},{"data":{"fileName":"Relationship Modeling","languages":[{"code":"$7c","label":"ODL","value":"odl","language":"pseudo"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"Referential Integrity in OODM","content":"When relationships are declared bidirectional with inverse specifications, the OODBMS automatically maintains referential integrity. Adding an employee to a department's employees set automatically sets the employee's department reference—and vice versa. This eliminates a major source of application bugs and data inconsistency.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"comparing-models","title":"Comparing Relational and Object Models","content":[{"data":{"content":"To solidify understanding, let's directly compare how the same real-world scenario is modeled in relational versus object-oriented approaches.\n\n**Scenario:** A library system tracking books, authors, and borrowing history."},"type":"text"},{"data":{"tabs":[{"id":"relational","label":"Relational Model","content":[{"data":{"languages":[{"code":"$7d","label":"SQL","value":"sql","language":"sql"}],"showLineNumbers":true},"type":"code"}],"titleIcon":"ListIcon"},{"id":"object-oriented","label":"Object Model","content":[{"data":{"languages":[{"code":"$7e","label":"ODL/Java","value":"java","language":"java"}],"showLineNumbers":true},"type":"code"}],"titleIcon":"Sparkles"}]},"type":"tabs"},{"data":{"content":"**Key observations:**\n\n1. **No junction tables** — The M:N relationship between Books and Authors is handled directly through bidirectional collection references.\n\n2. **Behavior with data** — Methods like `isAvailable()`, `isOverdue()`, and `getBorrowCount()` live with their data, rather than in application code far from the schema.\n\n3. **Navigation vs. joins** — The object model navigates directly (`author.books`), while relational requires joins across multiple tables.\n\n4. **Natural collections** — Ordered lists (`List` for co-author ordering) are first-class features, not implemented via extra columns.\n\n5. **Query simplicity** — Complex relational queries with GROUP BY become simple method calls on objects."},"type":"text"}],"titleType":"number","titleNumber":7},{"id":"summary-path-forward","title":"Summary: Objects and Classes","content":[{"data":{"content":"We've established the foundational concepts of object-oriented databases. Let's consolidate the key insights:"},"type":"text"},{"data":{"type":"ordered","items":["**Objects are the fundamental unit** — Combining state (attributes), behavior (methods), and identity (OID) into self-contained entities.","**Object Identity is existence-based** — OIDs are system-managed, immutable, and independent of attribute values—unlike relational keys.","**Complex state is natural** — Nested objects, collections, and references are first-class features, not requiring normalization workarounds.","**Classes serve as templates** — Defining structure, behavior, constraints, and relationships for all instances.","**Objects have managed lifecycles** — Creation, persistence, access, modification, and deletion are handled transparently.","**Relationships are direct references** — Navigation between objects is pointer traversal, not foreign key lookups.","**The paradigm addresses impedance mismatch** — Object databases store data the way programmers think about it."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nNow that we understand objects and classes, the next page explores **inheritance**—how class hierarchies enable code and structure reuse, polymorphism, and sophisticated type systems that dramatically reduce redundancy in complex domain models."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the fundamental building blocks of object-oriented databases. Objects and classes provide a richer, more natural representation of complex data than flat relational tables—at the cost of some mathematical elegance. Next, we'll see how inheritance extends this power.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_b2df5729c482c102ff2628dca5e45725","title":"Inheritance","order":1,"content":null,"isLocked":true},{"id":"seed_b5f7167f474db88c8f810e835e6103b4","title":"Encapsulation","order":2,"content":null,"isLocked":true},{"id":"seed_9e7201a4d407b7e7fbd5227af10a46de","title":"Object-Relational Mapping","order":3,"content":null,"isLocked":true},{"id":"seed_efe16537de1685b6d60ebc5e4b18923f","title":"Use Cases","order":4,"content":null,"isLocked":true}]}}