diff --git a/Writerside/images/image_644.png b/Writerside/images/image_644.png new file mode 100644 index 0000000..f21adde Binary files /dev/null and b/Writerside/images/image_644.png differ diff --git a/Writerside/images/image_645.png b/Writerside/images/image_645.png new file mode 100644 index 0000000..3a1e604 Binary files /dev/null and b/Writerside/images/image_645.png differ diff --git a/Writerside/images/image_646.png b/Writerside/images/image_646.png new file mode 100644 index 0000000..756d161 Binary files /dev/null and b/Writerside/images/image_646.png differ diff --git a/Writerside/images/image_647.png b/Writerside/images/image_647.png new file mode 100644 index 0000000..6626489 Binary files /dev/null and b/Writerside/images/image_647.png differ diff --git a/Writerside/images/image_648.png b/Writerside/images/image_648.png new file mode 100644 index 0000000..0e44685 Binary files /dev/null and b/Writerside/images/image_648.png differ diff --git a/Writerside/in.tree b/Writerside/in.tree index 574b53f..2565fe0 100644 --- a/Writerside/in.tree +++ b/Writerside/in.tree @@ -77,6 +77,7 @@ + diff --git a/Writerside/topics/04/Datenbanken/00_db_intro.md b/Writerside/topics/04/Datenbanken/00_db_intro.md index f4b88fe..36029da 100644 --- a/Writerside/topics/04/Datenbanken/00_db_intro.md +++ b/Writerside/topics/04/Datenbanken/00_db_intro.md @@ -1 +1,41 @@ # Einführung in DB +## Phasen des Datenbankentwurfs +```mermaid +stateDiagram + 1: Anforderungsanalyse + 2: Konzeptioneller Entwurf + 3: Logischer Entwurf + 4: Physischer Entwurf + 1-->2 + 2-->3 + 3-->4 + note right of 1: Datenbedarf (nicht formalisiert) - Planung + note left of 2: Konzeptuelles Modell (Informationsstruktur) - Analyse + note left of 3: Logisches Modell (logische Datenbankstruktur) - Design + note left of 4: Internes / Physisches Schema (interne (physische) Datenbankstruktur) - Implementierung +``` + +## Begriffsklärungen +### Datenbank (DB) +> Daten stellen in ihrer physischen Speicherform die eigentliche Datenbank dar + +### Datenbank-Managementsystem (DBMS) +> (proprietäre) Software eines DBS, die die Schnittstelle zwischen DB und Anwender schafft +> +> Das DBMS besteht aus einer Vielzahl komplexer Dienste, die zur Verwaltung der Daten zur Verfügung +> stehen und die Konsistenz der Daten gewährleisten. + +### Datenbanksystem (DBS) +> Gesamtheit aller Komponenten (DB, DBS, Anwendungen, ...) + +### Datenbankmodell +> definiert Speicherstruktur, die DBMS zur internen Datenverwaltung verwendet + +### Datenbanksprache +> idR. stellt ein DBMS eine spezifische Sprache (Data Sub-Language - DSL) zur Verfügung, die Zugriff auf Daten ohne Wissen von interner Strukur ermöglicht +> +> Mit Hilfe der DSL kann man Informationen/Daten verwalten (Insert, Update, Delete) und auf Anfrage (Query) verfügbar machen (Retrieval) + +### Hardware +> Man unterscheidet Plattenspeicher (mit Ein-/Ausgabeperipherie) und Hauptspeicher sowie Prozessoren zur Ausführung der DB-Systemsoftware + diff --git a/Writerside/topics/04/Datenbanken/01_semantischeDatenmodellierungUndRelationenmodell.md b/Writerside/topics/04/Datenbanken/01_semantischeDatenmodellierungUndRelationenmodell.md new file mode 100644 index 0000000..ce8ddd5 --- /dev/null +++ b/Writerside/topics/04/Datenbanken/01_semantischeDatenmodellierungUndRelationenmodell.md @@ -0,0 +1,69 @@ +# Semantische Datenmodellierung und Relationenmodell +## Lifecycle von Informationssystemen +![image_644.png](image_644.png) + +### 1. Planungsphase +- Informationsbedarf der zu untersuchenden Organisation ermitteln +- Informationsstrategie erarbeiten + +#### Beispiel: CRUD-Matrix (Create - Read - Update - Delete) +- Ergebnis: **Informationsprojekte** + - Zusammenfassung von Funktionen, die gleiche Informationsobjekte verwenden + - _Funktionsbereiche_ sind definiert + - strukturieren Organisationsbereich +- ![image_645.png](image_645.png) + +### 2. Analysephase +- _Informationsprojekte_ aus Planung weiter detaillieren + - Daten- und Prozesssicht +- durchgehende Konsistenz zwischen Daten- und Prozessmodell! +- Ergebnis: **Datenmodell** (UML) und **Prozessmodell** (Analysesicht) + + +### 3. Designphase +- Berücksichtigung des Datenbankmodells, Implementierungsplattform (DBMS) + - Implementierung von Beziehungen + - Definition von Referenzen + - Festlegung der Datentypen (DBMS-spezifisch) +- _CASE-Tools_ (_computer aided software engineering_) + - generieren Datenmodelle für 3. aus Datenmodellen aus 2. + - umgekehrt: Round-Trip-Engineering +- Ergebnis: + - Datenmodell + - z.B. **[Relationenmodell](#relationenmodell)**, ergänzt um Datentypen des Ziel-DBMS beim Einsatz von RDBMS + - Prozessmodell der Designsicht + +### 4. Implementierungsphase +- Güte von Analyse und Design zeigen sich in relativ problemloser Implementierung +- RDBMS: Implementierung DB-Schema durch deklarative Sprachkomponente von SQL (SQL DDL) +- CASE-Tools: SQL-Skript direkt aus Relationenmodell generieren + + +### Beispiel Phasen des DB-Entwurfs +![image_646.png](image_646.png) + + +## Relationenmodell +- Grundlage des von E. F. Codd vorgestellten RDB-Modells bildet der Relationenbegriff aus Mathe + - eine **n-stellige (n-äre) Relation in einer Menge M** ist eine Beziehung, die zwischen je n Elementen aus M besteht oder nicht + - vorstellbar als Menge von Tupeln gleicher Länge n + - auch n-Tupel genannt + - ![image_647.png](image_647.png) + - Spalten - Attribute + - einzelne Zeilen - Tupel / Datensätze + +### Definitionen Relationenmodell +- Eine **n-stellige Relation R** ist definiert als Untermenge des kartesischen Produkts der Wertebereiche der zugehörigen Attribute $A_1$, $A_2$, ..., $A_n$ + - $$R(A_1, A_2, ..., A_n) ⊆ W(A_1) x ... x W(A_n)$$ + - Beispiel: _Student (MatrNr, Name, Geb.) ⊆ integer x string x date_ +- Ein Element der Menge R wird als **Tupel** bezeichnet → $$t ∈ R$$ + - Beispiel: _t= (123456, 'Schmidt', 30.01.2014)_ +- Ist der Wert eines Attributs in einem Tupel unbekannt/nicht vorhanden + - **NULL-Wert** + - kann für jedes Attribut festgelegt werden, ob erlaubt ist oder nicht +- **Schlüssel** p minimale Menge von Attributen + - Werte identifizieren Tupel eindeutig + - Wert von p bestimmt die Attributwerte aller anderen Attribute des Tupels eindeutig + - Man kann (im zusammengesetzten Fall) kein Attribut aus p entfernen, ohne dass das verletzt wird +- ![image_648.png](image_648.png) +