THE OBSERVER DESIGN PATTERN AND THE MAINTENANCE OF CONSISTENCY CONSTRAINTS IN AN OBJECT-ORIENTED DATABASE

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 OODBs are not as robust
  as RDBs
• 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 System
Database 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 designers 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 users view of the database system
8
Evolution of Data Models
Data model refers to a model used for the design
of database schemas
9
Flat File
Contain fixed length records Cant 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.)
Foreign key a primary key of a data structure
thats 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 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
14
OO Data Model (cont.)
15
OO Data Model (cont.)
Most current OO Databases still dont 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
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
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
22
JAVA Programming Language
23
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
JAVAs strings cannot be accidentally
overwritten. Also, JAVAs 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.
24
Family Tree Database System and Observer Design
Pattern
25
High Level Overview of FTDB System
26
High Level Overview of FTDB System (cont.)
FTDB System an OO database system that stores
and manipulates peoples 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 each Transaction. These messages are
also automatically saved in a log file
29
The Subjects - PDSAM
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 relationship groups
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
35
FTGI HMI - Creation of New H-W Relationship
36
FTGI - Drawing Menu
37
FTGI Observer
38
RDSAM Subject
39
HWL Class Possible Consistency Search Results
40
Husband-Wife Relationship Existence Rules
41
H-W relationship consistency checking roadmap
42
The PDSAM Subject PL Class

• Rules 1 and 2
• Male (P1)
• Female (P2)

43
The RDSAM Subject HWL Class
Rules 3 and 4 3. Not (Husband-Wife (P1, P3)) 4.
Not (Husband-Wife (P3, P2))
44
HWL Class Possible Consistency Search Results
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 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

49
Selecting the New Relationship Type
50
Automatic Generation of Relationship Types and
Existence Rules
51
Results of Pattern Matching Exercise
52
New Half-Sister--Half-Brother Relationship
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 its 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