Data Management Design

1

Content

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

2

Persistence Transient objects

exist in memory and are discarded when an application terminates

Persistent objects objects must exist from one execution of an application to

another or be shared among different instances of applications.

3

Persistence Mechanisms and Architecture Persistence Mechanisms

Files hold data 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

Persistence Architecture The choice of the architecture for persistence is a system

design issue The design of storage for specific classes and associations

within that architecture is a class design issue

4

Persistence Design Questions Can files be used for some storage? Will the system use an existing DBMS? Will it use a relational DBMS? Will it use an object DBMS? 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?

5

File Systems

Ask what kind of design trade-offs might have to be made with these different kinds of file record structures. Fixed length (padded) – easy to process, but wastes storage Variable length (delimited) – more difficult to process (looking for

delimiters), but saves storage space Header and detail – allows for structure in data, may need line type and

line no. Tagged data (XML) – self-describing, but storage overhead for tags.

6

12345678901234567890123456789012345Simon Bennett Leicester GB 213 6789012322012002

”Simon”,”Bennett”,”Leicester”,”GB”,213,”22-01-2002”1,”Simon”,”Bennett”2,1,”0077098641”,20022,2,”0077096738”,2001

<Author> <Forename>Simon</Forename> <Surname>Bennett</Surname></Author>

Database Management Systems (DBMS) Problems with files:

Redundancy (Dư thừa): number of files grows with applications, and data is duplicated

Inconsistency (Không nhất quán): data is updated in one application’s files, but not in another’s

Maintenance problems (Vấn đề bảo trì) : changes to data structures mean changes to many programs

Difficulty combining data (Khó liên kết dữ liệu): business needs may mean users want data from different applications

7

DBMS

Corporate database consolidates data for different applications

Each application then has its own view of a subset of the data

8

DatabaseApplication 1 Application 2

DBMS Schema Ultimately data in databases is stored in files, but

their structure is hidden from developers

9

Conceptual Schema

External Schema

Internal Schema

The view on data used by application programs.

The logical model of data that is separate from how it is used.

The physical storage of data in files and indexes.

DBMS Features Data Definition Language (DDL) Data Manipulation Language (DML) Integrity Constraints Transaction Management Concurrency Security Tuning of Storage

10

Advantages & Disadvantages of DBMS Advantages

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

Disadvantages 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

11

Types of DBMS Relational – represent data in tables

tables consist of rows of data organized in columns

e..g. Oracle, MySQL, sybase,DB2

Object-relational – hybrid databases that can store data in tables but can also store objects in tables e.g. PostgreSQL, Oracle-X

12

Types of DBMS Object – store objects as objects

designed to handle complex nested objects for graphical and multimedia applications

e.g Jusmine, Ontos, ObjectStore

Object Data Management Group (ODMG) standard Not all object databases conform to the standard

Object databases are closely linked to programming languages Some may transparently "materialize" objects

Operations are not stored with classes

13

Using OODBMS for OBJECTS

Advantages Seamless Transition – no overhead Object in RAM and Objects in OODBMS behaves

same - no separate mechanisms Can store any object as it is. (e.g. picture) Levels of abstractions - gates to chips Can store association straight

Then, why still RDBMS is used to store objects ?

14

Why RDBMS is still used for objects ? Many companies already committed to some

RDBMS (huge investment)

RDBMS is robust and in use for a long time

ODBMS is yet to include some features

15

Using Relational DBMS for OBJECTS Most modern business application development projects use

object technology and relational databases to store the data. There is an impedance mismatch between object and

relational technology. 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

O-R Mapping "Mapping" will be used to refer to how objects and their relationships

are mapped to the tables in a relational database.

16

Flattening Objects to Tables:

Data from complex structures is ‘flattened’ into tables

Normalization Typically normalization is carried out as far as "Third

Normal Form"

Rules of Thump – An alternative approach simple Compound and Collections One-one, One-many and many- many Inheritance

17

Flattening Objects to Tables - 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

18

Normalization Example

19

Objects as a Table

To get to First Normal Form, break out the repeating groups

20

First Normal Form

21

Second Normal Form

22

Third Normal Form

23

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

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

24

Alternative Approach One-to-one associations are implemented as

foreign-key attributes – each class gains an extra attribute for the Object ID of the other

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

25

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

26

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

27

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 (generic) to handle

persistence for different classes

28

PersistentObject

Create an abstract superclass and make all persistent classes inherit from it Makes all business classes to

couple with a utility class Business classes still need to

do some unnecessary tasks Less cohesion less

reusable

29

PersistentObject {Abstract}

- objid: int- iterator: RandomAccessFile + getObject( ): Object+ store( )+ delete( )+ update( )+ iterate( ): Object+ write( ) {Abstract}+ read( ) {Abstract}

Location

- locationCode: String- locationName: String- intCampaignList: IntCampaign[ *] + findByLocationCode( String ): Location+ iterateLocation( ): Location+ iterateIntCampaign( ): IntCampaign+ addIntCampaign( IntCampaign )+ removeIntCampaign( String)+ numberOfCampaigns( ): int+ write( )+ read( )

Database Broker Use a broker class responsible for materializing

instances of each class from the database

30

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

materializes

Singleton class

Inheritance Hierarchy of Database Brokers

31

DatabaseBroker

RelationalBrokerFileBroker

IntCampaignBrokerLocationBroker

IntCampaignLocation

materializes

materializes

Using a Framework Why develop a framework when you can use an

existing one? Object-table mappings

Toplink Hibernate CocoBase

Products that will map attributes of classes to columns in a relational database table

32

Using a Framework O-R Mapping: Hibernate 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)

33