mark j. tseytlin 11/08/2002

55
1 THE OBSERVER DESIGN PATTERN AND THE MAINTENANCE OF CONSISTENCY CONSTRAINTS IN AN OBJECT-ORIENTED DATABASE Mark J. Tseytlin 11/08/2002

Upload: wayne

Post on 13-Jan-2016

27 views

Category:

Documents


2 download

DESCRIPTION

THE OBSERVER DESIGN PATTERN AND THE MAINTENANCE OF CONSISTENCY CONSTRAINTS IN AN OBJECT-ORIENTED DATABASE. Mark J. Tseytlin 11/08/2002. Initial Thoughts. One of the current trends in database theory is towards total object orientation [WK95] - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: 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

Page 2: 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.

Page 3: Mark J. Tseytlin 11/08/2002

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.

Page 4: Mark J. Tseytlin 11/08/2002

4

History and Introduction

Page 5: Mark J. Tseytlin 11/08/2002

5

Data Models and Their Evolution

Page 6: Mark J. Tseytlin 11/08/2002

6

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

Page 7: Mark J. Tseytlin 11/08/2002

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

Page 8: Mark J. Tseytlin 11/08/2002

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

Page 9: Mark J. Tseytlin 11/08/2002

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

Page 10: Mark J. Tseytlin 11/08/2002

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

Page 11: Mark J. Tseytlin 11/08/2002

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

Page 12: Mark J. Tseytlin 11/08/2002

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]

Page 13: Mark J. Tseytlin 11/08/2002

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]

Page 14: Mark J. Tseytlin 11/08/2002

14

OO Data Model (cont.)

Page 15: Mark J. Tseytlin 11/08/2002

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

Page 16: Mark J. Tseytlin 11/08/2002

16

Object Oriented Design Patterns

Page 17: Mark J. Tseytlin 11/08/2002

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

Page 18: Mark J. Tseytlin 11/08/2002

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

Page 19: Mark J. Tseytlin 11/08/2002

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].

Page 20: Mark J. Tseytlin 11/08/2002

20

Observer Design Pattern

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

Page 21: Mark J. Tseytlin 11/08/2002

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

Page 22: Mark J. Tseytlin 11/08/2002

22

JAVA Programming Language

Page 23: Mark J. Tseytlin 11/08/2002

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.

Page 24: Mark J. Tseytlin 11/08/2002

24

Family Tree Database System and Observer Design Pattern

Page 25: Mark J. Tseytlin 11/08/2002

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

Page 26: Mark J. Tseytlin 11/08/2002

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

Page 27: Mark J. Tseytlin 11/08/2002

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

Page 28: Mark J. Tseytlin 11/08/2002

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

Page 29: Mark J. Tseytlin 11/08/2002

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

Page 30: Mark J. Tseytlin 11/08/2002

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

Page 31: Mark J. Tseytlin 11/08/2002

31

FTDB – Example of Operation

OODB, Observer Pattern, and Consistency Constraints

Page 32: Mark J. Tseytlin 11/08/2002

32

PDEF HMI – Records Imported from File

Page 33: Mark J. Tseytlin 11/08/2002

33

FTGI HMI – Initial Set of Records

Page 34: Mark J. Tseytlin 11/08/2002

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

Page 35: Mark J. Tseytlin 11/08/2002

35

FTGI HMI - Creation of New H-W Relationship

Page 36: Mark J. Tseytlin 11/08/2002

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

Page 37: Mark J. Tseytlin 11/08/2002

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

Page 38: Mark J. Tseytlin 11/08/2002

38

RDSAM Subject

FTGI observer object group

PDSAM subjectobject group

RDSAM subjectobject group

PDSAM class

FTGI class

<rel_name_list> class

RDSAM class

Page 39: Mark J. Tseytlin 11/08/2002

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))

Page 40: Mark J. Tseytlin 11/08/2002

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

Page 41: Mark J. Tseytlin 11/08/2002

41

H-W relationship consistency checking roadmap

Page 42: Mark J. Tseytlin 11/08/2002

42

The PDSAM Subject – PL Class

PL class

People_List

PDSAM class

Person class

Rules 1 and 2:1. Male (P1)

2. Female (P2)

Page 43: Mark J. Tseytlin 11/08/2002

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

Page 44: Mark J. Tseytlin 11/08/2002

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))

Page 45: Mark J. Tseytlin 11/08/2002

45

FTGI HMI – ERROR new H-W Relationship

Page 46: Mark J. Tseytlin 11/08/2002

46

Future Work

Page 47: Mark J. Tseytlin 11/08/2002

47

Further Abstraction of the RDSAM Object Group

Page 48: Mark J. Tseytlin 11/08/2002

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

Page 49: Mark J. Tseytlin 11/08/2002

49

Selecting the New Relationship Type

Sister-Brother relationships

New type relationship X

X

P1

P2

Page 50: Mark J. Tseytlin 11/08/2002

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

Page 51: Mark J. Tseytlin 11/08/2002

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)

Page 52: Mark J. Tseytlin 11/08/2002

52

New Half-Sister--Half-Brother Relationship

Sister-Brother relationships

Half_Sister-Half_Brother relationship

New Type relationship X

P2

P1

Page 53: Mark J. Tseytlin 11/08/2002

53

Summary

Page 54: Mark J. Tseytlin 11/08/2002

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.

Page 55: Mark J. Tseytlin 11/08/2002

55

The end