Object-oriented DBMSs Chapter 1 Object-oriented DBMSs Chapters 25-27 in Textbook

Overview Relational quick review Why OO? What is an Object? What is an object ID? Classes, subclasses and inheritance UML ODL OQL OODBMS

Relational DBMS Quick Review Data model: ER. Data is stored in tables. Each row is a record. Relationships between tables (PK-FK). Takes SID Student Course CID name year Sem name SID name 424112211 Nora M 424221122 Sara S 424331133 Hala L SID CID year Sem 424112211 CAP364 1425 1 CAP430 1426 2 424331133 CID name CAP364 DB2 CAP430 Security OODBMS

Weaknesses of RDBMS Poor Representation of “Real World” Entities. Poor Support for Integrity and Enterprise Constraints. Homogeneous Data Structure. Limited Operations. Difficulty Handling Recursive Queries. Schema changes are difficult. RDBMSs are poor at navigational access. OODBMS

Why OO? Advanced DB Applications Computer-Aided Design (CAD). Computer-Aided Manufacturing (CAM). Computer-Aided Software Engineering (CASE). Network Management Systems. Office Information Systems (OIS) and Multimedia Systems. Digital Publishing. Geographic Information Systems (GIS). Interactive and Dynamic Web sites. Other applications with complex and interrelated objects and procedural data – Read pages 805-808 in book. OODBMS

What is an OODBMS anyway? OODBMS (Object-oriented DB Management System) is a database with data stored in objects and collections NOT rows and tables. OO Concepts: Abstraction, encapsulation, information hiding. Objects and attributes. Object identity. Methods and messages. Classes, subclasses, superclasses, and inheritance. Overloading. Polymorphism and dynamic binding. OODBMS

OODBMS OODBMS Traditional DBS Persistence Sharing Transactions Concurrency Control Recovery Control Security Integrity Querying Semantic Data Model Generalization Aggregation OOPS OID Encapsulation Inheritance Types & Classes Methods Complex objects Polymorphism Extensibility Special Requirements Versioning Schema Evolution OODBMS OODBMS

Object Uniquely identifiable entity that contains both the attributes that describe the state of a real-world object and the actions associated with it. Object encapsulates both state and behavior; an entity only models state. Persistent objects vs. transient objects. Everything in an OODBMS is an object. OODBMS

Object Identity (OID) Object identifier (OID) assigned to object when it is created that is: System-generated. Unique to that object. Invariant. Independent of the values of its attributes (that is, its state). Invisible to the user (ideally). OODBMS

OID Alternative 1 In RDBMS, object identity is value-based: primary key is used to provide uniqueness. Why not use primary key in OODBMS? Primary keys do not provide type of object identity required in OO systems: key only unique within a relation, not across entire system; key generally chosen from attributes of relation, making it dependent on object state (simulated key). OODBMS

OID Alternative 2 In OO programming languages, use variable names and pointers/virtual memory addresses, which also compromise object identity. In OOPL, OID is physical address in process memory space, which is too small - scalability requires that OIDs be valid across storage volumes, possibly across different computers. Further, when object is deleted, memory is reused, which may cause problems. OODBMS

OID Advantages They are efficient. They are fast. They cannot be modified by the user. They are independent of content. Identical objects vs. equal objects OODBMS

Encapsulation Object Attributes Method 1 Method 2 Method 4 Method 3 OODBMS

Class and Object (Instance) BranchNo = B005 Street = 22 Deer Rd City = London Postcode = SW1 4EH BRANCH Attributes branchNo street city postcode BranchNo = B007 Street = 16 Argyll St City = Aberdeen Postcode = AB2 3SU Methods print() getPostCode() numberOfStaff() BranchNo = B003 Street = 163 Main St City = Glasgow Postcode = G11 9QX OODBMS

Subclasses, Superclasses and Inheritance Inheritance allows one class of objects to be defined as a special case of a more general class. Special cases are subclasses and more general cases are superclasses. Process of forming a superclass is generalization; forming a subclass is specialization. Subclass inherits all properties of its superclass and can define its own unique properties. Subclass can redefine inherited methods (override). All instances of subclass are also instances of superclass. OODBMS

Single Inheritance PERSON STAFF MANAGER SALES STAFF OODBMS

Complex Objects A Complex object is something that can be viewed as a single thing in the real world but it actually consists of many sub-objects. 2 Types: Unstructured. Their structure hard to determine. Requires a large amount of storage. BLOB (Binary Large Objects): images & long test strings. Structured. Clear structure. Sub-objects in a part-of relationship. Will talk more about in next slide. OODBMS

Structured Complex Objects An object that consists of sub-objects but is viewed as a single object. Objects participate in a A-PART-OF (APO) relationship. Contained object can be encapsulated within complex object, accessed by complex object’s methods. Or have its own independent existence, and only an OID is stored in complex object. M1 M3 M2 M4 Obj 2 Obj 1 M1 M3 M2 M4 Obj 1 OID 2 M1 M3 M2 M4 Obj 3 OID 2 Obj 2 OODBMS

Commercial OODBMs GemStone from Gemstone Systems Inc., Itasca from Ibex Knowledge Systems SA, Objectivity/DB from Objectivity Inc., ObjectStore from eXcelon Corp., Ontos from Ontos Inc., Poet from Poet Software Corp., Jasmine from Computer Associates/Fujitsu, Versant from Versant Object Technology. OODBMS

Components of OODBMS Object Model (OM): abstract modeling of objects and relationships. Unified Modeling Language (UML): used to describe OM. Object Definition Language (ODL): language to specify the schema for an OODBMS. Object Query Language (OQL): Language to query an OODBMS. C++, Smalltalk, and Java Language Binding. OODBMS

Object Model -- Collections Contains a number of unnamed, homogeneous elements; each can be instance of atomic type, another collection, or a literal type. Types of Constructors: Set: unordered collection of objects without duplicates. Bag: unordered collection of objects that allows duplicates. List: ordered collection of objects that allows duplicates. Array: ordered collection of objects without duplicates. Dictionary: unordered sequence of key-value pairs without duplicate keys. OODBMS

OM – Object Relationships A relationship between 2 objects can be: One-to-One One-to-Many Many-to-Many UML (Unified Modeling Language) is used to model objects and object relationships. OODBMS

UML Example PERSON STAFF POWNER CLIENT BRANCH MANAGER SALESTAFF Name FName LName STAFF StaffNo position DOB salary POWNER OwnerNo address CLIENT ClientNo telNO prefType MaxRent MANAGER SALESTAFF BRANCH PROPERTY PropertyNo rooms rent BranchNo Manages WorksAt Offers Views Owns 1 OwnedBy N ViewedBy M M M 1 M Has 1 1 1 ManagedBy IsOfferedBy OODBMS

Object Definition Language -- ODL module DreamHome Class Branch (extent branchOffices key branchNo) { attribute string branchNo; attribute struct BranchAddress {string street, string city, string postcode} address; relationship Manager ManagedBy inverse Manager::Manages; relationship set<SalesStaff> Has inverse SalesStaff:WorksAt; relationship set<PropertyForRent> Offers inverse PropertyForRent::IsOfferedBy; void takeOnPropertyForRent(in string propertyNo) raises(propertyAlreadyForRent); }; OODBMS

ODL class Person { attribute struct Pname {string fName, string lName} name; }; Class Staff extends Person (extent staff key staffNo) { attribute staffNo; attribute enum SexType {M, F} sex;; attribute date DOB; short getAge(); Void increaseSalary(in float increment); class Manager extends Staff (extent managers) relationship Branch Manages inverse Branch::ManagedBy; OODBMS

Object Query Language -- OQL A Query language for OODBMS. OQL can be used for both associative and navigational access: Associative query returns collection of objects (like SQL). Navigational query accesses individual objects and object relationships used to navigate from one object to another. OODBMS

OQL SELECT [DISTINCT] <expression> FROM <fromList> [WHERE <expression>] [GROUP BY <attribute1: expression1, attribute2, expression2, ..>] [HAVING <predicate>] [ORDER BY <expression>] OODBMS

OQL vs. SQL: A Simple Example Query: List the names of the children of employees working in the sales department. OQL SQL select c.fname, c.lname from Depts d, d.employs e, e.hasChildren c where d.name = “Sales” select c.fname, c.lname from Depts d, Employee e, Children c where d.name = “Sales” and d.deptID = e.deptID and c.parentID = e.empID OODBMS

OQL: Extents Find all branches in London: SELECT b.branchNo FROM branchOffices b WHERE b.address.city = “London”; This returns a type bag<string> but since branchNo is unique  set<string>. OODBMS

OQL: Traversal Paths Find the salaries of sales staff who work at the branches in London SELECT DISTINCT s.salary FROM BranchOffices b, b.WorksAt s WHERE b.address.city = “London”; This returns set<float>. OODBMS

OQL: Using Structures Get structured set containing name, sex, and age for all staff who live in London: SELECT struct (lName:s.name.lName, sex:s.sex, age:s.getAge()) FROM s IN Staff WHERE s.WorksAt.address.city = “London”; This returns bag<struct>. OODBMS

OQL: Order By Get structured set containing name, sex, and age for all staff who live in London ordered by their salaries: SELECT struct (lName:s.name.lName, sex:s.sex, age:s.getAge()) FROM s IN Staff WHERE s.WorksAt.address.city = “London” ORDER BY s.salary; This returns a type list<struct>. OODBMS

OQL: Aggregates How many staff work in branch number 003? 2 ways to query SELECT COUNT(s) FROM s IN salesStaff WHERE s.WorksAt.branchNo = “B003”; COUNT(SELECT s FROM s IN salesStaff WHERE s.WorksAt.branchNo = “B003”); Return staff who work in branches with more than 10 employees SELECT s FROM s IN salesStaff WHERE COUNT(s.WorksAt) > 10; COUNT can be used in any part of the OQL OODBMS

OQL: Creating Objects A type name constructor is used to create an object with identity: Manager(staffNo: “SL21”, fName: “John”, lName: “White”, address: “19 Taylor St, London”, position: “Manager”, sex: “M”, DOB: date“1945-10-01”, salary: 30000) OODBMS