Download View defense presentation

THE OBSERVER DESIGN PATTERN AND
THE MAINTENANCE OF CONSISTENCY
CONSTRAINTS
IN AN OBJECT-ORIENTED DATABASE
Mark J. Tseytlin
11/08/2002
1
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.
2
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.
3
History and Introduction
4
Data Models and Their
Evolution
5
A Typical Database System
Database systems are computerized systems in which the interpretation and
storage of information are of primary importance [MD92].
6
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 database
description
• 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 the
database. 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
7
Evolution of Data Models
Object-relational data
model
Variable length
records and files
Flat files
Relational data model
Semantic data models
Hierarchical data
model
Network data model
Object-oriented data
model
Data model refers to a model used for the design of database schemas
8
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
9
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
10
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
11
Relational Data Model (cont.)
data of type 1
data of type 2
………
primary key
foreign key
data of type k
data of type k
data of type k+1
No physical link
………
data of type n-1
• 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]
12
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 specialized
definition
• 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 the
database consistent [MD92]
13
OO Data Model (cont.)
14
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
15
Object Oriented Design
Patterns
16
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
17
OO Design Patterns - Questions
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
18
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].
19
Observer Design Pattern
Subject – the data object
Observers – the user interface objects
Note: all objects are completely independent of each other
20
Observer Design Pattern - Observer Query the Subject
Observer changes state
Observer queries the Subject
Subject checks validity of change
No
Subject rejects the
change
Change valid?
Yes
Subject accepts the
change
Subject notifies other
observers
21
JAVA Programming Language
22
JAVA language
• JAVA is a totally object oriented language. This is very useful for the purposes
of 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’s
strings cannot be accidentally overwritten. Also, JAVA’s string representation saves
storage space.
• JAVA language lacks multiple inheritance. This is very useful in a complex
object oriented database environment where records are implemented as instances
of compound objects.
• JAVA supports multithreading. This feature allows running concurrent operations.
Concurrency is a key feature of modern database systems.
23
Family Tree Database System
and Observer Design Pattern
24
High Level Overview of FTDB System
Observers
Person Data Entry Form
(PDEF)
Family Tree Graphical Interface
(FTGI)
People Data Storage and
Manipulation
(PDSAM)
Relationship Data Storage and
Manipulation
(RDSAM)
Subjects
25
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 26
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
27
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 each
Transaction. These messages
are also automatically saved
in a log file
28
The Subjects - PDSAM
People Data Storage
and Manipulation
Gender
People
List
myUtilities
universalColor
hairColor
eyeColor
Person
• 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
29
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 relationship
groups
30
FTDB – Example of Operation
OODB, Observer Pattern, and
Consistency Constraints
31
PDEF HMI – Records Imported from File
32
FTGI HMI – Initial Set of Records
33
FTGI HMI – Observer queries the subject
End User
Mouse click
Display New Info
FTGI HMI
New Info?
Yes(true) + New Info
No(false)
PDSAM object group
34
FTGI HMI - Creation of New H-W Relationship
35
FTGI - Drawing Menu
boxes
Husband-Wife relationships
Father –Son relationship
Father-Daughter relationship
Mother-Son relationship
buttons
relationship
labels
Mother-Daughter relationship
Sister-Sister relationship
Brother-Brother relationship
Sister-Brother relationship
36
FTGI Observer
MW class
End User
FTGI observer object group
Lines
FTGI class
Drawing
Menu
Circles
PDSAM subject
object group
PDSAM
class
RDSAM
class
RDSAM subject
object group
37
RDSAM Subject
PDSAM subject
object group
PDSAM
class
RDSAM subject
object group
FTGI class
FTGI observer
object group
RDSAM class
<rel_name_list> class
38
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))
39
Husband-Wife Relationship Existence Rules
Rule
#
Rule
1
2
3
4
5
6
7
Male (P1)
Female (P2)
Not (Husband-Wife (P1, P3))
Not (Husband-Wife (P3, P2))
Not (Sister-Brother (P2, P1))
Not (Father-Daughter (P1, P2))
Not (Mother-Son (P2, P1))
Consistency Checked by class
PL class
PL class
HWL class
HWL class
SBL class
FDL class
MSL class
40
H-W relationship consistency checking roadmap
41
The PDSAM Subject – PL Class
Rules 1 and 2:
1. Male (P1)
2. Female (P2)
PDSAM class
PL class
People_List
Person class
42
The RDSAM Subject – HWL Class
RDSAM class
HWL class
Husband_Wife_List
HW class
Rules 3 and 4:
3. Not (Husband-Wife (P1, P3))
4. Not (Husband-Wife (P3, P2))
43
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))
44
FTGI HMI – ERROR new H-W Relationship
45
Future Work
46
Further Abstraction of the RDSAM Object Group
47
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 RDSAM
subject 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 of
objects responsible for maintenance of relationship consistency constraints
48
Selecting the New Relationship Type
Sister-Brother relationships
X
New type relationship
P1
X
P2
49
Automatic Generation of Relationship Types and
Existence Rules
MW object
DM object
Report action results
Create new menu
choice on the DM
FTGI object
New relationship data
Valid new relationship/ new relationship
type
RDSAM object
New relationship data
Valid new relationship/ new relationship
type
Relationship object
New relationship data
Check for validity/ store
New relationship data
Generated/
violated
New
Relationship group
Baselined relationship
group objects
New relationship data
object
Check for validity/ create
new relationship type
object
Violate/ don’t violate
integrity
<rel_name_objects>
50
Results of Pattern Matching Exercise
P3
P6
Rule
#
P4
P1
P5
X
Pattern Matching
Result
P2
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)
51
New Half-Sister--Half-Brother Relationship
Sister-Brother relationships
Half_Sister-Half_Brother relationship
X
New Type relationship
P1
P2
52
Summary
53
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.
54
The end
55