Kein Folientitel

Bauinformatik
Vertiefte Grundlagen
Systemtheorie
5. Semester
4. Vorlesung
Entwicklung der relationalen Datenstruktur
eines Informationssystemes
Prof. Dr.-Ing.
R. J. Scherer
TU Dresden - Institut für Bauinformatik
Nürnberger Str. 31a
2. OG, Raum 204
Bauinformatik II, Softwareanwendungen 1; 9. Vorlesung
Folie-Nr.: 1
Allgemeiner Prozess einer
ingenieurmäßigen Systembetrachtung
1. Systembetrachtung
Grobe Definition von Zweck, Funktion, Prozessen und Verhalten
Formale Repräsentation des Systems (IDEF0) auf hoher Ebene
2. Systemobjektmodell = Datenstruktur = {O, R}
basierend auf einem Metamodell (= O-O-Modell / E-R-Modell)
Entwicklung eines Datenmodells als O-O-/E-R-Schema
3. Implementierung des Schemas in einer Software
Umsetzen in ein vereinfachtes E-R-Modell
Implementieren in MS ACCESS
4. Instanziierung eines Ingenieurmodells
= Konfiguration des domänenspezifischen Ingenieurmodells aus dem Datenmodell
5. Numerisches Programm zur Berechnung des Systemverhaltens
= Simulation
= Prognose
basierend auf einem Modell + Modellannahmen + quantitativen Werten (Statistik)
6. Kommunikation M2M Maschine mit Maschine, M2H Maschine mit Mensch
7. Monitoring, Evaluation und Bericht
TU Dresden - Institut für Bauinformatik
Folie-Nr.: 2
Transformation:
Objektorinetiertes Datenmodell  Relationales Datenbankmodell
Bisher haben wir ein konzeptuelles Datenmodell unseres Ingenieursystems
entwickelt. Dieses konzeptuelle Modell ist noch objektorientiert.
Der nächste Schritt ist die Transformation des konzeptuellen objektorinetierten
Modells in ein relationales Datenbankmodell, das in einer relationalen Datenbank
implementiert werden kann.
Der Grund für die Nutzung relationaler Datenbanken ist:
- sie arbeiten präzise und
- schnell
Die Semantik des relationalen Datenbankmodells ist weniger ausdrucksstark, als
das des konzeptuellen Modells.
 Hauptziel der Transformation ist es, Transformationsregeln anzuwenden, die
den Verlust des semantischen Informationsgehalts so gering wie möglich halten.
TU Dresden - Institut für Bauinformatik
3
Relationale Datenbanken
• Jede Zeile ist eine Relation  Die Kombination von Werten in einer Zeile
definiert ein einmaliges Objekt oder das Auftreten (Zustand) eines Objektes
• Basiert auf der Mengentheorie
• Speichert alle Informationen in Tabellen
(eine Menge von Zeilen und Spalten)
• Jede Zeile ist eine Menge von Spalten mit jeweils nur einem Wert
• Alle Zeilen derselben Tabelle haben die gleiche Menge an Spalten
(einige Spalten können NULL-Werte haben, d.h. unbekannte Werte)
Im Gegensatz zu den relationalen Datenbanken hat das objektorientierte Paradigma
mehr “high-level”-Konzepte, die für die konzeptuelle Datenmodellierung
interessant sind
Problem:
Schemaerzeugung aus allgemeinen (high-level) konzeptuellen Modellen
TU Dresden - Institut für Bauinformatik
4
Relationale Datenbanken
Tabellen – die Basis für relationale Datenbanken
Spalte 1
Zeile 1
Spalte 2
Spalte 3
...
Zeile 2
Spalte 4
Erste Zeile:
Name der Zeile
und Datentyp
Daten (Objekte)
Zeile 3
“Attribute”
TU Dresden - Institut für Bauinformatik
5
Relationale Datenbanken
Beispiel:
Name
(string)
Straße
(string)
Hausnummer
(int)
Postleitzahl
(int)
Ort
(string)
Land
(string)
Schmidt
Gartenweg
10
01216
Dresden
Deutschla
nd
Müller
Main
street
84
NULL
Cork
Irland
...
...
Zwei Einträge mit fehlender Postleitzahl bei der Person Müller (NULL)
TU Dresden - Institut für Bauinformatik
6
Relationale Datenbanken
Schlüssel:
Wir brauchen eine Möglichkeit, um jede Zeile, die in der Tabelle gespeichert ist,
zu identifizieren. Im gegebenen Beispiel können wir die Spalte Name benutzen,
um jede Person zu identifizieren. Aber: wenn zwei Personen mit dem gleichen
Namen in der Tabelle eingetragen sind, können wir beide nicht auf Grundlage
ihres Namens unterscheiden!
Name
(string)
Straße
(string)
Hausnummer
(int)
Postleitzahl
(int)
Ort
(string)
Land
(string)
Schmidt
Gartenweg
10
01216
Dresden
Germany
Müller
Main
street
84
NULL
Cork
Ireland
Müller
Newtonstreet
...
...
...
Addresse von Müller?
TU Dresden - Institut für Bauinformatik
7
Relationale Datenbanken
Schlüssel:
Wir brauchen eine Möglichkeit, um jede Zeile, die in der Tabelle gespeichert ist,
zu identifizieren. Im gegebenen Beispiel können wir die Spalte Name benutzen,
um jede Person zu identifizieren. Aber: wenn zwei Personen mit dem gleichen
Kombinierter
Namen in der(Primär-)Schlüssel
Tabelle eingetragen sind, können wir beide nicht auf Grundlage
ihres Namens unterscheiden!
Name
(string)
Straße
(string)
Hausnummer
(int)
Postleitzahl
(int)
Ort
(string)
Land
(string)
Schmidt
Gartenweg
10
01216
Dresden
Germany
Müller
Main
street
84
NULL
Cork
Ireland
Müller
Newtonstreet
...
...
...
Addresse von Müller?
Lösung: 1) Nutzung eines kombinierten Schlüssels zur Identifikation
z. B. Name und Straße
TU Dresden - Institut für Bauinformatik
8
Relationale Datenbanken
Schlüssel:
Wir brauchen eine Möglichkeit, um jede Zeile, die in der Tabelle gespeichert ist,
zu identifizieren. Im gegebenen Beispiel können wir die Spalte Name benutzen,
um jede Person zu identifizieren. Aber: wenn zwei Personen mit dem gleichen
(Primär)Schlüssel
Namen in der Tabelle eingetragen sind, können wir beide nicht auf Grundlage
ihres Namens unterscheiden!
ID
(int)
Name
(string)
Straße
(string)
Hausnummer
(int)
Postleitzahl
(int)
Ort
(string)
Land
(string)
1
Schmidt
Gartenweg
10
01216
Dresden
Germany
2
Müller
Main
street
84
NULL
Cork
Ireland
3
Müller
Newtonstreet
...
...
...
Adresse von Müller?
Lösung: 2) Nutzung einer Spalte zur eindeutigen Identifikation von Zeilen,
z. B. neue Spalte ID
TU Dresden - Institut für Bauinformatik
9
Relationale Datenbanken
Beziehungen:
Zur Definition einer Referenz auf eine Spalte einer anderen Tabelle werden
Schlüssel benutzt.
Eine derartige Verknüpfung wird durch die Nutzung eines Schlüssels der
anderen Tabelle definiert, der als Fremdschlüssel bezeichnet wird.
Tabelle Personen
Tabelle Mitarbeiter
...
Mitarb_ID
(int)
Person_Nr
(int
referenziert Personen(ID))
1
2
ID
(int)
Name
(string)
1
Schmidt
2
Müller
2
1
3
Müller
..
...
...
Fremdschlüssel zur Tabelle Personen
TU Dresden - Institut für Bauinformatik
Bauinformatik II, Softwareanwendungen 1; 9. Vorlesung
Folie-Nr.: 10
Relationale Datenbanken
Empfehlung für das Datenbankschema (die dritte Normalformen):
Leitfaden zum Entwurf Relationaler Datenbanken, für einfach zu implementierende
Anwendungen und wartungsfreundliche Datenbanken.
1. Alle Spaltenwerten sind atomar
(z.B. die postalische Adresse ist nicht in einem String enthalten,
statt dessen ist jedes Element der Adresse in einer eigenen Spalten
gespeichert)
2. Alle Spaltenwerte hängen vom Wert des Primärschlüssels ab
(d.h. zur Abgrenzung von Information verschiedene Tabellen anlegen:
Mitarbeiter getrennt von Personen )
3. Kein Spaltenwert hängt vom Wert einer anderen Spalte ab,
ausgenommen vom Primärschlüssel (z.B. es existieren keine
abgeleiteten Werte)
4. Zusätzlich sollen keine NULL-Werte in den Tabellen enthalten sein
TU Dresden - Institut für Bauinformatik
Bauinformatik II, Softwareanwendungen 1; 9. Vorlesung
Folie-Nr.: 11
Transformation eines konzeptuellen objektorientierten
Modells in ein Relationales Datenmodel
Problematische objektorientierte Konzepte:
-
Vererbung
muß per Hand ausgeführt werden, bevor sie in Relationaler Datenbank
implementiert werden kann
-
Select-Typen
Nutzung eines diskriminierenden Attributes, das auf die richtige Sub-Tabelle
zeigt
-
Aggregationen
(kein Typ für Array, List, Set oder Bag von Werten, bzw. nicht empfohlen)
-
Bedingungen/Beschränkungen
(inverse Beziehungen, Kardinalitäten, optionale/obligatorische Attribute,
Regeln, abgeleitete Attribute)
TU Dresden - Institut für Bauinformatik
Bauinformatik II, Softwareanwendungen 1; 9. Vorlesung
Folie-Nr.: 12
Konzeptuelles Modell
nr
INTEGER
druck
REAL
REAL
nr
name
INTEGER
ZEICHENFOLGE
STRING
viskosität
geschwindigkeit
REAL
REAL
dichte
zeit
REAL
zeit
Knoten_Sensor
INTEGER
Rohr_Sensor
REAL
nr
Flüssigkeit
position
name
flüssigkeits_parameter position
ZEICHENFOLGE
STRING
x_coord
REAL
y_coord
Start_Knoten
(ABS)Knoten
nr
Rohr
INTEGER
End_Knoten
REAL
rohr_parameter
Q
z_coord
REAL
rohr_typ_select
REAL
druck
REAL
Input_Knoten
1
Output_Knoten
(OPT) parameter
Inner_Knoten
Rohr_Typ
name
verbrauch
erforderl_druck
wasser_input
REAL
STRING
ZEICHENFOLGE
REAL
REAL
Rohr_Parameter
durchmesser
PN
k
REAL
TU Dresden - Institut für Bauinformatik
REAL
REAL
nr
STRING
ZEICHENFOLGE
Bauinformatik II, Softwareanwendungen 1; 9. Vorlesung
Folie-Nr.: 13
Vereinfachtes konzeptuelles Modell
INTEGER
Probleme:
nr
druck
REAL
REAL
nr
name
INTEGER
ZEICHENFOLGE
STRING
viskosität
geschwindigkeit
REAL
REAL
dichte
zeit
REAL
zeit
Knoten_Sensor
INTEGER
Rohr_Sensor
REAL
nr
Flüssigkeit
position
name
Vererbung
ZEICHENFOLGE
STRING
x_coord
REAL
y_coord
flüssigkeits_parameter position
Start_Knoten
(ABS)Knoten
nr
Rohr
Select
Typ
INTEGER
End_Knoten
REAL
rohr_parameter
Q
z_coord
REAL
rohr_typ_select
REAL
druck
1
REAL
Input_Knoten
Output_Knoten
Inner_Knoten
(OPT) parameter
Rohr_Typ
name
verbrauch
erforderl_druck
wasser_input
REAL
"als Konsequenz
erhalten wir NULL-Wert
für den Inner_Knoten"
STRING
ZEICHENFOLGE
REAL
REAL
Rohr_Parameter
durchmesser
PN
k
REAL
TU Dresden - Institut für Bauinformatik
REAL
REAL
nr
STRING
ZEICHENFOLGE
Bauinformatik II, Softwareanwendungen 1; 9. Vorlesung
Folie-Nr.: 14
Identifikation der Tabellen
nr
Tabelle Knoten_Sensor
REAL
name
druck
REAL
nr
Tabelle
Rohr_Sensor
INTEGER
Tabelle
ZEICHENFOLGE
STRING
viskosität
REAL
Flüssigkeit
INTEGER
geschwindigkeit
REAL
dichte
zeit
REAL
zeit
Knoten_Sensor
INTEGER
Rohr_Sensor
REAL
nr
Flüssigkeit
position
name
flüssigkeits_parameter position
ZEICHENFOLGE
STRING
x_coord
REAL
y_coord
Start_Knoten
Tabelle
Start_Knoten
Knoten
(ABS)Knoten
REAL
nr
INTEGER
Tabelle
Rohr
Rohr
rohr_parameter
Q
z_coord
REAL
rohr_typ_select
REAL
druck
REAL
Input_Knoten
1
Output_Knoten
Inner_Knoten
Tabelle
Rohr_Parameter
(OPT) parameter
Rohr_Typ
name
verbrauch
erforderl_druck
wasser_input
REAL
STRING
ZEICHENFOLGE
REAL
REAL
Rohr_Parameter
durchmesser
PN
k
REAL
TU Dresden - Institut für Bauinformatik
REAL
REAL
nr
STRING
ZEICHENFOLGE
Bauinformatik II, Softwareanwendungen 1; 9. Vorlesung
Folie-Nr.: 15
Tabellen
Tabelle Knoten:
Spaltenname
nr
name
X_Coord
Y_Coord
Z_Coord
Druck
Wasser_
Input
Verbrauch
erforderl_
druck
Datentyp
INTEGER
PRIMARY
KEY
STRING
DOUBLE
DOUBLE
DOUBLE
DOUBLE
DOUBLE
DOUBLE
DOUBLE
Input_Knoten Output_Knoten
Knoten
Konzeptuelles
Modell
INTEGER
nr
Nachteil:
NULL-Werte
name
ZEICHENFOLGE
STRING
x_coord
REAL
y_coord
(ABS)Knoten
REAL
z_coord
REAL
druck
REAL
Input_Knoten
1
Output_Knoten
verbrauch
Inner_Knoten
erforderl_druck
wasser_input
REAL
REAL
TU Dresden - Institut für Bauinformatik
REAL
Bauinformatik II, Softwareanwendungen 1; 9. Vorlesung
Folie-Nr.: 16
Tabellen
Tabelle Rohr:
Spaltenname
Nr
Start_Knoten
End_Knoten
Rohr_Parameter
Flüssigkeits_Name
Datentyp
INTEGER
PRIMARY KEY
INTEGER
referenziert
Knoten
(Nr)
INTEGER
referenziert
Knoten
(Nr)
STRING
referenziert
Rohr_Parameter
(Nr)
INTEGER
referenziert
Flüssigkeits_Parameter
(Nr.)
Rohr
Konzeptuelles Modell
Flüssigkeit
flüssigkeits_parameter
Start_Knoten
Rohr
(ABS)Knoten
nr
INTEGER
End_Knoten
Q
Rohr_Parameter
REAL
Rohr_Parameter
TU Dresden - Institut für Bauinformatik
Bauinformatik II, Softwareanwendungen 1; 9. Vorlesung
Folie-Nr.: 17
Tabellen
Tabelle Rohr_Parameter:
Spaltenname
Nr
Durchmesser
PN
K
Name
Datentyp
STRING
PRIMARY
KEY
DOUBLE
DOUBLE
DOUBLE
STRING
Rohr_Typ
Rohr_Parameter
rohr_typ_select
Nachteil:
NULL-Werte
Konzeptuelles
Modell:
(OPT) parameter
Rohr_Typ
name
STRING
ZEICHENFOLGE
Rohr_Parameter
durchmesser
PN
k
REAL
REAL
REAL
nr
STRING
ZEICHENFOLGE
TU Dresden - Institut für Bauinformatik
Bauinformatik II, Softwareanwendungen 1; 9. Vorlesung
Folie-Nr.: 18
Tabellen
Tabelle Fluessigkeit:
SpaltenName
Name
Viskositaet
Dichte
Datentyp
STRING
PRIMARY
KEY
DOUBLE
DOUBLE
Konzeptuelles
Modell:
name
ZEICHENFOLGE
STRING
viskosität
REAL
dichte
REAL
Flüssigkeit
TU Dresden - Institut für Bauinformatik
Bauinformatik II, Softwareanwendungen 1; 9. Vorlesung
Folie-Nr.: 19
Tabelle
Table Rohr_Sensor:
Spaltenname
Datentyp
Nr
Geschwindigkeit
INTEGER
PRIMARY KEY
DOUBLE
Zeit
Position
TIME
INTEGER
referenziert
Rohr
(Nr)
Rohr_Sensor
Konzeptuelles
Modell:
nr
INTEGER
geschwindigkeit
REAL
zeit
Rohr_Sensor
REAL
position
Rohr
TU Dresden - Institut für Bauinformatik
Bauinformatik II, Softwareanwendungen 1; 9. Vorlesung
Folie-Nr.: 20
Tabelle
Tabelle Knoten_Sensor:
Spaltenname
Nr
Datentyp
INTEGER
PRIMARY KEY
Druck
DOUBLE
Zeit
Position
TIME
INTEGER
referenziert
Knoten
(Nr)
Knoten_Sensor
Konzeptuelles
Modell:
nr
INTEGER
REAL
REAL
druck
zeit
Knoten_Sensor
position
(ABS)Knoten
TU Dresden - Institut für Bauinformatik
Bauinformatik II, Softwareanwendungen 1; 9. Vorlesung
Folie-Nr.: 21