1. Faculty of Civil Engineering Institute of Construction Informatics, Prof. Dr.-Ing. Scherer Institute of Construction Informatics, Prof. Dr.-Ing. Scherer Technische Universität Dresden MIS 1 Management Information Systems Part 3 Transformation in a relational data structure and implementation as a relational database Prof. Dr.-Ing. Raimar J. Scherer Institute of Construction Informatics Dresden,19.11.2012

2. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 2 Overall Process of an Engineering System Treatment 1.System Capturing High level definition of the purpose, functions, processes and behaviour Formal Representation of the System (IDEF0) 2.data structure = {O,R} based on a specific meta model (= O-O-Model) development of a data model as an O-O-schema = ideal data structure of the concepts 3.transformation of the conceptual data model in a relational database model 4.implementation of the schema in a data base software; today being most appropriate as a relational data structure (approximations) 5.instantiation of an engineering model = configure the domain-specific engineering model from the data model 6.numerical program for the computation of the system behaviour = simulation = prognosis based on a model + model assumptions + quantitative values (statistics) (= {O-O + Impl.} + {Instantiation} ) 7.Communication M2M: between data base (= information) and computation program (= numerics) = data exchange (data conversion by importing program) M2H: Reports, i.e. graphical and alphanumerical representation of results (output and system changes) but also input, model and model assumptions 8.Monitoring + Evaluation + Reporting

3. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 3 Transformation: conceptual data model  relational database model Until now we developed a conceptual data model of our engineering system. This conceptual model is still object oriented. The next step is the transformation of the conceptual entity relationship model in a relational database model which is able to be implemented in a relational database system. The reason for the use of relational databases is: - They work precise and - fast The semantics of the relational database model is less expressive than the conceptual model.  main objective of the transformation is to apply tranformation rules that keep the loss of semantic content as low as possible

4. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 4 Relational Databases How to use the conceptual model based on the object-oriented paradigm in a relational database? Contrary to relational database the object-oriented paradigm has more high-level concepts which are interesting for conceptional data modelling. each row is a relation (1)  the combination of values in a row defines a unique object or the appearance (state) of an object based on set theory stores all information in tables (a set of rows and columns) Each row is a set of columns with only one value for each. All rows from the same table have the same set of columns, (some columns may have NULL, i.e. unknown values) Relational database: Problem: schema generation from high-level conceptual models

5. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 5 Relational Databases Tables – the basis of relational databases first row: name of the column and data type Column 1 Column 2 Column 3 Column 4 Row 1... Row 2 Row 3 data (objects) “attributes”

6. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 6 Relational Databases Example: Name (string) Street (string) Street- number (int) Postal code (int) City (string) Country (string) SchmidtGarten- weg 1001216DresdenGermany MüllerMain street 84NULLCorkIreland... Two entries with missing postal code for the person Müller (NULL).

7. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 7 Relational Databases Keys: Name (string) Street (string) Street- number (int) Postal code (int) City (string) Country (string) SchmidtGarten- weg 1001216DresdenGermany MüllerMain street 84NULLCorkIreland MüllerNewton- street... We need a way to identify each row stored into the table. In the shown example we can use the column Name to identify each person. But if there are two persons with the same name we can not differ between them by their name! Address from Müller?

8. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 8 We need a way to identify each row stored into the table. In the shown example we can use the column Name to identify each person. But if there are two persons with the same name we can not differ between them by their name! Relational Databases Keys: Name (string) Street (string) Street- number (int) Postal code (int) City (string) Country (string) SchmidtGarten- weg 1001216DresdenGermany MüllerMain street 84NULLCorkIreland MüllerNewton- street... Address from Müller? Solution: 1) Use a combination of columns for identification, e.g. Name and Street composite (primary) key

9. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 9 Relational Databases Keys: ID (int) Name (string) Street (string) Street- number (int) Postal code (int) City (string) Country (string) 1SchmidtGarten- weg 1001216DresdenGermany 2MüllerMain street 84NULLCorkIreland 3MüllerNewton- street... We need a way to identify each row stored into the table. In the shown example we can use the column Name to identify each person. But if there are two persons with the same name we can not differ between them by their name! Address from Müller? Solution: 2) Use a columns for unique identification of rows, e.g. new column ID (primary) key

10. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 10 Relational Databases Keys: Recommendation for definition of keys: - an own column for identification is much faster than a composite key -integer type is faster and needs less space than a string type - if a string type shall be used, a short string is much faster than a long string - syntethic keys, e.g. auto-increment type provided by the database, are preferred to ensure uniqueness of key values (syntethic keys are better than user defined keys)

11. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 11 Relational Databases Relationships: ID (int) Name (string)... 1Schmidt 2Müller 3 Use keys to define a reference to a row of an other table = Relation (2). Such a link is defined by using the key of the other table, which is called a foreign key. table persons Empl_ID (int) Person_No (int references persons(ID))... 12 21..... table employees foreign key to table persons

12. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 12 Relational Databases Recommendation for database layout (the three normalization forms): Guide on how to design relational databases that leads to simpler (to implement) applications and to more maintainable data bases: 1. All column values are atomic (e.g. postal address is not contained in one string, instead each element of the address is stored in a column) 2. All column values depends on the value of the primary key (e.g. separation of information in different tables: person and employees) 3. No column value depends on the value of any other column except the primarykey (e.g. having no derived values) 4. In addition, there should be no NULL value in the table

13. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 13 Database layout Use of object-oriented conceptual model for database layout: Problematic object-oriented concepts: -inheritance have to be inherited by hand before implementation as rel. data base -select types use a discrimination attribute, which points to the right sub-table -aggregations (no type for array, list, set or bag of values) -constraints (inverse relationships, cardinalities, optional/mandatory attributes, rules, derived attributes)

14. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 14 Transformation of Entity Types m each entity type will be transformed in a relation (1) m the name of the relation will be the same as the one of the entity type of the conceptual model m the attributes will also be taken from the conecptual model m the primary key will be chosen according to the rules explained before Entity Type attribute 1attribute 2attribute 3 DATA TYPE 1DATA TYPE 2DATA TYPE 3 DATA TYPE 1 DATA TYPE 2 Conceptual data model Relational database model

15. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 15 Transformation of Relation Types (Relationships) m Relation types are not supported by relational database models m the only way to transform them is to include them either  as an own relation schema or  as an attribute in an existing relation schema ( relation(2) ) m due to performance reasons the number or relation schemas should be as low as possible  the modelling of relation types as an attribute in an existing relation schema is the preferred way This is only possible if the merging of entity type and relation type will not cause data base anomalies (violate normal forms) m Rule:  relation types with cardinality [N:M] must be transformed in own relation schemas  relation types with cardinality [1:1] or [1:N] may be expressed in an existing relation schema of one of the related entity types

16. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden  1. hierarchical relations  3. network specific relations  2. conditional relations R2  /R1  1 c m mc. 1 1-1 c-1 m-1 mc-1 c 1-c c-c m-c mc-c m 1-m c-m m-m mc-m mc 1-mc c-mc m-mc mc-mc 10 different relation types result from the symmetry of the matrix. Additionally, there exist recursive relationships, which can be transformed into one of the 16 relation types. From the 4 association types 1, c, m, mc with 1 = 1, c = (0 or 1), m=m and mc = (0 or m) the following 16 relation types can be derived: These 16 relation types can be classified in: Transformation of Relation Types (Relationships) 16

17. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden The relation types define the dependencies between the tables  Complexity of the basic functions (database software)  Complexity of a transaction (additional programs) For this reason, only a few simple relation types are considered in advance. This is possible, because the conditional and network specific relations can be transformed into hierarchical relation types. In the ER-model there are only hierarchical relations allowed: 1 – 1 1 – c 1 – m 1- mc 17 Transformation of Relation Types (Relationships)

18. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden Workers (ANr, Name, First name) Vehicles (FNr, Vehicle name, Type, Build year) Vehicle driver (FNr, ANr) mc-mc relation leads to redundancies  NOT ALLOWED Transformation in 2 (1-mc) relations determines the introduction of an entity. mc Workers Vehicles Vehicle driver 1 mc 1 Each worker can use 1 or more construction vehicles. Each construction vehicle can be used by 1 or more workers. Vehicle driver 1 1 2 ANr 2 1 FNr 1 2 4 2 2 Vehicles crane excavator tipper 1 2 3 AK-90 R 124 KF-36 FNr Vehicle Type name 1995 1997 1996 build - year Workers ANr Name First Müller Lehmann Berger 1 2 3 Andy Jens Paul Altmann 4Peter 2 1 null ANr crane 1AK-90 1995 1 excavator 2R 124 1997 2 excavator 2R 124 1997 4 name 18 Transformation of Relation Types (Relationships) MC-MC Relation

19. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 19 Transformation of Relation Types Relationship as an attribute in an existing relation schema Entity Type 1 attribute 1.1attribute 1.2attribute 1.3 DATA TYPE 1DATA TYPE 2DATA TYPE 3 Entity Type 2 attribute 2.1attribute 2.2attribute 2.3attribute 2.4 DATA TYPE 1DATA TYPE 2DATA TYPE 3DATA TYPE 1 Foreign key to att 1.1 of Entity Type 1 1 N attribute 1.1 = attribute 2.4 Question: Would it be also possible to introduce the foreign key attribute to Entity Type 1 instead of Entity Type 2?

20. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 20 Transformation of Relation Types Relationship as an own relation schema Entity Type 1 attribute 1.1attribute 1.2attribute 1.3 DATA TYPE 1DATA TYPE 2DATA TYPE 3 Entity Type 2 attribute 2.1attribute 2.2attribute 2.3 DATA TYPE 1DATA TYPE 2DATA TYPE 3 Relationship attribute 3.1attribute 3.2 DATA TYPE 1 Foreign key to att 1.1 of Entity Type 1 Foreign key to att 2.1 of Entity Type 2 1 MN 1 attribute 3.1 = attribute 3.2 attribute 1.1 = attribute 3.1 attribute 3.2 = attribute 2.1

21. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 21 Transformation of Generalisation Hierarchies Entity Type 1 attribute 1.1attribute 1.2attribute 1.3 DATA TYPE 1DATA TYPE 2DATA TYPE 3 Entity Type 1a attribute 1a.1attribute 1a.2attribute 1a.3 DATA TYPE 1DATA TYPE 2DATA TYPE 3 Entity Type 1b attribute 1b.1attribute 1b.2attribute 1b.3 DATA TYPE 1DATA TYPE 2DATA TYPE 3 The primary key of the supertype (attribute 1.1) will be used also as a primary key of the subtypes (att. 1a.1 and att 1b.1) Therewith the subtypes are related with the supertype Supertype Subtype

22. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 22 Conceptual model

23. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 23 Approximated Conceptual model Problems: Inheritance Select type "as a consequence we receive NULL values for the Inner Node"

24. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 24 Identification of tables table Node table Node_Sensor table Pipe_Sensor table Pipe table Pipe_Parameter table Fluid

25. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 25 tables Table Node: Column name nrnameX_CoordY_CoordZ_CoordPressure Water_ Input Con- sumption required_ pressure Data type INTEGER PRIMARY KEY STRINGDOUBLE Node Output_NodeInput_Node Conceptual model: Drawback: NULL values But We still know Input / output note

26. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 26 tables Table Node: Column name nrnameX_CoordY_CoordZ_CoordPressure Water_ Input Con- sumption required_ pressure Data type INTEGER PRIMARY KEY STRINGDOUBLE Node Output_NodeInput_Node Conceptual model: Drawback: Reduced NULL values But We do not know Input / output note = Water flow

27. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 27 tables Table Pipe: Column name NrStart_NodeEnd_NodePipe_ParameterFluid No. Data type INTEGER PRIMARY KEY INTEGER REFERENCES Node (Nr) STRING REFERENCES Duct_Parameter (Nr) INTEGER REFERENCES Fluid_Parameters (Nr.) Pipe Conceptual model:

28. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 28 tables Table Pipe_Parameter: Column name NrDiameterPNKName Data type STRING PRIMARY KEY DOUBLE STRING Pipe_Parameter Pipe_Type Conceptual model: Drawback: NULL values

29. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 29 tables Table Fluid: Column name Nameviscositydensity Data type STRING PRIMARY KEY DOUBLE Conceptual model:

30. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 30 tables Table Pipe_Sensor: Column name NrVelocityTimelocation Data type INTEGER PRIMARY KEY DOUBLETIME INTEGER REFERENCES Duct (Nr) Pipe_Sensor Conceptual model:

31. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer MIS Technische Universität Dresden 31 tables Table Node_Sensor: Column name NrPressureTimeLocation Data type INTEGER PRIMARY KEY DOUBLETIME INTEGER REFERENCES Node (Nr) Node_Sensor Conceptual model: