Software Engineering Prof. Dr. Stefan Enderle NTA Isny
5 Arbeitsschritt Entwurf
5.1 Einführung Analyse: Beschreibung des Systems auf abstrakte Art, unabhängig von der verwendeten Technologie. Entwurf: Berücksichtigung von konkreten Technologien Grundlage für unmissverständliche Implementierung
Produkte von Analyse und Entwurf
Ausgangspunkt Produkte der Analyse: Anwendungsfälle Analysemodell Domänenmodell Analyseprototyp Stand der Technik / Erfahrung: Qualitätsanforderungen User Interface Design Fehlerbehandlung Architekturkonzepte
Ergebnis Produkte des Entwurfs: Architekturbeschreibung Systemaufteilung (Subsysteme) Anwenderschnittstelle (User Interface) Datenbasis Geschäftslogik
Ergebnis graphisch
5.2 Analyse technischer Varianten Beispiel: Auswahl einer Entwicklungsumgebung 2 Möglichkeiten: Möglichkeit 1: Nutzen der Standard-Entwicklungsumgebung, Systementwurf nach deren Möglichkeiten Möglichkeit 2: Wahl einer optimalen geeigneten Entw.umgeb. Auswahl durch wenige, entscheidende Projektmerkmale
Vor- / Nachteile Möglichkeit 1: Bestehende Entwicklungsumgebung: Vorteile: Erfahrung im Unternehmen Gute Programmierer Einsparen von Schulungskosten Nachteile: Entwicklung auf bestimmte Technologien begrenzt Einschränkungen bei der Implementierung (Projekt evtl. nicht realisierbar oder suboptimal) Innovation ist ausgeschlossen
Vor- / Nachteile Möglichkeit 2: Auswahl einer optimal geeigneten Entw-.Umg: Vorteile: Flexibilität Innovation (Theoretisch) optimale Lösung Nachteile: Hohes Risiko: Entwickler / Erfahrung vorhanden? Evtl. hoher Schulungsaufwand Auswahl selbst ist evtl. schwierig und langwierig
Merkmale von Entw.Umg. Die Auswahl einer Entwicklungsumgebung können verschiedene Merkmale beeinflussen: Unterstützung von Architekturkonzepten z.b. Datenbanken, Client-Server-Lösungen,... Leistung einzelner Komponenten z.b. Bibliotheken, User-Interface,... Verfügbarkeit von User-Interface Editor/Bibliothek (Eigenentwicklungen haben sehr schlechtes Kosten/Nutzen-Verhältnis) Unterstützung von Sprachkonzepten z.b. Objektorientierung, Fehlerbehandlung,... Portierbarkeit der Applikation Unterstützung von Versionsmanagement Eliminieren von Fehlern mit externen Programmen
Merkmale von Entw.Umg. (2) Merkmale unabhängig vom aktuellen Entwurf: Qualität einzelner Tools Compiler, Debugger, Editor Integration in Systemumgebung Betriebssystem, Zusammenarbeit mit anderen Tools Erweiterbarkeit und Anpassbarkeit Hersteller und Preis Oft umfangreicher aber teurer Support
Analyse technischer Varianten Allgemein müssen häufig Varianten von Systemen verglichen werden: Merkmalstabelle
Beispiel: UML-Tool Auswahl eines geeigneten UML-Tools: ArgoUML Visual Paradigm Merkmalstabelle! Siehe Praktikum...
5.3 Systemarchitekturen Shaw '96: Software-Architektur beinhaltet die Beschreibung von Elementen, aus denen Systeme gebaut werden, Interaktionen zwischen diesen Elementen, Muster, die deren Zusammensetzung steuern, und Einschränkungen in Bezug auf diese Muster. Ein bestimmtes System wird beschrieben durch die Sammlung von Komponenten und Interaktionen zwischen diesen Komponenten.
Beispiele Administratives Stand-Alone System vs. Embedded-/Echtzeitsystem
Beispiel Verteiltes System (Client-Server)
Schnittstellen Input: Daten Steuerinformation Je nach Systemarchitektur verschiedene Schnittstellen: Stand-Alone System: Über User-Interface Bei Embedded-system: Über Hardware Bei verteiltem System: Über mehrere UIs, Netzwerk
Stand-Alone vs. Verteiltes System Stand-Alone System: System, das auf einem einzelnen Rechner ausführbar ist. Ohne Netzwerk. Verteilte Systeme: Client/Server-System: Über ein Netzwerk zusammenarbeitende Anwendungen Jeweils Server (Dienst-Anbieter) oder Client (Nutzer) Server meist auf leistungsfähigen Rechnern Peer-to-Peer-System: Anwendungen haben ähnliche Fähigkeiten Jede Anwendung bietet und nutzt Dienste gleichermaßen Master/Slave-System: Master-Anwendung übt Kontrolle über Slaves aus
Schichten-Architekturen Eine Anwendung als EINEN Block zu sehen ist keine Architektur! Einfachste Unterteilung unterteilt in zwei Bereiche Zwei-Schichten Architektur
Zwei-Schichten-Architektur 2 Schichten: Anwendung Datenbank Eine oder mehrere verteilte Applikationen Datenbank können auch strukturierte Dateien sein Applikationen enthalten UI und Logik
Drei-Schichten-Architektur 3 Schichten: Anwendung Datenbank Domäne / Logik Domäne / Logik übersetzt zwischen User-Interface und Datenbank Bsp: Objekte <-> XML
Mehr-Schichten-Architekturen Hauptsächlich bei verteilten Systemen kann es sinnvoll sein, mehr als drei Schichten zu definieren. Beispiel: Architektur der Ticket-Line
5.4 Darstellung von Systemarchitekturen in UML Prinzip Divide-and-Conquer ( Teile und Herrsche ) Durch die Unterteilung eines Systems in Module können folgende Eigenschaften erzielt werden: Aufgabenteilung Gut für Fehlersuche (wegen Begrenzung) und für Änderungen Skalierbarkeit Leichteres Erweitern oder Entfernen von Modulen, ohne das Gesamtsystem zu beeinflussen Wartbarkeit Leichteres Austauschen von Modulen,
Diagramm-Arten Zur Darstellung von Systemarchitekturen werden meist folgende UML-Diagrammarten verwendet: Subsystemdiagramm Implementierungsdiagramm Auslieferungsdiagramm
Subsystemdiagramm Zeigt die Aufteilung eines Systems in Subsysteme Subsystem = Rechteck mit Tab und Gabel Schnittstelle (Service) = kleiner Kreis Zugriff auf Schnittstelle = gestrichelter Pfeil
Subsystemdiagramm Subsysteme: Administration, Kassa, Kiosk Kiosk greift auf Administration über Schnittstelle Daten zu. Administration verwendet eine Schnittstelle von Kassa. <<stub>> deutet an, dass es sich nur um einen Stellvertreter handelt, der die Daten weiterleitet oder Standardantworten z.b. für Testzwecke schickt.
Subsystemdiagramm Eine Schnittstelle kann auch genauer spezifiziert sein, dann wird eine Schnittstellenklasse verwendet (mit <<interface>>). Beispiel: Schnittstelle Daten von vorher
Subsystemdiagramm In einem Subsystemdiagramm können zusätzlich Zusammenhänge zu Elementen der Analyse dargestellt werden: Zwei Hälften: Specification Elements = Analyse (z.b. Anwendungsfälle), Realization Elements = Entwurf
Implementierungsdiagramm Zeigt die Aufgliederung des Quellcodes und gegenseitige Abhängigkeit Komponenten = Rechteck mit 2 kleineren Rechtecken Komponenten bestehen meist aus mehreren Klassen
Implementierungsdiagramm Admin greift auf Admin DB und auf Admin Kommunikation zu. Kiosk greift über Kiosk Kommunikation auf Admin Kommunikation zu.
Auslieferungsdiagramm Zeigt die Maschinen/Geräte der Zielumgebung z.b. PCs, Server, Controller Maschine = 3D Rechteck Innerhalb der 3D Rechtecke wieder Komponenten (wie im Implementierungsdiagramm) + Komponenten der Zielumgebung Instanzen!
Auslieferungsdiagramm Zwei Maschinenklassen: Server und InfoTerminal Administration und Kiosk wurden zufammengefasst Jedes Kiosk greift auf den Server über die AdministrationSchnittstelle zu Administration benutzt die Datenbank des Servers
5.4 Umsetzung der Analyse-Anforderungen Aus den Anforderungen der Analyse müssen hauptsächlich folgende Teile entworfen werden: Anwenderschnittstelle (User Interface) Geschäftslogik Datenbasis
5.4.1 Entwurf der Anwenderschnittstelle Über das User-Interface müssen Mensch und Maschine zusammenarbeiten Funktionelle Dinge: Effektive Dateneingabe Schnelle Steuerung Subjektive Dinge: Reaktivität Vertrauensvoll Keine grafische Überladung o.ä. Gimmicks Gesamtfunktionalität muss passen
Entwurf der Anwenderschnittstelle Aus Maci '92: Know your Audience Konsistente Gestaltung Metaphern (Konzepte aus anderem Zusammenhang) Direkte Interaktion (Erfolg, Misslingen,...) Benutzerführung vs. geführter Benutzer Feedback bei längeren Aktionen Fehlertoleranz (Rückgängig-machen)
Beispiele Ist folgende Anwenderschnittstelle besonders gut oder schlecht?
Beispiele Schlecht! Zu viele Informationen Vermischen von Kundendaten Passwort, PIN... Tabelle mit EINER sichtbaren Zeile
Beispiele Gut / Schlecht?
Beispiele Schlecht! Schlechte Anordnung der Elemente Fenstersteuerung fehlt Schriftgrößen eher zufällig
Typischer Entwurfsablauf Grafischer Entwurf mit später verwendeter Entwicklungsumgebung Vorteil: Weiterverwendung für Implementierung Aber: Aufbereitung als Entwurf: Separate Archivierung Dokumentation mit Screenshots
Inhalt: Entwurf Anwenderschnittstelle Ein Entwurf der Anwenderschnittstelle sollte beinhalten: Name der Klasse Bild/Grafik der Anwenderschnittstelle Initialisierung aller Elemente Objekte, deren Attribute durch die Anwenderschnittstelle angezeigt/verändert werden Dynamisches Verhalten des Dialogs Aktionen, die über die Anwenderschnittstelle ausgelöst werden können: über Menüs bei Aktivierung oder Verlassen von Dialogelementen über Kontextmenüs direkte Manipulation (Drag&Drop, Doppelklick,...) Fehlerhafte Aktionen ( Bearbeiten ohne Auswahl etc.) Aktionen, die beim Schließen des Dialogs auszuführen sind.
Beispiel: Entwurf User-Interface (1)
Beispiel: Entwurf User-Interface (2) Verwendete Obekte: In ListBox Suchergebnis werden Objekte der Klasse Veranstaltung angezeigt Dynamisches Verhalten: Das Fenster kann nicht vergrößert oder verkleinert, aber minimiert werden. Aktionen: Suchen: Die Werte aus den Feldern der Gruppen Aufführungsort, Veranstaltung und Stammdaten werden als Suchkriterium verwendet. Das Suchergebnis wird in Listbox Suchergebnis dargestellt. Übernehmen: Der ausgewählte Eintrag wird an das aufrufende Fenster zurückgeliefert. Schließen: Das Fenster wird geschlossen Doppelklick auf Eintrag in Listbox Suchergebnis zeigt den Datensatz im Detail in UIVeranstaltung an
Benutzbarkeitstest Zwei Möglichkeiten: Usability-Richtlinien Tausende spezifische Regeln Heuristische Evaluation Wenige Heuristiken Vorteile der Heuristischen Evaluation: Kann auch von Nicht-UserInterface-Experten durchgeführt werden Schneller Günstiger
Heuristische Evaluation (1) Allgemein akzeptierte Heuristiken für User-Interfaces: Einfache und natürliche Dialoge Keine irrelevanten Informationen Natürliche Abfolge der Informationen Sprache des Benutzers Keine Gedächtnisbelastung Der Benutzer sollte nicht gezwungen sein, sich Informationen von einem Dialog zum nächsten zu merken. Konsistenz Gleiche Begriffe, Aktionen, Situationen sollen immer das Gleiche bedeuten. System-Aktion durch Benutzer-Aktion. Feedback: Information des Benutzers, was gerade passiert.
Heuristische Evaluation (2) Klare Ausstiegspunkte Situationen vermeiden, in denen der Anwender keinen Ausgang findet Zurück oder Abbruch Shortcuts Abkürzung aufwändiger Dialoge für geübte Benutzer Gute Fehlermeldungen Defensiv: Darlegung des Problems, Keine Kritik! Präzise: Exakte Information über die Ursachen des Problems Konstruktiv: Vorschlag von Lösungen Verhindere Fehler: Gutes Design kann viele Fehler verhindern
5.4.2 Entwurf der Geschäftslogik Geschäftslogik = Funktionalität des Systems: Statischer Teil (Klassen, Daten) Dynamischer Teil (Abläufe) Ansatz: Analysemodell bietet bereits mögliche Einteilung in Klassen Erweiterung um zusätzliche Details
UML Klassendiagramm Beispiel: Analyse des Ticket Systems als Klassendiagramm Ticket {abstract} Veranstaltung Aufführungssaal Datum Platz-Ticket Platz Platz_zuweisen Platz_ändern Typen? Sichtbarkeit? verkaufen stornieren suchen Zähl-Ticket Anzahl_Plätze Anzahl_zuweisen Anzahl_ändern
Erweiterungen Sichtbarkeit der Attribute: Angaben durch Zeichen vor dem Attributnamen: + = public: Systemweiter Zugriff - = protected: Zugriff nur durch Instanzen der Klasse # = protected: Instanzen der Klasse und Unterklassen unterstrichen = class-scope (static): Systemweiter Zugriff ohne Instanz (Eigenschaft der Klasse) Fenster Standardgröße +aktuellegröße -tags #owner
Erweiterungen Typen der Attribute: Angabe des Typs nach : hinter dem Attributnamen: Fenster Standardgröße: Rechteck +aktuellegröße: Rechteck -tags: byte #owner: Fenster*
Erweiterungen Initialisierung der Attribute: Initialisierungswerte werden nach = hinter dem Typ angegeben: Fenster Standardgröße: Rechteck = (200,100) +aktuellegröße: Rechteck -tags: byte = 128 #owner: Fenster* = NULL
Erweiterungen Sichtbarkeit der Methoden: Angabe von +, -, #, _ wir bei Attributen: Fenster Standardgröße: Rechteck = (200,100) +aktuellegröße: Rechteck -tags: byte = 128 #owner: Fenster* = NULL -zeigefenster +öffnen +anzkinder #minimiereallekinder
Erweiterungen Typen der Parameter und Rückgabewerte von Methoden: Wie bei Attributen: Name : Typ: Fenster Standardgröße: Rechteck = (200,100) +aktuellegröße: Rechteck -tags: byte = 128 #owner: Fenster* = NULL -zeigefenster() +öffnen(owner:fenster*):boolean +anzkinder():int #minimiereallekinder()
Vereinbarungen Um das Klassendiagramm nicht zu überladen, wurde vereinbart, dass folgende Kategorien von Methoden weggelassen werden: Konstruktoren: Initialisierung des Objekts Destruktoren: Maßnahmen vor Beendigung des Objekts Set-Methoden: Setzen (einzelner) Attributwerte Get-Methoden: Lesen (einzelner) Attributwerte
Fehlerbehandlung Zur statischen Systembeschreibung gehört auch die Fehlerbehandlung Typischer Fehlerursachen: Falscheingabe des Benutzers Abbruch eines Algorithmus aufgrund bekannter Bedingungen Abbruch eines Vorgangs durch den Benutzer Inkonsistenzen von Daten im Speicher oder Datenbank Abbruch eines Vorgangs aufgrund ungültiger oder unvollständiger Daten
Fehlerbehandlung Mögliche Maßnahmen zur Fehlerbehandlung: Fehler ignorieren unbestimmbares und oft untragbares Verhalten Abbruch der gesamten Applikation meist unzumutbar Wert für die Ungültigkeit eines Ergebnisses gute Dokumentation! Statusvariablen gute Dokumentation + Benutzung! Statusmethoden (wie oben) Einer der Rückgabewerte als Fehlerwert OK, aber unschön Exception-Handling Sauberste Lösung, Trennen von Code und Ferhlerbehandlung
Wdh: Exceptions Beispiel: Werfen einer Ausnahme mit throw: double squareroot(double value) { if (value < 0) throw Wert kleiner 0 ; return sqrt(value); } Es können beliebige Typen/Klassen geworfen werden.
Wdh: Exceptions Exception-Handler mit try/catch: try { a = sqareroot(1.0); b = sqareroot(-1.0); c = sqareroot(2.0); } catch (const char* exc) { cerr << Fehler: << exc << endl; exit(1); }
Fehlerbehandlung Vorschlag: Eigenes Dokument Fehlerbehandlung mit Definition aller Mechanismen z.b. Exceptions und globale Variablen Definition aller Konstanten z.b. Exception-Klassen und Werte für globale Variablen Definition von Standard-Fehlermeldungen an den Benutzer z.b. Keine gültige Zahl verschiedene Sprachen?
5.4.3 Dynamische Abläufe Das Analysemodell besitzt auch bereits dynamische Diagramme : Kollaborationsdiagramm Sequenzdiagramm Zustandsdiagramm Im Entwurf werden diese überprüft an Datentypen angepasst ggfs. erweitert oder verändert.
Wdh: Sequenzdiagramm
Wdh: Zustandsdiagramm
5.4.4 Datenbasis Das Analysemodell besitzt eine objektorientierte Beschreibung der Datenbasis Beim Entwurf: Übergang zum tatsächlichen Speichermedium. Beispiele/Möglichkeiten: Strukturierte Dateien Relationale Datenbanken XML (Objektorientierte Datenbanken)
Strukturierte Dateien Die zu speichernden Daten werden in eine Datei geschrieben. Oft wird das ASCII-Format benutzt. Trennung durch White spaces (Leerzeichen, Tab, Newline) Problem: Strukturierung nur durch Abfolge der Daten Beispiel: Konfigurationsdatei ; lame configuration [InputFileTypes] Audio-Files=*.wav;*.aif;*.aiff;*.mp3;*.mp2;*.mp1 Wave-Files=*.wav MP3-Files=*.mp3 MPx-Files=*.mp3;*.mp2;*.mp1 AIFF-Files=*.aif;*.aiff...
Strukturierte Dateien Die Struktur der Datei muss in einem eigenen Dokument beschrieben werden Für komplexere Dateistrukturen bietet sich die Definition einer Grammatik an Beispiel: Grammatik Datei = Dateikopf Dateikopf Dateirumpf Dateikopf = Autorenname Datum Zweck Dateirumpf = Ausdruck Befehl Dateirumpf Ausdruck Dateirumpf Befehl Ausdruck = Zahl Ausdruck + Zahl Ausdruck Zahl Befehl = Text Autorenname = Text Datum = tt.mm.jjjj Zweck = Text
XML XML = Extensible Markup Language Sprache für Datenaustausch und Dokumentenmarkierung ASCII Datei
XML Ein XML-Dokument besteht aus Elementen. Ein Element ist Text, der in zueinander passende öffnende und schließende Tags eingeschlossen ist. Beispiel: <book> Mein Lieblingsbuch </book>
XML Innerhalb eines Elements kann stehen: gewöhnlicher Text wieder Elemente beides Beispiel: <book> Mein Lieblingsbuch <autor> Stefan Enderle </autor> </book>
XML Tags markieren die Struktur des Dokuments Der Text stellt den Inhalt dar.
XML <bibliographie> <buch> <artikel> <autor> E.F. Codd <autor> S. Abiteboul </autor> </autor> <titel> A Relational Model of Data Banks <autor> R. Hull </autor> </titel> <journal> Communications of the ACM <titel> Foundation of Databases </titel> </journal> <jahr> 1970 <verlag> Addison-Wesey </jahr> </verlag> </artikel> <jahr> </bibliographie> 1985 </jahr> </buch>
XML Die Gesamtstruktur ist immer ein Baum. Welche Knoten welche Unterknoten haben können wird durch eine separate Datei definiert: Document Type Definition DTD Die DTD ist im wesentlichen eine kontextfreie Grammatik!
XML Beispiel: Bisherige Schreibweise: bibliographie buch artikel autoren autor titel journal jahr verlag (buch artikel)* autoren titel verlag jahr autoren titel journal jahr autor autor autoren text text text text text
XML Beispiel: DTD Schreibweise: <!ELEMENT bibliographie (buch artikel)+ > <!ELEMENT buch (autor+,titel,verlag,jahr)> <!ELEMENT artikel (autor+,titel,journal,jahr)> <!ELEMENT autor PCDATA> <!ELEMENT titel PCDATA> <!ELEMENT journal PCDATA> <!ELEMENT jahr PCDATA> <!ELEMENT verlag PCDATA>
XML Das heißt: Die DTD ist die Grammatik, die eine Sprache definiert (nämlich die erlaubten XML Dateien). Eine konkrete XML Datei ist dann EIN mögliches Wort aus dieser Sprache, mit einem bestimmten Ableitungsbaum.
XML Verarbeitung Verarbeitung: Lesen und Auswerten der XML Datei Speichern von Daten als XML Datei XML Dateien werden meist durch eines der beiden Frameworks gelesen: SAX DOM
SAX SAX = Simple API for XML Erlaubt Verarbeitung einer XML-Datei schon während des Einlesens. Hierzu werden Events generiert, die dem XML-Stream entsprechen. Ereignisbasiert
SAX Beispiel: <book> Mein Lieblingsbuch </book> Events: start-tag( book ) character-data( Mein Lieblingsbuch ) end-tag( book )
SAX Vorteil: Kein Einlesen der gesamten Datei nötig Nachteil: Kein späterer Zugriff auf Daten möglich
DOM DOM = Document Object Model Liest komplette XML-Datei ein... und wandelt sie in einen Baum um.
DOM Beispiel: Ausschnitt aus HTML-Datei DOM Baum
DOM Zugriff auf die Baumstruktur: Elemente des Baumes können dann mit bestimmten Funktionen verarbeitet werden: Elemente lesen Elemente suchen Elemente verändern Elemente löschen
DOM Beispiel: Zugriff auf Elemente (Qt): Dokument spezifizieren: QDomDocument doc("mydocument"); Oberstes Element lesen: QDomElement docelem = doc.documentelement(); Ersten Kind-Knoten lesen: QDomNode n = docelem.firstchild(); Nächsten Kind-Knoten lesen: n = n.nextsibling();
XML Verarbeitung in Qt s. Übung
Datenbanken XML: XML dient der strukturierten Speicherung von Daten in separaten Dateien (XML Datei). Die Inhalte der XML Dateien können baumartig strukturiert sein. (Relationale) Datenbanken: Datenbank unterstützen ebenfalls die strukturierte Speicherung von Dateien. Zusätzliche Features: Einfaches Suchen und Einfügen von Datensätzen Client-Server-Betrieb Replikation Relationale Datenbank: Tabellen zur Strukturierung
Datenbanken Querbezug: Hierarchisches Datenbankmodell Beispiel: DOS oder UNIX Dateisystem eintspricht dem hierarchischen Datenbankmodell Hierarchie = Baum Es sind nur 1:n Beziehungen möglich Jedes Verzeichnis kann beliebig viele Unterverzeichnisse (mit Daten) enthalten. Umgekehrt jedoch nur genau eines! DOS / UNIX Kommandos können als Tools zur Benutzung der Datenbank betrachtet werden.
Relationale Datenbanken Ein Relationales Datenbanksystem besteht aus Datenbank Die eigentliche Datenmasse. Besteht ggfs. aus vielen Dateien, die jeweils Tabellen mit Daten beinhalten. Datenbank Management System (DBMS) Vielzahl von Werkzeugen, mit denen die Daten eingegeben geändert, verwaltet geschützt gesichert abgefragt bzw. gesucht werden können.
Relationale Datenbanken In einer relationalen Datenbank werden Objekte mit deren Attributen gespeichert. Die Haupt-Beschreibungseinheit ist eine Tabelle. Die Überschriften der Tabelle entsprechen den Attributen einer Klassendefinition Für jedes Attribut genau eine Spalte. In jeder Zeile der Tabelle befindet sich dann genau ein Objekt der Klasse
Relationale Datenbanken Beispiel Klasse in UML: Datenbank-Schema: Dozent Kürzel : char[3] Vorname : string Nachname : string Raum : string Telefon : int Tabelle Dozenten
Relationale Datenbanken Primärschlüssel: Für den eindeutigen Zugriff auf ein Objekt, muß mindestens eine Spalte das Schlüsselattribut Primärschlüssel enthalten. Durch den Primärschlüssel müssen die Zeilen der Tabelle eindeutig voneinander zu unterscheiden sein. Gegebenenfalls muß ein Schlüsselattribut zusätzlich "erfunden" werden, wenn keines der Attribute die Bedingung der Eindeutigkeit erfüllt. Beispiel: Index
Relationale Datenbanken Problem: Manche Dozenten halten sich oft in zwei oder mehr Räumen auf. Schlechte Lösungen: Noch eine Zeile mit anderem Raum ( fast gleiches Objekt nochmal) Weitere Spalten Raum 2, Telefon 2,... ( Wieviele?)
Relationale Datenbanken Gute Lösung: Aufteilen der Tabelle in Wiederholungsdaten und sich nicht wiederholende Daten. Tabelle Dozenten Tabelle Räume
Relationale Datenbanken Tabelle Dozenten Tabelle Räume In Dozenten ist Kürzel der Primärschlüssel In Räume ist Kürzel der Fremdschlüssel und kann auch mehrfach vorkommen.
Relationale Datenbanken Tabelle Dozenten Tabelle Räume 1. Problem gelöst: Ein neuer Raum für einen Dozenten wird einfach als weitere Zeile in Räume hinzugefügt.
Relationale Datenbanken Tabelle Dozenten Tabelle Räume Neues Problem: Räume und zugehörige Telefonnummern tauchen mehrfach auf. Was tun, wenn sich die Tel.Nr. eines Raumes ändert?
Relationale Datenbanken Man sieht, dass ein sauberer Entwurf einer Datenbank wichtig ist. Einige Regeln: Zeilen können jederzeit hinzugefügt werden, Spalten nicht! Keine Redundanz! Jede Angabe über eine Person oder Sache sollte nur einmal gespeichert sein. Unveränderliche Daten immer bevorzugen (Geburtstag anstatt Alter, usw.)
Relationale Datenbanken Beispiel: Ein Dozent will für sich selbst eine kleine Datenbank mit Studenten und deren Prüfungsleistungen anlegen. Er benötigt folgende Daten: Matrikelnummer Name Vorname Geburtsdatum Fach Semester Prüfungsdatum Note Note in Worten Wie könnte(n) die Tabelle(n) aussehen?
SQL Zugriff auf eine Relationale Datenbank PC Anwendungen mit Oberfläche: früher Borland mit dbase jetzt Access weitere: FoxPro, Paradox Auf Großrechnern und Client-Server Lösungen: SQL Structured Query Language SQL findet man in Oracle, DB/2, Informix,... Seit 1989 genormt (ANSI und ISO)
SQL Wichtige Befehle in SQL Anlegen einer neuen Datenbank: CREATE DATABASE dbname ; Löschen einer Datenbank: DROP DATABASE dbname ;
SQL Wichtige Befehle in SQL Anlegen einer neuen Tabelle: CREATE TABLE tabname ( Attribut Datentyp [, Attribut Datentyp,...] ); Einige Datentypen: INTEGER DECIMAL(i,n) DATE CHAR(n) Ganze Zahlen Dezimalzahl mit insgesamt i Stellen (einschließlich Dezimalpunkt), davon n Nachpunktstellen Datum, Format entsprechend Landeseinstellung, z. B.: tt.mm.jjjj String mit n Zeichen
SQL Beispiel: CREATE TABLE Student ( MatNum CHAR(7), Name CHAR(20), VName CHAR(15), GebDat DATE ) ;
SQL Wichtige Befehle in SQL Anlegen einer neuen Tabelle: INSERT INTO tabname VALUES ( Wert [, Wert... ] ) ; Beispiel: INSERT INTO Student VALUES ( 1230815, Korn, Klara, {14.04.1970} ) ;
SQL Wichtige Befehle in SQL Ändern einer Zeile: UPDATE tabname SET Attribut=Ausdruck [, Attribut=Ausdruck... ] WHERE Bedingung ; Löschen einer Zeile: DELETE FROM tabname WHERE Bedingung ;
SQL Beispiel: UPDATE Student SET GebDat={12.04.70} WHERE Name= Korn ; DELETE FROM Student WHERE MatNum= 1230815 ; Achtung: Die Aktionen können mehrere Zeilen betreffen!
SQL Wichtige Befehle in SQL Auswählen / Suchen von Daten: SELECT Ausdruck [, Ausdruck... ] * FROM tabname [ WHERE Bedingung ] [ ORDER BY Attribut ] ;
SQL Beispiel: SELECT * FROM Student; SELECT Name, VName, MatNum FROM Student WHERE GebDat < {01.01.1980} ORDER BY Name;
SQL SELECT genauer: SELECT Ausdruck [, Ausdruck... ] * FROM tabname [ WHERE Bedingung ] [ ORDER BY Attribut ] ; in Ausdruck kann vorkommen: Attribute (Spalten-Überschriften), Operatoren (z. B.: + * / ), Klammern, Funktionen und komplette SELECT-Anweisungen (in Klammern).
SQL SELECT genauer: Funktionen können sein: Spaltenfunktionen MIN(Attribut) Minimum der Spalte Maximum der Spalte MAX(Attribut) AVG(Attribut) Durchschnitt der Spalte SUM(Attribut) Summe der Spalte COUNT(*) Anzahl der Zeilen Mathematische Funktionen String-Funktionen Datumsfunktionen...
SQL Weitere Beispiele: SELECT COUNT (*) FROM Student ; Anzahl der Eintragungen in der Tabelle Student. SELECT INT ((DATE () GebDat)/365) FROM Student WHERE MatNum= 1230816 ; Alter eines Studententen SELECT AVG (Note) FROM Note WHERE Fach= Mathe ; Durchschnitt aller Noten der Mathe-Prüfung. SELECT AVG (Zensur) FROM Zensuren WHERE (Fach = Mathe1 OR Fach = Mathe2 ) AND Note <= 4 ; Notendurchschnitt aller bestandenen Prüfungen in den Fächern Mathe1 und Mathe2.
SQL in C++/Qt Beispiele: Datenbank-Verbindung herstellen: QSqlDatabase db = QSqlDatabase::addDatabase("QMYSQL"); db.sethostname("bigblue"); db.setdatabasename("flightdb"); db.setusername("acarlson"); db.setpassword("1utbsbas"); bool ok = db.open(); Anfrage: QSqlQuery query; query.exec("select name, salary FROM employee WHERE salary > 50000"); Anfrage auswerten/anzeigen: while (query.next()) { QString name = query.value(0).tostring(); int salary = query.value(1).toint(); qdebug() << name << salary; }
Relationale Datenbanken s. Übung