Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Concurrency control wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Navitaire Inc v Easyjet Airline Co. and BulletProof Technologies, Inc. wikipedia , lookup
Functional Database Model wikipedia , lookup
Clusterpoint wikipedia , lookup
Versant Object Database wikipedia , lookup
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