6 access layer.pdf

8/11/2019 6 access layer.pdf

1/84

Ob ect-Oriented S stems Develo ment Bahrami ? Irwin/ McGraw-Hill

Chapter 11:

Access Layer: Object Storageand Object Interoperability

Object-Oriented SystemsObject-Oriented Systems

DevelopmentDevelopment:Using the Unified ModelingUsing the Unified Modeling

LanguageLanguage


2/84


Goals

Object storage and persistence.Database management systems and

their technology.Client-server computing.

Distributed databases.Distributed object computing.


3/84


Goals (Cont)

Object-oriented databasemanagement systems.

Object-relational systems.Designing access layer objects.


4/84


IntroductionA database management system

(DBMS) is a collection of relateddata and associated programs thataccess, manipulate, protect andmanage data.


5/84


Whats the purpose of DBMS

The main purpose of a DBMS is toprovide a reliable, persistent datastorage facility,

and mechanism for efficientand convenient data access and

retrieval.


6/84


Persistence (review)Persistence is defined as objects

that outlive the programs whichcreated them.

Persistent object stores do notsupport query or interactive userinterface facilities, as found in a

fully supported DBMS orOODBMS.


7/84


Object Storage and PersistenceAtkinson et al. describe six broad

categories for the lifetime of data:

1. Transient results to the evaluationof expressions.

2. Variables involved in procedureactivation (parameters and variableswith a localized scope).

3. Global variables and variablesthat are dynamically allocated.


8/84


Object Storage and Persistence(Cont)

4. Data that exist between theexecutions of a program.

5. Data that exist between theversions of a program.

6. Data that outlive a program.


9/84


Database Management Systems

A DBMS is a set of programs that

enable the creation and maintenanceof a collection of related data.

DBMS have a number of propertiesthat distinguish them from the file-based data management approach.


10/84


Database system Vs. File System.

Engineering

Accounting

Marketing

Accounting

Sales

Accounts

Employee

Inventory

Customer

Parts

Database

DBMS

Marketing

Engineering Parts

Customer

SalesInventory

Accounts

File System

A Database System


11/84


Database Models

A database model is a collection of

logical constructs used to represent the

data structure and data relationships

within the database.Hierarchical Model

Network Model

Relational Model


12/84


Hierarchical model

Motor Vehicle

Truck CarBus

The hierarchical model representsdata as a single-rooted tree.


13/84


14/84


Relational ModelOf all the database models, the

relational model has the simplest,most uniform structure and is the

most commercially widespread.


15/84


Relational Database (Cont)Soup NameSoup-ID Price

Soup Table

NameCust-ID Address Phone #

Customer Table

Cust-IDSoup-ID QTY

Order Table

Order-IDKey

KeyKey

Foreign

Keys


16/84


What is a schema and metadata? The schema, or metadata, contains a

complete definition of the dataformats, such as the data structures,

types, and constraints.


17/84


Schema (Cont)

In an object-oriented DBMS, the

schema is the collection of classdefinitions.

The relationships among classes(such as super/sub) are

maintained as part of the schema.


18/84


19/84


Data Manipulation Language(DML)

Once data is stored in a database,there must be a way to get it, use it,and manipulate it.

DML is a language that allows usersto access and manipulate (such as:

creation, saving and destruction of)data organization.


20/84


DML (Cont)The Structured Query Language

(SQL) is the standard DML forrelational DBMS.

In a relational DBMS, the DML isindependent from a hostprogramming language.


21/84


DML (Cont)

For example, a host language such asC or COBOL would be used to writethe body of the application.

SQL statements are then typicallyembedded in C or COBOL

applications to manipulate data.


22/84


ShareabilityData in the database often needs

to be accessed and shared bydifferent applications.

The database then must detect and

mediate the conflicts and promotethe greatest amount of sharing

possible withoutsacrificing theintegrity of data.


23/84


TransactionA transactionis a unit of change, in

which either all changes to objectswithin a transaction will be appliedor not at all.

A transaction is said to commitif allchanges can be successfully made to

the database and to abortif allchanges cannot be successfullymade to the database.


24/84


Concurrency ControlPrograms will attempt to read and

write the same pieces of informationsimultaneously and, in doing so,create a contention for data.

The concurrencycontrol mechanism is

thus established to

mediate these conflicts.


25/84


Concurrency Control (Cont)

It does so by making policies thatdictate how read and write conflictswill be handled.


26/84


27/84


28/84


Distributed Databases

In distributed databases portions ofthe database reside on differentnodes (computers) in the network.


29/84


Client/Server Computing

Client/server computing allowsobjects to be executed in differentmemory spaces or even different

machines.


30/84


Client/Server Computing (Cont)The calling module becomes the

"client" (which requests a service),and the called module becomesthe "server" (which provides theservice).


31/84


Client/Server Computing (Cont)

Client programs usually manage:The user-interface

Validate data entered by the userDispatch requests to server

programs, and sometimes

Execute business logic.


32/84


Client/Server Computing (Cont)

The Business layer contains all ofthe objects that represent thebusiness such as:

Order

Customer

Line Item

Inventory, etc.


33/84


Client/Server Computing (Cont)A server process (program) fulfills

the client request by performingthe task requested.

Server programs generally receiverequests from client programs,execute database retrieval and

updates, manage dataintegrity, and dispatch

responses to client requests.


34/84


A two-tierarchitecture is one

where a client talks directly to aserver, with no intervening server.

This type of architecture istypically used in smallenvironments with less

than 50 users.

A Two-Tier Architecture


35/84


A Two-Tier Architecture (Cont)

SERVER

APPLICATION

CLIENTCLIENTCLIENT

LAN or WAN

APPL. APPL. APPL.

Printer

Data


36/84


A Three-Tier ArchitectureA three-tier architecture

introduces another server (or an"agent") between the client andthe server.

The role of the agent is many fold.

It can provide translation services

as in adapting a legacy applicationon a mainframe to a client/server

environment.


37/84


A Three-Tier Architecture (Cont)

UNIX SERVER

Host (i.e. IBM 3090)

CLIENT

Sybase RDBMS

Legacy applications: DB2 RDBMS

APPLICATIONSWindows 9xACCESSLotus

Agent


38/84


Basic Characteristics ofClient/Server Architectures

1. The client or front-end interactswith the user, and a server or back-end interacts with the sharedresource.


39/84


Basic Characteristics ofClient/Server Architectures (Cont)

2. The front-end task and back-endtask have fundamentally differentrequirements for computingresources.

Resources such as processor speeds,

memory, disk speeds and capacities,and input/output devices.


40/84


3. The environment is typicallyheterogeneous and multi-vendor.



41/84



4. Client-server systems can bescaled horizontally or vertically.

Horizontalscaling means adding or

removing client workstations withonly a slight performance impact.

Verticalscaling means migrating toa larger and faster server machine or

multi servers.


42/84


43/84


Distributed Processing (Cont)

For example, in processing an order

from our client, the clientinformation may process at one

machine and the accountinformation will then be processednext on a different machine.


44/84


Cooperative processingCooperative processing is a form of

distributed computing where two ormore distinct processes are requiredto complete a single business

transaction.

C o o p e r a t iv e P r o c e s si n g

A P P L I C A T I O N SW in d o w s 9 xA C C E S SL o t u s

A P P L I C A T I O N SW in d o w s 9 xA C C E S SL o t u s

S E R V E R


45/84


Client/Server Components

I.User Interface Layer:This is one ofthe major components of theclient/server application.

It interacts with users, screens,Windows, Window management,

keyboard, and mouse handling.


46/84


Client/Server Components (Cont)II.Business Processing Layer:This is

a part of the application that usesthe user interface data to performbusiness tasks.


47/84


48/84


Distributed Object Computing (DOC)

Distributed object computing

promises the most flexibleclient/server systems.

It utilizes reusable softwarecomponents that can roam anywhereon networks, run on differentplatforms, communicate with legacyapplications.


49/84


DOC (Cont)Currently, there are several

competing DOC standards,including:

Microsoft's ActiveX/DCOM

the Object Management Group'sCORBA, and

OpenDoc.


50/84


Common Object Request BrokerArchitecture (CORBA)

CORBA provides means tointegrate distributed, heterogeneousbusiness applications and data.

The CORBA Interface DefinitionLanguage(IDL) allows developers to

specify language-neutral, object-oriented interfaces for applicationand system components.


51/84


Object Request Brokers (ORBs) ORBs implement a communicationchannel through which applications can

access object interfaces and request dataand services.

Object Request Broker (ORB)

DomainObjects

NamingPersistenc

e Events

Concurrency

Transaction

Application Objects


52/84


Microsoft's ActiveX/DCOMThe Distributed Component Object

model, Microsoft's alternative toOMG's CORBA.

DCOM is an Internet andcomponent strategy where ActiveX(formerly known as object linking

and embedding, or OLE) plays therole of DCOM object.


53/84


54/84


Object-Oriented Database SystemManifesto

Malcolm Atkinson et al. describedthe necessary characteristics that asystem must satisfy to be considered

an object-oriented database.These categories can be broadly

divided into object-orientedlanguage properties anddatabaserequirements.


55/84


Manifesto (Cont) First, the rules that make it an object-oriented system are as follows:

1. The system must support complex objects. 2. Object identity must be supported.

3. Objects must be encapsulated.

4. The system must support types or classes.

5. The system must support inheritance.

6. The system must avoid prematurebinding.

7. The system must be computationally

complete.


56/84


Manifesto (Cont) 8. The system must be extensible.

Second, these rules make it a DBMS:

9. It must be persistent, able to remember anobject state.

10. It must be able to manage very largedatabases.

11. It must accept concurrent users.

12. It must be able to recover from hardwareand software failures.

13. Data query must be simple.


57/84


Object-Oriented Databases versusTraditional Databases

The objects are an "active"component in an object-orienteddatabase.

Relational database systems do notexplicitly provide inheritance of

attributes and methods.


58/84


Object-Oriented Databases versusTraditional Databases (Cont)

Each object has its own identity, orobject-ID(as opposed to the purelyvalue-oriented approach of

traditional databases).

Object identity allows objects to be

related as well as shared within adistributed computing network.


59/84


Object-Relational Systems: ThePractical World

In practice, even though manyapplications increasingly aredeveloped in an object-oriented

environment, chances are good thatthe data those applications need to

access live in a very differentuniversea relational database.


60/84


Object-Relation Mapping For a tool to be able to define how

relational data maps to and from

application objects, it must have at leastthe following mapping capabilities:

Table-class mapping.

Table-multiple classes mapping.

Table-inherited classes mapping.

Tables-inherited classes mapping.


61/84


62/84


Table-Multiple Classes Mapping The custIDcolumn provides the discriminant.

If the value for custID is null, an Employee

instance is created at run time; otherwise, aCustomerinstance is created. Employee

name

address

empIDname custIDaddress

Person Table

empID

Customer

name

address

custID


63/84


Table-Inherited Classes Mapping

Employee

namessn

name address

Person Table

ssn

HourlyEmployee

wage

SalariedEmployee

address

salary

wage salary

Instances of SalariedEmployeecan be created for anyrow in the Persontable that has a non null value forthe salarycolumn. If salary is null, the row isrepresented by an HourlyEmployeeinstance.

Tables Inherited Classes Mapping


64/84


Tables-Inherited Classes Mapping

name

name address

Person Table

dept

Customer

address

company

Employee

Person

name

Employee Table

ssn

name address

Customer Table

ssn

ssn

dept

company

salary

salary

Instances of Personare

mapped direct ly from

t h e P e r s o n t a b l e .

However, instances of

E m p l o y e e c a n b e

c rea ted on l y fo r t he

rows in the Employee

table (the joins of the

Employee and Persontables on the ssnkey).

The ssn is used both

as a primary key on the

Person table and as af o r e i g n k e y o n t h e

P e r s o n t a b l e a n d a

p r i m a r y k e y o n t h e

E m p l o y e e t a b l e f o r

activating instances of


65/84


Keys for Instance Navigation

name

Department Table

Department

name

Employee

name

Employee Table

ssndpartment ID salary

salary

department ID

name

ssn

department ID

T h e d e p a r t m e n t I D

p r o p e r t y o f E m p l o y e euses the foreign key in

c o l u m n

Employee.departmentID.

Each Employee instancehas a direct reference of

c l a s s D e p a r t m e n t

( a s s o c i a t i o n ) t o t h e

d e p a r t m e n t o b j e c t t o

which it belongs.


66/84


Multidatabase SystemA different approach for integrating

object-oriented applications withrelational data environments ismultidatabase systems, or

heterogeneous database systems,which facilitate the integration of

heterogeneous databases and otherinformation sources.


67/84


68/84


MDBS (Cont)

A mul t idatabase system

( M D B S ) i s a d a t a b a s e

system that resides on top

of, say existing relational

and object databases and

file systems (called local

database systems) andpresents a single database

illusion to its users.Application

OODBMS DBMS DBMS OODBMS

Local Databases

Virtual database


69/84


70/84


Characteristics of MDBS (Cont)

Integration of data types other than

relational data through the use ofsuch tools as driver generators.

Provision of a uniform but diverseset of interfaces (e.g., a SQL-style

interface, browsing tools, and C++)to access and manipulate data storedin local databases.


71/84


Open Database Connectivity Open database connectivity

(ODBC), provides a mechanism for

creating a virtual DBMS.Ap pl ication prog rams

ODBC driver manager

Database A

Database B

Database C

Database D

Database E

Loadable ODBC driver

Driver for database A

Driver for database B

Driver for database C

Driver for Database D

Driver for database E

...

ODBC

API


72/84


Designing Access Layer Classes The main idea behind creating an access

layer is to create a set of classes thatknow how to communicate with datasource, whether it be a file, relational

database, mainframe, Internet, DCOM,or via ORB.

The access classes must be able to

translate any data-related requests fromthe business layer into the appropriateprotocol for data access.


73/84


Access Layer Classes (Cont) The business layerobjects and view

layer objects shouldnot directly access

t h e d a t a b a s e .

I n s t e a d , t h e yshould consult with

the access layer for

all external systemconnectivity.

Database, ORB, Internet, etc.

View layer objects

Business Layer Objects

Access Layer Objects

Application /Web

Server

ClientClientClient

DBMS Server

or

Legacy data and

application

Benefits of Access Layer Classes


74/84


f f yAccess layer classes provide easy

migration to emerging distributed

object technology, such as CORBA andDCOM.

These classes should be able toaddress the (relatively) modest needsof two-tier client/server architectures

as well as the difficult demands offine-grained, peer-to-peer distributed

object architectures.

Process


75/84


The access layer design process consistsof these following activities:

1. If methods will be stored in a program thenFor every business class identified, determine if the

class has persistent data.

elseFor every business class identified, mirror the

business class package.

2.Define relationships.The same rule as applies among

business class objects also applies among access

classes.


76/84


Process (Cont)3. Simplify classes and relationships. The main goal

here is to eliminate redundant or unnecessary classes

or structures.3.1.Redundant classes.If you have more than one

class that provides similar services, simply select

one and eliminate the other(s).3.2.Method classes. Revisit the classes that consist

of only one or two methods to see if they can be

eliminated or combined with existing classes.4. Iterate and refine.

Process of Creating Access Layer


77/84


f g yClasses

Business

Layer

Access

Layer

Class1

Class2 Class3

Step 1: Mirror business c lass package

Class1DB

Class2DB Class3DB

Access

layer

Class1DB

Class2DB Class3DB

Step 2: Define relationships

Accesslayer

Accesslayer

Class1

Class2 Class3

Class1DB

Class2DB Class3DB

Step 3: Simplify classes and relationships


78/84


Access Layer Classes (Cont)

The relationbetween abusiness class and

its associatedaccess class.

Class1

Class1DB

Business class

Access c lass

for Class1

Summary


79/84


yThe fundamental purpose of a

DBMS is to provide a reliable

persistent data storage facility andthe mechanisms for efficient,convenient data access and retrieval.

Many modern databases aredistributed databases.

Summary (Cont)


80/84


Client/server computing is the logicalextension of modular programming.

Distributed computing is a secondclient/server revolution, a transitionto an immensely expandedclient/server era.

The object-oriented database

technology is a marriage of object-oriented programming and database

technology.

Summary (Cont)


81/84


y

In practice, even though many

applications increasingly are developed

using object-oriented programming

technology, the data those applications

need to access live in a relationaldatabase.


82/84


Summary (Cont) The main process in relational-object

integration is defining the relationshipsbetween the table structures

(represented as schemata) in the

relational database with classes

(representing classes) in the object

model.


83/84


Summary (Cont)

A different approach for integrating

object-oriented applications withrelational data environments

involves multidatabase systems, orheterogeneous database systems,which facilitate the integration ofheterogeneous databases and otherinformation sources.


84/84


Summary (Cont)The main idea behind an access

layer is to create a set of classes thatknow how to reach the data source.

Access layer classes provide easymigration to emerging distributedobject technology, such as CORBAand DCOM.

Date post:	02-Jun-2018
Category:	Documents
Upload:	allen-chandler
View:	223 times
Download:	0 times

6 access layer.pdf

Documents