Object-persistence formats. Files. Object-oriented databases. Data management layer design. Relational databases. Relational Database Example.

Download (0)

Full text


Data management layer design

Modelling and Systems Development Lecture 12

Mapping problem-domain objects

to object-persistence formats

Object-persistence formats

• Files

– Sequential and random-access

• Relational databases

• Object-oriented databases

• Object-relational databases


• Directly supported by programming language

– Example: java.io package

• Sequential access

– Optimized for operations on entire file – Access to specific objects not efficient – Example: java.io.InputStream class

• Random access

– Optimized for finding specific objects – Entire-file operations not efficient – Example: java.io.RandomAccessFile

Relational databases

• Primary key

– an attribute that uniquely identifies a row

• Foreign key

– an attribute that is a primary key from a different table

– in order to simulate associations between objects

• Referential integrity

– guarantees that the foreign-key links are valid

• Structured Query Language (SQL)

– the standard language for accessing relational database tables

Relational Database Example

Figure 13-3 Goes Here

Primary keysare underlined.

Foreign keysin Order are double underlined.

Referential integrityis suggested through the red ovals.

Object-oriented databases

• Two approaches

– Adding persistence extensions to OO languages

– Separate DBMS

• Standards from ODMG (

Object Data

Management Group



Object-oriented databases

• Support complex data:

– MM


– Finance, Healthcare, Telecom

• Object ID assigned

• Some support for inheritance

• Sharp learning curve

Object-relational databases

• Relational databases extended to

handle the storage of objects

• Use of user-defined data types

• Extended SQL to handle complex

object data

• Inheritance tends to be language


Comparing object storage formats

Mapping to object-persistence


• Storing the problem domain (PD) objects

introduces conversion requirements

• Put functionality for storing and retrieving


data management

(DM) layer

– DM classes dependent on PD classes, not vice versa

• Add primary and foreign keys

– Unless they add too much overhead

Appointment System: PD and

DM Layers

Patient Appt PD Layer DM Layer DM-Patient DM-Appt contains methods for storing and retrieving Appt-objects

Mapping to an OODB

factoring out MI in 2 different ways Superclass1 -attribute1 -attribute2 Superclass2 -attribute3 -attribute4 Class1 -attribute5 -attribute6 Superclass1 -attribute1 -attribute2 Class1 -attribute5 -attribute6 Superclass2 -attribute3 -attribute4 1 1 Superclass1 -attribute1 -attribute2 Class1 -attribute3 -attribute4 -attribute5 -attribute6


Mapping PD objects to ORDBMS


1. Map PD classes to DM classes and tables 2. Map attributes to

columns; distinguish

1. elementary types 2. set types 3. class types (object

ID’s) 4. derived attributes Class -attr1: elem_type -attr2: set_type -attr3: class_type Patient DM-Patient Patient_Table these types of attributes are supported by the ORDBMS tables

Mapping PD objects to ORDBMS


3. Map inheritance to associations 4. Map associations to columns (object ID’s) Class1 Class2 Superclass Class1_Table Class2_Table Superclass_tbl -Superclass_table[1..1] -Class2_table[1..*] 1 Class1_Table 1..*

Mapping PD objects to ORDBMS


Patient Appt Person Symptom 0..* 1..* Patient_Table -Person_Table[1..1] -Appts[0..*] -Symptoms[1..*] -name: String 0..* Symptom_Table -name[1..1] -Patients[0..*]

Also add read/write methods in DM_Patient and other DM classes

Person_Table Appt_Table -name[1..1] ... -date[1..1] ... 1

Mapping PD objects to RDBMS


• Get rid of multivalued attributes • Replace object ID’s by foreign keys

Patient_Table -Person_ID ... Person_Table Appt_Table -name -Person_ID ... -date -Person_ID Symp_Table -name -Symp_ID Pat_Symp_Table -Person_ID -Symp_ID Patient Appt Person Symptom 0..* 1..* -name: String 0..* 1

Navigation is not preserved

Album title Track title 1 * «table» Albums key title «table» Tracks key albumKey title

Building a DM layer

• Very complicated to map to an RDBMS

• Several design patterns can be used

(see link on MSO website)

• Many tools are now available


Optimizing RDBMS-based object


• Two dimensions for optimization:

– Storage efficiency (minimizing storage space)

– Speed of access (minimizing time to retrieve desired information)

Optimizing storage efficiency

• Reduce redundant data

• Limit null values

– Multiple possible interpretations can

lead to mistakes

• A well-formed logical data model does

not contain redundancy or many null



• A model is in first normal form (1NF) if

it does not lead to multi-valued fields or

repeating fields

– Every row has the same number of columns

– All fields contain precisely one value


Order -Order_no -Cust_ID -Date -Last_Name -First_Name -State -Tax_Rate Prod_Order -Order_no -Product_no -Product_descr -Product_price -Product_qty 1..* 0..*

1NF: repeating product fields in original Order table are now in a separate table. However, there are still partial dependencies.


Order -Order_no -Cust_ID -Date -State -Tax_Rate Prod_Order -Order_no -Product_no -Product_qty 1..* 0..* Customer -Cust_ID -Last_Name -First_Name Product -Product_no -Product_descr -Product_price 0..* 1..1

2NF: With partial dependencies removed there only remains a transitivedependency: the Tax rate depends only on the State.


Order -Order_no -Cust_ID -Date -State Prod_Order -Order_no -Product_no -Product_qty 1..* 0..* Customer -Cust_ID -Last_Name -First_Name Product -Product_no -Product_descr -Product_price 0..* 1..1

3NF: With OO-modelling you would obtain a similar model right away!


-State -Tax_Rate



Optimizing data access speed

• Denormalize by

adding fields:

– of look-up tables – of tables in 1-1 relationship Order -Order_no -Date -Payment_type -Payment_desc 0..* Payment_type -Payment_type -Payment_desc 1..1

Optimizing data access speed

• Clustering

– put similar records close together on the hard disk

• Indexing

– more space (additional tables)

– more speed (especially when index is put in memory) when retrieving data

– less speed when updating data

Payment Type Index

Guidelines for creating indexes

• Use indexes sparingly for transactionsystems • Use many indexes to increase response times

in decision supportsystems • For each table

– Create a unique index based on the primary key – Create an index based on the foreign key

• Create an index for fields used frequently for grouping or sorting




Related subjects : Files and Databases