1 / 37

Object-Oriented Databases

Object-Oriented Databases. Dr. Awad Khalil Computer Science Department AUC. Content. Object-Orientation Advanced Database Applications Relational Data Model (Pros & Cons) Object-Oriented Concepts. Object-Orientation.

Télécharger la présentation

Object-Oriented Databases

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-OrientedDatabases Dr. Awad Khalil Computer Science Department AUC Object_Oriented Databases, by Dr. Khalil

  2. Content • Object-Orientation • Advanced Database Applications • Relational Data Model (Pros & Cons) • Object-Oriented Concepts Object_Oriented Databases, by Dr. Khalil

  3. Object-Orientation • Object-Orientation is an approach to software construction that shows considerable promise for solving some of the classic problems of software development. • The basic concept behind object technology is that all software should be constructed out of standard, reusable components wherever possible. • Traditionally, software engineering and database management have existed as separate disciplines. • Database technology has concentrated on the static aspects of information storage, while software engineering has modeled the dynamic aspects of software. • With the arrival of the third generation of DBMSs, namely Object-Oriented DBMSs (OODBMSs) and Object-Relational DBMSs (ORDBMSs), the two disciplines have been combined to allow the concurrent modeling of both data and the processes acting upon the data. • However, there is currently significant dispute regarding this next generation of DBMSs. • The success of relational systems in the past two decades is evident, and the traditionalists believe that it is sufficient to extend the relational model with additional (object-oriented) capabilities. Others believe that underlying relational model is inadequate to handle complex applications, such as CAD, CASE, and GIS. Object_Oriented Databases, by Dr. Khalil

  4. Advanced Database Applications • The90s have seen significant changes in the computer industry. • In database systems, we have seen the widespread acceptance of RDBMs for traditional business applications, such as order processing, inventory control, banking, and airline reservations. • However, existing RDBMSs have proven inadequate for applications whose needs are quite different from those of traditional business databases applications. These applications include: • Computer-Aided Design (CAD). • Computer-Aided Manufacturing (CAM). • Computer-Aided Software Engineering (CASE). • Office Information Systems (OIS) and Multimedia Systems. • Digital Publishing. • Geographic Information Systems (GIS). • Interactive and dynamic Web sites. • Scientific and Medical Applications • Expert Systems Object_Oriented Databases, by Dr. Khalil

  5. Pros Strong theoretical foundation, based on first-order predicate logic Simplicity Suitability for Online Transaction Processing (OLTP) Support of Data-independence Cons Poor representation of “real world” entities Semantic overloading Poor support for integrity and enterprise constraints Homogenous data structure Limited operations Difficulty handling recursive queries Impedance mismatch Other problems associated with concurrency, schema changes, and poor navigational access Relational Data Model Object_Oriented Databases, by Dr. Khalil

  6. DBMS Generations Object_Oriented Databases, by Dr. Khalil

  7. Semantic Data Models • RDBMSs have their failings, particularly their limited modeling capabilities. • There has been much research attempting to address this problem. • In 1976, Chen presented the Entity-Relationship model that is now a widely accepted technique for database design. • In 1979, Codd himself attempted to address some of the failings in his original work with an extended version of the relational model (RM/T and RM/V2). • The attempt to provide a data model that represents the “real world” more closely have been loosely classified as semantic data modeling. Some of the more famous models are: • The Semantic Data Model (Hammer and Mcleod, 1981); • The Functional Data Model (Shipman, 1981); • The Semantic Association Model (Su, 1983). Object_Oriented Databases, by Dr. Khalil

  8. The relational model has been extended to support advanced database applications. SQL2 has been extended to support object-oriented features (SQL3). Object-Relational DBMSs Object_Oriented Databases, by Dr. Khalil

  9. Object-Oriented Concepts • Abstraction – the process of identifying the essential aspects of an entity and ignoring the unimportant properties. There are two fundamental aspects of abstraction: • Encapsulation – means that an object contains both the data structure and the set of operations that can be used to manipulate it. • Information hiding – means that we separate the external aspects of an object from its internal details, which are hidden from the outside world. • Modularization – An object is a ‘black box’ that can be constructed and modified independently of the rest of the system, provided the external interface is not changed. Object_Oriented Databases, by Dr. Khalil

  10. Object-Oriented Concepts • There are two views of encapsulation: • The object-oriented programming language (OOPL) - encapsulation is achievedthrough Abstract Data Types (ADTs). In this view an object has an interface part and an implementation part. The interface provides a specification of the operations that can be performed on the object; the implementation part consists of the data structure for the ADT and the functions that realize the interface. Only the interface part is visible to other objects or users. • The database approach – proper encapsulation is achieved by ensuring that programmers have access only to interface part. In this way, encapsulation provides a form of logical data independence: we can change the internal implementation of an ADT without changing any of the applications using that ADT. Object_Oriented Databases, by Dr. Khalil

  11. Objects and Attributes • Object – A uniquely identifiable entity that contains both the attributes that describe the state of a ‘real world’ object and the actions that are associated with it. • Attributes (instance variables) – describe the current state of an object. • A simple attribute – can be primitive type such as integer, string, real, and so on. • A complex attribute – can contain collections and/or references. For example, the attribute SalesStaff is a collection of staff objects. A reference attribute represents a relationship between objects and contains a value, or collection of values, which are themselves objects (for example, SalesStaff is, more precisely, a collection of references to Staff objects). An object that contains oneor more complex attributes is called a complex object. Object_Oriented Databases, by Dr. Khalil

  12. Object Identity • A key part of the definition of an object is unique identity. • In an object-oriented system, each object is assigned an Object Identifier (OID) when it is created that is: • System-generated; • Unique to that object; • Invariant, in the sense that it cannot be altered during its lifetime. Once the object is created, this OID will not be reused for any other object, even after the object has been deleted. • Independent of the values of its attributes (that is, its state). Two objects could have the same state but would have different identities; • Invisible to the user. Object_Oriented Databases, by Dr. Khalil

  13. OIDs • Advantages: • They are efficient • They are fast • They cannot be modified by the user • They are independent of content • Important issues: • Two objects can appear to be the same to the user, yet have different OIDs and so different objects. If the OIDs are invisible, how does the user distinguish between these two objects? The primary keys are still required!! • Two objects are identical (equivalent) if and if they are the same object (denoted by ‘=‘), that is their OIDs are the same. • Two objects are equal if their states are the same (denoted by ‘==‘) Objects have shallow equality if their states contain the same values when we exclude references to other objects. Objects have deep equality if their states contain the same values and if related objects also contain the same values. Object_Oriented Databases, by Dr. Khalil

  14. Methods and Messages • An object encapsulates both data and functions into a self-contained package. • In object technology, functions are usually called methods. • Methods define the behavior of the object. • Methods can be used to change the object’s state by modifying its attribute values, or to query the values of selected attributes. • A method consists of a name and a body that performs the behavior. • The body consists of a block of code that carries out the required functionality. • Messages are the means by which objects communicate. A message is simply a request from one object (the sender) to another object (the receiver) asking the second object to execute one of its methods Object_Oriented Databases, by Dr. Khalil

  15. Classes, Subclasses, Superclasses, and Inheritance • Classes are blueprints for defining a set of similar objects. • The objects in a class are called instances of the class. Each instance has its own value(s) for each attribute, but shares the same attribute names and methods with other instances of the class. • Inheritance allows one class to be defined as a special case of a more general class. • These special cases are known as subclasses and the more general cases are known as superclasses. • The process of forming a superclass is referred to as generalization and the process of forming a subclass is specialization. • By default, a subclass inherits all the properties of its superclass(es), and additionally defines its own unique properties. Object_Oriented Databases, by Dr. Khalil

  16. Single Inheritance Multiple Inheritance Inheritance Object_Oriented Databases, by Dr. Khalil

  17. Repeated Inheritance Selective Inheritance Allows a subclass to inherit a limited number of properties from the superclass Inheritance Object_Oriented Databases, by Dr. Khalil

  18. Overriding and Overloading • Overriding – the possibility to redefine a property or a method in a subclass. • Example: We might define a method in the staff class to increment salary based on a commission: Method void givecommission(float branchProfit) { salary = salary + 0.02 * branchProfit; } -------------------------------------------------------------------------------- Thismethod can be redefined (overridden) in the manager subclass: Method void givecommission(float branchProfit) { salary = salary + 0.05 * branchProfit; } Object_Oriented Databases, by Dr. Khalil

  19. Overriding and Overloading • Overloading – allows the name of a method to be reused within a class definition or across class definitions. This means that a single message can perform different functions depending on which object receives it and what parameters are passed to the method. Object_Oriented Databases, by Dr. Khalil

  20. Polymorphism • There are three types of polymorphism (from the Greek meaning: “having many forms”): • Operation – overloading is an example of an operation ( or ad hoc) polymorphism. • Inclusion – such as a method defined in a superclass and inherited in its subclasses. • Parametric - uses types as parameters in generic type, or class declarations. Object_Oriented Databases, by Dr. Khalil

  21. Complex Objects • A complex object is an item that is viewed as a single object in the “real world” but combines with other objects in a set of complex A-PART-OF relationships (APO). • The objects contained may themselves be complex objects, resulting in a n A-PART-OF hierarchy. • A contained object can be handled in one of two ways: • First, it be encapsulated within the complex object, and thus forms part of the complex object. • Second, it can be considered to have an independent existence from the complex object. In this case, the object is not stored directly in the parent object but only its OID (referential sharing). • Complex objects are classified as: • Structured complex objects - such as the types we discussed just before. • Unstructured complex object – whose structure can be interpreted only by the application program. In the database context, unstructured complex objects are sometimes known as Binary Large Objects (BLOBs). Object_Oriented Databases, by Dr. Khalil

  22. Storing Objects in Relational Databases • One approach to achieving persistence with the object-oriented programming language, such as C++, or Java, is to use an RDBMS as the underlying storage engine. • This requires mapping class instances (objects) to one or more tuples distributed over one or more relations. • To handle this type of class hierarchy, we have two basic tasks to perform: • Design the relations to represent the class hierarchy • Design how objects will be accessed. Object_Oriented Databases, by Dr. Khalil

  23. Mapping Classes to Relations Map each class or subclass to a relation Staff (staffNo, fName, lName, position, sex, DOB, salary) Manager (staffNo, bonus, mgrStartDate) SalesPersonnel (staffNo, salesArea, carAllownce) Secretary (staffNo, typingSpeed) • With this relational schema we have lost semantic information: it is no longer clear which relation represents the superclass and which relations represent the subclasses. Object_Oriented Databases, by Dr. Khalil

  24. Mapping Classes to Relations • Map each subclass to a relation Manager (staffNo, fName, lName, position, sex, DOB, salary, bonus, mgrStartDate) SalesPersonnel (staffNo, fName, lName, position, sex, DOB, salary, salesArea, carAllownce) Secretary (staffNo, fName, lName, position, sex, DOB, salary, typingSpeed) • Again we lost semantic information in this mapping: it is no longer clear that these relations are subclasses of a single generic class. Object_Oriented Databases, by Dr. Khalil

  25. Mapping Classes to Relations • Map the hierarchy to a single a relation Staff (staffNo, fName, lName, position, sex, DOB, salary, bonus, mgrStartDate, salesArea, carAllownce, typingSpeed, typeFlag) • Again we lost semantic information in this mapping. Further, this mapping will produce an unwanted number of nulls for attributes that don’t apply to that tuple. Object_Oriented Databases, by Dr. Khalil

  26. Object Structure (ODMG MODEL) • In OO database systems, the values (or states) of complex objects may be constructed from other objects by using certain type constructors. • One way of representing an objects is to view each object as a triple (i, c, v), where: i : is a unique object identifier (OID). c : is a constructor (that is, an indication of how the object value is constructed). v : is the object value (or state). Object_Oriented Databases, by Dr. Khalil

  27. Object Structure (Cont’d) • There are the following types of constructors: • Basic constructors: atom, tuple, set. • Other constructors: list, array, bag. • The common constructor: domain D, that contains all basic atomic values that are directly available in the system. These typically include integers, real numbers, character strings, Booleans, dates, and any other data types that the system supports directly. Object_Oriented Databases, by Dr. Khalil

  28. Object Structure (Cont’d) • An object value v is interpreted on the basis of the value of the constructor c in the triple (i, c, v): • If c = atom, then the value v is an atomic value from the domain D of basic values supported by the system. • If c = set, the value v is a set of object identifiers {i1, i2, ..., in}, which are the identifiers (OIDs) for a set of objects that are typically of the same type. • If c = tuple, the value v is a tuple of the form < a1:i1, a2:i2, ..., an:in>, where each aj is an attribute name (sometimes called an instance variable name) and each ij is an object identifier (OID). • If c = list, the value v is an ordered list of object identifiers [i1, i2, ..., in] of the same type. • If c = array, the value v is an array of object identifiers. Object_Oriented Databases, by Dr. Khalil

  29. Object Structure – An Example • We assume, for the following examples, that everything is an object, including basic values. • We assume that we have the constructors atom, set, and tuple. • We use i1, i2, i3, ... to stand for unique system-generated object identifiers. • An object is defined by a triple: (OID, type constructor, value). Object_Oriented Databases, by Dr. Khalil

  30. Object Structure – An Example Object_Oriented Databases, by Dr. Khalil

  31. Object Structure – An Example Consider the following objects: O1 = (i1, atom, Houston)   O2 = (i2, atom, Bellaire)   O3 = (i3, atom, Sugarland)   O4 = (i4, atom, 5)   O5 = (i5, atom, Research)   O6 = (i6, atom, 22-MAY-78) O7 = (i7, set, {i1, i2, i3}) O8 = (i8, tuple, <DNAME:i5, DNUMBER:i4, MGR:i9, LOCATIONS:i7, EMPLOYEES:i10, PROJECTS:i11>) O9 = (i9, tuple, <MANAGER:i12, MANAGERSTARTDATE:i6>) O10 = (i10, set, {i12, i13, i14})   O11 = (i11, set, {i15, i16, i17}) Object_Oriented Databases, by Dr. Khalil

  32. Graphical Representation Object_Oriented Databases, by Dr. Khalil

  33. Useful References http://jdocentral.com/ http://www.fastobjects.com/ Object_Oriented Databases, by Dr. Khalil

  34. Useful References Object_Oriented Databases, by Dr. Khalil

  35. Object_Oriented Databases, by Dr. Khalil

  36. Object_Oriented Databases, by Dr. Khalil

  37. Thank you Object_Oriented Databases, by Dr. Khalil

More Related