Download GoFforRelDB - Computer Science Home

Software Engineering Design Patterns
for Relational Databases
Cyril S. Ku
Department of Computer Science, William Paterson University
Thomas J. Marlowe
Dept. of Math & Computer Science, Seton Hall University
Tatyana Budanskaya
Dept. of Computer Science, New Jersey Institute of Technology
Philip K. Kang
Department of Computer Science, William Paterson University
SERP’07
Las Vegas, Nevada, USA
June 26-28, 2007
Presentation Overview
 I. Introduction
 Entity-Relationship/Extended Entity-Relationship model and
Relational model
 The UML (Unified Modeling Language), design patterns, and
the Unified Process
 Research benefits
 II. Generic Software Engineering Design Patterns
 GRASP (General Responsibility Assignment Software
Patterns)
 GoF (“Gang-of-Four”) design patterns
 III. Application of Design Patterns to Relational
Databases
 GoF examples
 IV. Conclusion and Future Research
1
I. Introduction
 Entity-Relationship (ER)/Extended ER (EER) Model
 Specification and design tool for database
 Data oriented model
 Relational Database
 Direct mapping from ER/EER model to relational model
 Separation of data (e.g., DDL – Data Definition Language) and
process (e.g., DML – Data Manipulation Language)
 Since database is a software system, the specification,
design, and development of databases should follow the
software development life cycle of any large scale software
project
 The UML
 Standard notation for software specification and design
 Map ER/EER diagram to UML Class Diagram, then map class
diagram to relational tables
2
I. Introduction (cont’d)
 Design Patterns
 Capture common idioms, patterns, and guidelines in the
software design and development process
 Facilitate flexibility, extensibility, maintainability, reusability
 Specified by the UML
 Use in software design and development but confine to
domain-specific patterns in databases
 The Unified Process
 An incremental and iterative software life cycle model
 The use of the UML, design patterns, and the Unified Process
becomes the standard suite of tools for modern software
engineering
 Our research attempts to use this suite of tools for relational
database design and development; focusing on generic
software engineering patterns, not domain-specific patterns
3
I. Introduction (cont’d)
 Research Benefits
 Standardize design and development of relational database
system with modern software engineering methodology
 Better communication and make connection with any
software project
 The cost of learning and training is amortized across all
types of software development efforts
 Connect design and development across the computer
science (at least software engineering and database courses)
curriculum
 Increase portability of design between a relational approach
and an object-oriented or object-relational approach
 Design patterns produce better and faster design in software
engineering. This research should result in better and faster
database design and development
4
II. Generic Software Engineering
Design Patterns
 GRASP (Craig Larman)
 General guidelines for class design and responsibility
assignment
 Pattern/principle: Information Expert, Creator, Controller,
Evaluative (Low Coupling, High Cohesion), Polymorphism,
Pure Fabrication, Indirection, Protected Variations
 Research published: Ku, C. S., Marlowe, T. J., and Mantell, N. M., “Design
Patterns across Software Engineering and Relational Databases,” Proceedings of the
15th International Conference on Software Engineering and Data Engineering (SEDE2006), Los Angeles, California, USA, pages 271-274, July 6-8, 2006.
 GoF (Gamma, Helm, Johnson, Vlissides)
 Building-block patterns that provide design and code
scaffolding
 Three varieties: Creational, Structural, Behavioral
 Preliminary research done: Marlowe, T. J., Ku, C. S., and Benham, J. W.,
“Design Patterns for Database Pedagogy – A Proposal,” Proceedings of the 36th
SIGCSE Technical Symposium on Computer Science Education (SIGCSE 2005), St.
Louis, Missouri, ACM Press, pages 48-52, February 23-27, 2005.
 This presentation focuses on the application of GoF patterns
5
III. Application to Relational Databases
 An Example – The Façade Pattern
Façade
Subsystems
Facade
Subsystem
Facade
Legacy
Database
Data Mart
Subsystem
Subsystem
Data
Warehouse
Operational
Database
6
III. Application to Relational Databases
 Creational – Builder
 Separate the construction of a complex object from its
representation so that the same construction process can
create different representations
 Construction of the aggregate and composite tables in
relational databases
 Creation of logical schemas (relational tables)
 Structural – Adapter
 Convert the interface of a class into another interface clients
expect. Adapter lets classes work together that couldn’t
otherwise because of incompatible interfaces
 User interface to query language translation
 Interface between table-oriented DBMS layer and file
management layer
 Interface between OLTP (On-Line Transaction Processing)
system and OLAP (On-Line Analytical Processing) system
7
III. Application to Relational Databases
(cont’d)
 Structural – Bridge
 Decouple an abstraction from its implementation so that the
two can vary independently
 Basically the same as Adapter for logical and physical data
independence concept
 Structural – Composite
 Compose objects into tree structures to represent part-whole
hierarchies. Composite lets clients treat individual objects and
compositions of objects uniformly
 Implementation of the aggregation and composition concept in
relational databases
 Table traversal of complex queries (or access plan) with Visitor
8
III. Application to Relational Databases
(cont’d)
 Structural – Decorator
 Attach additional responsibilities to an object dynamically.
Decorators provide a flexible alternative to subclassing for
extending functionality
 Specific realizations of unions (superclass/subclass
relationship) can be instances of Decorator
 Structural – Facade
 Provide a unified interface to a set of interfaces in a
subsystem. Façade defines a higher-level interface that makes
the subsystem easier to use
 Interface between data warehouse/data mart and operational
databases
 Interfaces among distributed database (not necessary
relational) systems
9
III. Application to Relational Databases
(cont’d)
 Structural – Proxy
 Provide a surrogate or placeholder for another object to
control access to it
 Enforce various database constraints (access control or
security) in relational databases
 Behavioral – Command
 Encapsulate a request as an object, thereby letting you
parameterize clients with different requests, queue or log
requests, and support undoable operations
 Enforce domain, key, and referential integrity constraints by
rejecting or modifying illegal updates (with Proxy)
 Behavioral – Iterator
 Provide a way to access the elements of an aggregate object
sequentially without exposing its underlying representation
 Table traversal for simple queries
10
III. Application to Relational Databases
(cont’d)
 Behavioral – Mediator
 Define an object that encapsulates how a set of objects
interact. Mediator promotes loose coupling by keeping objects
from referring to each other explicitly, and it lets you vary their
interaction independently
 Complex deferred triggers between databases and data
warehouse
 Behavioral – Memento
 Without violating encapsulation, capture and externalize an
object’s internal state so that the object can be restored to this
state later
 Allows access to old state to model transactions (with Proxy)
 Model distributed queries and the needed locking (with Proxy)
11
III. Application to Relational Databases
(cont’d)
 Behavioral – Observer
 Define a one-to-many dependency between objects so that
when one object changes state, all its dependents are notified
and updated automatically
 Database views (to filter appropriate, up-to-date entries and
fields from the base tables)
 Databases as observer of data warehouses or data marts
 Behavioral – Visitor
 Represent an operation to be performed on the elements of an
object structure. Visitor lets you define a new operation
without changing the classes of the elements on which it
operates
 Table traversal (access plan) for complex queries (with
Composite)
12
III. Application to Relational Databases
(cont’d)
 Behavioral – State
 Allow an object to alter its behavior when its internal state
changes. The object will appear to change its class
 “What-if” analysis (with Strategy and Command)
 Support optimization of selection among multiple
implementation for join and temporary files, particularly in
stored queries and views (with Strategy)
 Database reorganization – dynamic conversion between file
structures
 Behavioral – Strategy
 Define a family of algorithms, encapsulate each one, and make
them interchangeable. Strategy lets the algorithm vary
independently from clients that use it
 See examples in the State pattern
13
IV. Conclusion and Future Research
 Apply Generic Software Engineering Design Patterns
to Relational Database Design and Development
 15 (out of 23) GoF patterns
 Future Research




More application examples
Specify relationships with GRASP patterns
Combine with domain (database)-specific patterns
Extend design pattern applicability to data warehouses and
data marts
 A comprehensive curriculum design for software engineering
and database courses
14