1 / 68

Object oriented DataBase

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

oswald
Télécharger la présentation

Object oriented DataBase

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Object oriented DataBase CS157B Lecture 24 Prof. Sin-Min Lee Department of Computer Science

  2. 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

  3. 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.

  4. 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

  5. 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

  6. Objects • Data and procedures bound together form an Object • Data is no longer passive • The object can act on itself (recursive)

  7. OOP Terminology • Object Identity (OID) • Attributes (Instance variables) • Object State • Messages and Methods • Encapsulated Structure • The ability to hide the object’s internal details

  8. 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

  9. OOP Terminology • Superclasses • Subclasses • Inheritance • Single • Multiple

  10. 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

  11. Object Classification • Simple object • Composite object • Compound object • Hybrid object • Associative object

  12. OOP Example

  13. 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

  14. 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

  15. SuperClass PERSON Employee Student Subclasses

  16. 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

  17. Representing M:M Relationships Manufacturer Code Name Address Contact: Item Code Description Quantity Unit_Price Manufacturers: Person 1 Items: Manufacturer M Item M

  18. 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. ‘

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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)

  24. 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

  25. 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

  26. 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)

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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)

  32. 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

  33. 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

  34. 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

  35. 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

  36. 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

  37. 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

  38. 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

  39. 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

  40. 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

  41. 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

  42. 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

  43. 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

  44. 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

More Related