Geo-Databases: lecture 7 Database design Prof. Dr. Thomas H. Kolbe Institute for Geodesy and Geoinformation Science Technische Universität Berlin Credits: This material is mostly an english translation of the course module no. 8 (‘Geo-Datenbanksysteme‘) of the open e-content platform www.geoinformation.net.

Database design 21/09/2018

Motivation (1) Desired: A suitable relational schema in order to describe a given application (mini-world) Role of the database design: Systematic development of database schemata, with regard to the specific information needs of the user. Starting with SQL right away has some disadvantages: Poor in structuring concepts Application semantics therefore hidden in tables, foreign keys, etc Effects of changes in the real world on the schema hardly traceable Instead, we may perform the design process on a conceptual level: Usage of an abstract modelling language (e.g. Entity-Relationship-diagrams, UML-models) Projectable onto the language of the DBMS, e.g. an SQL schema 21/09/2018

Database design– a miniature example Task: Examination database Problem: Projection of an object-model into a relational schema? 21/09/2018

Logical design / Implementation A conceptual model can be converted into an implementable database model. 21/09/2018

Translation into the relational model There are some “cooking recipes“, that can help with the translation of a UML-diagram into a relational schema. Generally, the translation process can be carried out in several steps: Each class, that does not take part in the inheritance hierarchy is projected onto a table Each association, besides inheritance, is projected onto a table Refinement: Some tables can be combined Separate treatment of inheritance hierarchies 21/09/2018

Translation of classes Each class is projected onto a table. Name of the table: name of the class Attributes: Attributes of the class in the UML-diagram Note: if necessary, UML-data types have to be adapted to the SQL-data types! Example: 21/09/2018

Translation of associations Each association is projected onto a table. Name of the table: name of the association or, if existent, of the related association class; otherwise meaningful, new name Attributes: (if necessary attributes might have to be re-named!) Key attributes of the involved classes Attributes of the related association class (if existent) Example: 1:n-relationship between class room and class lecture 21/09/2018

Refinement: Combination of tables Some of the tables, that emanate from associations, can be eliminated. Let A and B be the classes / tables of the association. The options for the combination are determined by the type of association. 1:1 The key of B can be added to table A or vice versa. The association table can be eliminated 1:n The key of A can be added to the table B (“n-side“). The association table can be eliminated n:m The association table should persist. key of room for lecture 21/09/2018

Translation of inheritance hierarchies When it comes to inheritance hierarchies only the concerned classes are translated but not the inheritance relationships. There are several reasonable alternatives: One table per class in the hierarchy One table for each partial tree of the hierarchy that emanates from the root A single table for the entire hierarchy Criteria for the selection of an alternative: Required space (tuple size and number of emerged tables) Support of important manipulation operations and queries for the given application 21/09/2018

inheritance hierarchies, alternative I Alternative I: One table per class in the hierarchy. For each table: Name of the table: name of the class Attributes: Attributes of the corresponding class in the UML-diagram Key attributes of the root in the hierarchy, that remain keys 21/09/2018

inheritance hierarchies, alternative II (1) Alternative II: A table for each partial tree of the hierarchy that emanates from the root. For each partial tree: Name of the table: meaningful, clear name Attributes: al attributes of the concerned classes, renamed if necessary Tables: Persons, PersonsEmp, PersonsEmpProf, PersonsEmpAss, PersonsEmpProfAss, PersonsStud, PersonsEmpStud, PersonsEmpAssStud, PersonsEmpProfStud, PersonsEmpProfAssStud PersonsEmpAssStud wage Street 21/09/2018

inheritance hierarchies, alternative II (2) Alternative II illustrates the subject of disjunctive / non-disjunctive inheritance. An inheritance hierarchy is called non-disjunctive, if an object of an upper class K may have the type of more than one lower class of K. In our Example: Person is employee and (phd-) student at the same time Non-disjuntive inheritance can be expressed in all of the presented translation alternatives Alternative II shows an analogy to object-oriented programming languages in terms of disjuntive inheritance: All attributes of an object are stored in a “coherent“ memory area. If an inheritance hierarchy was translated according to alternative II, it requires the following amendments: Eliminate all tables that represent nonsensical combination in terms of the given application! In our Example: PersonsEmpProfStud 21/09/2018

inheritance hierarchies, alternative III Alternative III: A single table for the entire hierarchy. Name of the table: for example class name of the root Attributes: all class attributes that appear in the hierarchy, renamed if necessary. Not corresponding attributes are set to NULL! 21/09/2018

inheritance hierarchies, comparison (1) Comparison of the alternatives on the basis of the previously mentioned size parameters and the example query: “show name and rank of all professors!“ tuple size # of tables Example query A I (one table per class) compact besides foreign keys Medium SELECT Name, Rank FROM Professor, Person WHERE Professor.PerID =Person.PersID A II (one table per partial tree) High SELECT Name, Rank FROM PersonsEmpProf UNION SELECT Name, Rank FROM PersonsEmpProfAss SELECT Name, Rank FROM PersonsEmpProfAssStud SELECT Name, Rank FROM PersonsEmpProfStud A III (a single table) large minimal FROM Person WHERE Person.Rank IS NOT NULL 21/09/2018

inheritance hierarchies, comparison (2) Comparison of the alternatives on the basis of the dominating query types in the given application. Attributes of an upper class Attributes of a derivative class Attributes on different levels of the inheritance hierarchy A I + - A II + - A III Dominating attribute queries of the application + / - : number of tables to be included low / high 21/09/2018

Refinement of the design The implementable database schema can be improved: In terms of redundancy: Enforcement of the so-called normalisation of a relational database schema (later!) In terms of performance: controlled redundancy by targeted denormalisation by specifyfing further physical characteristics of the database, such as index structures for efficient access (see also “B-tree“ in LE 8 and “R-tree“ in LE 11) 21/09/2018

References Overview: Hector Garcia-Molina, Jeffrey D. Ullman, Database Systems: The Complete Book, Prentice Hall, 2002 Bernd Oestereich, Objektorientierte Softwareentwicklung: Analyse und Design mit der Unified Modeling Language, Oldenbourg Verlag, München, 1998 Gottfried Vossen, Datenbankmodelle; Datenbanksprachen und Datenbankmanagement-Systeme, Oldenbourg Verlag, München, 1999 Original works: P.P.-S. Chen, The entity-relationship model: Toward a unified view of data, in: ACM Transactions on Database Systems, Vol. 1, Seite 9-36, 1976 J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language for Object-Oriented Development - Documentation Set 0.9 Addendum, Rational Software Corporation, Santa Clara 1996 21/09/2018