mark j. tseytlin 11/08/2002

1

THE OBSERVER DESIGN PATTERN AND THE MAINTENANCE OF CONSISTENCY

CONSTRAINTS IN AN OBJECT-ORIENTED DATABASE

Mark J. Tseytlin

11/08/2002

2

Initial Thoughts

• One of the current trends in database theory is towards total object orientation [WK95]

• Problem: Current totally OODB’s are not as robust as RDB’s

• Reason: The need to maintain consistency between related objects in an OODB [GHJVB95]

• Solution: Consistency or Integrity constraints are used to govern the procedural actions needed to maintain consistency in a database

• The observer pattern [GHJVB95] is a software design pattern that creates a new outlook on the implementation of actions to maintain consistency constraints in object-oriented systems.

3

Objectives of the Study

• Implement a concrete database system that illustrates the concept of observer pattern

• Keep this database system as totally Object-Oriented as possible to prove usability and feasibility of the observer pattern for OODB applications

• Investigate maintenance of consistency rules that are used for consistency checks during database transactions.

4

History and Introduction

5

Data Models and Their Evolution

6

A Typical Database SystemDatabase systems are computerized systems in which the interpretation and storage of information are of primary importance [MD92].

7

A Typical Database System (cont.)

• Conceptual Schema - database designer’s view of the system

• DML - Data Modeling Language that is used to implement the logical databasedescription

• DBMS - Database Management System is a software package that supports the implementation of a database and performs operations on the data that is stored in thedatabase. These operations include:- storage of the data in a database- search and manipulation of stored data- display/receipt of old/new data to/from the end user

• The characteristics of these operations are directly dependent on the data model used as the conceptual guideline for the implementation of the DBMS

• HMI - Human Machine Interface is the end user’s view of the database system

8

Evolution of Data Models

Variable length records and files

Flat files Relational data model

Object-relational data model

Semantic data models

Object-oriented data model

Hierarchical data model

Network data model

Data model refers to a model used for the design of database schemas

9

Flat File

• Contain fixed length records• Can’t have repeating groups of information, i.e. the data has to be continuous [DK97]• Are widely used in relational databases

10

Relational Data Model

• It was the first to exemplify a model and a query language in which the layout of the data on a disk drive was not determined by the data model [EN00]

• It was implemented by employment of one level of abstraction with a mapping from the database schema to the physical layout of the data

• Flat file structure was used, but data was organized into normalized relations to prevent data-anomalies caused by manipulation of the data

11

Relational Data Model (cont.)

• Normalized relations - the table• Relation - a cell in the table that contains a singular value• Attribute - a column in the table that contains data from one domain• Tuple - a row in the table that must contain unique information- Each tuple contains a logical key or index that makes it unique

12

Relational Data Model (cont.)

data of type 1

data of type 2

………

data of type k data of type k

data of type k+1

………

data of type n-1

No physical link

primary key

foreign key

• Foreign key – a primary key of a data structure that’s included in another data structure in order to connect the two with a data relation instead of a pointer [JO98]

13

OO Data Model

• OO Data Model was fist to allow more complete representation of real-world objects in computing [JO98]

• Encapsulation – incorporation of behavior of real-world object into the class that defines such object

• Specialization – extension of a general definition of an object with a specializeddefinition

• Database constraints defined on the highest level – abstract class level

• Insertion - creation of a new object

• Insertion constraints – rules that govern the creation process in order to keep thedatabase consistent [MD92]

14

OO Data Model (cont.)

15

OO Data Model (cont.)

• Most current OO Databases still don’t include full non-procedural query language and views [WK95]

• Many OO systems bear the cost of being implemented as a set of concrete classes[PMD95]

• Designs should be specific enough to the problem at hand, but general enough to address future problems and requirements [GHJVB95]

• Most OO systems employ similar classes and communicating objects arranged in reoccurring patterns

16

Object Oriented Design Patterns

17

OO Design Patterns - Elements

Essential elements [GHJVB95]:

• Pattern name - a handle describing a design pattern in context of the concept that this pattern represents

• Problem - suggests when the pattern should be applied

• Solution - a schema of the design with relationships, responsibilities and collaborations

• Consequences - represent the pros and cons of applying the pattern to the design

18

Main questions [GHJVB95]:

• What does the design pattern do? - determine the purpose of each design pattern in search of best pattern for use • What are the situations in which this design pattern is applicable for use? - determine if the pattern selected is consistent with the purpose of the target software • Which classes are in the design and how do they collaborate to keep the design consistent? - determined whether the number and type of classes necessary for implementation of the pattern are reasonable for the implementation at hand • How does the pattern support its objectives and what are the trade-offs and results of using the pattern? - analyze the scope of the required operations, as well as the system and software requirements necessary to support these operations

OO Design Patterns - Questions

19

Observer Design Pattern

Observer design pattern is intended to define a one-to-many relationship among objects so that they exhibit “active” behavior [GHJVB95]

Active behavior - when one object changes state, all its dependents are notified and updated automatically

- Observer query the subject - observer changes its state and requests commitment notification, from the subject. The subject accepts change and propagates it to all its dependent observers (also known as publish-subscribe method) [GHJVB95]

- Observers register with the subject - when specific event occurs and only in this case, an observer gets a change of state notification from the subject. This is the most efficient method. The modifications of interest are specified explicitly [GHJVB95].

20

Observer Design Pattern

Subject – the data object Observers – the user interface objects Note: all objects are completely independent of each other

21

Observer Design Pattern - Observer Query the Subject

Observer changes state

Observer queries the Subject

Subject checks validity of change

Subject accepts the change

Change valid?YesNo

Subject rejects the change

Subject notifies other observers

22

JAVA Programming Language

23

JAVA language

• JAVA is a totally object oriented language. This is very useful for the purposesof creating a totally object-oriented database.

• JAVA is free of pointers. This property makes JAVA highly portable.

• In JAVA, strings are objects. The advantage of this representation is that JAVA’sstrings cannot be accidentally overwritten. Also, JAVA’s string representation savesstorage space.

• JAVA language lacks multiple inheritance. This is very useful in a complex object oriented database environment where records are implemented as instancesof compound objects. • JAVA supports multithreading. This feature allows running concurrent operations. Concurrency is a key feature of modern database systems.

24

Family Tree Database System and Observer Design Pattern

25

High Level Overview of FTDB SystemObservers

Person Data Entry Form(PDEF)

Family Tree Graphical Interface(FTGI)

People Data Storage and Manipulation

(PDSAM)

Relationship Data Storage and Manipulation

(RDSAM)

Subjects

26

High Level Overview of FTDB System (cont.)• FTDB System – an OO database system that stores and manipulates people’s records and family type relationships

• FTDB - a concrete database system implementation that uses concepts of the observer pattern. It uses “publish-subscribe” observer design pattern strategy with explicit specification of modifications of interest.

• Observers and subjects are implemented as completely autonomous sets of classes that correctly implement observer pattern characteristics.

• Subject object groups employ “change managers” to map subjects to their dependent observers, define update strategy, and notify all dependent observers in the event of a change

• The end user is able to enter information through one of the two HMIs

• The system checks consistency constraints when an attempt is made to enter a new record, modify existing record, or new family relationship is proposed

27

The Observers - PDEF

• Data can be entered via keyboard or by accessing an input file

• Data is checked for consistency

• This HMI accepts complete new records and modifications to existing records

• Consistency checks are performed upon any insertion/modification attempts

• The message window shows OK/ERROR result for each transaction. These messages are also automatically saved in a log file

• All modifications are automatically saved in an output file after the application is terminated

28

The Observers - FTGI• Used to graphically represent relationships among Person objects contained by the DB

• Each relationship type is color-coded

• Each new relationship is subject to satisfying existence rules

• The message window shows OK/ERROR result for eachTransaction. These messages are also automatically saved in a log file

29

The Subjects - PDSAM

universalColor

hairColor eyeColor

Gender

Person

People Data Storage and Manipulation

People List

myUtilities

• Used to facilitate the storage of people data entered via PDEF interface • Checks consistency between observers

• Propagates changes made via PDEF to FTGI

• PDSAM object is a “change manager” for the group that facilitates all consistency checks when a record is entered or modified and when a new family type relationship is created

30

The Subjects - RDSAM

• RDSAM object is a “change manager” that coordinates consistency checks when new relationship is entered

• Consistency checking is accomplished based on consistency rules

• Consistency rules are applied using existing relationships

• System supports marriage, ancestry, and sibling relationshipgroups

31

FTDB – Example of Operation

OODB, Observer Pattern, and Consistency Constraints

32

PDEF HMI – Records Imported from File

33

FTGI HMI – Initial Set of Records

34

FTGI HMI – Observer queries the subject

Mouse click

End User

PDSAM object group

New Info?

Yes(true) + New Info No(false)

Display New Info

FTGI HMI

35

FTGI HMI - Creation of New H-W Relationship

36

FTGI - Drawing Menu

relationshiplabels

buttons

Father –Son relationship

Father-Daughter relationship

Mother-Son relationship

Mother-Daughter relationship

Sister-Sister relationship

Brother-Brother relationship

Sister-Brother relationship

Husband-Wife relationships

boxes

37

FTGI Observer

RDSAM subject object group

PDSAM subject object group

FTGI observer object group

MW class

PDSAM class

RDSAM class

End User

CirclesDrawing

Menu

FTGI class

Lines

38

RDSAM Subject

FTGI observer object group

PDSAM subjectobject group

RDSAM subjectobject group

PDSAM class

FTGI class

<rel_name_list> class

RDSAM class

39

HWL Class – Possible Consistency Search Results

Search type Finding Message returned

D duplicate ERROR: DUPLICATE Husband(P1)-Wife(P2)

N Husband(P1)-Wife(P3) ERROR: Husband(P1)-Wife(P2) RELATIONSHIP NOT (Husband-Wife (P1, P3))

N Husband(P3)-Wife(P2) ERROR: Husband(P1)-Wife(P2) RELATIONSHIP NOT (Husband-Wife (P3, P2))

D no duplicates OK Husband(P1)-Wife(P2) DUPLICATE and list of rules from Table 3.2-2

N no inconsistencies OK Husband(P1)-Wife(P2) NOT (Husband-Wife (P1, P2))

40

Husband-Wife Relationship Existence Rules

Rule#

Rule Consistency Checked by class

1 Male (P1) PL class2 Female (P2) PL class3 Not (Husband-Wife (P1, P3)) HWL class4 Not (Husband-Wife (P3, P2)) HWL class5 Not (Sister-Brother (P2, P1)) SBL class6 Not (Father-Daughter (P1, P2)) FDL class7 Not (Mother-Son (P2, P1)) MSL class

41

H-W relationship consistency checking roadmap

42

The PDSAM Subject – PL Class

PL class

People_List

PDSAM class

Person class

Rules 1 and 2:1. Male (P1)

2. Female (P2)

43

The RDSAM Subject – HWL Class

Rules 3 and 4:3. Not (Husband-Wife (P1, P3))

4. Not (Husband-Wife (P3, P2))

HWL class

Husband_Wife_List

RDSAM class

HW class

44

HWL Class – Possible Consistency Search Results

Search type Finding Message returned

D duplicate ERROR: DUPLICATE Husband(P1)-Wife(P2)

N Husband(P1)-Wife(P3) ERROR: Husband(P1)-Wife(P2) RELATIONSHIP NOT (Husband-Wife (P1, P3))

N Husband(P3)-Wife(P2) ERROR: Husband(P1)-Wife(P2) RELATIONSHIP NOT (Husband-Wife (P3, P2))

D no duplicates OK Husband(P1)-Wife(P2) DUPLICATE and list of rules from Table 3.2-2

N no inconsistencies OK Husband(P1)-Wife(P2) NOT (Husband-Wife (P1, P2))

45

FTGI HMI – ERROR new H-W Relationship

46

Future Work

47

Further Abstraction of the RDSAM Object Group

48

RDSAM Abstraction (cont.)• This is a better design -reduces the number of interfaces and couplings among objects, but still exhibits modularity needed for different functionality.-RDSAM object is a true “change manager” rather an integral part of the RDSAMsubject object group

• Inter-group coordination- consistency checks are done on the relationship group object level- objects of the RDSAM subject object group remain a cooperating collection ofobjects responsible for maintenance of relationship consistency constraints

49

Selecting the New Relationship Type

Sister-Brother relationships

New type relationship X

X

P1

P2

50

Automatic Generation of Relationship Types and Existence Rules

New relationship data

New relationship data Valid new relationship/ new relationship type

New relationship data

Check for validity/ store

<rel_name_objects>

New relationship data

Generated/ violated

Baselined relationship group objects

New Relationship group

object

New relationship data

Check for validity/ create new relationship type

object

Violate/ don’t violate integrity

DM object MW object

Report action results Create new menu choice on the DM

FTGI object

Valid new relationship/ new relationship type

Relationship object

RDSAM object

51

Results of Pattern Matching Exercise

XP1P6 P2

P4 P5P3

Rule #

Pattern Matching Result

Rule

1 Male (P1) Male (X)

2 Female (P2) Female (Y)

3 Husband-Wife (P1, P6) Not (Husband-Wife (X,Y))

4 Father-Son (P3,P1) --

5 Father-Daughter (P5,P2) --

6 Mother-Son (P4,P1) Mother-Son (Z,X)

7 Mother-Daughter (P4,P2) Mother-Daughter (Z,Y)

52

New Half-Sister--Half-Brother Relationship

Sister-Brother relationships

Half_Sister-Half_Brother relationship

New Type relationship X

P2

P1

53

Summary

54

Accomplishment of Objectives

• FTDB System is a concrete database system that illustrates the concept of observer pattern. It uses “publish-subscribe” strategy with explicit specification of modifications of interest.

• FTDB is implemented in JAVA which is a totally OO programming language. The design of the database is specific enough for the problem at hand, yet it’s flexible enough to address future requirements.

• Complete investigation of maintenance of a subset of relationship consistency rules was conducted during this study. Also, a possible solution was proposed for automatic generation of existence rules.

55

The end