Bridging the Gap between Variability in Client Application and Database Schema

Database schemas are used to describe the logical design of a database. Diverse groups of users have different perspectives on the schema which leads to different local schemas. Research has focused on view integration to generate a global, consistent schema out of different local schemas or views. However, this approach seems to be too constrained when the generated global view should be variable and only a certain subset is needed. Variable schemas are needed in software product lines in which products are tailored to the needs of stakeholders. We claim that traditional modeling techniques are not sufficient for expressing a variable database schema. We show that software product line methodologies, when applied to the database schemas, overcome existing limitations and allow the generation of tailor-made database schemas.

Tools to Support Variability in Database Schemas

FeatureMapper is a tool developed by Florian Heidenreich to annotate EMF/GMF based models with features. In this project, we extended this approach to also allow annotations to Entity-Relationship models. The extension and FeatureMapper are Eclipse plugins. Feel free to contact Florian Heidenreich in order to test this approach. The project files of our example can be downloaded >here<.

Screenshot des ER-Eclipse Plugins.

The figure below depicts the complete schema colored specific to features. With this representation it is easy to distinguish between the feature's entities. It is obviously that the maintainability of large variable application is increased.

Screenshot aus dem Plugin für komplettes ER Modell.

Screenshot aus dem Plugin für komplettes ER Modell.

The second approach to bridging the gap between bariability in client application and database schema is to use model compositions. We created a simple grammar to allow the composition of Entity-Relationship diagrams. The tool FeatureHouse, developed by Sven Apel, can then be used to compose the ER models. An example of the grammar is given below. However, you can ask for the full definition Christian Kästner.

Feature: Course Offering entity Catalogue { Semester, Type }; entity Course { Course_ID, Course_Name }; relationship Offer between Catalogue (1) and Course (1-*);	Feature: Library entity Book { ISBN, Title, Published }; entity Author { Author_ID, Name }; entity Book_Copy { CopyID, Version }; entity Catalogue {}; relationship Propose between Catalogue () and Book (); relationship Write between Author () and Book (); relationship IS_A between Book (1) and Book_Copy (*);
Feature: Book Recommendation entity Book { ISBN, Title, Author_Names }; relationship Propose between Catalogue () and Book ();	Feature: Room Planning entity Room { Room_ID, Capacity }; entity Course { Capacity }; entity Building { Building_ID, Building_Name, Location, Depart_ID }; relationship In between Room () and Catalogue (); relationship Has between Room (1-*) and Building (1);
Feature: Sport entity Coach { Coach_ID, Name, Salary }; entity Team { Team_ID, Name, Members }; entity Sport_Area { Area_Name, Description, Website }; entity Competition { Comp_ID, Name, Date, Price }; relationship Train between Coach (1) and Team (1); relationship Take_Part between Team () and Competition (); relationship Type between Team () and Sport_Area();	Feature: Employee Management entity Department { Dep_ID, Dep_Name, Dep_Members }; entity Employee { Emp_ID, Emp_Name, Salary }; entity Student { Stud_ID, Stu_Name, Address }; entity Graduate { Thesis_Title, Thesis_Start }; entity Undergraduate { Avg_Grade }; relationship IS_A between Graduate (1) and Student (1); relationship IS_A between Undergraduate (1) and Student (1); relationship Study_At between Student() and Department (1); relationship* Working_Place between Department (1) and Employee(*);
Feature: Research entity Lecturer { Specialization, WorkingGroup }; entity Employee {}; entity Course {}; relationship IS_A between Employee(1) and Lecturer (1); relationship Teaches between Lecturer (1) and Course (*);

Contact

This web site is maintained by Norbert Siegmund at the University of Magdeburg.

Feature: Course Offering entity Catalogue { Semester, Type }; entity Course { Course_ID, Course_Name }; relationship Offer between Catalogue (1) and Course (1-*);	Feature: Library entity Book { ISBN, Title, Published }; entity Author { Author_ID, Name }; entity Book_Copy { CopyID, Version }; entity Catalogue {}; relationship Propose between Catalogue () and Book (); relationship Write between Author () and Book (); relationship IS_A between Book (1) and Book_Copy (*);
Feature: Book Recommendation entity Book { ISBN, Title, Author_Names }; relationship Propose between Catalogue () and Book ();	Feature: Room Planning entity Room { Room_ID, Capacity }; entity Course { Capacity }; entity Building { Building_ID, Building_Name, Location, Depart_ID }; relationship In between Room () and Catalogue (); relationship Has between Room (1-*) and Building (1);
Feature: Sport entity Coach { Coach_ID, Name, Salary }; entity Team { Team_ID, Name, Members }; entity Sport_Area { Area_Name, Description, Website }; entity Competition { Comp_ID, Name, Date, Price }; relationship Train between Coach (1) and Team (1); relationship Take_Part between Team () and Competition (); relationship Type between Team () and Sport_Area();	Feature: Employee Management entity Department { Dep_ID, Dep_Name, Dep_Members }; entity Employee { Emp_ID, Emp_Name, Salary }; entity Student { Stud_ID, Stu_Name, Address }; entity Graduate { Thesis_Title, Thesis_Start }; entity Undergraduate { Avg_Grade }; relationship IS_A between Graduate (1) and Student (1); relationship IS_A between Undergraduate (1) and Student (1); relationship Study_At between Student() and Department (1); relationship* Working_Place between Department (1) and Employee(*);
Feature: Research entity Lecturer { Specialization, WorkingGroup }; entity Employee {}; entity Course {}; relationship IS_A between Employee(1) and Lecturer (1); relationship Teaches between Lecturer (1) and Course (*);