18 KiB
Modellierung – Zusammenfassung
Dozent: A. Zimmermann | HWR Berlin | 2026 | Folien 1–112
1. Einführung (Folien 1–32)
1.1 Definitionen (Folien 3–6)
Charakteristik der Informationen im Unternehmen:
- Informationen bilden Entscheidungsgrundlagen
- Informationen können aus unterschiedlichen Quellen stammen
- Qualität hängt von Verfügbarkeit, Korrektheit und Vollständigkeit ab
- Erhebung, Speichern und Verarbeiten erzeugt Aufwände
- Aufgabengebiete sind durch Informationsbeziehungen verknüpft
Aspekte des Datenmanagements:
- Architektur (Datenmodellierung)
- Datentechnik (Hardware, Installation, Reorganisation, Sicherung)
- Administration und Datennutzung
Anforderungen an Datenverwaltung:
- Zentrale Verwaltung der Daten
- Vermeidung/Einschränkung von Redundanzen
- Vermeidung von Inkonsistenzen
- Gemeinsame Nutzung durch verschiedene Anwendungen
- Datenschutz und Datensicherung
- Datenintegrität
- Datenunabhängigkeit von Anwendungen
Definitionen:
- Daten = Logisch strukturierte Informationseinheiten
- Datenbank = Einrichtung für langfristige sichere Aufbewahrung von Daten
1.2 Modellierung (Folien 7–9)
Ein Modell ist ein Abbild der realen Welt, das man mit Absicht erstellt, um bestimmte Probleme zu lösen.
Modellbildungsprozess: Reales Problem → Modell → Analyse/Simulation → Theoretische Lösung → Interpretation → Überprüfung → Reale Lösung
Kriterien eines Modells nach Heinrich Hertz:
- Richtigkeit — Nicht beweisbar, nur durch Experimente überprüfbar und widerlegbar
- Zulässigkeit — Logisch eindeutig formuliert, ohne Widersprüche
- Zweckmäßigkeit — Keine überflüssigen Anteile; so einfach wie möglich, so kompliziert wie nötig
Modellierungsansätze: Verschiedene Modellierungssprachen führen zu verschiedenen semantischen Datenmodellen. Praktische Bedeutung haben insbesondere Entity-Relationship-Modellierung (ERM) und UML. Gängige Vorgehensweise: Erst ER-Modell, dann Konvertierung in relationales Modell.
1.3 Datenhaltung (Folien 10–14)
Zwei grundsätzliche Formen:
- Herkömmliche Form (Dateien): Datenverwaltung in die Anwendung integriert → enormer Entwicklungsaufwand, kaum Datenaustausch
- Datenbanken: Datenbank = Datenmanagement + Daten. DBMS übernimmt Speicherung, Aufruf, Änderungen, Sortieren, Sicherungen
Vorteile von Datenbanken gegenüber Dateien:
- Reduktion der Entwicklungskosten
- Flexible Verarbeitung und Darstellung
- Vermeidung von Redundanzen, Inkonsistenzen, Datenverlust
- Zugriffskontrolle
- Mehrbenutzerbetrieb
- Hohe Verfügbarkeit
Dateien statt Datenbanken empfohlen bei:
- Sehr kleinen, nicht-kommerziellen Anwendungen
- Systemnahen Anwendungen
- Verschiedenen Testumgebungen
- Groben konzeptuellen Entwicklungen
1.4 Architektur (Folien 15–18)
Client/Server-Architektur:
- Client nimmt die Ressource in Anspruch (z. B. Darstellung)
- Server stellt die Ressource zur Verfügung (z. B. Bearbeitung)
Oracle-Architektur:
- SQL-Plus, SQL-Developer, Oracle Instant Client → Listener → Dispatcher → DBMS-Instanzen → Datenbestände
- Multi-Tenant-Container und Real Application Cluster (RAC)
SQLite-Architektur (keine Client/Server-Architektur):
- DBMS-Instanz direkt in die Anwendung eingebettet
- Datenbestand als Dateien im Dateisystem
1.5 Datenbankbenutzer (Folien 19–20)
| Rolle | Aufgaben |
|---|---|
| DBA (Datenbankadministrator) | DB-Design, Softwareinstallation/-wartung, Speicherplatzverwaltung, Sicherheitsmechanismen, Backup/Recovery, Reorganisation, Systembeobachtung/Tuning |
| Anwendungsentwickler | Systemanalyse, SQL, Standard-Abfragen, Anwendungsentwicklung |
| Endanwender | Benutzung erstellter Programme, vorgefertigte/Ad-Hoc-Abfragen, QBE-Werkzeuge |
1.6 Entwicklung (Folien 21–24)
- 1960er Jahre: Jede Anwendung hat eigenes Datenmanagement und eigene Daten
- 1970er Jahre: Gemeinsames Datenmanagement, aber noch getrennte Datenbestände
- Heute: Gemeinsames Datenmanagement und gemeinsame Datenbestände
Zugriff auf Datenbanken erfolgt programmatisch z. B. über JDBC (Java Database Connectivity).
1.7 Arten von Datenbanken (Folien 25–28)
| Art | Status |
|---|---|
| Hierarchische Datenbanken | Heute selten verwendet |
| Netzartige Datenbanken | Heute selten verwendet |
| Dokumentenbasierte Datenbanken | Selten verwendet (z. B. MongoDB) |
| Key-Value-Datenbanken | Begrenzte Bedeutung (z. B. BerkeleyDB) |
| Objektorientierte Datenbanken | Vorhanden |
| Relationale Datenbanken | Heute fast ausschließlich verwendet |
Warum relationale Datenbanken dominieren:
- Beziehungen und Entitäten werden gleich dargestellt → derselbe Verarbeitungsmechanismus
- Relationale Algebra liefert umfangreiche und fortgeschrittene Operationen
- Alle anderen DB-Typen lassen sich damit emulieren
1.8 Prinzipien von E.F. Codd (Folien 29–32)
Die 12 Regeln von Codd definieren eine relationale Datenbank:
- Vollständige Verwaltung über relationale Fähigkeiten
- Darstellung von Informationen: Alle Informationen als Werte in Tabellen
- Zugriff auf Daten: Über Tabellenname + Primärschlüssel + Spaltenname
- Systematische Behandlung von Nullwerten: Durchgängig gleich als unbekannt/fehlend
- Struktur: Systemkatalog auf derselben logischen Ebene wie die Daten
- Abfragesprache: Mindestens eine Sprache mit vollständigem Befehlssatz (DDL, DML, Integrität, Autorisierung, Transaktionen)
- Aktualisieren von Sichten: Theoretisch aktualisierbare Sichten müssen vom System aktualisierbar sein
- Abfragen und Bearbeiten: Unterstützung für Einfügen, Aktualisieren und Löschen ganzer Tabellen
- Physikalische Datenunabhängigkeit: Logischer Zugriff unabhängig von physikalischen Methoden
- Logische Datenunabhängigkeit: Tabellenstruktur-Änderungen ohne Einfluss auf Anwendungslogik
- Unabhängigkeit der Integrität: Integritätsregeln in der DB-Sprache definierbar, nicht umgehbar
- Verteilungsunabhängigkeit: Logischer Zugriff unverändert bei verteilten Datenbanken
2. Mengenlehre (Folie 33)
Die Mengenlehre bildet die mathematische Grundlage der Theorie relationaler Datenbanken. Behandelt in separatem Skript (b_Mengenlehre). Themen: Definition, Eigenschaften, Operationen, Zahlenmengen, Dimensionen.
3. ANSI-SPARC-Modell (Folien 34–38)
3.1 Drei-Schichten-Architektur (Folien 35–37)
Das ANSI-SPARC-Modell gewährleistet Unabhängigkeit der Datenbank von Programmiersprache und Hardware:
| Ebene | Bezeichnung | Inhalt |
|---|---|---|
| Externe Ebene | Anwendungs-Ebene | Benutzeroberflächen, Datensichten, API, Schnittstellen. Jede Sicht zeigt nur einen Teil der Daten |
| Konzeptionelle Ebene | Logische Ebene | Beziehungen, Daten. Relationales Datenmodell, ERM-Diagramme, Integritätsbedingungen, Zugriffsrechte |
| Interne Ebene | Physische Ebene | Art und Form der Speicherung. Dateien, Partitionen, Tablespaces, Zugriffsmechanismen |
3.2 Phasen des Datenbankentwurfs (Folie 38)
- Anforderungsanalyse → Spezifikation (Pflichtenheft)
- Konzeptueller Entwurf → Konzeptuelles Schema (ERM)
- Logischer Entwurf → Logisches Schema (Tabellen)
- Physischer Entwurf → Physisches Schema (Datenträger)
4. Anforderungsanalyse (Folien 39–50)
4.1 Kurzfassung (Folien 40–42)
Im Laufe der Anforderungsanalyse wird erfasst:
- Welche Abteilungen mit der DB arbeiten
- Welche Geschäftsprozesse unterstützt werden
- Welche Daten involviert werden
- Wie die Daten strukturiert sind
- Qualitative und quantitative Anforderungen
Schritte nach A. Kemper:
- Identifikation von Organisationseinheiten
- Identifikation der zu unterstützenden Aufgaben
- Anforderungs-Sammelplan (zu befragende Personen)
- Anforderungs-Sammlung
- Filterung (Verständigkeit und Eindeutigkeit prüfen)
- Satzklassifikationen (Objekte, Beziehungen, Operationen, Ereignisse)
- Formalisierung/Systematisierung (ins Pflichtenheft übertragen)
Ergebnisse der Anforderungsanalyse:
- Informationsanforderungen: Beschreibung von Objekten/Attributen und Beziehungen/Attributen
- Datenverarbeitungsanforderungen: Beschreibung von Prozessen
4.2 Beispiel: Universitätsschema (Folien 43–46)
Drei Arten von Beschreibungen:
Objektbeschreibung (z. B. Uni-Angestellte):
| Attribut | Typ | Länge | Identifizierend | Beispiel |
|---|---|---|---|---|
| PersonalNr | Char | 10 | ja | 1234561234 |
| Gehalt | Dezimal | 8.2 | nein | 9000.11 |
| Rang | String | 4 | nein | W3 |
Beziehungsbeschreibung (z. B. prüfen):
- Beteiligte Objekte: Professor (Prüfer), Student (Prüfling), Vorlesung (Lehrstoff)
- Attribute: Datum, Uhrzeit, Note
Prozessbeschreibung (z. B. Zeugnisausstellung):
- Häufigkeit, Priorität, benötigte Daten, Datenmenge
4.3 Beispiel: Krankenhaus-Modell (Folien 47–50)
Objekte: Ärzte, Pflegepersonal, Patienten mit deren Beziehungen (behandelt, betreut) und Prozessen (Behandlungsplan erstellen).
5. Konzeptueller Entwurf (Folien 51–87)
5.1 Entity-Relationship-Modell (ERM) (Folien 51–54)
Auf Basis der Anforderungsanalyse wird ein konzeptuelles ERM erstellt. Das konkrete DBMS wird noch nicht betrachtet.
Beispiele:
- Uni-Schema: Studenten, Vorlesungen, Professoren, Assistenten mit Beziehungen hören, prüfen, lesen, arbeitenFür, voraussetzen
- Krankenhaus-Schema: Arzt, Patient, Pflegepersonal mit Beziehungen behandelt, betreut
5.2 Modellierungsstrukturen in Peter-Chen-Notation (Folie 55)
| Element | Grafische Darstellung | Bedeutung |
|---|---|---|
| Entitätstypen | Rechteck | Objekte der realen Welt |
| Beziehungstypen | Raute | Bindungen zwischen Entitäten |
| Attribute | Oval/Kreis | Charakteristiken von Entitäten und Beziehungen |
| Funktionalitäten | Beschriftung an Verbindungslinien | Kardinalität der Beziehungen |
| Schlüssel | Unterstrichene Attribute | Identifizierende Attribute |
| Rollen | Beschriftung bei rekursiven Beziehungen | Rolle einer Entität in der Beziehung |
5.3 Entitätstypen (Folie 56)
Gegenstände sind Objekte der realen Welt, die zu Gegenstandstypen (Entitätstypen) abstrahiert werden:
- "Zimmermann", "Merkel", "Meier" → Mensch
- "VW", "Mercedes", "BMW" → Auto
Man arbeitet ausschließlich mit Entitätstypen (abstrakte Klassen), nicht mit einzelnen Instanzen.
5.4 Beziehungstypen (Folie 57)
Beziehungen drücken Bindungen zwischen Entitäten aus. Nicht alle Entitätstypen müssen verbunden sein, aber ein alleinstehender Entitätstyp ohne Beziehung ist verdächtig.
5.5 Attribute (Folien 58–62)
Attributierte Beziehungen: Wenn beide Entitätstypen semantisch gleiche Attribute haben, werden diese dem Beziehungstyp zugeordnet (z. B. Betrag bei "Kredit geben" zwischen Kunde und Bank).
Entscheidung Entitätstyp vs. Attribut:
- Wird etwas durch anderes beschrieben → das Beschriebene ist Entitätstyp, das Beschreibende ist Attribut
- Kann etwas durch nichts weiteres beschrieben werden → es ist ein Attribut
Attributtypen:
| Typ | Beschreibung | Beispiel |
|---|---|---|
| Einfach | Ein Wert zu einem Zeitpunkt | Name = "Müller" |
| Mehrwertig | Mehrere Werte gleichzeitig | Ampel: rot + gelb |
| Zusammengesetzt | Besteht aus Teilattributen | Adresse: PLZ + Ort + Straße |
| Abgeleitet | Aus anderen Attributen berechnet | Bruttopreis = Netto × (1 + MwSt) |
5.6 Schlüssel und Primärschlüssel (Folien 63–65)
- Schlüssel: Attributmenge, deren Werte eine Entität eindeutig identifizieren
- Schlüsselkandidaten: Mehrere mögliche Schlüssel
- Primärschlüssel (PK): Der Kandidat mit minimaler Länge, im ERM unterstrichen
- Minimaler Schlüssel: Keine Untermenge des PK bildet selbst einen Schlüssel
- Wichtig: Wahl eines anderen PK ändert das gesamte Modell
5.7 Rekursive Beziehungen (Folie 66)
Beziehungen zwischen Entitäten desselben Entitätstyps. Dabei werden Rollen zugeschrieben.
Beispiele:
- Vorlesungen → voraussetzen (Vorgänger/Nachfolger)
- Softwareprodukt → Versionsnummer
- Polizisten → im Zweierteam patrouillieren
5.8 Funktionalitäten (Folien 67–76)
Funktionalität gibt an, wie viele Instanzen in einer Beziehung teilnehmen:
| Typ | Beschreibung | Beispiel |
|---|---|---|
| 1:1 | Einer Entität aus E1 entspricht höchstens eine aus E2 (und umgekehrt) | Persönliche Daten ↔ Ansprechdaten |
| 1:N | Einer aus E1 entsprechen mehrere aus E2, aber einer aus E2 höchstens eine aus E1 | Schüler → Fahrausweise |
| N:M | Mehrere aus E1 entsprechen mehreren aus E2 | Studenten ↔ Vorlesungen (hören) |
Auflösung einer M:N-Beziehung: Wird in zwei 1:N-Beziehungen aufgebrochen durch Einführung eines neuen Entitätstyps (z. B. Hersteller ↔ Lieferant → Hersteller → Herstlr_Liefrnt ← Lieferant).
5.9 (min,max)-Notation (Folien 77–78)
Genauere Angabe der Kardinalitäten als Standardfunktionalitäten:
- min = 0: Entitäten, die an keiner Beziehung teilnehmen
- *max = : Beliebig viele Entitäten
Beispiel Polyeder:
- Polyeder (4,*) — Hülle — (1,1) Flächen
- Flächen (3,*) — Grenze — (2,2) Kanten
- Kanten (2,2) — StartEnde — (3,*) Punkte
5.10 Mehrstellige Beziehungen (Folien 79–80)
- Ternäre Beziehung: Zwischen 3 Entitätstypen
- n-äre Beziehung: Zwischen n Entitätstypen
- Sollten möglichst in binäre Beziehungen umgewandelt werden
- Beispiel: "prüfen" (Student, Vorlesung, Professor) → neuer Entitätstyp "Prüfungen" mit binären Beziehungen
5.11 Spezielle Konzepte (Folien 82–87)
Komposition / Schwache Entitäten (Folie 83)
Existenz eines Entitätstyps ist von der Existenz eines anderen abhängig (has-a).
- Beispiel: Konto existiert nur in Zusammenhang mit einer Bank
Generalisierung (Folien 84–86)
Abstraktion auf Ebene der Entitätstypen (is-a). Gemeinsame Eigenschaften werden in einen Obertyp ausgelagert, spezifische bleiben bei den Untertypen.
- Beispiel: Lebensmittel (gültig bis) und Eisenwaren (Garantiefrist) → Obertyp Produkt (Bezeichnung, Hersteller)
Aggregation (Folie 87)
Verschiedene Entitätstypen bilden in ihrer Gemeinsamkeit einen neuen Entitätstyp (has-a).
- Beispiel: Fahrrad besteht aus Rahmen (Rohre, Lenker) und Rad (Speiche, Felge)
6. Logischer Entwurf (Folien 88–112)
6.1 Definitionen (Folien 89–90)
- Datentyp = Werte + Operationen (z. B. integer: +, -, *, /, mod)
- Relation = Untermenge des kartesischen Produktes mehrerer Datentypen = Tabelle
- Tupel = Zeile (Record, Datensatz)
- Feld = Spalte (Attribut, Eigenschaft)
- Schema = Namen aller Felder + Datentypen + Länge + Reihenfolge
6.2 Relationale Darstellung (Folien 91–93)
Vorteile des relationalen Modells:
- Entitäten und Beziehungen werden gleich als Tabellen dargestellt
- Dieselben algebraischen Operationen für beide
- Mathematisch begründet durch E.F. Codd
Notation:
RelationsName = { [ Feld1:Datentyp1, Feld2:Datentyp2, ... ] }
Beispiel: Auto = { [ KFZ:string, Modell:string, Gewicht:real, Baujahr:integer ] }
Primärschlüssel wird unterstrichen.
6.3 Konvertierungsregeln ERM → Relational (Folie 93)
Regeln für Entitätstypen:
- Neue Tabelle (Entitäts-Tabelle) bilden
- Alle Attribute des Entitätstyps inkludieren
Regeln für Beziehungstypen:
- Neue Tabelle (Beziehungs-Tabelle) bilden
- Primärschlüssel aller verbundenen Entitätstypen inkludieren → bilden i.d.R. den PK der Beziehungstabelle
- Attribute des Beziehungstyps inkludieren
6.4 Vereinfachung der Darstellungen (Folien 94–106)
1:1-Beziehungen (Folien 95–97)
Zwei Optionen:
- Option A: Beide Entitäts-Tabellen zu einer Tabelle zusammenführen + Beziehungsattribute. Vorsicht: Datensätze können zu groß werden
- Option B: Beziehungs-Tabelle weglassen, PK einer Entitäts-Tabelle als FK in die andere aufnehmen
1:N-Beziehungen (Folien 98–99)
- Beziehungs-Tabelle weglassen
- In die Tabelle auf der N-Seite den PK der Tabelle auf der 1-Seite als Fremdschlüssel (FK) einfügen
- Beziehungsattribute ebenfalls in die N-Seiten-Tabelle
Schwache Entitäten (Folien 100–101)
- Eigene Tabelle für schwache Entität
- PK der referenzierten (starken) Entität wird Teil des PK der schwachen Entität (Unterschied zu normalen 1:N-Beziehungen, wo der FK nicht Teil des PK wird)
6.5 Beispiel: Uni-Schema als Tabellen (Folien 102–103)
| Tabelle | Felder |
|---|---|
| Professoren | PersNr, Name, Rang, Raum |
| Studenten | MatrNr, Name, Semester |
| Vorlesungen | VorlNr, Titel, SWS, gelesenVon (FK→Professoren) |
| Assistenten | PersNr, Name, Fachgebiet, Boss (FK→Professoren) |
| hören | MatrNr (FK), VorlNr (FK) |
| voraussetzen | Vorgänger (FK), Nachfolger (FK) |
| prüfen | MatrNr (FK), VorlNr (FK), PersNr (FK), Note |
6.6 Wichtige Bemerkung (Folien 109–111)
Keine Felder/PK/FK willkürlich in Tabellen hinzufügen! Nur laut Vereinfachungsregeln.
Ausnahmen:
- ERM-bezogene Gründe (z. B. PID, MonsterID)
- Auditing/Richtlinien (z. B. "Alle Zeilen müssen fortlaufend nummeriert werden")
- Administrative Gründe (z. B. Fusion großer Datenmengen)
- Anwendungsbezogene Gründe (z. B. OO-DB pflegen PK selbst)
Kontroverse um künstliche IDs: Einige Autoren empfehlen ausdrücklich künstliche IDs, weil:
- PK soll keine semantischen Informationen enthalten
- PK darf sich nicht mit der Zeit ändern
- PK soll einfach aufgebaut sein (nicht aus mehreren Feldern)
Im Unterricht wird auf diese Meinung verzichtet (Verständnis halber), obwohl sie in der Wirtschaft sehr verbreitet ist.
Zusammenfassung der Kernthemen
| Thema | Kernaussage |
|---|---|
| Datenbank vs. Dateien | DB bietet Redundanzvermeidung, Mehrbenutzerbetrieb, Zugriffskontrolle |
| Codds 12 Regeln | Definieren eine relationale DB im strengen Sinne |
| ANSI-SPARC-Modell | Drei Ebenen: extern, konzeptionell, intern → Datenunabhängigkeit |
| Anforderungsanalyse | Objekt-, Beziehungs- und Prozessbeschreibungen erstellen |
| ERM – Peter-Chen | Entitäten (Rechteck), Beziehungen (Raute), Attribute (Oval), Schlüssel (unterstrichen) |
| Funktionalitäten | 1:1, 1:N, N:M; (min,max)-Notation für genaue Kardinalitäten |
| Spezielle Konzepte | Komposition (has-a, schwache Entität), Generalisierung (is-a), Aggregation (has-a) |
| Logischer Entwurf | ERM → Tabellen; Vereinfachung bei 1:1 und 1:N durch Wegfall der Beziehungstabelle |
| Fremdschlüssel | Bei 1:N wird PK der 1-Seite als FK in die N-Seite eingefügt |