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

8. 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 Evolution of Data Models 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. primary key foreign key No physical link data of type 1 data of type 2 data of type k ……… data of type k+1 ……… data of type k data of type n-1 Relational Data Model (cont.) • 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 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 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. 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 changes state Observer queries the Subject Subject checks validity of change Change valid? No Yes Subject accepts the change Subject rejects the change Subject notifies other observers 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 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.

24. Family Tree Database System and Observer Design Pattern

25. Observers Person Data Entry Form (PDEF) Family Tree Graphical Interface (FTGI) People Data Storage and Manipulation (PDSAM) Relationship Data Storage and Manipulation (RDSAM) Subjects High Level Overview of FTDB System

26. High Level Overview of FTDB System (cont.) • FTDBSystem – 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 each Transaction. These messages are also automatically saved in a log file

29. People Data Storage and Manipulation universalColor Gender hairColor eyeColor People List myUtilities Person 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. End User Mouse click Display New Info FTGI HMI New Info? Yes(true) + New Info No(false) PDSAM object group FTGI HMI – Observer queries the subject

35. FTGI HMI - Creation of New H-W Relationship

36. boxes Husband-Wife relationships Father –Son relationship Father-Daughter relationship Mother-Son relationship Mother-Daughter relationship Sister-Sister relationship Brother-Brother relationship Sister-Brother relationship buttons relationship labels FTGI - Drawing Menu

37. MW class End User FTGI observer object group Lines FTGI class Drawing Menu Circles PDSAM subject object group RDSAM subject object group PDSAM class RDSAM class FTGI Observer

38. PDSAM subject object group FTGI observer object group PDSAM class FTGI class RDSAM subject object group RDSAM class <rel_name_list> class RDSAM Subject

39. HWL Class – Possible Consistency Search Results

40. Husband-Wife Relationship Existence Rules

41. H-W relationship consistency checking roadmap

42. PDSAM class PL class People_List Person class The PDSAM Subject – PL Class • Rules 1 and 2: • Male (P1) • Female (P2)

43. RDSAM class HWL class Husband_Wife_List HW class 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. Sister-Brother relationships New type relationship X P1 X P2 Selecting the New Relationship Type

50. 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 New relationship data Generated/ violated New Relationship group object Baselined relationship group objects Check for validity/ store Check for validity/ create new relationship type object Violate/ don’t violate integrity New relationship data <rel_name_objects> Automatic Generation of Relationship Types and Existence Rules