730 likes | 922 Views
Object oriented DataBase. CS157B Lecture 24. Prof. Sin-Min Lee Department of Computer Science. Object Database Systems. Not a new concept – research dates back to the mid-1970s As the technology matured, a number of commercial ODBMSs appeared in the 80s and early 90s
E N D
Object oriented DataBase CS157B Lecture 24 Prof. Sin-Min Lee Department of Computer Science
Object Database Systems • Not a new concept – research dates back to the mid-1970s • As the technology matured, a number of commercial ODBMSs appeared in the 80s and early 90s • To compete with RDBMSs, it became clear that a standard for ODBMSs, analogous to SQL, was needed
Object-Oriented and Multimedia Databases • The object-oriented database (OODB) contains both the text data of traditional databases plus information about the set of actions that can be taken on the data fields. • Many OODBs are multimedia databasesthat include graphics, audio information and animation.
Object Orientation • Modeling and development methodology • A set of design and development principles based on objects • Objects – self-contained, reusable modules that contain data as well as their procedures
OOP – Object oriented Programming • OO concepts in Ada, Algol, LISP, SIMULA • OOPLs – Smalltalk, C++, Java • Provide for – • SW development environment • SW modeling tool • Reduce the amount of code • Reusable code
Objects • Data and procedures bound together form an Object • Data is no longer passive • The object can act on itself (recursive)
OOP Terminology • Object Identity (OID) • Attributes (Instance variables) • Object State • Messages and Methods • Encapsulated Structure • The ability to hide the object’s internal details
OOP Terminology • Object Class • the logical structure of an object (name, attributes, methods) • Object Class Library • a group of object classes • Object • an instance of an object class • Protocol – • collection of messages
OOP Terminology • Superclasses • Subclasses • Inheritance • Single • Multiple
OOP Terminology • Polymorphism • situation in which one name can be used to invoke different functions • Inheritance • automatically assuming the attributes and methods of another object at a higher class
Object Classification • Simple object • Composite object • Compound object • Hybrid object • Associative object
Object Instances PERSON NAME S ADDRESS S DOB S SEX S AGE I Instance variables John Smith 123 Easy St 23-Nov-1970 M 32
Instance VariablesADTs NAME FIRST_NAME S MIDDLE_NAME S LAST_NAME S ADDRESS STREET_NUM S STREET S APARTMENT S CITY S STATE S ZIP I DOB DAY I MONTH I YEAR I
SuperClass PERSON Employee Student Subclasses
Representing 1:M Relationships(Premiere Products Example) Customer SS# Name Address Balance Cred_Lim Sales_Rep Name Address Tot_Comm Com_Rate Customer M Sales_Rep 1
Representing M:M Relationships Manufacturer Code Name Address Contact: Item Code Description Quantity Unit_Price Manufacturers: Person 1 Items: Manufacturer M Item M
Late Binding ‘A desirable characteristic of OO development is its ability to let any object’s attribute contain object that define different data types (or classes) at different times. ‘
Late binding Instance variables OODB Item_Type Inv_Type Description String_of_char Vendor Vendor Weight Weight Price Money Attributes RDBMS Item_Type Numeric Description Char Vendor Numeric Weight Numeric Price Numeric
OODBMS OO Concepts OO data models OOPL GUI Object-Oriented Features OODBMS Data accessibility Persistence Backup and Recovery Transaction Processing Concurrency Security/Integrity Administration Conventional DBMS
13 Rules for an OODBMSfrom the OODBS Manifesto • System must support complex objects • Object identifier must be supported • Objects must be encapsulated • Systems must support types or classes • System must support inheritance • System must avoid premature binding • System must be computationally complete • System must be extensible
Object Database Systems • The vendors formed a consortium, the Object Database Management Group (ODMG), to define a standard • Current standards specification is ODMG 2.0 • Architecture has four major components – a data model, a specification language, a query language, and language bindings
Object Data Model • Based upon the (Object Management Group) OMG Object Model • OMG is another consortium of vendors instituted to create standards • Besides an object model, they oversee standards for UML and CORBA (Common Object Request Broker Architecture)
Object Model • Two basic modeling primitives – objects and literals • An object has a unique identifier • A literal has no identifier • Every object and every literal is categorized by its type – a set of values and a set of supported operations
Object Model • An object’s state is characterized by a set of properties • An object property can be either an attribute or a relationship to another object • The set of operations that can be executed on or by an object defines the behavior of an object
Object Model • An operation may have input and/or output parameters, and may return a value • The type of each parameter and the returned value must be specified • A database stores objects, which can be shared by multiple users and applications • A database is based on a schema, defined in the object definition language (ODL)
Types • There are two facets to the definition of a type – an external specification and one or more implementations • The specification of a type corresponds to what is visible to a user – operations that can be applied to instances, its properties, or state variables, and any exceptions that can be raised by the operations
Types • An implementation of a type defines the internal aspects of the objects of a type – how the operations access or modify the properties of an object • A class definition and an interface definition may specify both the abstract behavior and the abstract state of an object
Types • A literal definition specifies only the abstract state of a literal type • An implementation of an object type consists of a representation and a set of methods • The representation is a data structure realizing the abstract state of an object or literal, expressed in a language binding
Types • Each property is represented by an instance variable • The operations of an object type are implemented as procedures expressed in a language binding • The internal details of an implementation are invisible to the user
Inheritance • Inheritance is a second important characteristic of object orientation • The data model supports two constructs supporting inheritance – interfaces and classes • Interfaces permit the definition of subtypes • A subtype represents the specialization of a more general type (the supertype)
Inheritance • The generalization/specialization relationship is often called an “is-a” relationship • Interfaces are abstract types – they cannot be instantiated • The data model supports multiple inheritance of interfaces
Inheritance • Classes support a second form of inheritance, described as the “extends” relationship • A class can extend the behavior and state of another class • Classes can be instantiated • An object is an instance of a class
Inheritance • Classes support only single inheritance • An interface can inherit from another interface, but not from a class • A class can inherit from multiple interfaces and can extend a single class • Objects have a number of characteristics – identifiers, names, lifetimes, and structures
Identifiers • Unlike the relational model, objects within a database are assigned unique identifiers • An identifier is generated by the database system when the object is created • They are immutable – although the properties of a object may change, its identifier remains the same throughout its lifetime
Names • Object identifiers are commonly used for one object to refer to another • An object may also have a name • Applications typically refer to some objects by a user-defined name • The database internally maps names to identifiers
Lifetimes • The lifetime of an object is specified when it is created • The are two possible lifetimes – persistent and transient • A transient object is allocated memory by an application’s runtime system • A transient object’s lifetime is the lifetime of the procedure or process that creates it
Lifetimes • Persistent objects are allocated memory and secondary storage that is managed by the ODBMS runtime system • A persistent object exists after the process that created it terminates • Persistent objects also called database objects • Object types and lifetimes are independent
Collection Objects • The data model supports a number of container types to store collections of objects • All elements of a collection must be of the same type • Set object – an unordered collection with no duplicates
Collection Objects • Bag object – an unordered collection that may contain duplicate objects • List object – an ordered collection of elements • Array object – another kind of ordered collection of objects • Both lists and arrays are position-oriented
Collection Objects • The insertion and removal operations take argument specifying the position at which the element is to be inserted or deleted • Both collections are zero-based • Removing an element from a list changes the positions of elements in the list tail • Removing an element from an array simply replaces the element with a null value
Modeling an Object’s State • Two kinds of properties – attributes and relationships • An attribute is defined to be of a single type • Its type may be either a literal or a class • Relationships define associations between two types • The data model supports only binary relationships
Modeling an Object’s State • Relationships are defined implicitly by specifying traversal paths • Traversal paths are always declared in pairs • This permits bidirectional traversal from either object in the association • The ODBMS is responsible for maintaining the referential integrity of a relationship
Modeling an Object’s State • The connectivity of a relationship may be one-to-one, one-to-many, or many-to-many • The connectivity is always clear from the syntax of the declaration of a relationship • To represent arbitrary n-ary relationships, a designer would create a new class type, each instance of which would representan n-tuple