Object Data Model

A Data Model
• A data model is a logical organization of the
real world objects (entities), constraints on
them, and the relationships among objects.
• A database language is a concrete syntax of
a data model
• A database system implements a data model
 Object Data Model
• A core object-oriented data model consists
of the following basic object-oriented
concepts
• Object and object identifier
– A real world entity is uniformly modeled as
object (associated with unique id: used to
pinpoint an object to retrieve)
 Object Data Model
• Attributes and methods
– every object has a state (the set of values for the
attributes of an object) and a behavior (the set
of methods – program code – which operates
on the state of the object).
– The state and behavior encapsulated in an
object are accessed or invoked from outside the
object only through explicitly message passing.
 Object Data Model
• Class
– a means of grouping all the objects which share
the same set of attributes and methods.
– An object must belong to only one class as an
instance of that class (instance-of relationship).
– A class is similar to an object data type.
– A class may also be primitive (no attributes),
e.g., integer, string, Boolean
 Object Data Model
• Class hierarchy and inheritance
– Derive a new class (subclass) from existing
class (superclass). The subclass inherits all the
attributes and methods of the existing class and
may have additional attributes and methods.
Single inheritance (class hierarchy) vs. multiple
inheritance (class lattice)
 Object oriented data model
• In object oriented, data model represents
data and relationships of a real world
entities in a single structure which is known
as object
• In this model, two or more related objects
are connected through links as shown in the
diagram (next slide)
 Object
Shape
Methods Behavior of an
getArea() object
Properties of getPerimeter()
an object

Circle Rectangle Triangle

Attributes Attributes Attributes
center length base
radius breadth height
 Object Oriented Data Model
• In this model, the key concepts of object
oriented programming languages such as
inheritance, polymorphism, overloading,
encapsulation and information hiding can
easily be represented
 Object Schema: Graphical
Representation of Objects

Shared representation of all objects of a class Person

State of a Person Object Instance
Defining Three Abstract Data
Types
 Class Person with ADTs

Object representation for Instances of the class

Person with Abstract Data Types (ADTs)
Object Schema
Referential Sharing of Objects
Object Schema
Employee Object Representation
 Object Schema
• Inter object relationship: Attribute-Class
link
– A attribute-class or inter-object relationship is
created when an objects attribute references
another object of the same or difference class
– Relationship representation
• Representing 1:M Relationships
• Representing N:M Relationships
Class Hierarchy for Retail
Corporation
 Representing 1:M Relationships
• Related class are enclosed in boxes to make
relationships more noticeable
• The double line on the box’s right side
indicates that the relationship is mandatory
• Connectivity is indicated by labelling each
box
Representing 1:M Relationships
Representing 1:1 and 1:M
Relationships
Employee-Dependent
Relationship
Representing N:M Relationships
 OO DBMS
• ObjectStore
• Versant
• Objectivity/DB
• ObjectDatabase++
• ObjectDB
• GemStone/s
 Object Query Language
• Query language designed to operate on
databases described in ODL
• Is a Data Management Group’s query
language
• Return objects that are compatible with the
types of the system of the host language
• Similar to SQL with additional features for
objects
 Advantages
• Object oriented databases can handle the
different types of data such as, example,
pictures, voice, video, text, numbers etc.
• This model provides code reusability,
enriched real world modeling, improve
reliability and flexibility
• This model incur low maintenance costs
because most of the tasks are encapsulated
in the system
 Disadvantages
• There is no universally defined data model
for an Object Oriented Database
Management Systems (OODBMS)
• It does not provide adequate security
mechanisms
• It makes the system more complex than that
of Relational Database Management
Systems (RDBMSs)
 CORBA
Distributed Object Model
 Object Management Group
(OMG)
• Has more than 750 software vendors,
software developers and end users
• Goal: Improve the development and use of
integrated software systems by supporting
and encouraging modular production of
software, reuse of code, integration and
long-term maintenance
 OMG
• How? By providing a common
architectural framework for object oriented
applications based on widely available
interface specifications
• Benefits
– Portability
– Reuse
– Interoperability
Object Management Architecture
(OMA)
• Focuses on managed objects
– Managed objects are subject to system-wide
administration and control.
– Managed objects are installed, activated and
dynamically controlled
• Managed objects are the primary building
blocks of the OMA object model
– Application objects Domain objects
– Object Services Common Facilities
 OMA Components
• Application Domain-Specific Interfaces
– Non-standardized application-specific
interfaces
• Domain-Specific Interfaces (added in 1996)
– Domain-specific interfaces
– Use for specific application domains, such as
Finance, Healthcare, Manufacturing and
Telecom
 OMA Components
• Common Facility Interfaces
– Interfaces for horizontal end-user-oriented
facilities
– Use across application domains
• Object Services
– General purpose services that provide a
universal application domain-independent,
basis for application interoperability
OMA Canonical View
 Object Request Broker (ORB)
• Provides scalability for a distributed object
application
– Allows an object to call methods on objects
independent of the location of the objects
(location-transparency, location independence)
– Different process or different machine
– Think of Object-Oriented RPC (Remote
Procedure Call) across multiple languages and
multiple platforms
 ORB
• The ORB provides objects services as well
as object facilities
– Primary difference between object services and
object facilities
– Object services interoperate with the ORB
– Object facilities operate mostly with
application and domain objects
– Standardizing ORBs: CORBA (“an instance of
the class ORB”)
 CORBA
• A standard interface for ORB(est. in 1991)
• Defines interfaces, not their implementation
• Abstracts network services and OS services,
making them appear as objects within the
ORB
– Does not hide the network or operating system,
but allows programmers to hide them
• CORBA supports multiple ORBs
 CORBA
• A CORBA object is an interface definition
in the Interface Definition Language (IDL)
• CORBA objects: CORBA services, CORBA
facilities, application objects, domain
objects
 Why CORBA
• How did we integrate distributed
components before CORBA?
– Sockets, Net DDE (Dynamic Data Exchange),
DCOM (Distributed Component Model), DCE
RPC (Distributed Computing Environment
Remote Procedure Call)
• These technologies didn’t address issues:
a) Object-Oriented technologies (Java, C++)
• Sockets, RPC, etc don’t support objects
 Why CORBA
b) Cross-platform, cross-language, multi-vendor
support
• Try writing portable networking code with RPC
• No easy integration with legacy systems
c) There is a need for “Common services”
• Security, transactions, persistence, events
• No need to reinvent these services (Build vs buy)
d) Full location transparency (location
independence)
 Design Goals of CORBA
• Hardware/OS/Network/Language
independence
• Location independence
• Implementation flexibility allows both
– Easy implementations
– Full-strength fast, fault-tolerant, production-
quality implementations
– Developer can decide on quality of components
 CORBA services
• Class management: Abilities to create, delete, modify,
copy, move, distribute, describe class definitions and class
interfaces
• Instance management: Same as class management, minus
“distribute and describe”, plus: “invocation”
• Storage: Persistency for all sizes of objects, including
attributes and operations
• Integrity: Consistency both within and among objects,
needed for transactions.
• Security: Ability to define and enforce access control on
objects
 Structure of a CORBA
application
Java
Client Database
Service
ORB

Object Security
Service
Bus

C++
Client ORB Application
Service
 Interface Definition Language
(IDL)
• It is CORBA’s object contract language
• It is not a complete programming language
• It consists of two parts
– Front End
• Understands IDL syntax, creates intermediate representation
– Back End
• Understands the target language (C++, Java,..)
• Takes intermediate representation and produces language
specific source code
• Creates “stubs”: Client side stubs of the interface
• Creates “skeletons”: Server side stubs of the interface
 Data Dictionary for ORB object
Model
• IDL Stubs - The code generated for a specific IDL
interface to allow static invocation of that interface. Linked
into a CORBA client
• IDL Skeleton - The code generated for a specific IDL
interface. Linked into a CORBA object implementation
• Dynamic Invocation Interface - Allows invocations of
CORBA operations without IDL stubs
• Dynamic Skeleton Interface - Interface that allows
interpretation of requests to a server for types that were not
known at compile time
 Data Dictionary for ORB object
model
• ORB Interface - Interface offering miscellaneous services
from the ORB to clients and servers
• ORB agent - Locates and launches servers; facilitates
client communication with servers
• Object Adapter - Capable of activating servers whose
objects are required by invocations. (After a server is ready
it must inform the Object Adapter that its objects can
receive requests).
• Interface Repository - Stores operations and parameter
types of CORBA objects for discovery.
 Group Assignment
Write short notes about query processing and
query optimization supported by vivid
examples, motives, techniques and
implementation details (Refer to chap. 18 and
19 of Fundamentals of Database Systems by
Elmasri and Navathe, 2016) . Group
presentation will be conduct during next
period.