update
This commit is contained in:
parent
819ea787b9
commit
0cea260940
BIN
Writerside/images/image_644.png
Normal file
BIN
Writerside/images/image_644.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 62 KiB |
BIN
Writerside/images/image_645.png
Normal file
BIN
Writerside/images/image_645.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 245 KiB |
BIN
Writerside/images/image_646.png
Normal file
BIN
Writerside/images/image_646.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 40 KiB |
BIN
Writerside/images/image_647.png
Normal file
BIN
Writerside/images/image_647.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 6.8 KiB |
BIN
Writerside/images/image_648.png
Normal file
BIN
Writerside/images/image_648.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 35 KiB |
@ -77,6 +77,7 @@
|
||||
<toc-element toc-title="Datenbanken">
|
||||
<toc-element topic="CheatSheet.md"/>
|
||||
<toc-element topic="00_db_intro.md"/>
|
||||
<toc-element topic="01_semantischeDatenmodellierungUndRelationenmodell.md"/>
|
||||
|
||||
</toc-element>
|
||||
<toc-element toc-title="Informatik und Gesellschaft">
|
||||
|
@ -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
|
||||
|
||||
|
@ -0,0 +1,69 @@
|
||||
# Semantische Datenmodellierung und Relationenmodell
|
||||
## Lifecycle von Informationssystemen
|
||||

|
||||
|
||||
### 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
|
||||
- 
|
||||
|
||||
### 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
|
||||

|
||||
|
||||
|
||||
## 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
|
||||
- 
|
||||
- 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
|
||||
- 
|
||||
|
Loading…
x
Reference in New Issue
Block a user