relationale Datenbanken Flashcards
1
Q
relationale Datenbanken
A
- relationale Datenmodell 1970 von E. F. Codd entwickelt (bildet die Basis für rel. Datenbanken)
- Spalten werden Attribute oder Felder genannt
- Zeilen der Tabelle werden als Tupel oder Datensätze bezeichnet
- es gibt keine zwei Tupel die exakt gleich sind (mindestens in dem Primärschlüssel)
- der Aufbau einer Relation wird auch die Struktur oder das Schema der Tabelle genannt
- die Gesamtheit der zu einer Datenbank gehörigen Relationsschema heißt Schema der Datenbank
2
Q
Datentypen
A
- jedem Attribut wird ein bestimmter Datentyp zugeordnet
- meist stehen verschiedene Zahlentypen, Zeichenketten (Text) und Datumstypen zur Verfügung
- Datentyp bildet den Wertebereich (die Domäne) des Attributs
- welche Datentypen und weitere Einschränkungen möglich sind, hängt vom DBMS ab
3
Q
NULL-Werte oder leere Werte
A
- Attribute können entsprechend ihrem Wertebereich mit Werten belegt werden
- ein leerer Attributwert kann einen NULL-Wert haben
- NULL-Werte entsprechen keinen Datentyp, sonder sind nur symbolische Werte und sind nicht dem numerischen Wert null gleichzusetzen
- ein NULL-Wert ist ein Indikatorbyte, das angibt, ob in einem Tupel für ein Attribut ein Wert eingetragen wurde oder nicht und kann mit keinem anderen Wert verglichen werden, auch nicht mit einem anderen NULL-Wert
- ein leerer Wert dagegen entsteht, wenn z.B. ein Attributwert gelöscht wird
4
Q
Schlüssel
A
- ein einer Relation dürfen durch die Mengendefinition keine gleichen Tupel vorhanden sein
- somit ist jedes Tupel durch einen oder mehrere (gegebenfalls auch alle) Attributwerte eindeutig indentifizierbar
- die Menge der Attribute, die ein Tupel eindeutig identifizieren, heißt Schlüsselkandidaten
- an Schlüssel wird Minimalitätsanforderungen gestellt, d.h. ein Schlüssel sollte so kurz wie möglich sein und es darf keine Teilmenge des Schlüssels bereits Schlüssel sein
5
Q
Primärschlüssel
A
- um alle Tupel zu identizieren, kann einer Relation auch ein weiteres Attribut hinzugefügt werden, welches die Tupel durchnummeriert; so ist es möglich, die Tupel der Relation immer anhand dieses Attributs zu unterscheiden; das Attribut wird in diesem Fall der Primärschlüssel der Relation
- jede Relation kann nur einen Primärschlüssel besitzen
- das Attribut, welches als Primärschlüssel dient, wird auch als indentifizierendes Attribut bezeichnet (bzw. indentifizierende Attribute, wenn mehrere Attribute gemeinsam als Primärschlüssel dienen)
- ein Primärschlüssel einer Tabelle kann ein Attribut oder Attributkombinationen sein, deren Werte die Datensätze dieser Tabelle eindeutig identifizieren
- alle Attribute bzw. Attributkombinationen, deren Werte eindeutig sind, werden als Schlüsselkandidaten bezeichnet
- nur ein Schlüsselkandidat kann als Primärschlüssel festgelegt werden
- wenn eine Tabellle keine eindeutigen Datenfelder besitzt, sollte eine eindeutige ID-Nummer als Schlüssel vergeben werden, beispielweise eine Kundennummer für eine Relation Kunden
6
Q
Fremdschlüssel
A
- ist ein Attribut in einer Relation, welches eine Beziehung zu einem Schlüsselfeld einer anderen Relation herstellt
- kann über die Abkürzung FK oder das nachgestellte zeichen ‘#’ gekennzeichnet werden
- beispielweise befindet sich in einer Relation Aufträge in jedem Tupel eine Kundennummer des Kunden, der den Auftrag ausgelöst hat; diese Kundennummer identifiziert einen Kunden in der Kundenrelation eindeutig; die Kundennummer in der Auftragstabelle stellt somit einen Fremdschlüssel dar
7
Q
Index
A
- häufig sollen die Tupel einer Relation in einer anderen Reihenfolge durchlaufen werden, als sie erfasst wurden, z.B. nach Postleitzahlen; dazu muss die gesamte Relation nach diesen Postleitzahlen sortiert werden
- um bei einer großen Anzahl von Tupeln den Zugriff auf die Daten zu beschleunigen, können zusätzlich zum Primärschlüssel weitere Indizes angelegt werden, die auch als Sekundärindizen bezeichnet werden
- bei Verwendung mehrerer Indizen wird z.B. beim Füllen einer Tabelle viel Zeit benötigt, um die Indizes zu aktualisieren; günstig ist in diesem Fall, die Indizes erst nach dem Füllen der Tabelle zuaktualisieren
8
Q
1:1- und 1:n-Beziehungen
A
- für die Umsetzung der beiden Beziehungstypen gibt es zwei Möglichkeiten:
1.
-es wird eine neure Relation erzeugt, welche als Attribute (Spalten) die Primärschlüssel der beiden Reltionen, die in Beziehung stehen, enthält - außerdem kann die Relation beschreibende Attribute in einer zusätzlichen Spalte aufnehmen
Vorteil: es treten keine NULL-Werte auf
Nacheil: es wird eine weitere Relation benötigt
2.
- eine der beiden Relationen wird um ein Attribut (Spalte) erweitert
- bei 1:1-Beziehungen ist es egal, welche der beiden Relationen erweitert wird
- in einer 1:n-Beziehung wird die Relation erweitert, bei der das n steht, sonst würden Redundanzen auftreten
- besitzt die Relation beschreibende Attribute, so werden diese zusätzlich noch bei der erweiterten Relation angegeben
Nachteil: es können NULL-Werte auftreten
Vorteil: es werden keine zusätzlichen Relationen benötigt
9
Q
m:n Beziehungen
A
- ist immer eine zusätliche Relation erforderlich, um die betreffenden Entitäten zu verknüpfen
- diese Relation enthält die Primärschlüssel der beiden Relationen und kann zusätzlich noch beschreibende Attribute enthalten
10
Q
Generalisierung/Spezialisierung (is-a-Beziehung)
A
- für die Überführung einer is-a-Beziehung gibt es mehrere Möglichkeiten, die von dem jeweiligen Schema und von der Umgebung (dem Kontext) abhängig sind
- in jedem Fall ist aber keine zusätzliche Relation für die Beziehung nötig
1. - es wird für jede Entitätsmenge eine Relation mit den relevanten Attributen angelegt
- den Teilmengen (Spezialisierungen) wird der Primärschlüssel der Obermenge (Generalisierung) als Fremdschlüssel hinzugefügt, um die Zuordnung zu sichern
2.
- es wird nur eine Relation angelegt, die relevante Attribute der Teilmengen, sofern vorhanden, mit aufnimmt
- diese Möglichkeit der Umsetzung kann dann angewandt werden, wenn die Teilmengen keine oder wenige eigene Attribute haben
11
Q
Normalisierung des Datenbankes
A
Ziele:
- Anomalien beheben
- Redundanzen vermeiden
- einen übersichtlichen und möhlichst einfachen Aufbau der Relationen zu erhalten
- eine einfache Datenpflege ermöglichen
12
Q
Anomalien
A
- eine Relation befindet sich in der ersten Normalform (1NF), wenn jedes Attribut der Relation atomar ist (die Attribute dürfen keine weiteren Untergliederungen aufweisen bzw. für jedes Attribut eines Tupels ist nur ein Eintrag zulässig
- werden Tuoel geändert, neue eingefügt oder alte gelöscht, können fehlerhafte Zustände auftreten; diese werden durch die Datenredundanz hervorgerufen und führen zu Inkonsistenzen
- diese Fehler werden auch als Anomalien bezeichnet
13
Q
Einfüge-Anomalie:
A
- wenn sie der Relation einen neuen Mitarbeiter hinzufügt, der zu diesem Zeitpunkt an keinem Projekt Mitarbeiter beitet, entstehen leere Datenfelder
Probleme: - Speicherplatz wird verschwendet
- einem Attribut wird kein Wert zugewiesen, das Teil des Primärschlüssels ist, wie im Beispiel der Projektnummer
- beim Verwalten und Suchen dieses Datensatzes können Fehler auftreten
- in einigen Datenbaken ist es gar nicht möglich, einen solchen Datensatz zu speichern
14
Q
Lösch-Anomalie
A
- wenn man einen vorhandenen Mitarbeiter löscht, werden auch die zugehörigen Projektdaten gelöscht
- sind die Daten für dieses Projekt nur bei diesem Mitarbeiter gespeichert, gehen diese verloren
15
Q
Änderungs-Anomalie:
A
- wenn sich der Familienname eines Mitarbeiters ändert, müssen alle Datensätze geändert werden, die diesen Wert beinhalten
- wird der Familienname nur in einem Datensatz geändert, wird die Relation Inkonsistent, da in diesem Fall zu einer Personalnummer zwei verschiedene Familiennamen existieren
