Vorlesung Software-Engineering I Daten im Architektur

Vorlesung Software-Engineering I
… im 3. und 4. Semester
06. SW-Architektur - Datensicht
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
Daten im Architektur-Entwurf – Darstellung in Abläufen
Daten
Vorgang 1
Vorgang 2
Eingangsdaten
Ausgangsdaten
Vorgang 3
Ausgangsdaten
Vorgang 2
Vorgang 1
globale
Daten
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
2
Daten im Architektur-Entwurf - Inhalte
Was müssen wir von den Daten wissen?
•
•
•
•
Welche Daten sollen gespeichert werden
Welcher Art sind die Dateninhalte
Welche Daten gehören zusammen
In welcher Beziehung stehen die Daten
Datenfelder (Namen)
Datenfelder (Typ)
Gruppen -> Datensatz
Verknüpfungen
Grundsätze der Datenspeicherung:
•
•
•
Vermeiden der Doppelspeicherung
Jeder Datensatz muss eindeutig identifizierbar sein
Die Richtigkeit der Daten muss sichergestellt sein
Normalisieren
ID -> Primärschlüssel
Transaktionen
Achtung: in diesem Script werden nur relationale Daten behandelt!
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
3
Daten in der Architektur - Ebenen
DHBW-Stuttgart/Frank M. Hoyer
Benutzeroberfläche
Anzeigefelder,
Eingabefelder
GUI-Elemente
Programm
Programmspeicher
Strukturen,
Strukturen
Variablen
Objekte,
Objekte
Attribute
Datenablage
Datenbank,
Datei
Tabellen,
Felder
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
4
Darstellung: Entity-Relationship-Modell (ERM)
Strukturelle Beschreibung der
Tabellen und ihrer Verknüpfungen
in einer Datenbank.
Felddefinition oft in tabellarischer
Form (DataDictionary).
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
5
Kardinalitäten – Beziehungen zwischen den Dateneinheiten
1:1
Entität 1
Entität 2
Die 1:1 Relation kann auch in einer Tabelle abgebildet werden.
1:n
Entität 1
Entität 2
Die 1:n Relation ist die klassische Master-Detail-Beziehung.
Entität 3
Entität 4
m:n
Entität 1
Entität 2
Entität 1
Entität 3
Entität 4
Entität 3
E2E
Entität 5
Entität 2
Entität 4
Entität 5
m:n Beziehungen müssen in 1:n Beziehungen aufgelöst werden,
typischerweise mit einer Verknüpfungstabelle.
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
6
Datenspeicherung - Beispiel Ausleihliste
Die Mitarbeiter leihen aus unserem Ausleihschrank verschiedene Geräte aus.
Wir wollen wissen wer welches Gerät g
gerade ausgeliehen
g
hat.
Evtl. sollte der Mitarbeiter auch angeben bis wann er das Gerät wieder zurück gibt.
Wir haben Notebooks, Beamer, Digitalkameras, Videokameras im Ausleihschrank.
Was
Wann
Wer
Notebook 1
20.9.2010
H. Apel
Digitalkamera
1.10.2010
H. Burgmüller
Notebook 1
Beamer 1
3.10.2010
3.10.2010
H. Meier, Hans
H. Meier, Hans
Wenn die Mitarbeiter den Gegenstand zurück gebracht haben, wird die Zeile durchgestrichen.
Bei Mitarbeitern mit nicht eindeutigem Namen wird noch der Vorname hingeschrieben.
hingeschrieben
Einige Geräte sind mehrfach vorhanden, dann sind sie mit Nummern gekennzeichnet.
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
7
16. Juli 2010
geändert: 12. Oktober 2015, FMH
8
Normalisieren – Beispiel Ausleihliste
nicht normalisiert,
alles in einer Tabelle
Mitarbeiter in
eigener Tabelle
Mitarbeiter und
Gegenstände
eigener Tabelle
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
DataDictionary – Ausleihliste 1/2
Tabelle Gegenstand:
g
Name
Typ
Inhalt
ID_Gegenstand
Number()
Primary Key
Name
Sting(30)
Name oder Bezeichnung
Beschreibung
String(2000)
längere Beschreibung, mehrzeilig
Name
Typ
Inhalt
ID_Mitarbeiter
Number()
Primary Key
Name
Sting(50)
Nachname, Vorname
Abteilung
String(20)
Abteilungsbezeichnung
Tabelle Mitarbeiter:
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
9
DataDictionary – Ausleihliste 2/2
Tabelle Ausleihliste:
Name
Typ
Inhalt
ID_Liste
Number()
Primary Key
ID_Gegenstand
Number()
Fremdschlüssel auf Gegenstand
ID_Mitarbeiter
Number()
Fremdschlüssel auf Mitarbeiter
ausgeliehen am
ausgeliehen_am
DateTime
Datum der Ausleihe
zurückgegeben_am
DateTime
Datum der Rückgabe
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
10
BNF-Syntax zum Schreiben von DataDictionaries - Validierung
In einer Definition wird in Form einer Zuweisung geschrieben:
<Ni ht At
<Nicht-Atomarer
Begriff>
B iff> = <Ausdruck>
<A d k>
Links von der Zuweisung steht ein nicht-atomarer Begriff. Rechts von der Zuweisung steht eine Regel. Eine Regel
besteht aus einer Kombination von atomaren und nicht-atomaren Begriffen. Wiederholungen sind möglich. Zirkuläre
Definitionen sind verboten
verboten, Rekursionen hingegen erlaubt
erlaubt.
= Zuweisung
() Optional
Beispiel:
Kundenkarte
Adresse
Telefon
Vorwahl
Strasse
Hausnummer
V
Vorname
Name
[ | ] Auswahl
{} Wiederholung
= Anrede + (Titel) + Vorname + Name + {Adresse} + Telefon
= Strasse + Hausnummer + PLZ + Ort
= Vorwahl + { [0|1|2|3|4|5|6|7|8|9] }
= 0 + [1|2|3|4|5|6|7|8|9] + { [0|1|2|3|4|5|6|7|8|9] }
= STRING
= STRING
= STRING
= STRING
Quelle: Wikipedia
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
11
Einfache Nomenklatur für den Architektur-Entwurf – „Krähenfuss“
1..*
0..1
Tabellen mit dem Singular des Inhaltes bezeichnen.
Primärschlüssel (PK) eindeutig kennzeichnen (ID_xxx).
Für Fremdschlüssel (FK)die Bezeichnung der Zieltabelle benutzen.
Im Architektur-Entwurf nur die wichtigsten Felder anzeigen.
Mehrere Gegenstände können von
einem Mitarbeiter ausgeliehen sein.
(Kardinalität als Zahl ist optional, wenn nötig)
Es gibt aber auch Gegenstände die
gerade nicht ausgeliehen sind, also
keine Verknüpfung zu einem Mitarbeiter haben.
Elementare Datentypen:
yp
ID
Texte
Zahlen
D t
Datum
NUMBER()
STRING(<Länge>)
NUMBER(<Vorkomma>, <Nachkomma>)
DATE DATETIME
DATE,
Wenn der Pfeil beschriftet ist (optional),
g = Pfeilrichtung.
g
Leserichtung
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
12
Datenbank und GUI – Master-Detail
Mitarbeiter
Abteilung
Meier, Hans
Burgmüller
Schulze
Schmidt
Lehmann
Vertrieb
Peronal
Entwicklung
Entwicklung
Pforte
Gegenstand
ausgeliehen am
Notebook 1
Beamer 1
3.10.2010
3.10.2010
Master
zurückgegeben am
Detail / Master
Beamer 1
Auflösung:
Anschlüsse
Anschlüsse:
Sonstiges:
DHBW-Stuttgart/Frank M. Hoyer
Detail
1024 x 768
DVI VGA
DVI,
eingebaute Lautsprecher
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
13
Abfrage aus der Datenbank - DeNormalisierung
DB
SQL
SELECT
FROM
WHERE
AND
ORDER BY
;
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
G.Name, L.ausgeliehen_am, M.Name
Gegenstand G, Ausleihliste L, Mitarbeiter M
G.ID_Gegenstand = L.ID_Gegenstand
M.ID_Mitarbeiter = L.ID_Mitarbeiter
L.ausgeliehen_am
16. Juli 2010
geändert: 12. Oktober 2015, FMH
14
ER-Diagramm im UML
In der UML kann man Tabellen, Primär und Fremdschlüssel u.s.w. nicht darstellen [Balzert],
eine Lösung bieten UML-Profile [UML for Database Design; Naiburg, Eric; 2001]
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
15
16. Juli 2010
geändert: 12. Oktober 2015, FMH
16
ER-Diagramm im yED:
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
Best Practices: CodeTabellen für Auswahlfelder
Auswahlfeld in der GUI
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
17
Glossar
Entity:
Relation:
Row:
Column:
SQL:
Kardinalität:
Key:
View:
Normalisierung:
Validierung:
DHBW-Stuttgart/Frank M. Hoyer
Datenbank-Tabelle
Beziehung zwischen Datenbank-Tabellen
Zeile in einer Datenbank-Tabelle oder aus einer Datenbank-Abfrage
Spalte in einer Datenbank-Tabelle oder aus einer Datenbank-Abfrage
Abfragesprache für relationale Datenbanken
Wertigkeit der Beziehung zwischen den Tabellen
Eindeutiger Schlüssel auf einen Datensatz (Zeile)
Sicht auf eine oder mehrere Datenbank-Tabellen, ähnlich einer SQL-Abfrage
Vereinfachung der Struktur, damit Werte nicht doppelt gespeichert werden
Überprüfung zulässiger Werte
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
18
http://de.wikipedia.org/wiki/NoSQL_(Konzept)
noSQL – nicht relationale Datenmodelle
DB
Map
ID=1
ID=2
Name=Hans
Name=Audi
Ort=Stuttgart
Motor=Diesel
Reduce
Telefon=0711
Leistung=150
Liste
Lotus Notes
Si l DB
Simple
DHBW-Stuttgart/Frank M. Hoyer
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
19
SWE1 - 06. SW-Architektur - Datensicht
16. Juli 2010
geändert: 12. Oktober 2015, FMH
20
Fragen:
DHBW-Stuttgart/Frank M. Hoyer