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 toc-title="Datenbanken">
|
||||||
<toc-element topic="CheatSheet.md"/>
|
<toc-element topic="CheatSheet.md"/>
|
||||||
<toc-element topic="00_db_intro.md"/>
|
<toc-element topic="00_db_intro.md"/>
|
||||||
|
<toc-element topic="01_semantischeDatenmodellierungUndRelationenmodell.md"/>
|
||||||
|
|
||||||
</toc-element>
|
</toc-element>
|
||||||
<toc-element toc-title="Informatik und Gesellschaft">
|
<toc-element toc-title="Informatik und Gesellschaft">
|
||||||
|
@ -1 +1,41 @@
|
|||||||
# Einführung in DB
|
# 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