Datenbank – Datenbanksystem

Präsentation zum Thema: "Datenbank – Datenbanksystem"—  Präsentation transkript:

1 Datenbank – Datenbanksystem
verwaltungssystem Menge von zentral gespeicherten Daten- beständen (Data Base) Zusammenfassung aller Programme und Prozeduren zur Handhabung der gespeicherten Daten (Data Base Management System) Zielsetzungen - Vermeidung von Redundanz - Sicherung gegen Datenverlust - Schutz vor unberechtigtem Zugriff - Mehrfachnutzung von Datenbeständen - schnelle Antwortzeiten - einfache Handhabung LV: SE 2001/2002 Zilahi Datenbank

2 Relationale Datenbank
Speicherung der Daten in relationaler Form Beispiel: Folgender Zusammenhang soll gespeichert werden: Mandant Auftrag Ein Mandant kann mehrere Aufträge erteilen. Jeder Auftrag stammt jedoch von genau einem Mandanten. Es soll gespeichert werden, welcher Mandant welche Aufträge aufgegeben hat bzw. von welchem Mandanten ein bestimmter Auftrag stammt. LV: SE 2001/2002 Zilahi Datenbank

3 Relationale Datenbank Beispiel
Annahme: Es gibt 2 Mandanten M1 und M2. Es gibt 3 Aufträge A1, A2 und A3. M := {M1, M2} Menge der Mandanten A := {A1, A2, A3} Menge der Aufträge Für die Produktmenge MxA gilt: MxA := {(M1,A1),(M1,A2),(M1,A3),(M2,A1),(M2,A2),(M2,A3)} Eine Relation R der Mengen M und A ist eine Teilmenge von MxA, d.h. R MxA 'Bestell' - Relation R R = {(M1,A1), (M2,A2), (M2,A3)} LV: SE 2001/2002 Zilahi Datenbank

4 Relationale Datenbank Tabellenform
'Bestell' - Relation: R = {(M1, A1), (M2, A2), (M2,A3)} Mandant Auftrag M1 M2 A1 A2 A3 LV: SE 2001/2002 Zilahi Datenbank

5 Entity Sets Relation-Darstellung
Nicht nur Beziehungen (s. Beziehung zwischen Mandanten und Aufträge), sondern auch Entity Sets lassen sich als Relation darstellen! Entity Set: Mandant Attribute: - Nummer - Name - Adresse Es sei: Nr := Menge aller Nummern Na := Menge aller Namen Ad := Menge aller Adressen Mandant - Relation M mit: M Nr x Na x Ad Nr Name Adresse 1 2 3 4 5 Hans Otto Klaus Meyer Adele Schmitz Rainer Ochs Gisela Simon 35390 Giessen 35392 Giessen 35396 Giessen 35398 Giessen LV: SE 2001/2002 Zilahi Datenbank

6 Normalform entwickelt von E.F. Codd in den 70er Jahren
Ausgangsbasis: Entity Relationship Model Entity Set -, Attribut-, Beziehungsbeschreibungen Ziel: Aufbereitung der Daten für eine effiziente Speicherung im Rahmen relationaler Datenbanksysteme Grundsätze: Jedes Attribut sollte nur einmal gespeichert werden. Ein Attribut sollte dem Entity Set zugeordnet werden, mit dem es die engste Beziehung hat. Aufdecken von fehlenden Entity Sets und fehlenden Beziehungen. LV: SE 2001/2002 Zilahi Datenbank

7 1. Normalform Definition: Ein Entity Set befindet sich in der
1. Normalform, falls - das Entity Set einen eindeutigen Schlüssel enthält und - kein Attribut bzw. Attributgruppe je Entity mehr als einen Wert enthält Beispiel: Attribute: - Mandant-Nr. - Name - Adresse etc. Mandant Falls ein Mandant mehr als eine Adresse hat, befindet sich das Entity Set Mandant nicht in der 1. Normalform LV: SE 2001/2002 Zilahi Datenbank

8 1. Normalform - Vorgehen Entferne wiederholt vorkommende Attribute bzw. Attributgruppen (repeating attribut; repeating group) Definiere ein neues Entity Set für die wiederholt vorkommenden Attribute bzw. Attributgruppen Übernehme zur Kennzeichnung den Primärschlüssel des 'alten' Entity Sets in das neue Entity Set Unnormalisierte Form: NF: Mandant Mandant Mandant-Nr. Name Adresse 1 Adresse 2 ... Mandant-Nr. Name Adresse Mandant-Nr. Adresse LV: SE 2001/2002 Zilahi Datenbank

9 1. Normalform – Beispiel 1 Unnormalisierte Form Projekt
Projekt- Projekt- Projekt- Mitarbei- Mitarbeiter- Abt.- Abt.- Nr Name Art ter-Nr Name Nr Name Bsys E Schmitz Biblio Karl DV Hinz DV Einsys E Sens Einkauf Arnheim DV Karl DV Unger DV LV: SE 2001/2002 Zilahi Datenbank

10 1. Normalform – Beispiel 2 1. Normalform Projekt- Projekt Mitarbeiter
Projekt- Projekt- Projekt- Nr Name Art Bsys E Einsys E Projekt- Mitarbei- Mitarbeiter- Abt.- Abt.- Nr ter-Nr Name Nr Name 234 255 111 344 565 444 765 299 Schmitz Karl Hinz Sens Arnheim Unger 4 2 6 Biblio Dv Einkauf DV LV: SE 2001/2002 Zilahi Datenbank

11 Attribut Ein Attribut, oder eine Attributkombination ist
von einem anderen Attribut B, oder einer Attribut- kombination voll funktional abhängig, falls das Attribut A vom gesamten Attribut B, oder Attribut- kombination und nicht nur von einem Teil von B abhängt. Ein Attribut, oder eine Attributkombination ist von einem anderen Attribut oder einer Attributkombina- tion funktional abhängig, falls der Wert des 1. Attributes, oder Attributkombination durch den Wert des 2. Attributes, oder die Attributkombination bestimmt wird. Attributkombination: Projekt-Nr. + Mitarbeiter-Nr. Das Attribut Mitarbeiter-Name hängt nur von einem Teil der Attributkombination (nämlich von Mitarbeiter-Nr.) funktional ab. Mitarbeiter-Nr. hängt nicht voll von der Attributkombination Projekt-Nr. + Mitarbeiter-Nr. ab. Abt.-Nr. Abt.-Name Die Abt.-Nr. bestimmt den Abt.-Namen Der Abt.-Name ist von der Abt.-Nr. funktional abhängig Mitarbeiter-Nr. Projekt-Nr. Mitarbeitername Projektname LV: SE 2001/2002 Zilahi Datenbank

12 2. Normalform aus der 1. Normalform
Ein Entity Set befindet sich in der 2. Normalform (2. NF), wenn es sich in der 1. NF befindet und zusätzlich jedes Attribut vom Primärschlüssel voll funktional abhängt. Vorgehensweise: Entferne Attribute, die nicht voll funktional abhängig sind. Definiere ein neues Entity Set. Der Schlüsselteil, von dem das Attribut abhängig ist, wird zum Primärschlüssel des neuen Entity Sets. LV: SE 2001/2002 Zilahi Datenbank

13 2. Normalform – Beispiel 1 Beispiel: Projekt-Mitarbeiter
Projekt- Mitarbei- Mitarbeiter- Abt.- Abt.- Nr ter-Nr Name Nr Name 234 255 111 344 565 444 765 299 Schmitz Karl Hinz Sens Arnheim Unger 4 2 6 Biblio DV Einkauf Primärschlüssel ist: Projekt-Nr. + Mitarbeiter-Nr. Die Nicht-Schlüssel-Attribute - Mitarbeiter-Name - Abt.-Nr. - Abt.-Name hängen nur von der Mitarbeiter-Nr. ab und nicht vom gesamten Primärschlüssel! LV: SE 2001/2002 Zilahi Datenbank

14 2. Normalform – Beispiel 2 statt: Projekt-Mitarbeiter
Projektzugehörigkeit Mitarbeiter Projektzugehörigkeit: Projekt-Nr. Mitarbeiter-Nr. 234 255 11 344 565 444 765 299 Mitarbeiter: Mitarbeiter- Mitarbeiter- Abt.- Abt.- Nr Name Nr Name 111 344 565 444 765 299 Schmitz Karl Hinz Sens Arnheim Unger 4 2 6 Biblio DV Einkauf LV: SE 2001/2002 Zilahi Datenbank

15 3. Normalform Ein Entity Set befindet sich in der 3. Normalform
(3. NF) falls jedes Attribut vom Primärschlüssel voll funktional abhängig und von jedem Nicht- schlüsselattribut funktional unabhängig ist. Hinweis: Hängt ein Nichtschlüsselattribut C von einem anderen Nichtschlüsselattribut B funktional ab (beide hängen funktional von einem Primärschlüssel A ab!), so ergibt sich auch eine sog. transitive Abhängigkeit der Attribute. A B C Beispiel: Mitarbeiter-Nr Abt.-Nr Abt.-Name LV: SE 2001/2002 Zilahi Datenbank

16 3. Normalform aus der2. Normalform
Entferne aus dem Entity Set alle Attribute, die von Nichtschlüsselattributen abhängen. Definiere ein neues Entity Set. Das Nichtschlüsselattribut, von dem andere Nicht- schlüssel abhängen, wird zum neuen Primärschlüssel. Der Primärschlüssel des neuen Entity Sets bleibt als 'Fremdschlüssel' im ursprünglichen Entity Set. LV: SE 2001/2002 Zilahi Datenbank

17 3. Normalform - Übersicht
Entity Sets Attribute - Projekt-Nr. - Projektname - Projektart - Mitarbeiter-Nr. - Mitarbeitername - Abt.-Nr. - Abt.-Name Schlüssel Projekt Schlüssel Projektzugehörigkeit Schlüssel Schlüssel Mitarbeiter Schlüssel Abteilung LV: SE 2001/2002 Zilahi Datenbank

18 3. Normalform – Beispiel 1 Ausgangstabelle
Mitarbeiter: Mitarbei- Mitarbeiter- Abt.- Abt.- ter-Nr Name Nr Name 111 344 565 444 765 299 Schmitz Karl Hinz Sens Arnheim Unger 4 2 6 Biblio DV Einkauf Das Nichtschlüsselatribut 'Abt.-Name' ist von dem Nichtschlüsselattribut 'Abt.Nr. funktional abhängig. Mitarbeiter-Nr Abt.-Nr Abt.-Name LV: SE 2001/2002 Zilahi Datenbank

19 3. Normalform – Beispiel 2 Mitarbeiter Abteilung
Mitarbeiter: Mitarbeiter-Nr. Mitarbeiter-Name Abt.-Nr. 111 344 565 444 765 299 Schmitz Karl Hinz Sens Arnheim Unger 4 2 6 Abteilung: Abt.-Nr. Abt.-Name DV Biblio Einkauf 2 4 6 LV: SE 2001/2002 Zilahi Datenbank

20 Physikalische Umsetzung
Es gibt keine festen Regeln für die Umsetzung eines logischen Datenmodells in einen Datenbankentwurf. Es gibt mehr als nur eine Umsetzungsmöglichkeit! Kriterien für die physikalische Umsetzung: - Änderungshäufigkeit - Zugriffshäufigkeit - Speicherplatzrestriktionen - Zugriffszeitrestriktionen etc. LV: SE 2001/2002 Zilahi Datenbank

21 Physikalische Umsetzung Beispiel 1
erteilt Beispiel: Mandant Auftrag Mandant-Nr. M_name M_adresse Auftrags-Nr. Datum Kategorie Umsetzungsalternativen: 1. Kunden-Nr. M_name M_adresse Auftrags-Nr. DatumKategorie 1 2 Hugo Adam Astadt Bstadt 1 2 3 4 5 1.1.96 1.6.96 1.1.97 1.5.97 1.8.98 E I Mandant-Nr. M_name M_adresse 1 2 Hugo Adam Astadt Bstadt 2. Auftrags-Nr. Mandant-Nr. Datum Kategorie 1 2 3 4 5 1 2 1.1.96 1.6.96 1.1.97 1.5.97 1.8.97 E E E I I LV: SE 2001/2002 Zilahi Datenbank

22 Physikalische Umsetzung Beispiel 2
Mandant-Nr. M_name M_adresse 1 2 Hugo Adam Astadt Bstadt Auftrags-Nr. Datum Kategorie 1 2 3 4 5 1.1.96 1.6.96 1.197 1.5.97 1.8.97 E E E I I Mandant-Nr. Auftrags-Nr. 1 2 3 4 5 1 2 Welche Vor- und Nachteile haben die Umsetzungs- alternativen? Bei welcher Alternative sind die Normalformen erfüllt? LV: SE 2001/2002 Zilahi Datenbank