1. Object Oriented Data Base

2. Traditional Data Models : Hierarchical, Network (since mid- 60’s), Relational (since 1970 and commercially since 1982) Object Oriented (OO) Data Models since mid-90’s Reasons for creation of Object Oriented Databases Need for more complex applications Need for additional data modeling features Increased use of object-oriented programming languages Commercial OO Database products – several in the 1990’s, but did not make much impact on mainstream data management MAIN CLAIM: OO databases try to maintain a direct correspondence between real-world and database objects so that objects do not lose their integrity and identity and can easily be identified and operated upon Object: Two components: state (value) and behavior (operations).Introduction

3. 3 OODBMS Vendors GemStone Systems, Inc. Hewlett-Packard, Inc. (OpenODB) IBEX Corporation, SA. Illustra (Informix, Inc.) Matisse Software, Inc. O2 Technology, Inc. Objectivity, Inc. Object Design, Inc. ONTOS, Inc. POET Software Corporation UniSQL Unisys Corporation (OSMOS) Versant Object Technology

4. ODMG (Object Data Management Group) Provides a standard model for object databases (Object Model)(Object Model) Supports object definition via ODLODL Supports object querying via OQLOQL Supports a binding with OOL (Three langusges : C++, Java, SMALTALK).a binding with OOL

5. The Object Model of ODMG Objects and Literals The basic building blocks of the object model are – Objects – Literlas An object has four characteristics 1.Identifier: unique system-wide identifier 2.Name: unique within a particular database and/or program; it is optional 3.Lifetime: persistent vs transient 4.Structure: specifies how object is constructed by the type constructor and whether it is an atomic object A literal has a current value but not an identifier Three types of literals 1.atomic: predefined; basic data type values (e.g., short, float, boolean, char ) 2.structured: values that are constructed by type constructors (e.g., date, struct variables) 3.collection: a collection (e.g., array) of values or objects

6. The Object Model of ODMG Interface and Class Definition ODMG supports two concepts for specifying object types Interface & Class Both have behaviors (operations) and state (attributes and relationships) Interface An interface is a specification of the abstract behavior of an object type State properties of an interface (i.e., its attributes and relationships) cannot be inherited from Objects cannot be instantiated from an interface Class A class is a specification of abstract behavior and state of an object type A class is Instantiable Supports “extends” inheritance to allow both state and behavior inheritance among classes Multiple inheritance via “extends” is not allowed

7. Object Definition Language (ODL) ODL supports semantics constructs of ODMG ODL is independent of any programming language ODL is used to create object specification (classes and interfaces) ODL is not used for database manipulation

8. ODMG Interface Definition: ODL Examples interface is ODMG’s keyword for class/type interface Date:Object { enum weekday{sun,mon,tue,wed,thu,fri,sat}; enum Month{jan,feb,mar,…,dec}; unsigned short year(); unsigned short month(); unsigned short day(); … boolean is_equal(in Date other_date); }; enumeration types (Enum),

9. A Very Simple Class ODL Examples A very simple, straightforward class definition class Degree { attribute string college; attribute string degree; attribute string year; };

10. A Class With Key and Extent ODL Examples class Person (extent persons key ssn) { attribute struct Pname {string fname …} name; attribute string ssn; attribute date birthdate; … short age(); }

11. Inheritance via “:” – An Example interface Shape { attribute struct point {…} reference_point; float perimeter (); … }; class Triangle: Shape (extent triangles) { attribute short side_1; attribute short side_2; … };

12. Object Query Language (OQL) OQL is DMG’s query language OQL works closely with programming languages such as C++ Embedded OQL statements return objects that are compatible with the type system of the host language OQL’s syntax is similar to SQL with additional features for objects

13. Simple OQL Queries Basic syntax: select…from…where… SELECT d.name FROM d in departments WHERE d.college = ‘Engineering’; An entry point to the database is needed for each query An extent name (e.g., departments in the above example) may serve as an entry point

14. An Example of OQL View A view to include students in a department who have a minor: define has_minor(dept_name) as select s from s in students where s.minor_in.dname=dept_name has_minor can now be used in queries

15. An Example of an OQL Aggregate Operator To compute the average GPA of all seniors majoring in Business: avg (select s.gpa from s in students where s.class = ‘senior’ and s.majors_in.dname =‘Business’);

16. Binding with OOL Example : C++ Language Binding C++ language binding specifies how ODL constructs are mapped to C++ statements and include: – a C++ class library – a Data Manipulation Language (ODL/OML) – a set of constructs called physical pragmas (to allow programmers some control over the physical storage concerns)

17. Class Library The class library added to C++ for the ODMG standards uses the prefix d_ for class declarations d_Ref is defined for each database class T To utilize ODMG’s collection types, various templates are defined, e.g., d_Object specifies the operations to be inherited by all objects

18. Template Classes A template class is provided for each type of ODMG collections: – d_Set – d_List – d_Bag – d_Varray – d_Dictionary Thus a programmer can declare: d_Set >

19. Data Types of Attributes The data types of ODMG database attributes are also available to the C++ programmers via the d _ prefix, e.g., d_Short, d_Long, d_Float Certain structured literals are also available, e.g., d_Date, d_Time, d_Intreval

20. Object Database Design For several years, entity-relationship diagrams were the predominant model­ing technique for database design. OOD Design used Unified Modeling Language (UML) method, instead of traditional entity-relationship (ER) The basic similarities between ER and class diagrams are – entities (classes) are drawn as boxes – binary relationships (associations) are drawn as connecting lines – n-ary associations (relationships) are drawn as diamonds. The main dif­ferences between UML and ER diagrams occur in the details. In UML the multiplicity of an association is shown as simple numerical notation instead of as a cryptic icon

21. 21 Object Definition--encapsulation. – Object Name – Properties – Methods Customer CustomerID Address Phone AddCustomer DropCustomer Class name Properties Methods Commercial Contact VolumeDiscount ComputeDiscount Government Contact BalanceDue BillLateFees AddCustomer Inheritance Polymorphism Entity:Something in the real world that we wish to describe or track. Class: Description of an entity, that includes its attributes (properties) and behavior (methods). Object:One instance of a class with specific data. Property:A characteristic or descriptor of a class or entity. Method:A function that is performed by the class. Association:A relationship between two or more classes.

22. 22 Class Diagram Class/Entity(box) Association/Relationship – Lines – Minimum 0: optional 1: required – Maximum Arrows 1, M Customer Order Item 1 … 1 0 … * 1 … *..

23. 23 Sample Association Rules (Multiplicity) An order must have exactly 1 customer, – 1 … 1Minimum of 1 – 1 … 1Maximum of 1 And at least one item. – 1 … *Minimum of 1 – 1 … *Maximum many An item can show up on no orders or many orders. – 0 … *Optional (0) – 0 … *Maximum many Customer Sale Item 1 … 1 0 … * 1 … *

24. 24 N-ary Association Example Employee Name... Component CompID Type Name Product ProductID Type Name * ** Assembly EmployeeID CompID ProductID Multiplicity is defined as the number of items that could appear if the other N-1 objects are fixed. Almost always “many.” 1 1 1

25. 25 Association Details: Aggregation Sale SaleDate Employee Item Description Cost * * contains  Aggregation: the Sale consists of a set of Items being sold.

26. 26 Association Details: Composition Bicycle Size Model Type … Wheels Rims Spokes … 12 built from  Composition: aggregation where the components become the new object. Crank ItemID Weight Stem ItemID Weight Size 1 1 1 1 Bicycle Size Model Type … Wheels Crank Stem Two ways to display composition.

27. 27 Association Details: Generalization Animal DateBorn Name Gender Color ListPrice Mammal LitterSize TailLength Claws Fish FreshWater ScaleCondition Spider Venomous Habitat {disjoint}

28. 28 Inheritance Class Definition-- encapsulation – Class Name – Properties – Methods Inheritance Relationships – Generic classes – Focus on differences – Polymorphism – Most existing DBMS do not handle inheritance Accounts AccountID CustomerID DateOpened CurrentBalance OpenAccount CloseAccount Class name Properties Methods Savings Accounts InterestRate PayInterest Checking Accounts MinimumBalance Overdrafts BillOverdraftFees CloseAccount Inheritance Polymorphism

29. 29 Multiple Parents Vehicle Human Powered MotorizedOn-RoadOff-Road CarBicycle or

30. 30 Association Details: Reflexive Relationship Employee manager 0…1 worker *  manages A reflexive relationship is an association from one class back to itself. In this example, an employee can also be a manager of other employees.

31. 31 Computed Attributes Denote computed values with a preceding slash (/). Employee Name DateOfBirth /Age Phone … {Age = Today - DateOfBirth}

32. 32 Objects in a Relational Database CustomerID Address Phone Customer CustomerID Contact VolumeDiscount CommercialCustomer CustomerID Contact BalanceDue GovernmentCustomer Separate inherited classes. Link by primary key. Adding a new customer requires new rows in each table. Definitely need cascade delete.