Unit I: Introduction

You might also like

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 41

Unit I : Introduction

Data Modeling
 Data Modeling
◦ Data Modeling is the art of identifying the
entities that must be represented in a
database and the relationships among those
entities.
Hierarchical Data Model
 Data organized in a tree a parent can have
many children
 a child can have only one parent
 Records described by entity types
 1:N (one-to-many) relationships
 Query by path navigation
 Examples
◦ File system
◦ LDAP (Lightweight Directory Access Protocol )
◦ Windows Registry and Active Directory
◦ XML documents and XQuery
 Implemented by IBM’s Information
Management System (IMS)
 Allows only one-to-one or one-to-many
relationships between entities.
 The benefit of a hierarchical database is that
its navigational nature makes access very fast
when you are following the predefined
relationships.
 Inability to give an entity multiple parents
and the absence of direct data makes it
unsuitable for environments where ad hoc
queries are important.
Network Data Models
 Data organised in graph (lattice)
◦ A parent can have many children
◦ A child can have many parents
 Record types define properties
 Set type defined relationships
◦ Parent – child
 Query by graph navigation
Relational Model
 Data organized as tuples in relations
 Link between data tuples
◦ Primary and foreign keys
 Relation algebra
◦ Project, select, join
 Relational normal forms
 Declarative language
 Examples
◦ Oracle, MS SQL server, IBM DB2,PostgreSQL ,
MySQL
Object Oriented Data Model
 Development of object-oriented paradigm
brought about a fundamental change in the
way we look at data and the procedures that
operate on data.
 Traditionally, data and procedures have been
stored separately, the data and their
relationships in a database, the procedures in
an application programs.
 Object orientation, however, combines an
entity’s procedures with its data.
 Entities become self-contained units that can
be reused and moved around with relative
ease.
Object Roles in Databases
 Pure object-oriented DBMSs
◦ Is based solely on the object-oriented data
model.
◦ Used in mission critical systems
 Hybrid pr post-relational DBMSs
◦ Is primarily based on relational but stores
objects in relations
Sample Uses for Object-Oriented
Databases
 OODB are being used today in a wide
range of organizations for a wide range of
purposes
◦ CAD/CAM Computer Aided Design and
Computer Aided Manufacture Applications
◦ ECAD And MCAD
 Involves in research, design and development of
engineering systems structures
◦ RealTime Control System
◦ Multimedia Interface
Benefits of Object-Oriented
Approach
 Enhanced modeling Capabilities
◦ It is easy to model the real world object as close
as possible like the case of object oriented
Programming Concepts.
 Extensibility
◦ Support for new data types – unlike traditional
DBMS products where the basic data types are
hard coded in the DBMS and are unchangeable by
the users, with an ODBMS the user can encode
any type of structure that is necessary and the
ODBMS will manage that type.
 Removal of impedance mismatch
◦ Impedance mismatch is a set of conceptual and technical
difficulties that are often encountered when a relational
database management system (RDBMS) is being used by a
program written in an object oriented programming
language or style; particularly when objects or class
definitions are mapped in a straightforward way to
database tables or relational schema. The DML of
OODBMS can eliminate the difficulties.
 Expressive power
◦ Provides an ability to handle objects like records in
RDBMS. Hence, OODBMS is more expressive than
RDBMS. An object database stores complex data and
relationships between data directly, without mapping to
relational rows and columns, and this makes them suitable
for applications dealing with very complex data.
 Support for long-duration transactions
◦ The process of object data involves increased
complexity. Hence, it provide support for long
duration transactions.
 Applicability to advanced database
applications
◦ Enhanced modeling capabilities of OODBMS
makes it usable to application like Computer
Aided Design (CAD), Computer aided software
engineering (CASE), Office information systems,
multimedia systems, and many more.
 Improved performance
◦ Improved performance in the case of object
based applications.
 Reusability
◦ The code can be reused. Inheritance, method
support, etc enables the possibility of reusing
the code. An OODBMS can be programmed
with small procedural differences without
affecting the entire system
 OODBS eliminate need for user defined keys
◦ The OODB model has an OID that it is automatically
generated by the system and that guarantees
uniqueness to each object.
◦ Eliminates the need for user defined keys
◦ The OID cannot be modified by the application
◦ The notation of object identity provides a separate
and consistent notion of identity, which is
independent of how an object is accessed or modeled
with descriptive data.
◦ Two objects are different if they have different OIDs,
even if they have the same structures and the same
values for all their properties.
 OODBs reduce need for joins
◦ The capability of navigating through object
structures and the resulting path expression
in object attributes gives us a new perspective
on the issue of joins in OODBs. The relational
join is a mechanism that correlates two
relations in the basis of values of a
corresponding pairs of attributes, the
relational join (or explicit join) may still be
necessary in OODBS.
Relational DBMS Limitations
 Poor representation of ‘real world’
entities ƒ
 Poor support for integrity & business
constraints. ƒ
 Homogeneous data structure. ƒ
 Limited operations. ƒ
 Difficulty handling recursive queries.
 Difficulty with ‘Long Transactions’
OODBMS Disadvantages
 Lack of a universal data model
 ƒAd-hoc querying compromises
encapsulation. ƒ
 Locking at object-level impacts
performance ƒ
 Complexity
ƒLack of support for views ƒ
 Lack of support for security
ORDBMS
 An Object-Relational database adds
features associated with object oriented
systems to a RDBMS
 Extend the relational data model by
including object orientation and
constructs to deal with added data types
 The object-relational data model extends the
relational data model
◦ introduces complex data types
◦ object-oriented features
◦ extended version of SQL to deal with the richer type
system
◦ Complex data types
◦ new collection types including multisets and arrays
◦ attributes can no longer just contain atomic values (1NF)
but also collections
◦ nest and unnest operations for collection type attributes
◦ ER concepts such as composite attributes or multivalued
attributes can be directly represented in the object-
relational data model
OODBMS vs ORDBMS
 OODBMS put more emphasis on the role of
the client side This can improve long, process
intensive, transactions. ƒ
 ORDBMS SQL is still the language for data
definition, manipulation and query ƒ
 OODBMS have been optimised to directly
support objectoriented applications and
specific OO languages
ƒORDBMS are supported by most of the
‘database vendors’ in the DBMS market
place
 ORDBMS Most third-party database tools
are written for the relational model and
will therefore be compatible with SQL3
ƒORDBMS search, access and manipulate
complex data types in the database with
standard (SQL3 ?), without breaking the
rules of the relational data model ƒ
 OODBMS The ODMG standard group’s
OQL is now the standard query language
amongst OODBMS vendors
 Object databases
◦ complex datatypes
◦ tight integration with an object-oriented
programming language (persistent programming
language)
◦ high performance
 Object-relational databases
◦ complex datatypes
◦ powerful query languages
◦ good protection of data from programming
errors
 When to use an ODBMS?
◦ Iƒn applications that generally retrieve
relatively few (generally physically large) highly
complex objects and work on them for long
periods of time.
 When to use an ORDBMS?
◦ Iƒn applications that process a large number of
shortlived (generally ad-hoc query)
transactions on data items that can be
complex in structure
OODBMS vs RDBMS

Object oriented model Relational model


Class Relation
Object / Object instance Tuple /Record
Variable Attribute / column
Method Stored procedure
Object-Oriented Data Model
 Loosely speaking, an object corresponds to
an entity in the E-R model.
 The object-oriented paradigm is based on
encapsulating code and data related to an
object into a single unit.
 The object-oriented data model is a logical
model (like the E-R model).
 Adaptation of the object-oriented
programming paradigm (e.g., Smalltalk, C++)
to database systems.
Object Structure
 An object has associated with it:
◦ A set of variables that contain the data for the object.
The value of each variable is itself an object.
◦ A set of messages to which the object responds; each
message may have zero, one, or more parameters.
◦ A set of methods, each of which is a body of code to
implement a message; a method returns a value as the
response to the message
 The physical representation of data is visible only
to the implementor of the object
 Messages and responses provide the only
external interface to an object.
Messages and Methods
 The term message does not necessarily imply physical
message passing. Messages can be implemented as procedure
invocations.
 Methods are programs written in a general-purpose language
with the following features
◦ only variables in the object itself may be referenced directly
◦ data in other objects are referenced only by sending messages
 Strictly speaking, every attribute of an entity must be
represented by a variable and two methods, e.g., the
attribute address is represented by a variable address and two
messages get-address and set-address.
◦ For convenience, many object-oriented data models permit
direct access to variables of other objects
Object Classes
 Similar objects are grouped into a class; each
such object is called an instance of its class
 All objects in a class have the same
◦ variable types
◦ message interface
◦ Methods
 They may differ in the values assigned to
variables
 Example: Group objects for people into a
person class Classes are analogous to entity
sets in the E-R model
Class Definition Example
 class employee {
/* Variables */
string name;
string address;
date start-date;
int salary;

/* Messages */

int annual-salary();
string get-name();
string get-address();
int set-address(string new-address);
int employment-length();
}
Inheritance
 E.g., class of bank customers similar to class of bank
employees: both share some variables and messages,
e.g., name and address But there are variables and
messages specific to each class e.g., salary for
employees and and credit-rating for customers
 Every employee is a person; thus employee is a
specialization of person
 Similarly, customer is a specialization of person.
 Create classes person, employee and customer
◦ variables/messages applicable to all persons associated
with class person.
◦ variables/messages specific to employees associated with
class employee; similarly for customer
 Place classes into a specialization/IS-A hierarchy
◦ variables/messages belonging to class person are
inherited by class employee as well as customer
 Result is a class hierarchy
Class Hierarchy Definition
class person {
string name;
String address;
};

class customer is a person f


Int credit-rating;
};

class employee is a person {


Date start-date;
Int salary;
};

class officer is a employee {


Int office-number ;
Int expense-account-number ;
};
 Full variable list for objects in the class officer :
◦ office-number, expense-account-number : defined locally
◦ start-date, salary: inherited from employee
◦ name, address: inherited from person
 Methods inherited similar to variables.
◦ Substitutability — any method of a class, say person, can be
invoked equally well with any object belonging to any
subclass, such as subclass officer of person.
 class extent: set of all objects in the class. Two options:
◦ Class extent of employee includes all officer , teller and
secretary objects
◦ Class extent of employee includes only employee objects
that are not in a subclass such as officer , teller or secretary
Example of Multiple
Inheritance
 The class/subclass relationship is represented by a directed
acyclic graph (DAG) — a class may have more than one
superclass.
 A class inherits variables and methods from all its
superclasses.
 There is potential for ambiguity. E.g., variable with the same
name inherited from two superclasses. Different solutions
such as flag and error, rename variables, or choose one.
 Can use multiple inheritance to model “roles” of an object.
◦ A person can play the roles of student, a teacher or footballPlayer,
or any combination of the three (e.g., student teaching assistants
who also play football).
◦ Create subclasses such as student-teacher and student-teacher-
footballPlayer that inherit from multiple classes.
Object Identity
 An object retains its identity even if some or all of
the values of variables or definitions of methods
change over time.
 Object identity is a stronger notion of identity
than in programming languages or data models
not based on object orientation.
◦ Value – data value; used in relational systems.
◦ Name – supplied by user; used for variables in
procedures.
◦ Built-in – identity built into data model or
programming language.
 no user-supplied identifier is required.
 form of identity used in object-oriented systems.
Object Identifiers
 Object identifiers used to uniquely identify
objects
◦ can be stored as a field of an object, to refer
to another object.
◦ E.g., the spouse field of a person object may be
an identifier of another person object.
◦ can be system generated (created by
database) or external (such as social-security
number)
Object Containment
 Each component in a design may contain
other components
 Can be modeled as containment of objects.
Objects containing other objects are called
complex or composite objects.
 Multiple levels of containment create a
containment hierarchy: links interpreted as is-
part-of, not is-a.
 Allows data to be viewed at different
granularities by different users

You might also like