IS: Datenbanken, © Till Hänisch 2000 Entwicklung von Datenbankapplikationen Vorgehensmodell

IS: Datenbanken, © Till Hänisch 2000 Prinzip Analog wie bei "klassischer" Softwareentwicklung Analyse Design Umsetzung Spezifika bei Datenbankentwicklung ? Trennung in Applikations- und Datenbankfunktionalität

IS: Datenbanken, © Till Hänisch 2000 Anwendungsarchitektur Applikation Datenbank GUI, Schnittstellen,... Daten, Transaktionen,... Softwareentwicklung DB-Design

IS: Datenbanken, © Till Hänisch 2000 Vorgehen

IS: Datenbanken, © Till Hänisch 2000 Vorgehen Requirements data requirements (Welche Daten,...) functional requirements (Funktionen,...) konzeptionelles Datenmodell data requirements werden detailliert (Entities, Relationships, Constraints,...) Systemunabhängige Darstellung als ER-Diagramm Logisches Datenmodell Abbildung des konzeptionellen Modells auf konkrete DB Physikalisches Datenmodell Umsetzung auf tatsächliches Datenbanksystem (Datentypen, Speicherstrukturen, Indices, Tuning,...)

IS: Datenbanken, © Till Hänisch 2000 Schritte Requirements aus Analyse interessiert uns nicht konzeptionelles Modell abstrakt logisches Modell relational physikalisches Modell ORACLE, Sybase,...

IS: Datenbanken, © Till Hänisch 2000 konzeptionelles DB-Design

IS: Datenbanken, © Till Hänisch 2000 was ist das ? Systemunabhängige Darstellung des Datenmodells Was ist bei allen möglichen Datenbanksystemen gleich --> Systemtheorie Informationen über Objekte (Dinge) mit Attributen --> Entity Beziehungen zwischen diesen --> Relationship Entity Relationship Modell Chen, "The Entity Relationship Model - toward a unified view of data", ACM Trans. on Database Systems, 1976

IS: Datenbanken, © Till Hänisch 2000 Entities und Attribute Entity: "Ding" aus der realen Welt materiell (Person, Auto, Haus, Artikel,...) immateriell (Firma, Vorlesung, Auftrag,...) Attribut: Eigenschaft eines Entity z.B. Entity "Person" wird durch Name, Adresse beschrieben --> Attribute "Name", "Adresse" Für jeden Entity haben die Attribute bestimmte Werte (z.B. Name="Hänisch")

IS: Datenbanken, © Till Hänisch 2000 Arten von Attributen zusammengesetzte (composite) Attribute bestehen aus mehreren Teilen Adresse: (Strasse, Hausnummer, PLZ, Ort) Hierarchien möglich sinnvoll, wenn je nach Kontext entweder die einzelnen oder der gesamte Wert von Interesse einfache (atomic) Attribute können nicht weiter zerlegt werden

IS: Datenbanken, © Till Hänisch 2000 Arten von Attributen contd. einwertig (single valued) Das Attribut hat genau einen Wert Alter einer Person mehrwertig (multi valued) mehrere Werte möglich Telefonnummer einer Person abgeleitet (derived) Wert des Attributs kann aus anderen Werten berechnet werden Alter aus Geburtsdatum

IS: Datenbanken, © Till Hänisch 2000 Arten von Attributen contd. null Einem Attribut kann kein Wert zugeordnet werden (nicht existent oder unbekannt) spezieller Wert null three valued logic (true/false/null) complex composite und multivalued geschachtelt Adresse (mehrwertig), besteht aus Komponenten werden von realen DB-Systemen z.T. nicht unterstützt nur im konzeptionellen Modell !!

IS: Datenbanken, © Till Hänisch 2000 Entity type, Entity set Entity type Gruppe von Entities mit den gleichen Attributen nicht gleichen Werten !! wird durch einen Namen und die Menge der Attribute definiert Analogie zur Klasse, Entity entspricht Objekt Entity set alle zu einem Entity type gehörenden Entities

IS: Datenbanken, © Till Hänisch 2000 Beispiel

IS: Datenbanken, © Till Hänisch 2000 Schlüsselattribut eines Entity types Attribut, das für alle möglichen Entities unterschiedliche Werte hat Betonung auf "möglichen" Falls kein einzelnes diese Eigenschaft hat, möglicherweise zusammengestztes Attribut eindeutige Identifikation eines Entities Weak Entity Entity type ohne Schlüsselattribut

IS: Datenbanken, © Till Hänisch 2000 eines Attributs Menge aller möglichen Werte eines (atomaren) Attributs Definition des Attributs als Funktion A: Attribut von E V: Wertebereich von A P(V): Menge aller Teilmengen von V Für composite Attribute Wertebereich (domain)

IS: Datenbanken, © Till Hänisch 2000 Beispiel Verwaltung einer Firma mit Angestellten und Projekten Beispiel für kompletten Entwicklungszyklus Ausgangspunkt: Requirements vorhanden

IS: Datenbanken, © Till Hänisch 2000 Company Requirements Die Firma ist in Abteilungen organisiert. Jede Abteilung hat eine eindeutige Nummer, einen eindeutigen Namen und einen Mitarbeiter, der die Abteilung leitet. Das Datum, seit dem dieser die Abteilung leitet, wird gespeichert. Eine Abteilung kann verschiedene Standorte haben. Eine Abteilung führt eine Reihe von Projekten durch. Jedes Projekt hat einen eindeutigen Namen und eine eindeutige Nummer und wird an einem Standort durchgeführt. Zu jedem Mitarbeiter wird der Name, die Personalnummer, die Adresse, das Gehalt, das Geschlecht und das Geburtsdatum gespeichert. Jeder Mitarbeiter gehört zu einer Abteilung, kann aber an mehreren Projekten arbeiten, die nicht notwendigerweise alle von der gleichen Abteilung durchgeführt werden. Für jeden Mitarbeiter werden die Stunden/Woche, die er an jedem Projekt arbeitet, gespeichert. Jeder Mitarbeiter wird einem Vorgesetzten zugeordnet. Für jeden Mitarbeiter werden Informationen über seine Familienmitglieder für Versicherungszwecke gespeichert. Dazu wird jeweils der Name, das Geschlecht, das Geburtsdatum und die Art der Beziehung zum Mitarbeiter gespeichert.

IS: Datenbanken, © Till Hänisch 2000 Relationships Attribute, die sich auf andere Entities beziehen DEPARTMENT.Manager, EMPLOYEE.Department,... (mehrwertige) Attribute mit entsprechenden Entity sets als Wertebereich können (sollen ?) durch Relationships ausgedrückt werden Relationship type R zwischen Entity types E 1...E n definiert Menge von Assoziationen (Relationship set) zwischen Entities dieser Typen Menge von Relationship instances r i, wobei r i n Entities (e 1,...e n ) verbindet, e i  E i --> R  E 1 xE 2 x...xE n

IS: Datenbanken, © Till Hänisch 2000 Beispiel für Relationships e1e1 e2e2 e3e3 e4e4 e5e5 e6e6 e7e7 d1d1 d2d2 d3d3 EMPLOYEEWORKS_FORDEPARTMENT

IS: Datenbanken, © Till Hänisch 2000 Ordnung von Relationships j1j1 j2j2 j3j3 s1s1 s2s2 p1p1 p2p2 Zahl der an einer R beteiligten Entitiy types 2 => binär, 3 => tertiär (selten), höhere kommen kaum vor SUPPLIER PART SUPPLY PROJECT

IS: Datenbanken, © Till Hänisch 2000 Rollen Jeder Entity type hat bei Relationship bestimmte Rolle, z.B. WORKS_FOR: EMPLOYEE "worker", DEPARTMENT "employer" Falls sind Rollennamen redundant, aber: e1e1 e2e2 EMPLOYEE e3e3 SUPERVISION = Chef von 2 = unterstellt rekursive Relationships

IS: Datenbanken, © Till Hänisch 2000 Attribute Relationships können (wie Entities) Attribute haben WORKS_FOR könnte Attribut "Hours" haben wieder: nur konzeptionell möglich Je nach Abbildung wird dies u.U. nicht von DB- Systemen unterstützt Übersichtlicheres Modell (weniger Entities)

IS: Datenbanken, © Till Hänisch 2000 Kardinalitäten definieren, wie viele Entities jeweils an Relationship teilnehmen können bei WORKS_FOR hat DEPARTMENT:EMPLOYEE Kardinalität 1:N ein DEPARTMENT kann mehrere (0...viele) EMPLOYEES beschäftigen, jeder EMPLOYEE ist genau einem (oder keinem) DEPARTMENT zugeordnet Möglichkeiten 1:1, 1:N, N:1, M:N

IS: Datenbanken, © Till Hänisch 2000 Participation total Jeder Entity e des Entity types E ist an der Relationship R beteiligt existence dependancy: Entity e kann nur existieren, wenn er an R teilnimmt partial Es gibt Entities e, die nicht beteiligt sind EMPLOYEE:DEPARTMENT: total EMPLOYEE:MANAGES: partial Relationships in COMPANY-DB ?

IS: Datenbanken, © Till Hänisch 2000 ER-Diagramme - Grundlagen

IS: Datenbanken, © Till Hänisch 2000 ER-Diagramme - Relationships

IS: Datenbanken, © Till Hänisch 2000 ERD - Konventionen Entity (und Relationship) types GROSS Attribute mit grossem Anfangsbuchstaben Namen von Entity types im Singular Entity: Nomen Relationship: Verb Relationshipnamen so, daß von links nach rechts/oben nach unten gelesen werden kann

IS: Datenbanken, © Till Hänisch 2000 ERD - diverses Kardinalitäten unpraktisch zwei Mechanismen (Kardinalität, total/partial participation) für die gleiche Sache (min,max) Notation partial participation (0,...) total participation (1,...) Erweiterungen z. B. für Spezialisierung (Person-Student,...) verschiedene Notationen (vgl. Objektmodellierung) deshalb auch hier: UML (siehe SE) einsetzbar

IS: Datenbanken, © Till Hänisch 2000 Zusammenfassung ER-Diagramme zur konzeptionellen Modellierung Darstellung der semantischen Struktur Abstraktion über verwendete Technologien Übersichtlich da Details (z.B. Datentypen,...) weggelassen Konzepte, keine Details !!!

IS: Datenbanken, © Till Hänisch 2000 Fußballstatistik Datenbank zur Analyse von Spielen der Bundesliga erstellen. Jedes Spiel wird von zwei Mannschaften bestritten und von einem Schiedsrichter geleitet. Jede Mannschaft hat eine bestimmte Zahl an Spielern, die nicht notwendigerweise an jedem Spiel teilnehmen. Ziel ist es, zu erfassen, welche Spieler an welchem Spiel in welcher Position teilnahmen und wieviele Tore, Ecken, Freistöße,... jeder Spieler jeweils in welcher Minute erzielte. Das Ergebnis jedes Spiels soll ebenfalls festgehalten werden.