Data Management Design

Based on Chapter 18 of Bennett, McRobb

and Farmer:
Object Oriented Systems Analysis and
Design Using UML, (2nd Edition), McGraw
Hill, 2002.
03/12/2001 © Bennett, McRobb and Farmer 2002 1
 In This Lecture You Will
Learn:
 The different ways of storing
persistent objects
 The differences between object and
relational databases
 How to design data management
objects
 How to extend sequence diagrams
to include data management objects
© Bennett, McRobb and Farmer 2002 2
 Persistence
 Some objects are transient, exist in
memory and are discarded when
an application terminates
 Some objects must exist from one
execution of an application to
another or be shared among
different instances of applications.
Such objects are persistent objects
© Bennett, McRobb and Farmer 2002 3
Persistence Mechanisms
 Files hold data, typically on magnetic
media such as disks and tapes
 Database management systems (DBMS)
hold tables of data (relational DBMS) or
objects (object DBMS)
 DBMS use files to store data or objects,
but they hide the physical processes for
storing data beneath a layer of abstraction
 Objects can also be serialized directly to
files
© Bennett, McRobb and Farmer 2002 4
Persistence Architecture
 The choice of the architecture for
persistence is a system design issue
 The design of storage for specific
classes and associations within the
framework of that architecture is a class
design issue
 The overall design may be constrained
by having to operate with existing
systems or using existing DBMS
© Bennett, McRobb and Farmer 2002 5
 Persistence Design
Questions
 Can files be used for some storage?
 Is it truly an O-O system or just an
interface to a relational database
using Java or C++?
 Will the system use an existing
DBMS?
 Will it use a relational DBMS?
 Will it use an object DBMS?
© Bennett, McRobb and Farmer 2002 6
 Persistence Design
Questions
 What is the logical layering of the
system?
 What is the physical layering of the
system?
 Is the system distributed? Does this
include distributed data storage?
 What protocols will be used to
communicate within the system?

© Bennett, McRobb and Farmer 2002 7

 File Systems
Files and record structures
 Fixed length (padded)
 Variable length (delimited)
 Header and detail
 Tagged data (XML)

<Author>
12345678901234567890123456789012345
”Simon”,”Bennett”,”Leicester”,”GB”,
1,”Simon”,”Bennett”
<Forename>Simon</Forename>
Simon
213,”22-01-2002”
2,1,”0077098641”,2002
Bennett Leice
<Surname>Bennett</Surname>
ster
2,2,”0077096738”,2001
GB 21322012002
</Author>
© Bennett, McRobb and Farmer 2002 8
 File Systems
File organization
 Serial—new records appended
 Sequential—records ordered in file,
usually according to a numeric key
 Random—uses an algorithm to
convert a key to an address in the
file
© Bennett, McRobb and Farmer 2002 9
 File Systems
File access methods
 Serial—to read serial and sequential
files
 Index-sequential—using indexes to find
records in a sequential file and improve
access time
 Direct—using relative or hashed
addressing to move directly to the
required record in the file
© Bennett, McRobb and Farmer 2002 10
earching for Hamer using index-sequential file access

Index-sequential Access

© Bennett, McRobb and Farmer 2002 11

Direct Access

© Bennett, McRobb and Farmer 2002 12

 Improving Access
 Creating a linked list in random files
to make it possible to read records in
sequential order
 Adding a secondary index keyed on a
field that is not the key on which the
main access method is based
 Indexes can be inverted files or use
other techniques such as B-trees

© Bennett, McRobb and Farmer 2002 13

 File Types
 Master files
 Transaction files
 Index files
 Temporary file or work files
 Backup files
 Parameter files

© Bennett, McRobb and Farmer 2002 14

 File Example
 Using files in Java to handle localization
of prompts and messages
 Use the java.util.Locale class to hold
information about the current locale
– language_country_variant
– fr_FR_EURO
– fr_CA
– en_UK
– en_AU
© Bennett, McRobb and Farmer 2002 15
 File Example
 The Java class java.util.ResourceBundle
uses the locale to load a file with locale-
specific values e.g.
UIResources_fr_FR_EURO
 Java code to use this:
resources = ResourceBundle.getBundle(”UIResources”,
currentLocale);
Button cancelButton = new Button(resources.getString(”Cancel”);
rather than
Button cancelButton = new Button(”Cancel”);
© Bennett, McRobb and Farmer 2002 16
 Resource File
 File for French is
UIResources_fr_FR_EURO
 Contains
Cancel = Annuler
OK = OK
File = Fichier
…

© Bennett, McRobb and Farmer 2002 17

 Database Management
Systems (DBMS)
 Problems with files:
– redundancy—number of files grows with
applications, and data is duplicated
– inconsistency—data is updated in one
application’s files, but not in another’s
– maintenance problems—changes to data
structures mean changes to many programs
– difficulty combining data—business needs
may mean users want data from different
applications
© Bennett, McRobb and Farmer 2002 18
 DBMS
 Corporate database consolidates
data for different applications
 Each application then has its own
view of a subset of the data
Application 1 Database Application 2

© Bennett, McRobb and Farmer 2002 19

 DBMS Schema
 Ultimately data in databases is
stored in files, but their structure is
hidden from developers
External Schema The view on data used by
application programs.

Conceptual Schema The logical model of data that is

separate from how it is used.

Internal Schema The physical storage of data in

files and indexes.

© Bennett, McRobb and Farmer 2002 20

 DBMS Features
 Data Definition Language (DDL)
 Data Manipulation Language (DML)
 Integrity Constraints
 Transaction Management
 Concurrency
 Security
 Tuning of Storage
© Bennett, McRobb and Farmer 2002 21
 Advantages of DBMS
 Eliminate unnecessary duplication of data
 Enforce data integrity through constraints
 Changes to conceptual schema need not
affect external schema
 Changes to internal schema need not
affect the conceptual schema
 Many tools are available to manage the
database

© Bennett, McRobb and Farmer 2002 22

 Disadvantages of DBMS
 Cost of investing in the DBMS
 Running cost, including staff
(Database Administrators) to
manage the DBMS
 Processing overhead in converting
data to format required by
programs

© Bennett, McRobb and Farmer 2002 23

 Types of DBMS
 Relational—represent data in
tables
– tables consist of rows of data
organized in columns

© Bennett, McRobb and Farmer 2002 24

 Types of DBMS
 Object—store objects as objects
– designed to handle complex nested
objects for graphical and multimedia
applications
 Object-relational—hybrid
databases that can store data in
tables but can also store objects in
tables
© Bennett, McRobb and Farmer 2002 25
 Relational DBMS
 To store objects in a relational
database, the objects have to be
‘flattened’ into tables
 Complex objects have to be taken
apart and the parts stored in
different tables
 When retrieved from the database,
the object has to be reassembled
from the parts in different tables
© Bennett, McRobb and Farmer 2002 26
 Normalization
 Data from complex structures is
‘flattened’ into tables
 Typically normalization is carried
out as far as ‘Third Normal Form’
 In an object-oriented system, we
may use normalization to convert
classes to table schemas

© Bennett, McRobb and Farmer 2002 27

Normalization Example

© Bennett, McRobb and Farmer 2002 28

 Objects as a Table

 To get to First Normal Form, break

out the repeating groups
© Bennett, McRobb and Farmer 2002 29
First Normal Form

© Bennett, McRobb and Farmer 2002 30

Second Normal Form

© Bennett, McRobb and Farmer 2002 31

Third Normal Form

© Bennett, McRobb and Farmer 2002 32

 Alternative Approach
 Classes with simple data structure
become tables
 Object IDs become primary keys
 Where classes contain another class as
an attribute create a table for the
embedded class
 For collections create two tables, one for
the objects in the collection, the other to
hold Object IDs of the containing objects
and the contained objects
© Bennett, McRobb and Farmer 2002 33
 Alternative Approach
 One-to-many associations can be
treated like collections
 Many-to-many associations become two
separate tables for the objects and a
table to hold pairs of Object IDs
 One-to-one associations are
implemented as foreign-key attributes—
each class gains an extra attribute for
the Object ID of the other
© Bennett, McRobb and Farmer 2002 34
 Alternative Approach
 To implement inheritance
– only implement the superclass as a
table including all subclass attributes
– only implement the subclasses as
tables, duplicating superclass
attributes in each
– implement superclass and subclasses
as tables with shared primary keys
 Each approach has disadvantages
© Bennett, McRobb and Farmer 2002 35
 Object DBMS
 ODBMS have the advantage that objects
can be stored directly
 Object Data Management Group
(ODMG) standard
 Not all object databases conform to the
standard
 Object databases are closely linked to
programming languages with ways of
navigating through the database

© Bennett, McRobb and Farmer 2002 36

 Sample C++
ObjectStore Operation
IntCampaign * CreativeStaff::findIntCampaign
( string
campaignCode )
{
IntCampaign * intCampaignPointer;
intCampaignPointer =
staffIntCampaignList.getValue().query_pick(
“IntCampaign*”,
“campaignCode == this->campaignCode”,
os_database::of(this));
return intCampaignPointer;
}
© Bennett, McRobb and Farmer 2002 37
 Object DBMS
 Some will transparently
‘materialize’ objects from the
database when they are referred
to
 Update transactions need to be
bracketed with start and finish
transaction methods
 Operations are still implemented in
object-oriented languages
© Bennett, McRobb and Farmer 2002 38
 Designing Data
Management Classes
 Alternatives (two in bold are covered here):
– add save and retrieve operations to classes
– make save and retrieve class-scope methods
– allow all persistent objects to inherit from
a PersistentObject superclass
– use collection classes to manage persistence
– use broker classes to manage persistence
– use a parameterized class to handle persistence
for different classes

© Bennett, McRobb and Farmer 2002 39

 PersistentObject
PersistentObject
{Ab stract}

- objid: int
- iterator: RandomAccessFile

+ getObject( ): Object
 Create an + store( )
+ delete( )
+ update( )
abstract + iterate( ): Object
+ write( ) {Ab stract}
+ read( ) {Ab stract}
superclass
and make all Location

persistent - locationCode: String

- locationName: String

classes - intCampaignList: IntCampaign[ *]

+ findByLocationCode( String ): Location

inherit from + iterateLocation( ): Location

+ iterateIntCampaign( ): IntCampaign
+ addIntCampaign( IntCampaign )

it + removeIntCampaign( String )
+ numberOfCampaigns( ): int
+ write( )
+ read( )
© Bennett, McRobb and Farmer 2002 40
 PersistentObject
Materialization as Class
Method
 Sequence diagram

:ListCampaigns Location
Campaign
Dialog
Manager
GetNumberOf
findByLocation Location(
Campaigns( )
Code locationCode,
(locCode) locationName,
intCampaignList[ ]) :Location

numberOfCampaigns( )

© Bennett, McRobb and Farmer 2002 41

 Database Broker
 Use a broker class responsible for
materializing instances of each
class from the database
materializes
Location LocationBroker

- instance: LocationBroker

- LocationBroker( )
+ instance( ): LocationBroker
+ findByLocationCode( String ): Location
+ iterateLocation( ): Location

© Bennett, McRobb and Farmer 2002 42

 Database Broker
Materializes Instances
 Sequence diagram

:ListCampaigns :LocationBroker
Campaign
Dialog
Manager
GetNumberOf
Campaigns( ) findByLocation Location(
Code locationCode,
(locCode) locationName,
intCampaignList[ ]) :Location

numberOfCampaigns( )

© Bennett, McRobb and Farmer 2002 43

Inheritance Hierarchy of
Database Brokers
Datab aseBroker

FileBroker RelationalBroker

LocationBroker IntCampaignBroker

materializes materializes

Location IntCampaign

© Bennett, McRobb and Farmer 2002 44

RelationalBroker and Other
Classes
oracle::jdbc::driver::Oracle RelationalBroker
Driver

java::sql::Connection
Location Broker

materializes
java:sql::Statement

Location

java::sql::ResultSet

© Bennett, McRobb and Farmer 2002 45

Package Diagram

sun.jdbc java.sql

«import» «import»

Broker Application
Framework Brokers

© Bennett, McRobb and Farmer 2002 46

 Proxy Pattern
 Proxy objects act as placeholders for the
real objects, e.g. IntCampaigns in Locations
 The IntCampaignProxy has the same
interface as IntCampaign, but no data
 When a Location requires data about one of
its IntCampaigns, it sends a message to the
Proxy
 The Proxy requests the Broker to
materialize the IntCampaign and passes the
message on

© Bennett, McRobb and Farmer 2002 47

 Proxy Pattern
 The Proxy can then replace the
reference to itself in the Location with a
reference to the real materialized object
 This approach can be combined with
caching of objects
 The caches can be used by the Broker
to check whether an object is already in
memory and save materializing it from
the database if it is
© Bennett, McRobb and Farmer 2002 48
 Adding Caches
 Six caches
– new clean cache
– new dirty cache
– new deleted cache
– old clean cache
– old dirty cache
– old deleted cache

© Bennett, McRobb and Farmer 2002 49

 Transaction Commit
Cache Actions
 Six caches  Cache actions
– new clean cache – write to database
– new dirty cache – write to database
– new deleted cache – delete from cache
– old clean cache – delete from cache
– old dirty cache – write to database
– old deleted cache – delete from
database
© Bennett, McRobb and Farmer 2002 50
Class Diagram with
Caches and Proxies
Cache 6 1 DatabaseBroker

«Interface » RelationalBroker
IntCampaignInterface

«realize» «realize»

«Proxy» IntCampaignBroker
IntCampaignProxy

runs in materializes

Location IntCampaign

© Bennett, McRobb and Farmer 2002 51

 Collaboration Diagram
1.2 inMemory( )

1 printList( ) 1.1 getTitle( )

:Location :IntCampaignProxy

1.6 getTitle( ) 1.3 [not in memory]

getIntCampaign
( objectid )

:IntCampaign :IntCampaignBroker

1.5 [not in cache] 1.4 * inCache

retrieveIntCampaign ( objectid )
( objectid )
:Cache

© Bennett, McRobb and Farmer 2002 52

 Using a Framework
 Why develop a framework when
you can use an existing one?
 Object-table mappings
– Toplink
– CocoBase
 Products that will map attributes of
classes to columns in a relational
database table
© Bennett, McRobb and Farmer 2002 53
 Using a Framework
 J2EE Application Servers
 Enterprise JavaBeans (EJBs) can be
used – Entity Beans for business
objects
 Container-Managed Persistence
(CMP) is a framework for J2EE
containers to handle the persistence
of instances of entity beans
 Use J2EE Patterns (Alur et al., 2001)
© Bennett, McRobb and Farmer 2002 54
 Summary
In this lecture you have learned about:
 The different ways of storing persistent
objects
 The differences between object and
relational databases
 How to design data management objects
 How to extend sequence diagrams to
include data management objects

© Bennett, McRobb and Farmer 2002 55

 References
 Silberschatz et al. (1996)
 Howe (2001)
 Eaglestone and Ridley (1998)
 Alur, Crupi and Malks (2001)
(For full bibliographic details, see
Bennett, McRobb and Farmer)

© Bennett, McRobb and Farmer 2002 56