10.1. Funktionale Abhängigkeiten - Datenbanknormalisierung history menue Letztmalig dran rumgefummelt: 20.09.18 15:22:02
Datenbanknormalisierung ist der mehr oder weniger gut geglückte Versuch, einen Datendiskurs aus informationstechnischer Sicht so aufzubereiten, dass er nur minimal redundant ist, konsistent auch in der Phase der Datenpflege bleibt, wenig NULLWERTE enthält und den Ausschnitt aus der Welt in der Nutzung der Datenbasis sauber darstellt. Alle Objekte müssen dazu eindeutig durch gemeinsame Merkmale beschrieben worden sein und relational ohne Zirkelverbund miteinander verknüpft sein.
Eindeutige DB-Normalisierung vermeidet Anomalien, welche sich in der Daten
pflege ansonsten in jedem Falle ergeben.
  1. Normalformen von Datenbansen
  2. Analyse eines Datenbestandes
  3. Projektmanagement in der praktischen Datenbanktechnik
  4. dBASE IV-kompatible Relationships

Datenbanken

Logo der Daten-Normalisierung

inhaltlich auf korrektem Stand - evtl. partiell unvollständig ;-)

Wissen für Fortgeschrittene der Informatik

Quellen:

1. Normalformen von Datenbasen history menue scroll up
Die Normalformen beschreiben den Übergang vom einfachen Datenbestand zum maximal Objektrelationen Modell einschließlich sauberem Schlüsselkonzept sowie Einhaltung der Integritätsbestimmungen.

gegebener Datenbestand - keine Datenbank!

Hier wird der Datenbestand einfach durch die formale und unkomplizierte Erfassung der Eigenschaften der Objekte beschrieben. So werden typische "Datenbanken" von Anfängern beispielsweise mit Works erstellt - professionelle Datenbanken lassen solche Arbeitsweise gar nicht zu!

Kundenname Adresse Automarke Typ Seriennummer Verkäufer Verkaufsdatum
Meier Platanenweg 7 VW
OPEL
Golf
Kadett
123456
345678
Schmid
Plüss
23.4.92
7.8.92
Müller Altstadt 12 VW Golf 388721 Frey 17.6.92
Steffen Gartenstraße 7 VW Polo 222245 Schmid 15.7.92
Steffen Augasse 12 Audi Quattro 122154 Frey 13.11.92
    Opel Manta 445321    
          Schenk  

die "nullte" Normalform wird auch als ein Datenbestand bezeichnet

  • es existieren schon Attribute und es werden Objekt beschrieben
  • die Objekte werden durch ihre Merkmale beschrieben
  • ein Auffinden von Informationen ist grundsätzlich möglich - jedoch nicht nach den mathematischen Modellen einer Datenbank
  • der Datenbestand ist redundanzfrei

Die erste Normalform einer Datenbasis

Eine Tabelle befindet sich genau dann in der ersten Normalform, wenn alle Attribute nur einfache Attributwerte aufweisen (NULLWERTE eingeschlossen).

KdNr Kundenname Adresse ANr Automarke Typ Seriennummer VNr Verkäufer Verkaufsdatum
1 Meier Platanenweg 7 1 VW Golf 123456 1 Schmid 23.4.92
1 Meier Platanenweg 7 2 OPEL Kadett 345678 2 Plüss 7.8.92
2 Müller Altstadt 12 3 VW Golf 388721 3 Frey 17.6.92
3 Steffen Gartenstraße 7 4 VW Polo 222245 1 Schmid 15.7.92
4 Steffen Augasse 12 5 Audi Quattro 122154 3 Frey 13.11.92
      6 Opel Manta 445321      
      0       4 Schenk  

die "erste" Normalform reduziert die Informationsangabe auf einen Eintrag pro Zelle

  • es existieren Attribute und zu jedem Attribut genau ein Attributwert, NULLWERTE eingeschlossen
  • die Objekte werden durch ihre Merkmale beschrieben
  • ein Auffinden von Informationen ist auch hier grundsätzlich möglich
  • jedoch ist die Datenhaltung redundant
  • ist die maximale Datenhaltungsform, die ohne relationale Modelle möglich ist (Works)

Die zweite Normalform einer Datenbasis

Eine Tabelle befindet sich genau dann in der zweiten Normalform, wenn alle Attribute nur einfache Attributwerte aufweisen (NULLWERTE eingeschlossen) und redundante Datenhaltung durch relationale Modelle beseitigt wird (Schlüssel sind die zulässige Redundanz).

KdNr Kundenname Adresse
1 Meier Platanenweg 7
2 Müller Altstadt 12
3 Steffen Gartenstraße 7
4 Steffen Augasse 12

Relationales Entity "KUNDE"

ANr Automarke Typ Seriennummer
1 VW Golf 123456
2 OPEL Kadett 345678
3 VW Golf 388721
4 VW Polo 222245
5 Audi Quattro 122154
6 Opel Manta 445321

Relationales Entity "AUTO"

VNr Verkäufer
1 Schmid
2 Plüss
3 Frey
4 Schenk

Relationales Entity "VERKÄUFER"

KdNr ANr VNr Verkaufsdatum
1 1 1 23.4.92
1 2 2 7.8.92
2 3 3 17.6.92
3 4 1 15.7.92
4 5 3 13.11.92

Relationales Entity "VERKAUF"

  • es existieren Attribute zu jedem Attribut genau ein Attributwert, NULLWERTE eingeschlossen
  • die Objekte werden durch ihre Merkmale beschrieben
  • ein Auffinden von Informationen ist auch hier grundsätzlich möglich
  • jedoch ist die Datenhaltung redundant
  • ist die maximale Datenhaltungsform, die ohne relationale Modelle möglich ist (Works)

2. Analyse eines gegebenen Datenbestandes history menue scroll up

Voraussetzung für die Entwicklung eines praktisch auch funktionierenden Datenmodells sind konsistente (einander nicht widersprechende Daten - ein LKW kann zu einem Zeitpunkt nicht auf zwei verschiedenen Straßen unterwegs sein - das ist in der Welt und natürlich auch in der Datenhaltung falsch

Erstellen Sie die zugehörigen Tabellen und Bezüge mit Datenintegrität in FoxPro unter der Relation entsprechenden Namen!

TYP-

Tonnage

Halter

Firmensitz

Kennzeichen

Steuer pro Jahr

Zulassung

zulässige Anhänger

Fahrer

Mercides Bonz

7,5 t

Müller Transport GmbH.

Dresden

DD-AG 201

steuerfrei

2.6.96 - 17.10.05

13.1.08 - heute

1.     Sattelauflieger 11,5 t

2.     Schüttgutlader 15,7 t

3.     Pritschenhänger mit Plane

1.     Müller aus Freiberg am 17.2.15 von 6.00 - 17.30 Mit Anhänger 1

2.     Pohl aus Dresden am 19.2.15 von 9.30 - 24.00 Mit Anhänger 3

3.     Pohl aus Dresden am 20.2.15 von 0.00 - 3.45 Mit Anhänger 1

IVEKOS

13 t

René Staphan

Freiberg

FG-VK 36

6281.-€

27.6.95 - heute

4.     Schüttgutlader 8 t

5.     Sattelauflieger 14,7 t

6.     Pritschenhänger 13 t

7.     Hummso aus Freital am 3.5.15 von 6.30 - 21.30 Mit Anhänger 5

8.     Pohl aus Dresden am 23.2.15 von 6.15 - 17.00 Mit Anhänger 5

9.     Meier aus Pirna am 3.8.15 von 12.00 - 21.30 Mit Anhänger 6

MON

8 t

Scholz Transport-Service GmbH.

Meißen

MEI-DC 801

steuerfrei

2.12.97 - 9.9.07

1.1.09 - heute

7.     Planenlader 6,5 t

8. Muldenkipper 7 t

9. Baumlader 8,5 t

10.     Pohl aus Dresden am 17.12.14 von 5.45 - 19.00 Mit Anhänger 8

11. Pohl aus Dresden am 19.12.14 von 9.00 - 22.30 Mit Anhänger 8

12. Hummso aus Freital am 21.8.13 von 0.30 - 23.45 Mit Anhänger 7

FURDZ Transit

4 t

Fuhrunternehmen Friedrich

Oederan

FG-HD 318

509.-€

12.9.05 - heute

10.     Kipper 8 t

11.   Kofferaufbau 5,7 t

12.  Dreiseitenkipper

13.     Hummso aus Freital am 3.5.09 von 9.30 - 22.30 Mit Anhänger 10

14. Pohl aus Dresden am 23.2.15 von 6.15 - 17.00 Mit Anhänger 12

15. Meier aus Pirna am 3.3.07 von 9.00 - 23.30 Mit Anhänger 11

IVEKOS

12 t

Scholz Transport-Service GmbH.

Meißen

FG-BJ 895

steuerfrei

2.12.97 - 9.9.07

1.1.09 - heute

7.     Planenlader 6,5 t

8. Muldenkipper 7 t

9. Baumlader 8,5 t

10.     Pohl aus Dresden am 17.12.14 von 5.45 - 19.00 Mit Anhänger 8

11. Pohl aus Dresden am 19.12.14 von 9.00 - 22.30 Mit Anhänger 8

12. Hummso aus Freital am 21.8.13 von 0.30 - 23.45 Mit Anhänger 7

FURDZ Traveller

4 t

Fuhrunternehmen Friedrich

Oederan

DD-KL 807

509.-€

12.9.05 - heute

10.     Kipper 8 t

11.   Kofferaufbau 5,7 t

12.  Dreiseitenkipper

13.     Hummso aus Freital am 3.5.09 von 9.30 - 22.30 Mit Anhänger 10

14. Pohl aus Dresden am 23.2.15 von 6.15 - 17.00 Mit Anhänger 12

15. Meier aus Pirna am 3.3.07 von 9.00 - 23.30 Mit Anhänger 11

Gegebener Datenbestand


3. Projektmanagement in der Datenbanktechnik history menue scroll up
Hier zeigen wir von der simplen, jedoch integren Datenhaltung, wie man zu einem sauberen Schlüsselkonzept gelangt. Weder ist die Datenhaltung atomar, noch ist sie relational und somit logischerweise auch nicht frei von Redundanzen sowie "NULLWERTEN". Streng genommen entsteht jedoch die Masse der praktischen Datenerfassung genau auf diese Art und Weise.

 

Zu dem nachfolgenden Datenbestand ist ein Relationen-Modell anzugeben und unter einem DBMS entsprechende Datenbestände aufzubauen!

PERSONALNR

NAME

ABTEILUNGSNR

BEZEICHNUNG

POJEKTRNR

PROJEKTNAME

111

Meier

11

Einkauf

15,16

PA, PB

112

Schmitt

12

Produktion

15,17

PA, PC

113

Müller

12

Produktion

17, 18, 19

PC, PD, PE

120

Huber

11

Einkauf

15, 18

PA, PD

126

Fischer

16

Verkauf

18, 20, 23

PD, PG, PI

132

Jäger

16

Verkauf

17, 19

PC, PE

... die 2. Normalform des gegebenen Datenbestandes

PERSONALNR

NAME

ABTEILUNGSNR

BEZEICHNUNG

POJEKTRNR1

POJEKTRNR2 POJEKTRNR3

PROJEKTNAME1

PROJEKTNAME2 PROJEKTNAME3

111

Meier

11

Einkauf

15

16  

PA

PB  

112

Schmitt

12

Produktion

15

17  

PA

PC  

113

Müller

12

Produktion

17

18 19

PC

PD PE

120

Huber

11

Einkauf

15

18  

PA

PD  

126

Fischer

16

Verkauf

18

20 23

PD

PG PI

132

Jäger

16

Verkauf

17

19  

PC

PE  

NULLWERTE sind notwendig - diese jedoch machen das Abfrage-Ergebnis einer Datenbasis immer fragwürdig

PERSONALNR

NAME

ABTEILUNGSNR

BEZEICHNUNG

POJEKTRNR

PROJEKTNAME

111

Meier

11

Einkauf

15

PA

111

Meier

11

Einkauf

16

PB

112

Schmitt

12

Produktion

15

PA

112

Schmitt

12

Produktion

17

PC

113

Müller

12

Produktion

17

PC

113

Müller

12

Produktion

18

PD

113

Müller

12

Produktion

19

PE

120

Huber

11

Einkauf

15

PA

120

Huber

11

Einkauf

18

PD

126

Fischer

16

Verkauf

18

PD

126

Fischer

16

Verkauf

20

PG

126

Fischer

16

Verkauf

23

PI

132

Jäger

16

Verkauf

17

PC

132

Jäger

16

Verkauf

19

PE

Redundanzen sind notwendig - diese jedoch machen das Abfrage-Ergebnis einer Datenbasis fast immer falsch und die Datenhaltung unmöglich

und so sieht die Datenbasis überführt in die zweite Normalform aus

ABTEILUNGSNR

BEZEICHNUNG

11

Einkauf

12

Produktion

16

Verkauf

Entitytype ABTEILUNG

PERSONALNR

NAME

ABTEILUNGSNR

111

Meier

11

112

Schmitt

12

113

Müller

12

120

Huber

11

126

Fischer

16

132

Jäger

16

Entitytype MITARBEITER

POJEKTRNR

PROJEKTNAME

15

PA

16

PB

17

PC

18

PD

19

PE

20

PG

23

PI

Entitytype PROJEKT

PERSONALNR

POJEKTRNR

111

15

111

16

112

15

112

17

113

17

113

18

113

19

120

15

120

18

126

18

126

20

126

23

132

17

132

19

Entitytype BEARBEITET


4. dBASE IV-komplatible Relationships history menue scroll up
  dBASE IV war vormals das erste relationales DBMS, welches sich 100 % ig an den mengentehoretischen Modellen des amerikanischen Mathematikers E. F. Codd orientierte.
dBASE war das erste weithin genutzte dateibasierende Datenbankmanagementsystem (DBMS) für Mikrocomputer. Es wurde von dem Unternehmen Ashton-Tate ursprünglich für das Betriebssystem CP/M entwickelt und vertrieben. Später wurde die Datenbank-Applikation auf den IBM-PC unter DOS portiert.
Die Grundidee des dBASE-Systems ist, die Tabellen einer Datenbank in speziell strukturierten Dateien (DataBaseFiles = DBF) zu halten und zur Verarbeitung eine Programmiersprache der vierten Generation bereitzustellen - das ist das, was wir heute CODD'sches Relationenmodell nennen.

Zu dem nachfolgenden Datenbestand ist ein Relationen-Modell anzugeben und unter einem DBMS entsprechende Datenbestände aufzubauen!

S_NUMMER

NACHNAME

VORNAME

AUFGABEN_NR

AUFG_BEZ

KLASSE

POJEKTRNR

PROJEKTNAME

M63_2009

Holback

Jens

21, 24

Schulgarten, Hort-Betreuung

JG2009

AG17, AG29

Flugmodellbau, Turnen

M63_2008

Holzerland

Peter

12

Sozialdienst

JG2009

AG15, AG22

Graffitty, Schulchor

W09_2009

Köllner

Doreen

09, 18

Samariter, Schülerhilfe

JG2009

AG17, AG18, AG19

Flugmodellbau, Handball, Tennis

M05_2009

Frihse

Klaus

11, 18, 27

Grünflächenpflege, Schülerhilfe, Fahrradpark

JG2009

AG23

Elektronik

W21_2010

Yannix

Dorothee

02, 18, 26

Werkraum-Ordnung, Schülerhilfe, Baumpflege

JG2010

AG17, AG20, AG23

Flugmodellbau Töpfern, Elektronik

M11_2009

Frihse

Klaus

11, 26

Grünflächenpflege, Baumpflege

JG2009

AG18, AG20, AG23

PA, PD

M06_2009

Vietz

Stefan

16

Pausenaufsicht

JG2010

AG18, AG20, AG23

Handball, Töpfern, Elektronik

M46_2009

Selbmann

Gerd

11, 27

Grünflächenpflege, Fahrradpark

JG2009

AG15, AG18

Graffitty, Handball

W31_2009

Paulick

Michelle

02, 16, 26

Werkraum-Ordnung, Pausenaufsicht, Baumpflege

JG2010

AG18, AG20, AG23

Flugmodellbau, Töpfern, Elektronik

W16_2009

Sommer

Claudia

02, 16, 27

Werkraum-Ordnung, Pausenaufsichte, Fahrradpark

JG2009

AG15, AG18, AG03

Graffitty, Handball, Programmierung

M13_2009

Conrad

Paul

01, 12, 27

Aquarienpflege, Sozialdienst, Fahrradpark

JG2009

AG18, AG21, AG23

Flugmodellbau, Botanik, Elektronik

W74_2009

Pienert

Maxi

18, 26

Schülerhilfe, Baumpflege

JG2010

AG15, AG19

Graffitty, Tennis

M51_2009

Kitzscher

Johann

01

Aquarienpflege

JG2009

AG18, AG20, AG21

PFlugmodellbau, Töpfern, Botanik

W19_2009

Stein

Franziska

13

Sportgeräteausleihe

JG2010

AG18, AG20

Flugmodellbau, Töpfern



zur Hauptseite
© Samuel-von-Pufendorf-Gymnasium Flöha © Frank Rost am 4. November 2007

... dieser Text wurde nach den Regeln irgendeiner Rechtschreibreform verfasst - ich hab' irgendwann einmal beschlossen, an diesem Zirkus nicht mehr teilzunehmen ;-)

„Dieses Land braucht eine Steuerreform, dieses Land braucht eine Rentenreform - wir schreiben Schiffahrt mit drei „f“!“

Diddi Hallervorden, dt. Komiker und Kabarettist

Diese Seite wurde ohne Zusatz irgendwelcher Konversationsstoffe erstellt ;-)