Datenbank Grundlagen
Werbung
Bernhard Bausch Datenbanken und Informationssysteme 08.01.11 Technikerschule TS Kursunterlagen Datenbanksysteme Autor: Bernhard Bausch Versionsverzeichnis Version: Version 1.0 Version 2.0 Version 3.0 Version 3.1 www.babe-Informatik.ch Datum: 26.03.01 08.05.01 01.07.02 05.06.03 Revisionsgrund: Korr1 Ergänzung 7.1.4 Ergänzung ERM Überarbeitung Kapitel 6 2.1 Korr2 Korr3 2.2 Seite 1/32 Bernhard Bausch Schulungsunterlagen Datenbanken Inhalt 1 Das Datenbanksystem 1.1 Die Komponenten eines Datenbanksystems 1.2 Die Ebenen eines Datenbanksystems 1.3 Rechnerarchitektur für den Datenbankbetrieb 1.3.1 1.3.2 1.4 2.2 2.3 10 10 10 10 10 10 10 10 11 11 Der Projekt-Lebenszyklus 11 3.1.1 3.1.2 Das Wasserfallmodell Die unterschiedlichen Analyse- und Designmethoden Kontextdiagramm Die Event-Liste Datenfluss-Diagramme (DFD) 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 Modelle Die Unterschiedlichen Ebenen im Modell Das Datenfluss-Diagramm Modell Die Symbole der Komponenten Erweiterte Diagrammtechniken Entity Relationship Diagramm (ERD) 4.1 Bestandteile eines ERD's 4.1.1 4.1.2 4.2 8 8 8 11 11 Das essentielle Modell in der Analyse 3.1 Das Umgebungsmodell 3.2 8 Bottom-up-Verfahren Top-down-Verfahren 2.4.1 2.4.2 4 Online-Systeme Batch-Systeme Realtime-Systeme DecisionSupport-Systeme Knowledgebased-Systeme Kategorisierung in der Praxis Wer sind die Mitspieler bei Analyse und Design von Softwaresysteme Projektverfahren oder Vorgehensweise 2.3.1 2.3.2 2.4 6 7 Aufbau einer Tabelle (auch Relation genannt). Spaltenbedingungen Datentypen Analyse und Design von Software-Systeme 2.1 Software-Systeme 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 3 Zentrale Architektur Netzwerkarchitektur Struktur und Eigenschaften von Tabellen 1.4.1 1.4.2 1.4.3 2 4 4 5 6 Entitäten Beziehungen zwischen den Entitäten Beispiel eines Entity Relationship Diagrammes 12 13 13 13 13 14 15 15 15 15 15 16 18 18 18 19 21 5 Auflösen von nicht-hierarchischen Beziehungen 22 6 Relationale Integritätsregeln 6.1 Entity Integrität 6.2 Referenzielle Integrität 6.3 Konsistenz-Bedingungen 24 24 24 25 7 Entwickeln von relationalen Datenbanken 7.1 Grundsätze 26 26 7.1.1 7.1.2 7.1.3 7.1.4 7.1.5 7.2 Mutationsanomalie Keine Redundanz Eindeutigkeit Schlüssel (Key's) Daten- oder Tabellencharakter Datenstruktur - konzeptionelles Datenmodell 7.2.1 Abhängigkeiten von Attributen www.babe-informatik.ch 26 26 26 26 27 28 28 Seite 2/32 Bernhard Bausch 7.2.2 7.2.3 7.2.4 7.2.5 Die Erste Normalform Die Zweite Normalform Die Dritte Normalform Denormalisierung www.babe-informatik.ch Schulungsunterlagen Datenbanken 30 30 32 32 Seite 3/32 Bernhard Bausch 1 Schulungsunterlagen Datenbanken Das Datenbanksystem 1.1 Die Komponenten eines Datenbanksystems Eine Datenbank ist eine systematische Sammlung von Daten. Zur Verwaltung und Nutzung, der in der Datenbank gespeicherten Daten, benötigt der Anwender ein Datenbankverwaltungssystem. Ein Datenbanksystem besteht somit aus der Datenbank und dem Datenbankverwaltungssystem. In Anlehnung an den amerikanischen Sprachgebrauch wird für das Datenbankverwaltungssystem die Abkürzung DBMS (Data Base Management System) verwendet. Datenbanksystem Datenbankverwaltungssystem (DBMS) Datenbank Datentabellen Datentabellen Datentabellen Das DBMS besteht aus einer Vielzahl von Werkzeugen und Generatoren. Es stellt dem Entwickler die Instrumente zur Verfügung, mit denen er das Datenmodell beschreibt und einrichtet. Ferner muss das Datenbankverwaltungssystem die Funktionen anbieten, mit denen die Anwender Daten eingeben, verändern, abfragen und ausgeben können. Mittels Masken- und Listengeneratoren werden die Eingabe- und Ausgabeprogramme auf relativ einfache Weise erzeugt. Für Abfragen schafft das SQL-Modul einen direkten Zugriff auf die Daten. Schliesslich muss das Programm für die zweckmässige Speicherung der eingegebenen Daten sorgen. Der Entwickler teilt dem Programm die Datenlogik mit, der Anwender formuliert seine Abfrage. Wie die Daten zu speichern sind und welche Suchstrategie am besten anzuwenden ist, das ist Sache des Datenbankprogramms. Es ist also zuständig für die technische Umsetzung der Anforderungen von Entwickler und Anwender. DBMS, Database Management System Normal Anwender Fortgeschrittene Anwender AnwendungsProgrammierer Datenbank Administrator Applikationen Interaktives Abfragetool Compiler VerwaltungsWerkzeug DDL-Compiler (Data Definition Language) DML-Compiler (Data Manipulation Language) Anfangabarbeitung Schemaverwaltung Datenbankmanager Datenverwaltung www.babe-informatik.ch Log Dateien................................................................................................... Indexes......................................................................................................... Datanbasis.................................................................................................... Datendictionary............................................................................................. Daten Seite 4/32 Bernhard Bausch Schulungsunterlagen Datenbanken 1.2 Die Ebenen eines Datenbanksystems Um die Stellung des Nutzers im Datenbanksystem besser erklären zu können, bedient man sich der logischen Einteilung in Sichten (Views) bzw. Ebenen. Ebenen eines Datenbanksystems Externe Sicht Nutzer1 SQL Nutzer n DQL DML Programm 1 Kozeptionelle Sicht Interne Sicht Programm 2 Logische Datenstrukturen DDL DCL TPL Physische Datenstrukturen BETRIEBSSYSTEM HARDWARE Externe Sicht Auf der obersten Ebene befindet sich der Anwender, der das Datenbanksystem mit einer Datenabfragesprache (DQL = Data Query Language) oder Datenmanipulationssprache (DML = Data Manipulation Language) oder einem eigenen Anwendungsprogramm nutzt. Diese Ebene wird als Externe Sicht (external view) bezeichnet. Konzeptionelle Sicht Auf der zweiten Ebene, der konzeptionellen Sicht, wird das Datenmodell beschrieben. Unter einem Datenmodell versteht man die datenmässige Abbildung eines bestimmten Ausschnitts der realen Umwelt. In ihm sind die Strukturen der Daten und ihre Beziehungen in dem Datenmodell festgelegt. Die Art, wie die Beziehungen in dem Datenmodell geregelt werden, nennt man relationales Datenmodell. Interne Sicht Auf der inneren Ebene erfolgt die physische Speicherung der Daten. Die Speicherlogik, die dabei angewendet wird, hängt vom DBMS ab. Darum braucht sich der Anwender aber nicht zu kümmern. Die Daten werden in sogenannten Basistabellen gespeichert. Darüber hinaus benötigt das DBMS eine Vielzahl von weiteren Informationen, die in den Systemtabellen gespeichert werden. So werden die Informationen über die logische Struktur der Datenbank in dem Systemkatalog, auch Data Dictionary genannt, gesammelt. Der Systemkatalog enthält Systemdateien, die zum Beispiel darüber Auskunft geben, - welche Tabellen die Datenbank enthält - wie die Spalten der Tabellen heissen - welcher Datentyp bei einer Spalte vorliegt - in welcher Relation stehen die Tabellen zueinander www.babe-informatik.ch Seite 5/32 Bernhard Bausch Schulungsunterlagen Datenbanken Für die Verwaltung der Zugriffsberechtigung auf die Tabellen der Datenbank werden die Anweisungen der Data Control Language (DCL) eingesetzt. Die Kommandos die für die Sicherungsmassnahmen bei Datenübertragungen benötigt werden, bezeichnet man als TPL (Transaction Processing Language) 1.3 Rechnerarchitektur für den Datenbankbetrieb Eine DBMS muss auf der inneren Ebene auf das Betriebssystem abgestimmt sein, auf dem es aufsetzt. Datenbankverwaltungssysteme wie zum Beispiel SYBASE, INFORMIX, ORACLE oder SQL laufen nämlich auf Einzelplatz- und Mehrplatzbetriebssystemen sowie auch in lokalen Netzwerken. Die externe und die konzeptionelle Ebene werden davon nicht berührt. 1.3.1 Zentrale Architektur Bei einer zentralen Architektur ist das Datenbanksystem auf einem zentralen Rechner installiert, an den eine Vielzahl von Terminals angeschlossen ist. Terminal 1 Terminal 2 Terminal n Ergebnis Ergebnis Ergebnis Anwendung 1 Anwendung 2 Anwendung 3 Daten-Tabelle Daten-Tabelle Daten-Tabelle DBMS Zentralrechner mit Multi-User-Betriebssystem Verteilte Datenbanken Bei grossen Datenbanksystemen, die im Multi-User-Betrieb mit vielen Benutzern laufen, tritt das Problem langer Antwortzeiten auf. Um den Datenzugriff zu beschleunigen, werden die Tabellen des Datenbanksystems auf verschiedene Rechner aufgeteilt. Man spricht dann von einer verteilten Datenbank. Für den Anwender wie auch für den Entwickler des Datenbanksystems ist es nicht von Bedeutung, wie auf der internen Ebene die Speicherung und der Zugriff organisiert werden. Die Entwicklung und Anwendung einer Datenbank, ist unabhängig vom Rechner- und vom Betriebssystem. www.babe-informatik.ch Seite 6/32 Bernhard Bausch Schulungsunterlagen Datenbanken 1.3.2 Netzwerkarchitektur In Netzwerken übernimmt ein Server bestimmte Datenbankfunktionen. Der Server arbeitet entweder als File-Server oder als Client-Server, auch SQL-Server genannt. Die Daten werden auf dem Server vorgehalten. File-Server In einem File-Server-System werden bei der Durchführung jeder Abfrageanweisung beim Server die benötigten Tabellen angefordert und vollständig an den fragenden Arbeitsplatzrechner übertragen. Das Programm-Modul zur Auswertung der Abfrageanweisung läuft in dem Arbeitsplatzrechner. Aufgrund dieser Vorgehensweise kann das File-Server-System zu langen Wartezeiten führen, wenn mehrere Tabellen mit vielen Datensätzen zu übertragen sind Terminal 1 Terminal 2 Terminal n Ergebnis Ergebnis Ergebnis Anwendung 1 Anwendung 2 Anwendung 3 Daten-Tabelle Daten-Tabelle Daten-Tabelle Server Daten-Tabelle Daten-Tabelle Daten-Tabelle DBMS Client-Server Beim Client-Server-System laufen auf dem Server (Backend) auch die Datenbankdienste. An den Arbeitsplatzrechner (Frontend) wird nur noch das Ergebnis der Abfrage übertragen. Damit wird der Nachteil langer Wartezeiten vermieden. Terminal 1 Terminal 2 Terminal n Ergebnis Ergebnis Ergebnis Anwendung 1 Anwendung 2 Anwendung 3 Daten-Tabelle Daten-Tabelle Daten-Tabelle Clients Server DBMS www.babe-informatik.ch Seite 7/32 Bernhard Bausch Schulungsunterlagen Datenbanken 1.4 Struktur und Eigenschaften von Tabellen 1.4.1 Aufbau einer Tabelle (auch Relation genannt). Eine Relation ist eine logisch zusammenhängende Einheit von Informationen. Sie besteht aus einer festen Anzahl von Attributen und einer variablen Anzahl Tupel. Die Anzahl der Attribute einer Relation wird als Degree bezeichnet. Beim relationalen Datenmodell werden die Daten in zweidimensionalen Tabellen angeordnet. Pe_ID 1 2 3 Pe_Name Eifer Meyer Strom Personendat Pe_Vorname Pe_Geschl Heinz m Michael m Claudia w Pe_Eintritt 01.04.82 01.05.93 01.10.89 Ab_ID 4 4 1 Abteilung Ab_Bez Direktion Verwaltung Lager Transport Ab_ID 1 2 3 4 Begriffe, die im Zusammenhang mit Tabellen relevant sind: Relation Domain Tabelle Domäne Attribut Degree Tuple Spalte Ausdehnungsgrad Datensatz, Rekord Personendat, Abteilung Wertebereich eines Attributs oder alle gespeicherten Daten innerhalb eines Attributs. Pe_ID, Pe_Name, Pe_Vorname, Pe_Geschlecht usw. Tabelle Personendat = Degree 6. Variable Anzahl Zeilen einer Tabelle. 1.4.2 Spaltenbedingungen NOT NULL Damit wird sichergestellt, dass in dieser Spalte stets Werte eingegeben werden müssen. Im Zusammenhang mit Tabellen bedeutet NULL = leeres Feld UNIQUE-Index Die Werte der bezeichneten Spalte müssen immer eindeutig sein. Weitere Spaltenbedingungen sind: Standardwerte für neue Records definieren, Gültigkeitsregeln definieren, Eingabeformat bestimmen. 1.4.3 Datentypen Datentypen charakterisieren eine Spalte grundsätzlich als Zeichen-, Zahlen- oder Datumsspalte, wobei bei einer Zahlenspalte unterschieden wird zwischen Ganzzahl und Dezimalzahl. Alle Datenwerte einer Spalte müssen denselben Datentyp haben. Datentypen können in 4 Klassen unterteilt werden: numerische Datentypen alphanumerische Datentypen Datentypen für Datums- und/oder Zeitangaben abgeleitete Datentypen www.babe-informatik.ch Seite 8/32 Bernhard Bausch Schulungsunterlagen Datenbanken Numerische Datentypen Numerische Datentypen ermöglichen die Darstellung von Zahlen. Datentyp Beschreibung Int Beschreibt ganzzahlige numerische Werte, die in vier Byte gespeichert werden können. Int ist die verkürzte Schreibweise für Integer smallint Beschreibt ganzzahlige numerische Werte, die in zwei Byte gespeichert werden können und deswegen zwischen –32768 und 32767 liegen. tinyint Beschreibt ganzzahlige, positive numerische Werte, die in einem Byte gespeichert werden können. Werte liegen zwischen 0 und 255 decimal(p,[q]) Beschreibt Festpunktzahlen. Die Angabe p kennzeichnet die Anzahl aller Ziffern und q die Anzahl der Ziffern hinter dem Dezimalkomma. Dezimal-Werte werden, abhängig von der Angabe p, in 2 bis einschliesslich 17 Byte gespeichert Alphanumerische Datentypen Der alphanumerische Datentyp ermöglicht das Darstellen von Zeichenketten, wobei alle möglichen Zeichen innerhalb der Zeichenkette auftreten können. Datentyp Beschreibung Char[(n)] Beschreibt eine Zeichenkette, wobei n die Anzahl der Zeichen innerhalb der Zeichenkette angibt. Der Wert von n kann maximal 8000 betragen. Character(n) ist eine zusätzliche, gleichwertige Schreibweise für char(n). Falls n ausgelassen wird, beträgt die Länge der Zeichenkette 1. varchar[(n)] Beschreibt eine Zeichenkette variabler Länge (0<n<8000). Dieser Datentyp unterscheidet sich vom Datentyp char dadurch, dass die Varchar-Werte genau in ihrer tatsächlichen Länge gespeichert werden. text[(n)] Definiert eine Textdatei bis zu 2 Gigabyte Länge. Datums- und Zeitangaben Der Datentyp Datum wird grundsätzlich als Date bezeichnet und ist von Datenbank zu Datenbank unterschiedlicher als die anderen Datentypen. Der SQL-Server als Beispiel unterstützt folgende Datums- und Zeitangaben: Datentyp Beschreibung datetime Beschreibt eine Datums- und Zeitangabe, die als Ganzzahlen in je vier Byte gespeichert sind. smalldatetime Beschreibt eine Datums- und Zeitangabe, die als Ganzzahlen in je zwei Byte gespeichert sind. Die beiden Datentypen datetime bzw. smalldatetime sind als numerische Werte gespeichert, die in vier bzw. zwei Byte Teilfeldern gespeichert sind. Das Anfangsdatum für den Datentyp datetime ist 01.01.1753 (01.01.1900 für smalldatetime) und das Enddatum ist 3.12.9999 (6.6.2079 für smalldatetime). Der Zeitteil ist als die Anzahl von 3/100 Sekunden bei datetime bzw. von Minuten bei smalldatetime seit Mitternacht dargestellt und ist in dem zweiten Teilfeld mit vier bzw. zwei Bytelänge gespeichert. Abgeleitete Datentypen Abgeleitete Datentypen sind sogenannte benutzerdefinierte Datentypen und werden von einfachen Datentypen abgeleitet. www.babe-informatik.ch Seite 9/32 Bernhard Bausch 2 Schulungsunterlagen Datenbanken Analyse und Design von Software-Systeme 2.1 Software-Systeme Unter Softwaresystem verstehen wir ein automatisiertes System, das vom Menschen hergestellt wird und mit einem oder mehreren Computern interagiert oder von einem oder mehreren Computer kontrolliert wird. 2.1.1 Online-Systeme Ein Online-System empfängt Input-Daten vom Ort ihrer Entstehung und die Resultate von Berechnungen und anderen Verarbeitungen werden an die Nachfrager abgegeben. Online-Systeme interagieren direkt mit Menschen, die eine bestimmte Aufgabe ausführen. Online-Systeme stellen die Daten so bereit, dass darauf sehr schnell zugegriffen werden kann und keine unnötigen Wartezeiten entstehen. Bereits bei der Analyse und Design einer Applikation ist diesem Umstand gebührend Rechnung zu tragen. Online-Systeme verarbeiten sogenannte Transaktionen und unterstützen damit die Abwicklung des täglichen Geschäfts eines Unternehmens. Typische Online-Systeme sind Reservations-Systeme für Hotels, Airlines usw. oder auch moderne Kassensysteme. 2.1.2 Batch-Systeme Ein Batch-System führt eine Verarbeitung nicht online durch, sondern "im Hintergrund". Es ist keine direkte Interaktion mit Menschen während der Laufzeit der Programme vorgesehen, deshalb ist die Verarbeitungsgeschwindigkeit auch nicht von zentraler Bedeutung. Beispiele von Batch-Systeme sind Programme zur Erzeugung und Versand der Monatsfakturen für Strombezug eines Elektrizitätswerkes oder der zentrale Backup eines Rechenzentrums 2.1.3 Realtime-Systeme Der Unterschied zwischen Online- und Realtim-Systemen ist minimal, indem ein Realtim-System neben der Eigenschaften der Online-Systeme noch den Aspekt der Kontrolle der Umgebung beinhaltet. Ein Realtim-System empfängt Daten aus der Umgebung und steuert durch die Verarbeitung dieser Daten eben diese Umgebung. Ein Realtim-System interagiert daher typischerweise sowohl mit Menschen als auch mit Maschinen. Beispiele sind Liftsteuerungen, die Kontrolle eines AKW's oder das Steuerprogramm eines Bankomaten. 2.1.4 DecisionSupport-Systeme DecisionSupport-Systeme verarbeiten in der Regel keine Transaktionen, sondern werten einen gegebenen Datenbestand auf bestimmte Fragestellungen hin aus. Damit unterstützen sie die Entscheidungsfindung in einer Unternehmung. Tabellenkalkulationsprogramme sind typische Vertreter dieser Systemkategorie 2.1.5 Knowledgebased-Systeme Wissensbasierte Systeme, auch Expertensysteme genannt, kennen eine Vielzahl von Fakten und Regeln. Auf Grund dieser Kenntnisse können Expertensysteme automatisch Schlüsse auf Grund eingegebener Informationen ziehen, indem sie auf Fakten und Regeln zurückgreifen. Automatische Diagnosesysteme für Autos oder Flugzeuge sind Beispiele solcher wissensbasierter Systeme. 2.1.6 Kategorisierung in der Praxis Die meisten Software-Systeme lassen sich nicht ohne Weiteres genau einer der hier beschriebenen Kategorien zuordnen. Vielmehr enthält jedes System Aspekte der einzelnen Kategorien, meist überwiegen aber die Eigenschaften einer der genannten Kategorien. www.babe-informatik.ch Seite 10/32 Bernhard Bausch Schulungsunterlagen Datenbanken 2.2 Wer sind die Mitspieler bei Analyse und Design von Softwaresysteme Bei der Analyse und beim Design von Software-Systemen treffen Analytiker auf eine Vielzahl von Personen, die alle unterschiedliche Voraussetzungen mitbringen und auch unterschiedliche Ziele verfolgen. Da Entwicklung von Software vor allem anderen einmal Kommunikation bedeutet, muss man sich dieser Vielfalt bewusst sein. In allen Phasen muss der erfolgreiche Analytiker in der Lage sein, mit seinen Mitspielern zu kommunizieren und so zu den notwendigen Informationen zu kommen. Typische Projektteilnehmer sind: Analytiker Applikationsentwickler Projektleiter Management User Operatingpersonal Qualitätssicherungsstelle Security Gesetzgeber 2.3 Projektverfahren oder Vorgehensweise 2.3.1 Bottom-up-Verfahren Beim Bottom-up-Verfahren ist ein spezielles Problem der Ausgangspunkt für die Datenbankentwicklung. Dabei werden die im Unternehmen bereits eingesetzten Belege und Dateien untersucht und daraus wird abgeleitet, welche Informationen das Datenbanksystem liefern soll. Bei einer kleinen Anwendung mag dieses Verfahren hinreichend sein. In Unternehmen, in denen eine Vielzahl von Anforderungen an die Datenbank gestellt werden, kann diese Entwurfsmethode zu einer Vielzahl von Datenbanken führen, die nicht aufeinander abgestimmt sind. Es besteht die Gefahr, dass Daten in verschiedenen Tabellen redundant, also mehrfach geführt werden. 2.3.2 Top-down-Verfahren Beim Top-down-Verfahren bestimmt nicht die einzelne Anwendung, sondern die Informationsanforderung aller späteren Datenbankbenutzer die Entwicklung des Datenmodells. Für alle Datenbankanwender gibt es nur eine Datenbank. 2.4 Der Projekt-Lebenszyklus In der Theorie finden sich sehr viele unterschiedliche Modelle des Projekt-Lebenszyklus. Allen ist gemeinsam, dass sie verschiedene Schritte in einer bestimmten Reihenfolge vorsehen. Nach jedem Schritt wird zudem meist ein sogenanntes "Deliverable" vereinbart, womit zwischen Analytiker und Auftraggeber festgelegt wird, welche Dokumente, Programm-Teile oder anderes Abzulieferndes, als Resultat einer bestimmten Phase vorliegen müssen. Eine strukturierte Projekt-Vorgehensmethode soll zuerst einmal das Risiko eines Projektversagens minimieren. Beinahe ebenso wichtig ist aber die fortlaufende Dokumentation des Projektfortschrittes und die Nachvollziehbarkeit der gefällten Entscheidungen. Schliesslich ist auch die Standardisierung der verwendeten Methode in grösseren Unternehmen sehr wichtig. Nach jeder Phase lassen sogenannte Checkpoints einen Projektabbruch durch das Management zu. In diesem Kurs beschreiben wir den Projekt-Lebenszyklus nach dem traditionellen WasserfallModell. www.babe-informatik.ch Seite 11/32 Bernhard Bausch Schulungsunterlagen Datenbanken 2.4.1 Das Wasserfallmodell Bevor man in die erste Projektphase eintritt, braucht es ein umfassendes Konzept, worin die einzelnen Phasen detailliert beschrieben werden, damit alle Beteiligten wissen, was von ihnen erwartet wird und was sie selber erwarten dürfen. Die einzelnen Projektphasen im Wasserfallmodel sehen wie folgt aus: Systemumgebung Softwareumgebung Analyse Programm-Design Programmierung Test-Phase Produktion Phase 1: Definieren der Systemumgebung und Auswahl der Fachkräfte In der ersten Phase werden die Bedürfnisse für das ganze Software-System als Gesamtes definiert. Weiter wird sowohl die Hardware wie auch die zu verwendende Software, die notwendigen Personen und die Vorgehensweise definiert. Die wichtigsten Entscheide in dieser Phase sind, wer macht was mit welchen Mitteln. Die zu verwendende Software und Arbeitsmethode muss mit den Fachleuten, die die Arbeit ausführen, abgestimmt werden. Ressourcen in Form von Fach-Knowhow sollen optimal eingesetzt werden. Phase 2: Softwareumgebung definieren und Vorgehen konzeptionell festlegen In dieser Phase sitzen die Fachleute und Auftraggeber zusammen und legen fest, was das fertiggestellte System können soll und wie die Arbeit auszuführen ist. Anforderungen an die Software werden detailliert beschrieben. Es werden Konventionen festgelegt, wie gearbeitet wird, damit alle am gleichen Strick ziehen. Für die folgenden Phasen werden nötigenfalls entsprechende Konzepte erstellt. Phase 3: Analyse und Datenbank-Design In dieser Phase wird der Analytiker mit vielen Interviews mit möglichst allen Mitspielern versuchen, das zukünftige System so genau wie möglich zu beschreiben. Er verwendet Werkzeuge und Techniken, welche zum Ziel haben, die Kommunikation zwischen ihm und seinen Partnern zu vereinfachen. Diagramme und Techniken, zusammen mit dem Vorgehensmodel, werden nach den vorausbestimmten Methoden realisiert. In dieser Phase muss von allen Mitwirkenden so viel Zeit und Sorgfalt wie möglich investiert werden, damit Missverständnisse und Unklarheiten vollständig eliminiert werden können. Die Analyse als Gesamtes ist der wichtigste Teil des ganzen Projektes. Ein Programm kann nur so gut sein, wie es die Datenbank selber ist und die Datenbank ist das Produkt, das aus der Analyse hervorgeht. www.babe-informatik.ch Seite 12/32 Bernhard Bausch Schulungsunterlagen Datenbanken Phase 4: Programm-Design Nachdem die Analyse abgeschlossen ist, geht es nun darum, wie sich die zu entwickelnde Software präsentieren soll. Es geht um das Layout von Bildschirmmasken und Listen. Ebenfalls wird die Abfolge der einzelnen Masken zu diesem Zeitpunkt festgelegt. Phase 5: Programmierung Die in den früheren Phasen festgelegte Architektur, wird nun in Programmcode gegossen. Ab dieser Phase sind die Programmierer gefordert. Je genauer und detaillierter die vorhergehenden Phasen abgelaufen sind, desto effizienter wird der Programmierer jetzt arbeiten können. Phase 6: Test-Phase Die Test-Phase soll ein zuverlässiges Funktionieren des neuen Systems sichern. Die Tests müssen seriös und genau durchgeführt werden. Aus dem hohlen Bauch heraus testen ist nicht gefragt. Auch hier muss konzeptionell vorgegangen werden. Ein Konzept für die Testphase sollte bereits aus der zweiten Phase hervorgehen. Phase7: Übergabe des Produkts an das produktive System Das realisierte, auf Herz und Nieren getestete System, geht nun in die Produktion. Die Anwender werden auf die neue Software vorbereitet und arbeiten nun damit im täglichen Betrieb. Zweifellos werden Fehler auftauchen, die umgehend ausgemerzt werden. Im Laufe des Betriebs werden immer wieder Erweiterungen oder Ergänzungen des Systems notwendig werden. Diese werden wieder nach demselben Vorgehensmodell als eigentliche Projekte realisiert. 2.4.2 Die unterschiedlichen Analyse- und Designmethoden In der Literatur findet man eine Vielfalt an unterschiedlichen Methoden. Allen gemeinsam ist jedoch das Ziel, das Risiko der Software-Entwicklung soweit möglich zu minimieren und ein strukturiertes, standardisiertes Vorgehen bei Analyse und beim Design bereitzustellen. Die meisten der verwendeten Methoden setzen auf einfach grafische Symbole zur Visualisierung von Zusammenhängen und wollen so die Kommunikation zwischen Software-Fachleuten und Anwendern unterstützen. 3 Das essentielle Modell in der Analyse Das essentielle Modell beschreibt, was das neue System tun soll, um die Benutzerbedürfnisse zu befriedigen. Es heisst essentiell im Gegensatz zum Implementationsmodell, weil es sich überhaupt nicht - oder allenfalls höchstens am Rande – um Realisierungsaspekte kümmert. Es ist, als würde es auf einem fehlerfreien Computer mit unendlicher Geschwindigkeit und unendlichen Ressourcen laufen. Die wichtigsten Regeln sind: - Datenspeicher braucht es nur dann, wenn zeitlich verschobene Prozesse dieselben Daten benötigen. - Prozesse tragen keinen Namen wie "XYZ Statistiksystem", sondern drücken aus, was genau gemacht wird, zum Beispiel: "Regressionsgerade berechnen und darstellen" - Es sind keine Fehlerprüf-Prozesse im Innern des Systems vorzusehen, nur am Rand, wo menschliche Terminatoren Input liefern. 3.1 Das Umgebungsmodell Das Umgebungsmodell beschreibt den Rand des Systems, die Schnittstellen. Sie als Analytiker identifizieren die Terminatoren, den Input, den diese Terminatoren liefern und was für einen Output sie vom System erhalten. Konkret zeichnen sie ein Kontextdiagramm und anschliessend wird eine Event-Liste erstellt. 3.1.1 Kontextdiagramm Das Kontextdiagramm ist ein Diagramm, in welchem das gesamte System einen einzigen Prozess darstellt. www.babe-informatik.ch Seite 13/32 Bernhard Bausch Schulungsunterlagen Datenbanken Druckereien ng llu ste e Be und K Dr uc er kau te ft ile r a n g Kunden Re Lie chnu fer sch ng ein ng i s n feru Lie rzeug e k c Dru P1 Buchbestellsystem Ko n to abr s al do s u fe n en ng n nu ite ch rbe Re ea b te rich e b ts na ern Mo lief Management Buchhaltung Das Kontextdiagramm definiert die Schnittstellen, die den Rand des Systems betreffen. Buchhaltung und die anderen Terminatoren sind selbst eigenständige Systeme mit einem Eigenleben. Dieses Eigenleben der anderen Systeme interessiert uns nicht. Wir definieren hingegen, welche Daten das System Buchhaltung vom untersuchten System erhalten soll und welche Daten die Buchhaltung an unser System liefern soll. Zwischen Terminatoren kann es keine direkten Datenflüsse geben. Ein Terminator erzeugt normalerweise viele verschiedene Input- und Outputdaten. Um das Diagramm trotzdem übersichtlich zu halten, darf man einen Terminator mehrmals zeichnen oder man wählt für die Datenflusspfeile sehr allgemeine Bezeichnungen wie "Suchdialog" und zeichnet Doppelpfeile. Häufig ist es schwierig einen Terminator zu bezeichnen. Ob bei einer Bestellung der Terminator "Kunde" oder "Einkauf" heisst ist nicht wesentlich. Es gibt keine festen Regeln. 3.1.2 Die Event-Liste Stellen Sie sich das System als ein schlafendes Wesen vor, das auf Ereignisse wartet. Es beginnt nur zu arbeiten, wenn es durch einen Terminator angestossen wird (Ausnahme bilden zeitgesteuerte und Steuerungs-Events). Die Event-Liste muss sämtliche Events enthalten, die überhaupt vorkommen können. Jeder Input-Pfeil im Kontextdiagramm ist entweder ein Event oder ein Input, den ein Event verlangt. Die Events stossen das System an. Ohne Events schläft das System, es finden keine Ereignisse statt. Events werden wie folgt formuliert: <Terminator> <aktives Verb> <Objekt> Also im Stil: "Buchhalter berechnet Saldoliste", "Kunde bestellt Buch". Events werden nummeriert und entsprechend geordnet. www.babe-informatik.ch Seite 14/32 Bernhard Bausch Schulungsunterlagen Datenbanken 3.2 Datenfluss-Diagramme (DFD) 3.2.1 Modelle In der Analysephase eines Projektes wird ein Modell des zukünftigen Softwaresystems gebaut. Modelle können in vielen unterschiedlichen Erscheinungsformen daherkommen, z.B. als textliche Erklärung oder als graphische Darstellung. Graphische Darstellungen eignen sich am besten als Hilfsmittel in der Analyse. Jede Analysemethode verwendet denn auch ihre eigenen Symbole und Diagramme. Die graphischen Darstellungen werden durch textliche Erläuterungen verfeinert. Es gibt moderne Werkzeuge für die Erstellung der Diagramme, die für die Kommunikation mit den Anwendern ideal sind. 3.2.2 Die Unterschiedlichen Ebenen im Modell Ein EDV-System einer bestimmten Grösse ist eine sehr komplexe Angelegenheit und lässt sich nicht auf einem einzigen Blatt Papier darstellen, es sei denn, man verwendet Papiere des Formates A0. Jede Analysemethode bricht ein EDV-System deshalb in einzelne Teile – meist Module genannt – auf. So wird jeder Teil für sich überschaubar. Die einzelnen Module wiederum werden hierarchisch dargestellt. 3.2.3 Das Datenfluss-Diagramm Modell Ein Datenfluss-Diagramm stellt ein System als Netzwerk von Prozessen dar. Die Prozesse sind untereinander durch Datenleitungen verbunden und verfügen über Speicher für die verwendeten Daten. Zudem werden die mit dem System arbeitenden externen Instanzen dargestellt. DFD's bestehen aus folgenden Komponenten: Prozesse Process Datenflüsse Dataflow Datenspeicher Datastore Externe Instanzen External Komponente des System das Input in Output transformiert. Der Prozess ist das Ereignis selber. Fluss von Daten von einer Komponente des Systems zur nächsten. Daten, die dauerhaft gespeichert werden. Externe Instanzen, mit welcher das System zusammenarbeitet bzw. von welchen das System angestossen wird. 3.2.4 Die Symbole der Komponenten Datenflusssymbole, wie sie in diesem Kurs verwendet werden. Prozesse Der Prozess stellt ein Ereignis dar, welches aus der EventListe hervorgeht. Jedes Ereignis wird eindeutig bezeichnet, damit im Gesamtprojekt die Zusammenhänge ersichtlich sind. Ein Prozess hat kein "Eigenleben" und muss von einer anderen Instanz angestossen werden. P1.1.3 Neuer Kunde aufnehmen Datenflüsse Datenflüsse können in beide Richtungen laufen Kunde und gehen immer vom Prozess aus. erfassen Läuft der Datenfluss vom Prozess auf einen Datastore, dann werden Daten immer gespeichert bzw. geändert. Läuft der Datenfluss vom Datatstore auf den Prozess zu, dann werden Daten in den Prozess zur Information oder Auswertung eingelesen. www.babe-informatik.ch Seite 15/32 Bernhard Bausch Schulungsunterlagen Datenbanken Datenspeicher Ein Datenspeicher ist ein Teil der Datenbank. In der Regel handelt es sich um eine Tabelle, welche vom Prozess angesprochen wird. Kunde D5 Externe Instanzen Die externe Instanz ist der Teil, der den Prozess zur Aktion zwingt. Die externe Instanz ist verknüpft mit dem Geschäftsvorfall. Ein Kunde der eine Bestellung aufgibt. Ein Schüler der sich anmeldet. Ein Datum das zum aufbereiten der Rechnungen zwingt. Kunde Beispiel: Event (x) Lehrer erhält Kursauftrag P1.1.0 Kursauftrag erteilen Lehrerdaten Sekretariat D5 Teilnehmerliste D3 Kursteilnehmer um ra ng rs gu Ku ele b ag ftr en u A teil er Kurse D2 Ku In rsfo Ku r se sau nd ftra e g Ku n r be sa st uft ät ra ig g en Kursdaten für Auftrag Lehrer Bestätigung Lehrer Kursinfo D1 D4 Kursräume Personal 3.2.5 Erweiterte Diagrammtechniken Datenflüsse ohne Bezeichnung Wenn ein Datenfluss in einen Datenspeicher führt oder aus einem Datenspeicher kommt, so brauchen Sie den Pfeil nicht unbedingt zu beschriften, wenn der Datenfluss eindeutig ist. Es wird implizit angenommen, dass Informationen aus einem oder mehreren Exemplaren der im Speicher abgelegten Datensätze gemeint sind. Wenn es sich beispielsweise um Adressen handelt, so kann ein unbeschrifteter Pfeil bedeuten: - Eine einzige vollständige Adresse - Mehrere vollständige Adressen - Name, Vorname und Ort einer einzigen Adresse - Name, Vorname und Ort mehrerer Adressen Ein aus einem Datenspeicher führender Pfeil steht immer für "Lesen", entspricht also beispielsweise einem SELECT-Befehl. Ein in den Speicher führender Pfeil steht für eine Mutation. Ob es sich um Einfügen, Ändern oder Löschen handelt, geht aus dem Pfeil nicht hervor, auch nicht aus der Definition des Pfeils, sondern aus der Prozessspezifikation. www.babe-informatik.ch Seite 16/32 Bernhard Bausch Schulungsunterlagen Datenbanken Externe Datenspeicher Prozess P3 D3 Daten Textdatei für externen Speicher Hier werden vom Prozess P3 aufgearbeitete Daten in eine Textdatei abgelegt, die später in einem anderen System (das nicht Teil des betrachteten Systems ist) verarbeitet werden. Dieser Prozess sendet Daten in einen externen Speicher. Dieses Beispiel stellt eine Schnittstelle dar, die über Textdateien kommuniziert. Diese Art von Schnittstellen ist allgemein üblich, so kann man mit den unterschiedlichsten Systemen kommunizieren. Dialoge Manchmal ist es übersichtlicher, statt zwei getrennte Pfeile in Gegenrichtung einen einzigen Pfeil mit zwei Spitzen zu Zeichnen: Solch Pfeile werden mit xxx-Dialog bezeichnet. Übungen: Kontextdiagramm Schule erstellen Eventliste Schulbetrieb erstellen Einzelne Events nachzeichnen Beispiel: DVD Verleihung von Gegenständen Test: DVD gemäss Event-Liste erstellen www.babe-informatik.ch Seite 17/32 Bernhard Bausch 4 Schulungsunterlagen Datenbanken Entity Relationship Diagramm (ERD) Ein Entity-Relationship-Diagramm (kurz ERD) zeigt die gespeicherten Daten und deren Zusammenhänge eines EDV-Systems auf einer hohen Abstraktionsebene. Dank einem ERD können sowohl Anwender, welche wenig EDV-Erfahrung besitzen, als auch Entwickler und EDVSpezialisten miteinander über ein neues System kommunizieren. Zudem ist das ERD die Basis für die Entwicklung der Datenbank und die Dokumentation des Systems Früher diente ein ERD zur rein graphischer Darstellung von Datenbankstrukturen. Damals war das ERD fester Bestandteil des essentiellen Modells. Nach Abschluss des ERD's und somit Abschluss des essentiellen Modells, startetet das Implementationsmodell, in welchem als erstes die Datenbank gemäss diesem Modell manuell mit SQL-Befehlen aufgebaut wurde. Moderne Case-Tools automatisieren nun den Aufbau der Datenbank aufgrund der definierten Vorgaben. Ein gutes ERD-Tool baut eigenständig auf "Knopfdruck" das Datenmodell für die von Ihnen angegebene Datenbank. Durfte man früher keine Fehler beim manuellen erstellen der Datenbank machen, so muss man Heute mit dem ERD entsprechend sorgfältig verfahren. 4.1 Bestandteile eines ERD's ERD-Diagramme bestehen aus unterschiedlichen Objekten: Entitäten Beziehungen zwischen den Entitäten Beschreibungen der Beziehungen Die einzelnen Elemente werden nachfolgend kurz vorgestellt. 4.1.1 Entitäten Eine Entität wurde früher einfach als Rechteck dargestellt, welches den Namen der entsprechenden Relation (Tabelle) enthielt. Heute muss mit der automatisierten Version entsprechend anders verfahren werden. Die Tabellen werden in den Tools mit den entsprechenden Attributen dargestellt. Nur so ist es möglich, dass später die Datenbank mit diesem Modell auch automatisiert aufgebaut werden kann. Wie die einzelnen Tabellen dargestellt werden, bzw. wie sich die Darstellungsform präsentieren wird, können Sie im Tool unter verschiedenen Möglichkeiten auswählen. Für den Kurs verwenden wir für die Darstellung von Tabellen Vierecke, die die Tabellen, die Schlüssel und allenfalls auch die Attribute benennen. Beispiele: ERD Kunde PK FK CK Ku_ID PK Adr_ID UI_ID (Attribute) FK CK = = = www.babe-informatik.ch ERM Kunde Primary-Key Foreign-Key90 Candidate-Key Seite 18/32 Bernhard Bausch Schulungsunterlagen Datenbanken Die Entität steht für eine Menge von gleichartigen Objekten der realen Welt, deren einzelne Elemente (in der Theorie auch Instance oder Element genannt) den folgenden Kriterien genügen: Jedes Element einer Entität kann eindeutig über einen Schlüssel identifiziert werden. Jedes Element einer Entität ist innerhalb des Systems absolut notwendig, weil es dieses Element in dieser Form nur einmal gibt. In einer Entität die Kundendaten enthält, haben Daten von anderen Personen nichts verloren. Jede Entität kann durch eine oder mehrere Datenelemente beschrieben werden. Mehrere beschreibbare Datenelemente (Attribute) sind denkbar. 4.1.2 Beziehungen zwischen den Entitäten Entitäten können durch Beziehungen untereinander verknüpft sein. Im Diagramm wird die Beziehung durch eine Linie, welche die beiden Entitäten verbindet, angezeigt. Eine Beziehung wird durch einen Text näher erläutert. Kunde Auftrag Ku_ID Au_ID (Attribute) Erteilt Ku_ID FK (Attribute) Selbstverständlich besteht die Beziehung eigentlich nicht zwischen den Entitäten KUNDE und AUFTRAG, sondern zwischen einzelnen Elementen (Schlüssel). Diese Beziehung besagt: Ein Kunde kann KEINEN, EINEN oder MEHRERE Aufträge erteilen. Kunde Meier hat beispielsweise bereits 7 Aufträge erteilt Kunde Hugentobler hat erst 2 Aufträge laufen Kunde Miller wurde gerade erst erfasst und hat noch keinen Auftrag Die Beschreibung der Beziehung besteht aus zwei Elementen: 1. Verbale Beschreibung, z.B. "arbeitet in", "hat bestellt". Die Beziehung wird immer aus beiden Richtungen angesehen. Auf dem Diagramm findet jedoch nur eine Sicht Platz. 2. Symbolische Beschreibung des Beziehungstyps. Die Darstellungsform kann unterschiedlich sein. Die Beziehungen können von unterschiedlicher Art sein. Beziehungstyp 1 c m mc www.babe-informatik.ch Anzahl Elemente Genau ein Element Kein oder genau ein Element Mindestens ein Element oder beliebig viele Kein, eines oder beliebig viele Elemente Symbol Seite 19/32 Bernhard Bausch Schulungsunterlagen Datenbanken Übungsbeispiele: Linker Schuh Rechter Schuh Mitarbeiter Abteilung Ehepaar Kind Person Partei Klasse Schüler Auto Unfall Beispiel eines ERM 1 Kunde Artikel mc Auftrag www.babe-informatik.ch 1 mc 1 mc Bestellung Seite 20/32 Bernhard Bausch Schulungsunterlagen Datenbanken 4.2 Beispiel eines Entity Relationship Diagrammes In einem ERD werden nicht nur Beziehungen erstellt. Die ganze Tabelle wird mit Schlüssel und Datentypen definiert und am Schluss des Datendesigns wird daraus die Datenbank erstellt. Das ermöglichen uns Heute die modernen Tools. Notation eines ERD's wie, wie wir sie in diesem Kurs verwenden: Kunde Artikel Ku_ID Art_ID (Attribute) (Attribute) bestellt mit Erteilt Auftrag Bestellung Au_ID Be_ID Ku_ID FK (Attribute) umfasst Au_ID Art_ID (Attribute) In einer anderen Notation präsentiert sich das gleiche Diagramm so: Kunde Artikel Ku_ID Art_ID (Attribute) (Attribute) bestellt mit Erteilt Auftrag Bestellung Au_ID Be_ID Ku_ID FK (Attribute) umfasst Au_ID Art_ID (Attribute) Die unterschiedlichen Darstellungen des ERD's sind absolut gleichwertig. Es gibt verschiedene Formen von Notationen. Für welche Form Sie sich beim einzelnen Projekt entscheiden, hängt in erster Linie von Ihren persönlichen Präferenzen oder von denjenigen Ihres Auftraggebers ab. Ziel des ERD's ist es ja gerade, die Kommunikation zwischen Analytiker und Auftraggeber zu vereinfachen. Die meisten CASE-Tools lassen denn auch unterschiedliche Varianten zu, so dass auch ein Wechsel der Darstellungsform ohne Aufwand zu realisieren ist. www.babe-informatik.ch Seite 21/32 Bernhard Bausch 5 Schulungsunterlagen Datenbanken Auflösen von nicht-hierarchischen Beziehungen Artikel und Lieferant: Arikel liefert Lieferant Die obige Beziehung besagt, dass ein Artikel von mehreren Lieferanten geliefert werden kann, andererseits aber auch jeder Lieferant mehrere Artikel liefern kann. Auto und Fahrer Auto fährt Fahrer Diese Beziehung bedeutet einerseits, dass jedes Auto von einem oder mehreren Fahrern gefahren werden kann (natürlich nicht gleichzeitig) und dass andererseits auch jeder Fahrer mehrere Fahrzeuge fahren kann. Projekt Mitarbeiter Projekt bearbeitet Mitarbeiter In diesem Beispiel kann jeder Mitarbeiter an einem oder mehreren Projekten mitarbeiten und jedes Projekt kann einen oder mehrere Mitarbeiter beschäftigen. Die drei vorgestellten Beispiele lassen sich so in einer relationalen Datenbank nicht abbilden. Für Datenbanksysteme müssen Beziehungen hierarchisch sein, d.h. auf mindestens einer Seite der Beziehung muss eine "1" oder ein "c" stehen. Gültige Beziehungen sind demnach: Kanton und Auto Kanton ist zugelassen ihn Auto Hier legen wir fest, dass in jedem Kanton ein Auto oder mehrere Autos zugelassen werden können, dass aber jedes Auto in genau einem Kanton zugelassen sein muss. Mitarbeiter und Büro Büro arbeiten in Mitarbeiter In einem Büro können mehrere Mitarbeiter arbeiten aber jeder Mitarbeiter sitzt in genau einem Büro. www.babe-informatik.ch Seite 22/32 Bernhard Bausch Schulungsunterlagen Datenbanken Am Beispiel der Beziehung zwischen PROJEKT und MITARBEITER soll das Vorgehen der Auflösung dieser nicht-hierarchischen Beziehung aufgezeigt werden. Die ursprüngliche Beziehung war so definiert: Projekt bearbeitet Mitarbeiter Diese nicht-hierarchische Beziehung muss aufgelöst werden. Zu diesem Zweck wird eine zusätzliche Tabelle erstellt. Projekt Mitarbeiter beschäftigt Projektmitarbeit arbeitet an In dieser zwischengeschobenen Tabelle werden die Schlüssel der beiden anderen Tabellen mitgeführt. Übungsbeispiele: Artikel liefert Artikel Auto Auto www.babe-informatik.ch Lieferant Lieferant fährt Fahrer Fahrer Seite 23/32 Bernhard Bausch 6 Schulungsunterlagen Datenbanken Relationale Integritätsregeln Das DBMS garantiert die Entity Integrität und die referenzielle Integrität der Datenbank. Integrität in bezug auf Datenbanken bedeutet, dass die Daten unversehrt sind, also keine widersprüchlichen Daten in ihr gespeichert sind. Für diese Überprüfung verwendet das DBMS die Einträge in den Systemtabellen (Data Dictionary), wo die einzelnen Verknüpfungen aufgrund des Datenmodels definiert wurden. Ein DBMS kann nicht wissen, ob die Lieferantennummer 2 in der Relation ARTIKEL für die Artikelnummer 22 richtig ist. Es kann aber garantieren, dass der Lieferant Nr. 2 von Artikel Nr. 22 in der Tabelle LIEFERANTEN auch existiert. Die Identifizierung der einzelnen Tupeln, wird über die Key's (Primary-, Foreign-Key) gesteuert. 6.1 Entity Integrität Es dürfen keine doppelten Nullwerte in einem Hauptschlüssel (Primarykey) gespeichert werden. Definition Wenn ein Attribut die Komponente eines Primary-Key ist, dann darf dieses Attribut zu keinem Zeitpunkt einen NULL-Wert enthalten Mit der Entity-Integrität wird - neben der Sicherstellung der Eindeutigkeit über den Index gewährleistet, dass jedes Tupel (Datensatz) in einer Relation über einen Schlüssel eindeutigen identifizierbar ist. 6.2 Referenzielle Integrität Definition Eine Relation (R2) besitzt einen Foreign-Key, der auf einen Primary-Key in einer Relation (R1) verweist. Es muss jeder Wert eines Foreign-Key in R2 einem Wert eines Primary-Key in R1 entsprechen oder der Wert des Foreign-Key ist ein NULL-Wert. Durch die referenzielle Integrität wird also sicher gestellt, dass z.B. alle Kundennummern in der Relation BESTELLUNG auch in der Relation KUNDEN vorhanden sind. Das DBMS und nicht das Anwendungsprogramm (auch nicht das Maskensystem oder Prüfprogramme, die in regelmässigen Abständen laufen) hat dafür zu sorgen, dass die Integritätsbedingungen zu jeder Zeit erfüllt sind. Dies kann das DBMS durch Ablehnung aller nicht den Integritätsbedingungen entsprechenden Operationen sicherstellen. Neben den referenziellen Integritäts-Bedingungen können natürlich auch noch weitere Bedingungen definiert werden, welche immer eingehalten werden müssen, z.B.: Die Anzahl der Lohnzahlungen pro Jahr und Mitarbeiter darf 13 nicht übersteigen Jeder Mitarbeiter erhält pro Monat einen Lohn www.babe-informatik.ch Seite 24/32 Bernhard Bausch Schulungsunterlagen Datenbanken 6.3 Konsistenz-Bedingungen Eine Datenbank ist konsistent, wenn alle Tabellenverknüpfungen mit Konsistenzbedingungen sauber definiert wurden. Dazu gehört einerseits die Erfüllung der referenziellen Integrität und andererseits existieren zusätzlich definierte Bedingungen auf unterschiedlichen Ebenen. Beispiel: Mitarbeiter erhält Lohnzahlung Es kann kein Mitarbeiter aus dem System gelöscht werden, solange noch von ihm ein Eintrag in der Entität LOHNZAHLUNG vorhanden ist, da sonst die entsprechenden Elemente aus LOHNZAHLUNG keine Beziehungen mehr zur Tabelle MITARBEITER hätten und dann unsichtbar als "Daten-Leichen" weiterhin das System belasten würden. Unsichtbar sind die deshalb, weil sie über keine Verknüpfung mehr ansprechbar sind. Man kann vom System verlangen, dass beim Löschen eines Mitarbeiters auch sämtlich zu ihm gehörigen Lohnzahlungen gelöscht werden. Oder anders rum, der Mitarbeiter kann nur gelöscht werden, wenn auch alle Lohnzahlungen bereits gelöscht sind. Es gibt 3 verschieden Formen von Löschbedingungen. Restricted: Löschen eines Mitarbeiters ist nur erlaubt, falls keine Lohnzahlungen vorhanden sind Cascading: Beim Löschen des Mitarbeiters werden seine Lohnzahlungen automatisch mitgelöscht. Nullify: Beim Löschen eines Mitarbeiters werden die Referenzen in den abhängigen Tabellen gelöscht (auf Null gesetzt). Beim Einfügen eines Elementes in LOHNZAHLUNG gilt automatisch die Bedingung, dass nur Lohnzahlungen erfasst werden können, wenn sie einem Mitarbeiter zugeordnet werden können. Auch bei Änderungen an Tabellen wird sichergestellt, dass die Bedingungen der referentiellen Integrität gewährleistet bleiben. Konsistenzbedingungen können auf unterschiedlichen Ebenen auftreten: Ein Feld betreffend mehrere Felder desselben Datensatzes betreffend mehrere Datensätze einer Tabelle betreffend mehrere Datensätze mehrerer Tabellen betreffend www.babe-informatik.ch Seite 25/32 Bernhard Bausch 7 Schulungsunterlagen Datenbanken Entwickeln von relationalen Datenbanken 7.1 Grundsätze Daten werden seit Anbeginn der automatisierten Datenverarbeitung in Dateien gespeichert. In der Regel sind die Dateien nicht untereinander abgestimmt. So kann es zum Beispiel vorkommen, dass die Personaldaten eines Mitarbeiters in mehreren Dateien gespeichert werden. Abgesehen von dem Mehraufwand an Speicher ist eine solche Doppelspeicherung gleicher Daten mit Risiken der Mutationsanomalien behaftet. 7.1.1 Mutationsanomalie Unter Mutationsanomalie versteht man, dass sich in einem Dateisystem Unregelmässigkeiten einstellen, wenn Daten verändert werden. Wenn beispielsweise das Geburtsdatum eines Mitarbeiters sowohl in der Mitarbeiterstammdatei wie auch in der Lohndatei gespeichert wird, dann kann es passieren, dass bei einer Korrektur eine Änderung unterbleibt. In diesem Fall würde es sich um eine Update-Anomalie handeln. Eine Mutationsanomalie kann auch dann entstehen, wenn Daten auf falschen Tabellen verteilt wurden. Würde man beispielsweise die Telefonnummer eines Angestellten beim Projekt speichern, dann existiert die Telefonnummer nur im Zusammenhang mit Projekten und wird beim löschen eines Projektes verschwinden, was dann eine Delete-Anomalie wäre. Bei einem neuen Angestellten, der in die Datenbank aufgenommen werden soll und noch kein Projekt hat, würde es dann eine Insertion-Anomalie hervorrufen. 7.1.2 Keine Redundanz Jede Angabe zu einer Person oder zu einer Sache, darf nur einmal in der Datenbank gespeichert werden. 7.1.3 Eindeutigkeit Eine Datenbank enthält Angaben zu den Eigenschaften einer Person oder Sache. Mittels dieser Angaben muss eindeutig eine bestimmte Entität identifizierbar sein. Bezogen auf eine Personendatei müssen die Angaben in der Weise beschaffen sein, dass sie nur auf eine ganz bestimmte Person zutreffen können. Das Datenbankverwaltungssystem verfügt nicht über einen definierten Zugriffsweg auf einen bestimmten Datensatz. Deshalb muss in jeder Zeile einer Tabelle ein Wert enthalten sein, der diesen Eintrag eindeutig kennzeichnet. Um die Eindeutigkeit der Tabellenzeilen zu gewährleisten, erweitert man den Datensatz um ein Identifikationsmerkmal. So wird beispielsweise dem Personaldatensatz eine Personalnummer, dem Artikel eine Artikelnummer hinzugefügt. Durch ein solches Identifikationsmerkmal wird die eindeutige Zuordnung zwischen den Daten in der Tabellenzeile und der zu beschreibenden Entität sichergestellt. Dieses Merkmal wird Schlüsselbegriff, Schlüsselattribut oder einfach Schlüssel genannt. Beim Festlegen des Schlüsselbegriffs kann man selber einen Schlüssel definieren, man kann aber auch einen fremddefinierten Schlüssel verwenden. Bei einem Buch ist beispielsweise die ISBN-Nr. ein fremdbestimmter Schlüssel, bei einer Person die AHV-Nummer. Da aber Umstände eintreten können, die zu einer Änderung solcher fremddefinierten Schlüssel führen, die von dem Datenbankverwalter nicht kontrolliert werden können, empfiehlt es sich trotz Mehraufwandes, eigendefinierte Schlüssel zu verwenden. 7.1.4 Schlüssel (Key's) Primary-Key Jede Relation besitzt genau einen Primary-Key (Primärschlüssel), um ein Tupel der Relation eindeutig zu identifizieren. Er wird definiert, indem ein Attribut speziell für diesen Zweck eingeführt wird. Ein Primary-Key darf keine Null-Werte enthalten. Der Primary-Key soll mindestens einen Zugriffspfad garantieren, mit dem exakt ein Tupel angesprochen werden kann. Mit Hilfe dieses Primary-Key werden meist die Verknüpfungen (Joins) der Relationen in der Datenbank hergestellt. www.babe-informatik.ch Seite 26/32 Bernhard Bausch Schulungsunterlagen Datenbanken Foreign-Key Der Foreign-Key (Fremdschlüssel/Bezugsschlüssel) wird so genannt, da seine Wertemenge (Domäne) in einer anderen Relation als Primary-Key definiert ist. Beide Attribute (oder Attributmengen, wenn der Key aus mehr als einem Attribut besteht) müssen zu der gleichen Domäne gehören. Es ist wichtig, dass ein Datenbanksystem weiss, welche Attributmenge den Primary-Key definiert und welche Foreign-Key's existieren. Nur so kann das DMBS die referenzielle Integrität der Datenbank gewährleisten. Candidate-Key Eine Attributmenge wird Candidate-Key (Schlüsselkandidat) genannt, wenn alle Werte dieser Attributmenge unique (eindeutig) sind. Es existieren zu keinem Zeitpunkt zwei Werte eines Candidate-Key's mit gleichem Inhalt. Eine Tabelle kann einen oder mehrere Schlüsselkandidaten aufweisen. Einer dieser Schlüssel wird ausgewählt und als Primärschlüssel bezeichnet. Ein Candidate-Key wird durch die Aufzählung eines oder mehrerer Attributnamen definiert. Er darf, um eindeutig zu sein, keine überflüssigen Attribute beinhalten. Sobald ein Attributname weggenommen wird, darf somit die Eindeutigkeit der Candidate-Key-Werte nicht mehr gegeben sein. Alternate-Key Aus Performancegründen können zusätzlich beliebig viele Key's in einer Relation definiert werden. Diese werden dann Alternate-Key's oder auch Secondary-Key's (Zweitschlüssel) genannt. 7.1.5 Daten- oder Tabellencharakter Entitäten Normalerweise werden Daten erfasst und gespeichert. Es werden Adressen erfasst, Projekte eröffnet, Lohnabrechnungen gemacht usw. All diese Daten haben eines gemeinsam, sie werden laufend erzeugt, geändert oder auch wieder gelöscht. Es sind eigentliche Arbeitsdaten und sie bilden Entitäten aus einzelnen oder mehreren Relationen. Diese Daten unterscheiden sich in 2 Gruppen. Die eine Gruppe sind die Haupt- oder Steuerdaten und die anderen sind Ergänzungen zu diesen Hauptdaten, z.B. Kontaktadressen zu jeder Adresszeile oder erweiterte Informationen wie Mitarbeiterdaten zur Stammadresse. Prozessdaten Prozessdaten sind Daten, die durch einen Rechenprozess gebildet werden. Werden Prozessdaten gespeichert, so besteht die Gefahr, dass diese Daten in kurzer Zeit nicht mehr aktuell sein werden. Das mag folgendes Beispiel zeigen: Wenn bei einer Ersterfassung von einer Person neben dem Geburtsdatum auch das Alter gespeichert würde, dann ist dieser Eintrag nach spätestens einem Jahr falsch. Die Altersangabe ist ein Berechnungswert, der sich aus der Differenz von aktuellem Datum und Geburtsdatum, während einem Prozess, berechnen lässt. Stammdaten oder Wiederholungsdaten Stammdaten sind Daten, die sich nicht verändern oder nur selten. Es sind Daten, auf die während der Erfassung von Daten zugegriffen wird oder die erst in einer Auswertung zum Tragen kommen. Es sind Auswahlfelder die immer die gleiche Auswahl anbieten oder Ansätze die immer wieder verwendet werden, z.B. Abteilung, Mehrwertsteuersätze oder Anzahl Arbeitsstunden pro Tag usw. In einer Stammdaten-Tabelle werden keine Fremdschlüssel vererbt, es sei denn, Stammdaten beeinflussen Stammdaten. In einer Tabelle Lagerplätze kann der Schlüssel der Tabelle Lagerstandorte vererbt werden, um die Lagerplätze eindeutig einem Standort zuzuordnen. Steuertabellen oder Hilfstabellen Eine besondere Form der Tabelle stellt die Hilfstabelle dar, die bei der Normalisierung der Tabellenstruktur zwei oder mehrere Tabellen miteinander über die Hauptschlüssel verbindet. In so einer Tabelle werden Daten nicht eingegeben, sondern automatisch erzeugt. www.babe-informatik.ch Seite 27/32 Bernhard Bausch Schulungsunterlagen Datenbanken 7.2 Datenstruktur - konzeptionelles Datenmodell Die Zusammenstellung der für das Informationssystem erforderlichen Daten wird Informationsstruktur genannt. In dieser Informationsstruktur sind sämtliche Datenfelder mit ihren Bedeutungen aufgelistet, aus denen dann die einzelnen Tabellen entstehen. 7.2.1 Abhängigkeiten von Attributen Die verschiedenen Abhängigkeiten von Attributen werden in Klassen eingeteilt: Funktionale Abhängigkeit Voll funktionale Abhängigkeit Transitive Abhängigkeit Mehrwertige Abhängigkeit Funktionale Abhängigkeit In einer Relation R(A,B) ist das Attribut B von A funktional abhängig, falls zu jedem Wert des Attributs A genau ein Wert des Attributs B gehört. Funktional abhängig sind somit solche Attribute einer Relation, die sich in der realen Welt nicht unabhängig voneinander ändern können, ohne dass sich das davon abhängige Attribut mit ändert. Zum Beispiel sind Gewicht und die Bezeichnung eines Artikels von der Artikelnummer funktional abhängig. Unterschiedliche Gewichte implizieren unterschiedliche Artikelnummern. Die Artikelnummer ist allerdings nicht vom Gewicht des Artikels funktional abhängig, denn unterschiedliche Artikelnummern implizieren nicht unterschiedliche Gewichte. Oder es gibt unterschiedliche Artikelnummern mit gleichen Gewichten, aber es gibt keine unterschiedlichen Gewichte für gleiche Artikelnummern. Wenn ein Attribut B von A funktional abhängig ist, so sagt man auch: A bestimmt B oder A ist Determinante von B. Artikel Art_Nr 10010 10011 10020 10021 Art_Gewicht 1 Kg 5 Kg 1 Kg 5 Kg Art_Bez Zucher Zucker Mehl Mehl Voll funktionale Abhängigkeit In einer Relation R(S1,S2,A) ist das Attribut A von den Attributen (Schlüssel) S1,S2 voll funktional abhängig, wenn A vom zusammengesetzten Schlüssel (S1,S2) funktional abhängig ist, nicht aber von einem einzelnen Schlüsselteil S1 oder S2. www.babe-informatik.ch Seite 28/32 Bernhard Bausch Schulungsunterlagen Datenbanken Voll funktional Abhängig ist zum Beispiel das Attribut Pr_Abz der Relation PROJEKTE von dem zusammengesetzten Schlüssel (Pr_ID, Adr_ID), da Pr_Abz weder von Pr_ID noch von Adr_ID alleine funktionell abhängig ist. In der Praxis kann man in der Relation PROJEKTE die voll funktionale Abhängigkeit daran erkennen, dass: es für verschiedene Pr_Abz logischerweise immer verschiedene Attributkombinationen (Pr_Id,Adr_ID) geben muss, gleiche Pr_ID mit unterschiedlichen Pr_Abz vorkommen und gleiche Adr_ID mit unterschiedlichen Pr_Abz vorkommen. Projekte Pr_ID Projekt Adr_ID Pr_Abz Mitarbeiter Total Arbeitszeit 22 22 12 18 45 23 18 69 133.0 88.4 235.5 33.4 Transitive Abhängigkeit In einer Relation R(S,A,B) ist das Attribut B vom Attribut (Schlüssel) S (der auch ein zusammengesetzter Schlüssel sein kann) transitiv abhängig, wenn A von S funktional abhängig ist, S jedoch nicht von A, und B von A funktional abhängig ist. In folgendem Beispiel ist das Attribut Abteilungsname (Abt_Name) transitiv abhängig vom Attribut Personalnummer (Adr_ID), da die Abteilungsnummer (Abt_Nr) von der Personalnummer abhängig ist, allerdings nicht umgekehrt (Adr_ID ist nicht abhängig von Abt_Nr), und der Abteilungsname von der Abteilungsnummer funktional abhängig ist. Mitarbeiter Adr_ID 22 Adr_Name Adr_Ort Huber Abt_Nr Zürich 1 Abt _Name Chemie Mehrwertige Abhängigkeit In einer Relation R(A,B,C) ist das Attribut C mehrwertig abhängig vom Attribut A, falls zu einem A-Wert, für jede Kombination dieses A-Wertes mit einem B-Wert, eine identische Menge von C-Werten existieren kann. In dieser Relation ist das Attribut Li_ID (C-Wert) vom Attribut Art_Art (A-Wert) mehrwertig abhängig, da für die gleiche Art_Art (z.B. Monitor) in jeder Kombination mit der Art_Bez (B-Wert) die gleich Li_ID erscheint. Diese Konstellation setzt allerdings voraus, dass Art_Art immer vom gleichen Lieferanten geliefert wird. Artikel Art_ID 21 22 23 24 25 26 www.babe-informatik.ch Art_Bez Art_Art (Art_ID) Multisync I Multisync II Herkules HP P6 HP P7 Farb-Laser Monitor Monitor Grafikkarte Drucker Drucker Drucker Li_ID (Lieferant) 1 1 1 4 4 4 Seite 29/32 Bernhard Bausch Schulungsunterlagen Datenbanken 7.2.2 Die Erste Normalform Eine Tabelle befindet sich in der Ersten Normalform (1NF), wenn alle Attribute nur atomare Werte beinhalten, das heisst, jedes Attribut darf nur einmal in der Tabelle vorkommen. Die Vorschrift fordert, dass Daten die sich wiederholen, Wiederholungsdaten also, in eine gesonderte Tabelle auszugliedern sind. Diesen Vorgang der Ausgliederung von Datenfeldern bezeichnet man als Normalisierung. Die unten stehende Tabelle Artikel befindet sich nicht in der erste Normalform, da das Attribut Lief_ID sogenannte Wiederholungsgruppen aufweist. Die Verarbeitung eines Feldes wie die Lief_ID, gestaltet sich höchst schwierig. Die Relation kann nicht gejoint werden. Lieferantennummern sind einzeln nicht ansprechbar. Artikel Art_Nr Art_Bez Art_Art Lief_ID 1 2 3 6 Sync 1 Sync 2 Herkules P6 Monitor Monitor Grafikkarte Drucker 14 136 2479 4 Bei der Zuordnung der Datenfelder auf Tabellen ist zu beachten, das die Anzahl der Spalten einer Tabelle nicht variabel ist. Sie darf nicht von Satz zu Satz ändern: Pe_ID Pe_Name Pe_Vname Pe_Partner Pe_Kind1 Pe_Kind2 Pe_Kind3 14 15 16 Meier Huber Keller Rolf Doris Heinz Monika Michael Bernd Heinrich -- Susi Dieter -- Petra --- In einer solchen Tabelle ergeben sich zwei Unzulänglichkeiten. Die eine besteht darin, dass jeder Zeile Platz für eventuelle Einträge der Familienangehörigen vorgehalten werden muss und bei ledigen bedeutet es, Verschwendung von Speicherplatz. Die Zweite Unzulänglichkeit besteht dann, wenn Rolf und Monika ein viertes Kind bekommen. Die folgende Relation befindet sich allerdings (nur) in der ersten Normalform Person_1NF Pe_ID Pe_Name Pe_Ort Abt_Nr Abt_Name Prd_Nr Prd_Name Pe_Zeit 101 101 Paul Paul Genf Genf 1 1 Chemie Chemie 11 12 Kali Verdünner 60 40 7.2.3 Die Zweite Normalform Eine Datei ist in der Zweiten Normalform, wenn sie der Ersten Normalform entspricht und jedes Nicht-SchlüsselAttribut voll funktional vom Gesamtschlüssel abhängig ist, nicht aber von einem Teilschlüssel oder von einzelnen Schlüsselteilen. Die Zweite Normalform bezieht sich auf solche Tabellen, die über einen Primärschlüssel verfügen, der aus mehr als einem Attribut zusammengesetzt ist. Alle Nichtschlüsselfelder müssen vom Gesamtschlüssel abhängen. Besteht eine Abhängigkeit nur von einem Teil des zusammengesetzten Schlüssels, so müssen die betreffenden Felder ausgegliedert werden. www.babe-informatik.ch Seite 30/32 Bernhard Bausch Schulungsunterlagen Datenbanken Beispiel 1: Felder ausgliedern Leistungen in Std. werden nach einem festen Stundenansatz verrechnet. Leistungsbericht Pe_Nr Ber_Nr PersonalBerichtsNummer Nummer 5 5 5 Auf_Nr AuftragsNummer 940228 940228 940228 Tae_Nr TätigkeitsNummer 11111 11111 11111 Tae_Bez 3 2 5 LB_Std LB_Preis 4 1.5 3 130.00 100.00 110.00 Beratung Vorbesprechung Kalkulation Die Tabelle Leistungsbericht weist einen Gesamtschlüssel auf, der sich aus den Schlüsselfeldern Pe_Nr, Ber_Nr, Auf_Nr sowie Tae_Nr zusammensetzt. Die Nichtschlüsselfelder Tae_bez und LB_Preis sind jedoch nicht vom Gesamtschlüssel, sondern nur von dem Teilschlüssel Tae_Nr abhängig (LB_Preis sind Einzelpreise). Somit ist die Tabelle Leistungsbericht umzustrukturieren. Leistungsbericht Pe_Nr PersonalNummer 5 5 5 Ber_Nr BerichtsNummer Auf_Nr AuftragsNummer 940228 940228 940228 11111 11111 11111 Tae_Nr TätigkeitsNummer 3 2 5 LB_Std 4 1.5 3 Die ausgegliederten Felder werden in eine neue Tabelle Tätigkeitsarten eingebracht. Ergänzt um weitere Tätigkeitsarten, ist die Tabelle wie folgt aufgebaut. Tätigkeitsarten Tae_Nr TätigkeitsNummer 1 2 3 4 5 6 7 Tae_Bez Tae_Preis Akquisition Vorbesprechung Beratung Projektentwurf Kalkulation Zeichnen Schreibarbeiten 70.00 100.00 130.00 100.00 110.00 70.00 60.00 Beispiel 2: Schlüsselabhängigkeit Zusätzlich zum Monatslohn wird eine Sonderzahlung irgendwann im Laufe des Jahres ausbezahlt. Würde man die Zahlung in die Tabelle Monatslohn aufnehmen, ergäbe das folgendes Bild: Monatsgehälter Pe_Nr MG_Jahr 5 5 5 01 01 01 MG_Monat MG-Gehalt 1 2 ?? 5000.00 5200.00 2000.00 Die Sonderzahlung in der Höhe von Fr. 2000.00 ist wohl der Person und dem Jahr zuzurechnen. Da die Zahlung keinen Bezug zu einem bestimmten Monat aufweist, besteht nur eine Abhängigkeit von der Personalnummer (Pe_Nr) und dem Jahr (MG_Jahr). Sie ist nicht vom Gesamtschlüssel, sondern nur von Teilen des Schlüssels abhängig. www.babe-informatik.ch Seite 31/32 Bernhard Bausch Schulungsunterlagen Datenbanken 7.2.4 Die Dritte Normalform Eine Datei ist in der Dritten Normalform, wenn sie der Zweiten Normalform entspricht und die Nichtschlüsselfelder nicht von anderen Nichtschlüsselfeldern abhängen. Im Dritten Normalfall sind keine Abhängigkeiten zwischen Attributen erlaubt, die nicht als Schlüssel definiert sind. Mit anderen Worten, Eine Relation ist in der 3 NF, wenn sie sich in der 1NF und in der 2NF befindet und keine transitiven Abhängigkeiten aufweist. Beispiel: Person_2NF Pe_Nr 101 Pe_Name Pe_Ort Müller Zürich Abt_Nr 3 Abt_Name Chemie Die Relation Person_2NF weist eine transitive Abhängigkeit auf, da Abt_Name von dem Attribut Abt_Nr funktional abhängig ist und nicht vom Schlüssel Pe_Nr. Durch Auftrennung dieser Relation in Person_3NF und Abteilung erhalten wir zwei Relationen, die sich in der 3 NF befinden. Person_3NF Pe_Nr 101 Abteilung Pe_Name Pe_Ort Müller Zürich Abt_Nr 3 Abt_Nr 3 Abt_Name Chemie 7.2.5 Denormalisierung Die starke Aufgliederung der einzelnen Informationselemente in eine Vielzahl von Tabellen hat den Nachteil, dass der Rechner bei Suchvorgängen, die sich über mehrere Tabellen erstrecken, viel Zeit benötigt. Kommt es zu unerträglichen langen Antwortzeiten, so wird das Datenmodell umgebaut, indem Ausgliederungen wieder zurückgenommen werden. Diesen Vorgang bezeichnet man als Denormalisierung. www.babe-informatik.ch Seite 32/32
